From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master de76a16: Performance improvements for vc-hg Date: Mon, 08 Feb 2016 23:01:01 +0200 Message-ID: <83fux2q5ma.fsf@gnu.org> References: <20160208185311.9470.7389@vcs.savannah.gnu.org> <56B8F682.7040404@dancol.org> <83io1zosv7.fsf@gnu.org> <56B8FA6D.9070105@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1454965292 14883 80.91.229.3 (8 Feb 2016 21:01:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Feb 2016 21:01:32 +0000 (UTC) Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 08 22:01:27 2016 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 1aSsw1-0000xX-OQ for ged-emacs-devel@m.gmane.org; Mon, 08 Feb 2016 22:01:25 +0100 Original-Received: from localhost ([::1]:48804 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSsw1-00070b-3x for ged-emacs-devel@m.gmane.org; Mon, 08 Feb 2016 16:01:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60882) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSsvx-0006zY-J1 for emacs-devel@gnu.org; Mon, 08 Feb 2016 16:01:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aSsvu-0004hB-9S for emacs-devel@gnu.org; Mon, 08 Feb 2016 16:01:21 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37763) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSsvu-0004h0-78; Mon, 08 Feb 2016 16:01:18 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1714 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aSsvs-0000Nt-SW; Mon, 08 Feb 2016 16:01:17 -0500 In-reply-to: <56B8FA6D.9070105@dancol.org> (message from Daniel Colascione on Mon, 8 Feb 2016 12:28:29 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:199558 Archived-At: > Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org > From: Daniel Colascione > Date: Mon, 8 Feb 2016 12:28:29 -0800 > > >> I find the information useful, and we can now get it cheaply. > > > > We are paying a non-trivial price as a project for that information, > > see for example bug#21559. Maybe it should be an option, off by > > default? > > bug#21559 is a corner case. It could be the tip of an iceberg. > vc has been in place for decades, and is one of the things that makes > programming on Emacs pleasant. I'm not in favor of just removing the > feature because there are a few unfixed bugs. There is nothing > fundamentally wrong with the model. > > Making vc itself an option that's off by default makes no sense. I didn't suggest making VC an option. I suggested to make running the "status" command optional. > Under what circumstances should a user enable the feature? When she wants the mode line to display whatever it is that we display there. "When > he's willing to pay the cost" is the answer I expect. > How is he supposed to know the feature even exists? How do users know about the existence of any other feature? This one is no different. > There is no reason that vc integration can't work well and be on by > default. It was working before my change; now it works better. For a single VCS, and not the most important one. The problem with calling "status" is that locks the repository, makes changes in the filesystem, and interferes with Emacs features that are sensitive to changes in the filesystem. Making it optional could be the only solution to that conundrum. > A reasonable performance improvement should not be an occasion for > discussing the removal of a feature made faster. No one suggested removing the feature, this is a misunderstanding.