Re: [Groff] Status of the portability work, and plans for the future

> > .SY > > .SY > > .YS > > > > it's just necessary to test a flag, say, \n(sy, which is set by > > the first .SY call. If it's still set in the next call to .SY, > > don't call the .ad request. > > OK. Can I rely on you to add that? Yes. In case I forget please remind me :-) Werne

Re: [Groff] Status of the portability work, and plans for the future

Werner LEMBERG <[EMAIL PROTECTED]>: > > Then I don't know what the right thing is here. I agree with your > > design intention, but I can't see how to implement it robustly. > > Well, doclifter ignores it anyway, doesn't it? Yes, but doclifter isn't the problem here, either. > > Even querying

Re: [Groff] Status of the portability work, and plans for the future

> > > On reflection, I think that should probably be ".ad b". It's > > > supposed to be restoring the normal adjustment mode for a man > > > page. > > > > I disagree. Perhaps someone likes to make the appearance of man > > pages formatted with -man similar to the ones formatted with > > -mdoc, th

Re: [Groff] Status of the portability work, and plans for the future

> I know \[bv] is old. I mean this sequence that it begins, which wasn't > present when I first wrote doclifter: > >⎪ \[bv] braceex u23AA vertical exten‐ > sion [...] These glyphs have been t

Re: [Groff] Status of the portability work, and plans for the future

Werner LEMBERG wrote: I just fixed up ditroff.man. This is going fairly smoothly so far. Your past macro coders have had bad cases of "ooh! nifty feature! must use!", :-) but despite that the code is pretty readable. It's not really clear to me what you mean with `macro coders'. W

Re: [Groff] Status of the portability work, and plans for the future

Werner LEMBERG <[EMAIL PROTECTED]>: > > > That sequence of bracket characters starting with \bv is new to me > > -- I gather that has been introduced in CVS recently? > > What sequence do you mean? The glyph \[bv] has been there since ever. > And no, I no longer add new glyphs to groff using ad-

Re: [Groff] Status of the portability work, and plans for the future

Werner LEMBERG <[EMAIL PROTECTED]>: > > > > You've forgotten to store something in register `a'. > > > > On reflection, I think that should probably be ".ad b". It's > > supposed to be restoring the normal adjustment mode for a man page. > > I disagree. Perhaps someone likes to make the appeara

Re: [Groff] Status of the portability work, and plans for the future

> That sequence of bracket characters starting with \bv is new to me > -- I gather that has been introduced in CVS recently? What sequence do you mean? The glyph \[bv] has been there since ever. And no, I no longer add new glyphs to groff using ad-hoc glyph names. The groff glyph list is frozen

Re: [Groff] Status of the portability work, and plans for the future

> > You've forgotten to store something in register `a'. > > On reflection, I think that should probably be ".ad b". It's > supposed to be restoring the normal adjustment mode for a man page. I disagree. Perhaps someone likes to make the appearance of man pages formatted with -man similar to th

Re: [Groff] Status of the portability work, and plans for the future

Gunnar Ritter <[EMAIL PROTECTED]>: > When you started this discussion, I was under the > impression that you wanted to do development - to > correct certain problems you found with some manual > pages. I have supported that. But now I find that > it was rather a preparation for this evangelism,

Re: [Groff] Status of the portability work, and plans for the future

"Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > You skipped a step. You have a good point about calling up manual > pages within an editor, but not all character-cell displays are > equivalent; it doesn't follow from this that man(1) through xterm has > any value that lynx(1) through xterm wouldn'

Re: [Groff] Status of the portability work, and plans for the future

On Tue, Jan 09, 2007 at 02:09:52PM -0500, Eric S. Raymond wrote: > Joerg van den Hoff <[EMAIL PROTECTED]>: > >> well at least I would argue that navigating with `less' through the >> man output is superior to `lynx' for the same purpose > > In what way? That is, what actual capabilities and behavi

Re: [Groff] Status of the portability work, and plans for the future

Gunnar Ritter wrote: "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: It's a point for the future, really, and goes back to the philosophical question I opened up at the beginning of this discussion: is the groff community ready to accept that the future of on-line documentation belongs to hypert

Re: [Groff] Status of the portability work, and plans for the future

Eric S. Raymond wrote: man(1) is not sacred, and I actually find attitudes like yours kind of insulting, as though you think long-time man users like me are so utterly lacking in mental flexibility as to be unable to cope with even a tiny speedbump on the road to better things. Heh, you

