@DavidCarlisle In xml-entities/unicode.xml there are duplicate entries for limsup and sup where one of them has a missing 0 in the id field. Is this just a bug or some backward compatibility peculiarity? Example for limsup:

  <character id="U0006C-00069-0006D-00073-00075-0007" dec="108-105-109-115-117-112">
     <description>MULTIPLE CHARACTER OPERATOR: limsup</description>
  </character>
  <character id="U0006C-00069-0006D-00073-00075-00070" dec="108-105-109-115-117-112">
     <description>MULTIPLE CHARACTER OPERATOR: limsup</description>
  </character>

@MarcelKrüger Sigh, the first one is nonsense I'll delete. thanks. In general in mathml 3 and 4 we've been trying to downplay the multi-character entrues as the recommended markup is <mi>limsup</mi><mo>&ApplyFunction;</mo>.. not <mo>limsup</mo>... so theer should not be an operator dictionary entry for limsup anyway but certainly not one ending in U+0007 :-)

$ git commit -a -m "delete spurious duplicate limsup entry"
[gh-pages cf9da33] delete spurious duplicate limsup entry
 1 file changed, 3 deletions(-)

@MarcelKrüger ^

@MarcelKrüger sorry as you said, sup as well as limsup, another commit coming up

@DavidCarlisle Thanks, you got a PR for a third one.

@MarcelKrüger I wonder how they got there. sometime in the last 30 years I probably had a perl script with a bad regex:-)

@DavidCarlisle Nobody is using xml anyways, so... :P

So one cannot do \NewDocumentCommand\foo{ s O{} m e{^_} }{ #3 } inside a \ExplSyntaxOn .. \ExplSyntaxOff pair? It eats the ^ value, but not the _

Documented somewhere?

@daleif Probably not formally, but catcodes issues are so many that you can't document them all...

(probably needs something like :No variant of \NewDocumentCommand

@yo' I'd say this one is rather nasty, as the e{^_} is very useful. I'm doing some experiments on how to make an ultimate \DeclarePairedDelimiter, I'd for example like to have \normii{X}_b automatically so \lVert x \rVert_{2;b}. basically means that the Macro has to be defined outside of expl3 and that cannot be right.

Something along these lines?

@yo' wait a minute there are str's for these, perhaps they work out of the box?

That DOES work

Again ought to be mentioned somewhere.

@daleif There are string and tl constants for several of these... But you also have something like \make_me_a_char_with_given_catcode:Nn

@daleif my hack, or using the string constants?

\NewDocumentCommand\fooE{ s O{} m e{\c_underscore_str \c_circumflex_str} } {...}

@daleif cool :)

Lol, no it does not, just confused. It ain't eating anything

I would not have expected that _ was ignored in that case. I would have assumed that e some how "normalised" the input regarding cat codes.

BTW: anyone have any example of defining macros using key-val setups such that the resulting macros is are nestable. I fear that one can easilly end up in a situation where the options for the outer macro affect the options for the inner ones. (as a mental picture, imagine \DeclarePairedDelimiter, but using key-val lists to set up the macro, and support for various key-val options instead of just \big etc as opt arg). For now this is just a toy, and it is not planned to be backwards compatible.

@yo' Of course egreg had already answered it tex.stackexchange.com/a/548016/3929, \exp_args:Nne\NewDocumentCommand\fooE{ s O{} m e{\char_generate:nn {_}{8} ^} }` is a working one

@daleif expkv-cs.

@daleif well _ is a letter, I wonder if we could make that work directly, as the argument of e is rather constrained it might be possible to interpret _ as _ without too much overhead.

@Skillmon noted thanks. I was thinking about supporting making variants. Fx when the (annoying) users comes along who want \norm to auto scale by default, then that would be easy as \DeclarePairedVariant\norm\normalnorm{ scala = * }, meaning \norm is the same as \normalnorm[scale=*,<other usage iptions>]

@DavidCarlisle That or at least make sure it is documented, perhaps with @egregs solution in tex.stackexchange.com/a/548016/3929. It is a bit depressing when one make made some super duper expl3 code, and then one cannot do what one wanted, and the manual does not explain why (well, we know why but that is not the point).

@Skillmon unreliable contrib package from dodgy source people should keep to the one true version

@DavidCarlisle buggy package that's only historic ballast?

@daleif Well, expkv-cs is highly limited in what it can achieve as it works solely by expansion (which is also why a nested macro can't be affected by the parent).

@DavidCarlisle Probably

@DavidCarlisle \sb doesn't work as well... Code is too brilliant for the simple mind to trick.

Just use \exp_args:NNe and \char_generate:nn.

@Skillmon yes that's what egreg suggests in the answer @daleif linked to, although looks a bit nicer if you just use \sub defined as \def\sub{_} outside expl syntax, rather than char_generate.

@Skillmon I'm only going to use core code, just wanted suggestions one how one could make nestable macros bases on key-val input. I think an idea would to precompile the relevant key val list at def time, start the macro by "clearing" relevant macros, run the precompiled list, run the user usage options, run the code.

@daleif step "clearing" and "run the precompiled list" are the same... :)

But yes, that's basically the gist of it. We have answers doing just that on the network because we needed a key=value macro without groups for instance.

@Skillmon the precompile also brings along keys not set?

@daleif no, you'd precompile them containing their initial values. Basically, I'd do something like \keys_define:nn { myset } { foo .tl_set:N = \l_my_foo_tl, bar .code:n = whatever } and then \keys_precompile:nnN {myset } { foo = {}, bar = baz } \l__my_initial_keyvalues_tl \l__my_initial_keyvalues and wouldn't have any .initial:n inside the \keys_define:nn.

@PauloCereda fosstodon.org/@[email protected]/112983982296775397

@samcarter ooh