bug#4136: 23.1; delete-pair

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

Eli Barzilay
`delete-pair' is deleting what it documents -- instead of removing the
open paren of the following sexp, it deletes the current one.  So, if
the cursor is on some whitespace that precedes an expression, the
whitespace is deleted, and the open paren is left intact.



In GNU Emacs 23.1.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.10.14)
 of 2009-08-01 on winooski.ccs.neu.edu
Windowing system distributor `The X.Org Foundation', version 11.0.10300000
configured using `configure  '--prefix=/home/eli/bin/local/emacs-dir''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: POSIX
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US
  value of $XMODIFIERS: nil
  locale-coding-system: iso-latin-1-unix
  default-enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  cua-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  line-number-mode: t
  transient-mark-mode: t




Reply | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

martin rudalics
 > `delete-pair' is deleting what it documents -- instead of removing the
 > open paren of the following sexp, it deletes the current one.  So, if
 > the cursor is on some whitespace that precedes an expression, the
 > whitespace is deleted, and the open paren is left intact.

`delete-pair' shouldn't delete anything but matching elements of
`insert-pair-alist'.

martin



Reply | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

Juri Linkov
In reply to this post by Eli Barzilay
> `delete-pair' is deleting what it documents -- instead of removing the
> open paren of the following sexp, it deletes the current one.  So, if
> the cursor is on some whitespace that precedes an expression, the
> whitespace is deleted, and the open paren is left intact.

This should be fixed with the following patch:

Index: lisp/emacs-lisp/lisp.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/emacs-lisp/lisp.el,v
retrieving revision 1.102
diff -u -r1.102 lisp.el
--- lisp/emacs-lisp/lisp.el 22 Jul 2009 02:45:37 -0000 1.102
+++ lisp/emacs-lisp/lisp.el 13 Aug 2009 23:27:42 -0000
@@ -530,8 +530,12 @@
 (defun delete-pair ()
   "Delete a pair of characters enclosing the sexp that follows point."
   (interactive)
-  (save-excursion (forward-sexp 1) (delete-char -1))
-  (delete-char 1))
+  (save-excursion
+    (forward-sexp 1)
+    (save-excursion
+      (backward-sexp 1)
+      (delete-char 1))
+    (delete-char -1)))
 
 (defun raise-sexp (&optional arg)
   "Raise ARG sexps higher up the tree."

--
Juri Linkov
http://www.jurta.org/emacs/



Reply | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

Juri Linkov
In reply to this post by martin rudalics
>> `delete-pair' is deleting what it documents -- instead of removing the
>> open paren of the following sexp, it deletes the current one.  So, if
>> the cursor is on some whitespace that precedes an expression, the
>> whitespace is deleted, and the open paren is left intact.
>
> `delete-pair' shouldn't delete anything but matching elements of
> `insert-pair-alist'.

This is rather vague semantics.  I suggest to keep the current simple
semantics and just to fix it with the patch I sent.

--
Juri Linkov
http://www.jurta.org/emacs/



Reply | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

Eli Barzilay
In reply to this post by martin rudalics
On Aug 13, martin rudalics wrote:
>  > `delete-pair' is deleting what it documents -- instead of removing the
>  > open paren of the following sexp, it deletes the current one.  So, if
>  > the cursor is on some whitespace that precedes an expression, the
>  > whitespace is deleted, and the open paren is left intact.
>
> `delete-pair' shouldn't delete anything but matching elements of
> `insert-pair-alist'.

This is a very good point.


On Aug 14, Juri Linkov wrote:

> >> `delete-pair' is deleting what it documents -- instead of removing the
> >> open paren of the following sexp, it deletes the current one.  So, if
> >> the cursor is on some whitespace that precedes an expression, the
> >> whitespace is deleted, and the open paren is left intact.
> >
> > `delete-pair' shouldn't delete anything but matching elements of
> > `insert-pair-alist'.
>
> This is rather vague semantics.  I suggest to keep the current simple
> semantics and just to fix it with the patch I sent.

I disagree in two different ways: (a) it can be put into code, so it's
not vague at all; (b) it sounds like a very good feature -- as it
stands, this function is nearly useless without human supervision,
which makes it useless for keyboard macros.

Here is a version that checks that does exactly what Martin suggested.
It even fails on something like (...] -- which is very useful for
keyboard macros, since if you have that text in a buffer, then
something is probably messed up enough to require your attention.


