GNU bug report logs - #69232
30.0.50; [PATCH] EWW history navigation gets caught in a loop

Previous Next

Package: emacs;

Reported by: Jim Porter <jporterbugs <at> gmail.com>

Date: Sun, 18 Feb 2024 18:24:16 UTC

Severity: normal

Tags: patch

Found in version 30.0.50

Done: Jim Porter <jporterbugs <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #71 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: James Thomas <jimjoe <at> gmx.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Thu, 29 Feb 2024 17:00:22 -0800
On 2/29/2024 3:30 PM, James Thomas via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> The current patch is much better for me personally: 'l' and 'r' now do
> what they're supposed to do. But my ideal (short of any advanced 'tree'
> mechanism), as I originally stated, would've been to _insert_ (rather
> than _replace_) the new history at the position in the current history
> where it's created (but I see that there's no SOP for that in (info
> "(elisp) Minibuffer History"), and that there could be performance
> implications).

That shouldn't be too hard to do, at the very least with the appropriate 
hooks (i.e. you might need to write some Elisp depending on how many 
built-in options we want to support, but you won't have to use 
'advice-add').

> Why not simply make 'eww-save-history' customizable?

In a general sense, that's the idea. I don't want to make 
'eww-save-history' itself customizable though, since a) I want to let 
people define a history pruning/fixup function and b) I don't want that 
customizable function to have to be responsible for saving the current 
page's history; 'eww-save-history' can do that for us. In practice 
though, I think it'll all work out about the same, albeit easier to use.

> TBH I don't think anyone would have been (ab)using it effectively
> because each 'l' or 'r' made things more complicated; but the advantage
> that *all* of history was available with 'H'.

Yeah, I think the main thing we need here is some option to prevent loss 
of existing history.

> (I'm using this patch and will let you know if I see anything amiss)

I already found one issue with reloading messing up history, but that 
was an easy fix. Once I finish up the other parts of my v3 patch, I'll 
post it here.




This bug report was last modified 1 year and 75 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.