@DavidCarlisle @JosephWright happy new year!

Happy new year (GMT)

@DavidCarlisle it is already GMT+11 in australia

@UlrikeFischer they are even more wrong than you are in Germany:-)

@DavidCarlisle unfair advantage ;-)

Happy New Year everyone!

Since it's not yet midnight here, I can still wish everyone happy Hogmanay. (That's Scots for the last day of the year.) And in a few hours, happy New Year.

@DavidCarlisle @PauloCereda From Twitter ^^^

Is there a "better" solution (that does not require copy pasting LaTeX source)?

@user202729 no that's the right solution, even though @egreg posted it

Looking around it looks like that LaTeX stores the symbol font somewhere then set it up with \everymath

"even though"? You mean "even"

Anyway

@user202729 no I meant what I wrote:-)

No? "egreg posted it" should imply "that's the right solution", not contradict (you make it sound like egreg is usually wrong)

I mean surely it should be possible to get the raw font that corresponds to the current symbol, store it somewhere, then declaresymbolfont back after loading the package?

The LaTeX source code is "a little" (very) dense, I haven't been able to trace down where the font data is stored yet

@user202729 you could look at the code for bm which disasembles the NFSS table of math fonts to work out which font is being used for each \fam and install a bold version of the same. But it's a lot more work than copying the one \DeclareSymbolFont required to use one symbol from anoyther package

@user202729 That could be done if you just want the standard Computer Modern font, but before loading mtpro2, and with a very unclean methods.

Okay "NFSS table" is the term

"Very unclean"...

@user202729 well it's a term you won't find that term in the doc though as we tried (failed) to stop calling it N FSS in 1993 as it wasn't new by then and tex doesn't really have tables...

@user202729 you should look more at our interaction, try asking @egreg how he'd feel if he was pressed to comment on one of my answers that was correct....

Wait what?

I mean you probably want to say "because egreg posted it, it's the right solution"

instead of the current, which means "although egreg posted it; it's the right solution"

So tl;dr it's possible to parse the table, but the code would be more complex because there's no current package

Correct?

@user202729 No I meant to imply surprise at egreg posting a correct solution for once.

Okay :)

Anyway >.<

Okay I found more command documentation in fntguide (talk about hard to find documentation...)

Maybe have something easy to understand would help avoid roughly 100 question about "how do I load only symbol X from package Y". Not sure if it's supposed to be easy or not to figure out which piece of code does which

@user202729 I would not have said "because there's no current package" rather there isn't really any use. Even if you parsed the table what would you do, if you wanted to change the font used for a rght brace or a lambda or a forall or whichever the current question is, you still need to look what font the font package uses for that symbol and then declare just that font and define just that command. And with that you only need a couple of lines of code, so how could a package help?

especially for those non-programmers

Not for me though, I'm fine with understand (and copy paste code)

@user202729 a package could only help with the easy part (declaring the symbol) I don't see how you can help with the hard part, which is working out which parts of the existing package define the character that you want to use.

No I'm thinking that a package would allow a non-programmer to...

\CopySymbol{\oldforall}{\forall}
\usepackage{some font package}
\CopySymbol{\forall}{\oldforall}

Is it useful? I don't really know

@user202729 is it definable? you could use \NewCommandCopy but would get the wrong result? especially for delimiters which might use two fonts each in an encoding not used elsewhere, you need to know exactly how the some font package defines the symbol, you may need to declare encodings, load one or two fonts, then redeclare the definitions with the new font assignments. I don't think it is possible without code specific to the some font package

"Why do you ask me? I'm asking you"

Hm

@user202729 well as I said before I can't see how any command can be written to do this for a general font package

Well obviously if the package use some complex everymath mechanism to set the font it's not possible, but it seems to be possible for "common cases"?

I.e. with DeclareSymbolFont or similar. I should read on what the NFSS table is

@user202729 no everymath complications. every (classic tex) math font is in a unique encoding so if you know \forall is character 77 in font assigned to \fam 3 so in the general case you need to do a fair bit or work to recreate the command with a different font setup, although bm might help...

@user202729 also the ususal correct answer is "don't do that" a font should normally be seen as a work of art in its entirety and not just a sampler out of which to pick individual symbols.

Yes, and I'm okay with the default font already

