GNU bug report logs - #70435
30.0.50; cc-mode: <> are sometimes not reconized as parentheses

Previous Next

Package: emacs;

Reported by: Herman, Géza <geza.herman <at> gmail.com>

Date: Wed, 17 Apr 2024 10:48:06 UTC

Severity: normal

Found in version 30.0.50

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Herman Géza <geza.herman <at> gmail.com>
Cc: acm <at> muc.de, Eli Zaretskii <eliz <at> gnu.org>, 70435 <at> debbugs.gnu.org
Subject: bug#70435: 30.0.50; cc-mode: <> are sometimes not reconized as parentheses
Date: Sun, 28 Apr 2024 20:31:17 +0000
Hello again, Géza.

On Sun, Apr 28, 2024 at 18:47:47 +0200, Herman, Géza wrote:
> Hello Alan,

> Alan Mackenzie <acm <at> muc.de> writes:

> > You've been a little less than fully explicit, but I think you're
> > executing these commands in the *scratch* buffer.  The first two
> > lines, which are commented out in emacs-lisp-mode, are no longer
> > commented out in C++ Mode.  There is a whole line of garbage after
> > the last end of statement marker, the (double) semicolon on line 2.

> > On using ig<TAB> to insert the snippet, it is hardly surprising that
> > CC Mode's syntactic analysis gets confused.  If you first comment
> > out those first two lines (put the region around them and do C-c
> > C-c), then the inserted snippet appears to get the correct syntax on
> > its template markers.

> > I don't think there's a bug here.  If you could show ig<TAB>
> > producing the effect when typed inside a syntactically correct
> > context, things might be different.  Can you reproduce the effect in
> > correct C++ code?

> You're right, it seems that the example I provided wasn't the best 
> (this issue happens with me in real code, I tried to create a 
> minimal reproducible example).

That's always appreciated.

> If you delete the garbage from the scratch buffer, the bug doesn't 
> reproduce indeed.  But, if you run (setq 
> font-lock-maximum-decoration 2) before switching to c++-mode, the 
> issue reproduces with an empty scratch buffer.  I use this setting 
> because font-lock runs much faster this way, and I rely on the LSP 
> server to do the "full" highlighting.

I confirm I can reproduce the bug with font-lock-maximum-decoration set
to 2.  I'll look into it.

> Sorry about the bad example, here are the fixed repro steps:

> Repro:
> - put the yasnippet file (included below) into
> <emacs-config-dir>/snippets/c++-mode/something
> - install yasnippet
> - start emacs, scratch buffer appears
> - delete the contents of the scratch buffer
> - M-: (setq font-lock-maximum-decoration 2)
> - M-x c++-mode
> - M-x yas-minor-mode
> - load snippets with "M-x yas-reload-all"
> - write "ig", then press TAB to "yas-expand" the snippet
> - move the cursor on the opening "<", and execute "M-x 
>   describe-char"
> - notice that it will say "syntax: . which means: punctuation"
> - if you edit the buffer (like add a space somewhere), and execute
> describe-char again, Emacs will say "syntax: > which means: open,
> matches >", so the syntax class becomes correct.

> Geza

-- 
Alan Mackenzie (Nuremberg, Germany).




This bug report was last modified 1 year and 11 days ago.

Previous Next


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