lindydancer / cmake-font-lock Goto Github PK

On Emacs 23 symbol's function definition is void: font-lock-refresh-defaults

A quickfix:

--- a/andersl-cmake-font-lock.el
+++ b/andersl-cmake-font-lock.el
@@ -782,7 +782,8 @@ To activate this every time a CMake file is opened, use the following:
   (if (not font-lock-mode)
       (andersl-cmake-font-lock-setup)
     (andersl-cmake-font-lock-setup)
-    (font-lock-refresh-defaults)))
+    (when (fboundp 'font-lock-refresh-defaults)
+      (font-lock-refresh-defaults))))


 (defun andersl-cmake-font-lock-add-keywords (name keywords)

Hi,

Thank you for the really awesome package! It is really great :)

I normally add some custom highlighting of keywords in prog-mode, eg FIXME, TODO. However, when I do that cmake-font-lock won't activate from the cmake-mode-hook, only if I call it manually. My current workaround solution is to not enable the keyword highlighting in cmake-mode:

;; Highlight some keywords in prog-mode
(add-hook 'prog-mode-hook
          (lambda ()
            ;; Highlighting in cmake-mode this way interferes with
            ;; cmake-font-lock, which is something I don't yet understand.
            (when (not (derived-mode-p 'cmake-mode))
              (font-lock-add-keywords
               nil
               '(("\\<\\(FIXME\\|TODO\\|BUG\\|DONE\\)" 1 font-lock-warning-face t)
                 )
               )
              )
            )
          )

So the steps I take are:

1. Start Emacs opening a CMakeLists.txt file
2. Using (message) I deteremined first the prog-mode-hook above is called, then the cmake-mode-hook is called
3. No cmake-font-lock
4. Run M-x cmake-font-lock-activate enables cmake-font-lock

Here is how I set up cmake-mode:

(use-package cmake-mode
  :ensure t
  :mode ("CMakeLists.txt" ".cmake")
  :hook (cmake-mode . (lambda ()
                        (add-to-list 'company-backends 'company-cmake)))
  :config
  (use-package cmake-font-lock
    :ensure t
    :defer t
    :commands (cmake-font-lock-activate)
    :hook (cmake-mode . (lambda ()
                          (message "\nActivating font lock?\n")
                          (cmake-font-lock-activate)))
    )
  )

Do you know why this is happening? It would be useful to note on the README that the above workaround is necessary to get cmake-font-lock to activate properly. :)

Thank you!

Using current master version and a large CMakeLists.txt file, adding a new line starting with set( in the beginning of the file will make emacs use a lot of cpu on each key stroke until the set(...) block is closed.

This make this mode unusable in large projects as each new character typed takes a noticeable time to display (~100-300ms).

It's probably due to a whole buffer look ahead to find the closing ), but it's too costly.

It's easy to reproduce with CMake's own CMakeLists.txt: add a set(bla on the first line, and continue typing new characters.

Hi,
I'm currently working on a new project, which I'm calling extended-cmake-mode to integrate cmake-mode and everything good about this project, and build on them to create a true IDE experience. I was looking to include this project as a dependency, but it looks like the project isn't on MELPA. I was wondering if you were willing to either team up with me and bring the features from here to extended-cmake-mode, or submit a recipe to MELPA.

Thanks

Hi,
When I use cmake-font-lock along with rainbow-delimiters, cmake-font-lock does not have any visible effect on the buffer. When rainbow-delimiters is disabled I recover correct coloring.

Here is a minimal setup with use-package

(use-package rainbow-delimiters
  :ensure t
  :hook (prog-mode . rainbow-delimiters-mode))

(use-package cmake-mode
  :ensure t)

(use-package cmake-font-lock
  :ensure t
  :hook (cmake-mode . cmake-font-lock-activate))

1. Would it be easy to fix ?
2. Have you even considered pushing your changes to the kitware cmake-mode.el ? This is really enjoyable to have this coloring.

Thanks

Hi, I'm not sure if this is expected behavior from font-lock or there's something wrong with my setup. The issue I noticed is that, font-lock-mode is only t when I open a file in cmake-mode for the first time. For subsequent files opened in cmake-mode, font-lock-mode is nil, so, font-lock-refresh-defaults is not called. Font locking still works normally,font-lock-mode is only nil during the execution of cmake-mode-hook, it is t when I manually check after loading has finished.

Since all font-lock-refresh-defaults does is killing the local variable font-lock-set-defaults, I've modified the function cmake-font-lock-activate as follow and everything now works as expected.

(defun cmake-font-lock-activate ()
  "Activate advanced CMake colorization.

To activate this every time a CMake file is opened, use the following:

    (add-hook 'cmake-mode-hook 'cmake-font-lock-activate)"
  (interactive)
  (cmake-font-lock-setup)
  (when (boundp 'font-lock-set-defaults)
    (kill-local-variable 'font-lock-set-defaults))
  (when (and (boundp 'font-lock-mode) font-lock-mode)
    (font-lock-mode -1)
    (font-lock-mode 1)))

For example, in

install(DIRECTORY ./
  DESTINATION ${INSTALL_MODULES_DIR}
  COMPONENT Development
  FILES_MATCHING PATTERN *.cmake)

only DIRECTORY and DESTINATION are properly font locked. Others, COMPONENT, FILES_MATCHING, and PATTERN, are not font locked. However, if I enclose variable expansion into quotes, i.e.

install(DIRECTORY ./
  DESTINATION "${INSTALL_MODULES_DIR}"
  COMPONENT Development
  FILES_MATCHING PATTERN *.cmake)

all keywords are font locked properly. Although, I didn't study the implementation in details, I tend to think that if this is not a bug but at least an unintended side effect. What blocks the current implementation from mitigating this problem on variable expansions? Instead of " as anchors, one has ${ and }. I've read the second problem in README but it makes little sense to me in this case.

I'm no expert on Emacs font-lock implementations, but it feels to me like there's some overlap between cmake-font-lock-function-keywords-alist and cmake-font-lock-function-signatures.

I feel like function-signatures is (or would be if it was complete) a superset of the information in keywords-alist, in that if all the function-signatures were completed then all the keywords would be specified by the function signatures. Is there a reason to keep two separate settings?

This mainly came up for me because while adding keywords for my recent pull request I found myself adding the PERMISSIONS keywords for the install() command, which has syntax like:
install(... PERMISSIONS OWNER_READ OWNER_WRITE ...)
I was thinking that while PERMISSIONS is a keyword, the options such as OWNER_READ etc. might be better font-locked as a different type of thing. Maybe a property font or something like that.

So I looked further and found function-signatures where I could define the entire syntax of the function... but then I got confused about what the distinction is between these two and when one should use one versus the other, and why there are even two of them when it seems like if all functions were fully specified by function-signatures then why do we need function-keywords?

So I thought I'd ask 😄

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.