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 13:33:51 -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 1396546469 18838 80.91.229.3 (3 Apr 2014 17:34:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Apr 2014 17:34:29 +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 19:34:22 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 1WVlWt-0006sS-Fy for ged-emacs-devel@m.gmane.org; Thu, 03 Apr 2014 19:34:19 +0200 Original-Received: from localhost ([::1]:45476 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVlWt-0005g4-3d for ged-emacs-devel@m.gmane.org; Thu, 03 Apr 2014 13:34:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVlWc-0005QB-59 for emacs-devel@gnu.org; Thu, 03 Apr 2014 13:34:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WVlWU-00040J-JJ for emacs-devel@gnu.org; Thu, 03 Apr 2014 13:34:02 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:58385) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVlWU-00040B-6k for emacs-devel@gnu.org; Thu, 03 Apr 2014 13:33:54 -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 s33HXpOZ002785; Thu, 3 Apr 2014 13:33:51 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 6988B60528; Thu, 3 Apr 2014 13:33:51 -0400 (EDT) In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1v?= =?windows-1252?Q?ora=22's?= message of "Thu, 03 Apr 2014 17:56:52 +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 <688> : streams <1151316> : uri <1719298> 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:171279 Archived-At: >> [ 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? Ah, so the difference is in the way they're compiled. The OS factor is just "an accident". > Yes I see. But for me it's definitely better not to pair in those > situations But you'll also do the opposite: if there's an extra " somewhere far in the rest of the file (somewhere the user can't see and/or can't care less about), and the user has added a spurious " nearby, she will expect her next " to not-pair up (so as to complete the locally-unmatched, tho globally matched quote), whereas your code will decide to pair. > Anyway the "oh, it didn't pair..." disappointment is better than Yes, but the code can go wrong both ways. > "Something acceptible" then is "not pairing", just the self-insertion > the user asked for, rught? Yes. Actually both pairing and non-pairing are acceptable. What is not would be to signal an error, for example. > If (+ (point) ) is less than (point-max) and inside a string > we additionally assert that at least that string is paired. Let's say (+ (point) ) falls on the second line of the text below: foo "bar" baz "toto titi tata "tutu" "blabla" should it say "yup, we're within the string 'toto\ntiti\ntata ' or should it say "no, we're not within a string"? If we agree that using (point-max) is a bad idea, then the only other option is to try and find some other spot in the buffer (and after point) which is somehow known to be "outside of a string", and in general we don't know how to find such a thing (point-max is the only one we know in general). Hence electric-pair-string-bound-function (or give up on this idea and do something different). > What about this? Seems to be much much faster in the python buffer i've > been testing with (even on windoze :-) I think this will fail when unmatched ' appear in comments. You could fix that by not changing the syntax-table, i.e. only replace syntax-ppss with parse-partial-sexp, but then you'll find other cases (more corner-case and harder to reproduce) where the lack of syntax-propertization causes parse-partial-sexp to get it wrong (e.g. unmatched quotes in here-documents). Stefan