From: Thien-Thi Nguyen <ttn@gnuvola.org>
To: Dan Nicolaescu <dann@ics.uci.edu>
Cc: emacs-devel@gnu.org
Subject: Re: vc-*-root finctions
Date: Fri, 22 Feb 2008 15:41:22 +0100 [thread overview]
Message-ID: <87ablt3vfx.fsf@ambire.localdomain> (raw)
In-Reply-To: <200802211835.m1LIZcZ5005055@sallyv1.ics.uci.edu> (Dan Nicolaescu's message of "Thu, 21 Feb 2008 10:35:38 -0800")
() Dan Nicolaescu <dann@ics.uci.edu>
() Thu, 21 Feb 2008 10:35:38 -0800
It seems that this patch contains multiple independent things. It would
be better to split them, so they can be judged separately.
Good point. Will do so in the next few days.
As a documentation stickler you should know that having a backend
implementer look for documentation in both the beginning of vc.el and in
the comment in vc-status-refresh is not a good idea.
Why is not a good idea? One explains the interface, the other the rationale.
More, the comment in vc-status-refresh talks about "We used to
do this:" is just pointless.
Lots of comments in Emacs are likewise pointless, i suppose. In
any case, i'll move it to top-level and make it less time-oriented.
Frankly, having a function that is called twice once with an argument
t and another time with nil, and does completely different things
depending on the argument just screams WEIRD. Better have 2 different
functions.
I disagree. More functions is more maintenance.
The fact that there's a need for about 70 lines of comments for one
backend function, points to some design problems.
How so?
In general, it hard to see what you are trying to accomplish here, and
why you changes are better than what is there now.
The changes try to reduce failure modes, which, being "potential"
rather than actual issues, may indeed be difficult to appreciate.
You haven't explained why it is better to introduce the synchronous
behavior when I said that it can be easily used with the current API.
Well, i haven't introduced synchronous behavior in vc.el, so why
would i want to explain that?
Which would be wrong. git might be fast, but it takes a long time if it
has to read the inodes from disk or NFS on a big tree (which happens
every morning or after a big compilation job).
I don't know about that. I observe that "git status" on emacs.git
takes a little longer (maybe five seconds) the first time it is
run and then less than a second for subsequent times. (Perhaps
you're not talking about "git status" that vc-git-dir-status uses?)
> Yes, but removing the need to specify UPDATE-FUNCTION is better.
Why is that a big problem.
More functions, more maintenance: It's not a big problem when used
correctly; it's a big problem when misunderstood and subsequently
used incorrectly. Occam's razor and all that.
Yeah, this was intended to call a backend specific function at some
point, so better keep it a separate function that mix this code in the
middle of something else.
Regardless, the best place is during vc-status-refresh.
+(defsubst vc-overview-p () ...)
There are a few other places that could use this. But this should go at
the time vc-dired is completely replaced. Why not check this in
separately?
Good idea. I will commit it in the next day or two.
In the meantime, interested git users can look at:
http://www.gnuvola.org/wip/ (vc-status-hacking)
I will henceforth be munging there instead of posting patches.
thi
next prev parent reply other threads:[~2008-02-22 14:41 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-19 22:06 vc-*-root finctions Stefan Monnier
2008-02-20 11:12 ` Thien-Thi Nguyen
2008-02-20 17:21 ` Stefan Monnier
2008-02-20 18:21 ` Thien-Thi Nguyen
2008-02-20 18:50 ` Dan Nicolaescu
2008-02-21 15:33 ` Thien-Thi Nguyen
2008-02-21 18:35 ` Dan Nicolaescu
2008-02-21 19:03 ` Tom Tromey
2008-02-21 20:06 ` Dan Nicolaescu
2008-02-21 19:33 ` Stefan Monnier
2008-02-21 19:01 ` Tom Tromey
2008-02-21 20:01 ` Dan Nicolaescu
2008-02-21 19:50 ` Dan Nicolaescu
2008-02-22 14:41 ` Thien-Thi Nguyen [this message]
2008-02-22 15:42 ` Dan Nicolaescu
2008-02-22 17:34 ` Thien-Thi Nguyen
2008-02-22 19:02 ` Dan Nicolaescu
2008-02-22 2:42 ` Mike Mattie
2008-02-20 19:20 ` Stefan Monnier
2008-02-21 15:36 ` Thien-Thi Nguyen
2008-02-21 16:16 ` Stefan Monnier
2008-02-22 14:54 ` Thien-Thi Nguyen
2008-02-22 16:50 ` Stefan Monnier
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=87ablt3vfx.fsf@ambire.localdomain \
--to=ttn@gnuvola.org \
--cc=dann@ics.uci.edu \
--cc=emacs-devel@gnu.org \
/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).