bug#68913: [PATCH] Fix browse-url-url-at-point so that scheme does not duplicate

[Kenta USAMI <zonuexe@zonu.me>]

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

I'm using Emacs 29.2 on macOS.
GNU Emacs 29.2 (build 2, aarch64-apple-darwin23.3.0, NS appkit-2487.40
Version 14.3 (Build 23D56))
 of 2024-01-26

This problem is most noticeable when using markdown-mode and
goto-address-mode,
but it also seems to occur even if goto-address-mode is disabled in
text-mode or fundamental-mode.

You can see the problem by evaluating the Lisp code below.

;;; foo.el
(require 'ert)
(require 'browse-url)

(ert-deftest test-browse-url-url-at-point ()
  (let* ((text "
[![Emacs](
https://www.gnu.org/software/emacs/images/emacs.png)](https://www.gnu.org/software/emacs/download.html
)
")
         (expected "https://www.gnu.org/software/emacs/download.html")
         (actual (with-temp-buffer
                   (insert text)
                   (goto-char 76)
                   (browse-url-url-at-point))))
    (should (string= expected actual))))

Evaluate the expression directly in the buffer or save it to a file and
check it with the command below.

$ emacs --batch -l foo.el -f ert-run-tests-batch-and-exit

2024年2月4日(日) 4:49 Eli Zaretskii <eliz@gnu.org>:

> > From: Kenta USAMI <zonuexe@zonu.me>
> > Date: Sun, 4 Feb 2024 04:17:29 +0900
> >
> > In the text below, move point to the second half of the URL and
> > execute M-x browse-url-at-point.
> >
> > ```
> > [![Emacs](
> >
> https://www.gnu.org/software/emacs/images/emacs.png)](https://www.gnu.org/software/emacs/download.html
> > )
> > ```
> >
> > Firefox and Chromium-based browsers appear to open the URL "https//
> > www.gnu.org/software/emacs/download.html".
> > It seems that the ":" following https is deleted, but the browser
> actually
> > normalizes
> > the URL with the duplicate scheme "http://https://".
>
> In what version of Emacs did you see that?  And on what OS?
>
> Also, please post a complete recipe: do I type the above into the
> *scratch* buffer, or into some other buffer, and what should be the
> major-mode of that buffer?  Also, is the part inside [...] that
> precedes the URL important for reproducing the problem?
>
> Thanks.
>

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