* .Fn _* issue
@ 2010-09-25 6:35 Jason McIntyre
2010-09-25 15:23 ` Kristaps Dzonsons
2010-09-25 21:38 ` Ingo Schwarze
0 siblings, 2 replies; 10+ messages in thread
From: Jason McIntyre @ 2010-09-25 6:35 UTC (permalink / raw)
To: discuss
hi. the source, from cacheflush(3):
.Sh SYNOPSIS
.In machine/sysarch.h
.Ft int
.Fn cacheflush "void *addr" "int nbytes" "int cache"
.Ft int
.Fn _flush_cache "char *addr" "int nbytes" "int cache"
formats as:
SYNOPSIS
#include <machine/sysarch.h>
int
cacheflush(void *addr, int nbytes, int cache);
int
_flush_cache(char *addr, int nbytes, int cache);
so the issue is the initial `_' in _flush_cache. it's formatted in a
different font to the rest of the function name (you can see this best
on a terminal).
this is a long standing bug that we always had in old groff, which
really annoyed me. new groff fixed it.
jmc
--
To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: .Fn _* issue
2010-09-25 6:35 .Fn _* issue Jason McIntyre
@ 2010-09-25 15:23 ` Kristaps Dzonsons
2010-09-25 15:35 ` Jason McIntyre
2010-09-25 21:38 ` Ingo Schwarze
1 sibling, 1 reply; 10+ messages in thread
From: Kristaps Dzonsons @ 2010-09-25 15:23 UTC (permalink / raw)
To: discuss
> so the issue is the initial `_' in _flush_cache. it's formatted in a
> different font to the rest of the function name (you can see this best
> on a terminal).
>
> this is a long standing bug that we always had in old groff, which
> really annoyed me. new groff fixed it.
Jason, I'm not sure I follow as mandoc, new groff, and old groff all
seem to do the same thing with the _flush_cache beginning:
GNU nroff (groff) version 1.18.1
nroff -mandoc foo.1 | hexdump -c
_ \b _ f \b f l \b l u \b
mandoc foo.1 | hexdump -c
_ \b _ f \b f l \b l u \b
GNU troff version 1.15
nroff -mandoc foo.1 | hexdump -c
_ \b _ f \b f l \b l u \b
_\b_Kristaps
--
To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: .Fn _* issue
2010-09-25 15:23 ` Kristaps Dzonsons
@ 2010-09-25 15:35 ` Jason McIntyre
2010-09-25 15:45 ` Kristaps Dzonsons
0 siblings, 1 reply; 10+ messages in thread
From: Jason McIntyre @ 2010-09-25 15:35 UTC (permalink / raw)
To: discuss
On Sat, Sep 25, 2010 at 05:23:42PM +0200, Kristaps Dzonsons wrote:
> > so the issue is the initial `_' in _flush_cache. it's formatted in a
> > different font to the rest of the function name (you can see this best
> > on a terminal).
> >
> > this is a long standing bug that we always had in old groff, which
> > really annoyed me. new groff fixed it.
>
> Jason, I'm not sure I follow as mandoc, new groff, and old groff all
> seem to do the same thing with the _flush_cache beginning:
>
> GNU nroff (groff) version 1.18.1
> nroff -mandoc foo.1 | hexdump -c
> _ \b _ f \b f l \b l u \b
>
> mandoc foo.1 | hexdump -c
> _ \b _ f \b f l \b l u \b
>
> GNU troff version 1.15
> nroff -mandoc foo.1 | hexdump -c
> _ \b _ f \b f l \b l u \b
>
>
hmm, and you do not see the issue i describe? what else could it be?
surely not my TERM setting if mandoc shows it one way and groff another.
what else?
jmc
--
To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: .Fn _* issue
2010-09-25 15:35 ` Jason McIntyre
@ 2010-09-25 15:45 ` Kristaps Dzonsons
2010-09-25 17:47 ` Jason McIntyre
0 siblings, 1 reply; 10+ messages in thread
From: Kristaps Dzonsons @ 2010-09-25 15:45 UTC (permalink / raw)
To: discuss
>>> so the issue is the initial `_' in _flush_cache. it's formatted in a
>>> different font to the rest of the function name (you can see this best
>>> on a terminal).
>>>
>>> this is a long standing bug that we always had in old groff, which
>>> really annoyed me. new groff fixed it.
>> Jason, I'm not sure I follow as mandoc, new groff, and old groff all
>> seem to do the same thing with the _flush_cache beginning:
>>
>> GNU nroff (groff) version 1.18.1
>> nroff -mandoc foo.1 | hexdump -c
>> _ \b _ f \b f l \b l u \b
>>
>> mandoc foo.1 | hexdump -c
>> _ \b _ f \b f l \b l u \b
>>
>> GNU troff version 1.15
>> nroff -mandoc foo.1 | hexdump -c
>> _ \b _ f \b f l \b l u \b
>>
>>
>
> hmm, and you do not see the issue i describe? what else could it be?
> surely not my TERM setting if mandoc shows it one way and groff another.
>
> what else?
Jason,
It could be groff acting upon TERM. When I run this under a linux
terminal, for example, the underscores are colourised like the `Fa'
token (i.e., "underlined"). Do note that "_ \b _" is ambiguous: it
could either mean an underlined underscore or a bold underscore.
(I ran the above in TERM=rxvt.)
Kristaps
--
To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: .Fn _* issue
2010-09-25 15:45 ` Kristaps Dzonsons
@ 2010-09-25 17:47 ` Jason McIntyre
2010-09-25 20:18 ` Kristaps Dzonsons
0 siblings, 1 reply; 10+ messages in thread
From: Jason McIntyre @ 2010-09-25 17:47 UTC (permalink / raw)
To: discuss
On Sat, Sep 25, 2010 at 05:45:21PM +0200, Kristaps Dzonsons wrote:
> >>> so the issue is the initial `_' in _flush_cache. it's formatted in a
> >>> different font to the rest of the function name (you can see this best
> >>> on a terminal).
> >>>
> >>> this is a long standing bug that we always had in old groff, which
> >>> really annoyed me. new groff fixed it.
> >> Jason, I'm not sure I follow as mandoc, new groff, and old groff all
> >> seem to do the same thing with the _flush_cache beginning:
> >>
> >> GNU nroff (groff) version 1.18.1
> >> nroff -mandoc foo.1 | hexdump -c
> >> _ \b _ f \b f l \b l u \b
> >>
> >> mandoc foo.1 | hexdump -c
> >> _ \b _ f \b f l \b l u \b
> >>
> >> GNU troff version 1.15
> >> nroff -mandoc foo.1 | hexdump -c
> >> _ \b _ f \b f l \b l u \b
> >>
> >>
> >
> > hmm, and you do not see the issue i describe? what else could it be?
> > surely not my TERM setting if mandoc shows it one way and groff another.
> >
> > what else?
>
> Jason,
>
> It could be groff acting upon TERM. When I run this under a linux
> terminal, for example, the underscores are colourised like the `Fa'
> token (i.e., "underlined"). Do note that "_ \b _" is ambiguous: it
> could either mean an underlined underscore or a bold underscore.
>
> (I ran the above in TERM=rxvt.)
>
hmm. i use TERM=wsvt25. so do you think there is a bug in the term code,
or it's something else?
jmc
--
To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: .Fn _* issue
2010-09-25 17:47 ` Jason McIntyre
@ 2010-09-25 20:18 ` Kristaps Dzonsons
2010-09-25 21:25 ` Jason McIntyre
0 siblings, 1 reply; 10+ messages in thread
From: Kristaps Dzonsons @ 2010-09-25 20:18 UTC (permalink / raw)
To: discuss
>>>> GNU nroff (groff) version 1.18.1
>>>> nroff -mandoc foo.1 | hexdump -c
>>>> _ \b _ f \b f l \b l u \b
>>>>
>>>> mandoc foo.1 | hexdump -c
>>>> _ \b _ f \b f l \b l u \b
>>>>
>>>> GNU troff version 1.15
>>>> nroff -mandoc foo.1 | hexdump -c
>>>> _ \b _ f \b f l \b l u \b
>>>>
>>>>
>>> hmm, and you do not see the issue i describe? what else could it be?
>>> surely not my TERM setting if mandoc shows it one way and groff another.
>>>
>>> what else?
>> Jason,
>>
>> It could be groff acting upon TERM. When I run this under a linux
>> terminal, for example, the underscores are colourised like the `Fa'
>> token (i.e., "underlined"). Do note that "_ \b _" is ambiguous: it
>> could either mean an underlined underscore or a bold underscore.
>>
>> (I ran the above in TERM=rxvt.)
>>
>
> hmm. i use TERM=wsvt25. so do you think there is a bug in the term code,
> or it's something else?
There's nothing mandoc can do about it: the "_" character produces the
same escape sequence when it's underlined as when it's bold ("_\b_"). I
observe that, in this situation, the "underline" style has precedence
(by colouring on the "linux" terminal).
--
To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: .Fn _* issue
2010-09-25 20:18 ` Kristaps Dzonsons
@ 2010-09-25 21:25 ` Jason McIntyre
2010-09-25 21:29 ` Kristaps Dzonsons
0 siblings, 1 reply; 10+ messages in thread
From: Jason McIntyre @ 2010-09-25 21:25 UTC (permalink / raw)
To: discuss
On Sat, Sep 25, 2010 at 10:18:07PM +0200, Kristaps Dzonsons wrote:
> >
> > hmm. i use TERM=wsvt25. so do you think there is a bug in the term code,
> > or it's something else?
>
> There's nothing mandoc can do about it: the "_" character produces the
> same escape sequence when it's underlined as when it's bold ("_\b_"). I
> observe that, in this situation, the "underline" style has precedence
> (by colouring on the "linux" terminal).
so why groff displays "correctly" and mandoc not? the terminal
interprets those sequences? and i should just accept that there's a bit
screw up?
(not arguing, just clueless)
jmc
--
To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: .Fn _* issue
2010-09-25 21:25 ` Jason McIntyre
@ 2010-09-25 21:29 ` Kristaps Dzonsons
0 siblings, 0 replies; 10+ messages in thread
From: Kristaps Dzonsons @ 2010-09-25 21:29 UTC (permalink / raw)
To: discuss
Jason McIntyre wrote:
> On Sat, Sep 25, 2010 at 10:18:07PM +0200, Kristaps Dzonsons wrote:
>>> hmm. i use TERM=wsvt25. so do you think there is a bug in the term code,
>>> or it's something else?
>> There's nothing mandoc can do about it: the "_" character produces the
>> same escape sequence when it's underlined as when it's bold ("_\b_"). I
>> observe that, in this situation, the "underline" style has precedence
>> (by colouring on the "linux" terminal).
>
> so why groff displays "correctly" and mandoc not? the terminal
> interprets those sequences? and i should just accept that there's a bit
> screw up?
>
> (not arguing, just clueless)
Can you produce a hexdump of the escape sequence groff uses for the
offending phrase? I couldn't find any difference in groff and mandoc
output.
--
To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: .Fn _* issue
2010-09-25 6:35 .Fn _* issue Jason McIntyre
2010-09-25 15:23 ` Kristaps Dzonsons
@ 2010-09-25 21:38 ` Ingo Schwarze
2010-09-25 21:43 ` Joerg Sonnenberger
1 sibling, 1 reply; 10+ messages in thread
From: Ingo Schwarze @ 2010-09-25 21:38 UTC (permalink / raw)
To: discuss
Hi Jason,
Jason McIntyre wrote on Sat, Sep 25, 2010 at 07:35:23AM +0100:
> hi. the source, from cacheflush(3):
>
> .Sh SYNOPSIS
> .In machine/sysarch.h
> .Ft int
> .Fn cacheflush "void *addr" "int nbytes" "int cache"
> .Ft int
> .Fn _flush_cache "char *addr" "int nbytes" "int cache"
>
> formats as:
>
> SYNOPSIS
> #include <machine/sysarch.h>
>
> int
> cacheflush(void *addr, int nbytes, int cache);
>
> int
> _flush_cache(char *addr, int nbytes, int cache);
>
> so the issue is the initial `_' in _flush_cache. it's formatted in a
> different font to the rest of the function name (you can see this best
> on a terminal).
As Kristaps said, the first underscore is rendered underlined.
Apparently, that's the default interpretation of "_\b_".
The second understore, though, is rendered bold, even though
it's physically the exact same sequence of charachters, "_\b_".
Probably, that happens because the preceding 'h' character
is bold and not underlined. If i change that 'h' to underlined,
the second underscore becomes underlined, too.
Thus, i agree with Kristaps that i see nothing we could do about it.
It's not a mandoc bug, maybe not even a bug at all, but a limitation
of backspace encoding for bold and underline.
> this is a long standing bug that we always had in old groff, which
> really annoyed me. new groff fixed it.
Not really. What happens is that groff-1.20.1 uses ANSI encoding,
not backspace encoding for bold and underline, and in ANSI encoding,
that limitation does not exist. In ANSI encoding, the bold underscore
is "\e[1m_" while the underlined underscore would be "\e[4m_",
the "\e" representing the escape character (ASCII 0x1b).
Yours,
Ingo
--
To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: .Fn _* issue
2010-09-25 21:38 ` Ingo Schwarze
@ 2010-09-25 21:43 ` Joerg Sonnenberger
0 siblings, 0 replies; 10+ messages in thread
From: Joerg Sonnenberger @ 2010-09-25 21:43 UTC (permalink / raw)
To: discuss
On Sat, Sep 25, 2010 at 11:38:12PM +0200, Ingo Schwarze wrote:
> > this is a long standing bug that we always had in old groff, which
> > really annoyed me. new groff fixed it.
>
> Not really. What happens is that groff-1.20.1 uses ANSI encoding,
> not backspace encoding for bold and underline, and in ANSI encoding,
> that limitation does not exist. In ANSI encoding, the bold underscore
> is "\e[1m_" while the underlined underscore would be "\e[4m_",
> the "\e" representing the escape character (ASCII 0x1b).
Actually, I think for newer groff it depends on the output device. Some
use ANSI encodings, some use backspace encoding.
Joerg
--
To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-09-25 21:43 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-09-25 6:35 .Fn _* issue Jason McIntyre
2010-09-25 15:23 ` Kristaps Dzonsons
2010-09-25 15:35 ` Jason McIntyre
2010-09-25 15:45 ` Kristaps Dzonsons
2010-09-25 17:47 ` Jason McIntyre
2010-09-25 20:18 ` Kristaps Dzonsons
2010-09-25 21:25 ` Jason McIntyre
2010-09-25 21:29 ` Kristaps Dzonsons
2010-09-25 21:38 ` Ingo Schwarze
2010-09-25 21:43 ` Joerg Sonnenberger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).