On Fri, Jul 03, 2020 at 09:56:28PM +0200, Hans Hagen wrote:
On 7/3/2020 2:55 PM, Marcel Fabian Krüger wrote:
Hi,
I recently noticed some cases where luametatex behaved in unexpected ways:
- The "Extra \fi" error isn't triggered, instead an extra `\fi` freezes luametatex. (Can be reproduced by compiling a document which only consists of a single \fi)
i already fixed here (noticed it when documenting some conditionals)
Great.
- token.new can only create some `data` tokens, but it doesn't apply bound checking on it's arguments:
there is no checking yet, there is an upper limit of 0x1FFFFF, so i'll add a check for that
OK, that explains it. [...]
eventually i want all to have reasonable ranges in the token interface (not per se the same as in the engine itself but that's a black box anyway) which involves some offsetting .. i do that stepwise in order to keep a working engine (the token interface is not used in context that much)
Please let me know if there is anything I can do to help with that. Anyway, tehre is another thing I am wondering about: In the latest luametatex versions, error help strings do not seem to work like they used to. Especially after \errhelp{some help}\errmessage{error} or tex.error('fdfd', {'some help'}) in the 'handle_error_hook' callback, tex.gethelptext returns nil. gethelptext still works for errors triggered by TeX itself. One completely different question: When running luametatex (of course with appropriate format/lua init script options) but without a TeX file or command, luametatex does not expect interactive input but instead tries to read the input file 'luametatex.tex'. (Where luametatex does not seem to be hardcoded but derived from argv[0]) Is there a way to overwrite this default input file name? Marcel