(defun delete-pair ()
  "Delete a pair of characters enclosing the sexp that follows point."
  (interactive)
  (save-excursion
    (let* ((end      (progn (forward-sexp  1) (point)))
           (start    (progn (forward-sexp -1) (point)))
           (start-ch (char-after start))
           (end-ch   (char-before end))
           (match-p  nil))
      (let ((p insert-pair-alist))
        (while p
          (let* ((q (car p))
                 (fst (if (= (length q) 3) 1 0))
                 (snd (1+ fst)))
            (if (and (equal start-ch (nth fst q))
                     (equal end-ch   (nth snd q)))
              (setq p nil match-p t)
              (setq p (cdr p))))))
      (if match-p
        (progn (delete-region (1- end) end)
               (delete-region start (1+ start)))
        (error "not a matching pair")))))


--
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!



Reply | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

martin rudalics
In reply to this post by Juri Linkov
 > This is rather vague semantics.  I suggest to keep the current simple
 > semantics and just to fix it with the patch I sent.

Before a quoted object your fixed version deletes the last character of
the object and the first quote character.  Handling quote or prefix
syntax characters via (delete-char 1) doesn't strike me as very clean.

martin



Reply | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

Stefan Monnier
In reply to this post by Eli Barzilay
> Here is a version that checks that does exactly what Martin suggested.
> It even fails on something like (...] -- which is very useful for
> keyboard macros, since if you have that text in a buffer, then
> something is probably messed up enough to require your attention.

There's always a tension in such cases.  E.g. for interactive use, I'd
rather we allow such (..] cases, since it may occasionally come in handy
(whereas the beep will come as a major annoyance, where Emacs will
appear to the user as being dogmatic).


        Stefan




Reply | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

Juri Linkov
In reply to this post by martin rudalics
>> This is rather vague semantics.  I suggest to keep the current simple
>> semantics and just to fix it with the patch I sent.
>
> Before a quoted object your fixed version deletes the last character of
> the object and the first quote character.  Handling quote or prefix
> syntax characters via (delete-char 1) doesn't strike me as very clean.

This is fixed in the following version:

(defun delete-pair ()
  "Delete a pair of characters enclosing the sexp that follows point."
  (interactive)
  (save-excursion
    (forward-sexp 1)
    (save-excursion
      (backward-sexp 1)
      (skip-syntax-forward "'")
      (delete-char 1))
    (delete-char -1)))

--
Juri Linkov
http://www.jurta.org/emacs/



Reply | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

Juri Linkov
In reply to this post by Eli Barzilay
> Here is a version that checks that does exactly what Martin suggested.
> It even fails on something like (...] -- which is very useful for
> keyboard macros, since if you have that text in a buffer, then
> something is probably messed up enough to require your attention.

This command is useful even if it doesn't fail on (...] because
forward-sexp and backward-sexp don't fail on (...].

It seems you and Martin prefer checking against the `insert-pair-alist'
because the function name `delete-pair' suggests it should be
a counterpart of `insert-pair'.  In this case I think we sould have
two commands: one more strict version `delete-pair' that checks
`insert-pair-alist', and another loose version with the name e.g.
`delete-parens' with the body of the current `delete-pair'.

--
Juri Linkov
http://www.jurta.org/emacs/



Reply | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

Eli Barzilay
On Aug 15, Juri Linkov wrote:
> > Here is a version that checks that does exactly what Martin
> > suggested.  It even fails on something like (...] -- which is very
> > useful for keyboard macros, since if you have that text in a
> > buffer, then something is probably messed up enough to require
> > your attention.
>
> This command is useful even if it doesn't fail on (...] because
> forward-sexp and backward-sexp don't fail on (...].

Martin's example of '(blah) works better, but in general...

> It seems you and Martin prefer checking against the
> `insert-pair-alist' because the function name `delete-pair' suggests
> it should be a counterpart of `insert-pair'.

...this is exactly the issue: it is much better if `delete-foo' is
always an operation that reverts what `insert-foo' does.


> In this case I think we sould have two commands: one more strict
> version `delete-pair' that checks `insert-pair-alist', and another
> loose version with the name e.g.  `delete-parens' with the body of
> the current `delete-pair'.

The current state of `delete-pair' is so bad that my guess is that
hardly anyone used it, so adding another command doesn't make much
sense.  How about making it do the proper thing (removing only
balanced pairs as specified by `insert-pair-alist'), and ignoring
errors with a prefix argument?


