Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
In this thread varkor raised the possibility of using gerby to compile and display the nLab from git-maintained LaTeX source. Let’s discuss it!
I would be very excited about the idea of being able to edit the nLab directly using actual LaTeX code in my favorite LaTeX editor, and I bet a lot of other people would too. In particular, if I understand correctly we would then be able to define our own macros, which is something we’ve wanted for a long time. Of course, the database migration problem might be even harder – or it might not, since if I understand correctly the output would only need to be a collection of text files, not an import into a different format of database, so the only real thing to automate would be translating nLab-markdown syntax to LaTeX.
It looks like gerby uses plasTeX whose HTML5 output uses mathjax, so we’d have to compare the performance there I guess. In principle, I guess one could enhance plasTeX with a MathML renderer, but that doesn’t seem to have been done yet?
What about pictures and diagrams? It looks like the stacks project uses xypic with xyjax, but we could presumably extend plasTeX with the ability to render TikZ using tikzjax or perhaps better tex2svg.
How would links and redirects work? How about includes?
What other issues would there be?
My feelings about this are the same fundamentally as my feelings about moving to MediaWiki. Gerby also lacks most of the benefits software development-wise that people were touting for MediaWiki.
If people would like to use git to push content to the nLab, that is quite easy to implement, I can probably put something together in one evening’s work some time this week.
It’s true that it doesn’t yet have a very wide user base. But it would at least have a user base beyond us, and the stacks project is fairly substantial. (-: And unlike MediaWiki’s PHP, at least the rendering engine plasTeX appears to be written in, and extensible in, Python.
We’d have to think about tie-in with the nForum.
Let’s discuss it!
Do you have an exit strategy for the ensuing discussion? ;-)
An example of the past for how to proceed in such matters was Jake Bian’s change of the layout: Instead of starting a discussion and causing the inevitable bike-shed effect, he went ahead and implemented the change he envisioned. We saw it, liked it and forked it. It was a good step forward.
Gerby seems do be optimized for the perfect web output. But I don’t see the wiki functionality. The plan would be to implement all of this? Another point is, do you want to give every editor the full TeX power, i.e. defining own macros? Certainly some people will do some mess that is then hard for others to maintain.
While I originally mentioned Kerodon, it is maintained by a single author, so isn’t such a good comparison. However, the Stacks Project does use GitHub and pull requests, and so on, so it could be helpful to ask those responsible for running the Stacks Project about their experience with that kind of system.
If people would like to use git to push content to the nLab, that is quite easy to implement, I can probably put something together in one evening’s work some time this week.
For what it’s worth, I strongly support this idea. But in this case, I’d also ask for a command-line tool to verify nLab’s syntax (so that I don’t push incorrectly formatted articles).
It is worth pointing out that Keradon uses Gerby.
I think it is important to keep the following statistics in mind.
Kerodon has a single author, Jacob Lurie.
According to the statistics produced by git blame, 99.16% of the Stacks Project is due to Johan de Jong. Thus, it is also a one-man operation and its collaborative nature (so far) is a myth.
91.6% of Gerby’s code is due to Pieter Belmans and 85.6% of PlasTeX’s code is due to Kevin Smith.
In other words, these are single-man projects used by exactly two mathematicians so far. What happens if any of these folks retires? Maybe somebody else will pick it up, maybe not. Or it may end up like Instiki, which is still being maintained, but is no longer suitable for nLab’s purposes.
But I don’t see the wiki functionality. The plan would be to implement all of this?
The “everyone can edit” aspect of the wiki functionality would be implemented by git. The links between pages would presumably be just LaTeX \ref
s that gerby would compile into hyperlinks. Some tweaking of the syntax might be necessary. What else are you referring to?
What else are you referring to?
I would say that forcing people to use git or something similar would increase the threshold to contribute drastically. You mentioned (in the other thread) something like an online text editor. But wouldn’t this basically mean to program an interface?
You mentioned (in the other thread) something like an online text editor. But wouldn’t this basically mean to program an interface?
There are multiple possibilities here. Externally, people could use online editors like GitHub’s built-in editor or Overleaf, which doesn’t require knowledge of git. If editing facilities were still desired internally, the existing textarea could be kept (although it would be better to upgrade to something like CodeMirror).
I would say that forcing people to use git or something similar would increase the threshold to contribute drastically.
I’d be worried about that too.
Similiarly to the other discussion, and in accord with Urs’ suggestion, I think the best way forward here is to incorporate the ideas that we like, i.e. make possible local editing of nLab pages and submission of them (with the usual syntax checks, as Dmitri observes). I don’t see any real need for/benefits to a wholescale switch to gerby.
If people would like to use git to push content to the nLab, that is quite easy to implement, I can probably put something together in one evening’s work some time this week.
Has there been an update on this since the discussion?
My apologies, I gave a misleading impression here: I do not actually plan to implement this until more pressing matters are addressed (unless there is widespread demand for this over other things: my ’an evening this week’ was intended to be conditional on that).
I am not intending to reopen this discussion, but I was looking again at gerby for a totally different purpose and noticed that contrary to what I said in #1 it might actually also support TikZ (although I haven’t tested it yet). So I thought I’d add a comment here, so as not to mislead any future stumblers across this thread.
1 to 17 of 17