Indirect follow mode in agenda: Display, edition and how to hide drawers

Indirect follow mode in agenda: Display, edition and how to hide drawers

[Sébastien Gendre]

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

Hello,

I have enabled the indirect follow-mode when the agenda start. Now, for
each agenda item, I can see the selected item details and only it. Which
is great.

But I have multiple questions about it.


When a task have drawers, they are shown open. How a can I hide
them in this indirect follow mode ? I didn't enable the opening of
drawers in my config and if I remember they are hidden by default.


The display of a task, with the indirect follow mode, is done bellow the
agenda, and it's window size is adapted to the length of the task
body. But when a task have a lot of text, it's window size take most
of the place and the agenda window is too small. How can I prevent the
task window to take all the place ?


When I want to edit a task and press "TAB", the point is moved to
a window that show all the task. Not into the window opened by the
indirect follow mode. Is it possible to modify this ?



Best regards

-------
Gendre Sébastien



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: Indirect follow mode in agenda: Display, edition and how to hide drawers

[Kristoffer Balintona]

On Tue, Nov 05 2024, Sébastien Gendre wrote:

> Hello,
>
> I have enabled the indirect follow-mode when the agenda start. Now, for
> each agenda item, I can see the selected item details and only it. Which
> is great.
>
> But I have multiple questions about it.
>
>
> When a task have drawers, they are shown open. How a can I hide
> them in this indirect follow mode ? I didn't enable the opening of
> drawers in my config and if I remember they are hidden by default.
>

If I understand you correctly, you want the drawers shown by
org-agenda-follow-mode to be hidden rather than shown as you move across
agenda items, yet? If so, I'm not sure if there is an option to by
default have drawers hidden (I suppose you can alter the minor mode
yourself...), but calling SPC with C-u shows items but hides their
drawers.

>
> The display of a task, with the indirect follow mode, is done bellow the
> agenda, and it's window size is adapted to the length of the task
> body. But when a task have a lot of text, it's window size take most
> of the place and the agenda window is too small. How can I prevent the
> task window to take all the place ?
>
>
> When I want to edit a task and press "TAB", the point is moved to
> a window that show all the task. Not into the window opened by the
> indirect follow mode. Is it possible to modify this ?
>

This is not the default behavior, I don't think. Have you made
customizations to display-buffer-alist?

>
>
> Best regards
>
> -------
> Gendre Sébastien
>
>

-- 
Best,
Kristoffer

Re: Indirect follow mode in agenda: Display, edition and how to hide drawers

[Karthik Chikmagalur]

>> When a task have drawers, they are shown open. How a can I hide
>> them in this indirect follow mode ? I didn't enable the opening of
>> drawers in my config and if I remember they are hidden by default.
>>
>
> If I understand you correctly, you want the drawers shown by
> org-agenda-follow-mode to be hidden rather than shown as you move across
> agenda items, yet? If so, I'm not sure if there is an option to by
> default have drawers hidden (I suppose you can alter the minor mode
> yourself...), but calling SPC with C-u shows items but hides their
> drawers.

