bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in a loop

[Jim Porter <jporterbugs@gmail.com>]

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.