[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#15211: 24.3.50; Incorrect fontification in c++-mode
From: |
Ivan Andrus |
Subject: |
bug#15211: 24.3.50; Incorrect fontification in c++-mode |
Date: |
Tue, 10 Sep 2013 14:04:31 -0600 |
On Aug 31, 2013, at 2:56 PM, Alan Mackenzie <acm@muc.de> wrote:
> Hi, Ivan.
>
>> In C and C++ it is legal to place the const to the right of the type as
>> below:
>
>> Json parseJson( string const &json );
>
>> However, this results in "string" not being fontified as a type
>> (i.e. with `font-lock-type-face'). It seems to work some times, but the
>> minimal example above does not when starting from `emacs -q`.
>
> Yes. There is special code in `c-forward-type' that causes different
> return codes for "string const" and "string". These two return codes are
> specifically differentiated (at the end of `c-forward-decl-or-cast-1')
> when deciding whether or not to fontify the identifier.
>
> I've not been able to understand why this code does this - the code has
> been in place for well over a decade, and I've been looking at old change
> logs. The following patch disables the distinction and always fontifies
> the identifier. Please try it out and let me know if any undesirable
> side effects occur, or if it doesn't quite fix the problem in real code:
I have been using your diff below for a few days, and I haven't noticed any
negative side effects.
There are still two things that don't fontify correctly:
#define DELETE_MEMBER = delete
class Bob
{
Bob &operator=(Bob const &) = delete; // fontified (with diff applied)
Bob &operator=(Bob const &) DELETE_MEMBER; // not fontified with or without
diff
Bob( string ); // string is a `font-lock-type-face'
explicit Bob( string ); // string is `font-lock-variable-name-face'
};
The first bad fontification seems to be caused because it doesn't understand
the macro which probably can't be helped. The second though is a bit more
concerning, though it seems to be unrelated to the current bug. I will
probably open another bug for it unless you'd prefer I didn't
>
> diff -r 45df171f9859 cc-engine.el
> --- a/cc-engine.el Sat Aug 31 11:09:30 2013 +0000
> +++ b/cc-engine.el Sat Aug 31 20:32:22 2013 +0000
> @@ -7440,7 +7440,8 @@
> ;; interactive refontification.
> (c-put-c-type-property (point) 'c-decl-arg-start))
>
> - (when (and c-record-type-identifiers at-type (not (eq at-type t)))
> + (when (and c-record-type-identifiers at-type ;; (not (eq at-type t))
> + )
> (let ((c-promote-possible-types t))
> (save-excursion
> (goto-char type-start)
>
>
> After applying the patch to .../lisp/progmodes/cc-engine.el, just
> recompile cc-engine.el with M-x byte-compile-file <CR> cc-engine.el, then
> reload cc-engine.elc with M-x load-file <CR> cc-engine.elc.
>
>> Although this is fairly uncommon, there are valid reasons for doing this
>> (see http://www.dansaks.com/articles/1999-02%20const%20T%20vs%20T%20const.pdf
>> for example), and at work it's ubiquitous. The lack of fontification is
>> annoying since it gives me vi envy. :-)
>
> We can't have that. ;-)
Don't worry, it doesn't last long. :-)
>> Thanks for the overall excellent cc-mode(s)!
>
> And thank you for taking the trouble to report this bug, and even more
> for such a high quality bug report.
Based on how quickly you responded, I wish I had reported it long ago.
Thanks again,
Ivan
- bug#15211: 24.3.50; Incorrect fontification in c++-mode,
Ivan Andrus <=