From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kaushal Modi Newsgroups: gmane.emacs.devel Subject: Re: use-package.el -> Emacs core Date: Tue, 10 Nov 2015 10:56:08 -0500 Message-ID: References: <564136F7.2020404@yandex.ru> <877flqe1a4.fsf@gmail.com> <87twoucaxz.fsf@gmail.com> <877flqc9jh.fsf@gmail.com> <87twout0iu.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1447171070 24666 80.91.229.3 (10 Nov 2015 15:57:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Nov 2015 15:57:50 +0000 (UTC) To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , David Kastrup , Juanma Barranquero , Emacs developers , Oleh Krehel , Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 10 16:57:49 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZwBIq-0001PR-VV for ged-emacs-devel@m.gmane.org; Tue, 10 Nov 2015 16:57:49 +0100 Original-Received: from localhost ([::1]:33544 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwBIq-0003go-JC for ged-emacs-devel@m.gmane.org; Tue, 10 Nov 2015 10:57:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39352) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwBHx-0002bc-1F for emacs-devel@gnu.org; Tue, 10 Nov 2015 10:56:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwBHv-00036h-OO for emacs-devel@gnu.org; Tue, 10 Nov 2015 10:56:52 -0500 Original-Received: from mail-oi0-x230.google.com ([2607:f8b0:4003:c06::230]:35645) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwBHt-00035b-SX; Tue, 10 Nov 2015 10:56:49 -0500 Original-Received: by oige206 with SMTP id e206so512423oig.2; Tue, 10 Nov 2015 07:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=3/LNeZt/Z69YfaPOpdzudDoDJaGy7vGLMQKI0K5ELF8=; b=rWVc2xrkONxViE48KM+Dzv+QX7ANa/uBHnwqfBxmF0q96ir11qre3Vut3SWPQyFwC2 PKAMAc55Yhv1iKj78rAQ0SwzhtFAElpEy3MDNHvv5OuECtV33FQjOaGlE9RPDva9crJ9 18zkefNAc2lajN3keWqbL9i6IeN3QIWf1WNxRgm/Tk4x0oTjM5PeMnyPZxMEuepa8xk1 uwkHmGy4pfmScmVSgk/d+GjSYfiQVKpneT6TczAsSaxyVulkAfVucgioCcmFlo7rDzUZ B4k1KjxQrYDcd3a7vaC8lgOysbs0899hF7u8xakFF8hZ1WRU3IsUg5uSfDc7EcsAn59/ 98UQ== X-Received: by 10.202.104.91 with SMTP id d88mr1928057oic.57.1447171009047; Tue, 10 Nov 2015 07:56:49 -0800 (PST) Original-Received: by 10.202.80.133 with HTTP; Tue, 10 Nov 2015 07:56:08 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c06::230 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:193878 Archived-At: I would also fit in the cautious category, leaning towards against (see below for what I mean). My biggest concern is the duplication and confusion for end-user code. define-key vs bind-key. As Jo=C3=A3o mentioned in a different context, I feel this kind of syntactic sugar is probably not OK for end-user code; providing many options increases the complexity when debugging code for the user and the maintainer. My suggestion would be to first merge bind-key into define-key and sister defuns/macros. If that is feasible, then we can think if use-package can be merged. Biggest concerns with bind-key (1) Plain bind-key macro is not very much different for define-key or global-set key. I believe its addition is not necessary in the core. (2) bind-key*, bind-keys, bind-keys* would be good additions but should they be refactored as define-key* (while retaining the original define-key arg order) + global-set-key*, define-keys and define-keys*? (3) How would describe-personal-bindings work? Because if bind-key is made part of the core, we cannot control which internal package makes use of it. Write now the only way we know that the user added/redefined a key is if they made use of one of the bind-key macros. That luxury will go away once it is part of the core. About use-package: I also have a opinion that the user will understand less of how requires, autoloads, eval-after-loads and idle timers work if they start using use-package as the first thing. Until we have a solid solution for the above, my vote is against for both bind-key and use-package. With that said, would adding bind-key and use-package to GNU Elpa be a better option? If we do that, - There is no concern of duplication and confusion among users that I mentioned above. - Maintainers do not have to worry about the use/debug of use-package+bind-key in the core packages. - When helping out users debug something, the instructions for defining keys are pretty consistent: either define-key or global-set-key (usually the latter) vs the options of define-key/global-set-key/bind-key/bind-key*/bind-keys/bind-keys* - Also only the users who know what they are doing would install these pack= ages. - use-package + bind-key would still reach a wider user-base as not all users add Melpa to package-archives