What is the difference between ; and ;; when starting a comment in Clojure? I see that my text editor colours them differently, so I'm assuming there is notionally some difference.
I also see that Marginalia treats them differently:
; Stripped entirely
;; Appears in text section of marginalia
(defn foobar []
; Appears in code section of marginalia output
;; Again, appears in code section of marginalia output
6)
There is no difference as far as the interpreter is concerned. Think of ; ;; ;;; and ;;;; as different heading levels.
Here is my personal use convention:
;;;; Top-of-file level comments, such as a description of the whole file/module/namespace
;;; Documentation for major code sections (i.e. groups of functions) within the file.
;; Documentation for single functions that extends beyond the doc string (e.g. an explanation of the algorithm within the function)
; In-line comments possibly on a single line, and possibly tailing a line of code
Check out the official description of the meaning of ; vs ;; in elisp: since the Clojure indenter is basically the same, it will treat them similarly. Basically, use ; if you are writing a long sentence/description "in the margins" that will span multiple lines but should be considered a single entity. Their example is:
(setq base-version-list ; there was a base
(assoc (substring fn 0 start-vn) ; version to which
file-version-assoc-list)) ; this looks like
; a subversion
The indenter will make sure those stay lined up next to each other. If, instead, you want to make several unrelated single-line comments next to each other, use ;;.
(let [x 99 ;; as per ticket #425
y "test"] ;; remember to test this
(str x y)) ;; TODO actually write this function
Emacs ; to be used for end-of-line comments and will indent in surprising ways if that is not your intent. ;; does not so I usually use ;;.
Clojure doesn't care - any line is ignored from the ; to EOL.
I believe there is a tradition in CL of using increasing numbers of ; to indicate more important comments/sections.
no meaning for the language. ; is a reader macro for comment
perhaps other tools parse them but "within clojure" they are the same.
There is no difference from a Clojure-perspective. I find that ;; stands out a little better than ;, but that's only my opinion.
Marginalia on the other hand treats them differently because there are times when a comment should remain in the code section (e.g. license) and those are flagged with ;. This is an arbitrary decision and may change in the future.
In emacs lisp modes including clojure-mode, ;; is formatted with the convention of being at the beginning of a line, and indented as as any other line, based on the context. ; is expected to be used at the end of a line, so emacs will not do what you want it to if you put a single-semicolon comment at the beginning of a line expecting it to tab to the indentation for the present context.
Example:
(let [foo 1]
;; a comment
foo) ; a comment
I'm not sure (not used Clojure and never heard of this before), but this thread might help.
Related
Since version 22 of Emacs, we can use \,(function) for manipualting (parts of) the regex-search result before replacing it. But – this is mentioned often, but nonetheless still the truth – we can use this construct only in the standard interactive way. (Interactive like: By pressing C-M-% or calling query-replace-regexp with M-x.)
As an example:
If we have
[Foo Bar 1900]
and want to get
[Foo Bar \function{foo1900}{1900}]
we can use:
M-x query-replace-regexp <return>
\[\([A-Za-z-]+\)\([^0-9]*\) \([0-9]\{4\}\)\]
[\1\2 \\function{\,(downcase \1)\3}{\3}]
to get it done. So this can be done pretty easy.
In my own defun, I can use query only by replacing without freely modifying the match, or modify the prepared replaced string without any querying. The only way I see, is to serialize it in such a way:
(defun form-to-function ()
(interactive)
(goto-char (point-min))
(while (query-replace-regexp
"\\[\\([A-Za-z-]+\\)\\([^0-9]*\\) \\([0-9]\\{4\\}\\)\\]"
"[\\1\\2 \\\\function{\\1\\3}{\\3}]" ))
(goto-char (point-min))
(while (search-forward-regexp "\\([a-z0-9]\\)" nil t)
(replace-match (downcase (match-string 1)) t nil)
)
)
For me the query is important, because I can't be sure, what the buffer offers me (= I can't be sure, the author used this kind of string always in the same manner).
I want to use an elisp function, because it is not the only recurring replacement (and also not only one buffer (I know about dired-do-query-replace-regexp but I prefer working buffer-by-buffer with replace-defuns)).
At first I thought I only miss something like a query-replace-match to use instead of replace-match. But I fear, I am also missing the easy and flexible way of rearrange the string the the query-replace-regexp.
So I think, I need a \, for use in an defun. And I really wonder, if I am the only one, who is missing this feature.
If you want your rsearch&replace to prompt the user, that means you want it to be interactive, so it's perfectly OK to call query-replace-regexp (even if the byte-compiler will tell you that this is meant for interactive use only). If the warning bothers you, you can either wrap the call in with-no-warnings or call perform-replace instead.
The docstring of perform-replace sadly doesn't (or rather "didn't" until today) say what is the format of the replacements argument, but you can see it in the function's code:
;; REPLACEMENTS is either a string, a list of strings, or a cons cell
;; containing a function and its first argument. The function is
;; called to generate each replacement like this:
;; (funcall (car replacements) (cdr replacements) replace-count)
;; It must return a string.
The query-replace-function can handle replacement not only as a string, but as a list including the manipulating elements. The use of concat archives building an string from various elements.
So one who wants to manipulate the search match by a function before inserting the replacement can use query-replace-regexp also in a defun.
(defun form-to-function ()
(interactive)
(goto-char (point-min))
(query-replace-regexp
"\\[\\([A-Za-z-]+\\)\\([^0-9]*\\) \\([0-9]\\{4\\}\\)\\]"
(quote (replace-eval-replacement concat "[\\1\\2 \\\\function{"
(replace-quote (downcase (match-string 1))) "\\3}{\\3}]")) nil ))
match-string 1 returns the first expression of our regexp-search.
`replace-quote' helps us doublequoting the following expression.
concat forms a string from the following elements.
and
replace-eval-replacement is not documented.
Why it is in use here nevertheless, is because of emacs seems to use it internally, while performing the first »interactive« query-replace-regexp call. At least is it given by asking emacs with repeat-complex-command.
I came across repeat-complex-command (bound to [C-x M-:].) while searching for an answer in the source code of query-replace-regexp.
So an easy to create defun could be archieved by performing the standard search and replace way as told in the question and after first sucess pressing [C-x M-:] results in an already Lisp formed command, which can be copied and pasted in a defun.
Edit (perform-replace)
As Stefan mentioned, one can use perform-replace to avoid using query-replace-regexp.
Such a function could be:
(defun form-to-function ()
(interactive)
(goto-char (point-min))
(while (perform-replace
"\\[\\([A-Za-z-]+\\)\\([^0-9]*\\) \\([0-9]\\{4\\}\\)\\]"
(quote (replace-eval-replacement concat "[\\1\\2 \\\\function{"
(replace-quote (downcase (match-string 1))) "\\3}{\\3}]"))
t t nil)))
The first boolean (t) is a query flag, the second is the regexp switch. So it works also perfectly, but it didn't help finding the replacement expression as easy as in using \,.
Various Clojure style guides recommend avoiding lines longer than 80 characters. I am wondering if there is an idiomatic way to avoid long String literals.
While it's common these days to have wide screens, I still agree that long lines should be avoided.
Here are some examples (I'm tempted to follow the first):
;; break the String literal with `str`
(println (str
"The quick brown fox "
"jumps over the lazy dog"))
;; break the String literal with `join`
(println (join " " [
"The quick brown fox"
"jumps over the lazy dog"]))
I am aware that Clojure supports multi-line String literals, but using this approach has the undesired effect of the newline characters being interpreted, e.g. using the repl:
user=> (println "The quick brown fox
#_=> jumps over the lazy dog")
The quick brown fox
jumps over the lazy dog
You should probably store the string inside an external text file, and read the file from your code. If you still feel the need to store the string in your code, go ahead and use str.
EDIT:
As requested, I will demonstrate how you can read long strings at compile time.
(defmacro compile-time-slurp [file]
(slurp file))
Use it like this:
(def long-string (compile-time-slurp "longString.txt"))
You may invent similar macros to handle Java Properties files, XML/JSON configuration, SQL queries, HTML, or whatever else you need.
I find it convenient to use str to create strings and use character literals such as \newline or \tab instead of "\n" to break them.
I rarely violate the 80-column rule this way.
The most idiomatic ways I know of are the following:
1) Use (str) to split the string over multiple lines.
(str "User " (:user context)
" is now logged in.")
This is probably the most idiomatic usage. I've seen this done in multiple libraries and projects. It is fast, since (str) uses a StringBuilder under the hood. It also allows you to mix code in transparently, as I've done in the example.
2) Allow strings to break the 80 char limit by themselves, when it makes sense.
(format
"User %s is now logged in."
(:user context))
Basically, it's ok to break the 80 char limit for strings. Chances are it's less likely you care about reading the string when you work with the code, and on the off chance you need to, exceptionally, you'll need to scroll horizontally.
I've wrapped the string in a (format) here to be able to inject code similarly to my previous example. You don't need to.
Less idiomatic ways would be:
3) Put your strings in files and load them from there.
(slurp "/path/to/userLoggedIn.txt")
With a file: /path/to/userLoggedIn.txt containing:
User logged in.
I advise against this because:
It introduces IO side effects
It has the potential to fail, say the path is wrong, the resource is missing or corrupted, the disk errors, etc.
It has performance implications, disk reads are slow.
Its hard to inject content from code if you need too.
I would say do this only if your text is really big. Or if the content of the string needs to be changed by non devs. Or if the content is obtained externally.
4) Have a namespace where you def all your strings in, and load them from there.
(ns msgs)
(defn logged-in-msg [user]
(format
"User %s is now logged in."
user))
Which you then use like this:
(msgs/logged-in-msg (:user context))
I prefer this over #3. You still need to allow to use #2 here, where it's ok to have strings break the 80 char limit. In fact, here you put strings by themselves on a line, so they are easy to format. If you use code analysis like checkstyle, you can exclude this file from the rule. It also does not suffer from the issues of #3.
If you are going with #3 or #4, you probably have a special use case for your strings, like internationalization, or having business edit them, etc. In those cases, you might be better served building a more robust solution, that could be inspired from the above methods, or using a library that specializes in those use cases.
(defmacro strs
([]
"")
([a]
(if (string? a) `~a `(str ~a)))
([a & more]
`(str
~#(->> (cons a more)
(partition-by string?)
(mapcat #(if (string? (first %)) (cons (apply str %) nil) %))))))
Usage:
(strs "one "
"two "
3
" four" " five")
; => "one two 3 four five"
Neighbouring literal strings will be concatenated at compile time.
My code is a mess many long lines in this language like the following
(defn check-if-installed[x] (:exit(sh "sh" "-c" (str "command -v " x " >/dev/null 2>&1 || { echo >&2 \"\"; exit 1; }"))))
or
(def Open-Action (action :handler (fn [e] (choose-file :type :open :selection-mode :files-only :dir ListDir :success-fn (fn [fc file](setup-list file)))) :name "Open" :key "menu O" :tip "Open spelling list"))
which is terrible. I would like to format it like so
(if (= a something)
(if (= b otherthing)
(foo)))
How can I beautify the source code in a better way?
The real answer hinges on whether you're willing to insert the newlines yourself. Many systems
can indent the lines for you in an idiomatic way, once you've broken it up into lines.
If you don't want to insert them manually, Racket provides a "pretty-print" that does some of what you want:
#lang racket
(require racket/pretty)
(parameterize ([pretty-print-columns 20])
(pretty-print '(b aosentuh onethunoteh (nte huna) oehnatoe unathoe)))
==>
'(b
aosentuh
onethunoteh
(nte huna)
oehnatoe
unathoe)
... but I'd be the first to admit that inserting newlines in the right places is hard, because
the choice of line breaks has a lot to do with how you want people to read your code.
I use Clojure.pprint often for making generated code more palatable to humans.
it works well for reporting thought it is targeted at producing text. The formatting built into the clojure-mode emacs package produces very nicely formatted Clojure if you put the newlines in your self.
Now you can do it with Srefactor package.
Some demos:
Formatting whole buffer demo in Emacs Lisp (applicable in Common Lisp as well).
Transform between one line <--> Multiline demo
Available Commands:
srefactor-lisp-format-buffer: format whole buffer
srefactor-lisp-format-defun: format current defun cursor is in
srefactor-lisp-format-sexp: format the current sexp cursor is in.
srefactor-lisp-one-line: turn the current sexp of the same level into one line; with prefix argument, recursively turn all inner sexps into one line.
Scheme variants are not as polished as Emacs Lisp and Common Lisp yet but work for simple and small sexp. If there is any problem, please submit an issue report and I will be happy to fix it.
When entering code Emacs transiently highlights the matching brace or bracket. With existing code however is there a way to ask it to highlight a matching brace or bracket if I highlight its twin?
I am often trying to do a sanity check when dealing with compiler errors and warnings. I do enter both braces usually when coding before inserting the code in between, but have on occasion unintentionally commented out one brace when commenting out code while debugging.
Any advice with dealing with brace and bracket matching with Emacs?
OS is mostly Linux/Unix, but I do use it also on OS X and Windows.
If you're dealing with a language that supports it, give ParEdit a serious look. If you're not using with a Lisp dialect, it's not nearly as useful though.
For general brace/bracket/paren highlighting, look into highlight-parentheses mode (which color codes multiple levels of braces whenever point is inside them). You can also turn on show-paren-mode through customizations (that is M-x customize-variable show-paren-mode); that one strongly highlights the brace/bracket/paren matching one at point (if the one at point doesn't match anything, you get a different color).
my .emacs currently contains (among other things)
(require 'highlight-parentheses)
(define-globalized-minor-mode global-highlight-parentheses-mode highlight-parentheses-mode
(lambda nil (highlight-parentheses-mode t)))
(global-highlight-parentheses-mode t)
as well as that show-paren-mode customization, which serves me well (of course, I also use paredit when lisping, but these are still marginally useful).
Apart from the answer straight from the manual or wiki, also have a look at autopair.
tried on emacs 26
(show-paren-mode 1)
(setq show-paren-style 'mixed)
enable showing parentheses
set the showing in such as highlit the braces char., or if either one invisible higlight what they enclose
for toggling the cursor position / point between both, put this script in .emacs
(defun swcbrace ()(interactive)
(if (looking-at "(")(forward-list)
(backward-char)
(cond
((looking-at ")")(forward-char)(backward-list))
((looking-at ".)")(forward-char 2)(backward-list))
)))
(global-set-key (kbd "<C-next>") 'swcbrace)
it works toggling by press Control-Pgdn
BTW, for the immediate question: M-x blink-matching-open will "re-blink" for an existing close paren, as if you had just inserted it. Another way to see the matching paren is to use M-C-b and M-C-f (which jump over matched pairs of parens), which are also very useful navigation commands.
I second ParEdit. it is very good atleast for lisp development.
FWIW I use this function often to go to matching paren (back and forth).
;; goto-matching-paren
;; -------------------
;; If point is sitting on a parenthetic character, jump to its match.
;; This matches the standard parenthesis highlighting for determining which
;; one it is sitting on.
;;
(defun goto-matching-paren ()
"If point is sitting on a parenthetic character, jump to its match."
(interactive)
(cond ((looking-at "\\s\(") (forward-list 1))
((progn
(backward-char 1)
(looking-at "\\s\)")) (forward-char 1) (backward-list 1))))
(define-key global-map [(control ?c) ?p] 'goto-matching-paren) ; Bind to C-c p
Declaimer: I am NOT the author of this function, copied from internet.
If you just want to check the balanced delimiters, be them parentheses, square brackets or curly braces, you can use backward-sexp (bound to CtrlAltB) and forward-sexp (bound to CtrlAltF) to skip backward and forward to the corresponding delimiter. These commands are very handy to navigate through source files, skipping structures and function definitions, without any buffer modifications.
You can set the below in your init.el:
(setq show-paren-delay 0)
(show-paren-mode 1)
to ensure matching parenthesis are highlighted.
Note that (setq show-paren-delay 0) needs to be set before (show-paren-mode 1) so that there's no delay in highlighting, as per the wiki.
If you want to do a quick check to see whether brackets in the current file are balanced:
M-x check-parens
Both options tested on Emacs 27.1
I'm running Emacs 23.3.1 (Ubuntu, Oneiric package) and emacs doesn't appear to understand any of the new C++11 keywords, constexpr, thread_local, etc. Also it doesn't understand that '>>' is now permitted in template parameters, or the new 'enum class' syntax. Is there an updated or alternative module somewhere? Or failing that, some settings to make emacs more C++11 friendly in the mean time?
Well, I'm using 24.1. Some C++98 keywords are missing, and all new C++11 keywords. It does not even fontify number constants. It seems as if c++-mode hasn't been updated for a decade.
I'm using the following code for a long time now, and recently added C++11 keywords. Try putting it in your .emacs; it should fill some holes.
(require 'font-lock)
(defun --copy-face (new-face face)
"Define NEW-FACE from existing FACE."
(copy-face face new-face)
(eval `(defvar ,new-face nil))
(set new-face new-face))
(--copy-face 'font-lock-label-face ; labels, case, public, private, proteced, namespace-tags
'font-lock-keyword-face)
(--copy-face 'font-lock-doc-markup-face ; comment markups such as Javadoc-tags
'font-lock-doc-face)
(--copy-face 'font-lock-doc-string-face ; comment markups
'font-lock-comment-face)
(global-font-lock-mode t)
(setq font-lock-maximum-decoration t)
(add-hook 'c++-mode-hook
'(lambda()
(font-lock-add-keywords
nil '(;; complete some fundamental keywords
("\\<\\(void\\|unsigned\\|signed\\|char\\|short\\|bool\\|int\\|long\\|float\\|double\\)\\>" . font-lock-keyword-face)
;; add the new C++11 keywords
("\\<\\(alignof\\|alignas\\|constexpr\\|decltype\\|noexcept\\|nullptr\\|static_assert\\|thread_local\\|override\\|final\\)\\>" . font-lock-keyword-face)
("\\<\\(char[0-9]+_t\\)\\>" . font-lock-keyword-face)
;; PREPROCESSOR_CONSTANT
("\\<[A-Z]+[A-Z_]+\\>" . font-lock-constant-face)
;; hexadecimal numbers
("\\<0[xX][0-9A-Fa-f]+\\>" . font-lock-constant-face)
;; integer/float/scientific numbers
("\\<[\\-+]*[0-9]*\\.?[0-9]+\\([ulUL]+\\|[eE][\\-+]?[0-9]+\\)?\\>" . font-lock-constant-face)
;; user-types (customize!)
("\\<[A-Za-z_]+[A-Za-z_0-9]*_\\(t\\|type\\|ptr\\)\\>" . font-lock-type-face)
("\\<\\(xstring\\|xchar\\)\\>" . font-lock-type-face)
))
) t)
Hope this helps.
According to a request by Mike Weller here an updated version for C++11 strings literals (incl. user-defined literals).
(add-hook
'c++-mode-hook
'(lambda()
;; We could place some regexes into `c-mode-common-hook', but note that their evaluation order
;; matters.
(font-lock-add-keywords
nil '(;; complete some fundamental keywords
("\\<\\(void\\|unsigned\\|signed\\|char\\|short\\|bool\\|int\\|long\\|float\\|double\\)\\>" . font-lock-keyword-face)
;; namespace names and tags - these are rendered as constants by cc-mode
("\\<\\(\\w+::\\)" . font-lock-function-name-face)
;; new C++11 keywords
("\\<\\(alignof\\|alignas\\|constexpr\\|decltype\\|noexcept\\|nullptr\\|static_assert\\|thread_local\\|override\\|final\\)\\>" . font-lock-keyword-face)
("\\<\\(char16_t\\|char32_t\\)\\>" . font-lock-keyword-face)
;; PREPROCESSOR_CONSTANT, PREPROCESSORCONSTANT
("\\<[A-Z]*_[A-Z_]+\\>" . font-lock-constant-face)
("\\<[A-Z]\\{3,\\}\\>" . font-lock-constant-face)
;; hexadecimal numbers
("\\<0[xX][0-9A-Fa-f]+\\>" . font-lock-constant-face)
;; integer/float/scientific numbers
("\\<[\\-+]*[0-9]*\\.?[0-9]+\\([ulUL]+\\|[eE][\\-+]?[0-9]+\\)?\\>" . font-lock-constant-face)
;; c++11 string literals
;; L"wide string"
;; L"wide string with UNICODE codepoint: \u2018"
;; u8"UTF-8 string", u"UTF-16 string", U"UTF-32 string"
("\\<\\([LuU8]+\\)\".*?\"" 1 font-lock-keyword-face)
;; R"(user-defined literal)"
;; R"( a "quot'd" string )"
;; R"delimiter(The String Data" )delimiter"
;; R"delimiter((a-z))delimiter" is equivalent to "(a-z)"
("\\(\\<[uU8]*R\"[^\\s-\\\\()]\\{0,16\\}(\\)" 1 font-lock-keyword-face t) ; start delimiter
( "\\<[uU8]*R\"[^\\s-\\\\()]\\{0,16\\}(\\(.*?\\))[^\\s-\\\\()]\\{0,16\\}\"" 1 font-lock-string-face t) ; actual string
( "\\<[uU8]*R\"[^\\s-\\\\()]\\{0,16\\}(.*?\\()[^\\s-\\\\()]\\{0,16\\}\"\\)" 1 font-lock-keyword-face t) ; end delimiter
;; user-defined types (rather project-specific)
("\\<[A-Za-z_]+[A-Za-z_0-9]*_\\(type\\|ptr\\)\\>" . font-lock-type-face)
("\\<\\(xstring\\|xchar\\)\\>" . font-lock-type-face)
))
) t)
In the above implementation of user-defined strings literals, the delimiter tags are marked up separately as font-lock-keyword-face; another option would be font-lock-constant-face. This implementation is not as efficient as it could be; but it works and does not slow down Emacs. Note that the regexps for user-defined strings literals have not been "stolen" from somehere; so I hope they work. Any comments are welcome.
If you like to fontify the whole literal string as font-lock-string-face - including the delimiters - replace the three regexps by just one. Like this one:
.
.
("\\<\\([uU8]*R\"[^\\s-\\\\()]\\{0,16\\}(.*?)[^\\s-\\\\()]\\{0,16\\}\"\\)\\>" 1 font-lock-string-face t)
Have fun.
Have a look at the package : "Modern C++" font-lock for Emacs. It is also available on Melpa.
Syntax highlighting support for "Modern C++" - until C++17 and
Technical Specification. This package aims to provide a simple
highlight of the C++ language without dependency.
It is recommended to use it in addition with the c++-mode major mode
for extra highlighting (user defined types, functions, etc.) and
indentation.
I am the maintainer of this minor mode. Any feedback is appreciated.
Replacing Andreas' floating point regexp with this will improve hilighting of floats.
integer/float/scientific literals
("\\<[-+]?[0-9]*\\.?[0-9]+\\([uUlL]+\\|[eE][-+]?[0-9]+\\)?[fFlL]?\\>" . font-lock-constant-face)
Hope that helps someone.
I've checked trunk version, cc-mode hasn't been updated yet, and AFAIK there's no alternative. If you really want it, but don't want to get your hands dirty, you should pay someone to implement it for you...
For me, the two most pressing pain points with font-locking of modern C++ code have been
the fact that auto is highlighted as a keyword (and not a type) and thus the following identifier would normally not higlight as a variable declaration, and
that highlighting simply goes crazy when presented with some code (for an example, try rtags' src/ClangIndexer.cpp) and then e.g fails to highlight top-level constructs such as function definitions.
After a bit of experimentation, I arrived at a solution that works well for me and addresses both points.
The first one is achieved by modifying lisp/progmodes/cc-langs.el (copying to one's load-path and then modifying also works) to remove "auto" from
(c-lang-defconst c-modifier-kwds
"Keywords that can prefix normal declarations of identifiers
and add it to c++-font-lock-extra-types (e.g. via Customize).
For the second one, emptying c++-font-lock-extra-types (except for keeping "auto") helps.