unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* Problem with CC mode hooks and font-locking
  2018-11-17 17:51           ` Eli Zaretskii
@ 2018-11-27  1:06             ` Francis Belliveau
  2018-11-27  2:38               ` Stefan Monnier
  0 siblings, 1 reply; 7+ messages in thread
From: Francis Belliveau @ 2018-11-27  1:06 UTC (permalink / raw)
  To: help-gnu-emacs

I know that I am likely in the minority, but I find all those colors in my code distracting so I wish to turn it all off.
The documentation says how to turn it on, but that is the default and my attempts to turn it off have met with failure.

First, I am running a pre-built download of emacs Version 26.1 (9.0) on OS-X Version 10.13.6

My first attempt was to place  the line
(global-font-lock-mode nil)
in my .emacs file.  That did not work.

Then I placed it into my c-initialization-hook function.
At first, that seemed to work for a .h file, but not a .cpp, or .java, file.  What is strange here is that both the .h and .cpp claim to be running "C++ mode".
However, it seems to function differently depending on the order that files are loaded.  The first file opened (.h, .cpp or .java) is not colored, but the next two are colorized.

At this point I am confused since this should not be a toggling function call, and it should only be getting called once any way.

I had also placed it into the various "load each time" hooks with funny results that could have also been due to the order that I was loading files.

The documentation seems to indicate that just putting it in my .emacs file should be all that is necessary to take effect globally, but since it does not seem to work that way I am asking what is the correct mechanism to turn this off?

Your help will be greatly appreciated.
Fran


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Problem with CC mode hooks and font-locking
  2018-11-27  1:06             ` Problem with CC mode hooks and font-locking Francis Belliveau
@ 2018-11-27  2:38               ` Stefan Monnier
  2018-11-30 21:50                 ` Francis Belliveau
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2018-11-27  2:38 UTC (permalink / raw)
  To: help-gnu-emacs

> My first attempt was to place  the line
> (global-font-lock-mode nil)
> in my .emacs file.  That did not work.

Of course not: a nil argument turns it on, as the docstring says.  Try

    (global-font-lock-mode -1)

But personally I don't like colors either but kept font-lock:
I simply changed the faces to use bold/grey/italics instead of colors.


        Stefan




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Problem with CC mode hooks and font-locking
  2018-11-27  2:38               ` Stefan Monnier
@ 2018-11-30 21:50                 ` Francis Belliveau
  2018-12-01  7:55                   ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Francis Belliveau @ 2018-11-30 21:50 UTC (permalink / raw)
  To: help-gnu-emacs

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Problem with CC mode hooks and font-locking
  2018-11-30 21:50                 ` Francis Belliveau
@ 2018-12-01  7:55                   ` Eli Zaretskii
  2018-12-01 14:33                     ` Francis Belliveau
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2018-12-01  7:55 UTC (permalink / raw)
  To: help-gnu-emacs

> From: Francis Belliveau <f.belliveau@comcast.net>
> Date: Fri, 30 Nov 2018 16:50:23 -0500
> 
> 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.

Maybe the above does matters, as I'm not on macOS, so maybe there's
something macOS specific involved here; in particular, I have no idea
what does "opening application from my dock" mean.

> 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.

Just doing this one thing, i.e. having a .emacs that says only

  (global-font-lock-mode -1)

disables colors in both Lisp (including *scratch* buffer and any Lisp
file I visit) and C/Java files I visited.

Do you have anything else in your .emacs in addition to that single
line?  If so, perhaps those other things are the culprit.  What
happens if you leave just the above single line in your .emacs, and
then restart Emacs?

> 2. Removed it from main .emacs and placed it in my 'c-initialization-hook' produces the following curious effects:

This is definitely not the right thing to do, so let's disregard what
you get when you do this.  (c-initialization-hook is only relevant to
C-like languages, which is not what you want.  And if you do anything
from that hook, you should only change local values,
i.e. font-lock-mode and not global-font-lock-mode; the latter is a
global mode, so it is inappropriate to turn it on or off from a mode
hook.)

> I do not understand why there is any "file load order" dependency

Because you are changing a global setting from a hook that is called
when the first C-like file is visited.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Problem with CC mode hooks and font-locking
  2018-12-01  7:55                   ` Eli Zaretskii
