From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Re: vc-state-heuristic is gone Date: Mon, 24 Nov 2014 04:49:29 -0500 Organization: Eric Conspiracy Secret Labs Message-ID: <20141124094929.GA32148@thyrsus.com> References: <20141123215659.2CA0C382F79@snark.thyrsus.com> <874mtp58a9.fsf@fencepost.gnu.org> <20141124083310.GA29913@thyrsus.com> <87zjbh3r98.fsf@fencepost.gnu.org> Reply-To: esr@thyrsus.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1416822630 9301 80.91.229.3 (24 Nov 2014 09:50:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Nov 2014 09:50:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 24 10:50:24 2014 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 1XsqHo-0001dn-7o for ged-emacs-devel@m.gmane.org; Mon, 24 Nov 2014 10:50:24 +0100 Original-Received: from localhost ([::1]:51696 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsqHn-0006rH-SB for ged-emacs-devel@m.gmane.org; Mon, 24 Nov 2014 04:50:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsqHD-0006a1-SC for emacs-devel@gnu.org; Mon, 24 Nov 2014 04:49:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XsqH8-0002Hf-92 for emacs-devel@gnu.org; Mon, 24 Nov 2014 04:49:47 -0500 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:57421 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsqGw-0002CS-G0; Mon, 24 Nov 2014 04:49:30 -0500 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id D776A383670; Mon, 24 Nov 2014 04:49:29 -0500 (EST) Content-Disposition: inline In-Reply-To: <87zjbh3r98.fsf@fencepost.gnu.org> X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 71.162.243.5 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:178160 Archived-At: David Kastrup : > If I get a VC call across an ssh link for every keystroke I make in some > Tramp-edited buffer because the modeline wants to display the non-cached > current branch I am on, this is not going to lead to happy editing. Why do you suppose this could ever occur? There is not and never has been any VC code that fires on an ordinary keystroke - that is, one that is not bound as a VC command. The branch field, in particular, would only have to be updated when a VC operation that could potentially change it is invoked. My guess is that you have "removing caching" somewhat confused with "bulletproofing VC against operations going on behind its back". Removing the ancient caching code is partial hardening against those - it does eliminate *some* TOCTOU conditions, which as I previously noted is one reason it's a good idea. But the main goal was to reduce the complexity of the mode code, not futilely attempt to prevent *every* potential way that an out-of-VC operation could invalidate VC's stored state. That would be a crazy, infeasably expensive thing to do, and I'm certainly not going to try it. What my changes do is make the old modes that used to cache a lot of state approximately as safe as the modern ones that don't, like git's. That is, VC will behave reasonably in the face of operations done outside it context *through the ordinary VCS commands*. That is, your branch tag display might get stale, but that would be about the worst of it; VC operations made from an incorrect state will generally error out harmlessly rather than doing something nasty. -- Eric S. Raymond