bug#33871: 27.0.50; Revert Dired window saved in window configuration

[Juri Linkov]

>> OTOH, tab-bar.el is preloaded as well, so no problem to leave this
>> in tab-bar.el, since window.el is too large already.
>
> Then I would give them a 'tab-bar-' prefix.

I agree that if they remain in tab-bar.el they should have a 'tab-bar-' prefix.
But OTOH, such prefix doesn't look right to use for hooks in dired-mode,
because this is a general window functionality, not directly related to tabs.

Maybe still would be better to add this to window.el?
Then to not change the size of window.el, we could remove
some existing lines that don't belong to window.el.
For example, these defcustoms have no place in window.el:

  (defcustom display-comint-buffer-action
  (defcustom display-tex-shell-buffer-action

Ok, I will create a separate bug report to remove them.

>>> Maybe 'window-restore-set-context' and 'window-restore-use-context'
>>> would be more indicative names.
>>
>> The name 'window-restore-set-context' looks quite self-contradictory.
>> If your intention was to use a unique prefix, then maybe we could use the
>> prefix 'window-context' like in 'window-context-set', 'window-context-use'.
>
> I'd say the context of a window are the other windows of the same frame.

This was meant to denote a context inside a window.
Then maybe a better prefix would be 'window-point-context'?

>>> Note that when a buffer is killed, the values of its local variables may
>>> be lost.  I don't know whether this is an issue here.  Alternatively, we
>>> could have 'set_window_buffer' set the 'context' window parameter from
>>> the buffer-local value which would, however, mean that whenever one
>>> changes the buffer-local value, one would have to simultaneously update
>>> the parameters in all windows showing that buffer.  Something that could
>>> be done with the help of an advice, though...
>>
>> This doesn't look like an issue here because the context is stored
>> in a window parameter.
>
> IIUC the context is stored but not the function to restore the position
> from the context.

Indeed, there was an idea to store a function that restores point, but
this might be problematic when saving such a function to the desktop file.
Therefore, the patch has two separate functions to save and restore context
as mere strings and numbers.

>> And when the buffer is killed, there is no need
>> to restore a context in the killed buffer.
>
> If you don't intend to restore the context from the file the buffer was
> visiting.  Are you sure you don't want to do that?

After the buffer was killed?  This doesn't seems necessary.

>> The format of the window parameter
>>
>>    '(BUFFER-NAME . ((dired-filename . FILENAME)))
>>
>> uses BUFFER-NAME to check whether the buffer was killed,
>> and when the current window's buffer doesn't match BUFFER-NAME,
>> then do nothing.
>
> What do you do when you want to restore a configuration from a tab, that
> configuration contains a window whose buffer was killed but whose file
> still exists and you wanted to revisit that file in the window with its
> previous point?  Ignore any context for that window?

I think such cases are very rare.