GNU bug report logs - #75354
29.4; eww buffer is not displayed correctly when used from bookmark-jump

Previous Next

Full log

View this message in rfc822 format

From: Thierry Volpiatto <thievol <at> posteo.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: thievol <at> posteo.net, eliz <at> gnu.org, 75354 <at> debbugs.gnu.org
Subject: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump )
Date: Thu, 13 Mar 2025 19:29:13 +0000

[Message part 1 (text/plain, inline)]

Ship Mints <shipmints <at> gmail.com> writes:

>> From: Thierry Volpiatto <thievol <at> posteo.net>
>> Cc: Thierry Volpiatto <thievol <at> posteo.net>,  75354 <at> debbugs.gnu.org
>> Date: Wed, 08 Jan 2025 13:52:32 +0000
>> 
>> > This is contrary to what you originally wrote (with which I agree):
>> 
>> Yes, after deeper search I found that `bookmark--jump-via` is behaving
>> like this AFAIU:
>>  - It calls the handler which creates a new buffer related to bookmark.
>>  - It then displays the current-buffer (the one before jumping to bmk) in
>>  a window according to DISPLAY-FUNCTION and make the bookmark buffer current.
>> 
>> This approach is OK as long as the handler fn doesn't try do do one part
>> of the job (window handling) itself, which is not the case at least with
>> eww and w3m.  It is as well counter intuitive, DISPLAY-FUNCTION should
>> be called on the buffer generated by bookmark and not the contrary, so
>> this change makes the code simpler and easier to understand.
>> 
>> > By contrast, the change you propose now will affect all the uses of
>> > bookmarks, everywhere,
>> 
>> Yes, this is intended, in addition of fixing eww, it fixes w3m and also
>> the quit function of eww (actually broken).
>> 
>> > which is riskier, given how many different variants of bookmark usage
>> > are out there.
>> 
>> Tested here on many different kinds of bookmarks and work as expected
>> unlike the current code.
>
> It took me a while to find time to focus on some bugs with Emacs 31 in
> my workflow (reverting to Emacs 30 until I had time).
>
> I discovered that this change breaks all bookmark handlers that rely
> on managing window-state or window-configuration.

Which bookmark handlers?

> I have no workaround yet this until we fix it, I have to do screwy
> things to make 'bookmark--jump-via' ignore 'save-window-excursion'.
>
> What's the rationale for wrapping 'bookmark-handle-bookmark' with
> 'save-window-excursion'?

1) The bookmark handler function setup a buffer.
2) When this buffer is ready we jump to this buffer with
DISPLAY-FUNCTION.

If you don't save the window excursion in 1) and buffer is not ready,
the DISPLAY-FUNCTION may run from the buffer that was current before
calling the handler function.

Previously we were calling DISPLAY-FUNCTION on current-buffer, assuming
the handler fn had switched to a new buffer which should be current,
when the new buffer was not current we were swicthing to the
current-buffer the one that was current just before as explained above.

So this change has fixed not only eww but some other bookmarks (like
w3m).
  

> If this behavior is truly necessary (I'd like understand the use
> case), I suggest binding a new defvar to bind and trigger this
> behavior rather than affect all bookmark handlers.  Unless eww can be
> fixed.  It could handle window configuration management in its own
> bookmark handler.

That's the point, you should not handle window management in your
bookmark handler, this defeat bookmark--jump-via DISPLAY-FUNCTION.

This change also fixes old bugs where people were trying various things
in their bookmark handlers to get things right including polling or
running code under a timer etc...

> I'm happy to provide a patch once we agree on an approach.
>
> -Stephane

-- 
Thierry

[signature.asc (application/pgp-signature, inline)]

Previous Next

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