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: Sat, 12 Apr 2014 01:42:06 +0100 Message-ID: <87y4zbqsyp.fsf@kitaj.lan> References: <87d2h0ujls.fsf_-_@kitaj.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1397263355 25384 80.91.229.3 (12 Apr 2014 00:42:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Apr 2014 00:42:35 +0000 (UTC) Cc: Kevin Rodgers , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 12 02:42:28 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 1WYm1c-0005GY-1m for ged-emacs-devel@m.gmane.org; Sat, 12 Apr 2014 02:42:28 +0200 Original-Received: from localhost ([::1]:60617 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYm1b-0000LV-IL for ged-emacs-devel@m.gmane.org; Fri, 11 Apr 2014 20:42:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52145) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYm1U-0000LH-Fs for emacs-devel@gnu.org; Fri, 11 Apr 2014 20:42:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WYm1P-0005rH-0m for emacs-devel@gnu.org; Fri, 11 Apr 2014 20:42:20 -0400 Original-Received: from mail-we0-x233.google.com ([2a00:1450:400c:c03::233]:56302) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYm1O-0005rB-Pi for emacs-devel@gnu.org; Fri, 11 Apr 2014 20:42:14 -0400 Original-Received: by mail-we0-f179.google.com with SMTP id x48so5889665wes.24 for ; Fri, 11 Apr 2014 17:42:13 -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=aF/BcJPJ0HVgFkFbZT6rT2staEXb3Xy+e09DLvJ65IU=; b=BH4aiXS0g9o/KPmZ6XgY4mCLn+D4Iu51gFjEl1XP/eEpN314EybsT3OmBwOSHfj7bH JL8/moMOUVoa34d1UKfaPYzqqdbhvxywlClUJxhhnalwHEtz7aHWtGdQPdOxfCQUenjY yASskWOIs70cQBGGkVO6xMnOcBc6xpHtjspKCOja816LZoQBqbDG7TJURqOQBO92bxjV rDYWA8/w2hNES87UP8v+fofPUQfPtQQf1qA0l/ngjp9+BmbLwb62SFcpCurXMNj2fmiJ /InGM356gkRDJarZZMYXIN47I0fRAFZ/icHV8IW4G6UvdLSBv1oP5vYiMNOf5/ktA1bS BT8g== X-Received: by 10.180.104.161 with SMTP id gf1mr499517wib.38.1397263333617; Fri, 11 Apr 2014 17:42:13 -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 xm20sm7438848wib.19.2014.04.11.17.42.12 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 11 Apr 2014 17:42:12 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Fri, 11 Apr 2014 15:58:40 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c03::233 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:171408 Archived-At: Stefan Monnier writes: >> Re-reading Kevin's message I think there are two separate things here: > >> * deciding if the buffer is quote-balanced for pairing purposes. That >> can indeed only be done according to your idea Stefan, i.e. finding a >> safe spot the we assert to be outside a string. > >> * after having obtained reliable info that the buffer is unbalanced, we >> can further decide if we want to surprise/disappoint the user. This >> might be argued I think: if we know that there is an unbalance but >> that it is outside the users view, decide to pair anyway. If it is in >> the user's view, try to repair the unbalance by not pairing (this >> second bit is what is already done) > >> I don't know if I personally would like it, perhaps it can be a >> customization option. > > For strings, if we know that position POS, which should be outside of > a string, is inside a string, we know that there's an imbalance. *But* > we don't actually know where that imbalance comes from (it's just > "somewhere before POS"), so we can't really tell if that imbalance is > before or after window-end unless POS is itself before window-end. I think you're right. But if there is unbalance and one of the following is true: * the first non-string position searching backwards from (window-end) downto (point) is sucessfully asserted to be outside a string, or * there are no strings at all between (point) and window end (basically implies the previous point). then I think it is doable, i.e. there is a case for autopairing despite the unbalance. Not sure how useful, though. Needs prototyping, and I'm not super-motivated to do it right now. Jo=C3=A3o