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: Thu, 12 Dec 2013 21:32:45 -0500 Message-ID: References: <87haalh806.fsf@gmail.com> <87ppp2ydqf.fsf@gmail.com> <87r49h7eby.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1386901982 15002 80.91.229.3 (13 Dec 2013 02:33:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Dec 2013 02:33:02 +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 Fri Dec 13 03:33:07 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 1VrIYt-0001ZH-AZ for ged-emacs-devel@m.gmane.org; Fri, 13 Dec 2013 03:33:07 +0100 Original-Received: from localhost ([::1]:39649 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrIYs-0008Oe-KR for ged-emacs-devel@m.gmane.org; Thu, 12 Dec 2013 21:33:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42785) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrIYk-0008OX-3a for emacs-devel@gnu.org; Thu, 12 Dec 2013 21:33:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VrIYc-0006Ix-PP for emacs-devel@gnu.org; Thu, 12 Dec 2013 21:32:58 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:42552) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrIYc-0006Gm-KG for emacs-devel@gnu.org; Thu, 12 Dec 2013 21:32:50 -0500 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.DIT.UMontreal.CA (8.14.1/8.14.1) with ESMTP id rBD2WjRD026334; Thu, 12 Dec 2013 21:32:46 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 6AB22AE350; Thu, 12 Dec 2013 21:32:45 -0500 (EST) In-Reply-To: <87r49h7eby.fsf@gmail.com> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?= =?windows-1252?Q?ra=22's?= message of "Fri, 13 Dec 2013 01:02:41 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4790=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4790> : inlines <319> : streams <1089925> : uri <1622360> 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.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:166359 Archived-At: >> I think this change is for the worst. I often rely on ".." pairing in >> things like text-mode where they don't have `string' syntax. > But if you "rely" on those in text-mode, isn't the correct thing to give > them that syntax there? Not really, because then font-lock would make use of it, and they're not always properly balanced. IOW, yes, kind of but it has downsides, so being forced to do it is rather annoying. Why would it be a problem to keep them there? >> The explanation for removing (?\" . ?\") doesn't make much sense: you >> seem to say that the list should be kept empty because balance can't be >> provided, but until now balance wasn't provided either. > I suggested in the docstring that before adding to this list, since it > has priority, the lower priority buffer's syntax table should be used > instead, as it also helps balancing. Still: you changed the default on the grounds that "it doesn't work well", but it's worked well enough so far. >> Of course, when the syntax-table gives string syntax to ", then this >> entry should be ignored since the syntax table gives more info, which >> allows balancing. > So you mean inverting the lookup order? Yes. > If so, it seems like a good idea. I got the opposite idea from the > original implementation of `electric-pair-syntax' and the mention of > "regardless of major mode" in `electric-pair-pairs''s docstring. In the original behavior, the order was largely irrelevant. >> I suggest you use "text" rather than "non-code" in the variable names >> (and indeed, the behavior in strings and comments should largely be the >> same as in text-mode). > I disagree, but won't insist. On which part (the quoted text has at least 2 separate arguments)? >> (save-excursion (car (syntax-ppss (point-max)))) > This works... but only for one kind of parenthesis. It incorrectly > reports 0 for a buffer with '[)', Ah, I guess that indeed introduces some complications, indeed. Thanks for clearing things up. You might give this obvious example somewhere in a comment. >> So I think we need a "electric-pair-preserve-balance" flag to control >> those features. > OK, but I would set it to t. Yes, it should default to t (unless too many people complain). >> The priorities can be added as symbol properties, so the "sort" function >> doesn't need to know about the existing hooks. > Sounds a bit overkill for this particular case, unless we > make it more generic, like maybe adding this to add-hook's understanding > of its APPEND arg. But OK. I agree it's not too serious a problem, but, I think even in this case it can slightly simplify the code, since the comparison function can be a simpler (lambda (x y) (< (or (get x 'priority) 0) (or (get y 'priority) 0))). And additionally that might be useful for other people's post-self-insert-hooks. [ FWIW: I just added such priority support to add-function and advice-add. ] >>> +(defvar electric-pair-non-code-syntax-table prog-mode-syntax-table >> Why prog-mode-syntax-table, rather than (say) text-mode-syntax-table? > Explained above, but I don't object to text-mode-syntax-table. Can you give more concrete examples? >> BTW, syntax-ppss will get majorly confused if you call it while >> a different syntax-table is temporarily installed. > Never bit me, but thanks for the heads-up. It rarely bites, because in most cases syntax-ppss is pre-computed during font-locking. Which also means that when it does bite it tends to do so in fleeting, apparently unexplainable and unreproducible ways. >>> + (setq-local electric-pair-skip-whitespace 'chomp)) >> >> Hmm... lemme think... well... maybe we can't keep it tentatively. >> I suspect it will bite me sometimes, but let's give it a chance. > I don't undestand: we "can" or we "can't" keep it? Sorry, damn typo. It was "can". > No, it doesn't belong here, sorry :-) Some earlier attempt at making the > related newline-between-pairs feature. But since you spotted it, > shoudn't newline-and-indent also call the post-self-insertion hooks? I guess so, yes. Stefan