From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: VC mode and git Date: Wed, 25 Mar 2015 13:18:36 +0900 Message-ID: <87sictlnfn.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87384tna6c.fsf@uwakimon.sk.tsukuba.ac.jp> <20150325020126.GA9853@thyrsus.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1427257138 24778 80.91.229.3 (25 Mar 2015 04:18:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Mar 2015 04:18:58 +0000 (UTC) Cc: Stefan Monnier , Richard Stallman , emacs-devel@gnu.org To: esr@thyrsus.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 25 05:18:49 2015 Return-path: Envelope-to: ged-emacs-devel@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 1YacmE-0003nM-BB for ged-emacs-devel@m.gmane.org; Wed, 25 Mar 2015 05:18:46 +0100 Original-Received: from localhost ([::1]:36055 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YacmD-0006Yb-4p for ged-emacs-devel@m.gmane.org; Wed, 25 Mar 2015 00:18:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32803) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YacmA-0006YT-6K for emacs-devel@gnu.org; Wed, 25 Mar 2015 00:18:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yacm7-0005Hh-0a for emacs-devel@gnu.org; Wed, 25 Mar 2015 00:18:42 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:34129) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yacm6-0005HF-NQ; Wed, 25 Mar 2015 00:18:38 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 425141C3864; Wed, 25 Mar 2015 13:18:36 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 29141120EC9; Wed, 25 Mar 2015 13:18:36 +0900 (JST) In-Reply-To: <20150325020126.GA9853@thyrsus.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:184196 Archived-At: Eric S. Raymond writes: > Stephen J. Turnbull : > > Perhaps rather than assuming a universal meaning for DWIM, C-x v v > > could implement a limited concept of "workflow". Eg, a workflow could > > be modeled by a list ((LEXP1 OP1) (LEXP2 OP2) ...), and the workflow > > would be implemented something like > > > > (catch 'done > > (mapc (lambda (kv) > > (let ((lexp (first kv)) > > (op (second kv))) > > (if (eval lexp) (throw (funcall op))))))) > > > > A couple of default workflows could be provided. > > That sounds like lots of complexity for small gain to me. The complexity is already there, it's just hardwired and inflexible, and would become much more complex for not so much flexiblity if you provide a couple of optional hardwired workflows. But I'm not volunteering to implement and maintain either, so I guess the point is moot.