@PauloCereda QUACK QUACK QUACK

Does anyone have experiences with github.com/latex-lsp/tree-sitter-latex?

@DavidCarlisle oh no

Happy birthday Brian Blessed!

@Skillmon I think I looked at the site after some update announcement a while back but never tried anything

@UlrikeFischer As soon as the l3doc changes are available on main, I'll be changing the setup for siunitx :)

I am making a CV layout with information in the left margin. Using a shipout/background hook, I am colouring the left margin blue by \puting a \rule in the margins. Then I am inserting tcolorboxes in the margins with information. But at certain zoom levels in my PDF viewer, this tcolorbox potrudes the \rule

Like this

I could ask a detailed question in here, but the question is, is this avoidable at all?

@Gaussler yes, use another PDF viewer :P

@Skillmon Great idea. But here’s the thing: I don’t decide which PDF viewer the people reading my CV are using

@Gaussler But why tcolorbox? The things you put there look like a simple rectangular box. That's easily possible with a \colorbox.

True, tcolorbox just provided some useful options that I liked to use

such as only putting the colours behind the headings

@Gaussler do you expect them to zoom around until they see every little fault that your PDF might have?

@Skillmon Yeah, some nervous part of me kinda does ;-)

@Gaussler understandable for an application (though unlikely)

@Skillmon But I could try removing tcolorbox from my solution and making my own environment

@Gaussler well, you can't be certain that tcolorbox is at fault, might as well happen with a \colorbox.

@Gaussler easiest solution: Make it a deliberate design decision. Instead of trying to align the boxes make the content boxes stick out by a small amount on purpose (might look terrible, hard to say with only a fraction of a screenshot)

@JosephWright hm. Did you test it? I mean even if I handle l3doc as soon as you load other incompatible packages it breaks.

@Gaussler well at the end tcolorbox does nothing move than to draw a rule, if that does not happens if you draw a similar rule directly I would assume that you have a rounding error somewhere.

@UlrikeFischer looks like a rather big error for a rounding error of TeX

@UlrikeFischer Actually, no, because I used a style that relied on TikZ to draw the background box. But now I switched to the standard engine, and now it seems to work

@Skillmon Well rounding error was perhaps the wrong word. But I once had a picky customer who looked at every pixel and learned a lot about tcolorbox calculations and drawing. You really need to look at the pgf line width etc and consider if it is inside or outside etc.

@UlrikeFischer ahh, that makes sense :) (and I also was already working on 3000% magnification pixel-precision, picky people are picky)

@UlrikeFischer Yes :) If I make one change to the siunitx docs (a babel thing), I get compilation although I need to fix the font setup

Actually, it didn’t quite work with standard either. But then I just added a \rule using a \node in TikZ, and now the problem seems completely gone

So TikZ was to blame

@JosephWright wow. That sounds good. I plan to add that as a style to latex-lab as in the test files. Then one can add them one by one to the documentation. But one could also and interface to load it with the testphase key?

@JosephWright which changes? I don't see any PR. Or is it just a branch currently?

@Skillmon It's just gone out in dev, so I have to wait around two weeks before a release on main :)

@JosephWright ? changes to l3doc in dev? Or do you mean tagging code supporting l3doc?

@Skillmon Not yet - just TU support

@Skillmon github.com/latex3/latex3/commit/…

@JosephWright doesn't work in pdfTeX :P

@JosephWright oh you didn't mean the tagging support?

@UlrikeFischer Er, no - that's not yet in l3doc

@JosephWright that change log entry looks wrong. The line mentioning TU-encoding should also specify it's about l3doc not about the entirety of l3kernel.

@JosephWright I thought you had tested that ;-)

@UlrikeFischer Er, yes - the changes in l3doc for TU, i.e. the stuff that went to CTAN yesterday :)

@JosephWright but if it's changes to l3doc directly there shouldn't be a dev-difference. l3doc is a package not part of the format.

@Skillmon l3doc lives in l3kernel so it' the same as any other change there - plus there were some other things

@Skillmon Change-of-policy about l3kernel releases following the business with implementation detail of prop being relied on in various places

How does TeX Live manage the different versions of the packages? Different ls-R files depending on -dev?

@Skillmon latex-dev searches the dev tree before the normal tree, so you get a dev release file by preference

Luckily @wipet stole me a tick, or else I would've missed it.

@PauloCereda tex.stackexchange.com/questions/728332/…

@DavidCarlisle I really do not know what to say ...

@cfr :-)

@DavidCarlisle ooh go for it <3

@PauloCereda how about "you could use this under cygwin but it will run your cpu at 100% forever and warm your house" ?

