* bug#19662: 24.4: history bloat and navigation trouble
@ 2015-01-23 15:54 Boruch Baum
2015-01-25 2:47 ` Lars Ingebrigtsen
0 siblings, 1 reply; 7+ messages in thread
From: Boruch Baum @ 2015-01-23 15:54 UTC (permalink / raw)
To: 19662
[-- Attachment #1: Type: text/plain, Size: 8599 bytes --]
Whenever I use the 'r' or 'l' keys in eww-mode, to eww-forward-url or
eww-back-url in the history list, the size of the history increases.
This seems to me to be wrong. Also, this behaviour seems to make it
impossible (for me, at least) to traverse the entire history this way,
unless I do so in a straight sequence (eg. all eww-back-url without ever
using eww-forward-url).
Following is a version that seems to work for me.
(defun eww-back-url ()
; bugs resolved here:
; 1] (eww-save-history) should not be called here. All it doe\
s is bloat the history and make it difficult to navigate save\
for direct entry from the *eww-history* buffer
; 2] eww-history-position was being incremented by 2 instead \
of 1
; 3] math error in navigating history elements - off by one
; 4] improper use of 'when'. upon finding a user-error, it pr\
oceeds to continue with the function anyway. use 'if' instead
"Go to the previously displayed page."
(interactive)
(if (>= eww-history-position (1- (length eww-history)))
(user-error "No previous page")
(setq eww-history-position (1+ eww-history-position))
(eww-restore-history (elt eww-history eww-history-position\
))))
(defun eww-forward-url ()
"Go to the next displayed page."
(interactive)
(if (<= eww-history-position 0)
(user-error "No next page")
(setq eww-history-position (1- eww-history-position))
(eww-restore-history (elt eww-history eww-history-position\
))))
In GNU Emacs 24.4.1 (x86_64-pc-linux-gnu)
of 2014-12-09 on gaia, modified by Debian
System Description: Debian 7.0 GNU/Linux wheezy/testing
Configured using:
`configure --build x86_64-linux-gnu --prefix=/usr
--sharedstatedir=/var/lib --libexecdir=/usr/lib
--localstatedir=/var/lib --infodir=/usr/share/info
--mandir=/usr/share/man --with-pop=yes
--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp
--build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
--libexecdir=/usr/lib --localstatedir=/var/lib
--infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp
--with-x=no --without-gconf --without-gsettings 'CFLAGS=-g -O2
-fstack-protector-strong -Wformat -Werror=format-security -Wall'
CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-z,relro'
Important settings:
value of $LANG: en_US.utf8
locale-coding-system: utf-8-unix
Major mode: Emacs-Lisp
Minor modes in effect:
desktop-save-mode: t
savehist-mode: t
winner-mode: t
show-paren-mode: t
global-hi-lock-mode: t
hi-lock-mode: t
delete-selection-mode: t
shell-dirtrack-mode: t
tooltip-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
size-indication-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-favicon hides
/usr/share/emacs24/site-lisp/w3m/w3m-favicon
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-symbol hides
/usr/share/emacs24/site-lisp/w3m/w3m-symbol
home/boruch.emacs.d/elpa/w3m-20140107.1708/bookmark-w3m hides
/usr/share/emacs24/site-lisp/w3m/bookmark-w3m
home/boruch.emacs.d/elpa/w3m-20140107.1708/mime-w3m hides
/usr/share/emacs24/site-lisp/w3m/mime-w3m
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-filter hides
/usr/share/emacs24/site-lisp/w3m/w3m-filter
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-ccl hides
/usr/share/emacs24/site-lisp/w3m/w3m-ccl
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-namazu hides
/usr/share/emacs24/site-lisp/w3m/w3m-namazu
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-ems hides
/usr/share/emacs24/site-lisp/w3m/w3m-ems
home/boruch.emacs.d/elpa/w3m-20140107.1708/octet hides
/usr/share/emacs24/site-lisp/w3m/octet
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-bookmark hides
/usr/share/emacs24/site-lisp/w3m/w3m-bookmark
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-perldoc hides
/usr/share/emacs24/site-lisp/w3m/w3m-perldoc
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-dtree hides
/usr/share/emacs24/site-lisp/w3m/w3m-dtree
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-session hides
/usr/share/emacs24/site-lisp/w3m/w3m-session
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-mail hides
/usr/share/emacs24/site-lisp/w3m/w3m-mail
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-search hides
/usr/share/emacs24/site-lisp/w3m/w3m-search
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3mhack hides
/usr/share/emacs24/site-lisp/w3m/w3mhack
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-proc hides
/usr/share/emacs24/site-lisp/w3m/w3m-proc
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-tabmenu hides
/usr/share/emacs24/site-lisp/w3m/w3m-tabmenu
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-rss hides
/usr/share/emacs24/site-lisp/w3m/w3m-rss
home/boruch.emacs.d/elpa/w3m-20140107.1708/mew-w3m hides
/usr/share/emacs24/site-lisp/w3m/mew-w3m
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m hides
/usr/share/emacs24/site-lisp/w3m/w3m
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-image hides
/usr/share/emacs24/site-lisp/w3m/w3m-image
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-hist hides
/usr/share/emacs24/site-lisp/w3m/w3m-hist
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-lnum hides
/usr/share/emacs24/site-lisp/w3m/w3m-lnum
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-form hides
/usr/share/emacs24/site-lisp/w3m/w3m-form
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-cookie hides
/usr/share/emacs24/site-lisp/w3m/w3m-cookie
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-weather hides
/usr/share/emacs24/site-lisp/w3m/w3m-weather
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-bug hides
/usr/share/emacs24/site-lisp/w3m/w3m-bug
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-fb hides
/usr/share/emacs24/site-lisp/w3m/w3m-fb
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-antenna hides
/usr/share/emacs24/site-lisp/w3m/w3m-antenna
home/boruch.emacs.d/elpa/w3m-20140107.1708/w3m-util hides
/usr/share/emacs24/site-lisp/w3m/w3m-util
home/boruch.emacs.d/elpa/csv-mode-1.2/csv-mode hides
/usr/share/emacs24/site-lisp/emacs-goodies-el/csv-mode
/usr/share/emacs/24.4/site-lisp/cdargs hides
/usr/share/emacs/site-lisp/cdargs
/usr/share/emacs/24.4/site-lisp/debian-startup hides
/usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs24/site-lisp/flim/md4 hides /usr/share/emacs/24.4/lisp/md4
/usr/share/emacs24/site-lisp/flim/hex-util hides
/usr/share/emacs/24.4/lisp/hex-util
/usr/share/emacs24/site-lisp/dictionaries-common/flyspell hides
/usr/share/emacs/24.4/lisp/textmodes/flyspell
/usr/share/emacs24/site-lisp/dictionaries-common/ispell hides
/usr/share/emacs/24.4/lisp/textmodes/ispell
/usr/share/emacs/site-lisp/rst hides
/usr/share/emacs/24.4/lisp/textmodes/rst
/usr/share/emacs24/site-lisp/flim/sasl-ntlm hides
/usr/share/emacs/24.4/lisp/net/sasl-ntlm
/usr/share/emacs24/site-lisp/flim/hmac-def hides
/usr/share/emacs/24.4/lisp/net/hmac-def
/usr/share/emacs24/site-lisp/flim/hmac-md5 hides
/usr/share/emacs/24.4/lisp/net/hmac-md5
/usr/share/emacs24/site-lisp/flim/sasl-cram hides
/usr/share/emacs/24.4/lisp/net/sasl-cram
/usr/share/emacs24/site-lisp/flim/ntlm hides
/usr/share/emacs/24.4/lisp/net/ntlm
/usr/share/emacs24/site-lisp/flim/sasl hides
/usr/share/emacs/24.4/lisp/net/sasl
/usr/share/emacs24/site-lisp/flim/sasl-digest hides
/usr/share/emacs/24.4/lisp/net/sasl-digest
/usr/share/emacs/24.4/lisp/emacs-lisp/ert-x hides
/usr/share/emacs/24.4/site-lisp/slime/lib/ert-x
/usr/share/emacs/24.4/lisp/emacs-lisp/cl-lib hides
/usr/share/emacs/24.4/site-lisp/slime/lib/cl-lib
/usr/share/emacs/24.4/lisp/emacs-lisp/ert hides
/usr/share/emacs/24.4/site-lisp/slime/lib/ert
Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mailabbrev ...)
Memory information:
((conses 16 1043076 35535)
(symbols 48 49941 0)
(miscs 40 3608 4131)
(strings 32 211545 17576)
(string-bytes 1 6527905)
(vectors 16 56912)
(vector-slots 8 1760199 36350)
(floats 8 512 1702)
(intervals 56 139256 3953)
(buffers 960 130)
(heap 1024 69149 12252))
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#19662: 24.4: history bloat and navigation trouble
2015-01-23 15:54 bug#19662: 24.4: history bloat and navigation trouble Boruch Baum
@ 2015-01-25 2:47 ` Lars Ingebrigtsen
2015-01-25 7:09 ` Boruch Baum
2016-03-17 7:20 ` Marcin Borkowski
0 siblings, 2 replies; 7+ messages in thread
From: Lars Ingebrigtsen @ 2015-01-25 2:47 UTC (permalink / raw)
To: Boruch Baum; +Cc: 19662
Boruch Baum <boruch_baum@gmx.com> writes:
> Whenever I use the 'r' or 'l' keys in eww-mode, to eww-forward-url or
> eww-back-url in the history list, the size of the history increases.
> This seems to me to be wrong. Also, this behaviour seems to make it
> impossible (for me, at least) to traverse the entire history this way,
> unless I do so in a straight sequence (eg. all eww-back-url without ever
> using eww-forward-url).
The eww history navigation is, er, original, but it's trying to solve
the problem of "how do I get back to the page I saw just a few minutes
ago".
If you're on page A, then moves to B, then moves back to A, and then
moves to C, then getting back to B in eww is <back>, <back>. Because
that's the page you saw two pages ago.
In Firefox, if you do the same, <back> will get you to A, and then
there's no more <back>, and you can never visit B by either going back
or forward.
And it seems to me like your proposed change would have the same effect.
If anybody has a better way of registering the history (that still
wouldn't "forget" B, like Firefox does), I'm all ears.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#19662: 24.4: history bloat and navigation trouble
2015-01-25 2:47 ` Lars Ingebrigtsen
@ 2015-01-25 7:09 ` Boruch Baum
2015-01-26 2:04 ` Lars Ingebrigtsen
2016-03-17 7:20 ` Marcin Borkowski
1 sibling, 1 reply; 7+ messages in thread
From: Boruch Baum @ 2015-01-25 7:09 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 19662
[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]
On 01/24/2015 09:47 PM, Lars Ingebrigtsen wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
>
>> Whenever I use the 'r' or 'l' keys in eww-mode, to eww-forward-url or
>> eww-back-url in the history list, the size of the history increases.
>> This seems to me to be wrong. Also, this behaviour seems to make it
>> impossible (for me, at least) to traverse the entire history this way,
>> unless I do so in a straight sequence (eg. all eww-back-url without ever
>> using eww-forward-url).
>
> The eww history navigation is, er, original, but it's trying to solve
> the problem of "how do I get back to the page I saw just a few minutes
> ago".
>
> If you're on page A, then moves to B, then moves back to A, and then
> moves to C, then getting back to B in eww is <back>, <back>. Because
> that's the page you saw two pages ago.
>
> In Firefox, if you do the same, <back> will get you to A, and then
> there's no more <back>, and you can never visit B by either going back
> or forward.
>
> And it seems to me like your proposed change would have the same effect.
No. What ends up happening is that the sequence of the history list is
preserved, so you can always go back to B. It has the advantage of
reducing bloat, and if one scrolls through history much, that bloat can
be great.
I can see two uses for a history:
1] a log of the sequence in which pages were visited;
2] a list of visited places, in original sequence order.
For me, #2 is far and away more useful.
One problem with the current eww implementation is that once one does
something like A B C D C B, it becomes difficult to get to E using
commands l/r
>
> If anybody has a better way of registering the history (that still
> wouldn't "forget" B, like Firefox does), I'm all ears.
>
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#19662: 24.4: history bloat and navigation trouble
2015-01-25 7:09 ` Boruch Baum
@ 2015-01-26 2:04 ` Lars Ingebrigtsen
2015-01-26 6:29 ` Boruch Baum
0 siblings, 1 reply; 7+ messages in thread
From: Lars Ingebrigtsen @ 2015-01-26 2:04 UTC (permalink / raw)
To: Boruch Baum; +Cc: 19662
Boruch Baum <boruch_baum@gmx.com> writes:
> No. What ends up happening is that the sequence of the history list is
> preserved, so you can always go back to B. It has the advantage of
> reducing bloat, and if one scrolls through history much, that bloat can
> be great.
>
> I can see two uses for a history:
> 1] a log of the sequence in which pages were visited;
> 2] a list of visited places, in original sequence order.
>
> For me, #2 is far and away more useful.
The current history implementation also preserves the point position,
which is probably different in each frame. Which may or may not be
helpful.
I agree that the current way of recording the history may be overkill,
but I've also found it very handy because it's so predictable. <back>
<back> always, without fail, takes you back to the page you were at two
commands ago, no matter what the command was...
> One problem with the current eww implementation is that once one does
> something like A B C D C B, it becomes difficult to get to E using
> commands l/r
Where is E in that sequence of pages?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#19662: 24.4: history bloat and navigation trouble
2015-01-26 2:04 ` Lars Ingebrigtsen
@ 2015-01-26 6:29 ` Boruch Baum
2015-01-26 6:39 ` Lars Ingebrigtsen
0 siblings, 1 reply; 7+ messages in thread
From: Boruch Baum @ 2015-01-26 6:29 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 19662
[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]
On 01/25/2015 09:04 PM, Lars Ingebrigtsen wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
>
>> No. What ends up happening is that the sequence of the history list is
>> preserved, so you can always go back to B. It has the advantage of
>> reducing bloat, and if one scrolls through history much, that bloat can
>> be great.
>>
>> I can see two uses for a history:
>> 1] a log of the sequence in which pages were visited;
>> 2] a list of visited places, in original sequence order.
>>
>> For me, #2 is far and away more useful.
>
> The current history implementation also preserves the point position,
> which is probably different in each frame. Which may or may not be
> helpful.
>
> I agree that the current way of recording the history may be overkill,
> but I've also found it very handy because it's so predictable. <back>
> <back> always, without fail, takes you back to the page you were at two
> commands ago, no matter what the command was...
>
>> One problem with the current eww implementation is that once one does
>> something like A B C D C B, it becomes difficult to get to E using
>> commands l/r
>
> Where is E in that sequence of pages?
>
That's kind of the point, it would have been historically before D.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#19662: 24.4: history bloat and navigation trouble
2015-01-26 6:29 ` Boruch Baum
@ 2015-01-26 6:39 ` Lars Ingebrigtsen
0 siblings, 0 replies; 7+ messages in thread
From: Lars Ingebrigtsen @ 2015-01-26 6:39 UTC (permalink / raw)
To: Boruch Baum; +Cc: 19662
Boruch Baum <boruch_baum@gmx.com> writes:
>>> One problem with the current eww implementation is that once one does
>>> something like A B C D C B, it becomes difficult to get to E using
>>> commands l/r
>>
>> Where is E in that sequence of pages?
>>
> That's kind of the point, it would have been historically before D.
There is no E in "A B C D C B".
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#19662: 24.4: history bloat and navigation trouble
2015-01-25 2:47 ` Lars Ingebrigtsen
2015-01-25 7:09 ` Boruch Baum
@ 2016-03-17 7:20 ` Marcin Borkowski
1 sibling, 0 replies; 7+ messages in thread
From: Marcin Borkowski @ 2016-03-17 7:20 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 19662-done, Boruch Baum, 19662
On 2015-01-25, at 13:47, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
>
>> Whenever I use the 'r' or 'l' keys in eww-mode, to eww-forward-url or
>> eww-back-url in the history list, the size of the history increases.
>> This seems to me to be wrong. Also, this behaviour seems to make it
>> impossible (for me, at least) to traverse the entire history this way,
>> unless I do so in a straight sequence (eg. all eww-back-url without ever
>> using eww-forward-url).
>
> The eww history navigation is, er, original, but it's trying to solve
> the problem of "how do I get back to the page I saw just a few minutes
> ago".
>
> If you're on page A, then moves to B, then moves back to A, and then
> moves to C, then getting back to B in eww is <back>, <back>. Because
> that's the page you saw two pages ago.
>
> In Firefox, if you do the same, <back> will get you to A, and then
> there's no more <back>, and you can never visit B by either going back
> or forward.
>
> And it seems to me like your proposed change would have the same effect.
>
> If anybody has a better way of registering the history (that still
> wouldn't "forget" B, like Firefox does), I'm all ears.
Hi, it seems this thread just died silently. I'm closing this bug.
Please reopen it if anything new (like, an idea) pops up.
Best,
--
Marcin the Janitor
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-03-17 7:20 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-01-23 15:54 bug#19662: 24.4: history bloat and navigation trouble Boruch Baum
2015-01-25 2:47 ` Lars Ingebrigtsen
2015-01-25 7:09 ` Boruch Baum
2015-01-26 2:04 ` Lars Ingebrigtsen
2015-01-26 6:29 ` Boruch Baum
2015-01-26 6:39 ` Lars Ingebrigtsen
2016-03-17 7:20 ` Marcin Borkowski
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).