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

[Michael Welsh Duggan <md5i@cs.cmu.edu>]

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)