@ 2018-12-01 14:33                     ` Francis Belliveau
  0 siblings, 0 replies; 7+ messages in thread
From: Francis Belliveau @ 2018-12-01 14:33 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: help-gnu-emacs

Thank you Eli, I found found the problem hidden elsewhere that was toggling things.  Understanding is everything.
By the way "Starting from the dock" is the same a clicking an icon on the desktop.  It just starts the application without any arguments.

I am now at the point of not liking what this is doing because, as Eli said, all coloring has been disabled.  I did like seeing the colors in buffers like the output of "grep".

So I removed the statement from my .emacs file and placed (font-lock-mode -1) in my  'c-initialization-hook' with the intention of only disabling colors in my coding modes.
That seems to disable it for only the first file loaded, but not the others.  As Eli suggested, this does not have any effect on Lisp mode; that buffer is always colored.  My guess here is that placing it there does not step on the defaults for all future mode initializations like I would have expected.

So I moved if to my 'c-mode-common-hook' and that did the trick.

Thanks to all who read through my details.  I hope that it will help others to understand these things.

Fran


> On Dec 1, 2018, at 02:55, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Francis Belliveau <f.belliveau@comcast.net>
>> Date: Fri, 30 Nov 2018 16:50:23 -0500
>> 
>> 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.
> 
> Maybe the above does matters, as I'm not on macOS, so maybe there's
> something macOS specific involved here; in particular, I have no idea
> what does "opening application from my dock" mean.
> 
>> 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.
> 
> Just doing this one thing, i.e. having a .emacs that says only
> 
>  (global-font-lock-mode -1)
> 
> disables colors in both Lisp (including *scratch* buffer and any Lisp
> file I visit) and C/Java files I visited.
> 
> Do you have anything else in your .emacs in addition to that single
> line?  If so, perhaps those other things are the culprit.  What
> happens if you leave just the above single line in your .emacs, and
> then restart Emacs?
> 
>> 2. Removed it from main .emacs and placed it in my 'c-initialization-hook' produces the following curious effects:
> 
> This is definitely not the right thing to do, so let's disregard what
> you get when you do this.  (c-initialization-hook is only relevant to
> C-like languages, which is not what you want.  And if you do anything
> from that hook, you should only change local values,
> i.e. font-lock-mode and not global-font-lock-mode; the latter is a
> global mode, so it is inappropriate to turn it on or off from a mode
> hook.)
> 
>> I do not understand why there is any "file load order" dependency
> 
> Because you are changing a global setting from a hook that is called
> when the first C-like file is visited.
> 




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Problem with CC mode hooks and font-locking
@ 2018-12-15 10:04 Van L
       [not found] ` <D054980C-4420-43FE-9133-53E00BACC925@comcast.net>
  0 siblings, 1 reply; 7+ messages in thread
From: Van L @ 2018-12-15 10:04 UTC (permalink / raw)
  To: Help Gnu Emacs mailing list

> I am now at the point of not liking 
> what this is doing because, as Eli said, 
> all coloring has been disabled. 
> I did like seeing the colors in buffers like 
> the output of "grep”.

What you can do to fine tune the coloring is by 

#+NAME: fix--sh-heredoc-color-is-unreadable
#+BEGIN_COMMENT

1. M-x list-faces-display RET
   - alt :: C-u C-x =
     - apply to the offending unreadable character
2. sh-heredoc
   - example :: default coloring is unreadable for me
     - when M-x set-background-color is Gray
3. M-x customize RET
4. search for sh-heredoc and change it

#+END_COMMENT




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Problem with CC mode hooks and font-locking
       [not found] ` <D054980C-4420-43FE-9133-53E00BACC925@comcast.net>
@ 2018-12-16 21:31   ` Van L
  0 siblings, 0 replies; 7+ messages in thread
From: Van L @ 2018-12-16 21:31 UTC (permalink / raw)
  To: Help Gnu Emacs mailing list


> I have no clue what your 4 steps do

No probs. 

That note there helps with 
interactively choosing colors in the 
font-locking contextualization of 
text in the various modes.

I had been ignoring colored text
I was unable to read for ages
until I figured that out.



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2018-12-16 21:31 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-12-15 10:04 Problem with CC mode hooks and font-locking Van L
     [not found] ` <D054980C-4420-43FE-9133-53E00BACC925@comcast.net>
2018-12-16 21:31   ` Van L
  -- strict thread matches above, loose matches on Subject: below --
2018-10-24 15:23 Where is Emacs Lisp taught ? Jean-Christophe Helary
2018-10-24 16:02 ` Emanuel Berg
2018-10-24 22:24   ` Garreau, Alexandre
     [not found]     ` <mailman.4061.1542238084.1284.help-gnu-emacs@gnu.org>
2018-11-17 15:41       ` Gene
2018-11-17 17:39         ` Java-mode Debug question ? Francis Belliveau
2018-11-17 17:51           ` Eli Zaretskii
2018-11-27  1:06             ` Problem with CC mode hooks and font-locking Francis Belliveau
2018-11-27  2:38               ` Stefan Monnier
2018-11-30 21:50                 ` Francis Belliveau
2018-12-01  7:55                   ` Eli Zaretskii
2018-12-01 14:33                     ` Francis Belliveau

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).