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

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

[Peter Breitenlohner]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.3.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2004-02-24 on pcl321
configured using `configure  ix86-linux-gnulibc2 --prefix=/usr/local'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

If I use the emacs menu: Help -> Manuals -> Read Man Page...
to view a unix manpage I get bad output. The reason is, that since
groff-1.18.1 the output from 'groff -Tlatin1 -mandoc' contains SRG
escape sequences (ISO 6429, or ANSI color escapes) that emacs doesn't
display properly.

The same problem occured with xman from XFree86-4.3.0 (and maybe earlier).
There the solution was to invoke groff with a suitable environment variable:
      GROFF_NO_SGR= groff -Tlatin1 -mandoc

The alternative to invoke groff with '-c' is not viable because (1) that flag
is not understood by groff-1.17.x and (2) even for groff-1.18.1 seems not to
work as advertised.

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



Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <menu-bar> <help-menu> <manuals> <man> 
<return> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <menu-bar> <help-menu> <report-emacs-b
ug>

Recent messages:
(emacs)
Loading tool-bar...done
Loading image...done
Loading tooltip...done
For information about the GNU Project and its goals, type C-h C-p.
Loading man...done
if: No man args given
Loading emacsbug...done

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

[Eli Zaretskii]

> Date: Wed, 17 Mar 2004 10:56:36 +0100
> From: Peter Breitenlohner <peb@mppmu.mpg.de>
> 
> If I use the emacs menu: Help -> Manuals -> Read Man Page...
> to view a unix manpage I get bad output. The reason is, that since
> groff-1.18.1 the output from 'groff -Tlatin1 -mandoc' contains SRG
> escape sequences (ISO 6429, or ANSI color escapes) that emacs doesn't
> display properly.

Thanks for the report.

IIRC, Emacs 21.3 was released before Groff 1.18, so you cannot expect
it to support this feature.

Current Emacs development sources already set GROFF_NO_SGR=1 when they
run `man'.

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

[Peter Breitenlohner]

On Wed, 17 Mar 2004, Eli Zaretskii wrote:

> Thanks for the report.

Hi Eli,

thanks for your quick response.

> IIRC, Emacs 21.3 was released before Groff 1.18, so you cannot expect
> it to support this feature.

That's not entirely true. Groff-1.18.tar.gz from the ftp server is dated
"08 Oct 2002" and we use that version since 27 Nov 2002. On the other hand
emacs-21.3.tar.gz from the ftp server is dated "19 Mar 2003". But I agree
that there probably wasn't much time to detect the problem.

> Current Emacs development sources already set GROFF_NO_SGR=1 when they
> run `man'.

Good to know (in particular since man is somewhat disfavoured by FSF).

Is this built into the emacs binary or just in the one place I found:
line 61 of emacs-21.3/lisp/gnus/gnus-uu.el?
And would it suffice to modify that file
	'"groff -mandoc -Tascii %s' => '"GROFF_NO_SGR=1 groff -mandoc -Tascii %s'
(and of course recompile gnus-uu.elc)?

I certainly want to fix this little problem before we get emacs-21.4

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

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

[Reiner Steib]

On Thu, Mar 18 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'.
[...]
> Is this built into the emacs binary or just in the one place I found:
> line 61 of emacs-21.3/lisp/gnus/gnus-uu.el?

I think the correct place is `lisp/man.el'.  You can apply the
following patch.  If it works (I cannot check myself), can someone
apply this patch to the EMACS_21_1_RC branch, please?

--8<---------------cut here---------------start------------->8---
--- man.el.~1.108.4.2.~	Wed Oct 16 01:03:28 2002
+++ man.el	Thu Mar 18 16:20:26 2004
@@ -1,6 +1,6 @@
 ;;; man.el --- browse UNIX manual pages
 
-;; Copyright (C) 1993, 1994, 1996, 1997, 2001 Free Software Foundation, Inc.
+;; Copyright (C) 1993, 1994, 1996, 1997, 2001, 2004 Free Software Foundation, Inc.
 
 ;; Author: Barry A. Warsaw <bwarsaw@cen.com>
 ;; Maintainer: FSF
@@ -81,7 +81,7 @@
 ;;   footer).  A different algorithm should be used.  It is easy to
 ;;   compute how many blank lines there are before and after the page
 ;;   headers, and after the page footer.  But it is possible to compute
-;;   the number of blank lines before the page footer by euristhics
+;;   the number of blank lines before the page footer by heuristics
 ;;   only.  Is it worth doing?
 ;; - Allow a user option to mean that all the manpages should go in
 ;;   the same buffer, where they can be browsed with M-n and M-p.
