From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Jo=E3o_T=E1vora?= Newsgroups: gmane.emacs.devel Subject: Fwd: [patch] make electric-pair-mode smarter/more useful Date: Mon, 16 Dec 2013 19:02:57 +0000 Message-ID: References: <87haalh806.fsf@gmail.com> <87ppp2ydqf.fsf@gmail.com> <87r49h7eby.fsf@gmail.com> <87ppoxepfj.fsf@gmail.com> <87fvps98qs.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1387220597 13825 80.91.229.3 (16 Dec 2013 19:03:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Dec 2013 19:03:17 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 16 20:03:23 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 1VsdRr-0003de-5U for ged-emacs-devel@m.gmane.org; Mon, 16 Dec 2013 20:03:23 +0100 Original-Received: from localhost ([::1]:57723 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsdRq-0002DC-PQ for ged-emacs-devel@m.gmane.org; Mon, 16 Dec 2013 14:03:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42227) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsdRn-0002D7-7u for emacs-devel@gnu.org; Mon, 16 Dec 2013 14:03:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VsdRl-0005eD-LM for emacs-devel@gnu.org; Mon, 16 Dec 2013 14:03:19 -0500 Original-Received: from mail-qa0-x234.google.com ([2607:f8b0:400d:c00::234]:40604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsdRl-0005e5-HC for emacs-devel@gnu.org; Mon, 16 Dec 2013 14:03:17 -0500 Original-Received: by mail-qa0-f52.google.com with SMTP id cm18so1831586qab.18 for ; Mon, 16 Dec 2013 11:03:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=ma+39yu3zBR6J1iquOxTtNg+UwV0/slAy6+F9ZsAAwo=; b=R4GOwpKoUGNi19EwVtRurz1uBbgVtHb94HF34nCRp38edoRErAhcReRP9JfkKKzqb6 BOd++L2zxLh76zNE2qMEHbviH4gcPcvQoGHhPNQrGNLv8kRAT7aKnHnD68XXt7iYOdui /gUqAfscF+ebH/Ibb4EF0Va02eFTdZgn9fDQxI3HTCz4ZqYjVRz6ZaMWrR1ZwAPPBBJc meFsmijyvD8mBjassHb51u7Tj6j11960+6R5Ns5zv6/UXlrKYV/JLQjC6jX8shaE/fX5 6BmDk8jxrpumSBVVhbBV6enoK/X6SallrEuMCf/SYqBG+/5ovx6k2asoJK0ikjtohrSw 0QXg== X-Received: by 10.49.51.66 with SMTP id i2mr35430449qeo.26.1387220597095; Mon, 16 Dec 2013 11:03:17 -0800 (PST) Original-Received: by 10.229.32.195 with HTTP; Mon, 16 Dec 2013 11:02:57 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c00::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:166503 Archived-At: On Mon, Dec 16, 2013 at 3:30 PM, Stefan Monnier wrote: >> With ""foo""bar", try input " at point 1. Should become """"foo""= bar" and point at 2 > Why should it become """"foo""bar"? Mind you, don't confuse the docstring's quotes with the quotes in the fixture text. The fixture is "foo" "bar Which I (and font-lock) interpret as one perfectly terminated string followed by an unterminated string. So typing a quote at the very beginning should make it autopair IMO, so that you get. """foo" "bar Which is a perfectly terminated empty string, followed by the original fixt= ure's terminated and unterminated strings. >> - "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" > Not sure what the "balance, always" refers to or why we need it, but > other than that, yes. The "balance" entry will be a "balance maybe". Yes, it's silly probably. "balance, always" would be "balance without depending on electric-pair-preserve-balance. "balance, maybe" would be "balance, but depending on electric-pair-preserve-balance.". You want me to strike "balance, always" and keep only "balance, maybe", renamed as as "balance", right? > That's different: this `or' test is to distinguish between two different > notions of "interactively" (i.e. whether the user interactively > triggered this specific function, vs whether the function was called > using call-interactively). Oh OK, I read the docstring in diagonal and didn't test much. But that docstring might be a little confusing... > Maybe, maybe not (it probably depends on the specific case), but since > it's very rarely called from Lisp, I think we'd better not worry about > it until someone reports an actual problem with it. Then (newline 1 t) it is! >>>> +(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, > The whole point of using priorities is to make them not depend on each > other but on some external total order. But in the end they do depend directly on each other. OK, you can make it generic and say this one gets 20 because it inserts and deletes characters, this other one gets 40 because it inserts extra newlines, that 60 because something, and this one gets 100 because it does the sit-for. But developing this theory for now seemed like overkill to me, and without it would appear to the reader that ETOOMANYWORDS. OK I'll do it. >> In js-mode layout rules, pairing must come before layout, there's a test >> for that. > Do you know the underlying reason why the test fails if you do it the > other way around? I don't remember anymore, but its very easy to reproduce if you scratch the sort function and write an additional test with the order of minor mode= s reversed. Then I can check. I don't have emacs handy now. Hoping this message isn't too garbled by the gmail interface, Jo=E3o