I use this piece of advice to get the desired folding behavior in
`org-agenda-follow-mode':

(advice-add 'org-agenda-do-tree-to-indirect-buffer :after
   (defun my/org-agenda-collapse-indirect-buffer-tree (arg)
     (with-current-buffer org-last-indirect-buffer
       (org-ctrl-c-tab) (org-fold-show-entry 'hide-drawers))))

>> The display of a task, with the indirect follow mode, is done bellow the
>> agenda, and it's window size is adapted to the length of the task
>> body. But when a task have a lot of text, it's window size take most
>> of the place and the agenda window is too small. How can I prevent the
>> task window to take all the place ?
>>
>
> This is not the default behavior, I don't think. Have you made
> customizations to display-buffer-alist?

This used to be the default behavior, and it couldn't be customized as
it didn't obey display-buffer-alist.  The window would always open below
the current one.  In May this year it was changed (in commit
db5478108c063d012432eba50e4ebb71a278c060) to follow
display-buffer-alist.  Chances are Sébastien is using a version of Org
mode that does not have this commit.

Karthik

Re: Indirect follow mode in agenda: Display, edition and how to hide drawers

[Sébastien Gendre]

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

Hello,

Thank you for your reply.
Mines are bellow.


Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:

>> If I understand you correctly, you want the drawers shown by
>> org-agenda-follow-mode to be hidden rather than shown as you move across
>> agenda items, yet? If so, I'm not sure if there is an option to by
>> default have drawers hidden (I suppose you can alter the minor mode
>> yourself...), but calling SPC with C-u shows items but hides their
>> drawers.
>
> I use this piece of advice to get the desired folding behavior in
> `org-agenda-follow-mode':
>
> (advice-add 'org-agenda-do-tree-to-indirect-buffer :after
>    (defun my/org-agenda-collapse-indirect-buffer-tree (arg)
>      (with-current-buffer org-last-indirect-buffer
>        (org-ctrl-c-tab) (org-fold-show-entry 'hide-drawers))))

It's an interesting way to do it.

When I create a new Org file, create a heading and add a logbook entry,
the logbook drawer is collapsed.

But when org-agenda display a habit task, with indirect follow mode, it
expend the logbook drawer as well as the properties drawer.

I still search why this different behavior.


>> This is not the default behavior, I don't think. Have you made
>> customizations to display-buffer-alist?
>
> This used to be the default behavior, and it couldn't be customized as
> it didn't obey display-buffer-alist.  The window would always open below
> the current one.  In May this year it was changed (in commit
> db5478108c063d012432eba50e4ebb71a278c060) to follow
> display-buffer-alist.  Chances are Sébastien is using a version of Org
> mode that does not have this commit.

Is this new behavior on Org 9.7 ? I use 9.6.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: Indirect follow mode in agenda: Display, edition and how to hide drawers

[Sébastien Gendre]

[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]

Hello,

Thank you for your reply.
Mines are bellow.


Kristoffer Balintona <krisbalintona@gmail.com> writes:

> On Tue, Nov 05 2024, Sébastien Gendre wrote:
>
>> Hello,
>>
>> I have enabled the indirect follow-mode when the agenda start. Now, for
>> each agenda item, I can see the selected item details and only it. Which
>> is great.
>>
>> But I have multiple questions about it.
>>
>>
>> When a task have drawers, they are shown open. How a can I hide
>> them in this indirect follow mode ? I didn't enable the opening of
>> drawers in my config and if I remember they are hidden by default.
>>
>
> If I understand you correctly, you want the drawers shown by
> org-agenda-follow-mode to be hidden rather than shown as you move across
> agenda items, yet? If so, I'm not sure if there is an option to by
> default have drawers hidden (I suppose you can alter the minor mode
> yourself...), but calling SPC with C-u shows items but hides their
> drawers.

Yes, I want the drawer to be collapsed.

I checked my config and the Org buffers options, but no config set the
drawers to be shown expanded.



>> The display of a task, with the indirect follow mode, is done bellow the
>> agenda, and it's window size is adapted to the length of the task
>> body. But when a task have a lot of text, it's window size take most
>> of the place and the agenda window is too small. How can I prevent the
>> task window to take all the place ?
>>
>>
>> When I want to edit a task and press "TAB", the point is moved to
>> a window that show all the task. Not into the window opened by the
>> indirect follow mode. Is it possible to modify this ?
>>
>
> This is not the default behavior, I don't think. Have you made
> customizations to display-buffer-alist?


No, I did not customized `display-buffer-alist`.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: Indirect follow mode in agenda: Display, edition and how to hide drawers

[Sébastien Gendre]

[-- Attachment #1: Type: text/plain, Size: 2896 bytes --]

Hello,

I have solve my 2 problems.


For the first one: All drawers are unfolded when agenda indirect follow
mode show me the selected task.

The solution is simple: By default, when you display the content of an
Org file, everything is unfolded, including the drawers.

Based on the manual [1], this can be managed with the variable
`org-startup-folded` or the buffer setting `#+STARTUP:`. By default, the
variable `org-startup-folded` is set to `showeverything`. Which tell
Org-mode to unfold every headings, drawers, etc.

I misunderstood the default behavior of Org-mode because, when I tested
the add of a property to a new heading, the newly created "properties"
drawer was folded. Same with the "logbook" drawer. But if I save the
buffer to a file, close it and re-open the file, the drawers are
unfolded.

For my usage, I decided to keep the default behavior (unfold
everything). Except for the file that keep my habits. The logbook drawer
of my habits are too long to be unfolded when displayed by Org-agenda
indirect follow.


For the second problem: When a task have to many lines, the window
opened by indirect follow mode is too tall, forcing the agenda
window to be too small to be usable.

Thanks to Karthik Chikmagalur, who tell me that the window behavior of
Org-mode have changed with a commit from may this year, I updated to
Org-mode 9.7. And my problem is solved with this new version.


That it. I hope my summary is not too long and could help someone else
with same problem.


Have a nice day.


[1] https://orgmode.org/manual/Initial-visibility.html



Sébastien Gendre <seb@k-7.ch> writes:

> [[PGP Signed Part:Good signature from B586F7C77239E29E Sébastien Gendre <seb@k-7.ch> (trust ultimate) created at 2024-11-05T09:02:13+0100 using RSA]]
> Hello,
>
> I have enabled the indirect follow-mode when the agenda start. Now, for
> each agenda item, I can see the selected item details and only it. Which
> is great.
>
> But I have multiple questions about it.
>
>
> When a task have drawers, they are shown open. How a can I hide
> them in this indirect follow mode ? I didn't enable the opening of
> drawers in my config and if I remember they are hidden by default.
>
>
> The display of a task, with the indirect follow mode, is done bellow the
> agenda, and it's window size is adapted to the length of the task
> body. But when a task have a lot of text, it's window size take most
> of the place and the agenda window is too small. How can I prevent the
> task window to take all the place ?
>
>
> When I want to edit a task and press "TAB", the point is moved to
> a window that show all the task. Not into the window opened by the
> indirect follow mode. Is it possible to modify this ?
>
>
>
> Best regards
>
> -------
> Gendre Sébastien
>
>
> [[End of PGP Signed Part]]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: Indirect follow mode in agenda: Display, edition and how to hide drawers

[Sébastien Gendre]

[-- Attachment #1: Type: text/plain, Size: 3662 bytes --]

Rectification: Adding a "#+STARTUP: overview" on top of my habits
org-mode file did not change anything with org-agenda follow indirect
buffer.

Yes, if I manually open my habits org-mode file everything is folded.
And if I unfold a task, its drawers are still folded. Which is correct.

But when the same task is shown on an indirect buffer by org-agenda
follow mode, every drawers are unfolded.




Sébastien Gendre <seb@k-7.ch> writes:

> [[PGP Signed Part:Good signature from B586F7C77239E29E Sébastien Gendre <seb@k-7.ch> (trust ultimate) created at 2024-11-11T00:34:15+0100 using RSA]]
> Hello,
>
> I have solve my 2 problems.
>
>
> For the first one: All drawers are unfolded when agenda indirect follow
> mode show me the selected task.
>
> The solution is simple: By default, when you display the content of an
> Org file, everything is unfolded, including the drawers.
>
> Based on the manual [1], this can be managed with the variable
> `org-startup-folded` or the buffer setting `#+STARTUP:`. By default, the
> variable `org-startup-folded` is set to `showeverything`. Which tell
> Org-mode to unfold every headings, drawers, etc.
>
> I misunderstood the default behavior of Org-mode because, when I tested
> the add of a property to a new heading, the newly created "properties"
> drawer was folded. Same with the "logbook" drawer. But if I save the
> buffer to a file, close it and re-open the file, the drawers are
> unfolded.
>
> For my usage, I decided to keep the default behavior (unfold
> everything). Except for the file that keep my habits. The logbook drawer
> of my habits are too long to be unfolded when displayed by Org-agenda
> indirect follow.
>
>
> For the second problem: When a task have to many lines, the window
> opened by indirect follow mode is too tall, forcing the agenda
> window to be too small to be usable.
>
> Thanks to Karthik Chikmagalur, who tell me that the window behavior of
> Org-mode have changed with a commit from may this year, I updated to
> Org-mode 9.7. And my problem is solved with this new version.
>
>
> That it. I hope my summary is not too long and could help someone else
> with same problem.
>
>
> Have a nice day.
>
>
> [1] https://orgmode.org/manual/Initial-visibility.html
>
>
>
> Sébastien Gendre <seb@k-7.ch> writes:
>
>> [[PGP Signed Part:Good signature from B586F7C77239E29E Sébastien
>> Gendre <seb@k-7.ch> (trust ultimate) created at
>> 2024-11-05T09:02:13+0100 using RSA]]
>> Hello,
>>
>> I have enabled the indirect follow-mode when the agenda start. Now, for
>> each agenda item, I can see the selected item details and only it. Which
>> is great.
>>
>> But I have multiple questions about it.
>>
>>
>> When a task have drawers, they are shown open. How a can I hide
>> them in this indirect follow mode ? I didn't enable the opening of
>> drawers in my config and if I remember they are hidden by default.
>>
>>
>> The display of a task, with the indirect follow mode, is done bellow the
>> agenda, and it's window size is adapted to the length of the task
>> body. But when a task have a lot of text, it's window size take most
>> of the place and the agenda window is too small. How can I prevent the
>> task window to take all the place ?
>>
>>
>> When I want to edit a task and press "TAB", the point is moved to
>> a window that show all the task. Not into the window opened by the
>> indirect follow mode. Is it possible to modify this ?
>>
>>
>>
>> Best regards
>>
>> -------
>> Gendre Sébastien
>>
>>
>> [[End of PGP Signed Part]]
>
> [[End of PGP Signed Part]]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: Indirect follow mode in agenda: Display, edition and how to hide drawers

[Ihor Radchenko]

Sébastien Gendre <seb@k-7.ch> writes:

> Rectification: Adding a "#+STARTUP: overview" on top of my habits
> org-mode file did not change anything with org-agenda follow indirect
> buffer.
>
> Yes, if I manually open my habits org-mode file everything is folded.
> And if I unfold a task, its drawers are still folded. Which is correct.
>
> But when the same task is shown on an indirect buffer by org-agenda
> follow mode, every drawers are unfolded.

Maybe you changed the default value of `org-agenda-inhibit-startup'.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Indirect follow mode in agenda: Display, edition and how to hide drawers

[Sébastien Gendre]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

It's value is set to `nil`.

Ihor Radchenko <yantar92@posteo.net> writes:

> Sébastien Gendre <seb@k-7.ch> writes:
>
>> Rectification: Adding a "#+STARTUP: overview" on top of my habits
>> org-mode file did not change anything with org-agenda follow indirect
>> buffer.
>>
>> Yes, if I manually open my habits org-mode file everything is folded.
>> And if I unfold a task, its drawers are still folded. Which is correct.
>>
>> But when the same task is shown on an indirect buffer by org-agenda
>> follow mode, every drawers are unfolded.
>
> Maybe you changed the default value of `org-agenda-inhibit-startup'.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: Indirect follow mode in agenda: Display, edition and how to hide drawers

[Ihor Radchenko]

Sébastien Gendre <seb@k-7.ch> writes:

> It's value is set to `nil`.

Well. I do not have the described problem on my side.
Then, maybe try emacs -Q and see if the problem ends up somewhere in
your config?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Indirect follow mode in agenda: Display, edition and how to hide drawers

[Sébastien Gendre]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]


I have launch `emacs -Q` and evaluate this on the *scratch* buffer:

    (setq org-agenda-files
               (list "~/Org/Inbox.org"
                     "~/Org/Habits.org"))
    
    (setq org-agenda-start-with-follow-mode t)
    
    (setq org-agenda-follow-indirect t)


I got the same result: Task show inside the indirect follow window show
the logbook drawers expended.



Ihor Radchenko <yantar92@posteo.net> writes:

> Sébastien Gendre <seb@k-7.ch> writes:
>
>> It's value is set to `nil`.
>
> Well. I do not have the described problem on my side.
> Then, maybe try emacs -Q and see if the problem ends up somewhere in
> your config?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: Indirect follow mode in agenda: Display, edition and how to hide drawers

[Ihor Radchenko]

Sébastien Gendre <seb@k-7.ch> writes:

> I have launch `emacs -Q` and evaluate this on the *scratch* buffer:
>
>     (setq org-agenda-files
>                (list "~/Org/Inbox.org"
>                      "~/Org/Habits.org"))
>     
>     (setq org-agenda-start-with-follow-mode t)
>     
>     (setq org-agenda-follow-indirect t)
>
>
> I got the same result: Task show inside the indirect follow window show
> the logbook drawers expended.

I was able to reproduce.
This seems to be deliberate - `org-tree-to-indirect-buffer' explicitly
unfolds everything:

    (org-fold-show-all '(headings drawers blocks))

We can change this, but then we will introduce a surprise to users, so I
am not sure what would be the best approach.

Maybe another customization?

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

May we have a variant of display-buffer-reuse-window that considers indirect buffers? (was: Indirect follow mode in agenda: Display, edition and how to hide drawers)

[Ihor Radchenko]

Hi,

We got a use case when we want to display an Org buffer in other window,
but want to reuse an indirect buffer if it is already present.

May it be possible?
It feels like a natural thing to be available for `display-buffer', but
I cannot find anything.

Sébastien Gendre <seb@k-7.ch> writes:

> When I want to edit a task and press "TAB", the point is moved to
> a window that show all the task. Not into the window opened by the
> indirect follow mode. Is it possible to modify this ?

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: May we have a variant of display-buffer-reuse-window that considers indirect buffers?

[Juri Linkov]

>> When I want to edit a task and press "TAB", the point is moved to
>> a window that show all the task. Not into the window opened by the
>> indirect follow mode. Is it possible to modify this ?
>
> We got a use case when we want to display an Org buffer in other window,
> but want to reuse an indirect buffer if it is already present.
>
> May it be possible?
> It feels like a natural thing to be available for `display-buffer', but
> I cannot find anything.

It's possible to select the necessary window by using 'pop-to-buffer'
while displaying the non-selected window with a simple 'display-window'.

Re: May we have a variant of display-buffer-reuse-window that considers indirect buffers?

[martin rudalics]

 > It's possible to select the necessary window by using 'pop-to-buffer'
 > while displaying the non-selected window with a simple 'display-window'.

                                                          'display-buffer'

I suppose.

martin

Re: May we have a variant of display-buffer-reuse-window that considers indirect buffers?

[Ihor Radchenko]

Juri Linkov <juri@linkov.net> writes:

>> We got a use case when we want to display an Org buffer in other window,
>> but want to reuse an indirect buffer if it is already present.
>>
>> May it be possible?
>> It feels like a natural thing to be available for `display-buffer', but
>> I cannot find anything.
>
> It's possible to select the necessary window by using 'pop-to-buffer'
> while displaying the non-selected window with a simple 'display-window'.

May you please provide more information? AFAIK, `pop-to-buffer' will
search for exact buffer without considering its indirect buffers and
base buffer.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: May we have a variant of display-buffer-reuse-window that considers indirect buffers?

[martin rudalics]

 > May you please provide more information? AFAIK, `pop-to-buffer' will
 > search for exact buffer without considering its indirect buffers and
 > base buffer.

Could you please tell us what you would like 'display-buffer' to do
without referring to org-mode.  IIUC you want it to automatically detect
that if a base buffer has been displayed in a window earlier and BUFFER
is an indirect buffer sharing that base buffer, then it should try to
use that window for the indirect buffer.  Is that assumption correct?

martin

Re: May we have a variant of display-buffer-reuse-window that considers indirect buffers?

[Ihor Radchenko]

martin rudalics <rudalics@gmx.at> writes:

> Could you please tell us what you would like 'display-buffer' to do
> without referring to org-mode.  IIUC you want it to automatically detect
> that if a base buffer has been displayed in a window earlier and BUFFER
> is an indirect buffer sharing that base buffer, then it should try to
> use that window for the indirect buffer.  Is that assumption correct?

Yup.

To be 100% clear, let me try to restate exactly what I have in mind.

I want to call something like

 (pop-to-buffer BUFFER
   '((display-buffer-reuse-window display-buffer-pop-up-window)
     (reuse-indirect . t)))

1. If there is a window displaying BUFFER, switch to that window
2. If there is a window that is an indirect buffer of BUFFER or that
   shares the same base buffer with BUFFER, switch to that window
3. Otherwise, pop up a new window displaying BUFFER

(2) is the feature I am failing to find.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: May we have a variant of display-buffer-reuse-window that considers indirect buffers?

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

 > To be 100% clear, let me try to restate exactly what I have in mind.
 >
 > I want to call something like
 >
 >   (pop-to-buffer BUFFER
 >     '((display-buffer-reuse-window display-buffer-pop-up-window)
 >       (reuse-indirect . t)))
 >
 > 1. If there is a window displaying BUFFER, switch to that window
 > 2. If there is a window that is an indirect buffer of BUFFER or that
 >     shares the same base buffer with BUFFER, switch to that window

I included the facility that if there is a window whose buffer is the
base buffer of BUFFER use that window.  See the attached diff which I
did not test very thoroughly.

martin

[-- Attachment #2: display-indirect-buffer.diff --]
[-- Type: text/x-patch, Size: 4165 bytes --]

diff --git a/lisp/window.el b/lisp/window.el
index e9d57652ec6..31c2ae50792 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -2615,7 +2615,36 @@ get-largest-window
 	  (setq best-window window))))
     best-window))
 
