From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master de76a16: Performance improvements for vc-hg Date: Mon, 8 Feb 2016 13:09:01 -0800 Message-ID: <56B903ED.2090507@dancol.org> References: <20160208185311.9470.7389@vcs.savannah.gnu.org> <56B8F682.7040404@dancol.org> <83io1zosv7.fsf@gnu.org> <56B8FA6D.9070105@dancol.org> <83fux2q5ma.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pv3qDHB0jP99I6I2jTs6Bam0PoLBOHmWe" X-Trace: ger.gmane.org 1454965772 22581 80.91.229.3 (8 Feb 2016 21:09:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Feb 2016 21:09:32 +0000 (UTC) Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 08 22:09: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 1aSt3m-0003TY-LU for ged-emacs-devel@m.gmane.org; Mon, 08 Feb 2016 22:09:26 +0100 Original-Received: from localhost ([::1]:48864 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSt3m-0000wY-1c for ged-emacs-devel@m.gmane.org; Mon, 08 Feb 2016 16:09:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSt3W-0000wR-Dd for emacs-devel@gnu.org; Mon, 08 Feb 2016 16:09:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aSt3V-0007Cg-CV for emacs-devel@gnu.org; Mon, 08 Feb 2016 16:09:10 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:36708) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSt3U-0007CK-U1; Mon, 08 Feb 2016 16:09:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=r6auIwVwSdhV92N0lg8U7b/vUjhiqNFjAu2XUwnd8gY=; b=JMLXwaxr2w9ZEzUMisu1B6uQYhKCmowg9iuvuuaEE+qsY1h/04gsIDRpKHRJsoT6jw8Q065L76g/OmoUWyV3gUs/f9dZzuQg1Xy6sAbuC2rGf+wCUM8DFoQKzo2kPiJ8/UiWLsjFTwfGeC0glOT9t1s9XgHUE7HiVuTj4ndW3PjGjOnNOTnr+L/3LkUrxL4/Azo8g1YWVEJkyyj7lYCKfJVO1kT7WGsLcu6kuC37UUKyhADi2en4NRDC+UAtWaXvl++9zOonCagq5lIMqL80eSpS/k/MUoZYcVzax46I9sC5d8ZucQ40eM5U0Mnixl6evcBuHLWw9Ef2I1vlNTojtw==; Original-Received: from [2620:10d:c090:200::9:5509] (helo=[IPv6:2620:10d:c083:10fb:2ab2:bdff:fe1c:db58]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1aSt3T-0006Qu-4G; Mon, 08 Feb 2016 13:09:07 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 In-Reply-To: <83fux2q5ma.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:199559 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pv3qDHB0jP99I6I2jTs6Bam0PoLBOHmWe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/08/2016 01:01 PM, Eli Zaretskii wrote: >> 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. >=20 > It could be the tip of an iceberg. If it were, I'd have expected problems to crop up for a long time. vc has been running status on find-file for a very long time. >> 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. >=20 > I didn't suggest making VC an option. I suggested to make running the > "status" command optional. >=20 >> Under what circumstances should a user enable the feature? >=20 > When she wants the mode line to display whatever it is that we display > there. >=20 > "When >> he's willing to pay the cost" is the answer I expect. >=20 >=20 >> How is he supposed to know the feature even exists? >=20 > How do users know about the existence of any other feature? This one > is no different. You could use the same argument to suggest making auto-mode-alist blank by default. Users can enable the modes they want, and we wouldn't want to impose costs on users by enabling features they don't want. It's okay for some features to be on by default. vc is one of those features. I have seen nothing to suggest that we can't keep doing what we've been doing for a very long time. >=20 >> 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. >=20 > For a single VCS, and not the most important one. >=20 > 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. It's a classical lock ordering problem; the classical lock ordering solutions apply, including using try-lock instead of locking repositories and running the status command asynchronously, so that if it never completes, interactivity isn't harmed. Not doing anything that might "make[] changes in the filsystem" is far too cautious. --pv3qDHB0jP99I6I2jTs6Bam0PoLBOHmWe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWuQPtAAoJEN4WImmbpWBl5IIP/2sIeuhqO3I7wk1N83IKfCiu kxlvPpw0qX07awvjE4TUNAgDIrcCmzXU/nrghVeFO21cHBvL/8133Y+2J5ROe0JU mHGtokuWHtfb9e1aIMaBvDL5ZmsWkKePbq1U6GxIfRYZpcqpJdHM5uaQU5RYY/mw XEj3JFhl0UM1O6nm9IvDFftpteZ7AMoIeqHebEWzU0Z8BS5iiDHVlkw0r7cEuPVi vUf8AUJxs8trl6tEYFT40VBIjnZDnBMrknzIrUOEfcVgP+8XRjAlUBjrdC0A2ZA4 yZH5R8HbBNk3fUEr660ZHikgZGxObxgiIHz0w9dHnZnEpPVEI5K1QrYmRrMXARGU 2sS4CltcQQYTb5uzPXvigjFszbsHYsq8wkSyr2JqNluQQk6qjpxI4SJcz8e4JvAu ZjCdeZhvF4DGSfrO2teZxzTo7mALT+nAdjgYP1s1nsKM5GBZ1bNKTS1eVDCevIIJ FK5MaJ77HBXgJjXkpw3YsHZyK1G+YvQ9Ew823G5cuFiR/ckS4xIy/TYi0Ft6VoKr KphgCNkt6fIcg996pOwUP/vtKEWaXEV2gYBu3xW5v6HeqMP5Ilyh6pY+D1falzwz Np4//phCml6aXgeDogdREPOHevcYwGWznnPAKCzFd9ux4dnR7IIyD8J/oqedRA/T 2EvZsRExZtxYE++0U81r =d014 -----END PGP SIGNATURE----- --pv3qDHB0jP99I6I2jTs6Bam0PoLBOHmWe--