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

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

[David Reitter]

At some point on the way to Emacs 25, VC has begun creating new windows to display messages that would more appropriately fit into the echo area.

For example, you do C-x =, it’ll display a “no revisions between working revision and work file” message.  But that is shown in the echo area AND a newly created window.

The consequence is that the user has to get rid of the superfluous mini window.  Also, mistakes happen - i.e., opening a new file, the new buffer will display in a window that is only one line high, so one’s got to deal with that.

Bottomline, this shouldn’t happen.  Use the echo area appropriately unless there’s really something to display.

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

[Dmitry Gutov]

On 11/21/2015 03:55 PM, David Reitter wrote:
> At some point on the way to Emacs 25, VC has begun creating new windows to display messages that would more appropriately fit into the echo area.

I can reproduce this, thanks.

> For example, you do C-x =, it’ll display a “no revisions between working revision and work file” message.  But that is shown in the echo area AND a newly created window.

Are there other commands doing the same? It seems we might have to fix 
that separately in each of them.

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

[Dmitry Gutov]

On 11/21/2015 03:55 PM, David Reitter wrote:
> At some point on the way to Emacs 25, VC has begun creating new windows to display messages that would more appropriately fit into the echo area.
>
> For example, you do C-x =, it’ll display a “no revisions between working revision and work file” message.  But that is shown in the echo area AND a newly created window.

Looking at the code, the main reason for this is that the '<backend> 
diff' command is called asynchronously. Before Emacs 25, we made 
exceptions for certain backends (Git, Hg, RCS); not sure why, maybe 
because they're faster that the rest? They're treated the same now, 
since ed6ce56e2.

vc-diff-internal calls the 'diff' backend command, then checks if the 
process in its buffer has finished working and there's no output (which 
might be the case if the command was called *synchronously*), pops a 
window and sets up the code to be executed when the process finishes.

All of which seems reasonable: we can't really pop the window only after 
the process finishes, because if might take some time in certain cases, 
and the user would be still be waiting for anything to happen until then.

So, I'm not sure what's the best course of action here:

- Call 'git diff' synchronously, and leave all other backends with this 
problem.

- Call all 'diff' commands synchronously, and disregard the backends 
that might respond slowly to this command; the user will wait.

- Invent some other solutions, like introduce a timeout which we might 
wait for the backend to respond before popping the window, and abort (?) 
if the user interacts with Emacs during that time.

Suggestions welcome.

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

[David Reitter]

On Nov 21, 2015, at 7:04 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:

> So, I'm not sure what's the best course of action here:
> 
> - Call 'git diff' synchronously, and leave all other backends with this problem.
> 
> - Call all 'diff' commands synchronously, and disregard the backends that might respond slowly to this command; the user will wait.
> 
> - Invent some other solutions, like introduce a timeout which we might wait for the backend to respond before popping the window, and abort (?) if the user interacts with Emacs during that time.


Try this:

Call asynchronously.  Install timeout or sentinel that checks if or when the process has finished.  If it’s just one line, remove the window that was created.

My thinking is that this is likely to be handled so quickly that redisplay will not have time to pop up the window.

However, I can see that this might use low-level functions (pop-to-buffer is very configurable).  

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).

For the 25.1 branch, one could consider just calling it synchronously.

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

[Dmitry Gutov]

On 11/22/2015 03:07 AM, David Reitter wrote:

> Call asynchronously.  Install timeout or sentinel that checks if or when the process has finished.  If it’s just one line, remove the window that was created.

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.

> 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, 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.

> However, I can see that this might use low-level functions (pop-to-buffer is very configurable).

Not sure what's your point here.

> 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"?

> 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?

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.

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.

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

[Dmitry Gutov]

On 11/22/2015 04:28 AM, David Reitter wrote:

> 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”.

Indeed, that would complicate the "undo" logic. Especially the "new 
frames" part.

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

We also have vc-root-diff, which handles the whole repository, and not 
just one file. It would be desirable for the to behave similarly.

> No, just git-diff.

Why just Git?

>> 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,

I've reverted it for Git, Hg, MTN and RCS now, which should bring them 
to the Emacs 24 behavior.

> and then someone (who’s the VC maintainer?)

Take a guess.

