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, Marcel