GNU bug report logs -
#71734
30.0.50; eww interprets make errors as URLs
Previous Next
To reply to this bug, email your comments to 71734 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
larsi <at> gnus.org, bug-gnu-emacs <at> gnu.org
:
bug#71734
; Package
emacs
.
(Sun, 23 Jun 2024 13:13:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Kangas <stefankangas <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
larsi <at> gnus.org, bug-gnu-emacs <at> gnu.org
.
(Sun, 23 Jun 2024 13:13:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
`M-x eww` currently interprets this as a URL:
make: *** [Makefile:240: __sub-make] Error 2
I think this is due to the below commit:
```
commit 4113ac253456027c4b54b92a617e0c2b3003a049
Author: Lars Ingebrigtsen <larsi <at> gnus.org>
Date: Sun Jan 11 15:58:10 2015 +0100
Further eww URL DWIM tweaks
* net/eww.el (eww): Interpret anything that looks like a protocol
designator as a full URL.
diff --git a/lisp/net/eww.el b/lisp/net/eww.el
--- a/lisp/net/eww.el
+++ b/lisp/net/eww.el
@@ -258,29 +258,31 @@
- (if (or (string-match "\\`https?:" url)
+ ;; Anything that starts with something that vaguely looks
+ ;; like a protocol designator is interpreted as a full URL.
+ (if (or (string-match "\\`[A-Za-z]+:" url)
```
I think that this is much too dwim-y, and we should go back to the old
code. But I have no idea why Lars made the above change in the first
place, so I'd like to check here first. If the intention is to support
the various protocols that Emacs supports, then we should look for
exactly those and nothing else.
In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.16.0) of 2024-06-22 built on xxxxx
Repository revision: 014aab9847a0d3d898cb8cbc7224143f2d741abb
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71734
; Package
emacs
.
(Thu, 27 Jun 2024 09:01:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 71734 <at> debbugs.gnu.org (full text, mbox):
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Sun, 23 Jun 2024 06:11:57 -0700
>
> `M-x eww` currently interprets this as a URL:
>
> make: *** [Makefile:240: __sub-make] Error 2
>
> I think this is due to the below commit:
>
> ```
> commit 4113ac253456027c4b54b92a617e0c2b3003a049
> Author: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sun Jan 11 15:58:10 2015 +0100
>
> Further eww URL DWIM tweaks
>
> * net/eww.el (eww): Interpret anything that looks like a protocol
> designator as a full URL.
>
> diff --git a/lisp/net/eww.el b/lisp/net/eww.el
> --- a/lisp/net/eww.el
> +++ b/lisp/net/eww.el
> @@ -258,29 +258,31 @@
> - (if (or (string-match "\\`https?:" url)
> + ;; Anything that starts with something that vaguely looks
> + ;; like a protocol designator is interpreted as a full URL.
> + (if (or (string-match "\\`[A-Za-z]+:" url)
> ```
>
> I think that this is much too dwim-y, and we should go back to the old
> code.
OTOH, expecting "M-x eww" to do something sensible in the above case
is a bit far-fetched, IMHO.
I think the question we should ask ourselves is whether the use cases
fixed by Lars's change are more important to keep supported than
fixing the case above.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71734
; Package
emacs
.
(Fri, 28 Jun 2024 06:06:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 71734 <at> debbugs.gnu.org (full text, mbox):
On 6/23/2024 6:11 AM, Stefan Kangas wrote:
> `M-x eww` currently interprets this as a URL:
>
> make: *** [Makefile:240: __sub-make] Error 2
Interprets it how? I can't seem to reproduce the issue. I tried putting
point on various spots in that line and calling M-x eww, but EWW never
tried to turn anything from that line into the default URL for the
prompt. Maybe I'm just not doing the same thing you did; could you list
the steps to reproduce this?
This bug report was last modified 71 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.