From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joaotavora@gmail.com (=?iso-8859-1?Q?Jo=E3o_T=E1vora?=) Newsgroups: gmane.emacs.devel Subject: Re: Emacs pretest -- electric-pair-mode change Date: Thu, 03 Apr 2014 17:56:52 +0100 Message-ID: References: <87d2h0ujls.fsf_-_@kitaj.lan> 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 1396544723 28970 80.91.229.3 (3 Apr 2014 17:05:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Apr 2014 17:05:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 03 19:05:18 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 1WVl4o-0001tq-0N for ged-emacs-devel@m.gmane.org; Thu, 03 Apr 2014 19:05:18 +0200 Original-Received: from localhost ([::1]:45233 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVl4n-0001q8-F0 for ged-emacs-devel@m.gmane.org; Thu, 03 Apr 2014 13:05:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50886) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVkx8-0007ww-9p for emacs-devel@gnu.org; Thu, 03 Apr 2014 12:57:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WVkwj-00080h-7D for emacs-devel@gnu.org; Thu, 03 Apr 2014 12:57:22 -0400 Original-Received: from mail-wg0-x230.google.com ([2a00:1450:400c:c00::230]:50539) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVkwi-00080N-PV for emacs-devel@gnu.org; Thu, 03 Apr 2014 12:56:57 -0400 Original-Received: by mail-wg0-f48.google.com with SMTP id l18so2210631wgh.19 for ; Thu, 03 Apr 2014 09:56:55 -0700 (PDT) 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:content-transfer-encoding; bh=ZT1CM4VUQpMLQl4S03CEq1qCR9uvW+wUmo3WM+qFh7g=; b=oD83jeFY4OhABbnS7RTTihtsiM9aYzh2NYjSTZCnTucCqEntr8JzeB1yyPj26o8jPM ouTEBGyKmmmvYH43myMGkcxJSwXm4b66I2rtT0W8ufuKHBQLMDRC66RSc06tcs1baLCP Uv/KePD7ESPcX4hMCzzBAfs2aQOlPBJ+EzPlrQIrC7ejKhVMbNVOak6a1MtfMCVvmtNG rPFuPj8H0QTmVQO0TA2RC+SDWls9vaNyJrg0tqzThEoNW3sMVvhu+Diui4YoklTquX+M SmOys+dBQjQ/p1bUAavTCmlMIsw6f2ESR9OlfmAMA0NMW1KtlwaRyqUcuqtT8/7Z3JMs 1khw== X-Received: by 10.180.100.169 with SMTP id ez9mr39721345wib.15.1396544215742; Thu, 03 Apr 2014 09:56:55 -0700 (PDT) Original-Received: from BELMONTE.yourcompany.com (mail3.siscog.pt. [195.23.29.18]) by mx.google.com with ESMTPSA id q2sm47318609wix.5.2014.04.03.09.56.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Apr 2014 09:56:54 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Thu, 03 Apr 2014 10:22:28 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (windows-nt) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::230 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:171278 Archived-At: Stefan Monnier writes: >> 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. ] I'm using two relatively similar dual-core machines. In windows I use the builds of http://sourceforge.net/projects/emacs-bin/. Didn't I read somewhere that these are compiled without optimization flags? > 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). Yes I see. But for me it's definitely better not to pair in those situations (you seem to agree with me in your explanation of the "simplifying assumption" below). Anyway the "oh, it didn't pair..." disappointment is better than finding the unpaired string later, and at least in my workflow, leads me to try a one-off M-x check-parens and fix stuff before I continue hacking. >>> 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. Hmmm, sounds a little complicated, but will give it a go if all else fails. >> 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". Ok we agree perfectly then. "Something acceptible" then is "not pairing", just the self-insertion the user asked for, rught? >> 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. If (+ (point) ) is less than (point-max) and inside a string we additionally assert that at least that string is paired. If it's not, we say "incorrect" which is always true. Otherwise we say "correct" and risk a false judgement and a surprising pair. How often? Don't know. Anyway I agree it's not a very good perfect heuristic. What about this? Seems to be much much faster in the python buffer i've been testing with (even on windoze :-) (defvar electric-pair-no-strings-syntax-table (let ((table (make-syntax-table))) (dotimes (char 256) ;; only searches the first 256 chars, (let* ((entry (aref table char)) (class (and entry (syntax-class entry)))) (when (and class (eq ?\" class)) (modify-syntax-entry char "w" table)))) table)) =20=20=20=20=20 (defun electric-pair--unbalanced-strings-p (char) (let ((table (make-syntax-table electric-pair-no-strings-syntax-table= )) (ppss (syntax-ppss))) (modify-syntax-entry char "\"" table) (with-syntax-table table (save-excursion (nth 3 (parse-partial-sexp (or (and (nth 3 ppss) (nth 8 ppss)) (point)) (point-max))))))) =20=20=20=20=20=20=20=20=20 Jo=E3o=20=20=20=20=20=20=20=20=20=20