bug#24271: 25.1; font-lock problem of c++-mode

bug#24271: 25.1; font-lock problem of c++-mode

[Jiajian Huang]

[-- Attachment #1: Type: text/plain, Size: 3545 bytes --]


I recently notice that there's some strange behaviours of the font-lock of the c++-mode.

Let's start emacs by `emacs -Q` in the terminal, edit a new file `test.cpp` and save the following contents



Then put the cursor two lines above the `int main` line, type `int test`, you will find that the color of word `main` changes from *blue* to *black*



Backspace the current line to `in` or `i`, you will see that the color of `main` change back to *blue*



This is not a very big problem under this test, but I use color theme that the function names are in *bold* type. So when I add a function above another function, the font-lock of the below one keep changing all the time which is really annoying.

Is this a emacs bug ? I want *bold* function name and other *bold* keywords but how can I get rid of it ? Any help will be appreciated.


In GNU Emacs 25.1.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1911))
of 2016-07-25 built on builder10-9.porkrind.org
Windowing system distributor 'Apple', version 10.3.1404
Configured using:
'configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp''

Configured features:
NOTIFY ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LC_CTYPE: UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Entering debugger...
Quit
Type C-x 1 to delete the help window.
Quit

Load-path shadows:
None found.

Features:
(shadow sort mail-extr debug emacsbug message dired format-spec rfc822
mml mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel ns-win ucs-normalize term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote kqueue cocoa ns multi-tty
make-network-process emacs)

Memory information:
((conses 16 196504 7744)
(symbols 48 19533 0)
(miscs 40 68 160)
(strings 32 15110 5660)
(string-bytes 1 445077)
(vectors 16 32924)
(vector-slots 8 651358 5744)
(floats 8 163 155)
(intervals 56 245 20)
(buffers 976 20))

