GNU bug report logs - #78021
30.1; Unclear sentence in (emacs)Matching

Previous Next

Full log

View this message in rfc822 format

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "eliz <at> gnu.org" <eliz <at> gnu.org>, "78021 <at> debbugs.gnu.org" <78021 <at> debbugs.gnu.org>
Subject: bug#78021: 30.1; Unclear sentence in (emacs)Matching
Date: Fri, 25 Apr 2025 18:30:28 +0200

On Fri, 25 Apr 2025 15:51:31 +0000 Drew Adams <drew.adams <at> oracle.com> wrote:

> I don't have Eli's fix, to compare, 

I included the diff of his fix in my post, so I wonder why you can't see
it there; I also see it in the mailing list archive:

https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-04/msg01589.html

But I will quote from his fix below for your convenience.

>                                     and I can't
> follow your diff wrt the text I see in Emacs 30,

This is because my diff was against the current emacs-30 branch, which
contains Eli's changes.  But again, you should be able to see his diff
at the above URL (and in my post).

> so I can't tell what, in your suggested text, you
> think actually responds to _this_ bug, which I
> filed.
>
> This bug is only about this existing text, which
> I can't fathom (and "places" should be "place"):
>
>   "Conversely, when you insert a closing delimiter
>    over an existing one, no insertion takes places,
>    and that position is simply skipped over."
>
> (And the node-name abbreviation shouldn't just be
> "Matching".  There are lots of kinds of matching
> in Emacs; please don't hijack that term for this.)
>
> If you fix this bug, then fine.  But please make
> your other changes independently of this bug fix.
> Or at least make very clear what part of your fix
> actually corresponds to fixing this bug.  Thx.

Here is Eli's clarification of the bit you found wanting:

   "However, if you insert a closing delimiter where one already exists
   (probably a mistake, since typing the opening delimiter inserted the
   closing one for you), Emacs simply moves point to after the closing
   delimiter, skipping the insertion."

And here is my reformulation, which includes a more complete description
of the behavior, which I think is needed to understand the
functionality:

   "However, if you type a closing delimiter at a buffer position
   between matching delimiters of the same type with only white space
   between the delimiters, then by default Emacs simply moves point to
   after the closing delimiter and does not insert another one."

But I also made numerous other changes in this documentation, for
reasons I listed in my emacs-devel post, which is included in the post
you replied to and should be readable at the URL I provided above.
Admittedly, my other changes widen the scope of your bug report, but I
took that to be legitimate, since it's still about clarifying the
documentation of Electric Pair mode.  If you disagree, then I apologize
for hijacking your bug report (though I don't see it that way), but at
this point I would rather not open a new bug report and repeat
everything there; I hope you can accept that.

Steve Berman

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.