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: Fri, 11 Apr 2014 17:08:32 +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 1397232549 23299 80.91.229.3 (11 Apr 2014 16:09:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Apr 2014 16:09:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: Kevin Rodgers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 11 18:09:01 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 1WYe0h-0006wd-F9 for ged-emacs-devel@m.gmane.org; Fri, 11 Apr 2014 18:08:59 +0200 Original-Received: from localhost ([::1]:58743 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYe0g-00088i-Oe for ged-emacs-devel@m.gmane.org; Fri, 11 Apr 2014 12:08:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYe0V-00084a-98 for emacs-devel@gnu.org; Fri, 11 Apr 2014 12:08:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WYe0M-0004hF-2j for emacs-devel@gnu.org; Fri, 11 Apr 2014 12:08:47 -0400 Original-Received: from mail-we0-x22d.google.com ([2a00:1450:400c:c03::22d]:57484) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYe0L-0004gs-Ss for emacs-devel@gnu.org; Fri, 11 Apr 2014 12:08:38 -0400 Original-Received: by mail-we0-f173.google.com with SMTP id w61so5498457wes.4 for ; Fri, 11 Apr 2014 09:08:36 -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=FRDyenPUEH4IoBZwp3O/fC5TS7JXrQ5gOIOieT1xXgs=; b=0AhFjhgCo7X31PaEDew6zWVG8KHUldNAR8Zg3ej2Wg+F9uh2A2DHICvJXiPUk4G3O2 ISV8SCBPgVT6iqLfJAdgFNB1X8ukNd+gLCBIF9vw5PCd2Yawh3ukB6lB8qBcsc+c9fL2 ulrXhlwMZSbhm5FT3u+GOOjNozzStwUBrjQwyqQT0uYO1eb+6BMgX1GsB/TEV3DaxAGw x/FFv7758IcDoXR1Tz/M2YZT5HWHl5TKhW9khiWD8OspHkisRMT95HUF1FK82mmpCMKS 1+faPnzjw2GzAK5F4Hv+AsPsP7Ab3mshnm4nbPtM3Rn5uR1tkPK2v07DJWaCu+xoCn7i jCBQ== X-Received: by 10.180.206.167 with SMTP id lp7mr3326972wic.37.1397232516466; Fri, 11 Apr 2014 09:08:36 -0700 (PDT) Original-Received: from MONTIJO.yourcompany.com (mail3.siscog.pt. [195.23.29.18]) by mx.google.com with ESMTPSA id bj5sm5278813wib.3.2014.04.11.09.08.34 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Apr 2014 09:08:35 -0700 (PDT) In-Reply-To: (Kevin Rodgers's message of "Fri, 11 Apr 2014 08:42:52 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.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::22d 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:171400 Archived-At: Kevin Rodgers writes: > On 4/3/14 11:33 AM, Stefan Monnier wrote: >> 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. I remember considering this idea, and then abandoning it. I can't remember the reasoning any more :-), but I think it went along the lines of "It's possibly nice when (window-end) lands me outside a string, but what if it lands me inside one? Should I assume the buffer is quote-unbalanced and not autopair the quote? Should I check if that window-end-crossing string is terminated? In general it will always be even if by some other unbalanced quote. So if I do that it's just as slow and also harder to predict.". All in all think I prefer the current behaviour, which, by default, only asserts that (point-max) is outside a string for sure. Here's a related argument I've made before: If the user has left an unbalanced string far away down the buffer (i.e. unbalancing starts there), there might be some disappointment to not seeing the current quote being inserted pair, but then it's also a warning that something is wrong with the quote balance somewhere down. The warning comes from not only seeing the quote not be autopaired but also from the strange fontification that ensues. Jo=E3o