all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: David Reitter <david.reitter@gmail.com>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 21969@debbugs.gnu.org
Subject: bug#21969: VC opens new window to display minimal messages
Date: Sat, 21 Nov 2015 21:28:21 -0500	[thread overview]
Message-ID: <0BD66465-870D-44F0-9BB4-8141909FF652@gmail.com> (raw)
In-Reply-To: <565119F6.9050008@yandex.ru>

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.




  reply	other threads:[~2015-11-22  2:28 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-21 13:55 bug#21969: VC opens new window to display minimal messages David Reitter
2015-11-21 18:21 ` Dmitry Gutov
2015-11-22  0:04 ` Dmitry Gutov
2015-11-22  1:07   ` David Reitter
2015-11-22  1:27     ` Dmitry Gutov
2015-11-22  2:28       ` David Reitter [this message]
2015-11-22  5:01         ` Dmitry Gutov
2015-11-22 16:20         ` Eli Zaretskii
2015-11-22 16:46           ` Dmitry Gutov
2015-11-22 17:00             ` Eli Zaretskii
2015-11-22 17:02               ` Dmitry Gutov
2015-11-22 16:58           ` David Reitter
2015-11-22 16:08   ` Eli Zaretskii
2015-11-22 16:45     ` Dmitry Gutov
2015-11-22 16:58       ` Eli Zaretskii
2015-11-22 17:01         ` Dmitry Gutov
2015-11-22 17:40           ` Eli Zaretskii
2015-11-22 17:41             ` Dmitry Gutov
2015-11-22 17:45               ` David Reitter
2015-11-27 22:26                 ` Daniel Colascione
2015-11-28  0:50                   ` Dmitry Gutov
2015-11-28  8:21                     ` Eli Zaretskii
2015-11-28 12:01                       ` Dmitry Gutov
2015-11-28 12:15                         ` Eli Zaretskii
2015-11-28 12:19                           ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0BD66465-870D-44F0-9BB4-8141909FF652@gmail.com \
    --to=david.reitter@gmail.com \
    --cc=21969@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.