How do I best use common-lisp in elisp (if at all)? - emacs

Can someone please explain what the specific issues are with using the cl package in elisp? As a new coder in emacs I feel as though I'm making a mistake whenever I reach for the (require 'cl) option. I have read and understood the byte-compilation issue with the cl package. I have looked at the old arguments and have no wish to revive them. I am also not looking for any generalist comment on whether common-lisp is better than x brand lisp.
What I would like to know is practically how to use common-lisp so that any elisp I write will have a good chance of being accepted by the majority of elisp coders. Specifically, should I avoid using common lisp entirely, or are there some parts of the language that are acceptable to everyone and some parts where a good majority of coders would snigger and scoff at?
Without wishing to limit the breadth of the answer, is this:
(mapcar (lambda(x) (* x x)) '(1 2 3))
much more acceptable than this:
(require 'cl)
(loop for el in '(1 2 3) collect (* el el))

While using a lot of third-party libraries and writing some of my own eLisp code, I never encountered the situation when using CL package resulted in a name conflict. So, I'd be tempted to say that the argument against using CL is nothing but puritanism (in the original sense of the word, not meaning the religious side of things).
But, if you are planning on a very long time support and you want to have some sort of a backup, here's what I would do (but I'm not doing that myself, because fixing things once they are broken seems to be a better tactic). For the functions in CL package that you are using, create a special file, where you defalias all of them to have a cl- prefix. So, for example, instead of having a (position ...) you would have (cl-position ...). Theoretically will save you the problem of forward compatibility. However functions don't get removed instantly, you'll get a warning ahead of time of them being deprecated, and will have a lot of time to update. Up to you, really.
Loop macro in Common Lisp is a controversy all by itself, it is not a typical construct for the language and that's why, for example, the iterate library exists. It also requires that you learn "the loop mini-language" to use it well, which is sort of a small domain-specific language, and there's really no requirement that this kind of construct use one. BUT, loop has its strong sides. List processing functions such as mapcar or reduce will serve you well in more trivial cases, like the one you have in your example, but in the less trivial cases loop is going to be a better and also less verbose way of doing the same thing.

Have you read the macros section of the manual? Using macros such as your loop example is perfectly okay.
But you would use eval-when-compile around the require.
In fact (eval-when-compile (require 'cl)) appears 66 times just in the root lisp folder in my Emacs.

Unless you plan to integrate your code in Emacs use the CL package, and put this snippet in your .emacs to disable the warnings.
(byte-compile-disable-warning 'cl-functions)
Note: You can find some advices on elisp programming on nicferrier's blog.

Related

what should be auto-loaded in emacs libraries?

Emacs allows you to "autoload" functions with little cookies like ;;;###autoload
Is there any consensus on what should be autoloaded though? For example, does it make sense to autoload every interactive function in a module (suppose there are a lot of them, e.g. 50)? Or, does it make sense to only autoload the "main" ones.
You only autoload the "main" ones. For example, python-mode.el only has a few occurances of autoload:
;;;###autoload
(add-to-list 'auto-mode-alist (cons (purecopy "\\.py\\'") 'python-mode))
;;;###autoload
(add-to-list 'interpreter-mode-alist (cons (purecopy "python[0-9.]*") 'python-mode))
--
;;;###autoload
(defun run-python (cmd &optional dedicated show)
--
;;;###autoload
(define-derived-mode python-mode prog-mode "Python"
Only the "entry" functions are autoloaded. The dozens of helper functions are only needed once you're already in python-mode.
There are several possible scenarios here, and the answer will depend on which one you are working with.
The simple and obvious situation is with a library with a lot of interactive functions but only a few "main" entry points. The version control modes for Emacs are good examples -- there are many ways to interact with the version control back end, but the first step will usually happen when you check out a piece of code from version control, or want to examine what changes you have made in order to start committing. So these are the main entry points, and the others will be useful only when you start one of these operations (at least in the typical case).
A somewhat likely but unfortunate scenario would be a "module" which really is many small modules who want to be modules of their own. If internal cohesion is weak, maybe you should think about moving some parts of the code into separate, smaller libraries. (There are Emacs libraries which ship with the distribution which fit this description.)
If you really have a complex problem which requires a lot of different entry points, perhaps in fact you do want to expose them all. Grasping a bit at straws here, I think of e.g. a statistics package -- there are many, many methods to choose from, and you don't know in advance which one will make sense for each scenario. (Typically this sort of behemoth package will require at least a Bachelor's degree in the subject matter to operate properly, though!)

Autocompletion with Emacs and tags

Hi I work on a very large and complex C code base (complex not in a good way). The codebase dwarfs the linux kernel to give you an idea. I have set up emacs to do most of what I want. I get autocompletion on functions and variables but there are certain things which do not work (omni-completion).
I use cedet v2, xgtags, auto-complete, yastnippet, cscope and a few other tools all of which are installed via el-get on emacs-24. When I work on a smaller project, omni-completion in C works so I would get a list of the members of a struct when I access the object. However, in the very large "project", omni-completion does not work when accessing a struct. As I said, I get completion on functions and variables but not on structures.
My explanation is that auto-completion is using its parser which cannot handle the size and complexity of the codebase. However, gtags or etags can handle it.
Is there a way to make auto-complete look into the gtags (xgtags) database? My gtags are working very well indeed.
EDIT:
I am not an admin on my system and I cannot install packages easily. At the moment, I do not have clang. Having said that, I am quite capable of compiling from source and can get many packages this way.
Using clang+automplete is also an option:
http://truongtx.me/2013/03/06/emacs-ccpp-autocomplete-with-clang/
Edit: I see you've edited the question indicating you have no clang. I leave this answer here regardless, in case someone else finds it useful.
Have you tried ac-source-gtags that is comes together with auto-complete package? You can also combine several sources, like described in documentation...
I have found that cedet is really underwhelming.
I would recommend using just one tool which does everything
https://github.com/Andersbakken/rtags
It underlines errors as you type as well as using smart completions. Just add this to your init file after obtaining the required emacs packages
(require 'rtags)
(require 'popup)
(require 'rtags-ac)
(setq rtags-completions-enabled t)
(rtags-enable-standard-keybindings c-mode-base-map)
(add-hook 'c++-mode-hook
(lambda ()
(setq ac-sources '(ac-source-rtags)
)))

how to write scheme program fast in emacs

(define (cube guess x)
(if (good-enough? guess x)
guess
(improve guess x)))
I'm using emacs+Racket, but when I write in Racket,it doesn't auto-complete.
I also can't write the Anti-brackets in the same line,like this
(define (cube guess x) ). I want to use the 'return' key to make the anti-brackets next line, however the scheme interpreter will compute the expression,then it will be wrong.
then if we write the code in the scheme-mode buffer,it may be some bother, we have to
select the region,then compute in another buffer
Anyone tell me some better ways? sorry for my poor English!
It looks to me like you're using an interactive interpreter, and when you hit the "return" key in the middle of a line, it sends the expression to be evaluated rather than allowing you to edit it further. Is this correct? If so, I would encourage you to take a look at Neil Van Dyke's "Quack" package, which (IIRC) is designed to allow you to edit Racket code using emacs.
If you're not married to emacs, then of course I would also suggest trying to use DrRacket.
It sounds like you're using the scheme interpreter from within Emacs. This is a good start for writing small functions, but you really want to use a REPL (Read-Eval-Print Loop) workflow. Thankfully, Emacs has a ready-made scheme REPL built-in, and has been mentioned elsewhere, there are additional modes (like Quack) that enhance the experience.
In the REPL model, you can freely type expressions in the interpreter if you want to try them out, but most of your coding should take place in the file you're writing. From within that buffer, if you have a scheme interpreter running (M-x run-scheme), then you can send sexps to the interpreter for evaluation without copying manually with C-c C-e. You can use C-M-x to do the same thing.
You can compile the entire file with C-c C-k, and if you have several expression you want to send together, grab them in a region and use C-c C-r to send the region to the interpreter.
There are several other commands that make transferring your code to interpreter easy; you can read more about them in your REPL session by pressing C-h m to describe the keybindings for your current mode.
What does this code even do ? Are you missing the "if" ? That could be part of the reason the interpreter isn't working.?
(if (good-enough? guess x) guess (improve guess x))
Sorry if I just don't understand what you are trying to achieve.

When using Icicles in emacs, how do I get *just* the definition with a tag lookup?

In vanilla emacs, I load the TAGS file, and do a lookup of a symbol with "M-.". I go right to the definition of the symbol.
When using Icicles, I get 374 hits for the same symbol. While I can in theory chip away the non-elephant slowly to find what I want, that's a pain, and I end up just turning off icicles for the tag lookup, and turning it back on.
Is there any way to tell icicles that I just want the definition when I do a tags lookup, and not every relevant match in the tags file?
For instance, I might search for the definition of the task_struct structure in the linux kernel source code. I see many definitions of the form:
struct task_struct taskInfo;
struct task_struct info;
but all I want is the one definition:
struct task_struct {
While I can "chip away the non-elephant, the elephants are pretty similar here, and it is hard to tell while looking at the search results that I only want lines with a curly brace after the name, and the curly brace might have been on a different line anyhow, so there is no guarantee even that is the right way to slice the results.
I've also seen member functions of a class appearing when I use Icicles, and I'd like a way to turn them off more easily.
Tried reading the emacs wiki and an internet search, but I didn't have much luck just searching for "emacs icicles tags".
If vanilla M-. does what you want, doesn't icicle-find-first-tag' also do what you want? (Notice the-first'.)
http://www.emacswiki.org/emacs/Icicles_-_Emacs_Tags_Enhancements#icicle-find-first-tag
I don't use icicles, so I don't know if this will actually work, but give it a whirl and let me know.
(defadvice find-tag (around my-thawed-find-tag)
"Disable icicles when finding tags."
(let ((icy-state icy-mode))
(if (not (equal (icy-mode 0)))
(progn
(icy-mode 0)
ad-do-it
(icy-mode icy-state))
ad-do-it)))
(ad-activate 'find-tag)
The advice around find-tag wasn't really what I was looking for. Instead, what I need is a way to get the definition sometimes and references sometimes. I found that cscope and the xcscope.el plugin did what I needed (and CEDET also did something similar to solve my problem)

Lisp style: setq vs. setf

Peter Norvig mentions in Paradigms of Artificial Intelligence Programming, on page 50, the trade off between specificity and consistency and when choosing to use setq or setf to update a variable to a value. What do you recommend? Have you ever run into a situation where it mattered much beyond readability?
Using setq is more low-level, but the performance of setf is not a problem. And setf allows you (or library writers) to provide custom setf behavior, like setting parts of custom data structures. I say: go with setf everywhere unless you have a reason not to.
Also see Practical Common Lisp, chapter 3: "The SETF macro is Common Lisp's main assignment operator." PCL is available online for free: http://gigamonkeys.com/book/
FWIW, I always use setf. If I change the structure of my code slightly, I just need to change the "place" instead of the place and the operator (setq -> setf).
Also, don't worry about performance, setf is exactly the same as setq for symbols:
CL-USER> (macroexpand '(setf foo 42))
(SETQ FOO 42)
You can use setf wherever you could use setq. In fact, setf is actually a macro which builds on setq. So, this should be purely a readability and style issue.
Almost all the code I've seen avoids the use of setq and uses setf.
setf is "set field", it changes a place and can have user extensions.
setq is set with quoting first argument.
I recommend you follow Norvig's final advice in that section: be consistent. 'Readability' is of course the most important reason to make any choice in programming. If it is important to communicate to the reader (perhaps you in 2 months' time) that you are dealing with the entire value cell of a symbol, then use setq; otherwise use setf. But only if you're being consistent.
You will not be wrong if you used setf everywhere instead of setq.
It's the things like this that drags Common Lisp from going forward, lots of unused stuff that implementors still need to support.