Anyone around acquainted with footmisc? How relevant/popular is the multiple option of the package? The manual says that using the option "does not fully work" with hyperref, testing here it does not appear to work at all. Is this a fundamental problem with the way the option is implemented (using \lastkern), or just that "support has not been added yet"?

@DavidCarlisle ooh

@gusbrs did you try with the tagging code? (it reimplements parts of footmisc)

@UlrikeFischer I've seen that it does so, but I haven't tried it yet. Does it work?

@gusbrs I don't know. I hope you would test it ;-)

@UlrikeFischer I'm testing it now, and a simple document seems to work. :-)

@UlrikeFischer And do you have any idea of how popular/relevant this option is?

Btw, can I add a couple of technical questions? Is there anything special in the value of 3sp for \multiplefootnotemarker or is this just a value which "is highly unlikely to be found for any other reason"? Also, this seems to be a "shared feature", in that \multiplefootnotemarker and \multfootsep are shared macros at different places (at least memoir and KOMAScript). Is it fair game for another package to "join the pool"?

@gusbrs from the memoir side: is highly unlikely to be found for any other reason

@daleif That's what I had imagined. A clever mechanism, but it does give me the chills. ;-)

@gusbrs Frank made a list (in the latex-lab-footnote code) about the use of such kerns:

% 1 = CJK
% 2 = CJK
% 3 = multiple footnotes (footmisc, koma, eledmac, tufte, memoir,
%    parnotes, sidenotes)
% 3 = outer kern in letter spacing (letterspace)
% 3 = beginning of list (examdesign.cls)
% 4 = CJK pigin
% 5 = CJK ruby

% 1-4 = polyglossia for korean

@gusbrs which means that "3" for footnotes should be ok.

@UlrikeFischer Ah, it's official then. Hence special. Nice. But if I'm to use anything, I'd have to use the same value as footmisc,memoir and koma. So, it would be OK to provide \multiplefootnotemarker and \multfootsep as long as I use the same shared values for them?

@UlrikeFischer Btw, I see that you set the tagging code for latex-lab-footmisc directly in \multfootsep. Assume someone else provides the same feature and wants to implement tagging. Doesn't it then make tagging on their side depend on the presence of footmisc`?

@daleif As a matter of fact, I'm considering an alternative. This is for postnotes, and \postnote takes a key-val optional argument. So I could do something like \postnote{Foo.}\postnote[premark=,]{Bar.}. A little more manual work, but does not seem like a bad markup for what is an atypical case. And I could even handle ranges.

@daleif I'm still thinking, and whether I'd like for this to work with \footnote too, in which case, I can only use the same mechanism.

@gusbrs yes, currently there is a dependency (and probably it doesn't work in combination with memoir or if some other package define \multfootsep first). But if you look a bit into the docu and what Frank has written there, you can see that this is hard stuff with lots of history. It will take time to sort that out.

@UlrikeFischer I see, so my reasoning was not off course. But I understand, and will take a look at the comments/docu.

@UlrikeFischer @daleif Thank you!

@JosephWright right now I thoroughly miss a \keyval_map_inline:nnn function.

@Skillmon possibly ctan has some alternatiive kv packages with such a feature? :-)

@DavidCarlisle none that I'm aware of.

(abstraction level wise this would be expkv, but every key=value loop provided by it is expandable... I could certainly add it, but it doesn't fit the package, whereas it'd fit into expl3)

@Skillmon oh I read your comment as "my package is better than yours" you mean that you actually meant what you wrote?

@DavidCarlisle yes :)

@Skillmon shocking

@DavidCarlisle when would I ever write an honest "my package is better than yours" (except when comparing to the buggy keyval-package :P)

I don't consider expkv to be better than l3keys, just different, better in some aspects worse in others.

@Skillmon PR?

@JosephWright maybe :) But not today

actually, maybe later today, who knows :)

@Skillmon :)

@JosephWright it should actually be pretty straight forward and not even need a global list of restores

@JosephWright 9 sloc

A bit more if I also add \keyval_map_break:n?

Back to night job for the time being :P

@Skillmon :)

Ok, wife came over, night job is over for today :) But she's gone again for a few minutes... Maybe I can squeeze a PR into my schedule :D

@UlrikeFischer May I ask a code question about latex-lab-footmisc? When implementing the multiple option, Frank comments before saving the spacefactor: "?? is that necessary or even correct ??". I think I understand why, and agree. Right before that \@footnotemarkhas already stored the spacefactor in the same \@x@sf variable. Now, if there were no reason to assume the spacefactor has changed in between these two moments, saving it again is unnecessary. [...]

[...] But, if there is indeed a possibility that the spacefactor has changed, then when it is restored at the end of \@footnotemark it may have the wrong value. Is this correct?

@JosephWright drafted a PR (unit tests are still missing)