bug#74792: 29.2.50; goto-address-mode should support RET in special-mode buffers

bug#74792: 29.2.50; goto-address-mode should support RET in special-mode buffers

[Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors]

goto-address-mode binds C-c RET to goto-address-at-point when point is
on a URL or email address.  In special-mode buffers (or maybe any
read-only buffer?) it should also bind RET while point is on the URL or
email address.

This would improve functionality for packages which create special-mode
buffers showing arbitrary text that may contain URLs.

For example, commit messages may contain URLs, and enabling
goto-message-mode in vc-log buffers highlights those URLs, but RET
doesn't work to follow them.  Similarly, magit enables goto-address-mode
in buffers showing a commit message, but it implements separate handling
for RET on URLs since goto-address-mode doesn't provide that as a
binding.

This could be done with an extended-menu-item binding with a filter
which checks (derived-mode-p 'special-mode), but maybe there's a better
way?

bug#74792: 29.2.50; goto-address-mode should support RET in special-mode buffers

[Eli Zaretskii]

> Cc: dmitry@gutov.dev
> Date: Wed, 11 Dec 2024 11:10:53 -0500
> From:  Spencer Baugh via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 
> goto-address-mode binds C-c RET to goto-address-at-point when point is
> on a URL or email address.  In special-mode buffers (or maybe any
> read-only buffer?) it should also bind RET while point is on the URL or
> email address.

I don't think it's a good idea, since many special-mode descendants
bind RET to useful commands.  For goto-address-at-point to override
that would be a nuisance, I think.

bug#74792: 29.2.50; goto-address-mode should support RET in special-mode buffers

[Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

On Wed, Dec 11, 2024, 12:09 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > Cc: dmitry@gutov.dev
> > Date: Wed, 11 Dec 2024 11:10:53 -0500
> > From:  Spencer Baugh via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> >
> >
> > goto-address-mode binds C-c RET to goto-address-at-point when point is
> > on a URL or email address.  In special-mode buffers (or maybe any
> > read-only buffer?) it should also bind RET while point is on the URL or
> > email address.
>
> I don't think it's a good idea, since many special-mode descendants
> bind RET to useful commands.  For goto-address-at-point to override
> that would be a nuisance, I think.
>

True, but when I've specifically moved point to a URL it is usually because
I want to follow the URL, not do whatever is bound to RET in the mode.

But this sounds like something that may differ between users, so perhaps we
could add this controlled by a defcustom?

>

[-- Attachment #2: Type: text/html, Size: 1776 bytes --]

bug#74792: 29.2.50; goto-address-mode should support RET in special-mode buffers

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Wed, 11 Dec 2024 12:39:59 -0500
> Cc: 74792@debbugs.gnu.org, Dmitry Gutov <dmitry@gutov.dev>
> 
> On Wed, Dec 11, 2024, 12:09 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
>  > Cc: dmitry@gutov.dev
>  > Date: Wed, 11 Dec 2024 11:10:53 -0500
>  > From:  Spencer Baugh via "Bug reports for GNU Emacs,
>  >  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>  > 
>  > 
>  > goto-address-mode binds C-c RET to goto-address-at-point when point is
>  > on a URL or email address.  In special-mode buffers (or maybe any
>  > read-only buffer?) it should also bind RET while point is on the URL or
>  > email address.
> 
>  I don't think it's a good idea, since many special-mode descendants
>  bind RET to useful commands.  For goto-address-at-point to override
>  that would be a nuisance, I think.
> 
> True, but when I've specifically moved point to a URL it is usually because I want to follow the URL, not do
> whatever is bound to RET in the mode.

You cannot know that.  E.g., point could be on a URL by chance, for
example, if a buffer starts with a URL.

> But this sounds like something that may differ between users, so perhaps we could add this controlled by a
> defcustom?

Let's first hear that enough people here think that it might sometimes
be a good thing.  If so, then yes, a user option, by default off,
could be a way to introduce such behavior.

bug#74792: 29.2.50; goto-address-mode should support RET in special-mode buffers

[Juri Linkov]

>>  > goto-address-mode binds C-c RET to goto-address-at-point when point is
>>  > on a URL or email address.  In special-mode buffers (or maybe any
>>  > read-only buffer?) it should also bind RET while point is on the URL or
>>  > email address.
>> 
>>  I don't think it's a good idea, since many special-mode descendants
>>  bind RET to useful commands.  For goto-address-at-point to override
>>  that would be a nuisance, I think.
>> 
>> True, but when I've specifically moved point to a URL it is usually because I want to follow the URL, not do
>> whatever is bound to RET in the mode.
>
> You cannot know that.  E.g., point could be on a URL by chance, for
> example, if a buffer starts with a URL.
>
>> But this sounds like something that may differ between users, so perhaps we could add this controlled by a
>> defcustom?
>
> Let's first hear that enough people here think that it might sometimes
> be a good thing.  If so, then yes, a user option, by default off,
> could be a way to introduce such behavior.

Typing just RET would be more intuitive, but indeed there is a problem
that e.g. 'C-h C-t RET RET RET ...' will scroll lines one by one
until this line becomes current:

  https://www.gnu.org/licenses/why-assign.html

Then RET will surprisingly visit that URL.

Unfortunately, an option can't help because most users might want to
enable it, but only if it doesn't misfire in unexpected situations.

bug#74792: 29.2.50; goto-address-mode should support RET in special-mode buffers

[Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Juri Linkov <juri@linkov.net> writes:

>>>  > goto-address-mode binds C-c RET to goto-address-at-point when point is
>>>  > on a URL or email address.  In special-mode buffers (or maybe any
>>>  > read-only buffer?) it should also bind RET while point is on the URL or
>>>  > email address.
>>> 
>>>  I don't think it's a good idea, since many special-mode descendants
>>>  bind RET to useful commands.  For goto-address-at-point to override
>>>  that would be a nuisance, I think.
>>> 
>>> True, but when I've specifically moved point to a URL it is usually because I want to follow the URL, not do
>>> whatever is bound to RET in the mode.
>>
>> You cannot know that.  E.g., point could be on a URL by chance, for
>> example, if a buffer starts with a URL.
>>
>>> But this sounds like something that may differ between users, so perhaps we could add this controlled by a
>>> defcustom?
>>
>> Let's first hear that enough people here think that it might sometimes
>> be a good thing.  If so, then yes, a user option, by default off,
>> could be a way to introduce such behavior.
>
> Typing just RET would be more intuitive, but indeed there is a problem
> that e.g. 'C-h C-t RET RET RET ...' will scroll lines one by one
> until this line becomes current:
>
>   https://www.gnu.org/licenses/why-assign.html
>
> Then RET will surprisingly visit that URL.
>
> Unfortunately, an option can't help because most users might want to
> enable it, but only if it doesn't misfire in unexpected situations.

True.  Perhaps it should be enabled buffer-locally, then.  Then a user
can set it in a major-mode hook - and if a major-mode does not bind RET
to something else, the major-mode can just enable it.

bug#74792: 29.2.50; goto-address-mode should support RET in special-mode buffers

[Juri Linkov]

>> Typing just RET would be more intuitive, but indeed there is a problem
>> that e.g. 'C-h C-t RET RET RET ...' will scroll lines one by one
>> until this line becomes current:
>>
>>   https://www.gnu.org/licenses/why-assign.html
>>
>> Then RET will surprisingly visit that URL.
>>
>> Unfortunately, an option can't help because most users might want to
>> enable it, but only if it doesn't misfire in unexpected situations.
>
> True.  Perhaps it should be enabled buffer-locally, then.  Then a user
> can set it in a major-mode hook - and if a major-mode does not bind RET
> to something else, the major-mode can just enable it.

This means disabling RET on links in etc/TODO and all other
link-rich files that use 'view-help-file':

(defun describe-distribution ()
  "Display info on how to obtain the latest version of GNU Emacs."
  (interactive)
  (view-help-file "DISTRIB"))

(defun describe-copying ()
  "Display info on how you may redistribute copies of GNU Emacs."
  (interactive)
  (view-help-file "COPYING"))

(defun view-emacs-problems ()
  "Display info on known problems with Emacs and possible workarounds."
  (interactive)
  (view-help-file "PROBLEMS"))

(defun view-emacs-debugging ()
  "Display info on how to debug Emacs problems."
  (interactive)
  (view-help-file "DEBUG"))

For a long time I had been using RET to scroll by one line in Info:

  (define-key Info-mode-map [return]
    (lambda ()
      (interactive)
      (if nil ;; TODO: add predicate to check if point is on Info refs
          (Info-follow-nearest-node)
        (View-scroll-line-forward))))

But still can't find a predicate that would prevent RET from visiting
a reference only when the cursor moves to it while scrolling.
And don't believe this is possible.  So need to use other
less intuitive keys to visit links.

bug#74792: 29.2.50; goto-address-mode should support RET in special-mode buffers

[Juri Linkov]

> For a long time I had been using RET to scroll by one line in Info:
>
>   (define-key Info-mode-map [return]
>     (lambda ()
>       (interactive)
>       (if nil ;; TODO: add predicate to check if point is on Info refs
>           (Info-follow-nearest-node)
>         (View-scroll-line-forward))))
>
> But still can't find a predicate that would prevent RET from visiting
> a reference only when the cursor moves to it while scrolling.
> And don't believe this is possible.  So need to use other
> less intuitive keys to visit links.

I forgot about other futile attempts to find a suitable heuristic:

  (define-key gnus-article-mode-map [return] 'my-gnus-article-press-or-scroll)
  (defun my-gnus-article-press-or-scroll ()
    (interactive)
    ;; When point is at the bottom of the window while scrolling
    (if (eq (point) (save-excursion (move-to-window-line -1) (point)))
        (View-scroll-line-forward)
      (gnus-article-press-button)))

Here the button is pressed when point is not at the bottom,
because point moves to the bottom while scrolling.
But in `emacs -Q` I see that point remains at the top
while scrolling.  So this behavior depends on customization.

bug#74792: 29.2.50; goto-address-mode should support RET in special-mode buffers

[Dmitry Gutov]

On 11/12/2024 20:55, Eli Zaretskii wrote:

>>   > goto-address-mode binds C-c RET to goto-address-at-point when point is
>>   > on a URL or email address.  In special-mode buffers (or maybe any
>>   > read-only buffer?) it should also bind RET while point is on the URL or
>>   > email address.
>>
>>   I don't think it's a good idea, since many special-mode descendants
>>   bind RET to useful commands.  For goto-address-at-point to override
>>   that would be a nuisance, I think.
>>
>> True, but when I've specifically moved point to a URL it is usually because I want to follow the URL, not do
>> whatever is bound to RET in the mode.
> 
> You cannot know that.  E.g., point could be on a URL by chance, for
> example, if a buffer starts with a URL.

I also regularly try RET in such cases, notice it does not work, and 
then have to reach for the mouse. Just not often enough to look up and 
remember the alternative.

>> But this sounds like something that may differ between users, so perhaps we could add this controlled by a
>> defcustom?
> 
> Let's first hear that enough people here think that it might sometimes
> be a good thing.  If so, then yes, a user option, by default off,
> could be a way to introduce such behavior.

The same option could affect other "C-c RET" bindings as well, such as 
browse-url-button-open in ansi-osc-hyperlink-map and 
bug-reference-push-button in bug-reference-map.