bug#29785: [PATCH] Implement separate eww history

bug#29785: [PATCH] Implement separate eww history

[Robert Pluim]

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

It's always bugged me that eww uses the minibuffer history when
reading which url to open. Attached a patch to enable an optional
separate history.

I'm assuming this would target 27.1

Regards

Robert


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-support-for-eww-url-history.patch --]
[-- Type: text/x-diff, Size: 2775 bytes --]

From e805d28d8ef16db59347f44faf39fde5fd329fc6 Mon Sep 17 00:00:00 2001
From: Robert Pluim <rpluim@gmail.com>
Date: Wed, 25 Oct 2017 15:20:34 +0200
Subject: [PATCH] Add support for eww url history

* doc/misc/eww.texi (Basics): Document eww-separate-history

* etc/NEWS : Add documentation for eww-separate-history

* lisp/net/eww.el (eww-separate-history): Define.
(eww): Use it.
---
 doc/misc/eww.texi |  6 ++++++
 etc/NEWS          |  4 ++++
 lisp/net/eww.el   | 12 +++++++++++-
 3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/doc/misc/eww.texi b/doc/misc/eww.texi
index e9b544fbde..7fc6b068d9 100644
--- a/doc/misc/eww.texi
+++ b/doc/misc/eww.texi
@@ -85,6 +85,12 @@ Basics
 either prefix the file name with @code{file://} or use the command
 @kbd{M-x eww-open-file}.
 
+@vindex eww-separate-history
+@cindex eww
+  If you want to keep the history of URI's you've opened separate from
+the default minibuffer history, set @code{eww-separate-history} to
+@code{t}
+
 @findex eww-quit
 @findex eww-reload
 @findex eww-copy-page-url
diff --git a/etc/NEWS b/etc/NEWS
index 784c608041..df1520566a 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -900,6 +900,10 @@ bigger than the current window).
 avoid accidentally accessing remote links may rebind 'w' and 'u' in
 'eww-link-keymap' to it.
 
++++
+*** The new user variable 'eww-separate-history' causes eww to use a
+separate minibuffer history if non-nil
+
 ** Ido
 
 ---
diff --git a/lisp/net/eww.el b/lisp/net/eww.el
index bff592c3fe..b480710b98 100644
--- a/lisp/net/eww.el
+++ b/lisp/net/eww.el
@@ -113,6 +113,15 @@ eww-restore-reload-prompt
   :group 'eww
   :type 'string)
 
