* .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).