Re: [Groff] Status of the portability work, and plans for the future

On Tue, Jan 09, 2007 at 02:26:38PM -0500, Eric S. Raymond wrote: > > For me, and I think many others, > > getting a man page in an editor window does make sense and I > > wouldn't want to lose that ability. > > I agreed with you about this last time. I still don't see

Re: [Groff] Status of the portability work, and plans for the future

Jon Snader <[EMAIL PROTECTED]>: > I stand corrected on your desktop set up, but I'm willing to > concede only half the point. With your desktop, calling up a man > page from your editor would cause a browser to pop up. That's a > little distracting, perhaps, but not nearly so much as having to >

Re: [Groff] Status of the portability work, and plans for the future

Joerg van den Hoff <[EMAIL PROTECTED]>: > well at least I would argue that navigating with `less' through the man > output is superior to `lynx' for the same purpose In what way? That is, what actual capabilities and behaviors are you basing that evaluation on? And thanks for speaking up. --

Re: [Groff] Status of the portability work, and plans for the future

On Tue, Jan 09, 2007 at 12:03:14PM -0500, Eric S. Raymond wrote: > > Your thinking is intelligent and cogent -- but your factual > premise is wrong, leading you to an incorrect model of my > assumptions. On my usual desktop arrangement, rendering man > pages in a browser *would* in fact have the

Re: [Groff] Status of the portability work, and plans for the future

Eric S. Raymond wrote: Jon Snader <[EMAIL PROTECTED]>: As a Vim user, I use the K command to pop up a man page in an editor window when I need to check the exact usage or parameters. I know that emacs users can do similar things with the M-x man command. Most serious developers use either emacs

Re: [Groff] Status of the portability work, and plans for the future

Jon Snader <[EMAIL PROTECTED]>: > As a Vim user, I use the K command to pop up a man page in an > editor window when I need to check the exact usage or parameters. > I know that emacs users can do similar things with the M-x man > command. Most serious developers use either emacs or Vim, so I'd >

Re: [Groff] Status of the portability work, and plans for the future

On Mon, Jan 08, 2007 at 10:02:11PM -0500, Eric S. Raymond wrote: > > Gunnar, Linux man(1) can do this *now*. I added the code myself over a > year ago. All that's needed is for HTML pages to be in the right > places under /usr/man and it's game over. Of course, if you were > insistent on a cra

Re: [Groff] Status of the portability work, and plans for the future

"Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > > Huh? What world are you living on, Eric? In yours, people > > like browser windows popping up, make no use of browser tabs, > > and especially do not have their tabbed browser on another > > virtual desktop than their xterm(s)? Sounds like a strange

Re: [Groff] Status of the portability work, and plans for the future

Gunnar Ritter <[EMAIL PROTECTED]>: > Then at the very least add some sort of /*LINTED*/ comment > that allows authors to turn off your warnings within the > manual page. That's a good idea, if the way the warning hooks are implemented allows it. > Huh? What world are you living on, Eric? In your

Re: [Groff] Status of the portability work, and plans for the future

"Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > Gunnar Ritter <[EMAIL PROTECTED]>: > > Yes, and authors would also get nasty bug reports from > > people who compile their manual pages with the switch > > turned off because it is the default. This would be as > > bad as gcc shipping with -Wall enabl

Re: [Groff] Status of the portability work, and plans for the future

Werner LEMBERG <[EMAIL PROTECTED]>: > > > > U+23A2 LEFT SQUARE BRACKET EXTENSION > > > U+23A5 RIGHT SQUARE BRACKET EXTENSION > > > > W00t! I googled for that and I think I found matches for *all* of > > them nearby, here: > > Yep. I think I have all of them in groff_char. Yes, I think you

Re: [Groff] Status of the portability work, and plans for the future

> > U+23A2 LEFT SQUARE BRACKET EXTENSION > > U+23A5 RIGHT SQUARE BRACKET EXTENSION > > W00t! I googled for that and I think I found matches for *all* of > them nearby, here: Yep. I think I have all of them in groff_char. > .if '\*[.T]'dvi' \{\ > . ftr CB CW > .\} > . > .de SY > .nh > .a

Re: [Groff] Status of the portability work, and plans for the future

