all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Mauro Aranda <maurooaranda@gmail.com>
Cc: 35454@debbugs.gnu.org
Subject: bug#35454: 26.2.50; CC-Mode fontification fails inside macro
Date: Thu, 2 May 2019 08:57:14 +0000	[thread overview]
Message-ID: <20190502085714.GA4277@ACM> (raw)
In-Reply-To: <CABczVwc3BMNVtiDHsiARAy=sqvc00jfLoQohc40oZF2sdZvNnA@mail.gmail.com>

Hello, Mauro.

On Wed, May 01, 2019 at 19:31:48 -0300, Mauro Aranda wrote:
> Alan Mackenzie <acm@muc.de> writes:

> Hello Alan.  Thanks for looking into this bug!

> > Please try out the patch below.  On my system, it corrects the
> > fontification in both your test file and editfns.c.

> I've applied the patch and tried the recipe I provided, and it works fine.

> However, when I visit editfns.c and search for EXTRA_CONTEXT_FIELDS,
> like I said in my report, I see the following problem with this variables:
> struct buffer *buffer_a;
> struct buffer *buffer_b;
> unsigned char *deletions;
> unsigned char *insertions;

> All but deletions have face font-lock-variable-name-face.

> I can't seem to come up with a simple recipe to reproduce the problem,
> so I refer you to that part of editfns.c.

Thanks, I didn't notice these last night, but I can see them now.

> All the following steps, separately with emacs -Q (or you could kill the
> buffer if you want)
> 1) C-x C-f editfns.c
> C-s extra RET
> I observe deletions without its correspondent face and if I type:
> SPC DEL
> deletions gets font-lock-variable-name-face face.  However, if I
> revert the buffer with M-x revert-buffer RET yes RET buffer_a, deletions
> and the first 'buffer' lose their faces.

The problem with "deletions" seems to be triggered by the 2-line comment
in the macro not having a backslash escaping the \n.  In nearly 30 years
hacking C, I've never seen this before, and didn't even know it was
valid syntax.  However, this means at least four very commonly used
functions (c-beginning-of-macro, c-end-of-macro, c-forward-sws, and
c-backward-sws) are going to have to be amended to deal with it, and
this is inevitably going to make CC Mode slower.  :-(

I can't see at the moment any pattern with the fontification on
buffer_a.  Sometimes just scrolling the buffer a few lines makes
buffer_a lose its fontification.  But if an empty pair of parentheses is
put after EXTRA_CONTEXT_FIELDS, all these problems go away.  So they
seem related to what I half-fixed last night.

> 2) C-x C-f editfns.c
> C-s deletions RET
> I see that deletions has the right face.  But
> M-x revert-buffer
> makes it lose it (but *buffer_a keeps its face).

> 3) C-x C-f editfns.c
> C-s extra RET
> deletions without font-lock-variable-name-face.
> C-l C-l
> M-x revert-buffer
> deletions now has font-lock-variable-name-face.

> That is all the testing I could do, sorry for not being able to come up
> with a better recipe.  Let me know if you see the same behavior, or what
> else I could try.

Well, that seems like quite a lot of testing to me.  :-)  Thanks for
doing it and reporting back to me so quickly.

I'll be working on the outstanding bugs here in the next few days.

> Best regards,
> Mauro.

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2019-05-02  8:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-27 15:57 bug#35454: 26.2.50; CC-Mode fontification fails inside macro Mauro Aranda
2019-04-27 20:36 ` Alan Mackenzie
2019-05-01 21:02   ` Alan Mackenzie
2019-05-01 22:31     ` Mauro Aranda
2019-05-02  8:57       ` Alan Mackenzie [this message]
2019-05-02 14:42         ` Alan Mackenzie
2019-05-02 21:03       ` Alan Mackenzie
2019-05-02 21:44         ` Mauro Aranda
2019-05-03  7:41           ` Alan Mackenzie

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=20190502085714.GA4277@ACM \
    --to=acm@muc.de \
    --cc=35454@debbugs.gnu.org \
    --cc=maurooaranda@gmail.com \
    /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.