@StefanKottwitz On the amount of 'diversion' from development that sorting the FAQ means: it's taken a couple of days to get things into reasonable shape Markdown-wise, but updates will be rolling (a few minutes a day for a month or two). I hope that's not unreasonable.
@StefanKottwitz BTW, if you know anything about Jekyll ...
@DavidCarlisle Cool: probably a lot of them need zapping entirely. You'll likely be best revising some of the pages entirely.
@DavidCarlisle Hmm: I guess we might need to put in escaped ones then. That sort of thing will need logging in the CONTRIBUTING or a style guide: for example that we do have and … ...
@JosephWright yes there were a couple of generic issues with ~ in url which I fixed globally but the rest need to be done on a case by case basis.
@JosephWright that or I thought I might experiment with an inline jekyll liquid template thing, i think you should be abe to have {{quote text=foo}} or some such (or {{ctan pkg=colortbl}} for a ctan package link, etc
@JosephWright I think I'd go with US English, documenting \color in UK english wasn't a great success
@JosephWright yes that was my logic for the color package as well, but saying \color{red} produces the colour red just confused everyone. So I think you might want to explictly allow the variant of english to match the command names when describing a package even if the overall site is using uk english
@egreg I was thinking a general 'Would you welcome some code comments, for example I see that ...'
@egreg, @DavidCarlisle See team mail
@DavidCarlisle I guess the question is how far we want to use 'pure' Markdown and how far to use Jekyll for such things. At least at a first blush, I'd rather keep the Markdown 'vanilla' and see what we really need additionally
@DavidCarlisle Looks like I can activate a plugin on GitHub pages for smart quotes
@JosephWright yes there are advantages to that too, for ctan links one problem with the old site was some of teh older ones went to the tex-archive/macros url of a specific mirror rather than ctan.org/pkg (that got normalised but quite a few of the broken ones are where the ctan package doesn't match the latex package name eg longtable is in tools) also you can force standardisation of http v https (which accounts for the redirects in the checklink report)
@JosephWright currently it's pure markdown but if you add the jekyll --- frontmatter for page theme or standardised header/footer it's less pure whatever you do. Anyway I forked it so that I have access to the jekyll settings and may experiment a bit before suggesting anything. We used this a bit on the openmath site
@JosephWright now as a one off cleanup, yes, but I was thinking it's easier to tell people use {{foo ctan whatever}} or {{foo stackexhchange whatever than tell them to use the proper canonical links to teh sites and how to mark them up
@DavidCarlisle True: it's not pure Markdown anyway (we might want the tables-of-variables business, as in the LaTeX site, to do breadcrumbs). What I meant though is that the more Jekyll one needs, the harder editing is. So on balance for something like CTAN links I'd favour just bulk editing using a script
@DavidCarlisle Could be, at least for CTAN
@DavidCarlisle Like I say, we need a balance: I can see it for those two types of link, but not for much else (at least initially)
@DavidCarlisle Are you going to check out how to set this up? I'll work on tidying up quotes ...
@DavidCarlisle I'll also shift colour to color: you are (sadly) right on balance
@JosephWright first plan is the broken ctan links there I plan to not classify it as a page edit just as a global fixup up (there are 90 broken http://ctan.org/pkg links) many of the other ones I will probably just list as priority pages to rewrite. The jekyll styling business I have set up a fork running gh pages under my account and may experiment a bit offline with that before coming back with any actual suggestions
@JosephWright which has markup testing ctan {%include ctanpkg.html pkg="tools" lnk="longtable" %} link. with an include that looks like <a style="color:pink" href="https://www.ctan.org/pkg/{{ include.pkg }}">{{ include.lnk }}</a>
@JosephWright yes I think can probably drop the .html and if there is only one param you can drop teh quotes so {% ctan pkg=colortbl %} would work (I think:-) anyway I'll do more testing later [longtable](http://www.ctan.org/pkg/tools) isn't a lot shorter:-)
@JosephWright certainly {% meta text=this is my note %} would work, whether you can do it without the text= attribute-like syntax I'm not sure without a plugin
@DavidCarlisle Excellent: I'm looking at the attribute business
@DavidCarlisle Probably we can move the 'last edited' stuff to a header containing variables, then use a custom footer to add it: we likely want that for breadcrumbs too
@CarLaTeX Please tell the Professor that his second column is brilliant! I had a lot of fun reading it and the comparison between tikz and morse code is a very good idea! (@PauloCereda will probably soon be contacted by Hollywood to turn the duck story into a motion picture :)
@JosephWright yes I got an alternative syntax for meta working via variables (not sure I like it any better) testing meta2 {{page.bmeta}}widget{{page.emeta}} style. (para 3 of the above link)
@JosephWright yes I think in full jekyll you could define something better but here I think it has to be page.something or site.something so doesn't really work. I think the first form isn't to bad the angle quotes are a bit small I used ‹ originally I use ⟨ and ⟩ but Jekyll helpfully expanded them the wrong way left/right switched, I suppose I could use the numeric version instead:-), probably don't want bold, I was just checking if style=... passed through or got filtered
@JosephWright -- actually, i've dragged back a copy of the page, and will try my hand at updating it. (of course, if i find it likely that i'll make horrible errors, i'll simply send comments in some other intelligible form.)
@JosephWright It's going to take a while working through the broken links then we can take a decision on using or not using templates. Currently I would lean towards using them as I think it's good to classify links, and that would make it easy to have different but consistent styling for links to other questions or ctan links or whatever, but only if the markup is sufficiently simple.
@DavidCarlisle Agreed: we want to balance 'simple' with 'manageable'
@DavidCarlisle I'm going to move the dates and IDs (and perhaps titles) to a table at the start of the Markdown (as in raw.githubusercontent.com/latex3/latex3.github.io/master/latex3/…): I think the 'last revised' stuff should be in a footer that we construct using Jekyll
@JosephWright Note the current links to questions only accidentally work [writing Plain TeX](./FAQ-plaintex.html) works as the system strips .html , but .htm would break, we could use {%include faq = "plaintex"%} and have the page title and correct link get generated. this would fit well with moving page titles into the frontmatter suggestion as you just wrote
@JosephWright yep, of course it's easy enough to delete .html from them all at the moment but for documenting what to do a constraining template might help (or might not:-)
@JosephWright no one understands the latex float algorithm (or that latex only floats things if you ask for that:-)
@JosephWright well I'm fixing up links on the main site master but experimenting with templates on a fork running in my account that I don't intend to use to Pr back which is why I don't mind putting junk template links into the startup page to see what they look like
@JosephWright can you compare tex-faq.github.io/FAQ-fontsize with tex.ac.uk/FAQ-fontsize.html it's lost the description list at the end. I could just add it back by hand, in this case but i wonder if we need to check lists generally.
@JosephWright oh Ok I only noticed as the final but it works happily in the absence of the scaled fonts) got appended to the previous paragraph, I'll just delete while fixing the links.
@Skillmon arguably the same reason that \endlasthead is not, or because it didn't occur to me that anyone would want it or ... I haven't the faintest idea, it was a long time ago:-)
Hi folks. I'm having an annoying Emacs display issue with LaTeX code. The good news is that it's reproducible. The bad news is that this is apparently "normal" behavior, if I understand correctly. In any case, I'm linking to the question here in case anyone can offer clarification.
I running Emacs 25 on Debian 9.0 stretch. The version is 25.1+1-4+deb9u1.
I have a local copy of AUCTeX installed via Melpa. The relevant line in M-x list-packages is:
auctex 11.88.3 installed Integrated environment for *TeX*
See the screenshot below. The text
\url\expa...
@FaheemMitha I would expect that most latex syntax highlighters will have \url{...} as the syntax for \url and not cope with \expandafter tricks. TeX syntax is wildly context sensitive and wil defeat almost all parsing mechanisms
In relation to my previous question in this link Change part with arabic number, I ask how to obtain, using the Legrand orange book source and his structure.tex file, an appendix (in italian language) that has the letters of the alphabet. The complete code is on my previous question here: Change ...
@FaheemMitha anything is fixable but it's certainly not unexpected. editor syntax highlighting can't use tex's parser as they need to work with half finished code, and you can't parse tex with regex or any standard parser, try looking at xii.tex for example.
@Sebastiano you should fix the question first so it's more clear, you say the full code is in your previous question, but that has no code at all, so i assume you mean Christian's answer, then it's not clear what you expect people to do with the fragments in the current question
@FaheemMitha that's a bit odd, but given that it's not odd that it can't color \expandafter correctly, i wouldn't worry about it too much
@FaheemMitha the trouble (I would guess) is that \url is a verb-like command and it is treating it as \url|{| in which the { is not a group opener. But I haven't traced what it's doing.
@DavidCarlisle and the answer is: of course not. The highlighting of VIM in case of the vim-latexsuite doesn't parse the whole TeX file including catcode changes.
@DavidCarlisle just imagine you'd do that for each and every language which features such an interactive syntax, parsing every single bit of code (including loaded packages and stuff) just to do the highlighting in the currently displayed lines correctly. The overhead would kill my CPU :)
@Skillmon yes, not to mention you wouldn't be able to edit at all if there were errors or loops in the code typing \def\foo{\foo} will take a long time if the editor had to execute that to colour the final }
@FaheemMitha probably a corollary to godel's incompleteness theorem: for every sufficiently complex highlighting system there is some example that will break it. ;-)
@DavidCarlisle haven't thought of loops. Makes the idea even greater. I should implement that so I can edit code on my universities cluster with style (sadly my programming skills might not suffice)!
Reminded me of my own acknowledgement in my bachelor's thesis containing the following sentence: Donald E. Knuth danke ich für die Entwicklung von \TeX, das den einheitlichen Satz dieser Arbeit für mich stark vereinfachte.
Translating to: "I thank Donald E. Knuth for the development of \TeX, that eases the coherent formatting of this thesis a lot."
@G.Bay with the over sized brackets diverting attention so much I'd not worry about the fine points of \frac or \sfrac etc, it is going to look weird whatever you do!
@G.Bay all these things are rather dependent on convention in the area, back last century when I was doing math for a living I'd not have used / for division as it would look like a coset construction
@DavidCarlisle That should be 0.5 or a half, not 1/2 :) I use it for programming, because so far I haven't found any convenient way to input a proper frac in any language...