From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Barzilay Newsgroups: gmane.emacs.bugs Subject: bug#4136: 23.1; delete-pair Date: Sun, 16 Aug 2009 23:13:49 -0400 Message-ID: <19080.51949.798286.416193@winooski.ccs.neu.edu> References: <19075.45378.67131.491453@winooski.ccs.neu.edu> <4A83E299.3060002@gmx.at> <87tz0bqqhm.fsf@mail.jurta.org> <4A850F6C.2080205@gmx.at> <873a7uc8mg.fsf@mail.jurta.org> <4A8689EE.9020402@gmx.at> <87ljlk4snf.fsf@mail.jurta.org> <87eirfs56q.fsf@mail.jurta.org> <19076.47996.128071.281272@winooski.ccs.neu.edu> <87pray9ezq.fsf@mail.jurta.org> <19078.4981.525959.210519@winooski.ccs.neu.edu> <87ab20znhd.fsf@mail.jurta.org> <19079.19478.357436.68768@winooski.ccs.neu.edu> <87k5131d3d.fsf@mail.jurta.org> Reply-To: Eli Barzilay , 4136@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1250479633 19029 80.91.229.12 (17 Aug 2009 03:27:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Aug 2009 03:27:13 +0000 (UTC) Cc: 4136@emacsbugs.donarmstrong.com To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Aug 17 05:27:06 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1McssD-0003Bj-8o for geb-bug-gnu-emacs@m.gmane.org; Mon, 17 Aug 2009 05:27:05 +0200 Original-Received: from localhost ([127.0.0.1]:47209 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1McssC-000600-Eq for geb-bug-gnu-emacs@m.gmane.org; Sun, 16 Aug 2009 23:27:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mcss6-0005yH-Gh for bug-gnu-emacs@gnu.org; Sun, 16 Aug 2009 23:26:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mcss1-0005tj-Ih for bug-gnu-emacs@gnu.org; Sun, 16 Aug 2009 23:26:58 -0400 Original-Received: from [199.232.76.173] (port=59956 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mcss1-0005ta-Bk for bug-gnu-emacs@gnu.org; Sun, 16 Aug 2009 23:26:53 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:37442) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mcss0-0004aA-Ic for bug-gnu-emacs@gnu.org; Sun, 16 Aug 2009 23:26:53 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7H3Qoee008330; Sun, 16 Aug 2009 20:26:50 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n7H3K4hS007154; Sun, 16 Aug 2009 20:20:04 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Eli Barzilay Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 17 Aug 2009 03:20:04 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 4136 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 4136-submit@emacsbugs.donarmstrong.com id=B4136.12504788346182 (code B ref 4136); Mon, 17 Aug 2009 03:20:04 +0000 Original-Received: (at 4136) by emacsbugs.donarmstrong.com; 17 Aug 2009 03:13:54 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from barzilay.org (winooski.ccs.neu.edu [129.10.115.117]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7H3DqJS006177 for <4136@emacsbugs.donarmstrong.com>; Sun, 16 Aug 2009 20:13:54 -0700 Original-Received: from eli by barzilay.org with local (Exim 4.66) (envelope-from ) id 1McsfN-0008Ll-Qa; Sun, 16 Aug 2009 23:13:49 -0400 In-Reply-To: <87k5131d3d.fsf@mail.jurta.org> X-Mailer: VM 7.19 under Emacs 22.1.1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Sun, 16 Aug 2009 23:26:58 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:30288 Archived-At: On Aug 17, Juri Linkov wrote: > > Still, the first time I tried this, the cursor was at the > > beginning of an indented line. > > Where did you get this weird idea that `delete-pair' should delete a > character far away from the current cursor position? Look, > `insert-char' inserts a character at point and `delete-char' deletes > a character at point. Only when there is a character there. > `insert-pair' inserts an opening character at point. So why > `delete-pair' shouldn't do the same? Why it shouldn't delete an > opening character at point instead of using some additional > heuristics to find the position of the opening character? We're going back in circles here: "delete *pair*" shouldn't delete an opening character unless it is part of a *pair*. If by the above you mean make it delete the character pair starting at the current point, then that seems fine -- as long as it verifies that there really is a pair. > >> That's why even in the current state of `delete-pair' it is the > >> useful reverse of `insert-pair' because the latter creates > >> balanced lists and the former deletes them. > > > > ... unless you happen to have your cursor on a non-paren. > > Why would I want to put cursor on a non-paren when I want to delete > a paren? You wouldn't, which is why throwing an error is the right thing. If you apply this exact same argument to `delete-char': Why would I want to put the cursor at the end of the buffer when I want to delete a character? it can justify making `delete-char' delete the preceding character when the cursor is at the eob. > >> > This version doesn't make much sense as an operation you'd want to do > >> > on code: > >> > > >> > (foo '(x y z)) > >> > --> > >> > (foo 'x y z) > >> > >> It makes sense when `foo' is a multi-argument function like `list', > >> e.g. > >> > >> (list 'x y z) > >> > >> So I see no reason to introduce more restrictions to decide what > >> parens the user is allowed to delete in his/her code. > > > > You've missed my point: the difference between "y" and "'y" is *huge*, > > changing one to the other is something that you don't want to do by > > mistake. > > 99% of time when you write a program it is in the erroneous state > until you finish editing. But this doesn't mean we should disallow > the user to have an intermediate erroneous state. So of course, in > the above example you can add necessary quotes after deleting a pair > of parentheses. That makes absolutely no sense. Yes, a file is usually at a bad state while it's being edited -- but that's not a reason to make things worse by an operation that hardly ever does what you (some random hacker) want to do. (And you don't want to do that because 'foo is unrelated to foo.) > >> I know, I know, after I fix this, you'll come up with another > >> test case like > >> > >> `foo bar' > > > > Those examples are very good IMO -- it's not being picky for > > nothing, it's an attempt to avoid nasty surprises that make you > > end up with erroneous code. Emacs is usually good at being a > > careful editor for code, `delete-pair' is very exceptional in this > > aspect. > > Emacs is good at following the KISS principle to not over-engineer > simple functions. Are you serious?? In v23 I'm counting about 500 lines of just elisp code for next/previous-line. It is the resulting behavior that should be simple -- and that sometimes requires considerable amount of code. Making `delete-pair' does what its name suggest *is* keeping it simple. The current version of the function is pretty much swapping the last two characters in "KISS". -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life!