CMake/Editors/Emacs: Difference between revisions
(→Modes: Add company-mode link) |
Lindydancer (talk | contribs) (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
, andinclude
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
, andoff
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.
- 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) )
- 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. :)