-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
font-lock-activate isue with hooks #9
Comments
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>
.
|
Hi: I had exactly the same set up that is described in the readme, and it didn't work. I don't The only config I have tried that works for me is:
|
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>
.
|
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: For some reason when one of them is enabled the So for now I will continue with the workaround that is working for me. |
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>
.
|
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. |
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 Could you consider to do that? |
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>
.
|
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 variableglobal-font-lock-mode
. which is already set in that moment:Something like:
In
cmake-font-lock-activate
could fix this issue.The text was updated successfully, but these errors were encountered: