GNU bug report logs - #54551
show-paren-mode inconsistency

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 54551 in the body.
You can then email your comments to 54551 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: goncholden <goncholden <at> protonmail.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: show-paren-mode inconsistency
Date: Thu, 24 Mar 2022 20:13:55 +0000

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

I am using show-paren-mode to highlight watching opening or closing parentheses.

Have seen that putting the cursor on the opening brace highlights the closing brace. But putting the cursor does not highlight the opening brace. One has to go to the character following the closing brace. Because elisp customarily has many consecutive closing braces, using the consecutive character to highlight the matching opening brace is counter productive.

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: goncholden <goncholden <at> protonmail.com>
Cc: 54551 <at> debbugs.gnu.org
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Thu, 24 Mar 2022 22:28:19 +0200

> Date: Thu, 24 Mar 2022 20:13:55 +0000
> From:  goncholden via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> I am using show-paren-mode to highlight watching opening or closing parentheses. 
> 
> Have seen that putting the cursor on the opening brace highlights the closing brace. But putting the cursor
> does not highlight the opening brace. One has to go to the character following the closing brace. Because
> elisp customarily has many consecutive closing braces, using the consecutive character to highlight the
> matching opening brace is counter productive.

This is so typing the closing brace shows the matching opening brace.
With your proposal, when I type the closing brace, the opening one
will not be highlighted.

So this is by design, and for a good reason.

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

From: Phil Sainty <psainty <at> orcon.net.nz>
To: goncholden <goncholden <at> protonmail.com>
Cc: 54551 <at> debbugs.gnu.org
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Fri, 25 Mar 2022 10:34:23 +1300

On 2022-03-25 09:13, goncholden wrote:
> I am using show-paren-mode to highlight watching opening or closing
> parentheses.
> 
> Have seen that putting the cursor on the opening brace highlights the
> closing brace. But putting the cursor does not highlight the opening
> brace. One has to go to the character following the closing brace.

It's consistent, but you're confused because you think that the cursor
indicates a character rather than a position *between* two characters.

If you customize `cursor-⁠type' to the Vertical Bar option you will
have a more literal view of the cursor, and see what `show-⁠paren-⁠mode'
is actually doing.


-⁠Phil

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

From: goncholden <goncholden <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54551 <at> debbugs.gnu.org
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Thu, 24 Mar 2022 22:48:35 +0000

------- Original Message -------

On Friday, March 25th, 2022 at 8:28 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Thu, 24 Mar 2022 20:13:55 +0000
> >
> > From: goncholden via "Bug reports for GNU Emacs,
> >
> > the Swiss army knife of text editors" bug-gnu-emacs <at> gnu.org
> >
> > I am using show-paren-mode to highlight watching opening or closing parentheses.
> >
> > Have seen that putting the cursor on the opening brace highlights the closing brace. But putting the cursor
> >
> > does not highlight the opening brace. One has to go to the character following the closing brace. Because
> >
> > elisp customarily has many consecutive closing braces, using the consecutive character to highlight the
> >
> > matching opening brace is counter productive.
>
> This is so typing the closing brace shows the matching opening brace.
>
> With your proposal, when I type the closing brace, the opening one
>
> will not be highlighted.
>
> So this is by design, and for a good reason.

Thank you for the explanation.

Consider the following command