@UlrikeFischer I assume this is self-inflicted damage by the OP, not a miktex issue? tex.stackexchange.com/a/628691/1090

@DavidCarlisle While this statement is generally true, you forget the very important use case of writing ransom letters :)

@DavidCarlisle I will check when I'm home again.

@UlrikeFischer I thought I once saw a git repo with the miktex package versions? but at the miktex site I can only see a file list for each package currently?

@UlrikeFischer thanks for confirming (I assumed that was the case, despite what the OP said:-)

@DavidCarlisle I never tried to find out where the packages are managed in the miktex source. If I want to check a version I look at the file or in the miktex console. Imho from the outside the best is miktex.org/packages.

@UlrikeFischer yes found that but miktex.org/packages/natbib is just a file list

@DavidCarlisle yes, old packages often miss version numbers and similar.

@samcarter TEH FUTURE twitter.com/Serendippo/status/1477255999320899589

For tex.stackexchange.com/questions/312063/… ... this is lstlistings' package bug right? ("too lazy to figure out where to report bugs")

@PauloCereda ohhh

@user202729 why bug report? That's just a normal several year old post.

That lstlistings cannot handle [] in caption properly.

Wait actually let me check documentation to see

As in "if it explicitly say []is not allowed it's not bug, but that would be very weird behavior

Okay checked documentation, doesn't seem to mention anything regarding that

@user202729 well er tex feature that probably exposes itself as a keyval feature, in a delimited argument that consists just of a single brace group the braces are silently dropped. @Skillmon would enjoy that report:-)

No it's not just that.

I tried wrapping in additional groups

You need at least 4 groups for it to work properly

So partially lstlistings fault too

For lstinputlisting I need 5 groups

@user202729 try one group that isn't the whole value

Of course that one work

But the problem is that the groups keeps getting dropped somewhere in the pipeline

Not just once

@user202729 yes well fixing that is hard and when I once put out a keyval package that tried to fix it I broke half of ctan so I backed it out.....

Huh (what? It break packages?)

@PauloCereda -- High technology! Shades of Rube Goldberg!

Talk about bugs being actually features...

@user202729 in particular I broke babel so that quite a few people at a disadvantage

Although for now I'm not entirely sure which package's fault is it

Source code is dense, especially TeX source

But it dropping 3 groups is quite bad. At least drop only 1 group

Hm, that would be unexpected as well.

@user202729 keyval can drop braces in some contexts, and probably listings can drop some more but I didn't check.

@user202729 it's only unexpected if you don't expect it. I'd expect that as the default tex behaviour unless the package goes to some lengths to avoid it.

I guess the optimal one is "keep the exact number of groups"

At least tell the user "write caption={{... content here...}\relax} if there's any []" in the documentation

Bug = cases where the code does something different from what the documentation suggests

@user202729 no that isn't what is needed you need to be able to specify a final value without braces, so it can be used in whatever context.

@user202729 well write the author. No one here can change the documentation.

Hm...

Feature or bug, if it makes whoever use the thing spend time debugging mysterious unexpected behavior it's a bad thing.

TeX makes it easy for package developers to do bad things, therefore it's bad.

I guess.

@user202729 if you say so.

Not to complain. There are thousands of packages already, it would take a lot of money/time to make something better.

The latter is a reference to \tl_sort:nN.

@DavidCarlisle Actually in this particular case maybe it isn't that hard. Just use [{...}] for optional argument everywhere.

@user202729 Well if you think you found a bug: open a sensible issue in the github.

"will figure out where the GitHub is later" (actually alright I know)

@user202729 That's normal. And even if it were a bug, the user probably does not care, they just need a working solution.

@user202729 sure but when I changed keyval internals not to drop braces it turned out there were millions of existing documents going \somebabelthing[foo={{bar}}] which worked but then suddenly the braces didn't get dropped and an extra group ended up in the value and everything broke. The hard part of making changes is not fixing a reported "bug" it's not breaking 40 years of legacy documents

@user202729 do yourself a favour, use the number of groups you validated as working (4 wasn't it?) and then load the xkeyval package and try again.

@user202729 No, that's not the optimal one! That's what ltxkeys does, but you can't input what you want this way! Try inputting a value without surrounding braces but with commas this way...

@DavidCarlisle if everyone would just use expkv from now on :) (not serious, that approach has limitations as well)