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 16:54:53 -0400 Message-ID: References: <87d2h0ujls.fsf_-_@kitaj.lan> <87sipujhq2.fsf@kitaj.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1396558559 7256 80.91.229.3 (3 Apr 2014 20:55:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Apr 2014 20:55:59 +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 22:55:47 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 1WVofm-0000R0-MN for ged-emacs-devel@m.gmane.org; Thu, 03 Apr 2014 22:55:42 +0200 Original-Received: from localhost ([::1]:46380 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVofm-0008IC-Cs for ged-emacs-devel@m.gmane.org; Thu, 03 Apr 2014 16:55:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33386) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVofX-0008Ed-O6 for emacs-devel@gnu.org; Thu, 03 Apr 2014 16:55:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WVofO-00087N-TO for emacs-devel@gnu.org; Thu, 03 Apr 2014 16:55:27 -0400 Original-Received: from mercure.iro.umontreal.ca ([132.204.24.67]:45110) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVofO-00086u-Nm for emacs-devel@gnu.org; Thu, 03 Apr 2014 16:55:18 -0400 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id D2FCD84D9A; Thu, 3 Apr 2014 16:55:17 -0400 (EDT) Original-Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 8AE6B1E5B74; Thu, 3 Apr 2014 16:54:53 -0400 (EDT) Original-Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 57F46B4287; Thu, 3 Apr 2014 16:54:53 -0400 (EDT) In-Reply-To: <87sipujhq2.fsf@kitaj.lan> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?= =?windows-1252?Q?ra=22's?= message of "Thu, 03 Apr 2014 21:11:49 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 132.204.24.67 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:171287 Archived-At: >> 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). It basically means that we'll always say "don't pair" if (+ (point) ) is before the last quote in the buffer. If (+ (point) ) is not near point-max then it'll basically "always" be before the last quote. So this heuristic reduces to "only try to pair in the last chars of the buffer". >> 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. Right. > I see. I did that syntax-table change thinking *that* would make it > faster, but it was using `parse-partial-sexp' that did (why?). Because it avoids syntax-propertize. > Anyway, I think I could live with those cases of mispairings like > those here-documents. Right, but a "mispairing" will throw off all your pairing decisions before that mispairing. So a mispairing near the end of the file will throw off your algorithm pretty much all the time, and the user won't understand it because if/when she decides to go look at the end of the file, the problem disappears. I.e. then it *really* becomes unpredictable. And the frequency of those mispairing depends on the major-mode, since some major modes depend more on syntax-propertize then others. Stefan