GNU bug report logs - #77823
31.0.50; M-j regression since commit 4c6b1712a4d

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77823 in the body.
You can then email your comments to 77823 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Tue, 15 Apr 2025 19:27:44 +0800

X-debbugs-cc: eg642616 <at> gmail.com, eliz <at> gnu.org

1. emacs -q
2. C-x b foo RET
3. M-x emacs-lisp-mode RET
4. ;;;; hello M-j

Result is:

--8<---------------cut here---------------start------------->8---
;;;; hello|#
#|
--8<---------------cut here---------------end--------------->8---

but it should be

--8<---------------cut here---------------start------------->8---
;;;; hello
;;;;
--8<---------------cut here---------------end--------------->8---

My first thought is that since multiline comments of this style are not
valid Emacs Lisp, we should just set block-comment-start and
block-comment-end to nil for emacs-lisp-mode.

However, the recipe provided above works if you do 'M-x lisp-mode RET'
instead.

Even though Common Lisp supports these block comments, if you are
already writing a semicolon-delimited comment, then M-j should continue
it, rather than starting a #| |# comment.

-- 
Sean Whitton

Message #10 received at 77823-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: eg642616 <at> gmail.com, 77823-done <at> debbugs.gnu.org
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Tue, 15 Apr 2025 16:15:11 +0300

> Cc: eg642616 <at> gmail.com, eliz <at> gnu.org
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Tue, 15 Apr 2025 19:27:44 +0800
> 
> 1. emacs -q
> 2. C-x b foo RET
> 3. M-x emacs-lisp-mode RET
> 4. ;;;; hello M-j
> 
> Result is:
> 
> --8<---------------cut here---------------start------------->8---
> ;;;; hello|#
> #|
> --8<---------------cut here---------------end--------------->8---
> 
> but it should be
> 
> --8<---------------cut here---------------start------------->8---
> ;;;; hello
> ;;;;
> --8<---------------cut here---------------end--------------->8---

This has been fixed by a followup changeset that Elijah sent.

So I'm closing this bug.

Message #13 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: 77823 <at> debbugs.gnu.org, eliz <at> gnu.org, eg642616 <at> gmail.com
Cc: control <at> debbugs.gnu.org
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Wed, 16 Apr 2025 08:33:30 +0800

reopen 77823
thanks

Hello,

On Tue 15 Apr 2025 at 04:15pm +03, Eli Zaretskii wrote:

> This has been fixed by a followup changeset that Elijah sent.
>
> So I'm closing this bug.

It's still present, just replace 'M-x emacs-lisp-mode' with
'M-x lisp-mode' in my recipe.  M-j for editing Common Lisp is broken.

Possibly Elijah's original commit has just uncovered an existing
problem, but either way it's a bug.

Elijah, can you take a look at the lisp-mode issue, please?

-- 
Sean Whitton

Message #18 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: eliz <at> gnu.org, 77823 <at> debbugs.gnu.org, control <at> debbugs.gnu.org
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Tue, 15 Apr 2025 18:55:50 -0600

[Message part 1 (text/plain, inline)]

Sean Whitton <spwhitton <at> spwhitton.name> writes:

> reopen 77823
> thanks
>
> Hello,
>
> On Tue 15 Apr 2025 at 04:15pm +03, Eli Zaretskii wrote:
>
>> This has been fixed by a followup changeset that Elijah sent.
>>
>> So I'm closing this bug.
>
> It's still present, just replace 'M-x emacs-lisp-mode' with
> 'M-x lisp-mode' in my recipe.  M-j for editing Common Lisp is broken.
>
> Possibly Elijah's original commit has just uncovered an existing
> problem, but either way it's a bug.
>
> Elijah, can you take a look at the lisp-mode issue, please?

I found the issue, `comment-indent' was using both block-comment
variables first than `comment-start' and `comment-end', this must fix it.

[fixpatch.patch (text/x-patch, inline)]

