Update of bug#64484 (group groff):
Severity: 2 - Minor => 3 - Normal
Item Group: Incorrect behaviour => Feature change
Status: In Progress => Fixed
Open/Closed: Open => Closed
Planned Release: None => 1.24.0
_______________________________________________________
Follow-up Comment #8:
commit 974c063f0a9e1ef6c0d2cac4755a3b9d6e925b0d
Author: G. Branden Robinson <g.branden.robin...@gmail.com>
Date: Sat Jan 13 08:08:16 2024 -0600
[troff]: Unit-test device control spec chars.
* src/roff/groff/tests/device-control-special-character-handling.sh: Add
unit test for this feature. We want to be able to consistently pass
(some) special character escape sequences to device control commands,
and we want the `device` request and `\X` escape sequences to behave
consistently with each other.
* src/roff/groff/groff.am (groff_TESTS): Run test.
Test fails at this commit. See Savannah #64484.
commit 9dbf227a5b3870a19c1e6d90e5b619c4ae3e7f3e
Author: G. Branden Robinson <g.branden.robin...@gmail.com>
Date: Sat Jan 13 09:26:58 2024 -0600
[troff]: Fix Savannah #64484.
* src/roff/troff/input.cpp (encode_char_for_troff_output): Annotate the
function's purpose. Initially assume the character to be encoded as
valid. If the current token is a plain space, write a space (U+0020)
to the output. (This is necessary because the `device` request no
longer reads its arguments in copy mode; see below.) Move the `sc`
local variable to a higher scope. Update the new `is_char_valid`
Boolean instead of issuing an error diagnostic at each point of
validation failure. When done processing the character, test
`is_char_valid` and emit different diagnostics depending on whether
the input was a special character escape sequence we can't handle, or
something else. Emit a self-quoted escape character _as a backslash_,
not as the current *roff escape character.
(device_request): Rewrite to operate in interpretation mode, not copy
mode.
* doc/groff.texi (Postprocessor Access):
* man/groff.7.man (Request short reference):
* NEWS: Document it.
Fixes <https://savannah.gnu.org/bugs/?64484>.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64484>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
