bugGNU roff - Bugs: bug #67570, [PATCH] [troff] `cflags` request...

 
 

bug #67570: [PATCH] [troff] `cflags` request ignored when used on a class since commit 77d8f728d, 2025-09-04

Submitter:  Dave <barx>
Submitted:  Thu 02 Oct 2025 09:39:17 PM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.24.0
* Mandatory Fields

Post a Comment

Add a New Comment Rich Markup
   

Discussion

Jump to the original submission

Wed 03 Dec 2025 03:43:28 PM UTC, comment #22: 

Thanks!


comment #21:

> I inexplicably mistook a Boolean-valued return type for an
> `int`-valued one.


Irrelevant nit, but even if the type were an int, changing

  if (some_int)

to

  if (some_int >= 0)

would have changed the logic.

Dave <barx>
Group Member
Tue 02 Dec 2025 05:02:32 AM UTC, comment #21: 


commit cef376097c50115ccc59853680c16c886eed53b5
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Mon Dec 1 18:50:04 2025 -0600

    [groff]: Regression-test Savannah #67570.

    * src/roff/groff/tests/cflags-works-on-character-classes.sh: Do it.

    * src/roff/groff/groff.am (groff_TESTS): Run test.

    Test fails at this commit.

commit c545d5192dcf7beb643c8ce362fa3b17fcf1d033
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Mon Dec 1 17:44:45 2025 -0600

    [troff]: Fix Savannah #67570.

    * src/roff/troff/input.cpp (charinfo::get_flags): Fix inadvertent
      regression caused by fumbled refactoring, wherein I inexplicably
      mistook a Boolean-valued return type for an `int`-valued one.
      (`contains()` sounds Boolean to me now, in the cold light of day.)

    Fixes <https://savannah.gnu.org/bugs/?67570>.  Thanks to Dave Kemper for
    the report.  Problem introduced by me in commit 77d8f728d, 4 September.


G. Branden Robinson <gbranden>
Group administrator
Mon 01 Dec 2025 11:46:10 PM UTC, comment #20: 


comment #19:

> I confirm that the patch in comment #11 fixes the bug for me.


Thanks, Dave.  It'll be in my next push (probably sooner than later, 'cause my working copy is already 31 commits ahead of "origin").

G. Branden Robinson <gbranden>
Group administrator
Mon 01 Dec 2025 10:19:30 PM UTC, comment #19: 

I confirm that the patch in comment #11 fixes the bug for me.

Dave <barx>
Group Member
Mon 01 Dec 2025 05:47:19 PM UTC, comment #18: 

original submission:

> One curious twist: if we indicate the end of sentence to groff
> by using two spaces instead of the end of the line, the problem
> goes away.


I realized a while ago, but I see that I never posted, that this isn't a case of the problem going away, but only being obscured because by default, two word spaces have a horizontal width equal to a word space followed by an additional sentence space.  Add, for instance, an ".ss 12 6" to the top of alternate.roff to show that the problem is still there.

Dave <barx>
Group Member
Sun 16 Nov 2025 03:12:20 PM UTC, comment #17: 


comment #16:

> comment #14:
> > I posted an update to the wrong ticket yesterday.
>
> That would have fallen between comment #10 and comment #11 here (and made the chronology a lot clearer, making comment #13 unnecessary).
>
> I updated the Summary in comment #13, and comment #14 reverted it.  Branden, was this intentional, or the result of a stale browser tab?


Definitely a browser tab issue.  I'm only using the "since commit" notation in summaries for defects that *aren't* regressions relative to a released version of groff.

Fixed now.  I think.

G. Branden Robinson <gbranden>
Group administrator
Sun 16 Nov 2025 06:12:16 AM UTC, comment #16: 

comment #14:

> I posted an update to the wrong ticket yesterday.


That would have fallen between comment #10 and comment #11 here (and made the chronology a lot clearer, making comment #13 unnecessary).

I updated the Summary in comment #13, and comment #14 reverted it.  Branden, was this intentional, or the result of a stale browser tab?

Dave <barx>
Group Member
Sat 15 Nov 2025 09:34:33 AM UTC, comment #15: 

comment #14:

> Ingo will laugh at me, but it'll be worth it if I get a regression test out of this.


I got a regression test out of this.


$ cat src/roff/groff/tests/cflags-works-on-character-classes.sh
#!/bin/sh
#
# Copyright 2025 G. Branden Robinson
#
# This file is part of groff.
#
# groff is free software; you can redistribute it and/or modify it under
# the terms of the GNU General Public License as published by the Free
# Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# groff is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
# for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.

