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: Emacs pretest -- electric-pair-mode change Date: Thu, 03 Apr 2014 10:22:28 -0400 Message-ID: References: <87d2h0ujls.fsf_-_@kitaj.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1396534977 29419 80.91.229.3 (3 Apr 2014 14:22:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Apr 2014 14:22:57 +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 Thu Apr 03 16:22:50 2014 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 1WViXZ-00021l-T8 for ged-emacs-devel@m.gmane.org; Thu, 03 Apr 2014 16:22:50 +0200 Original-Received: from localhost ([::1]:44358 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WViXZ-00036b-F7 for ged-emacs-devel@m.gmane.org; Thu, 03 Apr 2014 10:22:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41040) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WViXP-00035y-FR for emacs-devel@gnu.org; Thu, 03 Apr 2014 10:22:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WViXH-0008O8-S7 for emacs-devel@gnu.org; Thu, 03 Apr 2014 10:22:39 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:51582) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WViXH-0008Nu-Lo for emacs-devel@gnu.org; Thu, 03 Apr 2014 10:22:31 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s33EMSBo005557; Thu, 3 Apr 2014 10:22:28 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 5DD596020F; Thu, 3 Apr 2014 10:22:28 -0400 (EDT) In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1v?= =?windows-1252?Q?ora=22's?= message of "Thu, 03 Apr 2014 12:06:39 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.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 RV4901=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4901> : inlines <687> : streams <1151194> : uri <1719155> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:171272 Archived-At: >> (since it will syntax-propertize any part of the buffer not yet >> propertized). > This suggests it's a kind of one-time delay per buffer, but that's not > the case at least for the large python above A modification at position X flushes all syntax propertization after X. So it's a "one time delay" but only until the next buffer modification. > The quote part does seem to be the most problematic. In the big > lisp/ldefs-boot.el I get just under a second on windows for pairing a > parens, and should be much faster on linux. [ Unrelated: it's odd that the speed should depend on the OS. ] BTW, while speed is a factor, it's not the only one: if the unpaired string is very far away, the user might be very surprised/disappointed by electric-pair's behavior (where it will pair when the user expects it not to and vice-versa). >> In many languages, strings can't span multiple lines, or they can >> only do so if end-of-lines are somehow escaped. Maybe we could use >> that to try and reduce the scope of the test. > Maybe (how?). Don't know. Maybe use a buffer-local variable like electric-pair-string-bound-function which major-modes can set to a function that jumps to some buffer position which should not be within a string according to the language rules. E.g. in C it could search for "[^\\]\n". In Python, I think that wouldn't help, since triple-quoted strings can contain anything whatsoever, IIUC. But python-mode could use a heuristic and look for the next "thing that looks like code" and hope that strings containing code will be rare enough. > But even even in those languages, syntax (and fontification) works > across newlines, so do we pair for the language or for the syntax? In Emacs we often use the simplifying assumption that we only try to make the code work right in the case where the buffer's content is "correct" and if the buffer's content is "incorrect" then we reduce our expectation to something like "we do something acceptable". IOW, we write the code assuming that the buffer is correct (and failing gracefully if it is not). In this case, of course, the test itself is trying to figure out if the code is correct, so "assume that it is correct" needs to be refined. > Anyway, best I can come up with right now is the following, but with > frequent false negatives in oversize buffers. I don't know if I'd > rather have false positives (meaning less electricity in oversize > buffers) Checking (nth 3 (syntax-ppss (+ (point) ))) doesn't make much sense, since we have no reason to assert that (+ (point) ) should be outside of a string. Stefan