On Aug 15, Juri Linkov wrote:

> >> This is rather vague semantics.  I suggest to keep the current
> >> simple semantics and just to fix it with the patch I sent.
> >
> > Before a quoted object your fixed version deletes the last
> > character of the object and the first quote character.  Handling
> > quote or prefix syntax characters via (delete-char 1) doesn't
> > strike me as very clean.
>
> This is fixed in the following version:
> [...]

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)

--
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!



Reply | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

martin rudalics
In reply to this post by Juri Linkov
 > This command is useful even if it doesn't fail on (...] because
 > forward-sexp and backward-sexp don't fail on (...].

Is this carved in stone?  The TODO file has

** (Controlled by a flag) make open and close syntax match exactly,
   i.e. `(' doesn't match `]'.

I always wondered what that entry aimed at ...

 > It seems you and Martin prefer checking against the `insert-pair-alist'
 > because the function name `delete-pair' suggests it should be
 > a counterpart of `insert-pair'.  In this case I think we sould have
 > two commands: one more strict version `delete-pair' that checks
 > `insert-pair-alist', and another loose version with the name e.g.
 > `delete-parens' with the body of the current `delete-pair'.

In any case, removing the first and last character from a name doesn't
strike me as very "pair-like" ;-)

martin



Reply | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

martin rudalics
In reply to this post by Juri Linkov
 > This is fixed in the following version:
 >
 > (defun delete-pair ()
 >   "Delete a pair of characters enclosing the sexp that follows point."
 >   (interactive)
 >   (save-excursion
 >     (forward-sexp 1)
 >     (save-excursion
 >       (backward-sexp 1)
 >       (skip-syntax-forward "'")
 >       (delete-char 1))
 >     (delete-char -1)))

Still doesn't seem TDTRT with `point' before something like

        `foo'

martin



Reply | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

Juri Linkov
>> This is fixed in the following version:
>>
>> (defun delete-pair ()
>>   "Delete a pair of characters enclosing the sexp that follows point."
>>   (interactive)
>>   (save-excursion
>>     (forward-sexp 1)
>>     (save-excursion
>>       (backward-sexp 1)
>>       (skip-syntax-forward "'")
>>       (delete-char 1))
>>     (delete-char -1)))
>
> Still doesn't seem TDTRT with `point' before something like
>
>        `foo'

I know, I know, after I fix this, you'll come up with another
test case like

         `foo bar'

;-)

--
Juri Linkov
http://www.jurta.org/emacs/



Reply | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

Juri Linkov
In reply to this post by Eli Barzilay
>> It seems you and Martin prefer checking against the
>> `insert-pair-alist' because the function name `delete-pair' suggests
>> it should be a counterpart of `insert-pair'.
>
> ...this is exactly the issue: it is much better if `delete-foo' is
> always an operation that reverts what `insert-foo' does.

The exact reverse is impossible.  For instance, put the cursor
on the letter `f' in:

    foo "" bar

and type `M-3 M-"' where M-" is bound to `insert-pair'.
The result will be:

    "foo "" bar"