(setq initial-frame-alist '((width . 72) (height . 26)) ).

Would be instructive that when one puts the cursor in the space between (width . 72) and (height . 26), the entire (width . 72) (height . 26) would be highlighted.

But (setq show-paren-when-point-inside-paren t) does not do that.
Can be very non-intuitive when debugging.  Also, if you put the cursor on the parenthesis following (height . 26), only (height . 26) gets highlighted, rather than the entire (height . 26) (height . 26).

Could some improvements be done about this?

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

From: Phil Sainty <psainty <at> orcon.net.nz>
To: goncholden <goncholden <at> protonmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 54551 <at> debbugs.gnu.org
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Fri, 25 Mar 2022 13:12:27 +1300

On 2022-03-25 11:48, goncholden wrote:
> Consider the following command
> 
> (setq initial-frame-alist '((width . 72) (height . 26)) ).
> 
> Would be instructive that when one puts the cursor in the space
> between (width . 72) and (height . 26), the entire (width . 72)
> (height . 26) would be highlighted.

That wouldn't make any sense for show-paren-mode.

The cursor (point) is either between the ")" and " " characters, or
else between the " " and "(" characters.  Those are the only two
possibilities, and in each case you would expect show-paren-mode to
highlight the adjacent expression (to the left or to the right of the
cursor, respectively).


> But (setq show-paren-when-point-inside-paren t) does not do that.

It's not documented as doing that, so there's not reason to expect
that it might.


I think you're looking for this library:

https://www.emacswiki.org/emacs/HighlightSexp

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

From: goncholden <goncholden <at> protonmail.com>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 54551 <at> debbugs.gnu.org
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Fri, 25 Mar 2022 04:20:39 +0000

------- Original Message -------

On Friday, March 25th, 2022 at 12:12 PM, Phil Sainty <psainty <at> orcon.net.nz> wrote:

> On 2022-03-25 11:48, goncholden wrote:

> > Consider the following command
> >   (setq initial-frame-alist '((width . 72) (height . 26)) ).
> > Would be instructive that when one puts the cursor in the space
> > between (width . 72) and (height . 26), the entire (width . 72)
> > (height . 26) would be highlighted.

> That wouldn't make any sense for show-paren-mode.

> The cursor (point) is either between the ")" and " " characters, or
> else between the " " and "(" characters. Those are the only two
> possibilities, and in each case you would expect show-paren-mode to
> highlight the adjacent expression (to the left or to the right of the
> cursor, respectively).

I use the block colouring of the cursor, meaning that your valid description
in not so intuitive.  Would it be possible to include a different interpretation
depending on the type of cursor display one is using?

> > But (setq show-paren-when-point-inside-paren t) does not do that.

> It's not documented as doing that, so there's not reason to expect
> that it might.
>
> I think you're looking for this library:
>   https://www.emacswiki.org/emacs/HighlightSexp

Will try it out and report back about it.

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

From: goncholden <goncholden <at> protonmail.com>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 54551 <at> debbugs.gnu.org
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Fri, 25 Mar 2022 04:29:01 +0000

------- Original Message -------

On Friday, March 25th, 2022 at 4:20 PM, goncholden <goncholden <at> protonmail.com> wrote:

> ------- Original Message -------
>
> On Friday, March 25th, 2022 at 12:12 PM, Phil Sainty psainty <at> orcon.net.nz wrote:
>
> > On 2022-03-25 11:48, goncholden wrote:
>
> > > Consider the following command
> > >   (setq initial-frame-alist '((width . 72) (height . 26)) ).
> > > Would be instructive that when one puts the cursor in the space
> > > between (width . 72) and (height . 26), the entire (width . 72)
> > > (height . 26) would be highlighted.

> > That wouldn't make any sense for show-paren-mode.

> > The cursor (point) is either between the ")" and " " characters, or
> > else between the " " and "(" characters. Those are the only two
> > possibilities, and in each case you would expect show-paren-mode to
> > highlight the adjacent expression (to the left or to the right of the
> > cursor, respectively).

> I use the block colouring of the cursor, meaning that your valid description
> in not so intuitive. Would it be possible to include a different interpretation
> depending on the type of cursor display one is using?

> > > But (setq show-paren-when-point-inside-paren t) does not do that.

> > It's not documented as doing that, so there's not reason to expect
> > that it might.

> > I think you're looking for this library:
> >   https://www.emacswiki.org/emacs/HighlightSexp

> Will try it out and report back about it.

Is HighlightSexp only relevant for use with lisp-mode-hook and emacs-lisp-mode-hook ?

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

From: Phil Sainty <psainty <at> orcon.net.nz>
To: goncholden <goncholden <at> protonmail.com>
Cc: 54551 <at> debbugs.gnu.org
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Fri, 25 Mar 2022 17:57:45 +1300

On 2022-03-25 17:20, goncholden wrote:
> I use the block colouring of the cursor, meaning that your
> valid description in not so intuitive.  Would it be possible
> to include a different interpretation depending on the type
> of cursor display one is using?

The position at point is the same no matter what the cursor
looks like, and the behaviour is based on where point is, so
for the current code the appearance of the cursor is irrelevant.

You *could* make the code test the cursor type and change its
behaviour in accordance with what it thought the cursor looked
like, but I'd really recommend just getting familiar with the
existing (and very consistent) behaviour, and remembering what
it is that the cursor actually represents.


> > I think you're looking for this library:
> > https://www.emacswiki.org/emacs/HighlightSexp
> 
> Is HighlightSexp only relevant for use with lisp-mode-hook
> and emacs-lisp-mode-hook ?

Anything lisp-based should certainly work, but it's more generic
than that.  Not every major mode would be relevant, but you can
experiment with different modes and see whether it works.


-Phil

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

From: goncholden <goncholden <at> protonmail.com>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 54551 <at> debbugs.gnu.org
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Fri, 25 Mar 2022 05:23:35 +0000

------- Original Message -------
On Friday, March 25th, 2022 at 4:57 PM, Phil Sainty <psainty <at> orcon.net.nz> wrote:
> On 2022-03-25 17:20, goncholden wrote:

> > I use the block colouring of the cursor, meaning that your
> > valid description in not so intuitive. Would it be possible
> > to include a different interpretation depending on the type
> > of cursor display one is using?

> The position at point is the same no matter what the cursor
> looks like, and the behaviour is based on where point is, so
> for the current code the appearance of the cursor is irrelevant.

> You could make the code test the cursor type and change its
> behaviour in accordance with what it thought the cursor looked
> like, but I'd really recommend just getting familiar with the
> existing (and very consistent) behaviour, and remembering what
> it is that the cursor actually represents.

> > > I think you're looking for this library:
> > > https://www.emacswiki.org/emacs/HighlightSexp

> > Is HighlightSexp only relevant for use with lisp-mode-hook
> > and emacs-lisp-mode-hook ?

> Anything lisp-based should certainly work, but it's more generic
> than that. Not every major mode would be relevant, but you can
> experiment with different modes and see whether it works.

> -Phil

Have tried to figure out the background colour used by show-paren-mode
after setting show-paren-when-point-inside-paren to t.  But have not
got to its determination.

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

From: Phil Sainty <psainty <at> orcon.net.nz>
To: goncholden <goncholden <at> protonmail.com>
Cc: 54551 <at> debbugs.gnu.org
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Fri, 25 Mar 2022 18:53:31 +1300

On 2022-03-25 18:23, goncholden wrote:
> Have tried to figure out the background colour used by show-paren-mode
> after setting show-paren-when-point-inside-paren to t.  But have not
> got to its determination.

M-x customize-group RET paren-showing-faces

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: goncholden <goncholden <at> protonmail.com>
Cc: 54551 <at> debbugs.gnu.org
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Fri, 25 Mar 2022 09:47:21 +0300

> Date: Thu, 24 Mar 2022 22:48:35 +0000
> From: goncholden <goncholden <at> protonmail.com>
> Cc: 54551 <at> debbugs.gnu.org
> 
> Consider the following command
> 
> (setq initial-frame-alist '((width . 72) (height . 26)) ).
> 
> Would be instructive that when one puts the cursor in the space between (width . 72) and (height . 26), the entire (width . 72) (height . 26) would be highlighted.

Why only "(width . 72) (height . 26)" and not the entire setq
expression?

Or maybe I don't understand what you mean by "instructive", i.e. what
exactly would you like Emacs to show you and why?

show-paren-mode has a specific goal: to show you the matching
parenthesis in an unobtrusive way, and do that as you type as well as
when you move through the code.  That is the "instructive" role that
it takes up upon itself.  It sounds like you want something else,
which would then call for a different feature with different visuals
(parenthesized expressions tend to nest, so being "inside" one of them
means you are "inside" all of the outer ones, and displaying them
calls for a different technique than what show-paren does).

> But (setq show-paren-when-point-inside-paren t) does not do that.
> Can be very non-intuitive when debugging.

For debugging, I suggest that you use C-M-u.

> Also, if you put the cursor on the parenthesis following (height . 26), only (height . 26) gets highlighted, rather than the entire (height . 26) (height . 26).

What do you mean by "the entire (height . 26)"?  Did you try to set
show-paren-style to 'expression', and if not, does it do what you
want?

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

From: goncholden <goncholden <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54551 <at> debbugs.gnu.org
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Fri, 25 Mar 2022 07:10:36 +0000

------- Original Message -------
On Friday, March 25th, 2022 at 6:47 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Date: Thu, 24 Mar 2022 22:48:35 +0000
> > From: goncholden goncholden <at> protonmail.com
> > Cc: 54551 <at> debbugs.gnu.org
> >
> > Consider the following command
> >
> > (setq initial-frame-alist '((width . 72) (height . 26)) ).
> >
> > Would be instructive that when one puts the cursor in the space between (width . 72) and (height . 26), the entire (width . 72) (height . 26) would be highlighted.
>
> Why only "(width . 72) (height . 26)" and not the entire setq expression?
>
> Or maybe I don't understand what you mean by "instructive", i.e. what
>
> exactly would you like Emacs to show you and why?
>
> show-paren-mode has a specific goal: to show you the matching
>
> parenthesis in an unobtrusive way, and do that as you type as well as
>
> when you move through the code. That is the "instructive" role that
>
> it takes up upon itself. It sounds like you want something else,
>
> which would then call for a different feature with different visuals
>
> (parenthesized expressions tend to nest, so being "inside" one of them
>
> means you are "inside" all of the outer ones, and displaying them
>
> calls for a different technique than what show-paren does).
>
> > But (setq show-paren-when-point-inside-paren t) does not do that.
> >
> > Can be very non-intuitive when debugging.
>
> For debugging, I suggest that you use C-M-u.
>
> > Also, if you put the cursor on the parenthesis following (height . 26), only (height . 26) gets highlighted, rather than the entire (height . 26) (height . 26).
>
> What do you mean by "the entire (height . 26)"? Did you try to set
> show-paren-style to 'expression', and if not, does it do what you
> want?

I had been trying "(customize-set-variable 'show-paren-when-point-inside-paren t)".
It has been suggested to me to try "highlight-sexp", which seems to work better than
the functionality provided by show-paren-when-point-inside-paren.

With "highlight-sexp", placing cursor after "(width . 72)" does highlight
"(width . 72) (height . 26)" for the expression
"(setq initial-frame-alist '((width . 72) (height . 26)) )"

"highlight-sexp" does highlight the innermost expression, not so with
"show-paren-when-point-inside-paren".

You are making sense, but I wondered if you could see possibilities for
improvements to "show-paren-mode".

I am debugging a problem where emacs states that there exists an extra
closing parenthesis, but having extreme difficulty locating it.

Have split the file in two and using "require" on a child file.  Otherwise
I have to comment each line of code rather than whole sections.  Commenting
each line is likely to introduce errors if one is not very careful removing
the comment tags.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: goncholden <goncholden <at> protonmail.com>
Cc: 54551 <at> debbugs.gnu.org
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Fri, 25 Mar 2022 10:21:22 +0300

> Date: Fri, 25 Mar 2022 07:10:36 +0000
> From: goncholden <goncholden <at> protonmail.com>
> Cc: 54551 <at> debbugs.gnu.org
> 
> I am debugging a problem where emacs states that there exists an extra
> closing parenthesis, but having extreme difficulty locating it.

For this, I propose one of the following methods, or their
combination:

  . use C-M-f to move forward by sexps in your init file
  . watch for show-paren to show the closing parenthesis in the
    "mismatched" color

> Have split the file in two and using "require" on a child file.  Otherwise
> I have to comment each line of code rather than whole sections.  Commenting
> each line is likely to introduce errors if one is not very careful removing
> the comment tags.

You could instead mark a region of the file, and then use
comment-region.

I don't think any of this, or the problem you are trying to solve, is
relevant to what show-paren does, though.

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

From: goncholden <goncholden <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54551 <at> debbugs.gnu.org
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Fri, 25 Mar 2022 08:35:09 +0000

Sent with ProtonMail secure email.
------- Original Message -------
On Friday, March 25th, 2022 at 7:21 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Fri, 25 Mar 2022 07:10:36 +0000
> >
> > From: goncholden goncholden <at> protonmail.com
> >
> > Cc: 54551 <at> debbugs.gnu.org
> >
> > I am debugging a problem where emacs states that there exists an extra
> >
> > closing parenthesis, but having extreme difficulty locating it.
>
> For this, I propose one of the following methods, or their
>
> combination:
>
> . use C-M-f to move forward by sexps in your init file
> . watch for show-paren to show the closing parenthesis in the
> "mismatched" color
>
> > Have split the file in two and using "require" on a child file. Otherwise
> > I have to comment each line of code rather than whole sections. Commenting
> > each line is likely to introduce errors if one is not very careful removing
> > the comment tags.

> You could instead mark a region of the file, and then use
> comment-region.

> I don't think any of this, or the problem you are trying to solve, is
> relevant to what show-paren does, though.

Not to what show-paren does, but about tools to isolate or focus on specific
sections of code.  Could there be a way to ignore sections of code without
requiring commenting?

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: goncholden <goncholden <at> protonmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 54551 <at> debbugs.gnu.org
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Fri, 25 Mar 2022 09:51:31 +0100

On Fri, 25 Mar 2022 07:10:36 +0000 goncholden via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> wrote:

> I am debugging a problem where emacs states that there exists an extra
> closing parenthesis, but having extreme difficulty locating it.
>
> Have split the file in two and using "require" on a child file.  Otherwise
> I have to comment each line of code rather than whole sections.  Commenting
> each line is likely to introduce errors if one is not very careful removing
> the comment tags.

Have you tried calling `check-parens' in the files?

Steve Berman

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

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 54551 <at> debbugs.gnu.org, goncholden <goncholden <at> protonmail.com>
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Fri, 25 Mar 2022 22:32:31 +1300

On 2022-03-25 21:51, Stephen Berman wrote:
> Have you tried calling `check-parens' in the files?

I think this is a continuation of 
https://emacs.stackexchange.com/q/71076
in which various things were tried to no avail.

I feel that "put the files online somewhere for other people to look at"
is the sensible next move.


-Phil

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: goncholden <goncholden <at> protonmail.com>
Cc: 54551 <at> debbugs.gnu.org
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Fri, 25 Mar 2022 13:15:16 +0300

> Date: Fri, 25 Mar 2022 08:35:09 +0000
> From: goncholden <goncholden <at> protonmail.com>
> Cc: 54551 <at> debbugs.gnu.org
> 
> > I don't think any of this, or the problem you are trying to solve, is
> > relevant to what show-paren does, though.
> 
> Not to what show-paren does, but about tools to isolate or focus on specific
> sections of code.  Could there be a way to ignore sections of code without
> requiring commenting?

Several people just gave you advice about some ways of doing that.

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

From: goncholden <goncholden <at> protonmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 54551 <at> debbugs.gnu.org
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Fri, 25 Mar 2022 11:47:31 +0000

------- Original Message -------

On Friday, March 25th, 2022 at 8:51 PM, Stephen Berman <stephen.berman <at> gmx.net> wrote:

> On Fri, 25 Mar 2022 07:10:36 +0000 goncholden via "Bug reports for GNU Emacs, the Swiss army knife of text editors" bug-gnu-emacs <at> gnu.org wrote:
>
> > I am debugging a problem where emacs states that there exists an extra
> >
> > closing parenthesis, but having extreme difficulty locating it.
> >
> > Have split the file in two and using "require" on a child file. Otherwise
> >
> > I have to comment each line of code rather than whole sections. Commenting
> >
> > each line is likely to introduce errors if one is not very careful removing
> >
> > the comment tags.
>
> Have you tried calling `check-parens' in the files?
> Steve Berman

Have not played with that, no.

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

From: goncholden <goncholden <at> protonmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 54551 <at> debbugs.gnu.org
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Fri, 25 Mar 2022 11:56:50 +0000

------- Original Message -------

On Friday, March 25th, 2022 at 11:47 PM, goncholden <goncholden <at> protonmail.com> wrote:

> ------- Original Message -------
>
> On Friday, March 25th, 2022 at 8:51 PM, Stephen Berman stephen.berman <at> gmx.net wrote:
>
> > On Fri, 25 Mar 2022 07:10:36 +0000 goncholden via "Bug reports for GNU Emacs, the Swiss army knife of text editors" bug-gnu-emacs <at> gnu.org wrote:
> >
> > > I am debugging a problem where emacs states that there exists an extra
> > >
> > > closing parenthesis, but having extreme difficulty locating it.
> > >
> > > Have split the file in two and using "require" on a child file. Otherwise
> > >
> > > I have to comment each line of code rather than whole sections. Commenting
> > >
> > > each line is likely to introduce errors if one is not very careful removing
> > >
> > > the comment tags.
> >
> > Have you tried calling `check-parens' in the files?
> >
> > Steve Berman
>
> Have not played with that, no.

Need some assistance on using check-parens.  Have done
"M-x check-parens", what do I have to do after that, and what should I check?

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: goncholden <goncholden <at> protonmail.com>
Cc: 54551 <at> debbugs.gnu.org
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Fri, 25 Mar 2022 13:00:34 +0100

On Fri, 25 Mar 2022 11:56:50 +0000 goncholden <goncholden <at> protonmail.com> wrote:

> ------- Original Message -------
>
> On Friday, March 25th, 2022 at 11:47 PM, goncholden
> <goncholden <at> protonmail.com> wrote:
>
>> ------- Original Message -------
>>
>> On Friday, March 25th, 2022 at 8:51 PM, Stephen Berman
>> stephen.berman <at> gmx.net wrote:
>>
>> > On Fri, 25 Mar 2022 07:10:36 +0000 goncholden via "Bug reports for GNU
>> > Emacs, the Swiss army knife of text editors" bug-gnu-emacs <at> gnu.org wrote:
>> >
>> > > I am debugging a problem where emacs states that there exists an extra
>> > >
>> > > closing parenthesis, but having extreme difficulty locating it.
>> > >
>> > > Have split the file in two and using "require" on a child file. Otherwise
>> > >
>> > > I have to comment each line of code rather than whole sections. Commenting
>> > >
>> > > each line is likely to introduce errors if one is not very careful removing
>> > >
>> > > the comment tags.
>> >
>> > Have you tried calling `check-parens' in the files?
>> >
>> > Steve Berman
>>
>> Have not played with that, no.
>
> Need some assistance on using check-parens.  Have done
> "M-x check-parens", what do I have to do after that, and what should I check?

If `check-parens' finds an unbalanced parenthesis, it moves point to
that position.  If point doesn't change in the buffer you called
`check-parens' in, then that buffer has no unbalanced parentheses.

Steve Berman

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 54551 <at> debbugs.gnu.org, goncholden <goncholden <at> protonmail.com>
Subject: Re: bug#54551: show-paren-mode inconsistency
Date: Fri, 25 Mar 2022 17:25:53 +0100

Phil Sainty <psainty <at> orcon.net.nz> writes:

> It's consistent, but you're confused because you think that the cursor
> indicates a character rather than a position *between* two characters.

This doesn't seem to be a bug, so I'm closing this report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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