Subject: bug#78021: closed (Re: bug#78021: 30.1; Unclear sentence in (emacs)Matching)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 10 May 2025 14:35:02 +0000

Your bug report

#78021: 30.1; Unclear sentence in (emacs)Matching

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
78021: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78021
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#78021: 30.1; Unclear sentence in (emacs)Matching
From: Stephen Berman <[email-masked]>
To: Eli Zaretskii <[email-masked]>
Cc: [email-masked]
Date: Sat, 10 May 2025 16:33:59 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

On Sat, 10 May 2025 15:49:38 +0300 Eli Zaretskii <[email-masked]> wrote:

>> From: Stephen Berman <[email-masked]>
>> Cc: [email-masked]
>> Date: Sat, 10 May 2025 14:44:48 +0200
>> 
>> On Sat, 10 May 2025 13:58:44 +0300 Eli Zaretskii <[email-masked]> wrote:
>> 
>> > Thanks, LGTM, but please make sure the first line of a doc string is
>> > always a single complete sentence.  I've seen it be only party of a
>> > sentence in two functions: electric-pair-post-self-insert-function and
>> > electric-pair-open-newline-between-pairs-psif.
>> 
>> I think they are complete sentences (checkdoc did not complain about
>> them), though a bit terse:
>
> Sorry, you are right, I've misread the diffs.

Ok, thanks.  I've now pushed the changes to emacs-30 as commit
bb735331650 and I'm (re)closing the bug.  When these changes have been
merged to master, they'll overwrite the sentence in the manual about
using a prefix argument, so I'll put it back then.

Steve Berman

Subject: 30.1; Unclear sentence in (emacs)Matching
From: Drew Adams <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 23 Apr 2025 22:42:49 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

In (emacs)Matching (not a great name for the node abbreviation, BTW),
this sentence is unclear:

  "Conversely, when you insert a closing delimiter over an existing one,
   No insertion takes places, and that position is simply skipped over."

What does it mean to insert a closing delimiter "over an existing one"?
No idea what this is trying to say, or why it's deemed the "converse" of
what happens when you insert an opening delimiter.

Presumably it should include something about what happens to the
"existing" closing delimiter, and something about point, if it hopes to
convey the converse behavior.

In GNU Emacs 30.1 (build 2, x86_64-w64-mingw32) of 2025-02-23 built on
 AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.26100
System Description: Microsoft Windows 10 Pro (v10.0.2009.26100.3775)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation=aot
 --without-compress-install --with-tree-sitter CFLAGS=-O2
 prefix=/g/rel/install/emacs-30.1'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

(NATIVE_COMP present but libgccjit not available)

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252