[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Re: new grotty format

From: Colin Watson
Subject: Re: [Groff] Re: new grotty format
Date: Tue, 18 Jun 2002 02:47:13 +0100
User-agent: Mutt/1.3.28i

On Mon, Feb 11, 2002 at 03:41:49PM +0200, Eli Zaretskii wrote:
> On Mon, 11 Feb 2002, Rick Richardson wrote:
> > How long a period do you propose for the default to remain overstrikes
> > before it is switched to SGR?
> I don't know, but a period of zero length sounds extremely harsh on the 
> users.  At least one officially-released Groff version should be used as 
> a grace period, if you ask me, and perhaps more.

Sorry to bring this old thread up again so long after its death. I've
cut the Cc: list down a bit since info has been changed to cope with

I've just tested SGR output for man pages with a few of Debian's pagers.
'less' is largely OK, since I've altered man to append -R to $LESS.
'most' displays the escape sequences in full (e.g. "^[[1m"), and I don't
see a way to change this. The venerable 'more' gets the colours right,
but evidently counts the columns wrongly; its word-wrapping of the
display is a mess.

> Look, you are effectively deprecating a widely-used feature.  It is
> generally accepted practice to declare a feature deprecated for some time 
> before it is turned off by default.  Think about all those users who will 
> all of a sudden see garbled man pages just because they upgraded their 
> Groff and didn't read the fine print of the NEWS file.

If such basic programs as the above have trouble, I'm inclined to agree.
I'd like to disable the SGR escapes for grotty at least in the Debian
package until they can be fixed, in an pre-emptive attempt to stem the
tide of bug reports. What method should I use for this? GROFF_NO_SGR=0?
GROFF_SGR=1? The latter seems neatest.

I like the colour output, and am tempted to say "push it out to everyone
as fast as possible", but it just isn't worth it yet when the support is
so limited.

> > Yes, I think there should be a flag day, it should come as soon as
> > possible, and a method can be provided to *disable* flag day for those
> > people who will never be ready for a flag day no matter what you do to
> > prepare them.
> As someone who has some experience in going that way, let me warn you: 
> users don't always like such an approach, don't always read the docs to 
> know in advance they should set some obscure environment variable, and 
> don't like to be told that they need to tweak their systems to make the 
> new version work reasonably well.

Man pages being what they are, the majority of users will have no idea
what's wrong and will have little or no influence on how quickly the
flag day can happen. It doesn't seem as if they will have a fixed
version of many programs to which they can simply upgrade.


Colin Watson                                  address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]