On Sat, Mar 15, 2025 at 10:18 AM Ship Mints wrote: > On Sat, Mar 15, 2025 at 1:37 AM Thierry Volpiatto > wrote: > >> Ship Mints writes: >> >> > 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. >> >> I don't really understand what your packages are doing or are intended >> doing, but FWICS in bufferlo: You are using in some places >> (bookmark-jump name #'ignore); why don't you do all this work (restore >> window-states in tab) in DISPLAY-FUNCTION instead of using `ignore`? >> Your handler would be much simpler by moving the window-state-put and >> alike calls in DISPLAY-FUNCTION: >> >> (bookmark-jump name #'your_function_restoring_window_or_frame_state) >> >> Using (bookmark-jump name #'ignore) with all the code that jump to >> frame/tab etc... in the handler is just a workaround to fix the previous >> buggy behavior of bookmark--jump-via. IMO. >> >> It would be good to start with a good example or recipe to see if we can >> find a good solution. >> > > We need the bookmarks to work from the bookmark menu where no > display-function overrides are supported. > > I suggest we add bookmark-record keys that indicate to bookmark-jump to > inhibit/or allow messing with window-configurations. The bufferlo > bookmarks (and Adam's if he wants) would contain these hint keys. > > '(bookmark-jump-inhibit-window-actions . t) ; or whatever we come up with > > I can contrive an example, if necessary, but I believe y'all get the > point. Nested bookmarks whose handlers expect their window-configurations > not to be messed with up the chain, will always be broken without > additional controls. > The attached patch implements such a scheme that works for us, and is transparent to other bookmark uses. -Stephane