Werner LEMBERG <[EMAIL PROTECTED]>: > Hmm. I have > > U+23A2 LEFT SQUARE BRACKET EXTENSION > U+23A5 RIGHT SQUARE BRACKET EXTENSION W00t! I googled for that and I think I found matches for *all* of them nearby, here: . > Please p

Re: [Groff] Status of the portability work, and plans for the future

> > What do you think about looking into groff_char also, not just > > lifting? :-) > > I've studied it pretty carefully, actually. How else do you suppose > I built the translation tables in doclifter? Touché. > Sigh...I rather expected that was what you were going to tell me. > Oh well, after

Re: [Groff] Status of the portability work, and plans for the future

Werner LEMBERG <[EMAIL PROTECTED]>: > > You wouldn't happen to know of mappings for the bracket pile > > graphics, would you? > > What do you think about looking into groff_char also, not just > lifting? :-) I've studied it pretty carefully, actually. How else do you suppose I built the translat

Re: [Groff] Status of the portability work, and plans for the future

> You wouldn't happen to know of mappings for the bracket pile > graphics, would you? What do you think about looking into groff_char also, not just lifting? :-) All I know Unicode mapping is already in this file. > > I'll fix the rest of groff in due course. However, this might > > only happe

Re: [Groff] Status of the portability work, and plans for the future

