Why is goto-address-mode not enabled by default everywhere?

Why is goto-address-mode not enabled by default everywhere?

[emacsq]

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

Is there some drawback?

Seems logical and handy that if there is a url in a buffer then it's clickable, so the user can visit it easily.

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

Re: Why is goto-address-mode not enabled by default everywhere?

[Po Lu]

emacsq <laszlomail@protonmail.com> writes:

> Is there some drawback?

Because that's not what most people expect in buffers visiting plain
text, or even code.  For example, you would certainly not want to click
the "URL" in this:

  sprintf (buf, "https://example.com/colors.php?color=%02x%02x%02x", ...

Re: Why is goto-address-mode not enabled by default everywhere?

[emacsq]

> emacsq laszlomail@protonmail.com writes:
>
> Because that's not what most people expect in buffers visiting plain
> text, or even code. For example, you would certainly not want to click
> the "URL" in this:
>
> sprintf (buf, "https://example.com/colors.php?color=\x02x\x02x\x02x", ...

I have code where there are urls in comments and it's very convenient to visit those urls with a click or enter.

Maybe goto address mode shoud be smarter and in programming modes it should only enable links in comments?

Re: Why is goto-address-mode not enabled by default everywhere?

[Po Lu]

emacsq <laszlomail@protonmail.com> writes:

> I have code where there are urls in comments and it's very convenient
> to visit those urls with a click or enter.

Why not enable `goto-address-mode' as a file or directory-local variable
in those files instead?

Re: Why is goto-address-mode not enabled by default everywhere?

[emacsq]

>
> > I have code where there are urls in comments and it's very convenient
> > to visit those urls with a click or enter.
>
> Why not enable `goto-address-mode' as a file or directory-local variable
> in those files instead?

Is there a problem with making urls in comments clickable by default? It's just useful to conveniently visit some documentation url.

Re: Why is goto-address-mode not enabled by default everywhere?

[Andreas Schwab]

On Apr 17 2022, emacsq wrote:

> Is there a problem with making urls in comments clickable by default? It's just useful to conveniently visit some documentation url.

It is still picked up by thing-at-point regardless.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Why is goto-address-mode not enabled by default everywhere?

[Philipp Stephani]

> Am 17.04.2022 um 11:35 schrieb emacsq <laszlomail@protonmail.com>:
> 
> 
> 
> 
> 
>> 
>>> I have code where there are urls in comments and it's very convenient
>>> to visit those urls with a click or enter.
>> 
>> Why not enable `goto-address-mode' as a file or directory-local variable
>> in those files instead?
> 
> Is there a problem with making urls in comments clickable by default? It's just useful to conveniently visit some documentation url.
> 

It interferes with moving point using the mouse, which might be too intrusive.  Maybe we could enable goto-address-prog-mode by default, but in turn disable mouse-1-click-follows-link, so that the user would need to use mouse-2 instead.

RE: [External] : Re: Why is goto-address-mode not enabled by default everywhere?

[Drew Adams]

> > Is there a problem with making urls in comments clickable by default?
> > It's just useful to conveniently visit some documentation url.
> 
> It interferes with moving point using the mouse, which might be too
> intrusive.  Maybe we could enable goto-address-prog-mode by default,
> but in turn disable mouse-1-click-follows-link, so that the user would
> need to use mouse-2 instead.

(I'm not arguing for or against linkifying URLs
in text by default, here.)

IMHO, we never should have let
`mouse-1-click-follows-link' default to non-nil.

We should have kept just `mouse-2' for following
links in Emacs, by default.  `mouse-1' in most
Emacs contexts should be for setting point etc.
- and not only by holding it for some period of
time before releasing it.

That's an ugly hack that affects user behavior,
even if experience Emacsers have by now become
habituated to it.  It makes using `mouse-1' in
Dired and similar buffers with large expanses
of links almost unusable.

We should now reverse the default behavior.
`mouse-2' is a much saner choice for Emacs.

AFAIK, the only reason we switched to letting
`mouse-1' follow links by default was because
that's the behavior in other apps, in particular
web browsers.  Those contexts are quite unlike
most Emacs contexts, which are about moving
around plain text, and often even editing it.

No, don't bother to say "That ship has sailed."
That ship should now be sunk, and a new ship
set to sail - a ship designed for use with
typical Emacs contexts.

Re: Why is goto-address-mode not enabled by default everywhere?

[emacsq]

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

> Because that's not what most people expect in buffers visiting plain
> text, or even code. For example, you would certainly not want to click
> the "URL" in this:
>
> sprintf (buf, "https://example.com/colors.php?color=%02x%02x%02x", ...

BTW, I see no great harm in highlighting this. It indicates that it's an url and helps to see the code constructs an url, and if someone browses C code and sees sprintf then he obviously knows what sprintf does, so he'll know the url won't work without parameter substitution anyway.

If the link is clicked then you get a 404 page for a non existent color, so it's just a broken link, nothing tragic.

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

Re: Why is goto-address-mode not enabled by default everywhere?

[Po Lu]

emacsq <laszlomail@protonmail.com> writes:

> BTW, I see no great harm in highlighting this. It indicates that it's
> an url and helps to see the code constructs an url, and if someone
> browses C code and sees sprintf then he obviously knows what sprintf
> does, so he'll know the url won't work without parameter substitution
> anyway.
>
> If the link is clicked then you get a 404 page for a non existent
> color, so it's just a broken link, nothing tragic.

It is fontified in the link face, which makes the fontification of the
string containing it very confusing.

And why is it necessary to shove this confusing, incorrect semantic
information into the face of the user?