bug#21969: VC opens new window to display minimal messages

[David Reitter]

On Nov 21, 2015, at 8:27 PM, Dmitry Gutov <dgutov@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.