GNU bug report logs -
#21969
VC opens new window to display minimal messages
Previous Next
Reported by: David Reitter <david.reitter <at> gmail.com>
Date: Sat, 21 Nov 2015 13:56:02 UTC
Severity: minor
Tags: fixed
Merged with 21518
Found in version 24.5
Fixed in version 25.1
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Sun, 22 Nov 2015 07:01:24 +0200
with message-id <56514C24.7080705 <at> yandex.ru>
and subject line Re: bug#21969: VC opens new window to display minimal messages
has caused the debbugs.gnu.org bug report #21969,
regarding VC opens new window to display minimal messages
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
21969: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21969
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
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.
[Message part 3 (message/rfc822, inline)]
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.
This bug report was last modified 9 years and 232 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.