This short essay discuss the use of camelCase in emacs lisp source code, and some code formatting issues.
Xah Lee wrote:
(in emacs) Sometimes you want to delete the file of the current buffer. How do you do it? Here's a simple command that does it.(defun delete-current-file () "Delete the file associated with the current buffer." (interactive) (let (currentFile) (setq currentFile (buffer-file-name)) (when (yes-or-no-p (concat "Delete file: " currentFile)) (kill-buffer (current-buffer)) (delete-file currentFile) (message (concat "Deleted file: " currentFile)) ) ) )
Thomas Munro wrote:
Why use CamelCase
I find that using camelCase is a good way to distinguish my own symbol names from built-in ones.
Especially because emacs's emacs-lisp-mode's syntax coloring is flawed in that it only color a small percentage of built-in keywords, rather against its own conventions in syntax coloring. For detail, see: Emacs Lisp Mode Syntax Coloring Problem.
Why use SETQ if you don't have to? How about this:(let ((current-file (buffer-file-name))) …
I find that this form:
(let ((var1 val1) (var2 val2) …) body)
is harder to read, especially when not all your vars are not constants or require a lot lisp code to define, example
(let (var1 (var2 (…)) var3 (var4 (…))…) (setq var1 …) … (setq var3 …) …)
where many of the values are themselves compound expressions with many nested parens.
I think it is a good recommendation that one should always use:
(let (var1 var2 var3 …) (setq var1 …) (setq var2 …) … body )
and only use the (var val) form if all the vars are just local constants.
Since you intend to delete the file AND kill the buffer, why not say so in your inline doc?
Yeah, probably better to say in the inline doc. Originally i just deleted the file. But then realized it left a dangling buffer. So i added code to remove buffer…
Though, i don't think stating the fact about also removing buffer is necessarily a good thing. My point of view is that, if you go by emacs tradition and technicality, then yes it should mention that buffer is also removed. However, the emacs tradition here, involving the concept of buffer, a computer engineering-by-product (like floats, int, long), is a major problem. Also, in vast majority of software, or other things involving info presentation, it is more important to communicate to the user than being technically correct.
Also, it could use a space and a question mark (at least the way YES-OR-NO-P works on my system, maybe yours is different). I would have written:
(when (yes-or-no-p (format "Delete file %s and kill buffer? " current-file)) …
you are probably right.
(kill-buffer (current-buffer)) (delete-file currentFile) (message (concat "Deleted file: " currentFile)) ) ) )
Arrgh! My eyes! How about:(kill-buffer (current-buffer)) (delete-file current-file) (message "Deleted file: %s" current-file))))
I might have formatted it the way you did, but just haven't done so.
I consider this trivial, and consider that the common advice and attention for code formatting has done major damage to the computing industry, from wasting programer's time to long-term damage in the growth and direction of computer languages. I've written several articles about this. The key concept is hard-coded formatting vs semantic formatting. The following articles discuss it from various aspects.
In two of the articles, “the Harm of Hard-wrapping Lines” and “Fundamental Problems of Lisp”, it discuss the long-term consequences of focusing on the hard-coded formatting.blog comments powered by Disqus