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 12:06:39 +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 1396528029 3471 80.91.229.3 (3 Apr 2014 12:27:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Apr 2014 12:27:09 +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 14:27:04 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 1WVfU1-0003Mk-Nb for ged-emacs-devel@m.gmane.org; Thu, 03 Apr 2014 13:06:57 +0200 Original-Received: from localhost ([::1]:43298 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVfU1-0005BT-9O for ged-emacs-devel@m.gmane.org; Thu, 03 Apr 2014 07:06:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49305) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVfTt-0005A9-TO for emacs-devel@gnu.org; Thu, 03 Apr 2014 07:06:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WVfTo-0000BS-P7 for emacs-devel@gnu.org; Thu, 03 Apr 2014 07:06:49 -0400 Original-Received: from mail-we0-x22b.google.com ([2a00:1450:400c:c03::22b]:34990) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVfTo-0000Ay-I5 for emacs-devel@gnu.org; Thu, 03 Apr 2014 07:06:44 -0400 Original-Received: by mail-we0-f171.google.com with SMTP id t61so1649260wes.16 for ; Thu, 03 Apr 2014 04:06:43 -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=/HkfK+JBplJ1CBIiacw7V9QpZMmOkHVaxYwRTOt0Hwc=; b=0BHxCt5eq0SMk8GmmrmHRJoN7cCtl2uIaQgekm5TbGdUE7CZ+88vL7WsG21V6CENHg EnmrWlXs3y6TQVU8u2E61j3WiYTaeOpfnvVfroN611xpfQ797hCeaczRU3Wk6gwyvuG4 a68EotEpV72U+TegwNKSSVCkweDBr+rFjKFe0z5AB7LQeCrnUGYa2rRuZEEUI+OhR1tZ wwQjRgfEwBwExlY2guLfezTrCvKH+igrNGVESBtaljfb6cpoQGstwUmits0ewb75AEda L7T85cqnc9iVWYnIyVgkwrXRo9ZDF0cfc0XE8KKcxZM6zpXq8R0EhcRA/mC3ED+BNACs a7XQ== X-Received: by 10.194.60.114 with SMTP id g18mr9104310wjr.61.1396523203502; Thu, 03 Apr 2014 04:06:43 -0700 (PDT) Original-Received: from BELMONTE.yourcompany.com (a81-84-241-129.static.cpe.netcabo.pt. [81.84.241.129]) by mx.google.com with ESMTPSA id mw3sm45573349wic.7.2014.04.03.04.06.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Apr 2014 04:06:42 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Wed, 02 Apr 2014 18:58:11 -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:c03::22b 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:171269 Archived-At: Stefan Monnier writes: >> This last behaviour is also arguable but it is "way too clever", almost >> buggy. The trunk's behaviour is better: it always inhibits pairing, the >> surprising electric action, whenever there is unbalance, and as such is >> more predictable. > > That makes sense. But its calling (syntax-ppss (point-max)) will result > in large delays at times You're right. I dug up https://github.com/capitaomorte/autopair/issues/38 https://github.com/capitaomorte/autopair/pull/30 and noticed that I managed to improve autopair there, but not beyond the limit that you mention. In the large python file attached to the first issue, I experience a 1 sec delay in my linux box and 5-6 secs in windows (on par with moving to the end of the buffer). > (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 > Maybe it's OK because the rest of the code already > causes similar delays. 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. > 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?). But even even in those languages, syntax (and fontification) works across newlines, so do we pair for the language or for the syntax? 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) (defvar electric-pair-quote-scan-bound 50000 "Number of chars to search when deciding quote pairing.") (defun electric-pair--unbalanced-strings-p (char) "Return non-nil if there are unbalanced strings started by CHAR" (let* ((bound (+ electric-pair-quote-scan-bound (point))) (selector-ppss (syntax-ppss)) (relevant-ppss (save-excursion (if (nth 4 selector-ppss) ; comment (electric-pair--syntax-ppss (progn (goto-char (nth 8 selector-ppss)) (forward-comment (point-max)) (skip-syntax-backward " >!") (point))) (syntax-ppss (min bound (point-max)))))) (string-delim (nth 3 relevant-ppss))) (and (or (eq t string-delim) (eq char string-delim)) (condition-case nil (progn (scan-sexps (nth 8 relevant-ppss) 1) nil) (scan-error t))))) Jo=E3o