From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Emacs pretest -- electric-pair-mode change Date: Thu, 03 Apr 2014 15:15:07 +0300 Message-ID: <8761mqfw38.fsf@yandex.ru> 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 1396527852 32290 80.91.229.3 (3 Apr 2014 12:24:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Apr 2014 12:24:12 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: joaotavora@gmail.com (=?utf-8?B?Sm/Do28gVMOhdm9yYQ==?=) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 03 14:24:05 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 1WVgYT-00067A-08 for ged-emacs-devel@m.gmane.org; Thu, 03 Apr 2014 14:15:37 +0200 Original-Received: from localhost ([::1]:43737 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVgYS-0003kW-Gm for ged-emacs-devel@m.gmane.org; Thu, 03 Apr 2014 08:15:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35186) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVgYF-0003kN-DR for emacs-devel@gnu.org; Thu, 03 Apr 2014 08:15:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WVgY6-0006DA-BR for emacs-devel@gnu.org; Thu, 03 Apr 2014 08:15:23 -0400 Original-Received: from mail-wg0-x22f.google.com ([2a00:1450:400c:c00::22f]:47605) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVgY6-0006C3-5D for emacs-devel@gnu.org; Thu, 03 Apr 2014 08:15:14 -0400 Original-Received: by mail-wg0-f47.google.com with SMTP id x12so1774596wgg.30 for ; Thu, 03 Apr 2014 05:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=GRDp6FcY49laNQYKVxfyD53NCoq/EX7bNjW9hp6w1Z4=; b=DbgPP2TmgwBJnq8FIKQEVpw+G0LOPGuI9xp5FVD++IVs++5FfZt2abfRh3CweqmYT0 fZEoeUB0eSmcwobgf+xlAKxgnamjceXywnjJFlSnXPIyI3u2OS11xP+tVPCY4lgZ6rr1 OabWQwLcBOleps2gWfhdU3dS9tdYyWKEEg7VJHPENxqBG8ZTIK2iykYWUZvAan1QzjLS UC7HGof3S+B4vwrGOAhyLuOIv3GT4ZDehgGELj8R6bvqGgGKZWC0hYTwn7gOXKsRCTrG QWxWBb+VUAr+JsFq/5liRhFnurUsAvnA4EhfzjPEi299dC65gGqwBSr9BYM2dMOZ50Cu LXbw== X-Received: by 10.180.188.66 with SMTP id fy2mr10472066wic.45.1396527312899; Thu, 03 Apr 2014 05:15:12 -0700 (PDT) Original-Received: from axl (93-20-136.netrun.cytanet.com.cy. [93.109.20.136]) by mx.google.com with ESMTPSA id p8sm11651951eef.26.2014.04.03.05.15.10 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 03 Apr 2014 05:15:12 -0700 (PDT) In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vo?= =?utf-8?Q?ra=22's?= message of "Wed, 02 Apr 2014 18:21:34 +0100") 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:c00::22f 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:171268 Archived-At: joaotavora@gmail.com (Jo=C3=A3o T=C3=A1vora) 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). >>> Anyway I've haven't gotten little feedback for this feature, negative or >>> positive. I'm using it. I like it, and I've filed just one bug for it as of yet. >> `electric-pair-mode' (even the old one) is not a commonly used option, >> IIUC. This is largely because it's not enabled by default, many people >> don't like/want such a feature, and those who do want it have many ways >> to get it, many of which predate electric-pair-mode. Since it's not commonly used, yet, any possible breakage introduced with this change would also be less of a problem. > But both being predictable, these users these packages are less likely > to switch or even try electric-pair-mode if it feels alien or hard to > predict, which IMO was *exactly* the problem with the "old" > electric-pair-mode. +1