font-lock-activate isue with hooks

[Ergus]

Hi:

I am trying to use this package with the hooks, but it is not working.

After some debugging I just found that the problem is that font-lock-mode is nil in that moment because it is set later; but you can use the global variable global-font-lock-mode. which is already set in that moment:

Something like:

(when (and (or font-lock-mode  global-font-lock-mode)
           (fboundp 'font-lock-refresh-defaults))
      (font-lock-refresh-defaults)))

In cmake-font-lock-activate could fix this issue.

[Lindydancer]

Hi! Can you describe how you set up cmake-font-lock mode in your init file? I think the original code should work. If font-lock-mode is nil (i.e. it is disabled), the changes the package makes will take effect when it is enabled.

…

-- Anders

On Sun, Apr 14, 2019 at 1:58 AM Jimmy Aguilar Mena ***@***.***> wrote: Hi: I am trying to use this package with the hooks, but it is not working. After some debugging I just found that the problem is that font-lock-mode is nil in that moment because it is set later; but you can use the global variable global-font-lock-mode. which is already set in that moment: Something like: (when (and (or font-lock-mode global-font-lock-mode) (fboundp 'font-lock-refresh-defaults)) (font-lock-refresh-defaults))) In cmake-font-lock-activate could fix this issue — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADBjQGbNkYSjePgfoJax1UAikonzUskLks5vgm8fgaJpZM4cuVSB> .

[Ergus]

Hi:

I had exactly the same set up that is described in the readme, and it didn't work. I don't enable font-lock-mode explicitly in the init file because it is already enabled by default with the global-font-lock-mode. After loading, the global variable font-lock-mode remains nil, but the buffer local one is set to t.

The only config I have tried that works for me is:

(use-package cmake-mode
  :mode ("\\'CMakeLists\\.txt\\'" "\\.cmake\(.in\)?\\'")
  :config
  (add-to-list 'company-backends 'company-cmake))

(use-package cmake-font-lock
  :preface
  (defun my/cmake-font-lock ()
    (cmake-font-lock-setup)
    (when (and (or font-lock-mode  global-font-lock-mode)
           (fboundp 'font-lock-refresh-defaults))
      (font-lock-refresh-defaults)))
  :init
  (add-hook 'cmake-mode-hook #'my/cmake-font-lock t))

[Lindydancer]

I just tested with the following minimal init file, and it works. I tested with Emacs 26.1. (The paths are specific to my setup, but they can easily be modified.): ;; ---------------------------------------- ;; Setup `cmake-mode'. ;; (add-to-list 'load-path "~/emacs/lisp") (autoload 'cmake-mode "cmake-mode" nil t) (progn (add-to-list 'auto-mode-alist '("CMakeLists\\.txt\\'" . cmake-mode)) (add-to-list 'auto-mode-alist '("\\.cmake\\'" . cmake-mode))) ;; ---------------------------------------- ;; Setup `cmake-mode-font-lock'. ;; (add-to-list 'load-path "~/emacs/src/cmake-font-lock") (autoload 'cmake-font-lock-activate "cmake-font-lock" nil t) (add-hook 'cmake-mode-hook #'cmake-font-lock-activate) I tested it using: emacs -Q -l myinit.el CMakeLists.txt I'm not that familiar with use-package, but I don't see any reason why it should interfere. Ditto for company mode. Anyway, the idea of the code is to look at the buffer-local version of the variable font-lock-mode. If it is nil (i.e. font-lock has not yet been enabled) it's sufficient to run cmake-font-lock-setup. When it's non-nil, font-lock-mode has already been enabled in the buffer. In that case, font-lock-refresh-defaults must be called. What version of Emacs are you using? Can you try the init code above (with updated paths) and check if it works for you? If it works, I would like to investigate why an init file based on use-package doesn't work.

…

-- Anders

On Mon, Apr 15, 2019 at 10:43 AM Jimmy Aguilar Mena < ***@***.***> wrote: Hi: I had exactly the same set up that is described in the readme, and it didn't work. I don't enable font-lock-mode explicitly in the init file because it is already enabled by default with the global-font-lock-mode. After loading, the global variable font-lock-mode remains nil, but the buffer local one is set to t. The only config I have tried that works for me is: (use-package cmake-mode :mode ("\\'CMakeLists\\.txt\\'" "\\.cmake\(.in\)?\\'") :config (add-to-list 'company-backends 'company-cmake)) (use-package cmake-font-lock :preface (defun my/cmake-font-lock () (cmake-font-lock-setup) (when (and (or font-lock-mode global-font-lock-mode) (fboundp 'font-lock-refresh-defaults)) (font-lock-refresh-defaults))) :init (add-hook 'cmake-mode-hook #'my/cmake-font-lock t)) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADBjQLJa8D-XhwH0q7QtvOUIkFx_Kp11ks5vhDu6gaJpZM4cuVSB> .

[Ergus]

Hi I double check and your config worked, as well the use-packages one when I tried them alone.

After double checking it seems that the problem is a conflict with the packages: highlight-numbers and highlight-indent-guides.

For some reason when one of them is enabled the cmake-font-lock-mode does not work when enabled as a hook (not your or mine config). Probably it has to do with some global-vs-local variable issue, but I am not a lisp specialist to understand where the conflict is.

So for now I will continue with the workaround that is working for me.

[Lindydancer]

Hi! If you even figure out what the problem is, please let me know. I will try to keep my eyes open, if I should come across similar problems in the future. Anyway, thanks for reporting this, and thanks for sticking with me, with all my follow-up questions!

…

-- Anders

On Mon, Apr 15, 2019 at 11:28 PM Jimmy Aguilar Mena < ***@***.***> wrote: Closed #9 <#9>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADBjQKVsJycmvHZnbXPXNQVUEKM-GBiHks5vhO8agaJpZM4cuVSB> .

[Ergus]

Hi I have been looking the code in highlight-numbers looking for the issue source, but I can't find it. Probably you could give a look too, it is a pretty simple package and 4 eyes are better than two.

[Ergus]

Hi:

After some time I am comming back to this and I wrote to Stefan Monnier to guive a look. So far he thinks that cmake-font-lock.el should reallybe part of cmake.el because setting font-lock-defaults directly can only be done reliably by the major-mode function itself rather than from the mode hook.

Could you consider to do that?

[Lindydancer]

Hi! This is more a philosophical question than a technical one. The main problem is that whoever is responsible for the main archive is also responsible to maintain the package -- adapt it to new CMake releases, fix problems, and also evolve it further (for example, a flycheck-like system that warns user for incorrect usage). I honestly don't think that that will happen if the package should be included in the main CMake archive. The package is very complex and is almost five times larger than Kitwares CMake mode. For what I know, they might not even like it to be included... Of course, it is open-source so anybody could do anything they like with it, but I don't think it would benefit the users if the code base would be forked. The only place that I would feel comfortable to donate the package to is if it would be included in the Emacs distribution. However, that would require that I, or someone in the Emacs community, implement a new GPL-licensed major mode for CMake using my highlighting code.

…

-- Anders Den tor 4 juni 2020 19:07Jimmy Aguilar Mena <notifications@github.com> skrev:

Hi: After some time I am comming back to this and I wrote to Stefan Monnier to guive a look. So far he thinks that cmake-font-lock.el should reallybe part of cmake.el because setting font-lock-defaults directly can only be done reliably by the major-mode function itself rather than from the mode hook. Could you consider to do that? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYGGQD2SUVKSMGOWWVU753RU7IDPANCNFSM4HFZKSAQ> .