You can have this honor, if you like.

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

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 22 Nov 2015 02:04:06 +0200
> 
> Looking at the code, the main reason for this is that the '<backend> 
> diff' command is called asynchronously. Before Emacs 25, we made 
> exceptions for certain backends (Git, Hg, RCS); not sure why, maybe 
> because they're faster that the rest? They're treated the same now, 
> since ed6ce56e2.
> 
> vc-diff-internal calls the 'diff' backend command, then checks if the 
> process in its buffer has finished working and there's no output (which 
> might be the case if the command was called *synchronously*), pops a 
> window and sets up the code to be executed when the process finishes.
> 
> All of which seems reasonable: we can't really pop the window only after 
> the process finishes, because if might take some time in certain cases, 
> and the user would be still be waiting for anything to happen until then.
> 
> So, I'm not sure what's the best course of action here:
> 
> - Call 'git diff' synchronously, and leave all other backends with this 
> problem.
> 
> - Call all 'diff' commands synchronously, and disregard the backends 
> that might respond slowly to this command; the user will wait.
> 
> - Invent some other solutions, like introduce a timeout which we might 
> wait for the backend to respond before popping the window, and abort (?) 
> if the user interacts with Emacs during that time.
> 
> Suggestions welcome.

Why not always show the output in a window, and remove the code that
shows it in the echo area?

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

[Eli Zaretskii]

> From: David Reitter <david.reitter@gmail.com>
> Date: Sat, 21 Nov 2015 21:28:21 -0500
> Cc: 21969@debbugs.gnu.org
> 
> > 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.

FWIW, I think changing it back to synchronous would be a step
backward.

And I also won't like the appearing and disappearing window.  Just
using the popup window always sounds like a better solution.

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

[Dmitry Gutov]

On 11/22/2015 06:08 PM, Eli Zaretskii wrote:

> Why not always show the output in a window, and remove the code that
> shows it in the echo area?

Because showing it in a buffer disturbs the window configuration, and 
you have to press `q' to quit it. Seems reasonable to want to avoid that 
when there's nothing to show.

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

[Dmitry Gutov]

On 11/22/2015 06:20 PM, Eli Zaretskii wrote:

> FWIW, I think changing it back to synchronous would be a step
> backward.

In a sense, it is. But then, if the diff command is fast enough when 
using all backends where I've changed it back, we should be able to live 
with it.

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

[Eli Zaretskii]

> Cc: 21969@debbugs.gnu.org, david.reitter@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 22 Nov 2015 18:45:17 +0200
> 
> On 11/22/2015 06:08 PM, Eli Zaretskii wrote:
> 
> > Why not always show the output in a window, and remove the code that
> > shows it in the echo area?
> 
> Because showing it in a buffer disturbs the window configuration, and 
> you have to press `q' to quit it. Seems reasonable to want to avoid that 
> when there's nothing to show.

How is that different from when Grep doesn't find any hits, or a
compile command produces no output?

IOW, we already have this kind of popping windows elsewhere in Emacs,
so why cannot this use case behave similarly?

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

[David Reitter]

On Nov 22, 2015, at 11:20 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> FWIW, I think changing it back to synchronous would be a step
> backward.

From a technical perspective, perhaps, but not for the user interface in the situation that I described (error message / no changes).

As a user, I would like an echo area message if there are no changes, and a popup window otherwise.  How that is implemented is secondary.

Now, this brings up another idea:  Why not do a fast synchronous status check (if we don’t know) to decide whether to call “diff” asynchronously?

This would be the alternative to doing an async call and opening the window only after a timeout or when the first output arrives.

> And I also won't like the appearing and disappearing window.  Just
> using the popup window always sounds like a better solution.

I think we’ve discarded the appearing/disappearing window idea.

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

[Eli Zaretskii]

> Cc: 21969@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 22 Nov 2015 18:46:39 +0200
> 
> On 11/22/2015 06:20 PM, Eli Zaretskii wrote:
> 
> > FWIW, I think changing it back to synchronous would be a step
> > backward.
> 
> In a sense, it is. But then, if the diff command is fast enough when 
> using all backends where I've changed it back, we should be able to live 
> with it.

When I tried in the past claim that very fast commands don't need to
be asynchronous, there was always someone who'd disagree, on the
premises that there's no "fast enough".

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

[Dmitry Gutov]

On 11/22/2015 06:58 PM, Eli Zaretskii wrote:

> IOW, we already have this kind of popping windows elsewhere in Emacs,
> so why cannot this use case behave similarly?

Because it behaved better in the past?

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

[Dmitry Gutov]

On 11/22/2015 07:00 PM, Eli Zaretskii wrote:

> When I tried in the past claim that very fast commands don't need to
> be asynchronous, there was always someone who'd disagree, on the
> premises that there's no "fast enough".

I'm not saying this is ideal, but I don't like the current solutions either.

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

[Eli Zaretskii]