+(defcustom eww-separate-history nil
+  "If t, keep the URI history separate from the minibuffer history.
+If nil, use the default minibuffer history list when prompting
+for a URI.  Note that this history is only used when prompting,
+it is separate from those used by `eww-list-histories'."
+  :version "27.1"
+  :group 'eww
+  :type 'boolean)
+
 (defcustom eww-history-limit 50
   "Maximum number of entries to retain in the history."
   :version "25.1"
@@ -218,6 +227,7 @@ eww-valid-certificate
 (defvar eww-data nil)
 (defvar eww-history nil)
 (defvar eww-history-position 0)
+(defvar eww-uri-history nil)
 
 (defvar eww-local-regex "localhost"
   "When this regex is found in the URL, it's not a keyword but an address.")
@@ -250,7 +260,7 @@ eww
 	  (prompt (concat "Enter URL or keywords"
 			  (if uris (format " (default %s)" (car uris)) "")
 			  ": ")))
-     (list (read-string prompt nil nil uris))))
+     (list (read-string prompt nil (and eww-separate-history 'eww-uri-history) uris))))
   (setq url (eww--dwim-expand-url url))
   (pop-to-buffer-same-window
    (if (eq major-mode 'eww-mode)
-- 
2.15.0.276.g89ea799ff

bug#29785: [PATCH] Implement separate eww history

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> +@vindex eww-separate-history
> +@cindex eww
> +  If you want to keep the history of URI's you've opened separate from
> +the default minibuffer history, set @code{eww-separate-history} to
> +@code{t}

I don't think this needs to be configurable -- the history should just
be a separate one.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#29785: [PATCH] Implement separate eww history

[Robert Pluim]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> +@vindex eww-separate-history
>> +@cindex eww
>> +  If you want to keep the history of URI's you've opened separate from
>> +the default minibuffer history, set @code{eww-separate-history} to
>> +@code{t}
>
> I don't think this needs to be configurable -- the history should just
> be a separate one.

So do I, but I don't want to elicit any 'how dare you change
behaviour' comments a year from now.

Robert

bug#29785: [PATCH] Implement separate eww history

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Wed, 20 Dec 2017 13:23:02 +0100
> Cc: 29785@debbugs.gnu.org
> 
> > I don't think this needs to be configurable -- the history should just
> > be a separate one.
> 
> So do I, but I don't want to elicit any 'how dare you change
> behaviour' comments a year from now.

The behavior doesn't change, though.

bug#29785: [PATCH] Implement separate eww history

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Date: Wed, 20 Dec 2017 13:23:02 +0100
>> Cc: 29785@debbugs.gnu.org
>> 
>> > I don't think this needs to be configurable -- the history should just
>> > be a separate one.
>> 
>> So do I, but I don't want to elicit any 'how dare you change
>> behaviour' comments a year from now.
>
> The behavior doesn't change, though.

As currently proposed, no. But if I enabled the separate history
unconditionally then it would.

Robert

bug#29785: [PATCH] Implement separate eww history

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 29785@debbugs.gnu.org,  larsi@gnus.org
> Date: Wed, 20 Dec 2017 17:50:34 +0100
> 
> >> So do I, but I don't want to elicit any 'how dare you change
> >> behaviour' comments a year from now.
> >
> > The behavior doesn't change, though.
> 
> As currently proposed, no. But if I enabled the separate history
> unconditionally then it would.

No, it won't.  M-p and M-n would still work as they did before.

bug#29785: [PATCH] Implement separate eww history

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: 29785@debbugs.gnu.org,  larsi@gnus.org
>> Date: Wed, 20 Dec 2017 17:50:34 +0100
>> 
>> >> So do I, but I don't want to elicit any 'how dare you change
>> >> behaviour' comments a year from now.
>> >
>> > The behavior doesn't change, though.
>> 
>> As currently proposed, no. But if I enabled the separate history
>> unconditionally then it would.
>
> No, it won't.  M-p and M-n would still work as they did before.

The history list they would cycle through would be the eww history
list, not the global minibuffer history list.  What am I missing?

Robert

bug#29785: [PATCH] Implement separate eww history

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 29785@debbugs.gnu.org,  larsi@gnus.org
> Date: Wed, 20 Dec 2017 20:01:33 +0100
> 
> >> As currently proposed, no. But if I enabled the separate history
> >> unconditionally then it would.
> >
> > No, it won't.  M-p and M-n would still work as they did before.
> 
> The history list they would cycle through would be the eww history
> list, not the global minibuffer history list.  What am I missing?

You don't miss anything.  I'm saying that user-visible behavior won't
change, as users don't care where the history is stored.  Therefore, a
defcustom, which is by definition for users and not for developers, is
not needed, at least not IMO.

bug#29785: [PATCH] Implement separate eww history

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: 29785@debbugs.gnu.org,  larsi@gnus.org
>> Date: Wed, 20 Dec 2017 20:01:33 +0100
>> 
>> >> As currently proposed, no. But if I enabled the separate history
>> >> unconditionally then it would.
>> >
>> > No, it won't.  M-p and M-n would still work as they did before.
>> 
>> The history list they would cycle through would be the eww history
>> list, not the global minibuffer history list.  What am I missing?
>
> You don't miss anything.  I'm saying that user-visible behavior won't
> change, as users don't care where the history is stored.  Therefore, a
> defcustom, which is by definition for users and not for developers, is
> not needed, at least not IMO.

OK. I'll just enable stuff and wait for the inevitable fallout.

Robert

bug#29785: [PATCH] Implement separate eww history

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> OK. I'll just enable stuff and wait for the inevitable fallout.

I guess you did and there was no fallout, so I'm closing this bug
report.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#29785: [PATCH] Implement separate eww history

[Robert Pluim]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> OK. I'll just enable stuff and wait for the inevitable fallout.
>
> I guess you did and there was no fallout, so I'm closing this bug
> report.  :-)

No, people suggested a bunch of additions/extensions, and I haven't
gotten around to implementing them yet. OK to close

Robert

bug#29785: [PATCH] Implement separate eww history

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Wed, 20 Dec 2017 12:56:53 +0100
> 
> +@vindex eww-separate-history
> +@cindex eww
> +  If you want to keep the history of URI's you've opened separate from
> +the default minibuffer history, set @code{eww-separate-history} to
> +@code{t}

Why should EWW usurp the history of URLs?  If we are going to provide
a history of URLs, it should be common to EWW and browse-url at least,
I think, and perhaps other commands that prompt for URL, if there are
such commands.

> ++++
> +*** The new user variable 'eww-separate-history' causes eww to use a
> +separate minibuffer history if non-nil

Period at the end of a sentence, and also EWW should be capitalized, I
think.

Btw, I see lately some kind of tendency to write long multi-line
sentences at the beginning of NEWS entries.  This is the opposite of
what we should try doing: NEWS is visited in Outline mode, so we
should facilitate that by having short headers, to allow users hide
the text of the entry.

Thanks.

bug#29785: [PATCH] Implement separate eww history

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Date: Wed, 20 Dec 2017 12:56:53 +0100
>> 
>> +@vindex eww-separate-history
>> +@cindex eww
>> +  If you want to keep the history of URI's you've opened separate from
>> +the default minibuffer history, set @code{eww-separate-history} to
>> +@code{t}
>
> Why should EWW usurp the history of URLs?

The patch does not change the existing history support of browse-url,
so 'usurp' feels harsh.

> If we are going to provide
> a history of URLs, it should be common to EWW and browse-url at least,
> I think, and perhaps other commands that prompt for URL, if there are
> such commands.

I could make the argument that URLs visited via browse-url are
passed to an external browser, so it's not up to Emacs to remember
that history, unlike ones visited internally using EWW.

>> ++++
>> +*** The new user variable 'eww-separate-history' causes eww to use a
>> +separate minibuffer history if non-nil
>
> Period at the end of a sentence, and also EWW should be capitalized, I
> think.
>
> Btw, I see lately some kind of tendency to write long multi-line
> sentences at the beginning of NEWS entries.  This is the opposite of
> what we should try doing: NEWS is visited in Outline mode, so we
> should facilitate that by having short headers, to allow users hide
> the text of the entry.

There appears to be quite a mix of those two styles in NEWS. I'll see
what I can do to cut down the initial sentence.

Robert

bug#29785: [PATCH] Implement separate eww history

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 29785@debbugs.gnu.org
> Date: Wed, 20 Dec 2017 17:36:58 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why should EWW usurp the history of URLs?
> 
> The patch does not change the existing history support of browse-url,
> so 'usurp' feels harsh.

It's just a word.  It feels strange to me to call URL history by name
that includes "eww" as a substring.  IMO it should be a general URL
history, like we have for files.

But that's just one opinion.

> I could make the argument that URLs visited via browse-url are
> passed to an external browser, so it's not up to Emacs to remember
> that history, unlike ones visited internally using EWW.

url-history.el seems to disagree.

> >> ++++
> >> +*** The new user variable 'eww-separate-history' causes eww to use a
> >> +separate minibuffer history if non-nil
> >
> > Period at the end of a sentence, and also EWW should be capitalized, I
> > think.
> >
> > Btw, I see lately some kind of tendency to write long multi-line
> > sentences at the beginning of NEWS entries.  This is the opposite of
> > what we should try doing: NEWS is visited in Outline mode, so we
> > should facilitate that by having short headers, to allow users hide
> > the text of the entry.
> 
> There appears to be quite a mix of those two styles in NEWS. I'll see
> what I can do to cut down the initial sentence.

Thanks.  In many cases, like this one, it's very simple:

  *** New user variable 'eww-separate-history'.
  If non-nil, this causes EWW to use a separate minibuffer history.
  The default is nil.

bug#29785: [PATCH] Implement separate eww history

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: 29785@debbugs.gnu.org
>> Date: Wed, 20 Dec 2017 17:36:58 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Why should EWW usurp the history of URLs?
>> 
>> The patch does not change the existing history support of browse-url,
>> so 'usurp' feels harsh.
>
> It's just a word.  It feels strange to me to call URL history by name
> that includes "eww" as a substring.  IMO it should be a general URL
> history, like we have for files.
>

It's the url history of M-x eww, but it's just a name.

> But that's just one opinion.
>
>> I could make the argument that URLs visited via browse-url are
>> passed to an external browser, so it's not up to Emacs to remember
>> that history, unlike ones visited internally using EWW.
>
> url-history.el seems to disagree.


OK, so that does even more, it remembers url history across
sessions. I never noticed it because:

a) It's disabled by default.

b) As far as I can tell, nothing uses it for actual completion of
urls.

So the final implementation should

1. Enable it by default
2. Hook up eww to it
3. Hook up browse-url to it
4. and probably various things in org

Note that eww has a separate history mechanism also to track the urls
you visit during a session (there may be a way to persist that as
well).

I'm thinking 3 different history mechanisms is too much. I can work on
connecting at least eww to the existing url-history mechanism over the
holidays, if you think that's the right direction [1]

> Thanks.  In many cases, like this one, it's very simple:
>
>   *** New user variable 'eww-separate-history'.
>   If non-nil, this causes EWW to use a separate minibuffer history.
>   The default is nil.

Thanks for that.

Robert

Footnotes: 
[1] And if I really get going I'll try to unify the 4 different ways
we have of determining what URL we think is at point

bug#29785: [PATCH] Implement separate eww history

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

>> If we are going to provide
>> a history of URLs, it should be common to EWW and browse-url at least,
>> I think, and perhaps other commands that prompt for URL, if there are
>> such commands.
>
> I could make the argument that URLs visited via browse-url are
> passed to an external browser, so it's not up to Emacs to remember
> that history, unlike ones visited internally using EWW.

I think it would make sense for all commands that handle URLs to share a
common history.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no