From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: VC's modeline Date: Tue, 09 Feb 2016 18:13:41 +0100 Message-ID: <87r3glx0vu.fsf@wanadoo.es> References: <20160208185311.9470.7389@vcs.savannah.gnu.org> <56B8F682.7040404@dancol.org> <83io1zosv7.fsf@gnu.org> <56B8FA6D.9070105@dancol.org> <87zivax3li.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1455038262 2504 80.91.229.3 (9 Feb 2016 17:17:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Feb 2016 17:17:42 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 09 18:17:29 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 1aTBuq-0003bq-Qh for ged-emacs-devel@m.gmane.org; Tue, 09 Feb 2016 18:17:28 +0100 Original-Received: from localhost ([::1]:58521 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTBuq-0005n1-3W for ged-emacs-devel@m.gmane.org; Tue, 09 Feb 2016 12:17:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46605) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTBrM-0008PO-MA for emacs-devel@gnu.org; Tue, 09 Feb 2016 12:13:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aTBrJ-0007Qd-Cg for emacs-devel@gnu.org; Tue, 09 Feb 2016 12:13:52 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:36099) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTBrJ-0007QS-53 for emacs-devel@gnu.org; Tue, 09 Feb 2016 12:13:49 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aTBrI-0008FY-2q for emacs-devel@gnu.org; Tue, 09 Feb 2016 18:13:48 +0100 Original-Received: from 1.red-83-38-42.dynamicip.rima-tde.net ([83.38.42.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Feb 2016 18:13:48 +0100 Original-Received: from ofv by 1.red-83-38-42.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Feb 2016 18:13:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 71 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 1.red-83-38-42.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:Q5JAdFiEf5ReIf9rG7P66xfB0J8= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:199614 Archived-At: Stefan Monnier writes: >> Saying that the file is on a directory that also has a .git (or .bzr, or >> whatever) directory is almost meaningless. > > It indicates which backend would be used if the user wants to perform > a VC operation. E.g. for non-managed files, it'd indicate which backend > will be used for `C-x v i' (vc-register). Why should you care about the backend? If you wish to register a file, you do it regardless of the backend. A user can easily lost track of the state of a buffer (is it edited? does it corresponds with the contents of the file on disk? to which branch does in belong?) But if the user forgets about which VCS he is using (suppossing that that info is relevant to him) he has more serious problems than Emacs being slow :-) >> You don't know if the file is actually versioned, nor if it is edited, > > In my experience 99% of Emacs users have no idea that the ":" between > the backend name and the "version info" means that the file is > locally modified. > > Of the remaining 1%, some (at least me; and I presume I'm not the only > one) never look at it and just use `C-x v =' to see what's changed. The info that the VC state gives you is that something changed. Using C-x v = for just checking if the file contains changes is quite a lot of work. > So this info is not of very high value. It is of high value for me. And indeed the colon is hard to notice. That's why I added faces to each of those VC states. >> nor the branch that is currently checked out (this last piece of >> information is specially important on workflows that uses >> colocated branches.) > > That's occasionally useful in Git, indeed. Luckily it's easy/cheap to > obtain this info in Git. Executing a shell command or a M-x command (if there exists one for that purpose) is never as easy as seeing the info right there when you switch to the buffer. It also shows that you are not going to edit some stale buffer that is out of sync with its file after a git operation (this also applies to the VC file state.) >> Personally, I find having that information on the modeline a very worthy >> investment. In practice, the only problem I experience is when working >> on MS Windows, where calling git is much slower than on GNU/Linux and it >> is annoying to wait until all buffers refreshes the VC info after some >> operation with Magit. > > See, we do have a problem. It is a problem for some users. For me and many others it is just an annoyance on certain specific circunstances. > I'm not opposed to having refined info > available, but the current setup where this refined info is > "indispensable" and always needs to be computed eagerly is problematic. > We should arrange for those things to be computed more lazily (and > maybe for that we need to change the UI so it's also *displayed* more > lazily, e.g. only after the user does something). I agree wholeheartedly here. But please note that there is no "eager computation" of the VC modeline, AFAIK. It happens by explicit request from packages like Magit or when the user has auto-revert-mode enabled on those buffers.