Werner LEMBERG <[EMAIL PROTECTED]>: > > Looking at my code, I see there is one more exception; troff \*(an, > > horizontal arrow extension, can't be mapped either. You'd think > > there'd be an ISO entity for this somewhere in the AMSA arrow set, > > but there isn't. Nor have I found a Unicode eq

Re: [Groff] Status of the portability work, and plans for the future

Gunnar Ritter <[EMAIL PROTECTED]>: > Yes, and authors would also get nasty bug reports from > people who compile their manual pages with the switch > turned off because it is the default. This would be as > bad as gcc shipping with -Wall enabled by default. Only authors who didn't strict-validate

Re: [Groff] Status of the portability work, and plans for the future

> Looking at my code, I see there is one more exception; troff \*(an, > horizontal arrow extension, can't be mapped either. You'd think > there'd be an ISO entity for this somewhere in the AMSA arrow set, > but there isn't. Nor have I found a Unicode equivalent. U+23AF HORIZONTAL LINE EXTENSION

Re: [Groff] Status of the portability work, and plans for the future

"Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > Gunnar Ritter <[EMAIL PROTECTED]>: > > > > Maybe. But still the tools should not complain if a troff > > > > expert has decided that something is safe. > > > > > > And how are they going to do that? Mental telepathy? :-) > > > > As I wrote in the te

Re: [Groff] Status of the portability work, and plans for the future

Gunnar Ritter <[EMAIL PROTECTED]>: > > > Maybe. But still the tools should not complain if a troff > > > expert has decided that something is safe. > > > > And how are they going to do that? Mental telepathy? :-) > > As I wrote in the text following, by separating a "lint" > (or "-Wall") mode and

Re: [Groff] Status of the portability work, and plans for the future

Werner LEMBERG <[EMAIL PROTECTED]>: > My mistake. Anyway, I think XML also knows Unicode character > entities, right? This is what I have meant. Yes, you can embed Unicode entities in XML. Right now doclifter does this for a handful of cases in which the right ISO entities don't exist. The se

Re: [Groff] Status of the portability work, and plans for the future

"Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > Gunnar Ritter <[EMAIL PROTECTED]>: > > All I want is to avoid an incomplete hack extension to -man > > which seems useful just for this discussion but does not > > result in a general improvement. > > What you're likely to get is an "incomplete hack e

Re: [Groff] Status of the portability work, and plans for the future

"Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > > Maybe. But still the tools should not complain if a troff > > expert has decided that something is safe. > > And how are they going to do that? Mental telepathy? :-) As I wrote in the text following, by separating a "lint" (or "-Wall") mode and si

Re: [Groff] Status of the portability work, and plans for the future

Gunnar Ritter <[EMAIL PROTECTED]>: > As I wrote, it depends on context. And as I wrote, that's not a useful answer. Any portability rule that can't be explained over a telephone and mechanically checked is going to become irrelevant because authors simply won't apply it. They have other things to

Re: [Groff] Status of the portability work, and plans for the future

Gunnar Ritter <[EMAIL PROTECTED]>: > All I want is to avoid an incomplete hack extension to -man > which seems useful just for this discussion but does not > result in a general improvement. What you're likely to get is an "incomplete hack extension" that's used in the groff man pages only. I too

Re: [Groff] Status of the portability work, and plans for the future

"Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > What requests would you say are "visually safe" in the way you are defining > that are not on the portable list? (It is presently .de .ds .fi .ft .ie .if > .ig .nf .nr .rm .rn .so .sp). You make a case for .hy/.nh/.ad; what others > would you add?

Re: [Groff] Status of the portability work, and plans for the future

"Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > Gunnar seems to think UTF-8 is the right direction. Yes, with the exception of CJK writers, people all over the world seem to agree on that, and it is unlikely that anybody except those will even have the idea to write text documents like troff input

Re: [Groff] Status of the portability work, and plans for the future

Werner LEMBERG <[EMAIL PROTECTED]>, 2007-01-08 15:44 +0100: [quoting me] > > I have observed problems in some environments with display of lines > > containing "\~" (which is why the DocBook manpages stylesheet > > outputs "\" instead). > > Details, please. Sorry, I don't have many. But for what

Re: [Groff] Status of the portability work, and plans for the future

> > Both `\' and `\~' (and \0) are equivalent to   > > But they're different in that "\~" stretches while "\" > doesn't, right? Yes, but viewed from the input encoding side, they are completely identical. > I have observed problems in some environments with display of lines > containing "\~" (wh

Re: [Groff] Status of the portability work, and plans for the future

> > 1. If the input encoding has been explicitly specified, use it. > > > > 2. Otherwise, check whether the input starts with a Byte Order > >Mark. If found, use it. > > 3. Finally, check whether there is a known coding tag in either > >the first or second input line. If found, use it.

Re: [Groff] Status of the portability work, and plans for the future

Werner LEMBERG <[EMAIL PROTECTED]>: > > Werner Lemberg wanted to know the status of \~. I found 17 uses > > within the groff documentation and 4 outside it. Of those 4, two > > were errors. So it's not much needed for manual pages, which is a > > good thing as it is not portable. In particular,

Re: [Groff] Status of the portability work, and plans for the future

Werner LEMBERG <[EMAIL PROTECTED]>, 2007-01-08 08:02 +0100: > > Werner Lemberg wanted to know the status of \~. I found 17 uses > > within the groff documentation and 4 outside it. Of those 4, two > > were errors. So it's not much needed for manual pages, which is a > > good thing as it is not

Re: [Groff] Status of the portability work, and plans for the future

> I consider a manual page portable when it can be formatted in all > viewers without flaws. But this does not forbid further careful > optimization for a certain viewer (i.e. nroff) as long as it does > not cause the output of other viewers to get worse. Well, we have `.if n', `.if t', \n[.g] (

Re: [Groff] Status of the portability work, and plans for the future

> Werner Lemberg wanted to know the status of \~. I found 17 uses > within the groff documentation and 4 outside it. Of those 4, two > were errors. So it's not much needed for manual pages, which is a > good thing as it is not portable. In particular, I was unable to > discover any correspondi

Re: [Groff] Status of the portability work, and plans for the future

Gunnar Ritter <[EMAIL PROTECTED]>: > > But now you say "One can safely use almost all requests if their context > > is pure visual nroff markup which does not hurt when omitted." You > > reverse the thrust of your earlier argument, and you do it in a way > > that makes no sense to me! > > It is

Re: [Groff] Status of the portability work, and plans for the future

"Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > But now you say "One can safely use almost all requests if their context > is pure visual nroff markup which does not hurt when omitted." You > reverse the thrust of your earlier argument, and you do it in a way > that makes no sense to me! It is

Re: [Groff] Status of the portability work, and plans for the future

Gunnar Ritter <[EMAIL PROTECTED]>: > "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > > > Note that .br/.nl, .ti, .ta, and .in are *not* in the portable set. > > These cannot be translated structurally by doclifter, and man-to-HTML > > translators tend to ignore them or give useless results as well.

Re: [Groff] Status of the portability work, and plans for the future

"Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > Note that .br/.nl, .ti, .ta, and .in are *not* in the portable set. > These cannot be translated structurally by doclifter, and man-to-HTML > translators tend to ignore them or give useless results as well. > . . . > I noted previously that \w is *not