[-- Attachment #2.1: Type: text/html, Size: 6388 bytes --]

[-- Attachment #2.2: 1.png --]
[-- Type: image/png, Size: 41048 bytes --]

[-- Attachment #2.3: 2.png --]
[-- Type: image/png, Size: 38734 bytes --]

[-- Attachment #2.4: Screen Shot 2016-08-19 at 16.51.52.png --]
[-- Type: image/png, Size: 41257 bytes --]

bug#24271: 25.1; font-lock problem of c++-mode

[Eli Zaretskii]

> From: Jiajian Huang <wherejoystarts@gmail.com>
> Date: Sat, 20 Aug 2016 08:42:43 +0800
> 
> I recently notice that there's some strange behaviours of the font-lock of the c++-mode.

I don't see it as strange.

> Let's start emacs by `emacs -Q` in the terminal, edit a new file `test.cpp` and save the following contents
> 
> Then put the cursor two lines above the `int main` line, type `int test`, you will find that the color of word `main` changes from *blue* to *black*
> 
> Backspace the current line to `in` or `i`, you will see that the color of `main` change back to *blue*

When you insert "int test", without the semi-colon, your buffer now
has an invalid C++ program, so it's a small wonder the colors change.
When you replace "int test" with "in test", the "in" part is no longer
a C++ type, so it's again small wonder that colors change.

> Is this a emacs bug ?

I don't think it's a bug.

Thanks.

bug#24271: 25.1; font-lock problem of c++-mode

[Eli Zaretskii]

Please keep the bug address on the CC list.

Forwarding to the bug tracker, since the response was sent only to me:

> From: Jiajian Huang <wherejoystarts@gmail.com>
> Date: Sat, 20 Aug 2016 15:39:58 +0800
> 
> Hi, Thanks for your reply.
> 
> I’m not meaning to write invalid C++ program intentionally, like making a “int test” into “in test”.
> 
> When we’re typing “int test”, we type the “i” first then “n”, then “t”, then “ “(space), then “test”, namely,
> 
> “i” -> “in” -> “int” -> “int “ -> … -> “int test”,
> 
> even “normally” typing, the syntax keeping changing. Let’s keep tracking this procedure.
> 
> 
> 
> As you can see, none of the above images shows a “valid” C++ program. But the color(or the font style) has at least
> changed twice. Base on what you’ve point out, the color should change once the “i” is input  and keep unbold till image 4 
> since none of them is valid.
> 
> This could happen in any other place when typing in c++-mode, like
> 
> Example 1
> 
> 
> Why the “vector” in the first image and third is not turn into “bold red” ?
> Why the “vec” in the second image is turn into “bold red” ?
> 
> Example 2
> 
> 
> This is a more serious example. As you can see, I normally input such a short line “using std::string”, the color have change 6 times !
> I don’s think any of them is a “valid” C++ program except the last one.
> 
> I’ve not seen any other major mode has such a “feature”. This is my first time get into c++-mode. Because of this mechanism,
> the current input area keep “flashing” too much when keep typing fast within a buffer full of words even under such a light color theme. 
> I feel that it’s so different from other major mode(python-mode etc.) soon as I switch to c++-mode. Maybe it’s not a bug, but I don’t think it’s a good feature.
> 
> Thanks.

This misses the images you sent, so please re-send them to the bug
address.

bug#24271: 25.1; font-lock problem of c++-mode

[Jiajian Huang]

[-- Attachment #1: Type: text/plain, Size: 2824 bytes --]

(I’m sorry for resending this message.)

Hi, Thanks for your reply. 

I’m not meaning to write invalid C++ program intentionally, like making a “int test” into “in test”.

When we’re typing “int test”, we type the “i” first then “n”, then “t”, then “ “(space), then “test”, namely,

“i” -> “in” -> “int” -> “int “ -> … -> “int test”,

even “normally” typing, the syntax keeping changing. Let’s keep tracking this procedure.



As you can see, none of the above images shows a “valid” C++ program. But the color(or the font style) has at least
changed twice. Base on what you’ve point out, the color should change once the “i” is input  and keep unbold till image 4 
since none of them is valid.

This could happen in any other place when typing in c++-mode, like

Example 1


Why the “vector” in the first image and third is not turn into “bold red” ?
Why the “vec” in the second image is turn into “bold red” ?

Example 2


This is a more serious example. As you can see, I normally input such a short line “using std::string”, the color have change 6 times !
I don’s think any of them is a “valid” C++ program except the last one.

I’ve not seen any other major mode has such a “feature”. This is my first time get into c++-mode. Because of this mechanism,
the current input area keep “flashing” too much when keep typing fast within a buffer full of words even under such a light color theme. 
I feel that it’s so different from other major mode(python-mode etc.) soon as I switch to c++-mode. Maybe it’s not a bug, but I don’t think it’s a good feature.

Thanks.

> On 20 Aug 2016, at 14:56, Eli Zaretskii <eliz@gnu.org <mailto:eliz@gnu.org>> wrote:
> 
>> From: Jiajian Huang <wherejoystarts@gmail.com <mailto:wherejoystarts@gmail.com>>
>> Date: Sat, 20 Aug 2016 08:42:43 +0800
>> 
>> I recently notice that there's some strange behaviours of the font-lock of the c++-mode.
> 
> I don't see it as strange.
> 
>> Let's start emacs by `emacs -Q` in the terminal, edit a new file `test.cpp` and save the following contents
>> 
>> Then put the cursor two lines above the `int main` line, type `int test`, you will find that the color of word `main` changes from *blue* to *black*
>> 
>> Backspace the current line to `in` or `i`, you will see that the color of `main` change back to *blue*
> 
> When you insert "int test", without the semi-colon, your buffer now
> has an invalid C++ program, so it's a small wonder the colors change.
> When you replace "int test" with "in test", the "in" part is no longer
> a C++ type, so it's again small wonder that colors change.
> 
>> Is this a emacs bug ?
> 
> I don't think it's a bug.
> 
> Thanks.

[-- Attachment #2.1: Type: text/html, Size: 7623 bytes --]

[-- Attachment #2.2: Screen Shot 2016-08-20 at 15.06.25.png --]
[-- Type: image/png, Size: 20585 bytes --]

[-- Attachment #2.3: Screen Shot 2016-08-20 at 15.06.35.png --]
[-- Type: image/png, Size: 20927 bytes --]

[-- Attachment #2.4: Screen Shot 2016-08-20 at 15.06.42.png --]
[-- Type: image/png, Size: 21047 bytes --]

[-- Attachment #2.5: Screen Shot 2016-08-20 at 15.06.53.png --]
[-- Type: image/png, Size: 24360 bytes --]

[-- Attachment #2.6: Screen Shot 2016-08-20 at 15.16.20.png --]
[-- Type: image/png, Size: 26539 bytes --]

[-- Attachment #2.7: Screen Shot 2016-08-20 at 15.17.10.png --]
[-- Type: image/png, Size: 30376 bytes --]

[-- Attachment #2.8: Screen Shot 2016-08-20 at 15.17.18.png --]
[-- Type: image/png, Size: 33241 bytes --]

[-- Attachment #2.9: Screen Shot 2016-08-20 at 15.17.27.png --]
[-- Type: image/png, Size: 33963 bytes --]

[-- Attachment #2.10: Screen Shot 2016-08-20 at 15.34.47.png --]
[-- Type: image/png, Size: 25604 bytes --]

[-- Attachment #2.11: Screen Shot 2016-08-20 at 15.27.05.png --]
[-- Type: image/png, Size: 26325 bytes --]

[-- Attachment #2.12: Screen Shot 2016-08-20 at 15.27.56.png --]
[-- Type: image/png, Size: 25547 bytes --]

[-- Attachment #2.13: Screen Shot 2016-08-20 at 15.28.03.png --]
[-- Type: image/png, Size: 26826 bytes --]

[-- Attachment #2.14: Screen Shot 2016-08-20 at 15.28.10.png --]
[-- Type: image/png, Size: 26929 bytes --]

[-- Attachment #2.15: Screen Shot 2016-08-20 at 15.28.32.png --]
[-- Type: image/png, Size: 28488 bytes --]

[-- Attachment #2.16: Screen Shot 2016-08-20 at 15.28.40.png --]
[-- Type: image/png, Size: 30505 bytes --]

[-- Attachment #2.17: Screen Shot 2016-08-20 at 15.28.43.png --]
[-- Type: image/png, Size: 29572 bytes --]

bug#24271: 25.1; font-lock problem of c++-mode

[Eli Zaretskii]

> From: Jiajian Huang <wherejoystarts@gmail.com>
> Date: Sat, 20 Aug 2016 15:57:02 +0800
> Cc: 24271@debbugs.gnu.org
> 
> This is a more serious example. As you can see, I normally input such a short line “using std::string”, the color have change 6 times !
> I don’s think any of them is a “valid” C++ program except the last one.
> 
> I’ve not seen any other major mode has such a “feature”. This is my first time get into c++-mode. Because of this mechanism,
> the current input area keep “flashing” too much when keep typing fast within a buffer full of words even under such a light color theme. 
> I feel that it’s so different from other major mode(python-mode etc.) soon as I switch to c++-mode. Maybe it’s not a bug, but I don’t think it’s a good feature.

The effects of changing the colors is exacerbated in your case by the
fact that you use a bold face for some of the faces.  If you just use
colors, the changes are not really as annoying as you say, IMO.

Regardless of what Alan, the developer of the C++ mode says about
this, I think you can avoid at least some of the unpleasant effects of
this in your setup if you activate stealth fontification by setting
jit-stealth-time to some non-nil value, like 0.1.  Then Emacs will not
attempt to re-fontify the buffer as long as you are typing, and will
only do so after Emacs has been idle for 0.1 sec (or any other value
you assign to jit-stealth-time).

(If you do try jit-stealth, I suggest to also set jit-stealth-load to
something like 25, to prevent stealth fontifications from hogging the
CPU.)

bug#24271: 25.1; font-lock problem of c++-mode

[Jiajian Huang]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

Thanks for your reply.

> The effects of changing the colors is exacerbated in your case by the
> fact that you use a bold face for some of the faces.  

The changes is really annoying. In my opinion, a bold type font for keywords 
and variable name is just too common in modern editor using a large monitor.
With the regular font style, it’s difficult to read the code.

> On 20 Aug 2016, at 16:15, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> Regardless of what Alan, the developer of the C++ mode says about
> this, I think you can avoid at least some of the unpleasant effects of
> this in your setup if you activate stealth fontification by setting
> jit-stealth-time to some non-nil value, like 0.1. 


Do you mean jit-lock-stealth-time ?

I set it to 0.1 (even 0.8) and nothing changes.

Thanks.

[-- Attachment #2: Type: text/html, Size: 4048 bytes --]

bug#24271: 25.1; font-lock problem of c++-mode

[Eli Zaretskii]

> From: Jiajian Huang <wherejoystarts@gmail.com>
> Date: Sat, 20 Aug 2016 16:27:38 +0800
> Cc: 24271@debbugs.gnu.org
> 
>  Regardless of what Alan, the developer of the C++ mode says about
>  this, I think you can avoid at least some of the unpleasant effects of
>  this in your setup if you activate stealth fontification by setting
>  jit-stealth-time to some non-nil value, like 0.1. 
> 
> Do you mean jit-lock-stealth-time ?
> 
> I set it to 0.1 (even 0.8) and nothing changes.

Sorry, I meant jit-lock-defer-time.

bug#24271: 25.1; font-lock problem of c++-mode

[Lars Ingebrigtsen]

Jiajian Huang <wherejoystarts@gmail.com> writes:

> This is a more serious example. As you can see, I normally input such
> a short line “using std::string”, the color have change 6 times !  I
> don’s think any of them is a “valid” C++ program except the last one.
>
> I’ve not seen any other major mode has such a “feature”. This is my
> first time get into c++-mode. Because of this mechanism, the current
> input area keep “flashing” too much when keep typing fast within a
> buffer full of words even under such a light color theme.  I feel that
> it’s so different from other major mode(python-mode etc.) soon as I
> switch to c++-mode. Maybe it’s not a bug, but I don’t think it’s a
> good feature.

I tried the recipe in Emacs 27, and it seems like c++ mode is much
calmer these days.  There are one three changes I see to the
fontification while typing that line, and none of them are very
attention-grabbing (i.e., none of them flash red bold at me), so I'm
going to go ahead and guess that this has been tweaked in the years
since this was reported, and I'm closing this bug report.

Please reopen if it's still an issue.

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