From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Reitter Newsgroups: gmane.emacs.bugs Subject: bug#21969: VC opens new window to display minimal messages Date: Sat, 21 Nov 2015 21:28:21 -0500 Message-ID: <0BD66465-870D-44F0-9BB4-8141909FF652@gmail.com> References: <906518FC-CA8A-408D-88CC-A44553EB66C6@gmail.com> <56510676.2010305@yandex.ru> <2DD7D456-BD0F-47A7-9138-E771094E169E@gmail.com> <565119F6.9050008@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1448159362 8163 80.91.229.3 (22 Nov 2015 02:29:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2015 02:29:22 +0000 (UTC) Cc: 21969@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 22 03:29:10 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a0KOs-0000fr-0z for geb-bug-gnu-emacs@m.gmane.org; Sun, 22 Nov 2015 03:29:10 +0100 Original-Received: from localhost ([::1]:54510 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0KOr-0003yh-Ci for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Nov 2015 21:29:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0KOn-0003yK-Qw for bug-gnu-emacs@gnu.org; Sat, 21 Nov 2015 21:29:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0KOk-00032I-ID for bug-gnu-emacs@gnu.org; Sat, 21 Nov 2015 21:29:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57806) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0KOk-00032D-ER for bug-gnu-emacs@gnu.org; Sat, 21 Nov 2015 21:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a0KOk-00054S-BH for bug-gnu-emacs@gnu.org; Sat, 21 Nov 2015 21:29:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: David Reitter Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 22 Nov 2015 02:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21969 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21969-submit@debbugs.gnu.org id=B21969.144815930619348 (code B ref 21969); Sun, 22 Nov 2015 02:29:02 +0000 Original-Received: (at 21969) by debbugs.gnu.org; 22 Nov 2015 02:28:26 +0000 Original-Received: from localhost ([127.0.0.1]:47514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0KO9-00051y-JA for submit@debbugs.gnu.org; Sat, 21 Nov 2015 21:28:25 -0500 Original-Received: from mail-qk0-f170.google.com ([209.85.220.170]:36636) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0KO7-00051l-IT for 21969@debbugs.gnu.org; Sat, 21 Nov 2015 21:28:24 -0500 Original-Received: by qkda6 with SMTP id a6so48374197qkd.3 for <21969@debbugs.gnu.org>; Sat, 21 Nov 2015 18:28:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=deQl/B6CTQXIwqsWyG2in95NX7vfIB+WGSX/kzy3iis=; b=JVduKhMaEqtkO47rsCxDZdJaLb5jSIPQDqNBF6u6XJNRfAQlUjRXR6TbkVNaHCm/MI SG54RJ3boAE1BUWsMXv7SaOdrBZa3C65A3fyJVSxk7T7BQvG7YSA8l36ZcXZ80SUN47+ pG1CvxdxmjOn4FBZrMvkjIr4G51gu9xWAAqs2TeKBNNSD8iOsxPDtAI7Dfn0cyJUwHBF 5QvWh94vADnris7G5Qng0D3+aBD/WEffFKtnLPLhjs3oqtpw0AdL1YskfM4Y+otD8g8J 83zMYwsyQDsqMY/oVdIKjvJatLH3DQd1J0KsCS1BzDfE3/WZjS71EHBCHqpe58FNxTDX trJg== X-Received: by 10.55.22.13 with SMTP id g13mr20821011qkh.8.1448159303037; Sat, 21 Nov 2015 18:28:23 -0800 (PST) Original-Received: from [10.0.1.23] (c-71-58-212-112.hsd1.pa.comcast.net. [71.58.212.112]) by smtp.gmail.com with ESMTPSA id f133sm1522938qkb.22.2015.11.21.18.28.21 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 21 Nov 2015 18:28:22 -0800 (PST) In-Reply-To: <565119F6.9050008@yandex.ru> X-Mailer: Apple Mail (2.3094) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:109044 Archived-At: On Nov 21, 2015, at 8:27 PM, Dmitry Gutov 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=E2=80=99t, either. >=20 >> My thinking is that this is likely to be handled so quickly that = redisplay will not have time to pop up the window. >=20 > Setting aside the fact that if it's that fast then we don't need = calling it asynchronously, You don=E2=80=99t know how fast it=E2=80=99s going to be. I think = that=E2=80=99s 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. >=20 >> However, I can see that this might use low-level functions = (pop-to-buffer is very configurable). >=20 > Not sure what's your point here. A user or a package might have configured their Emacs such that new = buffers aren=E2=80=99t shown in new windows, but in new frames, for = example, and undoing that would not be straightforward. I don=E2=80=99t = know how vc displays the buffer - I was just assuming = =E2=80=9Cpop-to-buffer=E2=80=9D. >=20 >> 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). >=20 > Like my option 3? What can be considered to be a "brief timeout=E2=80=9D= ? .05s, I=E2=80=99d say. My =E2=80=9Cgit diff=E2=80=9D is way faster than = that for a file that hasn=E2=80=99t changed. >=20 >> For the 25.1 branch, one could consider just calling it = synchronously. >=20 > 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=E2=80=99s = the VC maintainer?) could work out a more sophisticated solution. I = think async+timeout will be neither difficult nor complicated.=