@@ -613,6 +613,7 @@
 	      ;; the page will actually be displayed, but it seems
 	      ;; reasonable.
 	      (setenv "COLUMNS" (number-to-string (frame-width)))))
+	(setenv "GROFF_NO_SGR" "1")
 	(if (fboundp 'start-process)
 	    (set-process-sentinel
 	     (start-process manual-program buffer "sh" "-c"
--8<---------------cut here---------------end--------------->8---

For the ChangeLog:

--8<---------------cut here---------------start------------->8---
2004-03-18  Reiner Steib  <Reiner.Steib@gmx.de>

	* man.el (Man-getpage-in-background): Set GROFF_NO_SGR.
--8<---------------cut here---------------end--------------->8---

> And would it suffice to modify that file
> 	'"groff -mandoc -Tascii %s' => '"GROFF_NO_SGR=1 groff -mandoc -Tascii %s'
> (and of course recompile gnus-uu.elc)?

This is only for viewing uuencoded attached man page sources in Gnus,
AFAICS.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

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

[Peter Breitenlohner]

On Thu, 18 Mar 2004, Reiner Steib wrote:

> On Thu, Mar 18 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'.
> [...]
> > Is this built into the emacs binary or just in the one place I found:
> > line 61 of emacs-21.3/lisp/gnus/gnus-uu.el?
>
> I think the correct place is `lisp/man.el'.  You can apply the
> following patch.  If it works (I cannot check myself), can someone
> apply this patch to the EMACS_21_1_RC branch, please?

Hi Reiner,

just patched `lisp/man.el', recompiled `lisp/man.elc' and everything works
fine.

Thanks a lot.
Peter Breitenlohner <peb@mppmu.mpg.de>

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

[Eli Zaretskii]

> Date: Thu, 18 Mar 2004 09:52:31 +0100 (CET)
> From: Peter Breitenlohner <peb@mppmu.mpg.de>
> 
> > Current Emacs development sources already set GROFF_NO_SGR=1 when they
> > run `man'.
> 
> Good to know (in particular since man is somewhat disfavoured by FSF).
> 
> Is this built into the emacs binary or just in the one place I found:
> line 61 of emacs-21.3/lisp/gnus/gnus-uu.el?

No, it's in man.el:

	(setenv "GROFF_NO_SGR" "1")
	(if (fboundp 'start-process)
	    (set-process-sentinel
	     (start-process manual-program buffer "sh" "-c"
			    (format (Man-build-man-command) man-args))
	     'Man-bgproc-sentinel)

GROFF_NO_SGR when calling groff (was: Menu: Help -> Manuals -> Read Man Page... problem)

[Reiner Steib]

On Thu, Mar 18 2004, Eli Zaretskii wrote:

>> > Current Emacs development sources already set GROFF_NO_SGR=1 when they
>> > run `man'.
[...]
> 	(setenv "GROFF_NO_SGR" "1")
> 	(if (fboundp 'start-process)
> 	    (set-process-sentinel
> 	     (start-process manual-program buffer "sh" "-c"
> 			    (format (Man-build-man-command) man-args))
> 	     'Man-bgproc-sentinel)

Wouldn't it make sense to _use_ the SGR control sequences by applying
`ansi-color-apply-on-region' (from `ansi-color.el') on the output
buffer instead of suppressing them?

I don't have groff >= 1.18 here so I dunno if it would work nicely.

[ Probably this should be discussed on emacs-devel.
  -> Added along with Mail-Followup-To: emacs-devel@gnu.org ]

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: GROFF_NO_SGR when calling groff

[Werner LEMBERG]

> Wouldn't it make sense to _use_ the SGR control sequences by
> applying `ansi-color-apply-on-region' (from `ansi-color.el') on the
> output buffer instead of suppressing them?

Yes.  I've suggested this already, but my lisp knowledge (and my
available time) is too limited to do it by myself, and AFAIK nobody
has fixed it yet.  Volunteers welcome.


    Werner

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

[Peter Breitenlohner]

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>

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

[Werner LEMBERG]

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

He has tried :-)

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

This is available already!  In ansi-color.el there is a function
ansi-color-apply-on-region -- Kai has told me that he will have a look
how to integrate this function into the man stuff.  It should be
straightforward, but, as usual, we lack the manpower to do that
quickly.  Since a work-around is available, it hasn't too much a
priority I fear.


    Werner