bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

> Thanks, but I expected it to be more configurable, i.e. to also look
> at prev/next-buffers in a saved configuration when needed, etc.

We can easily do that.  But note that a window's previous and next
buffers are stored in the window itself (where, if the window is live,
they can change at any time) and not in the window copy stored in the
configuration.  So there are two solutions to your request: Have
'buffer-windows-from-configuration' return pointers to those two lists
or have say 'window-prev-buffers' accept dead windows as arguments?

> This could be achieved with a complete export of the saved
> configuration to a Lisp structure.

It's a bit tedious to code but can be certainly done.  But I suppose
that what might then interest you just as well is to transform window
states into window configurations ;-)

Also, the function as I wrote it could be easily complemented by a
function say 'set-window-buffer-in-configuration' where for an
argument WINDOW you could perform some surgery in the configuration
like setting its buffer (when it gets killed) or its point or start
position (when its buffer gets reverted).

> If you think this is too big task, then a simpler solution is
> just to create such metadata structure before the configuration
> is saved, and save it along with the configuration.  I already do
> this by saving a writable window state parallelly with saving
> a window configuration.  What I mean that in a package that
> saves window configurations, maintain such a list:
>
> ((window-configuration-1 writable-window-state-1 metadata-1)
>   (window-configuration-2 writable-window-state-2 metadata-2)
>   ...)
>
> where metadata could contain a list of buffers from windows
> and from prev/next buffers, and everything else required by
> application logic.

The problem with this is that states you save this way get outdated
wrt their corresponding configurations: In particular, after
(un-)showing a few more buffers in the corresponding frame, the
configuration will be aware of these changes (because they are stored
in the lists of previous and next buffers of the live windows) while
your saved states won't.

Finally, we probably want to do some of the things on your wish list
automatically for all configurations referenced by some particular
list like say 'registered-window-configurations'.  So maybe we should
think about such a structure and how to maintain it now.

martin