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.
A bibtex-like functionality might be good, but seems like a tall order, as this will not be dealt with by a handful lines of code. This might instead be something to outsource to a hired programmer once we have the donation mechanism in place, from March on?
Meanwhile, since bibtex is mostly a glorified include-mechanism, we can easily emulate something close right now:
Just write bibitems one by one into nLab pages, using some standardized naming convention, and then !include these where desired.
As an example for what I mean, I just created an item Quillen1967AHT-ref and included it into the list of references at model category (first item there).
On a more elementary note:
The vertical spacing above the first bullet list items on second nesting level is too small.
An example now in the Sandbox.
This might seem petty, but with hyperlinks and/or formulas in there it shows up a lot in our entries and looks bad, I think.
Thanks for raising! Just to let you know that I have seen these things and will respond/address them as soon a I get a chance.
Thanks, Richard.
I feel bad for raising yet one more issue. So not to rush, but just to record it:
I managed to make an entry – with the (beautiful, you must admit) title MΩΩSU(n) – which can’t be edited: hitting “edit” on the entry gives the HomePage.
The cause of the problem is clearly that I had renamed this entry to the (less beautiful but more sane) title Ravenel’s spectrum, leaving but a redirect to “MΩΩSU(n)” there.
So part of the system must know that the entry is gone and redirected. But other part of the system still displays the old version of the entry, without allowing to edit it away!
Thanks for raising, I’ll look into it as soon as I can!
Re #104: This was a curious one. The problem was that the cache of the beautifully named page was not removed. It turns out that the reason for this was the presence of the unicode character Ω; I could not even remove the cache file manually using rm on the server when using the full file name, I used some unique wildcard specification of it that did not involve a unicode character.
Though some experimentation indicates that only certain unicode characters lead to this issue, and thus its occurrence is not especially likely in general, I have made what I hope is a fix now.
Thanks!!
I have announced it in another thread, but I have now implemented an initial version of a fully fledged referencing mechanism for the nLab, as discussed in #98 - #101. Part of this implementation actually generates more or less exactly the same kind of page as Urs proposed in #101, just not a main nLab page, but a ’special’ page under nlab/reference/show which can be ’included’ using \bibitem rather than !include.
(What was requested in #98 is not implemented yet, just \cite).
There is a bug in referencing passworded pages (private labs). If I have a link from outside of my private lab and click on it during a day in which I did not log previously into the private page it will open the login page instead (OK). Then you enter or click the password (being saved in browser hence automatically entered or not), then it gets into the private lab, but during your fight with login window it lost the information which page was originally supposed to enter and it opens the homepage of the private lab instead. I think the default behavior would be to open the referenced page once the password is given.
Why this matters ? In my experience, it is fairly often time consuming to return to the referencing link and/or find it, for example if you have many windows open, you took a link from one window to open the private page in a new window. Then, after your link is lost in a fight with login window, it is difficult to find which one out of other 10-20 windows or tabs (which you did not plan to return soon to) contained the original link. Or one sometimes manually writes a long link to a private page and the link gets lost.
In edit mode, Hide markup help button has a suboptimal behaviour. People use this button if they want a clean page when editing. They sometimes also want to have wider place for the edit subwindow, but this does not happen. For me, usage of hide button is important when I share screen with somebody in Zoom and explain, say some math, by writing/solving some example in an edit window. After the session I tidy the example and publish it in my personal lab. The usage of Lab window is better than using an external editor as one can use the code which is previously in this scratch page (say the code which is already compiled and checked for rendering). For example of a personal lab page which I created in real time look for stat-041220 (zoranskoda). I spent only 20 minutes to tidy the page after editing it in a live instruction session for my students.
If you click on it and save, and reopen, the help will again reappear. If you do 20 saves and edits each time the help will reappear on the right hand side of the browser.
When one hides markup help, the space where the help becomes empty, but the window for editing stays shrunk to the previous width. I think that many editing tasks could be performed better in the edit window comprising almost the width of the browser and this is particularly important for readability of long formulas and when you share the screen.
There appears to be a missing space in Lex between “small” and “finitely” in the first bullet point, but there is a space in the source for the page.
This is a known bug, whitespace disappears between consecutive hyperlinked words. To work around it, for the moment, I have enforced whitespace (at Lex) by inserting
$\;$
Yes, the problem is that this is a bug in maruku, the Markdown renderer that Instiki uses, rather than in code I have written or in the old Instiki, so is tricky to fix. It will be gone once we move to the new Markdown renderer.
The algorithm that associates nForum discussions to nLab pages appears to be at least partially case-insensitive. This leads to, e.g., the “Discuss this page” link from span going to this discussion which is actually about the page Span.
Trying to correct a typo in higher Atiyah groupoid, pressing submit just gave me the same edit page. (The typo was Setc instead of Sect)
Thanks very much for reporting this Tim, the bug in the error handling was introduced in my major (if largely invisible) change announced here. I have now fixed the bug (see github), and also fixed the typo that you wished to fix (and a LaTeX error).
Re #114: Thanks for raising! I saw this when you first raised it, but then forgot about it; I have now fixed this. It can be tested for the pages SU(2) and su(2).
I fixed it about a year ago for the edit announcer, but the discussion detector is independent of that. The original reason for case insensitivity was that when these mechanisms were introduced, there was still plenty of inconsistency in titling of nForum discussions vs nLab page titles, and the idea was to avoid overlooking an existing page. Over the years since, things have become much more consistent, and it definitely it is better with case-sensitivity now.
A little tweak has now been made to show the wiki name as title of a wiki home page (e.g. ’nLab’ as title of HomePage) rather than the rather ugly ’HomePage’.
An edit I made has crashed the page flavour anomaly, but I can’t figure out what it was!
The error message is::
XML Parsing Error: mismatched tag. Expected: </div>. Location: https://ncatlab.org/nlab/show/flavour+anomaly Line Number 729, Column 35:
I’ll take a look later.
I have isolated the problem:
The error appears when an imagefromfile-environment has (a) a caption and (b) is included in a center-environment.
A minimal example is now in the Sandbox (which thereby doesn’t display, at the moment…)
I have now fixed this. Now that things work again, I have tweaked the syntax for some of the images at flavour anomaly to use captions correctly. Please check that it looks as intended!
Thanks! Looks good.
Minor point, but there is a grammar glitch in the new instructions on the right of the edit pane, where it says
Tikz can be used for figures almost exactly in LaTeX
(“as in”).
Maybe more importantly, as I was just reminded when I tried – and failed – to find the thread where you announced the renovation of the edit comments:
Search results on the nForum appear in chronological order, but they ought to appear in anti-chronological order (i.e. latest on top).
Moreover, there is only a “Next” button that jumps 20 or so search results ahead.
Together this makes it hard, at the moment, to have a useful search on the nForum for any keyword that has a non-trivial number of hits.
Apologies for the delay, I have been very busy. I have now fixed the typo.
Good idea regarding nForum searches. My feeling on this is that I don’t plan to do any significant changes to the existing nForum, but will make sure that the search functionality works in the way you describe in the new nForum, which I intend to make fully functional and live (i.e. as a replacement for the current nForum; it is live now at a different URL) before the completion of the imminent move to the cloud.
Since it is now implemented more or less verbatim in the new bibliography at Quillen1967, and since model category has been updated to use the latter (and there were no other uses of it), I have now deleted the example page created by Urs in #101 (in the interest of keeping things tidy :-)).
There is a bug that gets triggered when an item-list is followed by the closure of an ambient Definition/Proposition/Remark-environment without vertical whitespace in between.
I have put a minimal example into the Sandbox (which thereby does not render at the moment!):
\begin{remark}
Notice that
* bullet items without trailing vertical whitespace
* trigger a bug when followed by closure of the environment.
\end{remark}
After adding a reference, the entry sketch throws an error message on something in the bulk text.
Must be code that did compile before the parser was renovated. I tried to guess the offending strung, but failed.
Re #128, I have made sketch render now (by tweaking the syntax in one place). I believe that the lack of rendering was a consequence of the fix made in #122. The syntax in question was not a common pattern, and it is probably a corner case that the fix made in #122 does not cover. I’ll look into that when I get a chance, as well as into #127 (apologies, very busy at the moment).
Thanks, Richard!
Sorry, but here is one more issue. No rush, just to record it:
Over at sphere-fiber bundle in this sections I am using a bunch of tikzcd-digrams, and whenever I reduce the column separation with [column sep=tiny] it seems that also the row separation shrinks, and/or in fact the whole typesetting scale is reduced (i.e. also the font size decreases, unless I am hallucinating?).
The problem appears in the first two diagrams there. Contrast the scale with the third one. In the code the only difference between the first two and the third is that they have commands for reduced row or column separation.
Hi Urs, thank you for raising #130. This was a bit non-trivial to debug, but I’ve now pinned it down; the issue is actually to do with SVG, namely the relative sizes of the different SVG images (the rendered commutative diagrams) on the page. The text in those images is not actual text, but an SVG path (which is unfortunate, but would be very difficult to work around, as it comes from the tools used to create the SVG), so it gets scaled as with the entire image. In other words, the diagrams render correctly individually in LaTeX and indeed SVG, but are scaled differently when there are several of them on a page.
I’ll have a think to see if I can come up with a way of fixing this (short of writing a direct implementation of tikzcd into SVG!); I have an idea, but it’s not completely trivial to implement, and I’ll need to test it, so it may take me a little time before I get to it.
Thanks. But what does determine the resizing of those SVG images? Maybe I could work around it by adding some whitespace.
It will be determined by the browser. I’d suggest not to add whitespace; it might work, but would probably make things difficult for us later. I’ll try to get to it as soon as I can.
Thank you for the example; I have indeed seen it and will fix as soon as time allows. Feel free to edit it out of the Sandbox :-).
Hi Richard,
would it be easy to make the tikzcd diagrams on the nLab come out at about 1.2 times their current scale?
Currently the font size in tikzcd diagrams on the Lab is noticeably smaller than that of ambient Instiki text/formulas, which makes their combined appearance a little less neat than it could be. (I am currently looking at an example in sliced adjoint functors – section.)
Hi Richard,
maybe we need your help here: The page spin networks (plural) should just be redirecting to spin network (singular), but instead it sort of exists but in a weird way (e.g. can’t be edited and doesn’t show a page history).
Re #137: Fixed now. This was a caching issue: ’spin networks’ still existed in the cache; I guess the page was once called that and was renamed to ’spin network’ at some point, and that some problem occurred on the server following the renaming which caused the old cached page to not be deleted as it should.
Re #136: I have now made a small tweak to the code to explicitly set the font size to 12pt in Tikz diagrams (I have not touched xypic diagrams for the moment). For me, the diagrams then seem to end up at a compatible size to the surrounding text (as discussed earlier, see #131 and following, this is difficult to solve completely).
However, at sliced adjoint functors – section the main reason for the problematic sizing is the explicit setting of colsep and rowsep in the Tikz diagram code itself. I have fixed diagrams 1 (a) and 2 (a) to illustrate that the diagrams display fine when this explicit use of colsep and rowsep is removed, but I leave it to you (or whoever else is working on the page) to fix the others. You need to remove
[column sep={between origins, 33}, row sep=4]
and similar.
I also explicitly added more vertical space in 2 (a) for the long arrow; again, it is the Tikz code itself that determines this, so it needs to be handled manually.
I hope that my code change does not make too many existing Tikz diagrams now look far too big; if people notice any, please go ahead and fix them. It is a good principle to avoid explicit use of colsep and rowsep, and any other explicit sizing, unless absolutely necessary.
Re #127: I’ve taken a look, and see the reason for the problem, but it is something that needs care fixing. I’d like to focus on the move to the cloud for now, so will omit to fix this for the moment, as, though unfortunate, it is straightforwardly fixable by hand.
Thanks!!
I have taken the opportunity whilst I remember of changing all instances of historical page edits with author ’AnonymousCoward’ (which was the unfortunate default for a long time) to ’Anonymous’. Slightly scary with such database updates which affect thousands of edits in one command, but done now!
Not sure if this was noticed before, but the “Discuss this page” link from a “history” page seems not to work.
I have now tweaked the behaviour of the search results page when it returns no results, prompted by this discussion (see in particular #8).
Trying it out… Looks good! Thanks!
This was probably the cause for many or most accidental page creations that we had received in the past.
I have now fixed #143 I believe.
Re #145: Yes, I too think it might have well have been. It was worth digging into the nginx logs!
There was a request at another thread for \boxslash.
That other thread is of course here, where Richard did reply.
But following the links there, I see that we can type ⧄ (inside math mode inside entries) and it comes out as the desired “” (e.g. here).
Now it wouldn’t hurt to have this available as \boxslash, but typing ⧄ is no worse.
In fact, it’s a tad better even than typing ʃ for “”, as we have become accustomed to doing here.
So I guess we are fine regarding lifting properties.
But if Richard does find the time to implement \boxslash for ⧄,
maybe we could also get \shape for “ʃ”? :-)
Using ⧄ directly has the disadvantage that it will not scale, etc, correctly in general. Also, as I mentioned above, the symbol is also not visible on my machine with the fonts I have available. In fact \esh is already implemented (only on the nLab, not in the nForum), although I did it via a post-processing hack and not in itex2MML; I will change this once I’ve implemented \boxslash. Let me know whether I should use ⧄ or the other symbol for \boxslash; the latter has the advantage of being more widely available, but is more of a rectangle with a slash than a box with a slash.
Oh, I see, thanks.
Didn’t know (or forgot) about \esh. That’s good! Have now implemented this at shape modality.
Regarding scaling and availability I don’t know. But of course if you do implement \boxslash then we can use that generally and you can adjust its technical details behind the scenes as need be.
Just to highlight what you will have noticed:
The nLab just came back 5 minutes ago from being unresponsive for about half an hour, like it has been doing at this time of day for, I think, each day of the past few months.
I finally realized, a while back, that the nLab server goes down each day at exactly 1pm my local time here, which should be 9am GMT.
The downtime seems to vary. Today it was 31 or 32 minutes minutes, other days it’s less.
But the point at which it becomes unresponsive is always exactly 9:00 am GMT.
Maybe this suggests that there is a new cron-job that has been installed a few months ago, and which kicks in each day at the same time and steals all the server’s resoruces?
Anyway, I know you, Richard, are working on migrating us to a new server anyway, so such trouble with the old server may not be worth worrying about (as long as it does keep coming back after its daily nap… :-). Just thought I’d mention it here, also because other users here must be wondering about what’s going on
Not to pile up requests, but allow me just to mention the following for when there is spare time:
It would be useuseful if the call to tikzpicture could also load thetikzcd-package.
Because then we could, I think, use tikzcd-diagrams nested inside tikzpicture-environments inside Lab entries.
This would give an easy hack to group tikzcd-diagrams together, notably to arrange them horizontally. I had had a few occasions to whish that this were possible, but it was also brought up recently by a Guest here.
Just to note that I have seen the posts here, but have not had time to do anything about them yet; my apologies! Completely tied up at the moment. Please do continue to post anything that crops up, I’ll get round to addressing things eventually.
If you click on “Discuss this page” on a page that doesn’t currently have a discussion, you just get sent to the nForum homepage. It would make more sense to create a new linked thread. As it is, I have no idea how “Discuss this page” works: how do you set up a new thread that’s appropriately linked?
Just to say that while this is so, I commonly use the following hack: I make a trivial edit to the given entry, such as adding a blank line, type my comment into the box below the edit pane; so that by “submitting” this trivial edit, the software makes the comment appear in the correct thread.
On another note: since I was just asked for a pdf copy of an nLab page, with the comment that our “print”-functionality doesn’t work.
I don’t know what our “print” functionality is meant to do, clicking on it now has no effect on my machine. But if it is going to just call the browser’s print functionality, then it might be great to accompany it by a “convert nLab page to pdf”-functionality, simply by asking the browser to “print to pdf”, since few people seem to know that this is the way to go.
’Print’ basically just removes the menus (i.e. renders a page ’appropriate for printing’). It is not compatible with the new rendering features, though. I’d be somewhat inclined to remove the ’Print’ option completely; when it comes to printing to a pdf or whatever, this is the job of a web browser. Although removing the menus is probably a nice feature for printing, we could probably just rename ’Print’ to ’Display without menus’ or something
I am fine with completely removing the ’print’-option and have the user make their browsers print pages. But since many people don’t seem to know about this (!?) might it be easy to have our “print”-button simply call the browser’s print-functionality? If that works, we could also have a button “pdf” that would simply call the browser’s print-to-pdf functionality? That’s apparently a frequent request that user’s have. But if this is not immediate to implement, let’s not bother with it.
Yes, I think that is straightforwardly possible. I’ll give it a try when I get a chance.
Some pages using tikcd no longer render (e.g. tangent bundle category) on browsers that actively refuse the deprecated “xlink:href” SVG tag. Error in Chrome is:
error on line 1060 at column 61: Namespace prefix xlink for href on use is not defined
Would of course be great if tikzcd would interplay better with Instiki here, but for the moment one can work around this problem by aligning the tikzcd-delimiters to the absolute left.
I have now done this to make “tangent bundle category” display again (announced here).
Thanks!
On the page Grothendieck category, the reference Ab-enriched has not resolved, even though there is a redirect to Ab-enriched category. Perhaps this is because the redirect was added after the page Grothendieck category was last edited?
The logic of redirects and page rerenderings and cache invalidations has some bugs. If it occurs again, we can isolate an example.
One thing that Richard Williamson was planning on adding to the nLab before he resigned was a preview feature, so that editors could view how their changes to articles look like before publishing them. I think that would be a good feature to have, since it would reduce the amount of times editors have to re-edit the page to fix mistakes in their edits.
Just to highlight that:
re-edits within 30 min of the last edit are not recorded by the system as separate edits
for almost all practical purposes a de facto preview is available simply by copy-and-pasting the given source into the Sandbox.
The logic of redirects and page rerenderings and cache invalidations has some bugs. If it occurs again, we can isolate an example.
I’m pretty sure that if you write a link to a page that doesn’t exist, and then create the page, the original page will continue to have a broken link until it is edited again. A similar thing happens with uploaded files.
Currently, the nLab does not have environments for axioms as indicated by the list here. I wonder if we could have environments for axioms, such as
\begin{axiom} The axiom of X states that A and B imply C \end{axiom}
I’m pretty sure that if you write a link to a page that doesn’t exist, and then create the page, the original page will continue to have a broken link until it is edited again. A similar thing happens with uploaded files.
I just tested this (with no redirects), and it seems to work. It’s probably broken when the original page refers to some page name and that page name is added or removed as a redirect at another page. Unfortunately, the redirect expiration logic is broken by design.
Thanks for the alert, I’ll bring this to the attention of the technical team.
But — while the renderer ought to handle these situations gracefully — such code is of course ill-formed also on a conceptual level and we should really fix it in the source wherever it occurs. Could you list examples of entries where this problem appears?
[edit: I now saw that you ran into this at “phase space” and I have accordingly fixed it there]
I’m not entirely sure I understand how an svg is generated from tikz on this website. However, is there a way to generate the svg using the same font as the rest of the nlab (for math, I believe it’s DejaVu Math Tex Gyre)? Or does the tikz-to-svg pipeline not allow to load arbitrary packages?
Yes, the tikzcd-environment here does not allow to load packages nor is it being maintained by anyone, unfortunately.