unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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




  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).