23.0.60; Womang hangs on some links

23.0.60; Womang hangs on some links

[Frédéric Perrin]

Hello,

Starting with a fresh checkout of the emacs source tree, Woman hangs
when following some links to non-existent man pages. It happenned when
I was looking at the procmailrc(5) page, and wanted to follow the
regexp(5) link. At that moment, emacs stopped responding. The
regexp(5) page doesn't exist on my system.

However, when trying to come up with a minimal example, I saw that it
doesn't happen with all broken links. Here are the steps to reproduce :

1. Save the following snippet to a file, say hangs.1 :

---------------- 8< ----------------
.TH "hang" 1
.SH NAME
hang \- small man page that hangs Emacs
.SH DESCRIPTION
If you follow this link :
.BR regexp (5)
, Emacs will hang.

However, if you follow this one :
.BR nonexistent (5)
, Emacs won't hang.
---------------- 8< ---------------

2. Start emacs with emacs -Q, and visit hangs.1 with M-x
woman-find-file.

3. Put point on nonexistent(5) and press RET : as expected, Woman says
that the page cannot by found.

4. Put point on regexp(5), and press RET : emacs with stop responding,
consuming 100% of the CPU.

A side question : given the recent discussions about the state of the
toolchain used, I did 'rm -fr emacs ; cvs -d... co emacs ; cd emacs ;
./configure ; make bootstrap'. Is there a method less network and
CPU-hungry ?

-- 
Fred

In GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, GTK+ Version 2.12.10)
 of 2008-06-07 on girafe
Windowing system distributor `The X.Org Foundation', version 11.0.10400090
configured using `configure  '--prefix=/home/fred' '--program-suffix=.cvs''

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: fr_FR.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  shell-dirtrack-mode: t
  show-paren-mode: t
  global-hi-lock-mode: t
  hi-lock-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p o r t <tab> <return>

Recent messages:
Loading /usr/share/emacs22/site-lisp/debian-startup.elc...done
Loading 00debian-vars...done
Loading /etc/emacs22/site-start.d/50auctex.el (source)...
Error while loading 50auctex
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...
Error while loading 50dictionaries-common
Loading /etc/emacs/site-start.d/50php-elisp.el (source)...done
Loading /etc/emacs/site-start.d/50psvn.el (source)...done
Loading /home/fred/.emacs.d/my-emacs-cvs.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.

Re: 23.0.60; Womang hangs on some links

[Stefan Monnier]

> A side question : given the recent discussions about the state of the
> toolchain used, I did 'rm -fr emacs ; cvs -d... co emacs ; cd emacs ;
> ./configure ; make bootstrap'. Is there a method less network and
> CPU-hungry ?

You can use a cvs-clean script which just removes all
non-CVS-controlled files.  This is *much* faster and doesn't require any
network access.
E.g. I occasionally use the script below.


        Stefan


#!/usr/bin/perl

sub cvsclean {
    my($path) = @_;
    my(%files) = ();
    my(@subdirs);

    print STDOUT "Cleaning $path\n";
    opendir (DIR, "$path/") || die "No directory $path";
    open (ENTRIES, "$path/CVS/Entries") || die "No $path/CVS/Entries file";
    while (<ENTRIES>) {
	if (m[^D/([^/]+)]) {
	    push (@subdirs, "$path/$1");
	} elsif (m[^/([^/]+)/[^/-]]) {
	    $files{$1} = "managed";
	}
    }

    foreach $entry (readdir(DIR)) {
	if (!exists ($files{$entry})) {
	    $entry = "$path/$entry";
	    if (-f $entry) {
		print STDOUT "unlink $entry\n";
		unlink $entry;
	    }
	}
    }
    
    foreach $subdir (@subdirs) {
	&cvsclean ($subdir);
    }
}

&cvsclean (".");

bug#414: 23.0.60; Womang hangs on some links

[Frédéric Perrin]

Hello,

Frédéric Perrin <frederic.perrin@resel.fr> writes:
> Starting with a fresh checkout of the emacs source tree, Woman hangs
> when following some links to non-existent man pages. It happenned when
> I was looking at the procmailrc(5) page, and wanted to follow the
> regexp(5) link. At that moment, emacs stopped responding. The
> regexp(5) page doesn't exist on my system.

With a fresh CVS update (of this afternoon), it no longer happens. I
don't see the ChangeLog entry that would have fixed this bug. If I read
`cvs log woman.el` correctly, the last change seems to be :

> revision 1.70
> date: 2008-04-11 02:30:24 +0000;  author: cyd;  state: Exp;  lines: +1 -1;  commitid: t1JbOdImtMiRsDYs;
> (woman2-TH): Undo last change.  Use string-equal instead of
> string-match.

which is older than the version of CVS in which I saw the bug. Anyway...

Now, a link to regexp(5) displays the man page of regexp(n) (I didn't
notice that this page existed on my system...). More generally, WoMan
seems not to use the section of the man page when following a link. To
reproduce this behaviour, load man(1), and follow the groff(1) link.
WoMan then asks whether it should display groff(1) or groff(7). Now,
this one is only a minor annoyance.

-- 
Fred

bug#414: Still present in 25.1.50.1

[Fran Burstall]

This link issue is still present in 25.1.50.1.

---Fran Burstall

bug#414: following links to numbered man pages in woman

[Lars Ingebrigtsen]

Frédéric Perrin <frederic.perrin@resel.fr> writes:

>> Starting with a fresh checkout of the emacs source tree, Woman hangs
>> when following some links to non-existent man pages. It happenned when
>> I was looking at the procmailrc(5) page, and wanted to follow the
>> regexp(5) link. At that moment, emacs stopped responding. The
>> regexp(5) page doesn't exist on my system.

This is now finally fixed in Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no