-(defun get-buffer-window-list (&optional buffer-or-name minibuf all-frames)
+(defun window-indirect-buffer-p (&optional window buffer-or-name)
+  "Return non-nil if specified WINDOW is indirectly related to BUFFER-OR-NAME.
+WINDOW must be a live window and defaults to the selected window.
+BUFFER-OR-NAME may be a buffer or the name of an existing buffer and
+defaults to the current buffer.
+
+WINODW is indirectly related to BUFFER-OR-NAME if one of the following
+conditions hold:
+
+- BUFFER-OR-NAME specifies an indirect buffer and WINDOW's buffer is its
+  base buffer.
+
+- WINDOW's buffer is an indirect buffer whose base buffer is the buffer
+  specified by BUFFER-OR-NAME.
+
+- Both, WINDOW's buffer and the buffer specified by BUFFER-OR-NAME, are
+  indirect buffer's sharing the same base buffer.
+
+Return nil if none of the above holds."
+  (let* ((window (window-normalize-window window t))
+	 (window-buffer (window-buffer window))
+	 (window-base-buffer (buffer-base-buffer window-buffer))
+	 (buffer (window-normalize-buffer buffer-or-name))
+	 (buffer-base-buffer (buffer-base-buffer buffer)))
+    (or (eq buffer-base-buffer window-buffer)
+	(eq window-base-buffer buffer)
+	(and buffer-base-buffer
+	     (eq buffer-base-buffer window-base-buffer)))))
+
+(defun get-buffer-window-list (&optional buffer-or-name minibuf all-frames indirect)
   "Return list of all windows displaying BUFFER-OR-NAME, or nil if none.
 BUFFER-OR-NAME may be a buffer or the name of an existing buffer
 and defaults to the current buffer.  If the selected window displays
@@ -2644,11 +2673,17 @@ get-buffer-window-list
 - A frame means consider all windows on that frame only.
 
 Anything else means consider all windows on the selected frame
-and no others."
+and no others.
+
+INDIRECT non-nil means to include in the list returned all windows that
+are indirectly related to BUFFER-OR-NAME, that is, all windows for which
+`window-indirect-buffer-p' with the window and the buffer specified by
+BUFFER-OR-NAME as arguments returns non-nil."
   (let ((buffer (window-normalize-buffer buffer-or-name))
 	windows)
     (dolist (window (window-list-1 (selected-window) minibuf all-frames))
-      (when (eq (window-buffer window) buffer)
+      (when (or (eq (window-buffer window) buffer)
+		(and indirect (window-indirect-buffer-p window buffer)))
 	(setq windows (cons window windows))))
     (nreverse windows)))
 
@@ -8239,20 +8274,24 @@ display-buffer-reuse-window
 node `(elisp) Buffer Display Action Functions'.  It should be
 called only by `display-buffer' or a function directly or
 indirectly called by the latter."
-  (let* ((alist-entry (assq 'reusable-frames alist))
-	 (frames (cond (alist-entry (cdr alist-entry))
+  (let* ((reusable-frames (assq 'reusable-frames alist))
+	 (reuse-indirect (assq 'reuse-indirect alist))
+	 (frames (cond (reusable-frames (cdr reusable-frames))
 		       ((window--pop-up-frames alist)
 			0)
 		       (display-buffer-reuse-frames 0)
 		       (t (last-nonminibuffer-frame))))
-	 (window (if (and (eq buffer (window-buffer))
+	 (window (if (and (or (eq buffer (window-buffer))
+			      (and reuse-indirect
+				   (window-indirect-buffer-p nil buffer)))
 			  (not (cdr (assq 'inhibit-same-window alist))))
 		     (selected-window)
                    ;; Preferably use a window on the selected frame,
                    ;; if such a window exists (Bug#36680).
-                   (let* ((windows (delq (selected-window)
-                                         (get-buffer-window-list
-                                          buffer 'nomini frames)))
+                   (let* ((windows
+			   (delq (selected-window)
+                                 (get-buffer-window-list
+                                  buffer 'nomini frames reuse-indirect)))
                           (first (car windows))
                           (this-frame (selected-frame)))
                      (cond

Re: May we have a variant of display-buffer-reuse-window that considers indirect buffers?

[Ihor Radchenko]

martin rudalics <rudalics@gmx.at> writes:

>  >   (pop-to-buffer BUFFER
>  >     '((display-buffer-reuse-window display-buffer-pop-up-window)
>  >       (reuse-indirect . t)))
>  >
>  > 1. If there is a window displaying BUFFER, switch to that window
>  > 2. If there is a window that is an indirect buffer of BUFFER or that
>  >     shares the same base buffer with BUFFER, switch to that window
>
> I included the facility that if there is a window whose buffer is the
> base buffer of BUFFER use that window.  See the attached diff which I
> did not test very thoroughly.

Thanks!
It seems to work, although somewhat different than I described.

With your diff, in case (2), if BUFFER is what is passed to
`pop-to-buffer' and BUFFER2 is indirectly related buffer displayed in a
visible window, then BUFFER2 is replaced with BUFFER. I expected that
BUFFER2's window will be selected; nothing more.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: May we have a variant of display-buffer-reuse-window that considers indirect buffers?

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

attached.
 >>   > 1. If there is a window displaying BUFFER, switch to that window
 >>   > 2. If there is a window that is an indirect buffer of BUFFER or that
 >>   >     shares the same base buffer with BUFFER, switch to that window
 >>
 >> I included the facility that if there is a window whose buffer is the
 >> base buffer of BUFFER use that window.  See the attached diff which I
 >> did not test very thoroughly.
 >
 > Thanks!
 > It seems to work, although somewhat different than I described.
 >
 > With your diff, in case (2), if BUFFER is what is passed to
 > `pop-to-buffer' and BUFFER2 is indirectly related buffer displayed in a
 > visible window, then BUFFER2 is replaced with BUFFER. I expected that
 > BUFFER2's window will be selected; nothing more.

Hmmm...  This is not really what 'display-buffer' is supposed to do.  I
have to disguise the fact that we wanted to display BUFFER.  I attach a
new patch.

martin

[-- Attachment #2: display-indirect-buffer.diff --]
[-- Type: text/x-patch, Size: 6261 bytes --]

diff --git a/lisp/window.el b/lisp/window.el
index e9d57652ec6..dd030547350 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -2615,7 +2615,36 @@ get-largest-window
 	  (setq best-window window))))
     best-window))
 
-(defun get-buffer-window-list (&optional buffer-or-name minibuf all-frames)
+(defun window-indirect-buffer-p (&optional window buffer-or-name)
+  "Return non-nil if specified WINDOW is indirectly related to BUFFER-OR-NAME.
+WINDOW must be a live window and defaults to the selected window.
+BUFFER-OR-NAME may be a buffer or the name of an existing buffer and
+defaults to the current buffer.
+
+WINODW is indirectly related to BUFFER-OR-NAME if one of the following
+conditions hold:
+
+- BUFFER-OR-NAME specifies an indirect buffer and WINDOW's buffer is its
+  base buffer.
+
+- WINDOW's buffer is an indirect buffer whose base buffer is the buffer
+  specified by BUFFER-OR-NAME.
+
+- Both, WINDOW's buffer and the buffer specified by BUFFER-OR-NAME, are
+  indirect buffer's sharing the same base buffer.
+
+Return nil if none of the above holds."
+  (let* ((window (window-normalize-window window t))
+	 (window-buffer (window-buffer window))
+	 (window-base-buffer (buffer-base-buffer window-buffer))
+	 (buffer (window-normalize-buffer buffer-or-name))
+	 (buffer-base-buffer (buffer-base-buffer buffer)))
+    (or (eq buffer-base-buffer window-buffer)
+	(eq window-base-buffer buffer)
+	(and buffer-base-buffer
+	     (eq buffer-base-buffer window-base-buffer)))))
+
+(defun get-buffer-window-list (&optional buffer-or-name minibuf all-frames indirect)
   "Return list of all windows displaying BUFFER-OR-NAME, or nil if none.
 BUFFER-OR-NAME may be a buffer or the name of an existing buffer
 and defaults to the current buffer.  If the selected window displays
@@ -2644,12 +2673,23 @@ get-buffer-window-list
 - A frame means consider all windows on that frame only.
 
 Anything else means consider all windows on the selected frame
-and no others."
+and no others.
+
+INDIRECT non-nil means to append to the list of windows showing
+BUFFER-OR-NAME a list of all windows that are indirectly related to
+BUFFER-OR-NAME, that is, windows for which `window-indirect-buffer-p'
+with the window and the buffer specified by BUFFER-OR-NAME as arguments
+returns non-nil."
   (let ((buffer (window-normalize-buffer buffer-or-name))
+	(window-list (window-list-1 (selected-window) minibuf all-frames))
 	windows)
-    (dolist (window (window-list-1 (selected-window) minibuf all-frames))
+    (dolist (window window-list)
       (when (eq (window-buffer window) buffer)
 	(setq windows (cons window windows))))
+    (when indirect
+      (dolist (window window-list)
+	(when (window-indirect-buffer-p window buffer)
+	  (setq windows (cons window windows)))))
     (nreverse windows)))
 
 (defun minibuffer-window-active-p (window)
@@ -8235,35 +8275,53 @@ display-buffer-reuse-window
 event that a window on another frame is chosen, avoid raising
 that frame.
 
+If ALIST has a non-nil `reuse-indirect' entry and no window showing
+BUFFER has been found, try to find a window that is indirectly related
+to BUFFER and return that window.  This would be a window for which
+`window-indirect-buffer-p' with the window and BUFFER as arguments
+returns non-nil.
+
 This is an action function for buffer display, see Info
 node `(elisp) Buffer Display Action Functions'.  It should be
 called only by `display-buffer' or a function directly or
 indirectly called by the latter."
-  (let* ((alist-entry (assq 'reusable-frames alist))
-	 (frames (cond (alist-entry (cdr alist-entry))
+  (let* ((reusable-frames (assq 'reusable-frames alist))
+	 (reuse-indirect (assq 'reuse-indirect alist))
+	 (frames (cond (reusable-frames (cdr reusable-frames))
 		       ((window--pop-up-frames alist)
 			0)
 		       (display-buffer-reuse-frames 0)
 		       (t (last-nonminibuffer-frame))))
-	 (window (if (and (eq buffer (window-buffer))
-			  (not (cdr (assq 'inhibit-same-window alist))))
-		     (selected-window)
-                   ;; Preferably use a window on the selected frame,
-                   ;; if such a window exists (Bug#36680).
-                   (let* ((windows (delq (selected-window)
-                                         (get-buffer-window-list
-                                          buffer 'nomini frames)))
-                          (first (car windows))
-                          (this-frame (selected-frame)))
-                     (cond
-                      ((eq (window-frame first) this-frame)
-                       first)
-                      ((catch 'found
-                         (dolist (next (cdr windows))
-                           (when (eq (window-frame next) this-frame)
-                             (throw 'found next)))))
-                      (t first))))))
+	 (inhibit-same (cdr (assq 'inhibit-same-window alist)))
+	 (window
+	  ;; Avoid calling 'get-buffer-window-list' if the selected
+	  ;; window already shows BUFFER and can be used.
+	  (if (and (eq buffer (window-buffer)) (not inhibit-same))
+	      (selected-window)
+            ;; Preferably use a window on the selected frame,
+            ;; if such a window exists (Bug#36680).
+            (let* ((windows-raw
+		    (get-buffer-window-list
+                     buffer 'nomini frames reuse-indirect))
+		   (windows (if inhibit-same
+				(delq (selected-window) windows-raw)
+			      windows-raw))
+                   (first (car windows))
+                   (this-frame (selected-frame)))
+              (cond
+               ((eq (window-frame first) this-frame)
+                first)
+               ((catch 'found
+                  (dolist (next (cdr windows))
+                    (when (eq (window-frame next) this-frame)
+                      (throw 'found next)))))
+               (t first))))))
     (when (window-live-p window)
+      (when (and reuse-indirect
+		 (not (eq (window-buffer window) buffer)))
+	;; Pretend we were asking for a window showing the buffer of
+	;; that window.
+	(setq buffer (window-buffer window)))
       (prog1 (window--display-buffer buffer window 'reuse alist)
 	(unless (cdr (assq 'inhibit-switch-frame alist))
 	  (window--maybe-raise-frame (window-frame window)))))))

Re: May we have a variant of display-buffer-reuse-window that considers indirect buffers?

[Ihor Radchenko]

martin rudalics <rudalics@gmx.at> writes:

>  > It seems to work, although somewhat different than I described.
>  >
>  > With your diff, in case (2), if BUFFER is what is passed to
>  > `pop-to-buffer' and BUFFER2 is indirectly related buffer displayed in a
>  > visible window, then BUFFER2 is replaced with BUFFER. I expected that
>  > BUFFER2's window will be selected; nothing more.
>
> Hmmm...  This is not really what 'display-buffer' is supposed to do.  I
> have to disguise the fact that we wanted to display BUFFER.  I attach a
> new patch.

Now, when you said that, it does feel not right indeed.

What I was concerned about is the situation my request originated from:

1. Org displays a *narrowed* indirect buffer
2. User requests to jump to a heading in base buffer of that indirect
   buffer
3. Changing the buffer (even in the same window - with your patch) will
   suddenly change the narrowing state.

That said, it is not a problem `display-buffer' is supposed to solve
anyway. The modified `get-buffer-window-list' from your patch may also
be used in the above scenario before deciding which buffer we want to
change to.

So, I'd myself vote for the first version of the patch if looking from
more general Emacs perspective.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: May we have a variant of display-buffer-reuse-window that considers indirect buffers?

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]

 >> Hmmm...  This is not really what 'display-buffer' is supposed to do.  I
 >> have to disguise the fact that we wanted to display BUFFER.  I attach a
 >> new patch.
 >
 > Now, when you said that, it does feel not right indeed.
 >
 > What I was concerned about is the situation my request originated from:
 >
 > 1. Org displays a *narrowed* indirect buffer
 > 2. User requests to jump to a heading in base buffer of that indirect
 >     buffer
 > 3. Changing the buffer (even in the same window - with your patch) will
 >     suddenly change the narrowing state.
 >
 > That said, it is not a problem `display-buffer' is supposed to solve
 > anyway. The modified `get-buffer-window-list' from your patch may also
 > be used in the above scenario before deciding which buffer we want to
 > change to.
 >
 > So, I'd myself vote for the first version of the patch if looking from
 > more general Emacs perspective.

I attach a version which does both.  With (reuse-indirect . buffer) it
leaves the window's buffer alone.  With any other value it puts BUFFER
into the window.  Run it for a while and when you think it's useful I'll
install it.

martin

[-- Attachment #2: display-indirect-buffer.diff --]
[-- Type: text/x-patch, Size: 6554 bytes --]

diff --git a/lisp/window.el b/lisp/window.el
index e9d57652ec6..5178e302238 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -2615,7 +2615,36 @@ get-largest-window
 	  (setq best-window window))))
     best-window))
 
-(defun get-buffer-window-list (&optional buffer-or-name minibuf all-frames)
+(defun window-indirect-buffer-p (&optional window buffer-or-name)
+  "Return non-nil if specified WINDOW is indirectly related to BUFFER-OR-NAME.
+WINDOW must be a live window and defaults to the selected window.
+BUFFER-OR-NAME may be a buffer or the name of an existing buffer and
+defaults to the current buffer.
+
+WINODW is indirectly related to BUFFER-OR-NAME if one of the following
+conditions hold:
+
+- BUFFER-OR-NAME specifies an indirect buffer and WINDOW's buffer is its
+  base buffer.
+
+- WINDOW's buffer is an indirect buffer whose base buffer is the buffer
+  specified by BUFFER-OR-NAME.
+
+- Both, WINDOW's buffer and the buffer specified by BUFFER-OR-NAME, are
+  indirect buffer's sharing the same base buffer.
+
+Return nil if none of the above holds."
+  (let* ((window (window-normalize-window window t))
+	 (window-buffer (window-buffer window))
+	 (window-base-buffer (buffer-base-buffer window-buffer))
+	 (buffer (window-normalize-buffer buffer-or-name))
+	 (buffer-base-buffer (buffer-base-buffer buffer)))
+    (or (eq buffer-base-buffer window-buffer)
+	(eq window-base-buffer buffer)
+	(and buffer-base-buffer
+	     (eq buffer-base-buffer window-base-buffer)))))
+
+(defun get-buffer-window-list (&optional buffer-or-name minibuf all-frames indirect)
   "Return list of all windows displaying BUFFER-OR-NAME, or nil if none.
 BUFFER-OR-NAME may be a buffer or the name of an existing buffer
 and defaults to the current buffer.  If the selected window displays
@@ -2644,12 +2673,23 @@ get-buffer-window-list
 - A frame means consider all windows on that frame only.
 
 Anything else means consider all windows on the selected frame
-and no others."
+and no others.
+
+INDIRECT non-nil means to append to the list of windows showing
+BUFFER-OR-NAME a list of all windows that are indirectly related to
+BUFFER-OR-NAME, that is, windows for which `window-indirect-buffer-p'
+with the window and the buffer specified by BUFFER-OR-NAME as arguments
+returns non-nil."
   (let ((buffer (window-normalize-buffer buffer-or-name))
+	(window-list (window-list-1 (selected-window) minibuf all-frames))
 	windows)
-    (dolist (window (window-list-1 (selected-window) minibuf all-frames))
+    (dolist (window window-list)
       (when (eq (window-buffer window) buffer)
 	(setq windows (cons window windows))))
+    (when indirect
+      (dolist (window window-list)
+	(when (window-indirect-buffer-p window buffer)
+	  (setq windows (cons window windows)))))
     (nreverse windows)))
 
 (defun minibuffer-window-active-p (window)
@@ -8235,35 +8275,57 @@ display-buffer-reuse-window
 event that a window on another frame is chosen, avoid raising
 that frame.
 
+If ALIST has a non-nil `reuse-indirect' entry and no window showing
+BUFFER has been found, try to find a window that is indirectly related
+to BUFFER and return that window.  This would be a window for which
+`window-indirect-buffer-p' with the window and BUFFER as arguments
+returns non-nil.  If a suitable window has been found and the cdr of the
+entry equals the symbol `buffer', do not replace the buffer of the
+chosen window with BUFFER but return the window with its old buffer in
+place.  Otherwise, put BUFFER into the chosen window and return the
+window.
+
 This is an action function for buffer display, see Info
 node `(elisp) Buffer Display Action Functions'.  It should be
 called only by `display-buffer' or a function directly or
 indirectly called by the latter."
-  (let* ((alist-entry (assq 'reusable-frames alist))
-	 (frames (cond (alist-entry (cdr alist-entry))
+  (let* ((reusable-frames (assq 'reusable-frames alist))
+	 (reuse-indirect (assq 'reuse-indirect alist))
+	 (frames (cond (reusable-frames (cdr reusable-frames))
 		       ((window--pop-up-frames alist)
 			0)
 		       (display-buffer-reuse-frames 0)
 		       (t (last-nonminibuffer-frame))))
-	 (window (if (and (eq buffer (window-buffer))
-			  (not (cdr (assq 'inhibit-same-window alist))))
-		     (selected-window)
-                   ;; Preferably use a window on the selected frame,
-                   ;; if such a window exists (Bug#36680).
-                   (let* ((windows (delq (selected-window)
-                                         (get-buffer-window-list
-                                          buffer 'nomini frames)))
-                          (first (car windows))
-                          (this-frame (selected-frame)))
-                     (cond
-                      ((eq (window-frame first) this-frame)
-                       first)
-                      ((catch 'found
-                         (dolist (next (cdr windows))
-                           (when (eq (window-frame next) this-frame)
-                             (throw 'found next)))))
-                      (t first))))))
+	 (inhibit-same (cdr (assq 'inhibit-same-window alist)))
+	 (window
+	  ;; Avoid calling 'get-buffer-window-list' if the selected
+	  ;; window already shows BUFFER and can be used.
+	  (if (and (eq buffer (window-buffer)) (not inhibit-same))
+	      (selected-window)
+            ;; Preferably use a window on the selected frame,
+            ;; if such a window exists (Bug#36680).
+            (let* ((windows-raw
+		    (get-buffer-window-list
+                     buffer 'nomini frames reuse-indirect))
+		   (windows (if inhibit-same
+				(delq (selected-window) windows-raw)
+			      windows-raw))
+                   (first (car windows))
+                   (this-frame (selected-frame)))
+              (cond
+               ((eq (window-frame first) this-frame)
+                first)
+               ((catch 'found
+                  (dolist (next (cdr windows))
+                    (when (eq (window-frame next) this-frame)
+                      (throw 'found next)))))
+               (t first))))))
     (when (window-live-p window)
+      (when (and (eq (cdr reuse-indirect) 'buffer)
+		 (not (eq (window-buffer window) buffer)))
+	;; Pretend we were asking for a window showing the buffer of
+	;; that window.
+	(setq buffer (window-buffer window)))
       (prog1 (window--display-buffer buffer window 'reuse alist)
 	(unless (cdr (assq 'inhibit-switch-frame alist))
 	  (window--maybe-raise-frame (window-frame window)))))))

Re: May we have a variant of display-buffer-reuse-window that considers indirect buffers?

[Ihor Radchenko]

martin rudalics <rudalics@gmx.at> writes:

> I attach a version which does both.  With (reuse-indirect . buffer) it
> leaves the window's buffer alone.  With any other value it puts BUFFER
> into the window.  Run it for a while and when you think it's useful I'll
> install it.

Sebastien, would you be interested to test this? I can add a
complementary patch for Org that will work in tandem with this patch for
Emacs.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>