From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7628 invoked by alias); 22 Jul 2011 13:06:03 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 29594 Received: (qmail 9470 invoked from network); 22 Jul 2011 13:06:01 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_PASS autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at bewatermyfriend.org does not designate permitted sender hosts) From: Frank Terbeck To: Nikolai Weibull Cc: zsh workers , Mikael Magnusson Subject: Re: PATCH: (3/3) _git: re-add `user-commands' support again In-Reply-To: (Nikolai Weibull's message of "Fri, 22 Jul 2011 14:48:08 +0200") References: <1309211717-9650-1-git-send-email-ft@bewatermyfriend.org> <1309379833-31315-1-git-send-email-ft@bewatermyfriend.org> <1309379833-31315-4-git-send-email-ft@bewatermyfriend.org> <87ipqujzjn.fsf@ft.bewatermyfriend.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Date: Fri, 22 Jul 2011 14:49:49 +0200 Message-ID: <8762mujx8y.fsf@ft.bewatermyfriend.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Df-Sender: 430444 Nikolai Weibull wrote: [...] > Well, I=E2=80=99ve never guaranteed backwards compatibility in any of the > releases of _git. It=E2=80=99s always been a work in progress. The > user-commands style wasn=E2=80=99t something that I added, either. Thing= s are > stabilizing now, but that also means that I would like to cut cruft > like this. Backwards compatibility isn=E2=80=99t in itself a strong enou= gh > argument for keeping it around. > > So, what exactly is the use case for user-commands? Does it solve > something that something else won=E2=80=99t solve with greater satisfacti= on? It solves the case mentioned in the comment on top of the file. I don't say that there isn't a better way. Now there is, with the _git completion add-ons. But I don't think we should break compatibility unless we need to. And the code is simple enough and doesn't break performance or impair usability. So I'd say just throwing it away doesn't bring any advantages. But it would bring the disadvantage of breaking existing working setups for no good reason. So I'd be against removing it. Regards, Frank