Ship Mints <shipmints@gmail.com> writes:
> 1. ( ) text/plain (*) text/html
>
> On Fri, Mar 14, 2025 at 12:46 AM Thierry Volpiatto <thievol@posteo.net> wrote:
>
> Ship Mints <shipmints@gmail.com> 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.