From: Alan Mackenzie <acm@muc.de>
To: Bill Sacks <sacks@ucar.edu>
Cc: 56818-done@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
Subject: bug#56818: 28.1; c-mode font-lock issues in Emacs 28
Date: Sat, 30 Jul 2022 13:18:54 +0000 [thread overview]
Message-ID: <YuUvvo2Fhz72/P+j@ACM> (raw)
In-Reply-To: <00abbbce-f72d-dd4a-7430-f85722c9d9b0@ucar.edu>
Hello, Bill.
On Fri, Jul 29, 2022 at 14:38:53 -0600, Bill Sacks wrote:
> Unfortunately, I still see an issue in a slightly different context. The
> issue appears when function arguments appear on a line following the
> function name. This one is harder to provide screen shots for, because
> it is a bit more dynamic, but I'll try to walk through how to reproduce
> it, referencing two attachments: The starting point is testing_start.c
> and the end point is testing.c. If you start with testing_start.c and
> then take some steps to get to testing.c, you will notice a few issues
> with fontification of "somevar":
> (1) Position the cursor at the start of line 2 and hit Tab to put the
> cursor on line 2, column 12. Type "int somevar" and notice that
> "somevar" remains in the default face rather than being given
> font-lock-variable-name-face.
> (2) Run M-x font-lock-fontify-buffer to make "somevar" correctly take on
> font-lock-variable-name-face. (Interestingly, it seems fixed as soon as
> I type "M-x" and get into the minibuffer.)
> (3) Delete then retype the "r" in "somevar", noticing that it again
> reverts to default face
> (4) Repeat step (2) to temporarily fix the fontification
> (5) Type " // comment", noticing that "somevar" again loses its
> fontification
> (6) Repeat step (2) to temporarily fix the fontification
> (7) Delete and retype the "t" in "comment", noticing that "somevar"
> again loses its fontification.
> If my instructions are unclear or you cannot reproduce this, I can
> provide a screencast where I illustrate this behavior.
Those directions are admirably clear, thanks!
> I tested briefly with Emacs 27, and it appears that the problems in (1)
> and (3) are new issues in Emacs 28, but (5) and (7) appear in Emacs 27
> as well.
What is happening here is a different bug, distinct from bug #56818,
with different causes. I've opened a fresh bug for this, bug #56841,
putting you on the Cc:.
So I'm closing bug #56818 with this post, as it appears to be fixed.
[ .... ]
> Bill
--
Alan Mackenzie (Nuremberg, Germany).
prev parent reply other threads:[~2022-07-30 13:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-28 20:32 bug#56818: 28.1; c-mode font-lock issues in Emacs 28 Bill Sacks
2022-07-29 5:56 ` Eli Zaretskii
2022-07-29 17:44 ` Alan Mackenzie
2022-07-29 18:11 ` Eli Zaretskii
2022-07-29 20:23 ` Bill Sacks
2022-07-29 20:38 ` Bill Sacks
2022-07-30 13:18 ` Alan Mackenzie [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YuUvvo2Fhz72/P+j@ACM \
--to=acm@muc.de \
--cc=56818-done@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=sacks@ucar.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.