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