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 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.
]]>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}
]]>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.
]]>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.
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.
]]>The logic of redirects and page rerenderings and cache invalidations has some bugs. If it occurs again, we can isolate an example.
]]>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?
]]>Thanks!
]]>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).
]]>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
Yes, I think that is straightforwardly possible. I’ll give it a try when I get a chance.
]]>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.
]]>’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
]]>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.
]]>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.
]]>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 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.
]]>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 highlight that the thread here titled “24” (going with the new entry 24) is strangely not displaying its contents.
It does show that there are two messages (one must be the message caused by the creation of the entry, the second is a comment by me that I just sent), but neither is visible.
]]>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
]]>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.
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.