diff --git a/lisp/newcomment.el b/lisp/newcomment.el
index eb36f91104d..3e20da816b9 100644
--- a/lisp/newcomment.el
+++ b/lisp/newcomment.el
@@ -722,9 +722,9 @@ comment-indent
   (let* ((empty (save-excursion (beginning-of-line)
 				(looking-at "[ \t]*$")))
 	 (starter (or (and continue comment-continue)
-		      (and empty block-comment-start) comment-start))
+		      comment-start (and empty block-comment-start)))
 	 (ender (or (and continue comment-continue "")
-		    (and empty block-comment-end) comment-end)))
+		    comment-end (and empty block-comment-end))))
     (unless starter (error "No comment syntax defined"))
     (beginning-of-line)
     (let* ((eolpos (line-end-position))

[Message part 3 (text/plain, inline)]

-- 
                                          - E.G via GNU Emacs and Org.

Message #21 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: eliz <at> gnu.org, 77823 <at> debbugs.gnu.org,
 Elijah Gabe Pérez <eg642616 <at> gmail.com>
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Wed, 16 Apr 2025 09:49:42 +0800

Hello,

On Tue 15 Apr 2025 at 06:55pm -06, Elijah Gabe Pérez wrote:

> I found the issue, `comment-indent' was using both block-comment
> variables first than `comment-start' and `comment-end', this must fix it.
>
> diff --git a/lisp/newcomment.el b/lisp/newcomment.el
> index eb36f91104d..3e20da816b9 100644
> --- a/lisp/newcomment.el
> +++ b/lisp/newcomment.el
> @@ -722,9 +722,9 @@ comment-indent
>    (let* ((empty (save-excursion (beginning-of-line)
>  				(looking-at "[ \t]*$")))
>  	 (starter (or (and continue comment-continue)
> -		      (and empty block-comment-start) comment-start))
> +		      comment-start (and empty block-comment-start)))
>  	 (ender (or (and continue comment-continue "")
> -		    (and empty block-comment-end) comment-end)))
> +		    comment-end (and empty block-comment-end))))
>      (unless starter (error "No comment syntax defined"))
>      (beginning-of-line)
>      (let* ((eolpos (line-end-position))

Thanks!  I don't know the comment code well; Stefan, would you mind
giving this a quick look?

-- 
Sean Whitton

Message #24 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: eliz <at> gnu.org, 77823 <at> debbugs.gnu.org,
 Elijah Gabe Pérez
 <eg642616 <at> gmail.com>
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Wed, 16 Apr 2025 20:35:41 -0400

>> I found the issue, `comment-indent' was using both block-comment
>> variables first than `comment-start' and `comment-end', this must fix it.
>>
>> diff --git a/lisp/newcomment.el b/lisp/newcomment.el
>> index eb36f91104d..3e20da816b9 100644
>> --- a/lisp/newcomment.el
>> +++ b/lisp/newcomment.el
>> @@ -722,9 +722,9 @@ comment-indent
>>    (let* ((empty (save-excursion (beginning-of-line)
>>  				(looking-at "[ \t]*$")))
>>  	 (starter (or (and continue comment-continue)
>> -		      (and empty block-comment-start) comment-start))
>> +		      comment-start (and empty block-comment-start)))
>>  	 (ender (or (and continue comment-continue "")
>> -		    (and empty block-comment-end) comment-end)))
>> +		    comment-end (and empty block-comment-end))))
>>      (unless starter (error "No comment syntax defined"))
>>      (beginning-of-line)
>>      (let* ((eolpos (line-end-position))
>
> Thanks!  I don't know the comment code well; Stefan, would you mind
> giving this a quick look?

My understanding is that the `newcomment.el` code (and its predecessor
which lived in `simple.el`) never really knew what
`block-comment-start/end` were for so it's used inconsistently and I'd
be surprised if there aren't more misbehaviors linked to them,

Of course, maybe the `simple.el` code did know and it's the guy who
rewrote it into `newcomment.el` who messed it all up.  🙂

In any case, the above is equivalent to just removing the `(and empty
block-comment-start/end)` because `comment-start/end` should never be
nil anyway, so it's probably worthwhile thinking about what we want to
do with `block-comment-start/end` here.
Maybe "nothing" is the right answer, of course.


        Stefan "really not a fan of `block-comment-start/end`"

Message #27 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77823 <at> debbugs.gnu.org,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Wed, 16 Apr 2025 22:28:15 -0600

[Message part 1 (text/plain, inline)]

Stefan Monnier writes:

> In any case, the above is equivalent to just removing the `(and empty
> block-comment-start/end)` because `comment-start/end` should never be
> nil anyway, so it's probably worthwhile thinking about what we want to
> do with `block-comment-start/end` here.
> Maybe "nothing" is the right answer, of course.


block-comment-start/end have been unused for almost 20 years,
comment-start/end had already replaced them ofc.  So, I think block-comment
variables should no longer be used to indent comments (as it seems that it
was planned), instead use them for other purposes, give them a "new life".

[Message part 2 (text/html, inline)]

Message #30 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: eliz <at> gnu.org, 77823 <at> debbugs.gnu.org
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Fri, 18 Apr 2025 15:07:43 +0800

Hello,

Thanks for commenting, Stefan.  Indeed, this change as it is can't be
right, because comment-start and comment-end will always be defined.

The intent of the code seems to be that block comment is used if the
user types M-; on an empty line, such that comment-indent wants to
insert a new comment.

But that's definitely wrong for Common Lisp.  As #| |# comments are
rarely used at all, M-; on an empty line with no active region ought to
behave just like it does in Emacs Lisp mode.

In other modes, block comments might be the most common form of comment,
however.  So I think we need a new mode-specific variable which says
which to prefer in the case where the context does not determine it?

-- 
Sean Whitton

Message #33 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Elijah Gabe Pérez <eg642616 <at> gmail.com>,
 77823 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Fri, 18 Apr 2025 09:10:37 -0400

> In other modes, block comments might be the most common form of comment,
> however.

AFAIK "the most common form of comment" is what `comment-start/end`
is for.


        Stefan "who still doesn't know what block-comment-start/end is for"

Message #36 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Elijah Gabe Pérez
 <eg642616 <at> gmail.com>,  77823 <at> debbugs.gnu.org,  eliz <at> gnu.org
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Sat, 19 Apr 2025 08:26:23 +0800

Hello,

On Fri 18 Apr 2025 at 09:10am -04, Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

>> In other modes, block comments might be the most common form of comment,
>> however.
>
> AFAIK "the most common form of comment" is what `comment-start/end`
> is for.
>
>
>         Stefan "who still doesn't know what block-comment-start/end is for"

I'm not sure either.  Maybe we should back out Elijah's change and
implement the actual user functionality he wants (the new minor mode) in
some other way?

-- 
Sean Whitton

Message #39 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: eliz <at> gnu.org, 77823 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Fri, 18 Apr 2025 21:46:34 -0600

[Message part 1 (text/plain, inline)]

Sean Whitton <spwhitton <at> spwhitton.name> writes:

>>> In other modes, block comments might be the most common form of comment,
>>> however.
>>
>> AFAIK "the most common form of comment" is what `comment-start/end`
>> is for.
>>
>>
>>         Stefan "who still doesn't know what block-comment-start/end is for"
>
> I'm not sure either.  Maybe we should back out Elijah's change and
> implement the actual user functionality he wants (the new minor mode) in
> some other way?

In that case, I've written a patch for that:

[0001-Revert-block-comments-settings-and-use-a-different-v.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

-- 
                                          - E.G via GNU Emacs and Org.

Message #42 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: eliz <at> gnu.org, 77823 <at> debbugs.gnu.org,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Sat, 19 Apr 2025 00:41:01 -0400

>  lisp/electric.el                     | 24 ++++++++++++++----------
>  lisp/emacs-lisp/lisp-mode.el         |  3 +--
>  lisp/newcomment.el                   |  9 ++++-----
>  lisp/nxml/nxml-mode.el               |  3 +--
>  lisp/progmodes/c-ts-common.el        |  6 ++----
>  lisp/progmodes/go-ts-mode.el         |  3 +--
>  lisp/progmodes/js.el                 |  3 +--
>  lisp/progmodes/json-ts-mode.el       |  3 +--
>  lisp/progmodes/lua-ts-mode.el        |  3 +--
>  lisp/progmodes/opascal.el            |  3 +--
>  lisp/progmodes/pascal.el             |  3 +--
>  lisp/progmodes/typescript-ts-mode.el |  3 +--
>  lisp/textmodes/css-mode.el           |  5 +----
>  lisp/textmodes/sgml-mode.el          |  3 +--
>  14 files changed, 31 insertions(+), 43 deletions(-)

IIRC, the recent changes also added setting to
`block-comment-start/end` in CC-modes, so there may need to be more reversals.

>  (define-minor-mode electric-block-comment-mode
>    "Toggle automatic closing of block comments (Electric Block Comment mode).
>  
> +When enabled, typing the beginning of a block comment closes it inserting their
> +corresponding block comment end."

So, IIUC what is meant by "block comment" here is a comment that's not
closed by the next EOL but by some other sequence of characters.

Interesting cases to consider:

- In SNMP mode, IIRC, comments take the shape of

       -- a comment --

  so you have to check `syntax-ppss` to figure out if the `--` that was
  just inserted was a comment starter or ender.

- In OPascal mode there is more than one kind of "block
  comment":

        { a comment }
        (* another comment *)
        /* yet another comment */

  so your `electric-block-comments` should probably support not just
  a single pair but a list of pairs.

- It might make sense to extend this to related constructs and/or to
  merge it into `electric-pair-mode`.
  By related constructs, I'm thinking of things like [OCaml's
  quotations](https://caml.inria.fr/pub/docs/tutorial-camlp4/tutorial004.html)
  that take the form `<:FOO<...>>` or [OCaml's quoted
  strings](https://ocaml.org/manual/5.2/lex.html#quoted-string-id)
  that look like `{FOO|...|FOO}`.


        Stefan

Message #45 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: eliz <at> gnu.org, 77823 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Sat, 19 Apr 2025 18:02:29 +0800

Hello Elijah,

Thank you very much for working on a revised approach.

Would it be possible for you to separate this two diffs?  One patch
reverting the previously installed changes, and a patch with the new
approach.

We don't have to actually install them as two separate git commits, but
given that Stefan and I didn't review the original change, it would
probably make things much more approachable for us to see these
separated.

-- 
Sean Whitton

Message #48 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: eliz <at> gnu.org, 77823 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Sat, 19 Apr 2025 23:11:38 -0600

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:

>>  lisp/electric.el                     | 24 ++++++++++++++----------
>>  lisp/emacs-lisp/lisp-mode.el         |  3 +--
>>  lisp/newcomment.el                   |  9 ++++-----
>>  lisp/nxml/nxml-mode.el               |  3 +--
>>  lisp/progmodes/c-ts-common.el        |  6 ++----
>>  lisp/progmodes/go-ts-mode.el         |  3 +--
>>  lisp/progmodes/js.el                 |  3 +--
>>  lisp/progmodes/json-ts-mode.el       |  3 +--
>>  lisp/progmodes/lua-ts-mode.el        |  3 +--
>>  lisp/progmodes/opascal.el            |  3 +--
>>  lisp/progmodes/pascal.el             |  3 +--
>>  lisp/progmodes/typescript-ts-mode.el |  3 +--
>>  lisp/textmodes/css-mode.el           |  5 +----
>>  lisp/textmodes/sgml-mode.el          |  3 +--
>>  14 files changed, 31 insertions(+), 43 deletions(-)
>
> IIRC, the recent changes also added setting to
> `block-comment-start/end` in CC-modes, so there may need to be more reversals.

Oops, i forgot it.

>>  (define-minor-mode electric-block-comment-mode
>>    "Toggle automatic closing of block comments (Electric Block Comment mode).
>>  
>> +When enabled, typing the beginning of a block comment closes it inserting their
>> +corresponding block comment end."
>
> So, IIUC what is meant by "block comment" here is a comment that's not
> closed by the next EOL but by some other sequence of characters.
>
> Interesting cases to consider:
>
> - In SNMP mode, IIRC, comments take the shape of
>
>        -- a comment --
>
>   so you have to check `syntax-ppss` to figure out if the `--` that was
>   just inserted was a comment starter or ender.

I didn't know that were possible.

> - In OPascal mode there is more than one kind of "block
>   comment":
>
>         { a comment }
>         (* another comment *)
>         /* yet another comment */
>
>   so your `electric-block-comments` should probably support not just
>   a single pair but a list of pairs.

Yeah, i realized when i made the changes.

> - It might make sense to extend this to related constructs and/or to
>   merge it into `electric-pair-mode`.

I originally planned to merge it with electric-pair, but electric-pair
is something complex for this little feature (and also electric-pair
uses characters, not strings), so I decided to make it standalone.

>   By related constructs, I'm thinking of things like [OCaml's
>   quotations](https://caml.inria.fr/pub/docs/tutorial-camlp4/tutorial004.html)
>   that take the form `<:FOO<...>>` or [OCaml's quoted
>   strings](https://ocaml.org/manual/5.2/lex.html#quoted-string-id)
>   that look like `{FOO|...|FOO}`.

It looks outside the purpose of this minor mode, but I have nothing
against implementing it, it can handle it.  Honestly, if that were the
case, I don't know what name to give this mode.

-- 
                                          - E.G via GNU Emacs and Org.

Message #54 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: eliz <at> gnu.org, 77823 <at> debbugs.gnu.org,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Sun, 20 Apr 2025 09:22:47 -0400

>> - It might make sense to extend this to related constructs and/or to
>>   merge it into `electric-pair-mode`.
>
> I originally planned to merge it with electric-pair, but electric-pair
> is something complex for this little feature (and also electric-pair
> uses characters, not strings), so I decided to make it standalone.

I understand it's a non-trivial change, but extending support for
multi-character delimiters would be nice.  This could cover things like
``...'' in LaTeX.

>>   By related constructs, I'm thinking of things like [OCaml's
>>   quotations](https://caml.inria.fr/pub/docs/tutorial-camlp4/tutorial004.html)
>>   that take the form `<:FOO<...>>` or [OCaml's quoted
>>   strings](https://ocaml.org/manual/5.2/lex.html#quoted-string-id)
>>   that look like `{FOO|...|FOO}`.
>
> It looks outside the purpose of this minor mode, but I have nothing
> against implementing it, it can handle it.  Honestly, if that were the
> case, I don't know what name to give this mode.

`electric-multichar-pair-mode`?  🙂


        Stefan

Message #57 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Sean Whitton
 <spwhitton <at> spwhitton.name>
Cc: eliz <at> gnu.org, 77823 <at> debbugs.gnu.org
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Sun, 20 Apr 2025 14:40:05 -0600

[Message part 1 (text/plain, inline)]

Fine, I'm sending here 2 patches:

For revert the previous commits:

[0001-Revert-commits-74842b4cb2c-and-4c6b1712a4d.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

And the new feature implementation:

[0001-Change-electric-block-comment-mode-to-electric-multi.patch (text/x-patch, attachment)]

[Message part 5 (text/plain, inline)]

-- 
                                          - E.G via GNU Emacs and Org.

Message #60 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: eliz <at> gnu.org, 77823 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Tue, 22 Apr 2025 20:19:38 +0800

Hello,

Okay, thanks, I understand better now what you're trying to accomplish.

This isn't fundamentally about comments at all.  For example, these
multichar pairs could include the opening "case" and closing "esac" in a
shell script, right?

If that's right, then I'm not sure a new electric minor mode is the
right thing.  We already have abbrevs and skeletons which work for this
sort of thing.  Indeed, this is exactly how sh-case is already
implemented.

-- 
Sean Whitton

Message #63 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Elijah Gabe Pérez <eg642616 <at> gmail.com>,
 77823 <at> debbugs.gnu.org, eliz <at> gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Tue, 22 Apr 2025 19:20:12 +0300

> This isn't fundamentally about comments at all.  For example, these
> multichar pairs could include the opening "case" and closing "esac" in a
> shell script, right?

Maybe 'electric-pair-mode' should support string delimiters
in addition to characters, e.g.

  (setopt electric-pair-pairs `(("case" . "esac")))

Message #66 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77823 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Tue, 22 Apr 2025 13:36:09 -0600

[Message part 1 (text/plain, inline)]

Sean Whitton writes:

> Hello,
>
> Okay, thanks, I understand better now what you're trying to accomplish.
>
> This isn't fundamentally about comments at all.  For example, these
> multichar pairs could include the opening "case" and closing "esac" in a
> shell script, right?
>

Honestly, I always had in mind that it would be for comments.

So if your type /*, it will automatically insert
/*  */
  ^ cursor in middle both spaces

(including spaces an maybe newlines)

It was similar to what I saw in the cc modes and smartparens-mode

If that's right, then I'm not sure a new electric minor mode is the
> right thing.  We already have abbrevs and skeletons which work for this
> sort of thing.  Indeed, this is exactly how sh-case is already
> implemented.


But those do not expand immediately AFAIK; like if you type "{"

[Message part 2 (text/html, inline)]

Message #69 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77823 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Tue, 22 Apr 2025 13:52:31 -0600

[Message part 1 (text/plain, inline)]

Juri Linkov <juri <at> linkov.net> escribió:

> > This isn't fundamentally about comments at all.  For example, these
> > multichar pairs could include the opening "case" and closing "esac" in a
> > shell script, right?
>
> Maybe 'electric-pair-mode' should support string delimiters
> in addition to characters, e.g.
>
>   (setopt electric-pair-pairs `(("case" . "esac")))
>

Right, but using case for this would be a downside from my POV, if you
write `case' in a comment for documentation it will auto insert `esac',
another idea is define a variable in electric-pairs for this kind of pairs
which specifies if a pair can be expanded in comments/strings.

>

[Message part 2 (text/html, inline)]

Message #72 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Sean Whitton <spwhitton <at> spwhitton.name>,
 77823 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Tue, 22 Apr 2025 17:25:26 -0400

>>   (setopt electric-pair-pairs `(("case" . "esac")))
>
> Right, but using case for this would be a downside from my POV, if you
> write `case' in a comment for documentation it will auto insert `esac',
> another idea is define a variable in electric-pairs for this kind of pairs
> which specifies if a pair can be expanded in comments/strings.

That's why there is both `electric-pair-pairs' and `electric-pair-text-pairs'.

Another issue if we want to expand the scope of electric-pair is that
when the users type `case` maybe they're just yping `case` but cases
they're actually on their way to typing `cases` or `cased` or `case_nb`
or god knows what else: for those matched thingies that can be prefixes of
arbitrary identifiers, we'd probably want to wait for the user to hit
SPC (like abbrev does) before inserting the closing element.


        Stefan

Message #75 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77823 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Wed, 23 Apr 2025 10:10:45 +0800

Hello,

On Tue 22 Apr 2025 at 01:36pm -06, Elijah Gabe Pérez wrote:

> But those do not expand immediately AFAIK; like if you type "{"

I think that's specifically how abbrev and abbrev-based skeletons don't
trigger if you only type characters that aren't word constituents.
Good point -- that probably renders them unsuitable for this.

ISTM that a combination of the suggestions from Juri and Stefan would
work well.  It would be great if you could expand the functionality of
electric-pair-mode to handle these cases.

-- 
Sean Whitton

Message #78 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77823 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Tue, 22 Apr 2025 21:47:55 -0600

[Message part 1 (text/plain, inline)]

Sean Whitton writes:

> ISTM that a combination of the suggestions from Juri and Stefan would
> work well.  It would be great if you could expand the functionality of
> electric-pair-mode to handle these cases.
>

Yeah, at least support strings and specify if a paren should be expanded
after a space (for do not conflict with others parens)(?), I will work on
that, at this point it would be to make it similar to smartparens.

Ofc, some built-in major modes should set which parens to use.

>

[Message part 2 (text/html, inline)]

Message #83 received at 77823-done <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77823-done <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Wed, 23 Apr 2025 11:56:20 +0800

Hello,

On Tue 22 Apr 2025 at 09:47pm -06, Elijah Gabe Pérez wrote:

> Sean Whitton writes:
>
>  ISTM that a combination of the suggestions from Juri and Stefan would
>  work well.  It would be great if you could expand the functionality of
>  electric-pair-mode to handle these cases.
>
> Yeah, at least support strings and specify if a paren should be expanded after a space (for do not
> conflict with others parens)(?), I will work on that, at this point it would be to make it similar to
> smartparens.

I'm not really familiar with smartparens but those seem like relevant
considerations.

> Ofc, some built-in major modes should set which parens to use.

Right.

I'll close this bug since the regression is fixed.  You could post your
new patch to a new bug, perhaps.

-- 
Sean Whitton

Message #86 received at 77823 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Sean Whitton <spwhitton <at> spwhitton.name>,
 77823 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#77823: 31.0.50; M-j regression since commit 4c6b1712a4d
Date: Tue, 22 Apr 2025 21:58:43 -0600

[Message part 1 (text/plain, inline)]

Stefan Monnier writes:

> Another issue if we want to expand the scope of electric-pair is that
> when the users type `case` maybe they're just yping `case` but cases
> they're actually on their way to typing `cases` or `cased` or `case_nb`
> or god knows what else: for those matched thingies that can be prefixes of
> arbitrary identifiers, we'd probably want to wait for the user to hit
> SPC (like abbrev does) before inserting the closing element.


Fine, but i think that some parens from alist should specify if must expand
after inserting an space, something like:

'(("/*" . "*/") ("case" "esac" t)...
                             ^ any non-nil value

[Message part 2 (text/html, inline)]

Previous Next

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