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

From: Ship Mints <[email-masked]>
Date: Fri, 14 Mar 2025 16:39:44 -0400

On Fri, Mar 14, 2025 at 7:57 AM Thierry Volpiatto <[email-masked]>
wrote:

> 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.
>

I have workarounds that work only for the most simplistic cases.  Many of
our bookmarks themselves contain embedded bookmarks and bookmark references
(which are individually addressable so can be used separately) with
window-states we need to restore in tab-bar tabs that they represent.  When
jumping to the outermost bookmark, that window-configuration that was saved
in that context gets restored when control returns to the outermost
call, frustrating attempts to manage these at lower levels.  These use
cases are legitimate uses of bookmarks and I have software that has
depended on bookmarks being able to contain any objects for a long time.

bookmark--jump-via save-window-excursion behavior needs to be optional.

Please.

I stand by my suggestions to handle this.