bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#74246: [PATCH] Reuse display windows in image-dired


From: Juri Linkov
Subject: bug#74246: [PATCH] Reuse display windows in image-dired
Date: Thu, 12 Dec 2024 20:42:23 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)

>> Still too limited solution when the users can't store the last window
>> for other commands.  Better would be to add a new alist entry that
>> will force 'display-buffer' to remember the last window from any call:
>>
>>    (display-buffer buffer `((nil (category . compilation)
>>                                  (remember-last-window . t))))
>>
>> or by user customization of display-buffer-alist:
>>
>>    ((category . compilation)
>>     (nil (remember-last-window . t)))
>
> In that case the 'last-window' parameter maintained by 'display-buffer'
> would have to become a list of categories.  Then what about two grep
> operations running in parallel as you mention above: Would they share
> the same target window?

The only different things two grep operations don't share are their
source buffers.  Therefore need to save the last window in the buffer-local
variable in each grep buffer.  They can share the same target window
if the user wants.

>> And a function that stores/restores the last window could be customizable as 
>> well.
>> So the users could decide whether to save it in a buffer-local variable,
>
> ... buffer-local where - in the source or the target buffer?

In the source buffer.  But it should be possible to redefine the function
to use the target buffer, e.g.:

  (remember-last-window .
    (lambda (source-buffer target-buffer source-window target-window)
      (with-current-buffer target-buffer
        (setq-local last-window target-window))))

or

  (remember-last-window .
    (lambda (source-buffer target-buffer source-window target-window)
      (set-window-parameter source-window 'last-window target-window)))

>> or in the window parameter.  This option could be like 'xref-history-storage'
>> that provides the choice of 'xref-global-history' or 
>> 'xref-window-local-history':
>>
>>    ((category . compilation)
>>     (nil (remember-last-window . global)))
>>
>> or
>>
>>    ((category . compilation)
>>     (nil (remember-last-window . window-local)))
>>
>> or
>>
>>    ((category . compilation)
>>     (nil (remember-last-window . buffer-local)))
>
> Just think of describing this in the manual.

No problem.

> But I already see: We'll have to maintain a buffer-local variable, say
> 'xref-last-window' in the source buffer, have xref consult that variable
> and pass it as (last-window . ,xref-last-window) to 'display-buffer'.
> The value returned by 'display-buffer' would then become the new value
> of 'xref-last-window' in the source buffer.  Would that be OK with you?

This should not be specific to packages.  It should be general to be usable
for any display-buffer call.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]