GNU bug report logs - #67650
[PATCH] ; Hide completion preview when switching windows

Previous Next

Full log

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 67650 <at> debbugs.gnu.org
Subject: Re: bug#67650: [PATCH] ; Hide completion preview when switching
 windows
Date: Wed, 06 Dec 2023 19:29:32 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> OK, I understand.  However, it means that now we will not only slow
> down every command in the buffer that has the completion-preview mode
> turned on, but we will also slow down every redisplay cycle, even if
> the buffer was not switched.

How so?  The docstring of `window-selection-change-functions` says:

  Functions specified buffer-locally are called for each window showing
  the corresponding buffer if and only if that window has been selected
  or deselected since the last redisplay.

And indeed I see that the function this patch adds to that hook is only
called in those circumstances.  What performance impact do you envision
for other redisplay cycles?

> I think we should find a better way of doing this.

I was also a bit uneasy with extending another hook at first, so I
appreciate your scrutiny, and I'd love to consider different ways to
achieve what we want here.  But so far this is the best way I came up
with, and after testing it and examining the specifics of the case I
feel that it's not such a bad solution.

> How about that idle timer idea we discussed earlier?

I'm not sure I see how that would solve this issue, because we want to
dismiss the preview as soon as you switch windows, and I imagine that an
ideal timer would instead be less prompt to react to such a change.
What do you have in mind?

I also feel that we shouldn't underrate the ability of the current
approach to display the preview immediately.  In fact, one user said
that Completion Preview mode "seems more smooth and efficient" then the
package he was using before, which I attribute to this exact property of
showing the preview without delay.

> I'm beginning to like it more and more, and I have a reason to believe
> this is not the end of more and more hooks you'd need to add if we
> stay with this design.

I share the concern that you're expressing towards excessive use of
hooks, but I can't currently think of further cases in which we'll
/need/ any hook but `post-command-hook` for showing/hiding the preview,
and I think that we're still in the safe zone with this patch.

Perhaps we should wait a few days to see if other suggestions come up?


Thanks,

Eshel

Previous Next

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