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/
