GNU bug report logs - #36680
27.0.50; undo-tree visualizer flickering with display-buffer-reuse-frames -> t

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36680 in the body.
You can then email your comments to 36680 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; undo-tree visualizer flickering with
 display-buffer-reuse-frames -> t
Date: Tue, 16 Jul 2019 00:23:30 +0200

Hi,

recipe from emacs -Q, after getting a source of undo-tree:

Copy to scratch and evaluate

(setq display-buffer-reuse-frames t)
(require 'undo-tree)
(undo-tree-mode)

Make some further edits to scratch for testing.  Then

C-x 5 2
C-x u
[up]...

Any time you switch the current node in the visualizer, the first frame
is raised for a very short time, then lowered again.  This is quite
annoying, it makes C-x u quite useless when you have a window in another
frame displaying the current buffer because it distracts me from seeing
what changes in the buffer, I'm unable to see it.  Setting
display-buffer-reuse-frames -> nil fixes this.

The visualizer calls

  (switch-to-buffer-other-window undo-tree-visualizer-buffer-name)

which doesn't seem to behave well in this situation.

TIA,

Michael.


In GNU Emacs 27.0.50 (build 9, x86_64-pc-linux-gnu, GTK+ Version 3.24.5)
 of 2019-07-15 built on drachen
Repository revision: fb725fc0fa320e94daf8e4aa1a3320ba60142449
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux bullseye/sid

Message #8 received at 36680 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Michael Heerdegen <michael_heerdegen <at> web.de>, 36680 <at> debbugs.gnu.org
Subject: Re: bug#36680: 27.0.50; undo-tree visualizer flickering with
 display-buffer-reuse-frames -> t
Date: Wed, 17 Jul 2019 10:39:37 +0200

> (setq display-buffer-reuse-frames t)
> (require 'undo-tree)
> (undo-tree-mode)
>
> Make some further edits to scratch for testing.  Then
>
> C-x 5 2
> C-x u
> [up]...
>
> Any time you switch the current node in the visualizer, the first frame
> is raised for a very short time, then lowered again.  This is quite
> annoying, it makes C-x u quite useless when you have a window in another
> frame displaying the current buffer because it distracts me from seeing
> what changes in the buffer, I'm unable to see it.  Setting
> display-buffer-reuse-frames -> nil fixes this.
>
> The visualizer calls
>
>    (switch-to-buffer-other-window undo-tree-visualizer-buffer-name)
>
> which doesn't seem to behave well in this situation.

I don't know why 'undo-tree' apparently insists on switching to its
buffer here but if you put it on another frame you have to live with
the fact that that frame will be raised.  I think you should make a
special rule for 'display-buffer' to not display the undo tree on a
separate frame.  Note also that 'display-buffer-reuse-frames' is an
obsolete variable.

martin

Message #11 received at 36680 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 36680 <at> debbugs.gnu.org
Subject: Re: bug#36680: 27.0.50; undo-tree visualizer flickering with
 display-buffer-reuse-frames -> t
Date: Thu, 18 Jul 2019 04:38:24 +0200

[Message part 1 (text/plain, inline)]

martin rudalics <rudalics <at> gmx.at> writes:

> I don't know why 'undo-tree' apparently insists on switching to its
> buffer here but if you put it on another frame you have to live with
> the fact that that frame will be raised.

I think you didn't understand what I tried to describe.  I attach a
video demonstration (hope that works).

I don't put the visualizer to another frame, that's not the case and not
the problem.

It's the visualizer that looks if the buffer is displayed not only in
the current frame, but also in another frame, and raises this other
frame when there is one.

> I think you should make a special rule for 'display-buffer' to not
> display the undo tree on a separate frame.

As said, this is not the problem.

> Note also that 'display-buffer-reuse-frames' is an obsolete variable.

I think also other settings could lead to this effect.


Thanks,

Michael.

[Emacs Bug#36680.webm (video/webm, attachment)]

Message #14 received at 36680 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 36680 <at> debbugs.gnu.org
Subject: Re: bug#36680: 27.0.50; undo-tree visualizer flickering with
 display-buffer-reuse-frames -> t
Date: Thu, 18 Jul 2019 05:01:06 +0200

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> As said, this is not the problem.

BTW, the call tree looks like

undo-tree-visualize > switch-to-buffer-other-window
                    > pop-to-buffer with t ACTION
                    > display-buffer with t ACTION
                    > display-buffer-reuse-window

and the last blindly uses the first window in

  (get-buffer-window-list buffer 'nomini frames)

which can be a window of a different frame even if there is a suitable
window in the selected frame.  That's not good IMHO.

Michael.

Message #17 received at 36680 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 36680 <at> debbugs.gnu.org
Subject: Re: bug#36680: 27.0.50; undo-tree visualizer flickering with
 display-buffer-reuse-frames -> t
Date: Thu, 18 Jul 2019 09:49:47 +0200

[Message part 1 (text/plain, inline)]

>> As said, this is not the problem.

You probably should have used an 'inhibit-switch-frame' ALIST entry
then.

> BTW, the call tree looks like
>
> undo-tree-visualize > switch-to-buffer-other-window
>                      > pop-to-buffer with t ACTION
>                      > display-buffer with t ACTION
>                      > display-buffer-reuse-window
>
> and the last blindly uses the first window in
>
>    (get-buffer-window-list buffer 'nomini frames)
>
> which can be a window of a different frame even if there is a suitable
> window in the selected frame.  That's not good IMHO.

OK.  Then please, try the attached patch.  Note that when there's no
suitable window on the selected frame you will still get the annoying
behavior.

Thanks, martin

[display-buffer-reuse-window.diff (text/plain, attachment)]

Message #20 received at 36680 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 36680 <at> debbugs.gnu.org
Subject: Re: bug#36680: 27.0.50; undo-tree visualizer flickering with
 display-buffer-reuse-frames -> t
Date: Thu, 18 Jul 2019 23:13:28 +0200

martin rudalics <rudalics <at> gmx.at> writes:

> You probably should have used an 'inhibit-switch-frame' ALIST entry
> then.

Where would you suggest to do that, as a user, without changing code?
Potentially any arbitrary buffer can be affected.

> OK.  Then please, try the attached patch.

Yes, good, that's what I want - thanks.  I hope no existing code relies
on the old behavior.  But I think it's an improvement, also in other
situations.

> Note that when there's no suitable window on the selected frame you
> will still get the annoying behavior.

In this case it's not trivial what could be done better.  Let's say that
this is not part of my report.


Thanks,

Michael.

Message #23 received at 36680 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 36680 <at> debbugs.gnu.org
Subject: Re: bug#36680: 27.0.50; undo-tree visualizer flickering with
 display-buffer-reuse-frames -> t
Date: Fri, 19 Jul 2019 10:16:07 +0200

>> You probably should have used an 'inhibit-switch-frame' ALIST entry
>> then.
>
> Where would you suggest to do that, as a user, without changing code?
> Potentially any arbitrary buffer can be affected.

It's not trivial, unfortunately.  As a user, one has to identify the
calling undo-tree function.

>> OK.  Then please, try the attached patch.
>
> Yes, good, that's what I want - thanks.

I pushed the change now.

> I hope no existing code relies
> on the old behavior.  But I think it's an improvement, also in other
> situations.

Strictly speaking, the change should be in 'get-buffer-window-list' to
possibly pick a window before the selected one on the selected frame.
But I can't really change the semantics of that.

>> Note that when there's no suitable window on the selected frame you
>> will still get the annoying behavior.
>
> In this case it's not trivial what could be done better.  Let's say that
> this is not part of my report.

OK.  If you see no further problems, please close this bug.

Thanks, martin

Message #28 received at 36680-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 36680-done <at> debbugs.gnu.org
Subject: Re: bug#36680: 27.0.50; undo-tree visualizer flickering with
 display-buffer-reuse-frames -> t
Date: Fri, 19 Jul 2019 23:49:09 +0200

martin rudalics <rudalics <at> gmx.at> writes:

> OK.  If you see no further problems, please close this bug.

I'm happy.  Thanks for working on this.

Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.