@UlrikeFischer <3

Overleaf has an in-person meeting this week. I wouldn't ever have expected a speaker here to ask the question: "How many of you have pinapple on pizza?"

@PauloCereda ^^

I understand that key-value pairs as defined using \keys_define:nn are something very similar to property lists. Is this understanding right? Because, I found a striking difference: keys can have no value, but properties in prop lists need to have one. Example case: I want to store a token list to use with \keys_set:nn. If all keys have values, I can use a prop, but if one key has no value, I would need to store as tl. Is this intended?

@JasperHabicht your assessment is correct, props are not really key=value, and yes this difference is deliberate. Another difference is that prop is unordered, while key=value input might be ordered (for instance the transformations of graphicx can yield order-dependent results). There is a function to serialise prop back to key=value

@Skillmon So, it would be better to store such token lists as tl actually anyways? I just wondered because they are really quite similar

@JasperHabicht correct. Or clist.

@Skillmon clist uhm ... right, I haven't thought about that ... thanks!

@JasperHabicht you could also parse into prop (storing a novalue mark), and serialising back to token list. But beware that you might lose information this way.

@Skillmon Right, I actually don't want to make things too complicated. I just felt that using a simple tl would maybe not the right thing to store keys into. But considering that there is not dedicated data type, it might well be fine.

@JasperHabicht yes, as I said, either use tl or clist, depends on what you want to do with it. If you only store the data to forward it later on, then a tl is fine, if you need some mapping, I'd use a clist because I can then use \clist_step_.....

@Skillmon Consider also seq, depending on the situation it could make more sense.

@JasperHabicht Keys always have a value, it just might be 'empty'

@JosephWright Well, but a user input such as keyA=valueA, keyB will raise an error if fed to \prop_set_from_keyval:Nn for example, because the = is missing

@JosephWright Maybe I did not express it correctly =)

@JosephWright I don't agree with you.

@yo' only if you map really often against it...

@Skillmon I know - there are different ways of approaching this - I mean more that 'keys as set up by l3keys always have values: \keyval_parse: doesn't have that starting point

@JasperHabicht prop data are not 'user' level :)

@JosephWright it could be that data, originally entered by the user travels down and becomes such

@JasperHabicht Yeah, that shouldn't happen ... clist are a bit of an outlier, but otherwise I'd expect 'user level' parsing separate from data structure setiup

@JosephWright But think I get what you mean. The less flexible a data type is, the less likely it should be exposed to the user? So, prop and seq are examples for non-user types? They could store data, but it should be properly parsed ny the package or class.

@JasperHabicht Exactly

Or, more exactly: every user input should be parsed at least once to ensure the corrent data type (or not, then tl)

@DavidCarlisle Would tex.stackexchange.com/a/567081/36296 be a good use case for your new lsfiles superpower?

@samcarter yes I justsaw that (as it popped into my notifications thing this morning) an answer would look nicer once we release latex-dev and then you won't need any expl3 code just \QueryFiles{*.jpg}{\includegraphics{#1}}

@yo' what ask?, isn't "everyone" the known answer?

@DavidCarlisle Something to look forward to! Great!

@samcarter github.com/latex3/latex2e/blob/develop/required/tools/…

@DavidCarlisle Dev release?

@JosephWright aren't we planing a dev release once the current round of PRs land?

Interesting situation at the luatex list. "I won't change anything." "I won't change anything"...

@DavidCarlisle Is there a standard method for lines like this in normal tables?

As I've heard the Chinese say, "Do nothing, and nothing will be done."

@mickep German saying: Only those who do nothing can do nothing wrong.

@cis no, there are some answers on site making that sort of thing with unicode tree drawing characters and/or tikz but nothing really with standard table | and \cline don't really line up the way you'd want

@cis Die Deutschen, die kann.

@mickep people should look at log files, not the pdf, then they wouldn't need synctex

@DavidCarlisle Oh, indeed. Maybe they could just type the pdfs directly. Then they would not need luatex either. :)

@mickep oh, it is my bug report ....

@UlrikeFischer Now you can feel safe nothing will be done. :)

@cis for example:

@DavidCarlisle Aha, interesting.

@cis was the first hit from tex.stackexchange.com/search?q=box+drawing there may be others you can use as well

Is \seq_gput_right:Nx deprecated and \seq_gput_right:Ne to be used instead? I cannot find the former in the current interface3 doc.

@AlexG yes, we use e everywhere now.

@UlrikeFischer Ah, good to know. A lot to be changed in my pkgs, though.

@UlrikeFischer in the secret b.... project the pdf outline links are to the page not to the heading itself? (I think I confused myeslf)

@UlrikeFischer So, when will usage of \tl_set:Nx, for example, break a package?

@AlexG never. it's not deprecated as in "will be removed" just that if \expanded had been added two decades earlier most things x would have been e so we are using e to lead by example

@DavidCarlisle When was \expanded added?

@DavidCarlisle Phew, that's reassuring!

@UlrikeFischer If I were you I'd ask him to simply fix it in synctex.

@mickep it was added to an unreleased version of pdftex in the time of the dodos and in luatex since the start it got added to pdftex/ptex/xetex/... in er.. 2018 or so I'd have to check

@DavidCarlisle Oh, I'm happy with "around 2018", thanks.

@DavidCarlisle unreleased version, the curious duck would get into spin about such secrets...

@mickep It sounds more as if luatex uses the wrong command, but I don't think that I want to get involved ;-)

@UlrikeFischer I'm not sure about that...

@DavidCarlisle it looks like the heading (and the toc shows destinations with chapter.XX), but they look too low.

@JosephWright still incorrect, because an empty value is something else than picking up a default value, which you lose if you simply treat it like an empty value during sequencing a prop.

I've been gone for a while, and since I've come back, when I look at the review queues and want to come back to the main q/a page, the nice list of options (used to include "questions") isn't there any more. Was this announced, or did it just happen silently? (I think it was a bad decision. Not at all friendly.)

@barbarabeeton click on those three lines ^^^ Then there is "Questions".