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 19:23:36 +0100 Message-ID: References: <87d2h0ujls.fsf_-_@kitaj.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1397240644 2750 80.91.229.3 (11 Apr 2014 18:24:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Apr 2014 18:24:04 +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 Fri Apr 11 20:23:57 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 1WYg7I-0002el-Rl for ged-emacs-devel@m.gmane.org; Fri, 11 Apr 2014 20:23:56 +0200 Original-Received: from localhost ([::1]:59369 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYg7I-0001IR-CE for ged-emacs-devel@m.gmane.org; Fri, 11 Apr 2014 14:23:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48632) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYg7A-0001IL-2a for emacs-devel@gnu.org; Fri, 11 Apr 2014 14:23:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WYg74-0005XU-Kn for emacs-devel@gnu.org; Fri, 11 Apr 2014 14:23:48 -0400 Original-Received: from mail-wi0-x235.google.com ([2a00:1450:400c:c05::235]:51831) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYg74-0005XH-DZ for emacs-devel@gnu.org; Fri, 11 Apr 2014 14:23:42 -0400 Original-Received: by mail-wi0-f181.google.com with SMTP id hm4so1467934wib.14 for ; Fri, 11 Apr 2014 11:23:40 -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=wpLJnYEmSackwTp1p2cTr5tvz0XN7CbWB/GqeBcAhAo=; b=EqXmnGukRHj9HZ96HlwvJQpOMPYe1iBDmwQ8K9agnCDHqWFnh8n1Ygm5OjwLhfSpEN gyLpQhjfG0fjjDimToqQTltPK12c4AisEapPJDPTk3qq80jzQteroHOmWg2WHaezKBSa BXA6TeK1K7qCByNX1Snk25L44THikBtFHYz6zAz48bPVPBY+Yr1O3L7a2H2QuhBQL87Q a8oqlSwd6zD003EOs81c82xy1DulGczW1pPrJtgFLyXow0fMCBayP/AXJJsiECQRGteO 6JuRUy8I0RYLOubtQHNA6DtSx6Hcx3i5sy7hODl4n214VQL+a2aZXtMNDoAgxY9k2Wrq GXfQ== X-Received: by 10.180.97.37 with SMTP id dx5mr4608076wib.53.1397240620873; Fri, 11 Apr 2014 11:23:40 -0700 (PDT) Original-Received: from MONTIJO.yourcompany.com (mail3.siscog.pt. [195.23.29.18]) by mx.google.com with ESMTPSA id c7sm12318332wjf.19.2014.04.11.11.23.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Apr 2014 11:23:39 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Fri, 11 Apr 2014 11:53:15 -0400") 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:c05::235 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:171401 Archived-At: Stefan Monnier writes: >> 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. > > No, the problem is not the distance, the problem is to find a position > that we know is outside of a string. There's no reason why > (window-end) should be presumed to be outside of any string. 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.