From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joaotavora@gmail.com (=?utf-8?B?Sm/Do28gVMOhdm9yYQ==?=) Newsgroups: gmane.emacs.devel Subject: Re: [patch] make electric-pair-mode smarter/more useful Date: Mon, 16 Dec 2013 14:21:47 +0000 Message-ID: <87fvps98qs.fsf@gmail.com> References: <87haalh806.fsf@gmail.com> <87ppp2ydqf.fsf@gmail.com> <87r49h7eby.fsf@gmail.com> <87ppoxepfj.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1387203806 32372 80.91.229.3 (16 Dec 2013 14:23:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Dec 2013 14:23:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 16 15:23:32 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 1VsZ51-0007OL-2i for ged-emacs-devel@m.gmane.org; Mon, 16 Dec 2013 15:23:31 +0100 Original-Received: from localhost ([::1]:56405 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsZ50-0002zf-MN for ged-emacs-devel@m.gmane.org; Mon, 16 Dec 2013 09:23:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsZ4t-0002yx-FJ for emacs-devel@gnu.org; Mon, 16 Dec 2013 09:23:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VsZ4n-0006Fe-5S for emacs-devel@gnu.org; Mon, 16 Dec 2013 09:23:23 -0500 Original-Received: from mail-we0-x234.google.com ([2a00:1450:400c:c03::234]:57909) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsZ4m-0006FR-Q3 for emacs-devel@gnu.org; Mon, 16 Dec 2013 09:23:17 -0500 Original-Received: by mail-we0-f180.google.com with SMTP id t61so4637877wes.39 for ; Mon, 16 Dec 2013 06:23:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=37+PHkWLLIWugrhHd+HqtGuzU0K+qvo2c919f6h8R04=; b=L+bodqVaISf4qea7uZK/HRavEgjuZ/DmGOQJsNYCPb1LO+2KH4YtFY6vzvrDnx73WZ og/3TDDMaJmxR0t8NemQHzBWZc9UzVJ1vEFPJrToZLNYYQmVjD4ukJoSH6b6vEHf8sD1 27uJwWjyvfKromkgk/354eRWHRS1wZhPDrp74Et4qlxIMXBMekrAJiyfRpOm9OOkWCNf s9MUeR9l3rh+nqrcb7W2TF2CoOCeBwEBN8dMhqDEVME2N25wSL0k1C6KuEysUeiApfHQ TqG7yhIaIphLyBWhp8k4DLLYxTcw8zPItgl8vp0bGkr2MixKwDj8TlTBSnajYS1b6/Mp jZ2w== X-Received: by 10.180.98.1 with SMTP id ee1mr14020343wib.47.1387203795472; Mon, 16 Dec 2013 06:23:15 -0800 (PST) Original-Received: from kitaj.yourcompany.com (66.207.108.93.rev.vodafone.pt. [93.108.207.66]) by mx.google.com with ESMTPSA id xm7sm26265268wib.0.2013.12.16.06.23.14 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 16 Dec 2013 06:23:14 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Sun, 15 Dec 2013 22:22:31 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c03::234 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:166471 Archived-At: Stefan Monnier writes: > I'm not completely set on using text-mode-syntax-table. I think I can > be convinced to try prog-mode-syntax-table. Oh :) Read below I'll give the example you asked for :-) >> The buffer situation "())", for example, has too many closers. But, to > Maybe you could handle this by considering > (- (car (syntax-ppss)) > (save-excursion (car (syntax-ppss (point-max)))) > But that doesn't solve the mixed-parens issue. Interesting. >> Your simplification for `electric-pair--looking-at-mismatched-string-p' >> was also found to fail some tests > It'd be useful to keep track of which ones. Using this simplification: (save-excursion (eq char (nth 3 (syntax-ppss (point-max))))) one gets 5 failures F electric-pair-inhibit-only-if-next-is-mismatched-at-point-1-in-c++-mode With ""foo""bar", try input " at point 1. Should become """"foo""bar" and point at 2 F electric-pair-inhibit-only-if-next-is-mismatched-at-point-1-in-emacs-lisp-mode With ""foo""bar", try input " at point 1. Should become """"foo""bar" and point at 2 F electric-pair-inhibit-only-if-next-is-mismatched-at-point-1-in-ruby-mode With ""foo""bar", try input " at point 1. Should become """"foo""bar" and point at 2 F electric-pair-leave-unbalanced-quotes-alone-2-at-point-4-in-ruby-mode-in-comments With "# "\"' ", try input " at point 4. Should become "# ""\"' " and point at 5 F electric-pair-leave-unbalanced-quotes-alone-at-point-4-in-ruby-mode-in-comments With "# "' ", try input " at point 4. Should become "# ""' " and point at 5 Using `electric-pair--syntax-ppss' fixes the last two but adds three more (which are actually less becuase they're just mode-variations on the same test) F electric-pair-inhibit-only-if-next-is-mismatched-at-point-1-in-c++-mode With ""foo""bar", try input " at point 1. Should become """"foo""bar" and point at 2 F electric-pair-inhibit-only-if-next-is-mismatched-at-point-1-in-emacs-lisp-mode With ""foo""bar", try input " at point 1. Should become """"foo""bar" and point at 2 F electric-pair-inhibit-only-if-next-is-mismatched-at-point-1-in-ruby-mode With ""foo""bar", try input " at point 1. Should become """"foo""bar" and point at 2 F electric-pair-inhibit-only-if-next-is-mismatched-at-point-3-in-ruby-mode-in-comments With "# "foo""bar", try input " at point 3. Should become "# """foo""bar" and point at 4 F electric-pair-inhibit-only-if-next-is-mismatched-at-point-4-in-c++-mode-in-comments With "// "foo""bar", try input " at point 4. Should become "// """foo""bar" and point at 5 F electric-pair-inhibit-only-if-next-is-mismatched-at-point-4-in-emacs-lisp-mode-in-comments With ";; "foo""bar", try input " at point 4. Should become ";; """foo""bar" and point at 5 >> Here too, I've kind of changed my mind :-) Balancing can already be >> turned off by customizing two variables: >> electric-pair-inhibit-predicate >> electric-pair-skip-self > The thing is that the two kinda go together. Having to tweak both > together sounds like "coding" rather than "configuring". Yeah, that's true. > We could have the two functions check a new defcustom > electric-pair-preserve-balance and if nil fallback on the old default. Yes, that's what I meant, too. OK. So in the existing 2 variables custom menu there will be basically 4 options: - "always" or "never" (depending on whether it's pair or skip) - "balance, maybe" (the default we're discussing) - "balance, always" - "don't balance, be conservative" >> Explained above again. Using prog-mode-syntax-table allows me to get >> some quote balancing in comments and strings. > This is not really an example, let alone example*S*. Which quotes? > Why are they there? Is it only for quotes? OK. So Emacs -Q, M-x electric-pair-mode and then in the scratch buffer go to some place in the comment's text and type a double quote. You get it autopaired. If you type it again you get a skip. OK. Now go back to the first quote and type it again. You get a skip. In my opinion, not so nice. Delete the first quote, go back some words and type another quote. You'll get an unbalanced string inside the comment. Again not so nice. Now if you do (setq electric-pair-text-syntax-table prog-mode-syntax-table) and repeat the second paragraph, you'll get results that I personally think are nicer. BTW these are exactly the results that you mostly loose if you do the `electric-pair--looking-at-mismatched-string-p' simplification above. >> It also does when it detects it's in c-mode or c++-mode, since in my >> testing syntax-ppss is sometimes broken there (tried in in >> src/syntax.c) > > I'm not really surprised, sadly, but please report it as a bug (the fix > is probably to make cc-mode use syntax-propertize-function, which is > not a quick&easy fix since cc-mode currently sets the syntax-table in > a very contorted way spread over various places and times). OK. > I don't understand why you'd want (not (or executing-kbd-macro > noninteractive)) rather than any non-nil constant. Where does this (not > (or executing-kbd-macro noninteractive)) come from? I read it in `called-interactively-p''s docstring... I mean, if one calls `newline-and-indent' from lisp it shouldn't call newline with interactive=t right? >> +(put 'electric-pair-post-self-insert-function 'priority 20) >> +(put 'electric-layout-post-self-insert-function 'priority 40) >> +(put 'electric-indent-post-self-insert-function 'priority 60) >> +(put 'blink-paren-post-self-insert-function 'priority 100) > These belong next to the corresponding functions. Do they? The relative order is between them, spreading them throughout the buffer makes it difficult to read, doesn't it? I would agree to spread if the priority spec was something like. (put 'electric-pair-post-self-insert-function 'priority '(before electric-layout-post-self-insert-function)) and so on. > Also, if you know why the order is this way, please add comments > explaining it (I do know for blink-paren-post-self-insert-function and > electric-indent-post-self-insert-function, but not sure why > electric-layout-post-self-insert-function should come after > electric-pair-post-self-insert-function rather than the opposite). In js-mode layout rules, pairing must come before layout, there's a test for that. Otherwise it was just a thumb rule. But OK, I can add comments for the known dependencies. >> +(defcustom electric-pair-skip-whitespace t > This docstring still needs to be improved, because it still doesn't > explain what really happens. More specifically, which whitespace > is skipped (before or after the skipped paren?). OK. > Other than those nitpicks, feel free to install those changes, Hmmm, I don't know if I have write privs. I'll check. And I'll have to check some bzr tutorials and README's.