[bug #64439] .chop does not treat a .char definition atomically(?)

[G. Branden Robinson]

Update of bug #64439 (project groff):

                  Status:                    None => Need Info              
             Assigned to:                    None => barx                   
                 Summary: .chop does not treat a .char definition atomically
=> .chop does not treat a .char definition atomically(?)

    _______________________________________________________

Follow-up Comment #1:

Hmm, from what I understand of character definitions, this is working as
expected, and the defined-character object at the end of this string _is_
being treated atomically--as an indivisible unit.

Reviewing our Texinfo manual...


 -- Request: .char c [contents]
 -- Request: .fchar c [contents]
 -- Request: .fschar f c [contents]
 -- Request: .schar c [contents]
     Define a new character or glyph C to be CONTENTS, which can be
     empty.  More precisely, 'char' defines a 'groff' object (or
     redefines an existing one) that is accessed with the name C on
     input, and produces CONTENTS on output.  Every time glyph C needs
     to be printed, CONTENTS is processed in a temporary environment and
     the result is wrapped up into a single object.  Compatibility mode
     is turned off and the escape character is set to '\' while CONTENTS
     is processed.  Any emboldening, constant spacing, or track kerning
     is applied to this object rather than to individual glyphs in
     CONTENTS.

     An object defined by these requests can be used just like a normal
     glyph provided by the output device.  In particular, other
     characters can be translated to it with the 'tr' or 'trin'
     requests; it can be made the leader character with the 'lc'
     request; repeated patterns can be drawn with it using the '\l' and
     '\L' escape sequences; and words containing C can be hyphenated
     correctly if the 'hcode' request is used to give the object a
     hyphenation code.


...it seems clear to be that `chop` (and other string-processing operations)
should not be penetrating the boundary of the character definition, and
correctly treat it as a character/glyph.

What do you think?

(I continue to feel that the spurious diagnostic in #64101 is well observed,
and should be fixed.)


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64439>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/