ement-room-list should not call display-buffer when reverting (display-buffer-alist may conflict when customized)

[mekeor]

When I evaluate

  (add-to-list 'display-buffer-alist
    '(always (display-buffer-reuse-window display-buffer-same-window)))

then the *Ement Room List* buffer is frequently, disturbingly reopened all the time. Is this expected behaviour? I don't think so.

[alphapapa]

Hello,

The code in question appears to be here:

ement.el/ement-room-list.el

Lines 629 to 632 in 28de42d

	(defun ement-room-list-revert (_ignore-auto _noconfirm)
	"Revert current Ement-Room-List buffer."
	(interactive)
	(ement-room-list :display-buffer-action '(display-buffer-no-window (allow-no-window . t))))

I guess you're overriding the alist there, '(display-buffer-no-window (allow-no-window . t)), which causes the window to be redisplayed when the room list buffer is refreshed, which happens each time an update is received from the Matrix server.

The easiest solution would probably be for you to adjust your display-buffer-alist to not affect the *Ement Room List* buffer. Alternatively, some of the code in question could be refactored to not call display-buffer. Or maybe the ement-room-list function could be modified to not call display-buffer when its :display-buffer-alist argument is nil.

What do you think? Thanks.

[mekeor]

2023-01-20 03:46 ***@***.***:

Hello,

Hello :)

The code in question appears to be here: https://github.com/alphapapa/ement.el/blob/28de42d653cc1e254cc3dccfcb685db947cdde4c/ement-room-list.el#L629 I guess you're overriding the alist there, '(display-buffer-no-window (allow-no-window . t)), which causes the window to be redisplayed when the room list buffer is refreshed, which happens each time an update is received from the Matrix server.

Thanks for explaining!

The easiest solution would probably be for you to adjust your display-buffer-alist to not affect the *Ement Room List* buffer.

Yes, that seems to work: ```elisp (add-to-list 'display-buffer-alist (list (defun /display-buffer-not-ement-room-list (buffer-name _) (not (string-equal buffer-name "*Ement Room List*"))) '(display-buffer-reuse-window display-buffer-same-window))) ```

Alternatively, some of the code in question could be refactored to not call display-buffer. Or maybe the ement-room-list function could be modified to not call display-buffer when its :display-buffer-alist argument is nil. What do you think? Thanks.

From the perspective of an Ement-user, it'd be nicer if Ement would not call `display-buffer` in the first place. What's even the reason it does call it? I mean, the buffer is not meant to be displayed in this situation, right? Without understanding the code, it seems, Ement is hijacking the display-buffer stuff for another purpose. But for me, personally, it does not matter. It works. :)

[alphapapa]

From the perspective of an Ement-user, it'd be nicer if Ement would not call display-buffer in the first place. What's even the reason it does call it? I mean, the buffer is not meant to be displayed in this situation, right? Without understanding the code, it seems, Ement is hijacking the display-buffer stuff for another purpose.

It's an implementation detail: the command to show the room list buffer shows the buffer, of course. The command to refresh that buffer calls the same command again, but it does so with an argument that causes display-buffer to not actually display the buffer. That works as intended, unless the user customizes display-buffer-alist to override that behavior, as you did.

Of course, there's nothing wrong with your doing that, so, yes, probably the command should not call display-buffer at all when refreshing the buffer. It will take a few lines of code, but it will be more correct.

I'll intend to make this fix in v0.6. Thanks for reporting it.

[mekeor]

Of course, there's nothing wrong with your doing that, so, yes, probably the command should not call display-buffer at all when refreshing the buffer. It will take a few lines of code, but it will be more correct. I'll intend to make this fix in v0.6. Thanks for reporting it.

Thanks for taking time and effort to explain. And thanks for fixing.