Links in WoMan buffer should not call `man'

Links in WoMan buffer should not call `man'

[Reiner Steib]

Hi,

in GNU Emacs 22.0.50.3 (i686-pc-linux-gnu, GTK+ Version 2.8.3) of
2006-08-24 on viandante, following manual links in WoMan buffers
should create new WoMan buffers, not new man buffers.

To reproduce:

- emacs -Q

- M-x woman RET procmailex RET

,----[ *WoMan 5 procmailex* ]
| PROCMAILEX(5) -- 2001/08/04 -- BuGless
| 
| NAME
| 	procmailex - procmail rcfile examples
| 
| SYNOPSIS
| 	$HOME/.procmailrc examples
| 
| DESCRIPTION
| 	For a description of the rcfile format see procmailrc(5).
| [...]
`----

- Move cursor to "procmailrc(5)" and hit RET.

Result: A buffer `*Man 5 procmailrc*' is created in the other window.

Expected result: New WoMan buffer with procmailrc(5) man page should
be created.

Note: Following links from the "See also:" section of `*WoMan 5
procmailex*' in fact open new WoMan buffers, i.e. the expected
behavior.

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

Re: Links in WoMan buffer should not call `man'

[Chong Yidong]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> Hi,
>
> in GNU Emacs 22.0.50.3 (i686-pc-linux-gnu, GTK+ Version 2.8.3) of
> 2006-08-24 on viandante, following manual links in WoMan buffers
> should create new WoMan buffers, not new man buffers.

This hack should fix it.

