From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joaotavora@gmail.com (=?utf-8?B?Sm/Do28gVMOhdm9yYQ==?=) Newsgroups: gmane.emacs.devel Subject: Re: Emacs pretest -- electric-pair-mode change Date: Thu, 03 Apr 2014 21:11:49 +0100 Message-ID: <87sipujhq2.fsf@kitaj.lan> References: <87d2h0ujls.fsf_-_@kitaj.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1396555939 7460 80.91.229.3 (3 Apr 2014 20:12:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Apr 2014 20:12:19 +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 22:12:13 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 1WVnze-000763-PF for ged-emacs-devel@m.gmane.org; Thu, 03 Apr 2014 22:12:10 +0200 Original-Received: from localhost ([::1]:46224 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVnze-0000Eu-Bz for ged-emacs-devel@m.gmane.org; Thu, 03 Apr 2014 16:12:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53065) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVnzW-0000EF-Ov for emacs-devel@gnu.org; Thu, 03 Apr 2014 16:12:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WVnzO-00022j-NX for emacs-devel@gnu.org; Thu, 03 Apr 2014 16:12:02 -0400 Original-Received: from mail-wi0-x236.google.com ([2a00:1450:400c:c05::236]:35380) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVnzO-00022T-42 for emacs-devel@gnu.org; Thu, 03 Apr 2014 16:11:54 -0400 Original-Received: by mail-wi0-f182.google.com with SMTP id d1so50961wiv.9 for ; Thu, 03 Apr 2014 13:11:53 -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; bh=RVayiv8UGCv0fKE9ssknbi48Hf+h97bPEIubP+04HXE=; b=SFSPxPffluv+A6eKxu35tU747U1hYTaEMHe9bor2wo/xluR+yia5LkCElCdwv3oZkM 3KPPvs1ruBi2IaGZ8n1mXDI1OG15o0W9w6eROkVkuS0TCaqG2N7ZkULQrfByhS7T1srM jJBDWoO0PowtJOnElnnpmZJlmD2FhegR1fWyYYYfPKVkuqB2cC28iFHMOBU3TiDoHgnd fcFb9a9lec41+h/tfkWecaIRsBrCmkvvZdS+fwpje/44u0axv1hVwsJ5tgYiaYPIy5Mm 5uZj/7qOfygtdK1QDXVpVBOKGi2/TGmZVOUQ9D0xOgFCbw7AaLD1vocvHWAYPabtZgb8 mdWQ== X-Received: by 10.194.188.68 with SMTP id fy4mr13765293wjc.30.1396555913041; Thu, 03 Apr 2014 13:11:53 -0700 (PDT) Original-Received: from kitaj.lan.yourcompany.com (66.207.108.93.rev.vodafone.pt. [93.108.207.66]) by mx.google.com with ESMTPSA id g5sm9146472wjs.8.2014.04.03.13.11.51 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 03 Apr 2014 13:11:52 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Thu, 03 Apr 2014 13:33:51 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::236 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:171286 Archived-At: Stefan Monnier writes: >>> [ 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 > Ah, so the difference is in the way they're compiled. Of course, scheduling aside, in the end that's always true :-). I might have misunderstood Eli Zaretskii's: http://lists.gnu.org/archive/html/emacs-devel/2014-03/msg00930.html But in general, is the machine-code for windows builds exactly the same (or very similar) as linux for things involved in these operations? If so, how can I check the compile flags of a build? Because mine really is slower. My OSX build is also much slower, FWIW, not as slow as windows tho. >> 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. True, with this important detail: she had the second surprise coming, since the spurious " she added nearby *didn't* pair, which is an early indication of unbalacing. > 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"? It will be mistake itself say "everything's fine, proceed with the pairing", which is one of the cases where it's wrong, as I had already admitted. But when it says "it's wrong,.don't pair" it will be always right. And if constant is made big enough the number of mistakes decreases (though not by much I admit). > 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). Hmmm I understand your idea better. Using that with a default implementation returning (point-max) might be a good idea, modes that are experiencing trouble can then write their complicated versions. >> 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). I see. I did that syntax-table change thinking *that* would make it faster, but it was using `parse-partial-sexp' that did (why?). Anyway, I think I could live with those cases of mispairings like those here-documents. Do you have other prominent cases? I always think of electric-pair-mode's balancing as a best-effort thing.