GNU bug report logs - #21969
VC opens new window to display minimal messages

Previous Next

Full log

View this message in rfc822 format

From: David Reitter <david.reitter <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 21969 <at> debbugs.gnu.org
Subject: bug#21969: VC opens new window to display minimal messages
Date: Sat, 21 Nov 2015 21:28:21 -0500

On Nov 21, 2015, at 8:27 PM, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> So you would be content with a window that appears, changes layout, and then flips back after 0.1s? I wouldn't like that, myself.

I wouldn’t, either.

> 
>> My thinking is that this is likely to be handled so quickly that redisplay will not have time to pop up the window.
> 
> Setting aside the fact that if it's that fast then we don't need calling it asynchronously,

You don’t know how fast it’s going to be.  I think that’s the whole problem.

> redisplay *will* almost always have the time to show the changes window configuration, simply because it's changed during the command's execution, and any "change back" will have to happen afterwards.

That would be a show-stopper.

> 
>> However, I can see that this might use low-level functions (pop-to-buffer is very configurable).
> 
> Not sure what's your point here.

A user or a package might have configured their Emacs such that new buffers aren’t shown in new windows, but in new frames, for example, and undoing that would not be straightforward.  I don’t know how vc displays the buffer - I was just assuming “pop-to-buffer”.


> 
>> Alternatively, and perhaps that is the correct solution, I would start asynchronously and install a very brief timeout that opens up the new window unless the process has finished with just one line of output (or an error).
> 
> Like my option 3? What can be considered to be a "brief timeout”?

.05s, I’d say.  My “git diff” is way faster than that for a file that hasn’t changed.


> 
>> For the 25.1 branch, one could consider just calling it synchronously.
> 
> For all backends? Including SVN and CVS, which generally have to talk to remote servers, which can respond rather sluggishly?

No, just git-diff.

> I can change it back to synchronous for the mentioned backends (Git, Hg, RCS) now; that's simple. The more advanced solution will have to be written by someone else then.

I would probably change it back for 25.1, and then someone (who’s the VC maintainer?) could work out a more sophisticated solution.  I think async+timeout will be neither difficult nor complicated.

Previous Next

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