groff="${abs_top_builddir:-.}/test-groff"

# Regression-test Savannah #67570.  Thanks to Dave Kemper for the
# reproducer.

input='.
.ec @
.class [EOS] @[em]
.cflags 1 @C![EOS]!
1234567890123456
.br
I@[em]
fold.
.pl @n[nl]u
.'

output=$(printf "%s\n" "$input" | "$groff" -T ascii)
echo "$output" | grep -Fqx 'I--  fold.'

# vim:set autoindent expandtab shiftwidth=2 tabstop=2 textwidth=72:


G. Branden Robinson <gbranden>
Group administrator
Sat 15 Nov 2025 09:29:54 AM UTC, comment #14: 

I posted an update to the wrong ticket yesterday.  It went to bug #52433 when it should have gone here.  Here 'tis.




Bisecting the Japanese code points thing was not fruitful.

So I went back to what I could (and should) have done after comment #0, and bisected using your exhibit and a starting point of `pchar`'s birth in March, which was early enough.


    $ git bisect good
    77d8f728dba1c483b2fbbbe64017c0668c5b8450 is the first bad commit
    commit 77d8f728dba1c483b2fbbbe64017c0668c5b8450
    Author: G. Branden Robinson <g.branden.robinson@gmail.com>
    Date:   Thu Sep 4 01:39:31 2025 -0500

        [troff]: Trivially refactor.

        Rename `charinfo` class's member function `get_unicode_code()` to
        `get_unicode_mapping()`.

        * src/roff/troff/charinfo.h (class charinfo): Do it.

        * src/roff/troff/input.cpp (charinfo::get_unicode_code): Rename this...
          (charinfo::get_unicode_mapping): ...to this.

          (define_class, charinfo::get_flags): Update call sites.

     ChangeLog                 | 11 +++++++++++
     src/roff/troff/charinfo.h |  2 +-
     src/roff/troff/input.cpp  | 12 ++++++------
     3 files changed, 18 insertions(+), 7 deletions(-)


Another trivial refactoring bites me in the butt.

Ingo will laugh at me, but it'll be worth it if I get a regression test out of this.

G. Branden Robinson <gbranden>
Group administrator
Sat 15 Nov 2025 01:18:05 AM UTC, comment #13: 

comment #11:

> something not trivial slipped into that trivial refactoring.


"That trivial refactoring" seems to refer to commit 77d8f728d, for those trying to follow along at home.

Dave <barx>
Group Member
Sat 15 Nov 2025 12:17:45 AM UTC, comment #12: 

comment #9:

> applying character flags to a character class...uh...doesn't
> work, and I have to imagine that it either never did or has been
> broken for a long, long time.


It did work, in August and for many years previously... but also has failed for many years in some situations: bug #67571.

Dave <barx>
Group Member
Fri 14 Nov 2025 11:46:13 PM UTC, comment #11: 

Just as you'd figure, something not trivial slipped into that trivial refactoring.


