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: Thu, 03 Apr 2014 14:43:49 +0100 Message-ID: References: <87d2h0ujls.fsf_-_@kitaj.lan> <8761mqfw38.fsf@yandex.ru> 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 1396532947 30040 80.91.229.3 (3 Apr 2014 13:49:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Apr 2014 13:49:07 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 03 15:49: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 1WVhwB-0007nV-K0 for ged-emacs-devel@m.gmane.org; Thu, 03 Apr 2014 15:44:11 +0200 Original-Received: from localhost ([::1]:44130 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVhwB-0001Mk-5N for ged-emacs-devel@m.gmane.org; Thu, 03 Apr 2014 09:44:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60770) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVhw1-0001Dg-8V for emacs-devel@gnu.org; Thu, 03 Apr 2014 09:44:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WVhvv-0003XX-9P for emacs-devel@gnu.org; Thu, 03 Apr 2014 09:44:01 -0400 Original-Received: from mail-wg0-x233.google.com ([2a00:1450:400c:c00::233]:63953) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVhvv-0003XS-3T for emacs-devel@gnu.org; Thu, 03 Apr 2014 09:43:55 -0400 Original-Received: by mail-wg0-f51.google.com with SMTP id k14so1908812wgh.22 for ; Thu, 03 Apr 2014 06:43:54 -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=+N3TXoHvwV6l91QUqQvswIw/j+4Og6Ib1k/UqHnOb98=; b=BuMre/bDIl9N7DPdb06YBXNK6LuKoOyI1w7NRVIRHSw60YePUuYJwU4A0ZfjU8fHK4 efw/X7JBUefXmh6+2pr8o3MW6RkqYHWUOvjqoCuCqWPenTlaFqZONykDc+0pG3U59GeE E7XsPWymx4m/FrobI2ch/iVq9qqPsYN/mEoW29CRp6qAAiYPpwSjRXjm+Vyr+E3uHrxx GDwsBY+gPYjuum5SQlzsBSz5OKkz0dR4wn8kWs4z6TsjgHQx5Y5LoFtam+ZpP6UlnTzh fUMeR0O/qK4w+zNu1yOVo2EzxS6ujPJJgy1u/2QtNvcVQcabUT/k8wevD34BMVdvyzHp 06vw== X-Received: by 10.194.9.73 with SMTP id x9mr10420415wja.79.1396532634025; Thu, 03 Apr 2014 06:43:54 -0700 (PDT) Original-Received: from BELMONTE.yourcompany.com (a81-84-241-129.static.cpe.netcabo.pt. [81.84.241.129]) by mx.google.com with ESMTPSA id ct2sm7767620wjb.33.2014.04.03.06.43.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Apr 2014 06:43:53 -0700 (PDT) In-Reply-To: <8761mqfw38.fsf@yandex.ru> (Dmitry Gutov's message of "Thu, 03 Apr 2014 15:15:07 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (windows-nt) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::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:171271 Archived-At: Dmitry Gutov writes: > joaotavora@gmail.com (Jo=E3o T=E1vora) writes: > >> This last behaviour is also arguable but it is "way too clever", almost >> buggy. The trunk's behaviour is better: it always inhibits pairing, the >> surprising electric action, whenever there is unbalance, and as such is >> more predictable. > > I don't see what can be "too clever" about it. It's either buggy, or just > sloppy (as in: electric-pair-mode isn't aware of that specific case). It's too clever because I was trying to implement the reasoning that only if the string immediately following point being unbalanced can you be sure that inhibiting is the right thing. Because if strings are unbalanced in the whole buffer you can't really be sure whether the correct is thing is to add just the one quote at beginning or at the end. I also had faster implementation, but that was a side effect. Anyway, a few weeks using it, I realized that this behaviour is annoying, is practically never what I want, and is hard to predict. Jo=E3o