From: Po Lu <luangruo@yahoo.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: tumashu@163.com, larsi@gnus.org, emacs-devel@gnu.org
Subject: Re: Subject: [PATCH] * lisp/xwidget.el (xwidget-webkit-browse-url): Remove space prefix of url.
Date: Sat, 13 Nov 2021 17:34:50 +0800 [thread overview]
Message-ID: <87h7cgo0ud.fsf@yahoo.com> (raw)
In-Reply-To: <83r1bkxzvu.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 13 Nov 2021 09:45:25 +0200")
Eli Zaretskii <eliz@gnu.org> writes:
> Is this a replacement for eww--dwim-expand-url? Or is this in
> addition to it?
It's a replacement for `eww--dwim-expand-url', but in url-utils, because
it is too generally useful to warrant staying internal to eww.
>> (defun url-dwim-expand-url (url local-regex search-prefix)
>> "Canonicalize URL.
> First line of a doc string should mention all the mandatory
> arguments. (But see below.)
>> Try to determine if URL is an incomplete URL or a search query, and
>> return the canonical form of URL.
>> SEARCH-PREFIX is the prefix to be prepended to URL if it is a search query.
> Can the doc string explain what does "search query" mean in this
> context?
>> match is successful, then URL is treated as an address."
> This begs the question: and if it doesn't match, then what? And what
> does "address" mean in this context, i.e. what does "treated as an
> address" means in practice?
>> (cond ((string-match-p "\\`file:/" url))
>> ;; Don't mangle file: URLs at all.
> This comment should be above the line that handles file:// URLs.
> Btw, should other URLs be exempt from "mangling"? AFAIK, there are
> many protocols whose syntax we don't really understand in url*.el
> code, so shouldn't they all be left alone?
This is code I extracted from eww.el; Lars should know the reasoning for
that better.
>> ((string-match-p "\\`ftp://" url)
>> (user-error "FTP is not supported"))
> I can understand this in EWW, but why should FTP be unsupported in
> url-util?
Hmm, makes sense. See below.
>> ;; 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)
> This will match Windows-style d:/foo/bar absolute file names. Is that
> what we want?
No, but in this case eww should have to be fixed too.
>> (and (= (length (split-string url)) 1)
> You are using split-string here to verify that URL has no SPC
> characters?
That's what the original code in eww.el did. I didn't dare change it,
because I didn't know why it was there.
>> (or (and (not (string-match-p "\\`[\"'].*[\"']\\'" url))
>> (> (length (split-string url "[.:]")) 1))
> It would be good to have a comment here explaining what do these
> conditions test.
Lars, do you know what this test is for? Thanks.
>> (string-match local-regex url))))
> This sole use of LOCAL-REGEX hints that maybe it should be an optional
> argument.
>
>> (progn
>> (unless (string-match-p "\\`[a-zA-Z][-a-zA-Z0-9+.]*://" url)
>> (setq url (concat "http://" url)))
>
> "http", not "https"? I think the default nowadays is the latter.
>
>> (setq url (concat search-prefix
>> (mapconcat
>> #'url-hexify-string (split-string url) "+"))))))
>> url)
> Doesn't this part mean a search query is expected to be in some
> specific format? If so, that format should be documented in the doc
> string.
I don't know: Lars, do you know why this is here? Thanks in advance.
> Thanks.
Thanks. Here's a better docstring, but I don't want to change any of
the code until I know precisely what it does.
Canonicalize URL, with SEARCH-PREFIX if URL seems to be a search query.
Try to determine if URL is an address or a query for a search engine,
and return canonicalized URL, with SEARCH-PREFIX prepended before
cannibalisation if it seems to be such a query. Optional argument
LOCAL-REGEX is a regular expression that URL is matched against. If the
match is successful, then URL is treated as an address, and not a search
query.
next prev parent reply other threads:[~2021-11-13 9:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-11 9:36 Subject: [PATCH] * lisp/xwidget.el (xwidget-webkit-browse-url): Remove space prefix of url tumashu
2021-11-11 9:39 ` Po Lu
2021-11-11 10:49 ` tumashu
2021-11-11 10:53 ` Po Lu
2021-11-11 10:53 ` Lars Ingebrigtsen
2021-11-11 11:15 ` Po Lu
2021-11-11 11:58 ` Lars Ingebrigtsen
2021-11-11 12:21 ` Po Lu
2021-11-11 12:25 ` Lars Ingebrigtsen
2021-11-13 1:08 ` Po Lu
2021-11-13 7:45 ` Eli Zaretskii
2021-11-13 9:34 ` Po Lu [this message]
2021-11-13 10:26 ` Eli Zaretskii
2021-11-13 10:45 ` Po Lu
2021-11-13 13:29 ` Eli Zaretskii
2021-11-13 15:32 ` Stephen Berman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h7cgo0ud.fsf@yahoo.com \
--to=luangruo@yahoo.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=larsi@gnus.org \
--cc=tumashu@163.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.