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: VC command for showing outgoing changes Date: Sun, 06 Dec 2009 20:40:27 -0500 Message-ID: References: <200910132024.n9DKOHGj015040@godzilla.ics.uci.edu> <200912051945.nB5Jjam5020140@godzilla.ics.uci.edu> <200912051952.nB5JqXSm020185@godzilla.ics.uci.edu> <200912060833.nB68XgjU025891@godzilla.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 1260150055 16835 80.91.229.12 (7 Dec 2009 01:40:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Dec 2009 01:40:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 07 02:40:47 2009 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 1NHSak-0003QU-CE for ged-emacs-devel@m.gmane.org; Mon, 07 Dec 2009 02:40:47 +0100 Original-Received: from localhost ([127.0.0.1]:57921 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHSaj-0002y7-Jb for ged-emacs-devel@m.gmane.org; Sun, 06 Dec 2009 20:40:45 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHSab-0002vJ-O2 for emacs-devel@gnu.org; Sun, 06 Dec 2009 20:40:37 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHSaW-0002on-ID for emacs-devel@gnu.org; Sun, 06 Dec 2009 20:40:37 -0500 Original-Received: from [199.232.76.173] (port=55966 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHSaW-0002og-Dm for emacs-devel@gnu.org; Sun, 06 Dec 2009 20:40:32 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:57812 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHSaW-00067B-4G for emacs-devel@gnu.org; Sun, 06 Dec 2009 20:40:32 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgEAI7rG0tMCrV1/2dsb2JhbACBS9NvhDMEih6DBg X-IronPort-AV: E=Sophos;i="4.47,351,1257138000"; d="scan'208";a="50813797" Original-Received: from 76-10-181-117.dsl.teksavvy.com (HELO pastel.home) ([76.10.181.117]) by ironport2-out.pppoe.ca with ESMTP; 06 Dec 2009 20:40:28 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id EEA3680B4; Sun, 6 Dec 2009 20:40:27 -0500 (EST) In-Reply-To: <200912060833.nB68XgjU025891@godzilla.ics.uci.edu> (Dan Nicolaescu's message of "Sun, 6 Dec 2009 00:33:42 -0800 (PST)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: 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:118354 Archived-At: >> [ Another option might be to specify the `outgoing' or `incoming' as >> arguments to vc-print-log or vc-diff. Basically your `vc-(in|out)going' >> is like (vc-print-log from-upstream to working-revision). ] > That looks like it would make vc-print-log more complex Actually I really meant vc-print-log-internal and I don't think it would make it any more complex (it might even stay almost unchanged). The affected code would be the `print-log' operations in the backends. But I don't know enough about how the various backends should/could support incoming/outgoing to know whether it should be folded into the `print-log' operation, or have its own backend operation(s). We can keep them separate for now as your patch did. We can always add default implementations which redirect those to the `print-log' backend operation. > and would make this feature harder to find. That wouldn't preclude new vc-log-incoming and vc-log-outgoing front ends. > How about key bindings? No opinions here, except that they should preferably be related to "log" somehow. >> Also incoming/outgoing will probably want to obey vc-log-short-style, so >> we really want to use as much of vc-print-log-internal as possible here. > It won't work: outgoing/incoming are project wide, so the directory vs > file logic used for vc-log-short-style does not apply. I don't see why it wouldn't work: what you're saying is that it will always follow the `directory' part of that logic. It's OK. Note that there is no fundamental reason why `incoming' and `outgoing' should always apply to the whole tree (tho there might be such a limitation in all current implementations of the backends, but that's another question altogether). > Now there's a permanent-local variable `log-view-type', the values > used for it are 'long 'short 'log-outgoing 'log-incoming. > Currently only 'short is used in any logic. Thanks. Really what this var does is specify the format used, and it will mostly be used in a backend-specific way (after all, you almost always need to know the backend in order to understand the format anyway), so there is no strong need to standardize on particular values. > It would be nice if log-view-mode had an optional parameter to pass > this info. But maybe adding optional arguments to major modes is > a big no-no. For one, it's a big no-no, indeed. But also, log-view-type really describes the buffer's content, so it makes a lot of sense for it to be permanent-local. Actually, for that same reason, we may prefer to name it vc-log-type. Look at it this way: it's called "log-view-type", is declared in log-view.el, and yet log-view.el doesn't make any use of it: Not good. >> We could still define a generic `log-view-type' or `log-view-format' >> variable for it, tho. The idea is that the generic part of the code may >> want to use it, e.g. to display it in the mode-line (and let button-2 >> run a command that changes the format to something else). But it should >> be set by the backend's `print-log' operation rather than by the >> generic code. > Why should the backend set this? Because it's (currently) only ever used in the backend's log-view-mode, i.e. it's really an internal issue of the backend. Many backends don't have that much choice, other backends allow more choices of formats, also some backends may prefer to use a vc-log-message-re that simply matches all relevant formats, thu not needing log-view-type at all. > It looks more cumbersome if all backends had to take care of doing it. Not all of them would need it. And it would make it easier to extend the set of formats for specific backends. Your new patch looks closer, thanks. But we also still need to factor out the commonality between vc-incoming-outgoing-internal and vc-print-log-internal. Stefan