@@ -10251,7 +10251,7 @@ void charinfo::get_flags()
   // troff's dictionary types use a pre-STL approach to containers.
   while (iter.get(&s, reinterpret_cast<void **>(&ci))) {
     assert(!s.is_null());
-    if (ci->contains(get_unicode_code())) {
+    if (ci->contains(get_unicode_mapping() >= 0)) {
 #if defined(DEBUGGING)
       if (want_html_debugging)
        fprintf(stderr, "charinfo::get_flags %p %s %d\n",


Going back to HEAD and patching...


$ git diff
diff --git a/src/roff/troff/input.cpp b/src/roff/troff/input.cpp
index 8f3e16d09..4cb8481d9 100644
--- a/src/roff/troff/input.cpp
+++ b/src/roff/troff/input.cpp
@@ -10611,7 +10611,7 @@ void charinfo::get_flags()
   // troff's dictionary types use a pre-STL approach to containers.
   while (iter.get(&s, reinterpret_cast<void **>(&ci))) {
     assert(!s.is_null());
-    if (ci->contains(get_unicode_mapping() >= 0)) {
+    if (ci->contains(get_unicode_mapping())) {
 #if defined(DEBUGGING)
       if (want_html_debugging)
        fprintf(stderr, "charinfo::get_flags %p %s %d\n",
$ ./build/test-groff -T utf8 ATTIC/67570-indirect.groff | od -c
special character '[EOS]'
  defined at: file name: "ATTIC/67570-indirect.groff", line number: 1
  contains ranges: U+2014
  contains nested classes: (none)
special character 'em'
  is not translated
  has a macro: "file name": "tty.tmac", "starting line number": 22, "length": 10, "contents": "\\[em]\\[em]", "node list": [ ]
  special translation: 0
  hyphenation code: 0
  flags: 5 (ends sentence, allows break after)
  asciify code: 0
  ASCII code: 0
  Unicode mapping: U+2014
  is found
  is transparently translatable
  is not translatable as input
  mode: normal
0000000   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5   6
0000020  \n   I 342 200 224 342 200 224           f   o   l   d   .  \n
0000040


Two spaces after the em dash as desired.

G. Branden Robinson <gbranden>
Group administrator
Fri 14 Nov 2025 11:23:50 PM UTC, comment #10: 

Weird.


$ git describe
1.23.0-2953-g40f7ca3da
$ ./build/test-groff -mja
japanese.tmac: warning: font TR may lack coverage of Japanese script
.pchar \C'[CJKnormal]'
special character "[CJKnormal]"
  is not translated
  does not have a macro
  special translation: 0
  hyphenation code: 0
  flags: 512
  ASCII code: 0
  asciify code: 0
  is found
  is transparently translatable
  is not translatable as input
  mode: normal
.pchar \[u3041]
special character "u3041"
  is not translated
  does not have a macro
  special translation: 0
  hyphenation code: 0
  flags: 0
  ASCII code: 0
  asciify code: 0
  is found
  is transparently translatable
  is not translatable as input
  mode: normal


But weird is good, because I see two things to dig into.

1.  Back in March, at the birth of `pchar`, the *correct* character flags were reported for the `[CJKnormal]` character class, even if that class was misidentified as a special character in debugging output.  That change can be bisected.

2.  The wrong character flags are reported for the U+3041 character itself.  Unclear if that's because it was already broken, or because the reporting was incorrect.

G. Branden Robinson <gbranden>
Group administrator
Fri 14 Nov 2025 11:18:06 PM UTC, comment #9: 

So...ah...it would appear that the GNU troff feature of applying character flags to a character class...uh...doesn't work, and I have to imagine that it either never did or has been broken for a long, long time.

Or maybe only two months (now three and a half?), given what you said.

> The below examples compare behavior of groff 1.23 and a current groff build.  The problem only came into groff in the last two months, but I no longer have that two-months-ago build for direct comparison.



$ ./build/test-groff -mja
/home/branden/src/GIT/groff/build/../tmac/ja.tmac: warning: font TR may lack coverage of Japanese script
.pchar \C'[CJKnormal]'
character class '[CJKnormal]'
  defined at: file name: "/home/branden/src/GIT/groff/build/../tmac/ja.tmac", line number: 44
  contains ranges: U+3041-U+3096 U+3096 U+30A0-U+30FF U+30FF U+4E00-U+9FFF U+9FFF
  contains nested classes: (none)
.pchar \[u3041]
special character 'u3041'
  is not translated
  does not have a macro
  special translation: 0
  hyphenation code: 0
  flags: 0 (none)
  asciify code: 0
  ASCII code: 0
  Unicode mapping: U+3041
  is found
  is transparently translatable
  is not translatable as input
  mode: normal
$ sed -n '44,+1p' tmac/ja.tmac
.class [CJKnormal] \
  \[u3041]-\[u3096] \[u30A0]-\[u30FF] \[u4E00]-\[u9FFF]


I'll go back to the dawn of the `pchar` feature and see if it exposes the problem.

G. Branden Robinson <gbranden>
Group administrator
Fri 14 Nov 2025 10:45:34 PM UTC, comment #8: 

Maybe I spoke to soon.  This *does* show different character flags for `\[em]`.  That is, in fact, illuminating.


  flags: 1 (ends sentence) [direct]
  flags: 4 (allows break after)


G. Branden Robinson <gbranden>
Group administrator
Fri 14 Nov 2025 10:42:49 PM UTC, comment #7: 

Unfortunately my new fancy introspection stuff doesn't seem to shed a lot of light on the original report.


$ cat ATTIC/67570-direct.groff
.cflags 1 \[em]
1234567890123456
.br
I\[em]
fold.
.pl \n[nl]u
.pchar \[em]
$ cat ATTIC/67570-indirect.groff
.class [EOS] \[em]
.cflags 1 \C'[EOS]'
1234567890123456
.br
I\[em]
fold.
.pl \n[nl]u
.pchar \C'[EOS]'
.pchar \[em]
$ ./build/test-groff -T utf8 ATTIC/67570-direct.groff | od -c
special character 'em'
  is not translated
  has a macro: "file name": "tty.tmac", "starting line number": 22, "length": 10, "contents": "\\[em]\\[em]", "node list": [ ]
  special translation: 0
  hyphenation code: 0
  flags: 1 (ends sentence)
  asciify code: 0
  ASCII code: 0
  Unicode mapping: U+2014
  is found
  is transparently translatable
  is not translatable as input
  mode: normal
0000000   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5   6
0000020  \n   I 342 200 224 342 200 224           f   o   l   d   .  \n
0000040
$ ./build/test-groff -T utf8 ATTIC/67570-indirect.groff | od -c
special character '[EOS]'
  defined at: file name: "ATTIC/67570-indirect.groff", line number: 1
  contains ranges: U+2014
  contains nested classes: (none)
special character 'em'
  is not translated
  has a macro: "file name": "tty.tmac", "starting line number": 22, "length": 10, "contents": "\\[em]\\[em]", "node list": [ ]
  special translation: 0
  hyphenation code: 0
  flags: 4 (allows break after)
  asciify code: 0
  ASCII code: 0
  Unicode mapping: U+2014
  is found
  is transparently translatable
  is not translatable as input
  mode: normal
0000000   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5   6
0000020  \n   I 342 200 224 342 200 224       f   o   l   d   .  \n
0000037


Hmmm.


G. Branden Robinson <gbranden>
Group administrator
Fri 14 Nov 2025 10:31:30 PM UTC, comment #6: 

Bug #67617 is resolved in my working copy.  Returning to the examples from comment #1 (with a syntax correction) and comment #3...


$ printf '.class [EOS] \\[em]\n.pchar \C"[EOS]"\n' | ./build/test-groff
character class '[EOS]'
  defined at: file name: "<standard input>", line number: 1
  contains ranges: U+2014
  contains nested classes: (none)
$ printf '.pchar \\C#[CJKprepunct]#\n' | ./build/test-groff -mja
/home/branden/src/GIT/groff/build/../tmac/ja.tmac: warning: font TR may lack coverage of Japanese script
character class '[CJKprepunct]'
  defined at: file name: "/home/branden/src/GIT/groff/build/../tmac/ja.tmac", line number: 32
  contains ranges: U+002C U+003A U+003B U+003E U+007D U+3001 U+3002 U+FF0C U+FF0E U+30FB U+FF1A U+FF1B U+FF1F U+FF01 U+FF09 U+3015 U+FF3D U+FF5D U+300D U+300F U+3011 U+3041 U+3043 U+3045 U+3047 U+3049 U+3063 U+3083 U+3085 U+3087 U+30FC U+30A1 U+30A3 U+30A5 U+30A7 U+30A9 U+30C3 U+30E3 U+30E5 U+30E7
  contains nested classes: (none)


Those both had only singleton ranges.  Here's one that uses real ranges.


$ printf '.pchar \\C#[CJKnormal]#\n' | ./build/test-groff -mja
/home/branden/src/GIT/groff/build/../tmac/ja.tmac: warning: font TR may lack coverage of Japanese script
character class '[CJKnormal]'
  defined at: file name: "/home/branden/src/GIT/groff/build/../tmac/ja.tmac", line number: 44
  contains ranges: U+3041-U+3096 U+3096 U+30A0-U+30FF U+30FF U+4E00-U+9FFF U+9FFF
  contains nested classes: (none)


G. Branden Robinson <gbranden>
Group administrator
Fri 14 Nov 2025 09:19:25 PM UTC, comment #5: 

Dave,

You might want to take a look at bug #67617.

G. Branden Robinson <gbranden>
Group administrator
Sat 04 Oct 2025 04:50:16 PM UTC, comment #4: 

comment #3:

> So we have an opportunity to help the user troubleshoot an issue where
> they accidently masked a special character name with a character class.


Good point.  I took the manual's advice as standard practice that everyone followed, but I forgot about those rebels who don't play by society's rules.

Dave <barx>
Group Member
Sat 04 Oct 2025 04:20:11 PM UTC, comment #3: 

At 2025-10-04T11:48:14-0400, Dave wrote:

> Follow-up Comment #2, bug #67570 (group groff):
>
> comment #1:
> > I notice I forgot something in the new `pchar` request:
> >
> > It should try to resolve the argument as a character class first.
>
> I don't see why.  The .class request doesn't define a character, so
> one wouldn't expect .pchar to analyze it as a character.


You might, because (special) characters and character class occupy a
shared name space.

So we have an opportunity to help the user troubleshoot an issue where
they accidently masked a special character name with a character class.

> And as the manual says, "Currently, only the 'cflags' request can
> handle references to character classes."  So even if .pchar did return
> something for it, the only data points it could return are the
> characters in the class and its set of flags, as that's the only data
> a character class can hold.


I was thinking of having `.pchar [class]` list the members of the class.

> This might be marginally useful, but it'd be a surprising use for
> .pchar rather than a separate request, say, .pclass (although the two
> sharing a namespace does muddy this some).


Your parenthetical is exactly my thought.

> > $ printf '.class [EOS] \\[em]\n.pchar [EOS]\n'
>
> Because the class name contains the ] character (as recommended in the
> manual to avoid namespace collisions), it has to be dereferenced with
> the \C escape, so the above .pchar syntax doesn't access the class
> anyway.


Yes, but if someone fails to follow this advice, they could step on a
special character name.

In any case, something has to be done:


$ printf '.pchar \\C#[CJKprepunct]#\n' | ./build/test-groff -mja
/home/branden/src/GIT/groff/build/../tmac/ja.tmac: warning: font TR may lack coverage of Japanese script
special character "[CJKprepunct]"
  is not translated
  does not have a macro
  special translation: 0
  hyphenation code: 0
  flags: 128 (prohibits break before)
  Unicode mapping: none (-1)
  ASCII code: 0
  ASCII code: 0
  asciify code: 0
  is found
  is transparently translatable
  is not translatable as input
  mode: normal


That's misleading.

G. Branden Robinson <gbranden>
Group administrator
Sat 04 Oct 2025 03:48:11 PM UTC, comment #2: 

comment #1:

> I notice I forgot something in the new `pchar` request:
>
> It should try to resolve the argument as a character class first.


I don't see why.  The .class request doesn't define a character, so one wouldn't expect .pchar to analyze it as a character.  And as the manual says, "Currently, only the 'cflags' request can handle references to character classes."  So even if .pchar did return something for it, the only data points it could return are the characters in the class and its set of flags, as that's the only data a character class can hold.

This might be marginally useful, but it'd be a surprising use for .pchar rather than a separate request, say, .pclass (although the two sharing a namespace does muddy this some).

> $ printf '.class [EOS] \\[em]\n.pchar [EOS]\n'


Because the class name contains the ] character (as recommended in the manual to avoid namespace collisions), it has to be dereferenced with the \C escape, so the above .pchar syntax doesn't access the class anyway.

Dave <barx>
Group Member
Thu 02 Oct 2025 09:49:21 PM UTC, comment #1: 

No idea how I managed to change this behavior; I'll have to bisect.

In the meantime I notice I forgot something in the new `pchar` request:

It should try to resolve the argument as a character class first.


$ printf '.class [EOS] \\[em]\n.pchar [EOS]\n' | ./build/test-groff
character '['
  is not translated
  does not have a macro
  special translation: 0
  hyphenation code: 0
  flags: 0 (none)
  Unicode mapping: U+005B
  ASCII code: 91
  ASCII code: 91
  asciify code: 0
  is found
  is transparently translatable
  is not translatable as input
  mode: normal
character 'E'
  is not translated
  does not have a macro
  special translation: 0
  hyphenation code: 101
  flags: 0 (none)
  Unicode mapping: U+0045
  ASCII code: 69
  ASCII code: 69
  asciify code: 0
  is found
  is transparently translatable
  is not translatable as input
  mode: normal
character 'O'
  is not translated
  does not have a macro
  special translation: 0
  hyphenation code: 111
  flags: 0 (none)
  Unicode mapping: U+004F
  ASCII code: 79
  ASCII code: 79
  asciify code: 0
  is found
  is transparently translatable
  is not translatable as input
  mode: normal
character 'S'
  is not translated
  does not have a macro
  special translation: 0
  hyphenation code: 115
  flags: 0 (none)
  Unicode mapping: U+0053
  ASCII code: 83
  ASCII code: 83
  asciify code: 0
  is found
  is transparently translatable
  is not translatable as input
  mode: normal
character ']'
  is not translated
  does not have a macro
  special translation: 0
  hyphenation code: 0
  flags: 32 (is transparent to end of sentence)
  Unicode mapping: U+005D
  ASCII code: 93
  ASCII code: 93
  asciify code: 0
  is found
  is transparently translatable
  is not translatable as input
  mode: normal


G. Branden Robinson <gbranden>
Group administrator
Thu 02 Oct 2025 09:39:17 PM UTC, original submission:  

The below examples compare behavior of groff 1.23 and a current groff build.  The problem only came into groff in the last two months, but I no longer have that two-months-ago build for direct comparison.

This exercise uses ".cflags 1" to make the em dash a sentence-ending character.  So when an em dash is last on a line, it should be treated as the end of a sentence.

First, let's set the cflag on the character directly.

$ cat direct.roff
.cflags 1 \[em]
I\[em]
fold.
$ groff-latest --version | head -1
GNU groff version 1.23.0.3991-48d2f-dirty
$ diff <(groff -Z direct.roff) <(groff-latest -Z direct.roff)
8,9d7
< V12000
< H72000
11a10,11
> V12000
> H72000

I don't know why those two lines moved a bit in grout, but no matter: this has no effect on the output.  Typeset results are identical in 1.23 and current groff.

Now let's put the em dash in a class, and set the cflag on that.

$ cat indirect.roff
.class [EOS] \[em]
.cflags 1 \C'[EOS]'
I\[em]
fold.
$ diff <(groff -Z indirect.roff) <(groff-latest -Z indirect.roff)
8,9d7
< V12000
< H72000
11a10,11
> V12000
> H72000
14c14
< wh15000
---
> wh12500

The horizontal movement has changed between groff 1.23 (in fact, groff of August 2025) and today.  The latest groff no longer adds the extra sentence space when the cflags value is applied to a class rather than to the character directly.

Looked at another way, the files direct.roff and indirect.roff should behave the same: they're defining the same sentence-ending character in different ways.  And they used to, but now do not:

$ diff <(groff -Z direct.roff) <(groff -Z indirect.roff)
$ diff <(groff-latest -Z direct.roff) <(groff-latest -Z indirect.roff)
14c14
< wh15000
---
> wh12500

One curious twist: if we indicate the end of sentence to groff by using two spaces instead of the end of the line, the problem goes away.

$ cat alternate.roff
.class [EOS] \[em]
.cflags 1 \C'[EOS]'
I\[em]  fold.
$ groff -Z alternate.roff | grep ^wh
wh15000
$ groff-latest -Z alternate.roff | grep ^wh
wh15000


Dave <barx>
Group Member

 

Attached Files

This item currently has no attached files.

(Note: upload size limit is set to 4.0MiB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

 

Dependencies

This item does not depend on any other items.

No items depend on this one.

 

Mail Notification Carbon-Copy List

Carbon-Copy List
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    Votes

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

    History

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-12-02 gbranden StatusIn Progress Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.24.0
    2025-12-01 barx Summary[troff] `cflags` request ignored when used on a class since commit 77d8f728d, 2025-09-04 [PATCH] [troff] `cflags` request ignored when used on a class since commit 77d8f728d, 2025-09-04
    2025-11-16 gbranden Summary[troff] `cflags` request ignored when used on a class [troff] `cflags` request ignored when used on a class since commit 77d8f728d, 2025-09-04
    2025-11-15 gbranden Summary[troff] `cflags` request ignored when used on a class since commit 77d8f728d, 2025-09-04 [troff] `cflags` request ignored when used on a class
    2025-11-15 barx Summary[troff] `cflags` request ignored when used on a class [troff] `cflags` request ignored when used on a class since commit 77d8f728d, 2025-09-04
    2025-11-14 gbranden StatusConfirmed In Progress
        Assigned toNone gbranden
    2025-11-14 gbranden Summary[troff] &quot;cflags 1&quot; sometimes ignored when used on a class [troff] `cflags` request ignored when used on a class
    2025-11-14 gbranden StatusNone Confirmed
    2025-10-20 gbranden Summary&quot;cflags 1&quot; sometimes ignored when used on a class [troff] "cflags 1" sometimes ignored when used on a class

    Back to the top

    Powered by Savane 3.16-a7ba.
    Corresponding source code