From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: [elpa] master 550ae83 1/2: [gnugo int] Decruft: Don't declare hook and keymap vars. Date: Thu, 09 Feb 2017 18:39:58 +0100 Message-ID: <87a89vmff5.fsf@zigzag.favinet> References: <20170208091858.6699.16542@vcs.savannah.gnu.org> <20170208091858.F26CA220010@vcs.savannah.gnu.org> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: blaine.gmane.org 1486662406 18790 195.159.176.226 (9 Feb 2017 17:46:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 9 Feb 2017 17:46:46 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 09 18:46:41 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cbsnp-0004Q1-Ed for ged-emacs-devel@m.gmane.org; Thu, 09 Feb 2017 18:46:41 +0100 Original-Received: from localhost ([::1]:39413 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbsnt-0006F4-E1 for ged-emacs-devel@m.gmane.org; Thu, 09 Feb 2017 12:46:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40438) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbsmp-0006DE-GG for emacs-devel@gnu.org; Thu, 09 Feb 2017 12:45:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cbsmn-000829-Qy for emacs-devel@gnu.org; Thu, 09 Feb 2017 12:45:39 -0500 Original-Received: from mail.agora-net.com ([67.59.132.6]:55717) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cbsmn-00081p-MP for emacs-devel@gnu.org; Thu, 09 Feb 2017 12:45:37 -0500 Original-Received: from ttn by mail.agora-net.com with local (Exim 4.82) (envelope-from ) id 1cbsmj-00066M-ST for emacs-devel@gnu.org; Thu, 09 Feb 2017 12:45:33 -0500 Original-Received: from ttn by zigzag.favinet with local (Exim 4.80) (envelope-from ) id 1cbshY-00037R-IL for emacs-devel@gnu.org; Thu, 09 Feb 2017 18:40:12 +0100 Mail-Followup-To: emacs-devel@gnu.org In-Reply-To: (Stefan Monnier's message of "Wed, 08 Feb 2017 17:28:44 -0500") X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ttn@gnuvola.org X-SA-Exim-Scanned: No (on mail.agora-net.com); SAEximRunCond expanded to false X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 67.59.132.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:212172 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable () Stefan Monnier () Wed, 08 Feb 2017 17:28:44 -0500 why you prefer the non-idiomatic way I don't know what to call idiomatic or non-idiomatic. I simply try to muddle through (i.e., survive w/o {add,los}ing many gray hairs) the evolution of Emacs. In the old days, the model was: (defvar MODE-map nil) ; model A (defun MODE () ...) (unless MODE-map (setq MODE-amp INIT)) This and the byte-compiled result worked fine for many years, satisfying the design goals: (a) declare once; (b) init once, even during re-=E2=80=98load=E2=80=99 (to avoid clobbering customizations);= (c) init only after commands are defined. Aside: (c) is arguably non-idiomatic to begin w/ for Emacs Lisp; it's a personal aesthetic born from exposure to C and Guile, where keeping definitions topologically sorted makes for less-cluttered code. Then, at some point =E2=80=98define-derived-mode=E2=80=99 was introduced an= d i tried the modified model: (defvar MODE-map nil) ; model B (define-derived-mode MODE ...) (unless MODE-map (setq MODE-map INIT)) This worked sometimes, but not others. I suspect the times it didn't work were when byte-compiling substituted the =E2=80=98nil=E2=80=99 = in the declaration for =E2=80=98(make-sparse-keymap)=E2=80=99, resulting in the =E2=80=98unless=E2=80=99 CONDITION evaluating to true and thus precluding i= nit. Rather than investigate further, i vaguely recall reluctantly forgoing design goal (c) and adopting the model: (defvar MODE-map INIT) ; model C (define-derived-mode MODE ...) The comment in the removed INIT in the patch (in Subject) shows some of the hand-wringing involved w/ the B-C transition. What i (somewhat stupidly) didn't realize at the time is that using =E2=80=98define-derived-mode=E2=80=99 (models B and later) already departs = from design goal (a). So that brings us to the present model: (define-derived-mode MODE ...) ; model D (unless EXPECTED-MODE-map-BINDING (INITIALZE MODE-map)) which once again supports all three design goals, though less perfectly (CONDITION was algorithmic, now heuristic) than model A. I think in this case, the chosen CONDITION is close enough. Anyway, i especially enjoy the reduction in forms, which is what i imagine the introduction of =E2=80=98define-derived-mode=E2=80=99 was sup= posed to achieve. Pruned profligacy for perplexable programmers! :-D =2D-=20 Thien-Thi Nguyen ----------------------------------------------- (defun responsep (query) (pcase (context query) (`(technical mailing-list) t) ...)) 748E A0E8 1CB8 A748 9BFA =2D-------------------------------------- 6CE4 6703 2224 4C80 7502 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlicqXQACgkQZwMiJEyAdQJPEQCaA+Evb+ovRXdpmEig7rsO+dJO 6YcAoLCzJcxklq4PPJaIj9Xf5r5T/hzk =tdLt -----END PGP SIGNATURE----- --=-=-=--