18

We already have a question about tools useful specifically for testing, but what about actually writing the code? Which packages do you find speed up your development? Which aids do you use to quickly and easily navigate and understand your projects?

Sean Allred
  • 6,861
  • 16
  • 85
  • 3
    This question is very broad and open ended. Many of the packages you listed in your answer can apply to any code development. Also that answer can end up containing a major subset of the packages listed in package manager. If you prefer `multiple-cursors`, someone else might prefer `visual-regexp` or ag/ack/grep from command line or from within emacs or emacs inbuilt `query-replace` or `query-replace-regexp` or something else. Similar arguments can be made for each package. Instead a good question would be asking how to do something specific in "package development". – Kaushal Modi Nov 01 '14 at 14:11
  • @kaushalmodi It's CW, so it was partly my intention to be open-ended. Asking specific questions might be a better way to go about this, but this question would still exist as a collection of those questions. I tried to aim the question specifically at tools that are helpful with lisps and emacs development—`multiple-cursors`, for example, is useful everywhere, but perhaps there are other packages that respect lisp's explicit scoping. Surely `macrostep` and `ielm` aren't applicable *anywhere* else. Bring this up on meta, maybe? – Sean Allred Nov 01 '14 at 14:20
  • @kaushalmodi: good points, but isn't this why it's now a community wiki? Presumably we could edit the answer to flag elisp-specific and development-general packages. – Dan Nov 01 '14 at 14:20
  • It's alright to have a community wiki but I think that this can easily transform into "What are your favorite packages?" CW. Let's take the another generic aspect in your answer: Navigation.. Speedbar, projectile, outshine, orgstruct, g/c/etags, neotree, tabbar, ido, helm and helm plugins, ibuffer, etc – Kaushal Modi Nov 01 '14 at 14:26
  • @kaushalmodi `ido`, `helm`, `ibuffer`, `tabbar`—I don't think—would be appropriate entries. There's nothing that really makes *elisp* development easier. They're surely fantastic packages, but (in my experience) they don't have anything to add to *elisp* development. `etags`—while I'm not familiar with it, sounds like it *would* be appropriate. Perhaps another CW is appropriate for these other packages (because they really do deserve mention), but I fear that your fears for this question would surely be realized in that one. – Sean Allred Nov 01 '14 at 14:30
  • *Just a general notice:* CW does not mean "Let's ask anything". A broad question is always bad, regarless of its wikiness. If people want their CW question to stay open, they should put *all the more effort* into creating the question, **not less**. – Malabarba Nov 02 '14 at 10:46
  • That said. I do not this question here is close-worthy at all. But it could do with a little more construction. – Malabarba Nov 02 '14 at 10:47
  • @Malabarba This has been discussed on TeX.SX and we came to the same conclusion. However, I do recall that in cases of real use to the community, [exceptions](http://tex.stackexchange.com/q/339/17423) were made. One that translates particularly well is [this question](http://tex.stackexchange.com/q/553/17423) about popular packages. That said, TeX.SX is not Emacs.SE; we should figure out what we want ourselves as a community. – Sean Allred Nov 02 '14 at 14:30
  • @SeanAllred the problem with this question is not that it asks for suggestions, it's that it shows very little effort. A question that wants to be answered by the community needs more than 3 sentences. That's also why other people are complaining this is broad, these three sentences might have a very clear meaning in your head but have a completely different meaning for someone else. – Malabarba Nov 02 '14 at 15:44
  • @SeanAllred The question you linked even backs what I said before, there's much more construction behind it. See how much more context it provides. – Malabarba Nov 02 '14 at 15:50
  • @Dan [Community wiki is no longer an excuse to keep overly broad or subjective questions around](http://blog.stackoverflow.com/2011/08/the-future-of-community-wiki/). – Gilles 'SO- stop being evil' Nov 04 '14 at 11:18
  • I don't think this is overly broad. If you look at the current top answer, almost all of the tools are specific to Emacs Lisp (or at least Lisp), and some are quite hard to find individually. – shosti Nov 04 '14 at 19:27
  • @shosti See http://meta.emacs.stackexchange.com/q/183/2264. I'm considering scrapping this question and creating several others (big-list, CW) with more specific goals for Lisps, like "Are there any refactoring tools that work specifically for Emacs Lisp" and "How to debug Emacs Lisp", tagging them all [tag:elisp-development] or something like that. See Meta post for details. (hehe... metapost) – Sean Allred Nov 04 '14 at 19:34

1 Answers1

21

Authoring

  • edebug: Step-by-step debugging of Elisp code.
  • checkdoc: Learn about style errors in your comments and docs.
  • elint: Linter for Emacs Lisp.
  • paredit: Manipulate lisp code as trees instead of lines. Never have unbalanced parentheses.
  • lispy: vi-like alternative / superset of paredit. Additionally includes shortcuts for outlines, narrowing, edebug, ediff, semantic, ace-jump-mode, multiple-cursors, cider, slime and geiser.
  • multiple-cursors: Simultaneously edit multiple similar expressions. Amognst other things, useful for code refactoring.
  • erefactor: Code refactoring.
  • redshank: Another refactoring library (designed for Common Lisp, but works well with Emacs Lisp).
  • macrostep: Interactive in-buffer macro expansion.
  • yasnippet: Code snippets for quick expansion of repetitive idioms (examples here)

Navigation

  • speedbar: The speedbar is a great way to navigate through your project. It recognizes 'tags' as defuns and defvars (and the like) and provides visible bookmarks as an outline.
  • outlined-elisp-mode: A collection of settings for the outline minor mode for Elisp buffers.
  • elisp-slime-nav: Instant jumping to function and variable definitions with M-..

Profiling

  • elp: Interactive frontend for the Emacs Lisp Profiler, useful for exploring what exactly is slow in your profiled function and how it interacts with the rest of Emacs.

Management

  • names: Provides a macro to create namespaces

Version control

  • Git and its Emacs front-end Magit: arguably the best version control system and a very well-thought Emacs front-end for it.

Misc

  • ielm: interactive REPL
shosti
  • 5,048
  • 26
  • 33
Sean Allred
  • 6,861
  • 16
  • 85
  • 1
    Please extend on this list with your favorite tools if you believe they are widely helpful. – Sean Allred Nov 01 '14 at 04:49
  • 1
    I have listed additional resources [here](https://www.reddit.com/r/emacs/comments/axsnw8/your_favorite_packages_and_best_packages/ehwxgro) – clemera Mar 09 '19 at 11:42