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.
Leading on a bit from Eric's discussion on matters of style, here's a style question. Should we have a lab convention on fonts for categories, functors, and the like? I realise that it may not be possible to always adhere to such a convention, so more of a guideline than a strict rule.
My point is that good notation should aid the reader. Having preferred fonts for categories, functors, and so forth can make the relationships between different pages a little easier.
In one recent paper, I (and my coauthor) used for elements and morphisms, for objects, for categories, and for functors. Of course I'm not suggesting that this be the convention, just raising the question as to whether or not there should be one, then if that is agreed upon here's my initial suggestion.
(By the way, maths on this forum is contained in double dollars, even inline maths)
I tend to use for categories (or -categories or -categories) and for functors (that is, the same) if the article is primarily about categories and functors. That leaves lowercase and for objects and morphisms. But I'm more likely to use (even though that doesn't presently render properly, at least in Firefox) or (although that can cause font trouble for some people) if the article is primarily about other stuff and the categories come in later. In that case, I'm liable to use for sets or structured sets but for elements and for functions.
Also, I tend to enforce for the delooping of a group into a one-object groupoid but for the classifying space of that groupoid.
I forgot to mention that I pretty much never change a standard for a given page that is already established on that page.
This is an interesting idea. I always use conventions of this sort when writing math papers; I find it especially helpful to keep things straight in my head because I tend to write papers that involve a bunch of different types of categorical thing (e.g. category, 2-category, 3-category ,double category, indexed category can often all occur in the same paper, not to speak of functors). But I think at this point I'd rather not try to impose a style convention on the nLab, since it would raise the barrier to entry just a little bit higher. (Plus the odds of getting multiple people to agree on a single convention for the entire nLab seem to me rather slim!)
Here's one for the Lab Elves (typesetting division): now that I can have the error logs scrolling past my screen without worrying about it blocking anyone else's access, I can see all the complaints that the markdown (maruku) filter has about everyone's syntax. The most common offenders are square brackets. Since these are part of markdown's syntax, it tries to make them such. So when someone types
[43, p. 153]
then I see
___________________________________________________________________________
| Maruku tells you:
+---------------------------------------------------------------------------
| Could not find ref_id = "43_p_153" for md_link(["43, p. 153"],"43_p_153")
| Available refs are []
+---------------------------------------------------------------------------
\___________________________________________________________________________
Not creating a link for ref_id = "43_p_153".
So presumably these should be changed to \[
and \]
by some enterprising soul.
The good thing about that is that it simply renders this as if there were no brackets (albeit inside a <span>
or something that affects the CSS very slightly), which in most cases looks just fine.
I'm a little confused about what you are calling a 'good thing'. Either the brackets should be visible, in which case they should be escaped properly, or they shouldn't be there, in which case they shouldn't be there in the source code.
Maybe you mean that at least it doesn't break anything! In which case, I agree fully.
Oh, it's fun reading the error logs. It's amazing what people type ...
Maybe you mean that at least it doesn't break anything!
Yes. Even at the level of the casual reader, it usually doesn't break anything significantly.
Yeah, but the error messages are sufficiently irritating that I'm going to fix 'em when I get a minute.
More seriously, I'm monitoring the errors to see when we get a spike and it's hard to keep up when all these minor stuff goes by (there's an asterisk in the Sandbox that it doesn't like either).
1 to 9 of 9