From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [patch] make electric-pair-mode smarter/more useful Date: Sat, 07 Dec 2013 18:07:21 -0500 Message-ID: References: <87haalh806.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1386457654 18626 80.91.229.3 (7 Dec 2013 23:07:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Dec 2013 23:07:34 +0000 (UTC) Cc: emacs-devel@gnu.org To: joaotavora@gmail.com (=?windows-1252?B?Sm/jbyBU4XZvcmE=?=) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 08 00:07:39 2013 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 1VpQyJ-0005aJ-Hx for ged-emacs-devel@m.gmane.org; Sun, 08 Dec 2013 00:07:39 +0100 Original-Received: from localhost ([::1]:37675 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VpQyJ-0006cw-2r for ged-emacs-devel@m.gmane.org; Sat, 07 Dec 2013 18:07:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48801) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VpQy9-0006by-VI for emacs-devel@gnu.org; Sat, 07 Dec 2013 18:07:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VpQy2-0001er-M1 for emacs-devel@gnu.org; Sat, 07 Dec 2013 18:07:29 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:63201) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VpQy2-0001eH-H6 for emacs-devel@gnu.org; Sat, 07 Dec 2013 18:07:22 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFLd/UW/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA2IQgbBLZEKA4hhnBmBXoMV X-IPAS-Result: Av4EABK/CFFLd/UW/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA2IQgbBLZEKA4hhnBmBXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="41408862" Original-Received: from 75-119-245-22.dsl.teksavvy.com (HELO pastel.home) ([75.119.245.22]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 07 Dec 2013 18:07:22 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id CB43860078; Sat, 7 Dec 2013 18:07:21 -0500 (EST) In-Reply-To: <87haalh806.fsf@gmail.com> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?= =?windows-1252?Q?ra=22's?= message of "Fri, 06 Dec 2013 23:31:05 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:166191 Archived-At: > In a recent cleanup I did of my autopair.el library [1], I decided to > try and add one of its core features to emacs's built-in > `electric-pair-mode' and make it the default behaviour. Thank you, very appreciated. > The feature was surprisingly easy to implement using the existing > `electric-pair-inhibit-predicate' customization variable and only > slightly changing the semantics of the existing > `electric-pair-skip-self` variable. Overall, the integration looks very good, indeed. > +(defun electric-pair--pair-of (char) > + "Return pair of CHAR if it has parenthesis or delimiter syntax." > + (and (memq (char-syntax char) '(?\( ?\) ?\" ?\$)) > + (cdr (aref (syntax-table) char)))) Hmmm... the existing code already has such a functionality. Can you try and use your new function in that code, or somehow merge the two? > +(defun electric-pair--up-list (&optional n) > + "Try to up-list forward as much as N lists. > + > +With negative N, up-list backward. N default to `point-max'. > + > +Return a cons of two descritions (MATCHED START END) for the > +innermost and outermost lists that enclose point. The outermost > +list enclosing point is either the first top-level or mismatched > +list found by uplisting." Could you try and use up-list, instead? Also, you can find the START of all enclosing lists in (nth 9 (syntax-ppss)), which seems like it might be helpful here. It would be good to try and avoid moving all the way to the START or END of the outermost list, since that may require scanning the whole buffer, which in pathological cases will make the feature slow. Maybe using syntax-ppss could help us avoid those pathological cases (since syntax-ppss uses a cache to avoid re-scanning). Stefan