From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: vc-state-heuristic is gone Date: Mon, 24 Nov 2014 10:02:59 +0100 Message-ID: <87zjbh3r98.fsf@fencepost.gnu.org> References: <20141123215659.2CA0C382F79@snark.thyrsus.com> <874mtp58a9.fsf@fencepost.gnu.org> <20141124083310.GA29913@thyrsus.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1416819813 28615 80.91.229.3 (24 Nov 2014 09:03:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Nov 2014 09:03:33 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Eric S. Raymond" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 24 10:03:27 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 1XspYM-0007Hf-Km for ged-emacs-devel@m.gmane.org; Mon, 24 Nov 2014 10:03:26 +0100 Original-Received: from localhost ([::1]:51474 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XspYM-0008H2-7l for ged-emacs-devel@m.gmane.org; Mon, 24 Nov 2014 04:03:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44196) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XspY8-0008Gv-IH for emacs-devel@gnu.org; Mon, 24 Nov 2014 04:03:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XspY7-0000Fw-HG for emacs-devel@gnu.org; Mon, 24 Nov 2014 04:03:12 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51758) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XspY7-0000Fr-F6 for emacs-devel@gnu.org; Mon, 24 Nov 2014 04:03:11 -0500 Original-Received: from localhost ([127.0.0.1]:58932 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XspY6-0003FK-PS; Mon, 24 Nov 2014 04:03:11 -0500 Original-Received: by lola (Postfix, from userid 1000) id 41F83DF3F4; Mon, 24 Nov 2014 10:02:59 +0100 (CET) In-Reply-To: <20141124083310.GA29913@thyrsus.com> (Eric S. Raymond's message of "Mon, 24 Nov 2014 03:33:10 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:178159 Archived-At: "Eric S. Raymond" writes: > David Kastrup : >> > Affected back ends: SCCS, RCS, CVS, SVN, Bazaar. I've already tested >> > with RCS and any change in preformance is now so small that a human is >> > not capable of registering it. >> >> For local files, presumably. Both NFS and Tramp exist and are in use, >> however, so the "no cache" philosophy should likely not extend to >> operations which can be triggered repeatedly during keystrokes that do >> not explicitly invoke VC-based operations. > > I hope I am parsing your last sentence correctly. You do not appear > to be suggesting anything about how VC should work, but making a general > observation about *other* modes that have local caching. Not at all. I _am_ suggesting problems with VC operation that are likely to occur with a "no caching needed anywhere" strategy you are proposing. Your statements about the speed of current computers/computing are only valid for locally edited files. Emacs can edit a lot more than just local files, including version controlled files on a remote system. > The next thing I'm going to look at is unifying the status-querying > functions. 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. -- David Kastrup