bug#23647: 25.1.50; In man pages, links on hyphenated words don't work

[Stephen Berman <stephen.berman@gmx.net>]

On Sun, 29 May 2016 17:42:13 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Sun, 29 May 2016 11:52:29 +0200
>> 
>> O. emacs -Q
>> 1. Open a man page that has a link on a hyphenated word, e.g. on my
>>    system: M-x man RET signal RET, put point on the word spanning lines
>>    129-130, which is displayed as `sig-
>>    nalfd(2)'.
>> 2. Type RET (or click mouse-1 or mouse-2) on that link.
>> => The error message "Can’t find the 2 sig-nalfd manpage" is displayed.
>> 
>> The following patch makes the link DTRT:
>> 
>> diff --git a/lisp/man.el b/lisp/man.el
>> index 5acf90b..5d4cacc 100644
>> --- a/lisp/man.el
>> +++ b/lisp/man.el
>> @@ -1430,8 +1430,14 @@ Man-bgproc-sentinel
>>  			(quit-restore-window
>>  			 (get-buffer-window (current-buffer) t) 'kill)
>>  		      (kill-buffer (current-buffer)))
>> -		    (message "Can't find the %s manpage"
>> -			     (Man-page-from-arguments args)))
>> +                    ;; Entries hyphenated due to the window width
>> +                    ;; won't be found in the man database, so remove
>> +                    ;; the hyphenation and look again.
>> +		    (if (string-match "-" args)
>
> Is it only the ASCII hyphen/minus, or could there be other characters
> (e.g., if Groff/troff are invoked with some exotic -Tfoo switch)?

That possibility didn't occur to me but according to Wikipedia, groff
also outputs soft hyphens (octal 255) and indeed I see that the function
Man-build-references-alist, which also removes hyphenation (in a more
complicated way that doesn't seem to be needed in the present case),
also takes the soft hyphen into account.  That can be done here too by
changing the above string-match regexp to "[-­]".  If someone knows of
other possibilities allowed by [gt]roff, maybe the regexp could be
further extended, or the condition reformulated as required.  What do
you think?

>> This is a long-standing bug (presumably since commit
>> 162a12b1d7b1e985a8810bad24d068c825286f56 of Sep 13 2007), but although
>> the fix seems safe, I suppose it's too late for emacs-25.  So if there
>> are no objections, should I commit it to master, or is it ok for the
>> upcoming release?
>
> Master, please.

Ok.  I'll wait another day or two in case there's more feedback.
Thanks.

Steve Berman