From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] scratch/fix-33794-extend-electric-layout-mode 41a9132: Extend electric-layout-mode to handle more complex layouts Date: Fri, 28 Dec 2018 12:51:41 -0500 Message-ID: References: <20181221180327.7142.84494@vcs0.savannah.gnu.org> <20181221180328.D755D20538@vcs0.savannah.gnu.org> <87sgyp6ysy.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1546019671 12862 195.159.176.226 (28 Dec 2018 17:54:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 28 Dec 2018 17:54:31 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 28 18:54:26 2018 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 1gcwL4-0003Em-FV for ged-emacs-devel@m.gmane.org; Fri, 28 Dec 2018 18:54:26 +0100 Original-Received: from localhost ([127.0.0.1]:60762 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gcwNB-0003gQ-6l for ged-emacs-devel@m.gmane.org; Fri, 28 Dec 2018 12:56:37 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:40213) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gcwMu-0003Nf-Pc for emacs-devel@gnu.org; Fri, 28 Dec 2018 12:56:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gcwIV-0001pb-Ub for emacs-devel@gnu.org; Fri, 28 Dec 2018 12:51:51 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:38826) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gcwIU-0001ee-2Q for emacs-devel@gnu.org; Fri, 28 Dec 2018 12:51:47 -0500 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id wBSHpgEY031966; Fri, 28 Dec 2018 12:51:42 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id A52EBAE0D0; Fri, 28 Dec 2018 12:51:41 -0500 (EST) In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Fri, 28 Dec 2018 16:33:52 +0000") X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 3 Rules triggered LNG_SB_1=0.2, EDT_SA_DN_PASS=0, RV6449=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6449> : inlines <6990> : streams <1808456> : uri <2771367> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:232020 Archived-At: The new API looks good to me, thanks. > (defvar electric-layout-rules nil > "List of rules saying where to automatically insert newlines. > > Each rule has the form (MATCHER . WHERE) where MATCHER examines > the state of the buffer after a certain character was inserted > and WHERE specifies where to insert newlines. > > MATCHER can be a character CHAR or a boolean function of no > arguments. Could we pass the inserted char to the function, so the function doesn't need to choose between looking at last-command-event, char-before, or yet something else? > The rule matches if the character just inserted was > CHAR or if the function return non-nil. ^^^^^^ returns > WHERE and can be: ^^^ > * one of the symbols `before', `after', `around', `after-stay' or > nil; nil doesn't need to be mentioned here, since it's a special case of "list of the preceding symbols". > * a list of the preceding symbols, processed in order of > appearance to insert multiple newlines; Great: much better than the previous approach of processing all matches. > Instead of the (MATCHER . WHERE) form, a rule can also be just a > function of no arguments. It should return a value compatible > with WHERE if the rule matches, or nil if it doesn't match. I think I'm fine with allowing MATCHER to be a function, and I'm fine with allowing (MATCHER . WHERE) to be a function, but I don't like the idea of allowing both, which seem a bit redundant (actually, allowing WHERE to be a function is also somewhat redundant with those, but it's part of the current API, so we're kind of stuck with it). [ BTW, the one user I know of the "WHERE is a function" (sml-mode) uses this function as a kind of predicate (it either returns `after` or nil) so it could get the same result with a MATCHER function (or a separate PREDICATE function). Stefan