From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Introducing 'unrecognized and 'ignored Date: Sat, 19 Jan 2008 14:40:20 -0500 Message-ID: References: <17EA38DF-BCC1-4565-8510-5DD10DD667E3@mac.com> <20071229114551.GD9794@thyrsus.com> <20080102021907.GA15494@thyrsus.com> <200801020445.m024jWU2008538@oogie-boogie.ics.uci.edu> <200801031805.m03I5SBf022748@oogie-boogie.ics.uci.edu> <200801050901.m0591mQj011970@oogie-boogie.ics.uci.edu> <20080105143415.GG30869@thyrsus.com> <200801061037.m06AbIRD004966@oogie-boogie.ics.uci.edu> <200801182346.m0INkiEg022130@sallyv1.ics.uci.edu> <200801191705.m0JH5WOU026943@sallyv1.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1200771646 23945 80.91.229.12 (19 Jan 2008 19:40:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Jan 2008 19:40:46 +0000 (UTC) Cc: Tom Tromey , esr@thyrsus.com, harsanyi@mac.com, rms@gnu.org, emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 19 20:41:03 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JGJYo-0003E6-07 for ged-emacs-devel@m.gmane.org; Sat, 19 Jan 2008 20:40:58 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JGJYO-0003Kd-SO for ged-emacs-devel@m.gmane.org; Sat, 19 Jan 2008 14:40:32 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JGJYK-0003Jb-AZ for emacs-devel@gnu.org; Sat, 19 Jan 2008 14:40:28 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JGJYI-0003I9-7r for emacs-devel@gnu.org; Sat, 19 Jan 2008 14:40:27 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JGJYI-0003I1-2q for emacs-devel@gnu.org; Sat, 19 Jan 2008 14:40:26 -0500 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JGJYE-0001Hf-7S; Sat, 19 Jan 2008 14:40:22 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABrhkUfO+KVp/2dsb2JhbACtTX4 X-IronPort-AV: E=Sophos;i="4.25,221,1199682000"; d="scan'208";a="12951266" Original-Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 19 Jan 2008 14:40:20 -0500 Original-Received: from pastel.home ([206.248.165.105]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id ZUH77320; Sat, 19 Jan 2008 14:40:20 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 4F4B0800F; Sat, 19 Jan 2008 14:40:20 -0500 (EST) In-Reply-To: <200801191705.m0JH5WOU026943@sallyv1.ics.uci.edu> (Dan Nicolaescu's message of "Sat, 19 Jan 2008 09:05:24 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:87085 Archived-At: >> I'm not really sure about using generate-new-buffer-name here. >> Presumably each vc-status buffer should have a single vc "work" buffer >> as well. > IMO yes. I did it that way for vc-hg. But it still needs some > management: warn if the buffer already exist and refuse to start a new > status command, remove the buffer after it has been processed. Yes, maybe Tom is right, sorry for telling you to always use a new buffer. Part of the PCL-CVS could probably be reused here because it shouldn't have any CVS dependency, but then again, it may not be worth the trouble. >> After trying this a couple times, I think the user needs an indication >> of whether anything is running. pcl-cvs puts this nicely in the >> buffer... anyway, if you run vc-status on a directory with no changes, >> it can be a little confusing as-is. > Yep. vc-status-refresh and vc-update-vc-status-buffer can insert some > start/end messages similar to PCL-CVS. > It would be nice if we had something more general that is easily > visible for buffers that use VC async commands. > Something like changing the background of a mode-line entry for VC > buffers that are waiting for a command to compile. This should make it > very easy to spot a buffer that is still executing some command. There's the mode-line-process entry, but it's not visible enough. Also the PCL-CVS way of putting the actual command in the buffer turned out to be very useful to double-check what it is doing (and even more so when several commands are running at the same time). > log, diff and annotate could all use this functionality. Indeed, they could use `mode-line-process'. As for on-the-fly updating rather than updating in the end. It's been on my todo list for PCL-CVS, but I never got to it. It'd probably be a good idea to add this from the beginning because it substantially changes the way things work: you have to use a process filter rather than a sentinel, you have to check whether the partial output you have is enough to parse it reliably or whether we need to way for more output, and you have to be able to update the display incrementally. Stefan