> Cc: 21969@debbugs.gnu.org, david.reitter@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 22 Nov 2015 19:01:45 +0200
> 
> On 11/22/2015 06:58 PM, Eli Zaretskii wrote:
> 
> > IOW, we already have this kind of popping windows elsewhere in Emacs,
> > so why cannot this use case behave similarly?
> 
> Because it behaved better in the past?

Slower isn't better.

Anyway, you now know my opinions on this, and can use it or disregard
it as you see fit.  I see no reasons for me to continue arguing.

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

[Dmitry Gutov]

On 11/22/2015 07:40 PM, Eli Zaretskii wrote:

> Slower isn't better.

I think we should return to this after someone demonstrates a "slower" 
situation in a real-world scenario.

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

[David Reitter]

On Nov 22, 2015, at 12:41 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:

> I think we should return to this after someone demonstrates a "slower" situation in a real-world scenario.


I think it’s reasonable to assume that local (distributed) VCSs will be fast, while networked ones will be too slow.   In my experience, bzr may be slow even if it runs a local operation.  That’s why I think it’s not a good idea to do exactly the same for every VCS.

(It may be worth coming up with a more general solution that could apply to other external processes as well.)

D

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

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

On 11/22/2015 09:45 AM, David Reitter wrote:
> On Nov 22, 2015, at 12:41 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
>> I think we should return to this after someone demonstrates a "slower" situation in a real-world scenario.
> 
> 
> I think it’s reasonable to assume that local (distributed) VCSs will be fast, while networked ones will be too slow.   In my experience, bzr may be slow even if it runs a local operation.  That’s why I think it’s not a good idea to do exactly the same for every VCS

Believe me, any VCS will be slow once you throw enough files at it. I've
had to disable Emacs Mercurial integration because I was sick of waiting
three seconds for hg status -A and hg log -l1 --template '{rev}' to run
every time I visited a file. I've been working on a _very_ large repository.

I'd rather we always show a window and always run asynchronously.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Dmitry Gutov]

On 11/28/2015 12:26 AM, Daniel Colascione wrote:

> Believe me, any VCS will be slow once you throw enough files at it. I've
> had to disable Emacs Mercurial integration because I was sick of waiting
> three seconds for hg status -A and hg log -l1 --template '{rev}' to run
> every time I visited a file. I've been working on a _very_ large repository.

Sure, you can make anything slow if you try hard enough. But if 'hg 
status' is that slow, you won't try to use vc-diff at all in that 
repository, will you? Then the sync vs async question is moot.

And there's a difference in that you'd often prefer not to wait for the 
status operation to finish, but the user has to invoke vc-diff 
explicitly. It's not like they're going to switch to another task while 
waiting for the asynchronous result, right?

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

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 28 Nov 2015 02:50:42 +0200
> Cc: 21969@debbugs.gnu.org
> 
> On 11/28/2015 12:26 AM, Daniel Colascione wrote:
> 
> > Believe me, any VCS will be slow once you throw enough files at it. I've
> > had to disable Emacs Mercurial integration because I was sick of waiting
> > three seconds for hg status -A and hg log -l1 --template '{rev}' to run
> > every time I visited a file. I've been working on a _very_ large repository.
> 
> Sure, you can make anything slow if you try hard enough. But if 'hg 
> status' is that slow, you won't try to use vc-diff at all in that 
> repository, will you? Then the sync vs async question is moot.
> 
> And there's a difference in that you'd often prefer not to wait for the 
> status operation to finish, but the user has to invoke vc-diff 
> explicitly. It's not like they're going to switch to another task while 
> waiting for the asynchronous result, right?

Given the controversy, would it make sense to have an option that
controls this behavior?

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

[Dmitry Gutov]

On 11/28/2015 10:21 AM, Eli Zaretskii wrote:

> Given the controversy, would it make sense to have an option that
> controls this behavior?

Probably not in 25.1.

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

[Eli Zaretskii]

> Cc: 21969@debbugs.gnu.org, david.reitter@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 28 Nov 2015 14:01:34 +0200
> 
> On 11/28/2015 10:21 AM, Eli Zaretskii wrote:
> 
> > Given the controversy, would it make sense to have an option that
> > controls this behavior?
> 
> Probably not in 25.1.

Is any change planned for this issue in 25.1?  If so, I think the
option should be part of the change.

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

[Dmitry Gutov]

On 11/28/2015 02:15 PM, Eli Zaretskii wrote:

> Is any change planned for this issue in 25.1?

None, as far as I'm concerned. This issue has been closed with a workaround.

We can reconsider this after the release.