Re: Menu: Help -> Manuals -> Read Man Page... problem

[Peter Breitenlohner <peb@mppmu.mpg.de>]

On Thu, 18 Mar 2004, Peter Breitenlohner wrote:

> On Wed, 17 Mar 2004, Eli Zaretskii wrote:
>
> Current Emacs development sources already set GROFF_NO_SGR=1 when they
> run `man'.

Hi Eli,

meanwhile I have added `(setenv "GROFF_NO_SGR" "1")' to `lisp/man.el' and
recompiled `lisp/man.elc'. This sort of works BUT is still far from a
solution of the problem.

On our linux/gnu systems we use man-db-2.4.0 (not man-1.5k) which
automatically caches formatted manpages as catpages (which we then
periodically expire via a cron job). As far as I can see that's perfectly
consistent with the POSIX specs (as I understand them from man.1p
distributed with man-pages-1.65).

This caching only occurs when COLUMNS=80, otherwise the manpages are
reformatted on the fly.

Together with the emacs manviewer (with GROFF_NO_SGR=1) and assuming
COLUMNS=80 that means:

(a) there exists a cached catpage (produced by man invoked directly)  =>
emacs will mis-display the color escapes.

(b) there is no cached catpage (or there is on one produced by man invoked
from emacs) => fine.

The way out by `xman' is that man is bypassed completely and the various
filters plus groff are invoked directly. Since this requires a knowledge of
MANPATH and of filters that's hardly a solution for emacs.

As far as I can see there are the following solutions to these problems:

(1) You, the emacs developers, convince the groff people to abandon the
whole color escape stuff (hardly realistic).

(2) You introduce an emacs display option to properly handle color escapes and
use that option when viewing manpages (may be difficult).

(3) Make sure that man never gets invoked with COLUMNS=80. This would most
probably solve our immediate problems, at least with man-db, but is no more
than a kludge.

As a temporary solution for us we will probably force our man command to
invoke groff with GROFF_NO_SGR=1 such that the cached catpages with color
escapes will disappear after a while.

regards
Peter Breitenlohner <peb@mppmu.mpg.de>