@Rmano I meant during usage. In the actual TeX file.
I don't know about documentation. I suppose one might group options by topic in documentation, for example. But for actual usage it might make sense to order them alphabetically. I use a template, so I would change it there.
@FaheemMitha I suppose it's a matter of taste. The biggest list I have (I hate too many package options; I think the correct interface is to have a \packageoption{} for anything that can be postponed) is this:
@FaheemMitha no, sorry, I've been cryptic. I mean that any package should have a command to set option after the loading, I find that much more usable (and avoid the dreaded "option clash" when requiring a package). Like for example siunitx that has \sisetup{}.
@FaheemMitha Yes. There are things that are only selectable at package load time (for example, in circuitikz, enabling the alternate syntax for units) but I think that a lot of things should be postponed if possible. My package is guilty of this too, there are things like voltage-direction and betterproportions that should not be package options, but settable after loading (and better if locally) with ctikzset.
Yes. For example: suppose you use a package that do, internally, \RequirePackage[svgnames]{xcolor}. Now if in your file you use \usepackage[x11names]{xcolor} you will have an error Option clash for package xcolor. That would not happen if you could load xcolor without options and then use some kind of \xcolorsetup{x11colors} or something like that.
Said that, there are things that must be options, no doubt about it.
I try to "\RequirePackage" strictly with no options whenever I can, to avoid that... (and yes, I know that often you can solve it with \PassOtionsToPackage early on, but still. I love \sisetup and \hypersetup for that)
@FaheemMitha grouping them semantically makes more sense to me, alphabetic seems completely arbitrary what advantage would that be over random order (which is what I actually use)
@samcarter_says_quack Leute, die nicht auf Englisch schreiben, verdienen kein Mitgefühl,
@samcarter_says_quack youtube.com/watch?v=Ck57sOYq7YI I like how they avoid using specific names: Christmas eve is Toy day and Carnaval is Festivale. :)
@FaheemMitha some classes use \ProcesOptions or \ProcessOptions* in the first case the order in the document is irrelevant so why give yourself a rule it has to be in a specific order. In the second case the order is relevant so you cannot add sone arbitrary constraint like putting them in alphabetic order without changing the resulting document.
@DavidCarlisle OK. I just thought it would make it easier to find whether a given option was present or not, if they were in alphabetical order. But I suppose that's not much of a reason.
@PauloCereda I think the Christmas thing is not to upset non Christian (Muslim, for instance) customers. The same as using "gosh" in TV series. But the Carnaval thing... why?
Just curious, does anybody know how to hyphenate numbers in TeX as if they were letters? I'm doing it inserting discretionaries with a loop in Lua, but I feel there's a better, "only TeX", way
@JairoA.delRio for specific strings there plenty of macros around that allow breaking anywhere (I think xstring has one or xurl or answers on this site, if you mean any runs of digits in free text without having \zzz{123} that's a bit harder (you could do it with \patterns but that requires a new format oh unless you restrict to luatex..
@JairoA.delRio hmm I'm not sure even luatex likes patterns for digits. Anyone else know a trick to make \patterns{999} specify a level 9 hyphenation point between two 9's ?
@DavidCarlisle I felt compelled to answer a question using \caption{Blub}\label{tab:Blub} in the example, and it reminded me that tabularx is lacking an interface to exclude something from the trial run ...
@UlrikeFischer the real documentation is tabularx.sty so much easier to read than tabularx.dtx with all those weird % \begin{macrocode} lines disturbing the reading flow.
@UlrikeFischer @JosephWright With the pdfbase equivalents I get different y coordinates. But they seem right as they coincide with those of the rectangle (re) produced from \rule. Is 200bp the depth, in your case?
@AlexG I guess at some stage I'll also tackle patterns and whatnot in dvips for l3draw - lots of PostScript to write (inspired by the colorspace stuff I've managed to do)
@AlexG Cool: hopefully l3pdf will end up providing good interfaces all round (@UlrikeFischer is dealing mainly with interfaces, I just do backend stuff)
Somehow I get the feeling I'm now the PostScript expert on the team ... how did that happen?
@JosephWright I'm not sure. I had a test file with destination options and everything moved down by around 10 points. It still works in master. I need to check this.
@JosephWright I found it. You boxed also the \pdf_destination:nn and this is not good. It changes the spacing all over the place. E.g. here for a section:
133.768 657.235 Td original
133.768 657.235 Td l3pdf no box
133.768 612.334 Td l3pdf boxed
And yes, if someone uses a FitR there it will change spacing too, but one can document it.