zsh-workers
 help / color / mirror / code / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Nikolai Weibull <now@bitwi.se>
Cc: Mikael Magnusson <mikachu@gmail.com>,
	Frank Terbeck <ft@bewatermyfriend.org>,
	zsh-workers@zsh.org
Subject: Re: Slowness issue with git completion
Date: Wed, 27 Apr 2011 01:25:32 +0300	[thread overview]
Message-ID: <BANLkTik0cYpzkbOZxf+R=dyjhH_7-i++0w@mail.gmail.com> (raw)
In-Reply-To: <BANLkTi=AgTZNVCjqUB7LSbnQyMLPUfkT5Q@mail.gmail.com>

On Wed, Apr 27, 2011 at 1:03 AM, Nikolai Weibull <now@bitwi.se> wrote:
> On Tue, Apr 26, 2011 at 23:35, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Wed, Apr 27, 2011 at 12:13 AM, Mikael Magnusson <mikachu@gmail.com> wrote:
>
>>> It's only slow in repos as large as the linux one.
>
>> No. It's slow everywhere, it's *dead* slow on Linux. And BTW, there's
>> thousands of developers working on Linux (the kernel), I guess we are
>> not important.
>
> So perhaps you can improve it then.  Or one of the thousands of
> developers working on Linux (the kernel).  (I don’t believe that a
> very large fraction of them actually use Zsh,

And now I see why.

> though, or someone would
> have already provided a patch.)  Or perhaps you could patch the kernel
> to make it faster?

It works fine in bash.

> I’ve spent innumerable hours on making it correct.  I expect someone
> to pitch in a couple of hours to make it fast.

Well, kernel and git developers have spent many more hours to make git
fast,  and this "correctness" is disrespecting that work because the
time it takes to execute the completion is longer than the command
itself.

> I find your attitude in this thread rather offensive.

Oh, if I say the current implementation is dead slow and unusable, you
find that offensive? Maybe you should understand that criticism to
code is not criticism to you. But I will tell you what I do when
somebody finds a fatal flaw in my software; I fix it. If the person is
offensive or cordial doesn't really matter, the fatal flaw is there.

Now, how about you make a compromise between "correctness" and
usability? There's many parts of the code marked as TODO, so I guess
the code is not "perfectly correct". Add one more TODO, so in the
meantime 'git add' shows unchanged files, which would make the rest of
the commands as fast as they should be.

I will tell you why I use completion; because I want to be more
productive. If completion makes me less productive, I will obviously
not use it... What's the point? I don't see why that is so hard to
understand. Note that this is the case also for small projects.

Are you interested in fixing this use-case even if it means to make
some compromises in correctness or not?

-- 
Felipe Contreras


  reply	other threads:[~2011-04-26 22:25 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-26 18:26 Felipe Contreras
2011-04-26 18:43 ` Frank Terbeck
2011-04-26 19:06   ` Nikolai Weibull
2011-04-26 20:10     ` Frank Terbeck
2011-04-26 20:23   ` Felipe Contreras
2011-04-26 20:34     ` Mikael Magnusson
2011-04-26 20:57       ` Felipe Contreras
2011-04-26 20:59         ` Mikael Magnusson
2011-04-26 21:10           ` Felipe Contreras
2011-04-26 21:13             ` Mikael Magnusson
2011-04-26 21:35               ` Felipe Contreras
2011-04-26 22:03                 ` Nikolai Weibull
2011-04-26 22:25                   ` Felipe Contreras [this message]
2011-04-26 23:14                     ` Benjamin R. Haskell
2011-04-27  7:01                       ` Benjamin R. Haskell
2011-04-27  1:52                     ` gi1242+zsh
2011-04-27  6:11                     ` Nikolai Weibull
2011-04-27  8:30                       ` Felipe Contreras
2011-04-27  8:47                         ` Frank Terbeck
2011-04-27  9:06                           ` Felipe Contreras
2011-04-27 10:15                         ` Nikolai Weibull
2011-04-27 10:42                           ` Felipe Contreras
2011-04-27 11:14                             ` Nikolai Weibull
2011-04-27  4:19                 ` Bart Schaefer
2011-04-27  6:13                   ` Nikolai Weibull
2011-04-27 12:51                   ` Nikolai Weibull
2011-04-27 14:55                     ` Bart Schaefer
2011-04-27 18:36                       ` Nikolai Weibull
2011-04-30 14:37                     ` Simon Ruderich
2011-04-30 15:00                       ` Simon Ruderich
2011-05-02  9:59                       ` Nikolai Weibull
2011-05-03 13:59                         ` Nikolai Weibull
2011-04-26 21:52         ` Benjamin R. Haskell
2011-04-26 22:04           ` Felipe Contreras
2011-04-26 22:35             ` Benjamin R. Haskell

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

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

  git send-email \
    --in-reply-to='BANLkTik0cYpzkbOZxf+R=dyjhH_7-i++0w@mail.gmail.com' \
    --to=felipe.contreras@gmail.com \
    --cc=ft@bewatermyfriend.org \
    --cc=mikachu@gmail.com \
    --cc=now@bitwi.se \
    --cc=zsh-workers@zsh.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.vuxu.org/mirror/zsh/

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 NNTP newsgroup(s).