[luatex] groupcode in pre_linebreak_filter

[Christopher DeCoro]

It appears to be a bug.  I previously relied on the groupcode to indicate
whether a paragraph was in a footnote or other insert, and that
functionality suddenly stopped working.  Hopefully this can be corrected
soon (it may be in the most recent; I only have the older version from
TexLive).

On Fri, Apr 1, 2016 at 6:48 PM, Frank Mittelbach <
frank.mittelbach at latex-project.org> wrote:

> Am 01.04.16 um 18:26 schrieb Frank Mittelbach:
>
>  From the manual I understand that the groupcode argument in the
>> pre_linebreak_filter callback gives me the context where this paragraph
>> breaking happens (eg <empty> means main vertical list, vbox means ...)
>>
>> Unfortunately that doesn't seem to be true:
>>
>> \directlua{
>> require "ltluatex.lua"
>> function prelinebreak (head, groupcode)
>>   print()
>>   print("   groupcode in pre_linelinebreak_filter = " ..
>>             groupcode .. " on line " .. tex.inputlineno)
>>   return true
>> end
>> luatexbase.add_to_callback("pre_linebreak_filter", prelinebreak, "new
>> linebreak callback")
>> }
>>
>>
>> \input tufte
>>
>> \vbox{\input tufte }
>>
>> \vbox{\input tufte \par}                         % should report in
>> vmode but reports main vlist
>>
>> \vbox{\begingroup \input tufte \endgroup}
>>
>> \vbox{\begingroup \input tufte \par\endgroup}    % should report in
>> vmode but reports main vlist
>>
>> looks like the groupcode reported depends on whether it is an explicit
>> par or the implicit one from the box but not the actual context
>>
>> \bye
>>
>> is this a bug or do I miss something?
>>
>> The above means I can't really determine if a paragraph is in fact on
>> the main vertical list or hidden inside some box so that it is
>> unbreakable even if it eventually ends up (as a box) on the main
>> vertical list.
>>
>
> as a workaround, I guess I can additionally look at the semantic nest
> pointer and if that is == 1 then I really at at paragraph on the main
> vertical list and if > 1 then not. Is this the right workaround?
>
> frank
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/luatex/attachments/20160402/daf376fc/attachment.html>