CMake/Editors/Emacs: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
(→‎Modes: Add company-mode link)
(Added information about the Emacs package andersl-cmake-font-lock)
Line 15: Line 15:
(autoload 'cmake-mode "~/CMake/Docs/cmake-mode.el" t)
(autoload 'cmake-mode "~/CMake/Docs/cmake-mode.el" t)
</pre>
</pre>
== andersl-cmake-font-lock ==
The package [https://github.com/Lindydancer/cmake-font-lock andersl-cmake-font-lock] provides advanced font-lock support for CMake scripts.
Although the standard package have some syntax coloring support, this package raises the bar quite a bit. The main new feature is that arguments are colored according what type they are (the package is aware of all standard CMake functions, and can easily be extended with other functions).
The following is a list of things that are colored (taken from the
documentation):
* Comments and quoted strings.
* Special functions like <code>if</code>, <code>while</code>, <code>function</code>, and <code>include</code> are colored as font-lock <em>keywords</em> (not to be confused with keywords in the CMake sense).
* Other function name are colored as, well, <em>functions</em>.
* The arguments of functions are colored according to the type, as specified by the function <em>signature</em>. The built-in signatures can color an arguments as a <em>variable</em>, a <em>function</em>, a <em>property</em>, a <em>target</em>, a <em>policy</em>, and finally a CMake keyword is colored as a <em>type</em>.
* The constants <code>true</code>, <code>false</code>, <code>yes</code>, <code>no</code>, <code>y</code>, <code>n</code>, <code>on</code>, and <code>off</code> are colored as <em>constants</em>.
* <code>${...}</code> constructs are fontified as <em>variables</em>. Nested constructs are supported.
* For <code>$ENV{...}</code>, <code>ENV</code> is fontified as a <em>variable</em> and the content as a <em>constant</em>.
* For <code>$<name:...></code> constructs, <code>name</code> is colored as a <em>constant</em>.
* For preprocessor definitions like <code>-DNAME</code>, <code>NAME</code> is colored as a <em>constant</em>.


== company-mode ==
== company-mode ==

Revision as of 03:48, 7 May 2013

Modes

cmake-mode

See the combined syntax highlighting and indentation mode in the CMake source tree. To enable it, add the following to your .emacs file:

; Add cmake listfile names to the mode list.
(setq auto-mode-alist
	  (append
	   '(("CMakeLists\\.txt\\'" . cmake-mode))
	   '(("\\.cmake\\'" . cmake-mode))
	   auto-mode-alist))

(autoload 'cmake-mode "~/CMake/Docs/cmake-mode.el" t)

andersl-cmake-font-lock

The package andersl-cmake-font-lock provides advanced font-lock support for CMake scripts.

Although the standard package have some syntax coloring support, this package raises the bar quite a bit. The main new feature is that arguments are colored according what type they are (the package is aware of all standard CMake functions, and can easily be extended with other functions).

The following is a list of things that are colored (taken from the documentation):

  • Comments and quoted strings.
  • Special functions like if, while, function, and include are colored as font-lock keywords (not to be confused with keywords in the CMake sense).
  • Other function name are colored as, well, functions.
  • The arguments of functions are colored according to the type, as specified by the function signature. The built-in signatures can color an arguments as a variable, a function, a property, a target, a policy, and finally a CMake keyword is colored as a type.
  • The constants true, false, yes, no, y, n, on, and off are colored as constants.
  • ${...} constructs are fontified as variables. Nested constructs are supported.
  • For $ENV{...}, ENV is fontified as a variable and the content as a constant.
  • For $<name:...> constructs, name is colored as a constant.
  • For preprocessor definitions like -DNAME, NAME is colored as a constant.

company-mode

See company-mode and its completion backend for CMake scripts.

User Suggestions

Buffer Names

I've been long irritated with having to deal with multiple buffers all name CMakeLists.txt. Emacs by default will call them CMakeLists.txt, CMakeLists.txt<2>, CMakeLists.txt<3>, etc.. This is really hard to switch back and forth when the buffer names are difficult to associate with location.

I've found a couple of solutions to this problem.

  1. Use uniquify emacs package. This gives several options to automatically rename buffers based on their location on disk.
    ;; uniquify.el is a helper routine to help give buffer names a better unique name.
    (when (load "uniquify" 'NOERROR)
      (require 'uniquify)
      (setq uniquify-buffer-name-style 'forward)
      ;(setq uniquify-buffer-name-style 'post-forward)
      )
    
  2. Rename the buffer as part of the cmake-mode
    (defun cmake-rename-buffer ()
      "Renames a CMakeLists.txt buffer to cmake-<directory name>."
      (interactive)
      ;(print (concat "buffer-filename = " (buffer-file-name)))
      ;(print (concat "buffer-name     = " (buffer-name)))
      (when (and (buffer-file-name) (string-match "CMakeLists.txt" (buffer-name)))
          ;(setq file-name (file-name-nondirectory (buffer-file-name)))
          (setq parent-dir (file-name-nondirectory (directory-file-name (file-name-directory (buffer-file-name)))))
          ;(print (concat "parent-dir = " parent-dir))
          (setq new-buffer-name (concat "cmake-" parent-dir))
          ;(print (concat "new-buffer-name= " new-buffer-name))
          (rename-buffer new-buffer-name t)
          )
      )
    
    (add-hook 'cmake-mode-hook (function cmake-rename-buffer))
    

I actually prefer renaming my buffers with my cmake-rename-buffer function, because the buffer names start with a lower case letter. :)