help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with CC mode hooks and font-locking


From: Francis Belliveau
Subject: Re: Problem with CC mode hooks and font-locking
Date: Fri, 30 Nov 2018 16:50:23 -0500

First: Thank you Stefan for your answer.

I will endeavor to rerun my experiments and document the results in a more 
scientific manner.

To be clear, what I am trying to do is eliminate the colors being applied to 
text in all my files.  My understanding from the documentation is that if I add 
(global-font-lock-mode -1) to my .emacs file before I load any modes, the 
effects should be globally disabled.  Therefore, "failure" in this case is when 
various portions of my text is being shown in different colors.

I am not sure that it matters, but for clarity, my .emacs setup opens up with 
the window split vertically so that I can see two buffers simultaneously.
For the experiments below, I always open the application from my dock so that 
no file is loaded.  Then I usually open my .emacs file first, in the left half, 
then the code files in order on the right.  Where I open another file first, it 
is done in the left side and the others on the right.

1. Placing this in my .emacs file does not seem to have any effect.  Lisp, C++ 
and Java modes all show text in lots of colors.

2. Removed it from main .emacs and placed it in my 'c-initialization-hook' 
produces the following curious effects:
  a) Load .emacs shows Lisp mode with lots of colors
  b) Load foo.h shows C++ mode with lots of colors, but the colors are gone 
from the .emacs text
  c) Load foo.cpp shows C++ mode all in black
  d) Load foo.java shows Java mode all in black

  Curious about the .h file being colorized, but loading it eliminated the 
colors from the .emacs buffer.
  I switched between these 4 buffers in the the two sides and the coloring 
stayed firm with the buffer contents as expected.

  I restarted emacs without any .emacs changes and loaded the files in 
different order.
  - .emacs, foo.cpp, foo.java, foo.h
    Same effects, Lisp shows colors that go away when the first C++ file 
(foo.cpp) is loaded with lots of colors and all others are in black.
  - .emacs, foo.java, foo.h, foo.cpp
    Same effects, Lisp shows colors that go away when the first file (foo.java) 
is loaded with lots of colors and all others are in black.
  - foo.h, .emacs, foo.cpp, foo.java
    This time foo.h is colored, and remains that way.  All others are black.
  - foo.java, .emacs, foo.h, foo.cpp
  - foo.cpp, foo.h, foo.java, .emacs
    Both of these tests showed the first file remained all colored, and the 
others all black.

  3. Put it back into the main .emacs code, and left it in the 
'c-initialization-hook'.
  - .emacs, foo.h, foo.cpp, foo.java
  This produced the same results as in 2 that .emacs first showed itself all 
colored and then turned black when foo.h was loaded and shown all colored.  The 
other files were also all black.

I do not understand why there is any "file load order" dependency, or why the 
first CC mode file seems to "rob" the Lisp mode buffer of its color.  I use the 
term "rob" with tongue-in-cheek.

The order of things in my .emacs file is:

;; disable all colorization stuff
(global-font-lock-mode -1)

(defun my-load-once-code-hook ()
    "My function to load when a code-mode is initialized the first time"
    (progn
      ;-(setq flb-dbg-val '1)
      (global-font-lock-mode -1)
      ;-(setq c-basic-offset my-tab-width)
      ;-(my-require 'sce)
      ;-(if c-mode-base-map
      ;-    (define-key c-mode-base-map "\C-m" 'c-newline))
      ;-(flb)
    ))

;; set all the load-once stuff for coding
(add-hook 'c-initialization-hook 'my-load-once-code-hook)

;;;;;;;;
I expect that this is more than enough for you all to digest for now.
My obvious next step would be to move on and place this in a 
'c-mode-common-hook' but I wonder if I should remove the other two uses first?
Does anybody have any other ideas?

Thanks for taking the time for reading all this.  I will appreciate any help I 
can get with chasing down the reason for this.

Fran


reply via email to

[Prev in Thread] Current Thread [Next in Thread]