From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#20637: incompatible, undocumented change to vc-working-revision Date: Fri, 15 Apr 2016 15:23:58 +0200 Message-ID: <8737qnc8ep.fsf@gmx.de> References: <6ok2vyzwf9.fsf@fencepost.gnu.org> <08f70cda-44be-0657-e50a-2b2c80d2c21c@yandex.ru> <87oa9dzgl0.fsf@gmx.de> <87potshczh.fsf@gmx.de> <87h9f4ghzg.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1460726728 30500 80.91.229.3 (15 Apr 2016 13:25:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Apr 2016 13:25:28 +0000 (UTC) Cc: 20637@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Apr 15 15:25:15 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1ar3kH-0002Xz-6T for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 Apr 2016 15:25:13 +0200 Original-Received: from localhost ([::1]:34175 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ar3kG-0007Fk-1h for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 Apr 2016 09:25:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35639) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ar3kB-00079q-Jq for bug-gnu-emacs@gnu.org; Fri, 15 Apr 2016 09:25:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ar3k6-00005S-Dt for bug-gnu-emacs@gnu.org; Fri, 15 Apr 2016 09:25:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52282) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ar3k6-00005L-9Z for bug-gnu-emacs@gnu.org; Fri, 15 Apr 2016 09:25:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ar3k5-00012U-UG; Fri, 15 Apr 2016 09:25:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, Dmitry Gutov Resent-Date: Fri, 15 Apr 2016 13:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20637-submit@debbugs.gnu.org id=B20637.14607266493927 (code B ref 20637); Fri, 15 Apr 2016 13:25:01 +0000 Original-Received: (at 20637) by debbugs.gnu.org; 15 Apr 2016 13:24:09 +0000 Original-Received: from localhost ([127.0.0.1]:36386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ar3jF-00011G-6A for submit@debbugs.gnu.org; Fri, 15 Apr 2016 09:24:09 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:55085) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ar3jD-000112-K1 for 20637@debbugs.gnu.org; Fri, 15 Apr 2016 09:24:08 -0400 Original-Received: from detlef.gmx.de ([87.146.62.238]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lyi0B-1bnxSh3ikx-016APw; Fri, 15 Apr 2016 15:24:01 +0200 In-Reply-To: (Dmitry Gutov's message of "Fri, 15 Apr 2016 04:01:02 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-Provags-ID: V03:K0:9QHMAT1qm2BmUcZWyumwZRSlggmDnslHMAsVLfwdg4RUgtwbfuZ PjsL823/tue5PzAmpMFaekJkP1XXErJPR/fPvUQCbSB0VPCQq3581OdyRNmq0OqP3bNfECr 816K2m5VJgl73SBDJINB2/W4ALcYHA69UsYQTf2kOSz2JTnFFoSsHEVEn5GPYRbO/eyHJm+ kTsJk4H70upmfaAHl3w3A== X-UI-Out-Filterresults: notjunk:1;V01:K0:FUglgUxaweg=:v1do8UNJOvFdZHoMAznWQe Jc6BfCIU6pWmlWs6l4s7SdkaVjPN2vTmdk4XUbFpz6Fx5fnx1LOBQO2JtsHdQiqR8FZZaDzFx FKgmMZL7sRQ8GdxOfYXdhKxnU5l/VU/l6RsYDjqnaz+MQ1uUCdSE52w61GzSwIrspwuOFW3uN 2QlduwBDvu3LNRYe804ueP4p7MqHeG+Puaeypq0+OQ/k78NzHowlIBHdJ3HZb+jLp/rcujLz4 ccAxqhB4mJPO/J+idth2m0KDs4jzhIllM3RFnGbji9YNkkIi4985zM7T4z3MORLCP8CT8xb0p 6VpvBJYuP19R39ypjZp99Kh6BlV3SWpGEJAAY0UKeyJRezs23aG94Z6p+NFaFnnS768T5KtXs 32+rWfMq4RNyqWTYOPj9EWLggo7C0ZbnrkC4GU8dstgxJi+p+TxBhTJ2qKxoRQfZYrkIrTEGI 7O13dHaaCHroAgkAgLd08oYqjn0V0RzjZR4HlPnXRXMTQuCmenyOnn2xFMO16NbOt4GkpaaPZ 5Njh9g+UXGuts48WvYs3thyjXSFy9sevtQzDqpg4KF8xpnkFkA/5DuMKw9Arcst6E8EyCxJM9 rHGE0b5G1K77LSzCeUK+wr2flc/QZuu3Yz8ZTLPHTTqrw7bMkggNEFVYizh0yOfzByuxXzL5F asqYeSfrzR/jvXRWc/onvOohmOkNnm1+OS5V8Pgf8KLg0En6Ek0TerN+ezD3mFLZzfyI/LLW8 +Y/vSq4K5Sbz4ZeD61lB8vg6IQTEw4gvpR05GdpbguK2ycSInbaxWa23dTO6I4kYDGTnY5aU X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:116504 Archived-At: Dmitry Gutov writes: > On 04/14/2016 09:31 PM, Michael Albinus wrote: > >> Yes. I hope we could use more file properties caches. To be investigated. > > OK, that could be a fine solution to the problem of vc-registered's > slowness, but it adds complexity. So I'm still in favor of equating > `unregistered' with nil, . I'm not against this. But I would like to see the whole picture first. Where else unregistered is used, and whether we run into conflicts when using nil instead of unregistered. >> And as said already several times, if >> we would document vc-* functions in the manual, it would allow us to >> have a more global view on proposed changes. > > I disagree. The manual is the documentation for the users, to explain > in depth, give examples, et cetera. The docstrings and VC's internal > documentation have to stand on their own. It would be silly if the > difference between `vc-backend' and `vc-responsible-backend' were to > only be explained in the manual, but not in the docstrings. Are we speaking about different manuals? I'm speaking about the =E2=80=98GNU Emacs Lisp Reference Manual=E2=80=99, and not the =E2=80=98GNU Emacs Manual= =E2=80=99 (the manual dedicated to users). > That would also be unfair to people such as myself who prefer to > consult the latter. With your argument, we could nuke the Emacs Lisp manual. Shall we? > So, do you need anything from me in this area? E.g., feel free to give > a list of docstrings that seem insufficient to you, together with what > you feel they are missing. I will start somehow, and show you for review. >> I trust you that you have all involved interfaces in your mind. I >> haven't, and I would like to see how an interface change compares to >> the other interfaces. > > I don't really know everything about VC, I just have some > recollections about dealing with it, as well as experience writing a > third-party package depending on VC's API. > > To get an opinion about the current bug report, I still had to dig > into the code and investigate, look at the commit history, search for > call occurrences, etc. My first sentence above is a rhetorical one, of course :-) >> But you have spoken about >> design decisions in the past (for example whether unregistered files >> could be an argument), which I believe is not documented. > > BTW, we've mentioned it before when fixing my old bug report about VC > using too many process calls > (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D11757#77). Yes, but that's not the documentation! I'm pretty good in forgetting everything, and I don't remember what was said in message 77 of bug report 11757, months ago ... > It may not have even been a deliberate design decision, but it's the > way `vc-state' is used. Which, in turn, allows backend implementations > to be sloppy in the cases that are (almost?) never exercised. > >> And at least for me the "global view" about vc-* functions is missing, >> and how they are related. > > I usually tease that kind of information out by reading the source > code. Is there anything in particular I could help add to your > understanding of the "global view"? Even if I understand it, it won't help any other developer. Let's document it. >> Yep. Pls test my patch, and confirm whether it is sufficient. Same for >> Glenn, if possible. I would like to close this bug then, removing a >> release blocker for Emacs 25.1. > > It must fix this bug, since it reverts to the old code, and testing > Glenn's example from the description confirms as much. > > So I think it can be closed, and the discussion should move to emacs-deve= l. OK, I'm waiting for some few days (maybe Glenn want to say something about), and then I'll close this bug. Thanks for all your help this way! Best regards, Michael.