Subject: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump )

From: Thierry Volpiatto <[email-masked]>
Date: Fri, 14 Mar 2025 12:04:27 +0000

Ship Mints <[email-masked]> writes:

> 1.  ( ) text/plain          (*) text/html           
>
> On Fri, Mar 14, 2025 at 12:46 AM Thierry Volpiatto <[email-masked]> wrote:
>
>     Ship Mints <[email-masked]> writes:
>    
>     >     Which bookmark handlers?
>     >
>     > At least these packages rely on bookmarks that store window state and
>     > their handlers restore window state.  There are workarounds I have
>     > considered but they are distasteful, to say the least.
>     >
>     > bufferlo
>     > activities
>     > burly
>    
>     After a quick look at source code of activities I see that it tries hard
>     to fix the bug this change fixed, there is even comments, so I suggest
>     these packages adapt their bookmark code to new bookmark--jump-via, IMO
>     this will reduce the code and make it simpler.
>
> Thanks for taking a look.  Those are just the ones that immediately came to mind.  There may be many other users.  I stand by my suggestions that we either or both:
>
> - Add defcustoms and/or defvars to control this new behavior that breaks bookmarks.  bookmarks are *not* documented to be merely for files, not documented to avoid window and frame
> behavior (some of our bookmarks also perform frame operations compounding the issue with this new behavior).
>
> - Add bookmark-record properties/keys to control bookmark behavior so that bookmark-record-make functions can decide for themselves which behavior to trigger.

The old behavior was wrong, working by chance in many places, so no I
don't think bookmark handlers should relay on it anymore.

> - Add a defustom to set the default display-func so that pop-to-buffer-same-window can be overridden.  I consider that this is missing as an oversight in the implementation that does not
> forbid common use cases for which bookmarks have been adopted.
>
> I'm happy to submit patches for this to make everyone's bookmark use more general and less painful.  In the same vein, I've submitted patches to correct an oversight in window-state-get
> that makes using bookmark-records that contain window-state objects more reliable.
>
> Don't you agree this is a better approach than a wholesale behavior change?

No, I still think you should fix your code according to the new
behavior.  The old bookmark handlers (yours included) are implemented on
a buggy bookmark--jump-via, they should be rewrited to fit with new
code.  But this is just my opinion, let see what others think.

-- 
Thierry