[bug #66675] [troff] valid .char definition starting with `\[u` provokes erroneous error

2025-03-16 Thread G. Branden Robinson
Follow-up Comment #12, bug #66675 (group groff): Hi Dave, A couple of updates. [comment #6 comment #6:] > The problem is worse than originally reported as well, and has nothing to do > with .char and its ilk. > This also used to work as expected. > +verbatim+ > $ echo 'Foo\[u202Z]bar' | groff -

[bug #66675] [troff] valid .char definition starting with `\[u` provokes erroneous error

2025-03-16 Thread G. Branden Robinson
Follow-up Comment #13, bug #66675 (group groff): Whoops, sorry, in the font description file, special character names generally don't have a leading backslash on them. That seems to be reserved for special cases (like `\-`, `\|`, and `\^`). __

[bug #66675] [troff] valid .char definition starting with `\[u` provokes erroneous error

2025-03-16 Thread G. Branden Robinson
Follow-up Comment #15, bug #66675 (group groff): [comment #12 comment #12:] > I'm not convinced of your reasoning here, in part because (as far as I > recall), I haven't touched the code that interprets the "charset" sections of > font description files. I did _touch_ it (and indeed forgot about

[bug #66675] [troff] valid .char definition starting with `\[u` provokes erroneous error

2025-03-16 Thread G. Branden Robinson
Update of bug #66675 (group groff): Severity: 5 - Blocker => 3 - Normal ___ Follow-up Comment #16: Hah! That GNU _troff_'s `char` request (and its relatives) reads its first argument in interpretation mode (aga

[bug #66675] [troff] valid .char definition starting with `\[u` provokes erroneous error

2025-03-16 Thread G. Branden Robinson
Update of bug #66675 (group groff): Status: Confirmed => In Progress ___ Follow-up Comment #14: The fix for the character resolution part is simple. $ git diff diff --git a/font/devps/TR b/font/devps/TR in

[bug #66675] [troff] valid .char definition starting with `\[u` provokes erroneous error

2025-03-16 Thread Dave
Follow-up Comment #17, bug #66675 (group groff): [comment #12 comment #12:] > the foregoing is not a valid test. > > GNU _troff_'s -a output does not resolve/interpret user-defined > characters, and that's not a new development. True, bug #55799 has been around a while. But one of us is misunde

[bug #66675] [troff] valid .char definition starting with `\[u` provokes erroneous error

2025-03-16 Thread Dave
Follow-up Comment #18, bug #66675 (group groff): [comment #17 comment #17:] > _I_ couldn't, when I renamed the u2026 in TR to u202Z. If _you_ can, > I would love to know how you did it. Never mind, I see now how you did it, in your comment #14 patch: you added a line below the u2026 line dittoin

[bug #66919] .hcode no longer accepts a special character as a first argument

2025-03-16 Thread Dave
URL: Summary: .hcode no longer accepts a special character as a first argument Group: GNU roff Submitter: barx Submitted: Sun 16 Mar 2025 09:59:17 AM CDT Category: Core

[bug #66040] [troff] no longer warns about unrecognized .hcode input

2025-03-16 Thread Dave
Follow-up Comment #21, bug #66040 (group groff): [comment #20 comment #20:] > So this confirms that the ".hcode \[~o] \[~o]" does nothing, and > also now fails to warn or error To clarify: the above snippet doesn't on its own demonstrate the lack of diagnostics, since the fgrep filters stderr in

[bug #55799] -a output does not heed .char definitions

2025-03-16 Thread G. Branden Robinson
Update of bug #55799 (group groff): Status:None => Confirmed ___ Follow-up Comment #2: Now that we've got Advancing Dumping Technologyâ„¢ in _groff_ Git's master branch, we can obtain some insight into w

[bug #55799] [troff] -a output does not heed .char definitions

2025-03-16 Thread G. Branden Robinson
Update of bug #55799 (group groff): Summary: -a output does not heed .char definitions => [troff] -a output does not heed .char definitions ___ Reply to this item at:

[bug #55799] [troff] -a output does not heed .char definitions

2025-03-16 Thread G. Branden Robinson
Follow-up Comment #4, bug #55799 (group groff): Oh, silly me, GNU _troff_ already had a function for this, `ascii_print_reverse_node_list()`. I'll simplify. ___ Reply to this item at: ___

[bug #55799] [troff] -a output does not heed .char definitions

2025-03-16 Thread G. Branden Robinson
Follow-up Comment #5, bug #55799 (group groff): Alternative fix. diff --git a/src/roff/troff/node.cpp b/src/roff/troff/node.cpp index e4fb3717b..4bc0bf751 100644 --- a/src/roff/troff/node.cpp +++ b/src/roff/troff/node.cpp @@ -4680,12 +4680,7 @@ void composite_node::asciify(macro *m) void comp