[NTG-context] another error message in LMTX

Hans Hagen j.hagen at xs4all.nl
Sat Nov 7 13:29:32 CET 2020

On 11/7/2020 12:41 PM, Pablo Rodriguez wrote:
> Hans,
> using latest from yesterday, I get the following error:
>   tex error       > tex error on line 22 in file cont-yes.mkiv: Valid
>   keyword expected, likely 'minus'
>   <lua output> mt
>       xrunjit
>   <to be read again>
>       \relax
>   <macro> \buff_verbatim_type_buffer_indeed ...rrentregime
>   }tab{\typingparameter \c!tab }method{\p_buff_option
>   }escape{\typingparameter \c!escape }nature{display}\relax
>       \dostoptagged \endofverbatimlines \dostoptagged \stoppacked
>       \typingparameter \c!after
>   [...]
>   You started a keyword but it seems to be an invalid one. The first
>   character(s) might give you a clue. You might want to quit unwanted
>   lookahead with \relax.
> This comes from a book with > 300pp. It compiles perfectly fine with
> MkIV, so the typo might be in LMTX itself.
> I wonder whether it would be possible to add the invalid keyword (and
> related command) to the error message. This would mean something like:
>   tex error       > tex error on line 22 in file cont-yes.mkiv: Valid
>   keyword expected, got "invalid one" (related to "command").
> This would help a lot to figure out where to start searching for clues
> for a MWE.
well, the clue is there: you have

you have a \hskip or \vskip someplace that is not properly terminated by 
\relax so tex keeps scanning for optional plus|minus keywords and in 
your case runs into "mtxrunjit"

in luametatex we have a slightly different keyword scanner

- in traditional tex it will just push back the 'non valid' keyword and 

- but that actually obscures a potentential error when the \hskip is 
burried deep: maybe you are typesetting "minus" as is and then it *is* a 
valid keyword and probably an error wil be that no valid dimension is seen

- so, you'rve just been lucky so far

so, this new keyword scanner is more picky in the sense that when it 
notices a potential keywors start it will complain earlier which might 
actually catch potential errors ealier (in this case all follow up words 
that start with a 'p' or 'm'

another change in scanning is that in many cases order no longer 
matters; for instance in scanning skips it's a 'plus' spec followed by a 
'minus' spec but in rules it can be mized 'width', 'height', 'depths'
  in any order and repetitive

in luametatex (unless there is good reason) the order doesn't matter, 
and often repetition is ok (so, multiple plus and minus in a skip and in 
any order where the last one counts)

this also permits for instance an order like:

     \hbox to 20pt xoffset  3cm{1\hss}
     \hbox to 20pt             {\hss2\hss}
     \hbox to 20pt xoffset -3cm{\hss3}

where previously the 'to' spec always came last and multiple 'to' are 
okay (offsets etc are a lmtx feature, and it means many more keywords 
have to be scanned, which was one reason for cooking up a better 
mechanism, even if right from the start that was already rather optimized).

now, in principle this brings the possibility to support partial 
keywords, so 'xo' 'xoff' etc (in fact i only need to change a few lines 
of code) which can be handy when for instance one passes many 
attributes) but first i want the main machinery to be stable

actually, this was already there for a while; the good news is that all 
this doesn't harm performance (we actually gain some here, not that it's 
normally noticeable)

so: more flexibility, better performance, earlier interception but of 
course the later might demand users to fix code (i actually had to fix 
context in one spot for this lookahead issue).

(I'll add \relaxes to the after handling but that just obscures the issue.)


                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl

More information about the ntg-context mailing list