bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#4136: 23.1; delete-pair


From: Eli Barzilay
Subject: bug#4136: 23.1; delete-pair
Date: Sun, 16 Aug 2009 23:13:49 -0400

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!





reply via email to

[Prev in Thread] Current Thread [Next in Thread]