[Dev-luatex] [PATCH] Allow literal # in argument text by escaping

Marcel Fabian Krüger tex at 2krueger.de
Mon May 27 18:49:15 CEST 2019

On Mon, May 27, 2019 at 06:19:23PM +0200, Hans Hagen wrote:
> On 5/27/2019 5:52 PM, Marcel Fabian Krüger wrote:
> > Anyway I do not understand what you say with your last statement. How would
> > they help solving the original problem of `#` delimiters? As far as I
> > can tell they are rewritten into "normal" positional arguments, so I do
> > not see how they could help.
> It's indeed unrelated so of no help and anyway something context specific
> that is nto used that often (performance wise, it started out as an
> experiment as usual).
Just out of curiosity I would still love to see where it is implemented.

> [...]
> fwiw: I have considered extending the macro handler, e.g. with more than 9
> arguments which is not that hard but it makes not much sense. Macro packages
> have to deal with other engines too.
> note: As one of the complaints about luatex is that we kept adding stuff
> which is then voiced as equivalent for it being not stable which in turn
> becomes kind of boring / annoying to endure, at some point one has to decide
> to freeze functionality. So don't expect much additions. I'm considering a
> few low level optimizations and non intrusive thingies as side effect of
> some experiments but that will be a once-in-a-while adventure in sync with
> version bumps in the first digit (like 1.20, 1.30  and so).

Ok, I understand that. Then there is probably very little hope for this
either, but I will just mention it anyway: Would it maybe be a option to
provide access to the token list of macros instead? Meaning some variant
of `get_macro/set_macro` which allows setting/getting the token list as
returned by token.scan_toks(true, -)? This wouldn't affect any old code
and not have any speciall effect for the TeX side, but would make
working with macros from Lua much easier, especially if they contain too
inconsistant (or unknown) catcodes to make going through a string
representation a viable option. It would e.g. allow doing this `#` stuff
through Lua, atomic replacements in existing macros and creating macros
with more "creative" catcodes from Lua code without requiring having to
go through odd `\def` constructions. Giving that the internal argument
list representation is exposed through scan_toks anyway, it looks like a
quite small and consistant change.

Best regards,

More information about the dev-luatex mailing list