unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: 20637@debbugs.gnu.org
Subject: bug#20637: incompatible, undocumented change to vc-working-revision
Date: Thu, 14 Apr 2016 17:20:41 +0300	[thread overview]
Message-ID: <e3132bc6-f1d4-ebef-00d4-93fa0807fea0@yandex.ru> (raw)
In-Reply-To: <87potshczh.fsf@gmx.de>

On 04/14/2016 10:21 AM, Michael Albinus wrote:

> I haven't thought too much about performance. But you are right, we
> shouldn't add serious performance penalties to the code. And improving
> performance for the 25.1 release is much too late.

It's hard for me to judge how serious those are, really (I only have a 
fast laptop with GNU/Linux these days), but being wary of extra process 
calls seems prudent. Ideally, we'd reduce their number, not increase it.

> So we might revert the patch for vc-state and vc-working-revision indeed
> for the emacs-25 branch, going back to using vc-backend.

Thanks, I agree.

> In the master branch we might apply my proposed patch using
> vc-registered or something similar, and start to improve performance.

Improve how? Would you like to comment on the last paragraph of my 
previous email in this subthread?

I don't really see a point in returning `unregistered' from `vc-state'. 
When would the caller treat it differently from nil? And returning nil 
seems like an easier choice, implementation-wise, and well as a more 
conservative one from the backward compatibility perspective.

The `dir-status-files' backend command would continue including the 
`unregistered' entries (we could make it skip the up-to-date ones, 
though, in the interest of improving performance).

> In
> parallel, we shall start to write a VCS section for the elisp manual,
> describing vc-* functionality in more detail. We could start with
> vc-backend and vc-responsible-backend and their intended use. I'm
> missing such documentation for years.

I'd rather put the missing information into the docstrings, really. It 
seems unlikely that we're missing more than a few sentences in these two 
functions' descriptions, and we could also rephrase the existing ones.

But if you'd be more comfortable with having that information in the 
manual as well, don't let me stop you.

> I'll come back later today with the patch for emacs-25, if you agree.

In any case, I definitely agree with reverting vc-state and 
vc-working-revision to use vc-backend in Emacs 25.1.





  reply	other threads:[~2016-04-14 14:20 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-23 23:49 bug#20637: incompatible, undocumented change to vc-working-revision Glenn Morris
2016-03-28 23:28 ` Dmitry Gutov
2016-03-29 18:13   ` Michael Albinus
2016-04-01  0:36     ` Dmitry Gutov
2016-04-09 19:34       ` Michael Albinus
2016-04-09 20:42         ` Dmitry Gutov
2016-04-10  8:00           ` Michael Albinus
2016-04-10 16:00             ` Dmitry Gutov
2016-04-10 18:09               ` Michael Albinus
2016-04-10 18:58                 ` Dmitry Gutov
2016-04-11  6:55                   ` Michael Albinus
2016-04-13 20:55                     ` Dmitry Gutov
2016-04-14  7:10                       ` Michael Albinus
2016-04-14 13:53                         ` Dmitry Gutov
2016-04-14 15:26                           ` Michael Albinus
2016-04-15  0:33                             ` Dmitry Gutov
2016-04-15 13:13                               ` Michael Albinus
2016-04-14 15:23                         ` Eli Zaretskii
2016-04-13 15:14   ` Michael Albinus
2016-04-13 20:49     ` Dmitry Gutov
2016-04-14  7:21       ` Michael Albinus
2016-04-14 14:20         ` Dmitry Gutov [this message]
2016-04-14 18:31           ` Michael Albinus
2016-04-15  0:20             ` Dmitry Gutov
2016-04-15 13:11               ` Michael Albinus
2016-04-17  0:44                 ` Dmitry Gutov
2016-04-18 12:27                   ` Michael Albinus
2016-04-18 12:33                     ` Dmitry Gutov
2016-04-18 12:46                       ` Michael Albinus
2016-04-18  1:40                 ` Dmitry Gutov
2016-04-15  1:01             ` Dmitry Gutov
2016-04-15  1:04               ` Dmitry Gutov
2016-04-15 13:23               ` Michael Albinus
2016-04-17  0:27                 ` Dmitry Gutov
2016-04-18  1:33             ` Dmitry Gutov
2016-04-18 12:28               ` Michael Albinus
2016-04-18 12:37                 ` Dmitry Gutov
2016-04-18 12:53                   ` Michael Albinus
2016-04-18 12:58                     ` Dmitry Gutov
2016-04-18 13:06                       ` Michael Albinus
2016-04-18 16:34                     ` John Wiegley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e3132bc6-f1d4-ebef-00d4-93fa0807fea0@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=20637@debbugs.gnu.org \
    --cc=michael.albinus@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).