From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#21969: VC opens new window to display minimal messages Date: Sun, 22 Nov 2015 03:27:18 +0200 Message-ID: <565119F6.9050008@yandex.ru> References: <906518FC-CA8A-408D-88CC-A44553EB66C6@gmail.com> <56510676.2010305@yandex.ru> <2DD7D456-BD0F-47A7-9138-E771094E169E@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1448155703 26056 80.91.229.3 (22 Nov 2015 01:28:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2015 01:28:23 +0000 (UTC) Cc: 21969@debbugs.gnu.org To: David Reitter Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 22 02:28:11 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 1a0JRp-0001Ee-6x for geb-bug-gnu-emacs@m.gmane.org; Sun, 22 Nov 2015 02:28:09 +0100 Original-Received: from localhost ([::1]:54375 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0JRo-0006nm-Gc for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Nov 2015 20:28:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37085) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0JRl-0006nZ-KA for bug-gnu-emacs@gnu.org; Sat, 21 Nov 2015 20:28:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0JRi-0000GF-D1 for bug-gnu-emacs@gnu.org; Sat, 21 Nov 2015 20:28:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57783) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0JRi-0000GB-8k for bug-gnu-emacs@gnu.org; Sat, 21 Nov 2015 20:28:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a0JRh-0002NJ-PU for bug-gnu-emacs@gnu.org; Sat, 21 Nov 2015 20:28:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 22 Nov 2015 01:28:01 +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.14481556639098 (code B ref 21969); Sun, 22 Nov 2015 01:28:01 +0000 Original-Received: (at 21969) by debbugs.gnu.org; 22 Nov 2015 01:27:43 +0000 Original-Received: from localhost ([127.0.0.1]:47491 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0JRO-0002Mf-L2 for submit@debbugs.gnu.org; Sat, 21 Nov 2015 20:27:42 -0500 Original-Received: from mail-wm0-f46.google.com ([74.125.82.46]:32926) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0JR4-0002MC-2B for 21969@debbugs.gnu.org; Sat, 21 Nov 2015 20:27:40 -0500 Original-Received: by wmec201 with SMTP id c201so117583969wme.0 for <21969@debbugs.gnu.org>; Sat, 21 Nov 2015 17:27:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=qhcYj+tuUMPtJ5dJbOeuLK0Xq+4ukuwLhG5zkWAz1Pg=; b=ET6xWXFPhBNXG2Y9CqFi6gbwfU0QRr0pbTPjkMQxUQQr/0ahPBDjFpF/yCDBIkdQOo NzYlWye2Ab641rkZA/DR578PTTfkEa3YeBcDQoJwBVNhQBecSJocYPMtqRgrEqYXH1CV l9aP0YaLs9J++z6mnoeBYhO2Poo2KiCWFiP3+HeHIKMOThP8j/gro263CS0fYMCZyJlM 5O3Vnn74xeKEWieF0bZmJQwkO0ZPbbhaYiAy5ApliPxI4v7+qLn8UsWxeuXR+o0pDwrk 2x3SKpRaujRhizdfkcGYTEvCImVU42xmxbnPDfE3rPzbgO9zE++jtEhHRN3M7UHckkK6 V3pg== X-Received: by 10.28.111.151 with SMTP id c23mr11312496wmi.28.1448155641470; Sat, 21 Nov 2015 17:27:21 -0800 (PST) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id s189sm6385226wmf.16.2015.11.21.17.27.20 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 21 Nov 2015 17:27:20 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <2DD7D456-BD0F-47A7-9138-E771094E169E@gmail.com> 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:109042 Archived-At: 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.