Now what `delete-pair' should do to revert this back to the original?

> The current state of `delete-pair' is so bad that my guess is that
> hardly anyone used it, so adding another command doesn't make much
> sense.  How about making it do the proper thing (removing only
> balanced pairs as specified by `insert-pair-alist'), and ignoring
> errors with a prefix argument?

I've been using `delete-pair' for many years several times a day
without any problem because my lists are always correctly balanced
thanks to `insert-pair' that I exclusively use to create balanced
lists and strings.

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.

>> This is fixed in the following version:
>> [...]
>
> 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.

--
Juri Linkov
http://www.jurta.org/emacs/



Reply | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

Eli Barzilay
On Aug 16, Juri Linkov wrote:
> >> It seems you and Martin prefer checking against the
> >> `insert-pair-alist' because the function name `delete-pair'
> >> suggests it should be a counterpart of `insert-pair'.
> >
> > ...this is exactly the issue: it is much better if `delete-foo' is
> > always an operation that reverts what `insert-foo' does.
>
> The exact reverse is impossible.

Of course it isn't, but the operation is one that negates in what it
"generally does" the thing that `insert-foo' does.  Just like
`scroll-down' and `scroll-up' are opposites even though they don't
always cancel out.


> > The current state of `delete-pair' is so bad that my guess is that
> > hardly anyone used it, so adding another command doesn't make much
> > sense.  How about making it do the proper thing (removing only
> > balanced pairs as specified by `insert-pair-alist'), and ignoring
> > errors with a prefix argument?
>
> I've been using `delete-pair' for many years several times a day
> without any problem because my lists are always correctly balanced
> thanks to `insert-pair' that I exclusively use to create balanced
> lists and strings.

Believe me, I've written a paren or two, and I use `insert-pair'
enough to have my own improved version of it.  (In fact, guess why I
almost never use smileys in emails.)  Still, the first time I tried
this, the cursor was at the beginning of an indented line.  But the
point is still the same: having two nearly identical functions is
exactly what prefix arguments are for.


> 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.


> >> This is fixed in the following version:
> >> [...]
> >
> > 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.


On Aug 16, Juri Linkov wrote:

> >> This is fixed in the following version:
> >>
> >> (defun delete-pair ()
> >>   "Delete a pair of characters enclosing the sexp that follows point."
> >>   (interactive)
> >>   (save-excursion
> >>     (forward-sexp 1)
> >>     (save-excursion
> >>       (backward-sexp 1)
> >>       (skip-syntax-forward "'")
> >>       (delete-char 1))
> >>     (delete-char -1)))
> >
> > Still doesn't seem TDTRT with `point' before something like
> >
> >        `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.

--
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!



Reply | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

martin rudalics
In reply to this post by Juri Linkov
 > I know, I know, after I fix this, you'll come up with another
 > test case like
 >
 >          `foo bar'

I wouldn't.  Doing a `forward-sexp' on `foo' wouldn't get me to the end
of `bar'.  So you could all too easily reject such a test case ;-)

If, however, `delete-pair' were called with a prefix argument of 2 ...

martin



Reply | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

martin rudalics
In reply to this post by Juri Linkov
 > The exact reverse is impossible.  For instance, put the cursor
 > on the letter `f' in:
 >
 >     foo "" bar
 >
 > and type `M-3 M-"' where M-" is bound to `insert-pair'.
 > The result will be:
 >
 >     "foo "" bar"

Obviously `insert-pair' would have to escape the old quotes here ;-)

martin, who couldn't resist



Reply | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

Juri Linkov
In reply to this post by Eli Barzilay
> Believe me, I've written a paren or two, and I use `insert-pair'
> enough to have my own improved version of it.  (In fact, guess why I
> almost never use smileys in emails.)

You can write smileys using the closing parenthesis (but we should
improve `delete-pair' to delete smileys completely after deleting the
closing parenthesis ;-)

> 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.  `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?

>> 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?

>> > 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.

>> 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.

--
Juri Linkov
http://www.jurta.org/emacs/



Reply | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

Eli Barzilay
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 | Threaded
Open this post in threaded view
|

bug#4136: 23.1; delete-pair

Juri Linkov
>> `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.

We are in violent agreement.  I didn't claim that `delete-pair'
shouldn't check `insert-pair-alist'.  On the contrary, I think
`delete-pair' should verify if the character pair starting at the
current point is part of a pair according to `insert-pair-alist'.
"At the current point" - that's my point.  It shouldn't try
finding the opening character somewhere else.  So in your original
test case it should throw an error when the cursor is on some
whitespace that precedes an expression.

>> 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.

I agree.  So I'd like to close this issue with the following patch:

Index: lisp/emacs-lisp/lisp.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/emacs-lisp/lisp.el,v
retrieving revision 1.102
diff -u -r1.102 lisp.el
--- lisp/emacs-lisp/lisp.el 22 Jul 2009 02:45:37 -0000 1.102
+++ lisp/emacs-lisp/lisp.el 17 Aug 2009 21:16:32 -0000
@@ -530,7 +530,15 @@
 (defun delete-pair ()
   "Delete a pair of characters enclosing the sexp that follows point."
   (interactive)
-  (save-excursion (forward-sexp 1) (delete-char -1))
+  (let ((open-char (char-after)))
+    (save-excursion
+      (forward-sexp 1)
+      (unless (member (list open-char (char-before))
+      (mapcar (lambda (p)
+ (if (= (length p) 3) (cdr p) p))
+      insert-pair-alist))
+ (error "Not a matching pair"))
+      (delete-char -1)))
   (delete-char 1))
 
 (defun raise-sexp (&optional arg)

--
Juri Linkov
http://www.jurta.org/emacs/



12