From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kevin Rodgers Newsgroups: gmane.emacs.devel Subject: Re: Emacs pretest -- electric-pair-mode change Date: Fri, 11 Apr 2014 08:42:52 -0600 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; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1397227337 10137 80.91.229.3 (11 Apr 2014 14:42:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Apr 2014 14:42:17 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 11 16:42:10 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 1WYcee-0006uE-6A for ged-emacs-devel@m.gmane.org; Fri, 11 Apr 2014 16:42:08 +0200 Original-Received: from localhost ([::1]:58034 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYced-0006Zd-PP for ged-emacs-devel@m.gmane.org; Fri, 11 Apr 2014 10:42:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYceT-0006YX-RK for emacs-devel@gnu.org; Fri, 11 Apr 2014 10:42:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WYceM-00014c-AL for emacs-devel@gnu.org; Fri, 11 Apr 2014 10:41:57 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:48368) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYceM-00014T-3z for emacs-devel@gnu.org; Fri, 11 Apr 2014 10:41:50 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WYceH-0006Xy-1d for emacs-devel@gnu.org; Fri, 11 Apr 2014 16:41:45 +0200 Original-Received: from 70-59-41-30.hlrn.qwest.net ([70.59.41.30]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Apr 2014 16:41:45 +0200 Original-Received: from kevin.d.rodgers by 70-59-41-30.hlrn.qwest.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Apr 2014 16:41:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 55 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 70-59-41-30.hlrn.qwest.net User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:171397 Archived-At: On 4/3/14 11:33 AM, Stefan Monnier wrote: >>> [ 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). Would replacing (+ (point) ) with (window-end) give reliable behavior, from the user's perspective? If the extra " is not visible, it would not impact the result. -- Kevin Rodgers Denver, Colorado, USA