.Fn _* issue

.Fn _* issue

[Jason McIntyre]

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

Re: .Fn _* issue

[Kristaps Dzonsons]

> 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

Re: .Fn _* issue

[Jason McIntyre]

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

Re: .Fn _* issue

[Kristaps Dzonsons]

>>> 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

Re: .Fn _* issue

[Jason McIntyre]

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

Re: .Fn _* issue

[Kristaps Dzonsons]

>>>>   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

Re: .Fn _* issue

[Jason McIntyre]

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

Re: .Fn _* issue

[Kristaps Dzonsons]

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

Re: .Fn _* issue

[Ingo Schwarze]

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

Re: .Fn _* issue

[Joerg Sonnenberger]

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