*** emacs/lisp/woman.el.~1.44.~	2006-04-17 18:12:14.000000000 -0400
--- emacs/lisp/woman.el	2006-08-25 18:12:59.000000000 -0400
***************
*** 1750,1756 ****
    (define-key woman-mode-map [M-mouse-2] 'woman-follow-word)
  
    ;; We don't need to call `man' when we are in `woman-mode'.
!   (define-key woman-mode-map [remap man] 'woman))
  
  (defun woman-follow-word (event)
    "Run WoMan with word under mouse as topic.
--- 1750,1767 ----
    (define-key woman-mode-map [M-mouse-2] 'woman-follow-word)
  
    ;; We don't need to call `man' when we are in `woman-mode'.
!   (define-key woman-mode-map [remap man] 'woman)
!   (define-key woman-mode-map [remap man-follow] 'woman-follow))
! 
! (defun woman-follow (topic)
!   "Get a Un*x manual page of the item under point and put it in a buffer."
!   (interactive (list (Man-default-man-entry)))
!   (if (or (not topic)
! 	  (string= topic ""))
!       (error "No item under point")
!     (woman (if (string-match Man-reference-regexp topic)
! 	       (substring topic 0 (match-end 1))
! 	     topic))))
  
  (defun woman-follow-word (event)
    "Run WoMan with word under mouse as topic.

Re: Links in WoMan buffer should not call `man'

[Reiner Steib]

On Sat, Aug 26 2006, Chong Yidong wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>> in GNU Emacs 22.0.50.3 (i686-pc-linux-gnu, GTK+ Version 2.8.3) of
>> 2006-08-24 on viandante, following manual links in WoMan buffers
>> should create new WoMan buffers, not new man buffers.
>
> This hack should fix it.

Thanks it does fix it for me.  Will you install it?

[...]
>     ;; We don't need to call `man' when we are in `woman-mode'.
> !   (define-key woman-mode-map [remap man] 'woman)
> !   (define-key woman-mode-map [remap man-follow] 'woman-follow))
> ! 
> ! (defun woman-follow (topic)
> !   "Get a Un*x manual page of the item under point and put it in a buffer."

Maybe we should add something like "This function is a replacement of
`man-follow' in WoMan mode." in the doc string.

> !   (interactive (list (Man-default-man-entry)))
> !   (if (or (not topic)
> ! 	  (string= topic ""))
> !       (error "No item under point")
> !     (woman (if (string-match Man-reference-regexp topic)
> ! 	       (substring topic 0 (match-end 1))
> ! 	     topic))))

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

Re: Links in WoMan buffer should not call `man'

[Chong Yidong]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> On Sat, Aug 26 2006, Chong Yidong wrote:
>
>> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>>> in GNU Emacs 22.0.50.3 (i686-pc-linux-gnu, GTK+ Version 2.8.3) of
>>> 2006-08-24 on viandante, following manual links in WoMan buffers
>>> should create new WoMan buffers, not new man buffers.
>>
>> This hack should fix it.
>
> Thanks it does fix it for me.  Will you install it?

Done.

Re: Links in WoMan buffer should not call `man'

[Juri Linkov]

> in GNU Emacs 22.0.50.3 (i686-pc-linux-gnu, GTK+ Version 2.8.3) of
> 2006-08-24 on viandante, following manual links in WoMan buffers
> should create new WoMan buffers, not new man buffers.

BTW, I have the desire to marry man and woman so they would share the
common history.  Is this a good idea?

I.e. M-p typed after either `M-x man' or `M-x woman' would insert
the same history items into the minibuffer.  Currently, woman
uses the history list `woman-topic-history', and man uses the
default history list (via the nil history arg of `read-string').

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Links in WoMan buffer should not call `man'

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Sun, 27 Aug 2006 23:12:15 +0300
> 
> BTW, I have the desire to marry man and woman so they would share the
> common history.  Is this a good idea?

After the release, maybe.  Not now, please.

Re: Links in WoMan buffer should not call `man'

[Richard Stallman]

    BTW, I have the desire to marry man and woman so they would share the
    common history.  Is this a good idea?

It isn't necessary for them to get married; they just have to
interchange internal information between their bodies ;-).

I think this is a bug fix.  Please make it happen.

Re: Links in WoMan buffer should not call `man'

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Mon, 28 Aug 2006 18:09:50 -0400
> Cc: emacs-devel@gnu.org
> 
>     BTW, I have the desire to marry man and woman so they would share the
>     common history.  Is this a good idea?
> 
> It isn't necessary for them to get married; they just have to
> interchange internal information between their bodies ;-).
> 
> I think this is a bug fix.  Please make it happen.

If mean to unite man.el with woman.el, please consult the woman.el
maintainer before you do.  He might have something to say about that.

Re: Links in WoMan buffer should not call `man'

[Juri Linkov]

>>     BTW, I have the desire to marry man and woman so they would share the
>>     common history.  Is this a good idea?
>>
>> It isn't necessary for them to get married; they just have to
>> interchange internal information between their bodies ;-).
>>
>> I think this is a bug fix.  Please make it happen.
>
> If mean to unite man.el with woman.el, please consult the woman.el
> maintainer before you do.  He might have something to say about that.

We could leave woman unaware about this change by changing her defvar
to (defvaralias 'woman-topic-history 'man-topic-history), where
man-topic-history could be declared in man.el as
(defvar Man-topic-history nil "Topic read history."),
i.e. let woman to be based on part of man.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Links in WoMan buffer should not call `man'

[Juri Linkov]

>     BTW, I have the desire to marry man and woman so they would share the
>     common history.  Is this a good idea?
>
> It isn't necessary for them to get married; they just have to
> interchange internal information between their bodies ;-).
>
> I think this is a bug fix.  Please make it happen.

While testing this change, I discovered one strange old bug (I can
reproduce it at least in the last year's CVS check-out, but not
in CVS check-out of two years ago).  man fails in woman's frame.
Test case:

M-x man RET man RET      ;; creates a new window in the same frame
M-x woman RET man RET    ;; creates a new dedicated frame
q                        ;; deletes the buffer, but leaves the frame
M-x man RET man RET

the last command typed in the woman's dedicated frame fails with the error
signalled by string-match:

  Man-translate-references: Wrong type argument: arrayp, nil

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Links in WoMan buffer should not call `man'

[Richard Stallman]

    the last command typed in the woman's dedicated frame fails with the error
    signalled by string-match:

      Man-translate-references: Wrong type argument: arrayp, nil

How about debugging it?  This sounds like something straightforward to
debug.

Re: Links in WoMan buffer should not call `man'

[Juri Linkov]

>     the last command typed in the woman's dedicated frame fails with the error
>     signalled by string-match:
>
>       Man-translate-references: Wrong type argument: arrayp, nil
>
> How about debugging it?  This sounds like something straightforward
> to debug.

I narrowed it to the simplest case.  This error occurs only when `M-x man'
is executed in the *Messages* buffer.  (The shortest key sequence to
reproduce it: `C-h e M-x man RET man RET')

Putting the gdb breakpoint on `wrong_type_argument' gives the following bt:

#0  wrong_type_argument (predicate=137953905, value=137897977) at data.c:121
#1  0x0818d95c in Faref (array=137897977, idx=17768) at data.c:2082
#2  0x081ae982 in char_table_translate (table=137897977, ch=2221) at fns.c:2789
#3  0x0817129f in set_image_of_range_1 (work_area=0xbfcfa4b4, start=2221, end=2221, translate=137923116) at regex.c:2132
#4  0x08171a55 in set_image_of_range (work_area=0xbfcfa4b4, start=2221, end=2221, translate=137923116) at regex.c:2262
#5  0x08174968 in regex_compile (pattern=0x8927b78 "^\\([-a-zA-Z0-9_\201\255+][-a-zA-Z0-9_.:\201\255+]*\\)(\\([0-9][a-zA-Z+]*\\|[LNln]\\))$", size=70, syntax=3408388, 
    bufp=0x8373c4c) at regex.c:2973
#6  0x08181f70 in re_compile_pattern (pattern=0x8927b78 "^\\([-a-zA-Z0-9_\201\255+][-a-zA-Z0-9_.:\201\255+]*\\)(\\([0-9][a-zA-Z+]*\\|[LNln]\\))$", length=70, 
    bufp=0x8373c4c) at regex.c:6165
#7  0x08168751 in compile_pattern_1 (cp=0x8373c40, pattern=141439291, translate=137923116, regp=0x836ace8, posix=0, multibyte=1) at search.c:173
#8  0x08168976 in compile_pattern (pattern=141439291, regp=0x836ace8, translate=137923116, posix=0, multibyte=1) at search.c:248
#9  0x08168f21 in string_match_1 (regexp=141439291, string=141439307, start=137897977, posix=0) at search.c:400
#10 0x081690b3 in Fstring_match (regexp=141439291, string=141439307, start=137897977) at search.c:443
(gdb) fr 3
#3  0x0817129f in set_image_of_range_1 (work_area=0xbfcfa4b4, start=2221, end=2221, translate=137923116) at regex.c:2132
2132          int eqv = RE_TRANSLATE (eqv_table, start);
(gdb) xprintsym eqv_table
"nil"

i.e. eqv_table in the *Messages* buffer is nil.

I have no idea why it should be nil in the *Messages* buffer,
but `Man-translate-references' fails when it tries to run
`string-match' in this buffer.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Links in WoMan buffer should not call `man'

[Michael Welsh Duggan]

Juri Linkov <juri@jurta.org> writes:

>>     the last command typed in the woman's dedicated frame fails with the error
>>     signalled by string-match:
>>
>>       Man-translate-references: Wrong type argument: arrayp, nil
>>
>> How about debugging it?  This sounds like something straightforward
>> to debug.
>
> I narrowed it to the simplest case.  This error occurs only when `M-x man'
> is executed in the *Messages* buffer.  (The shortest key sequence to
> reproduce it: `C-h e M-x man RET man RET')

I don't know what the correct fix for the underlying problem is (i.e.,
the fact that this doesn't error out in other contexts), but the
problem can be solved by fixing the Man-name-regexp, which is currenly
invalid.  The following is a patch for that.

Index: man.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/man.el,v
retrieving revision 1.164
diff -u -p -r1.164 man.el
--- man.el	2 Sep 2006 23:28:55 -0000	1.164
+++ man.el	5 Sep 2006 03:37:31 -0000
@@ -259,7 +259,7 @@ the associated section number."
 (defvar Man-cooked-hook nil
   "Hook run after removing backspaces but before `Man-mode' processing.")
 
-(defvar Man-name-regexp "[-a-zA-Z0-9_­+][-a-zA-Z0-9_.:­+]*"
+(defvar Man-name-regexp "[-a-zA-Z0-9_+][-a-zA-Z0-9_.:+]*"
   "Regular expression describing the name of a manpage (without section).")
 
 (defvar Man-section-regexp "[0-9][a-zA-Z0-9+]*\\|[LNln]"


-- 
Michael Welsh Duggan
(md5i@cs.cmu.edu)

Re: Links in WoMan buffer should not call `man'

[Michael Welsh Duggan]

Michael Welsh Duggan <md5i@cs.cmu.edu> writes:

> Juri Linkov <juri@jurta.org> writes:
>
>>>     the last command typed in the woman's dedicated frame fails with the error
>>>     signalled by string-match:
>>>
>>>       Man-translate-references: Wrong type argument: arrayp, nil
>>>
>>> How about debugging it?  This sounds like something straightforward
>>> to debug.
>>
>> I narrowed it to the simplest case.  This error occurs only when `M-x man'
>> is executed in the *Messages* buffer.  (The shortest key sequence to
>> reproduce it: `C-h e M-x man RET man RET')
>
> I don't know what the correct fix for the underlying problem is (i.e.,
> the fact that this doesn't error out in other contexts), but the
> problem can be solved by fixing the Man-name-regexp, which is currenly
> invalid.  The following is a patch for that.

I take my original statement back.  The character I removed was not a
hyphen as I expected, but rather a soft-hyphen (U+00AD).  On the other
hand, the fact that removing this character fixed the problem might
narrow down the problem a bit more.  I will now look into this a bit
more deeply.

-- 
Michael Welsh Duggan
(md5i@cs.cmu.edu)

Re: Links in WoMan buffer should not call `man'

[Michael Welsh Duggan]

Michael Welsh Duggan <md5i@cs.cmu.edu> writes:

> Michael Welsh Duggan <md5i@cs.cmu.edu> writes:
>
>> Juri Linkov <juri@jurta.org> writes:
>>
>>>>     the last command typed in the woman's dedicated frame fails with the error
>>>>     signalled by string-match:
>>>>
>>>>       Man-translate-references: Wrong type argument: arrayp, nil
>>>>
>>>> How about debugging it?  This sounds like something straightforward
>>>> to debug.
>>>
>>> I narrowed it to the simplest case.  This error occurs only when `M-x man'
>>> is executed in the *Messages* buffer.  (The shortest key sequence to
>>> reproduce it: `C-h e M-x man RET man RET')
>>
>> I don't know what the correct fix for the underlying problem is (i.e.,
>> the fact that this doesn't error out in other contexts), but the
>> problem can be solved by fixing the Man-name-regexp, which is currenly
>> invalid.  The following is a patch for that.
>
> I take my original statement back.  The character I removed was not a
> hyphen as I expected, but rather a soft-hyphen (U+00AD).  On the other
> hand, the fact that removing this character fixed the problem might
> narrow down the problem a bit more.  I will now look into this a bit
> more deeply.

Some time later, I am realizing that string_match_1 is using
current_buffer's case table.  Since the string being matched against
might have nothing to do with the current buffer, this seems
incorrect.  Is this a red herring?

-- 
Michael Welsh Duggan
(md5i@cs.cmu.edu)

Re: Links in WoMan buffer should not call `man'

[Michael Welsh Duggan]

Michael Welsh Duggan <md5i@cs.cmu.edu> writes:

> Michael Welsh Duggan <md5i@cs.cmu.edu> writes:
>
>> Michael Welsh Duggan <md5i@cs.cmu.edu> writes:
>>
>>> Juri Linkov <juri@jurta.org> writes:
>>>
>>>>>     the last command typed in the woman's dedicated frame fails with the error
>>>>>     signalled by string-match:
>>>>>
>>>>>       Man-translate-references: Wrong type argument: arrayp, nil
>>>>>
>>>>> How about debugging it?  This sounds like something straightforward
>>>>> to debug.
>>>>
>>>> I narrowed it to the simplest case.  This error occurs only when `M-x man'
>>>> is executed in the *Messages* buffer.  (The shortest key sequence to
>>>> reproduce it: `C-h e M-x man RET man RET')
>>>
>>> I don't know what the correct fix for the underlying problem is (i.e.,
>>> the fact that this doesn't error out in other contexts), but the
>>> problem can be solved by fixing the Man-name-regexp, which is currenly
>>> invalid.  The following is a patch for that.
>>
>> I take my original statement back.  The character I removed was not a
>> hyphen as I expected, but rather a soft-hyphen (U+00AD).  On the other
>> hand, the fact that removing this character fixed the problem might
>> narrow down the problem a bit more.  I will now look into this a bit
>> more deeply.
>
> Some time later, I am realizing that string_match_1 is using
> current_buffer's case table.  Since the string being matched against
> might have nothing to do with the current buffer, this seems
> incorrect.  Is this a red herring?

More data:  The *Message* buffer at dump time has a case_canon_table
with three extra slots, all nil.

(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/local/src/emacs/src/emacs -Q
[Thread debugging using libthread_db enabled]
[New Thread -1213884736 (LWP 28342)]
[Switching to Thread -1213884736 (LWP 28342)]

Breakpoint 10, main (argc=2, argv=0xbf884c74) at emacs.c:843
(gdb) p Vbuffer_alist
$65 = 137906437
(gdb) xcdr
$66 = 0x8384a85
(gdb) xcdr
$67 = 0x8382d55
(gdb) xcar
$68 = 0x8382d4d
(gdb) xcdr
$69 = 0x83beb1c
(gdb) xbuffer
$70 = (struct buffer *) 0x83beb18
(unsigned char *) 0x8389220 "*Messages*"
(gdb) p $70->case_canon_table
$71 = 137940012
(gdb) xchartable
$72 = (struct Lisp_Char_Table *) 0x838cc28
Purpose: "case-table"  3 extra slots
(gdb) p $72->extras[0]
$73 = 137914569
(gdb) pr
nil
(gdb) p $72->extras[1]
$74 = 137914569
(gdb) pr
nil
(gdb) p $72->extras[2]
$75 = 137914569
(gdb) pr
nil

On buffer creation, the buffers case_canon_table gets a
copy of Vascii_downcase_table's second extra slot, which matches (the
first two of this slot's extra elements are also nil).

(gdb) p Vascii_downcase_table
$76 = 137938404
(gdb) xchartable
$77 = (struct Lisp_Char_Table *) 0x838c5e0
Purpose: "case-table"  3 extra slots
(gdb) p $77->extras[1]
$79 = 139808316
(gdb) xchartable 
$80 = (struct Lisp_Char_Table *) 0x8554e38
Purpose: "case-table"  3 extra slots
(gdb) p $80->extras[0]
$85 = 137914569
(gdb) pr
nil
(gdb) p $80->extras[1]
$86 = 137914569
(gdb) pr
nil

I am still trying to figure out what all this means.  Hopefully, this
analysis is useful to someone else.

-- 
Michael Welsh Duggan
(md5i@cs.cmu.edu)

Re: Links in WoMan buffer should not call `man'

[Chong Yidong]

Michael Welsh Duggan <md5i@cs.cmu.edu> writes:

>> Some time later, I am realizing that string_match_1 is using
>> current_buffer's case table.  Since the string being matched against
>> might have nothing to do with the current buffer, this seems
>> incorrect.  Is this a red herring?
>
> More data:  The *Message* buffer at dump time has a case_canon_table
> with three extra slots, all nil.

This patch removes the bug, and is probably the correct thing to do.
Any objections to my installing it?

*** emacs/src/regex.c.~1.211.~	2006-02-21 14:36:47.000000000 -0500
--- emacs/src/regex.c	2006-09-05 16:53:54.000000000 -0400
***************
*** 2162,2168 ****
  
    Lisp_Object eqv_table;
  
!   if (!RE_TRANSLATE_P (translate))
      {
        EXTEND_RANGE_TABLE (work_area, 2);
        work_area->table[work_area->used++] = (start);
--- 2162,2170 ----
  
    Lisp_Object eqv_table;
  
!   if (!RE_TRANSLATE_P (translate)
!       || (eqv_table = XCHAR_TABLE (translate)->extras[2],
! 	  NILP (eqv_table)))
      {
        EXTEND_RANGE_TABLE (work_area, 2);
        work_area->table[work_area->used++] = (start);
***************
*** 2170,2177 ****
        return -1;
      }
  
-   eqv_table = XCHAR_TABLE (translate)->extras[2];
- 
    for (; start <= end; start++)
      {
        enum case_type this_type;
--- 2172,2177 ----

Re: Links in WoMan buffer should not call `man'

[Richard Stallman]

    This patch removes the bug, and is probably the correct thing to do.
    Any objections to my installing it?

I wrote another fix for this.  I will compare yours with mine when I
have time.

Re: Links in WoMan buffer should not call `man'

[Richard Stallman]

    This patch removes the bug, and is probably the correct thing to do.
    Any objections to my installing it?

I think your patch is not in fact correct.  TRANSLATE in this case IS
the eqv_table, and should be used as such, not disregarded.

I'll install my patch.

Re: Links in WoMan buffer should not call `man'

[Richard Stallman]

    Some time later, I am realizing that string_match_1 is using
    current_buffer's case table.  Since the string being matched against
    might have nothing to do with the current buffer, this seems
    incorrect.  Is this a red herring?

I think it is not the main problem here.

You are right that it is unclean in principle to use the buffer's case
table; but it makes no difference in practice.

Re: Links in WoMan buffer should not call `man'

[Richard Stallman]

I wrote a fix, which I'll install when I have a good chance.