[HN Gopher] Emacs's Builtin Elisp Cheat Sheet
       ___________________________________________________________________
        
       Emacs's Builtin Elisp Cheat Sheet
        
       Author : seansh
       Score  : 149 points
       Date   : 2022-07-06 08:29 UTC (14 hours ago)
        
 (HTM) web link (www.masteringemacs.org)
 (TXT) w3m dump (www.masteringemacs.org)
        
       | tut-urut-utut wrote:
       | Emacs is an amazing editor and never ceases to surprise in a
       | positive way.
       | 
       | The only complaint I have about Emacs is its look and feel and a
       | lack of a usable Sidebar. If they could "steal" that from Sublime
       | Text it would be perfect.
        
         | mickeyp wrote:
         | Do you mean like `M-x speedbar'? Lots of third-party
         | customizations for it, too.
        
           | mxben wrote:
           | Thanks! Never knew this existed. Would have been better if
           | the sidebar was not shown in a new frame. There are third-
           | party customizations to launch speedbar in the same frame
           | though.
        
             | mmargerum wrote:
             | i like it as a separate frame
        
           | pksebben wrote:
           | to add to this, if there are things the speed bar doesn't do
           | that you wish it did, the chance that there's no package for
           | {specific thing you want} is vanishingly small.
           | 
           | The primary difficulty is in being able to find exactly what
           | you're looking for. Precise terminology and specific terms of
           | art (i.e. linting, directory traversal, syntax hiliting) will
           | help here.
        
             | tut-urut-utut wrote:
             | For me, speedbar is a no-go, since it opens in a new frame.
             | If I switch to browser, and then back to Emacs buffer, it
             | is still hidden behind a browser windows.
             | 
             | From sidebar, what I look is an exact equivalent of Sublime
             | Text's sidebar.
             | 
             | - It opens in the same frame - I can add/pin a folder tree
             | there, it should be operable by mouse (open/close subtree,
             | click to open a file in buffer or switch to it) - Have a
             | list of open files / buffers - clicking on it should switch
             | to buffer
             | 
             | Currently looking at treemacs and neotree that were
             | suggested by me. Previously I was giving up trying to
             | configure them, now I may be more persistent.
        
               | jhbadger wrote:
               | The site here has some elisp code that puts the speedbar
               | in the current frame. I've just tried it and it seems to
               | work.
               | 
               | https://carnet.danielhan.dev/linux-unix/emacs/speedbar-
               | in-on...
        
               | gpderetta wrote:
               | sr-speedbar in melpa seems relevant .
        
         | hprotagonist wrote:
         | there's even a minimap implementation.
        
         | steeleduncan wrote:
         | I've not used Sublime Text, but I think treemacs fits what you
         | are looking for
         | 
         | https://github.com/Alexander-Miller/treemacs
        
         | arkanane wrote:
         | I think that the look and feel is what I like more about Emacs.
         | Having such a complete environment full screen without much
         | space waster makes me much more focused
        
       | submeta wrote:
       | Excellent! This is a wonderful function I did not know about. - I
       | learn a lot about Emacs from Mickey Petersen, his book "Mastering
       | Emacs" (highly recommended), and his articles on r/emacs. Thank
       | you again for this article.
        
       | rollcat wrote:
       | I have a love-hate relationship with Emacs.
       | 
       | The defaults are absolutely awful. The editor is pretty unusable
       | without at least a hundred lines of ELisp: basic stuff like CUA,
       | setting up fonts, disabling useless UI clutter, delete-selection-
       | mode, rebinding a couple keys, setting up packages, explaining
       | where to find coreutils on BSD systems, etc. And then you get to
       | packages.
       | 
       | If you want to do anything remotely useful, you're gonna have to
       | start installing random stuff from GNU ELPA, MELPA, etc. There's
       | no package pinning or SemVer so you get what you get, packages
       | sometimes break in mysterious ways. So you write more code to
       | work around various broken stuff in packages.
       | 
       | I've gone through several iterations of throwing away my entire
       | init.el and starting from scratch with just the bare minimum
       | needed to get work done. At the current iteration, ELisp is still
       | ~33% of all source code volume in my dotfiles repo[0]. I haven't
       | pushed my latest effort to unbreak "jump to definition" (because
       | apparently dumb-jump is deprecated??? and I need to use xref???
       | but it doesn't work???) so that'll likely go up.
       | 
       | I never wanted to write enough ELisp to justify calling it a
       | program, but Emacs made me.
       | 
       | But then there is magit[1], which is so damn good, it makes every
       | other VCS interface look like a sad joke. Which is problematic,
       | because configuring Emacs itself is a bit of a sad joke. I want
       | to just write code, not write code to make just writing code less
       | of a pain. :(
       | 
       | [0]: https://github.com/rollcat/dotfiles
       | 
       | [1]: https://magit.vc
        
         | [deleted]
        
         | michaelsbradley wrote:
         | You might find prelude worth a look:
         | 
         | https://github.com/bbatsov/prelude#readme
        
         | iLemming wrote:
         | The story is as old as Emacs itself. Many people (if not most)
         | start using Emacs by treating it as "an editor". They think
         | they have to configure it by tweaking settings and changing
         | various options.
         | 
         | But Emacs is nothing but clay, an assortment of Lego pieces,
         | building blocks, programmers' equivalent of IKEA furniture, DYI
         | toolkit, etc.
         | 
         | It's not an editor, it's material for you to build your own
         | editor.
         | 
         | > I never wanted to write enough ELisp
         | 
         | That's the mistake Emacs newcomers often make. If you truly
         | want to master Emacs, there's no way around it - you have to
         | accept Emacs Lisp. With all its flaws and incredible power.
         | 
         | If you hate Lisp because it's not like languages you learned
         | and used before; it doesn't look like Python, Javascript or
         | Ruby, then maybe you're missing something.
         | 
         | One needs to set aside their prejudice about parenthesis, learn
         | structural editing commands, understand REPL-driven workflow,
         | and then, once they are over that initial barrier, they may
         | realize that all those [more popular] languages borrowed
         | heavily from Lisp, and Lisp is an extremely nice programming
         | language.
         | 
         | True craftsmen very often make their own tools. I am of course
         | biased here, but in all honesty, every single professional I
         | know, whom I can count as an Emacs power-user or even a master;
         | Every single one of them is truly an incredible hacker.
         | 
         | ps.: "you" used here in the general sense, not targeted to the
         | OC personally.
        
         | rvdca wrote:
         | Regarding your comment on package pinning, you can see
         | straight.el (https://github.com/radian-software/straight.el)
         | 
         | Previous discussion on HN here :
         | https://news.ycombinator.com/item?id=31833101
        
         | abrax3141 wrote:
         | Exactly the difference between emacs and most of the software
         | world is that for most of the software world your post would
         | end at "The defaults are absolutely awful. The editor is pretty
         | unusable."
        
           | MonkeyClub wrote:
           | "Sane defaults" is a thing, but the sanity supporting the
           | defaults changes every couple of decades.
           | 
           | E.g., re the GP's complaint about lack of CUA: CUA is an IBM
           | effort to standardize a dozen shortcuts that are considered
           | more or less universally useful.
           | 
           | But Emacs predates CUA by a couple of decades, and supports
           | easy access to an insanely wider (two, three orders of
           | magnitude) space of functionality.
           | 
           | If you want CUA, Notepad is 100% conformant.
           | 
           | Disclaimer: Yes I would adore a clean pure new Emacs, but
           | given the dearth of Stallmans, the new Emacs would take even
           | longer to not have CUA by default.
        
             | robonerd wrote:
             | > _But Emacs predates CUA by a couple of decades_
             | 
             | Only a couple of years if you're taking GNU Emacs
             | specifically. About one decade if you're talking about
             | editor macros for TECO.
        
             | morelisp wrote:
             | Most people today would freak out given only CUA
             | cut/copy/paste though. It's also too old.
             | 
             | Panta rhei - you can either pick a tool that comes with
             | you, or deal with switching at each stop on the river.
        
               | abrax3141 wrote:
               | Without the kill ring I would have to kill myself :-)
        
         | rawoke083600 wrote:
         | Try Doom Emacs :)
        
         | TacticalCoder wrote:
         | > The defaults are absolutely awful.
         | 
         | I find them awful too but many people are fine with these
         | defaults.
         | 
         | > There's no package pinning or SemVer so you get what you get,
         | packages sometimes break in mysterious ways. So you write more
         | code to work around various broken stuff in packages.
         | 
         | There's however a way around it which you may like, seen your
         | complaint... What I do, and it's not unheard of but definitely
         | not the most common when it comes to Emacs, is that I load
         | specific versions of packages. And I commit my entire Emacs
         | setup in Git.
         | 
         | So when I upgrade packages (or install new ones) if anything
         | goes wrong I can just checkout/restore a known fully working
         | state.
         | 
         | There are trade offs when versioning your entire "emacs.d"
         | directory but honestly I don't see many downsides. And I share
         | that emacs.d between several user accounts / machines and any
         | change I made are one "git pull" away.
         | 
         | When I start Emacs I don't check for packages / refresh package
         | contents or anything like that: I only do that when I actually
         | plan to upgrade packages (which I do maybe once every six
         | months or so).
         | 
         | > I want to just write code, not write code to make just
         | writing code less of a pain.
         | 
         | I'd say that's kinda a big selling point of Emacs though: you
         | can write elisp code to make anything you do (not just writing
         | code) less of a pain.
        
           | rollcat wrote:
           | > I'd say that's kinda a big selling point of Emacs though:
           | you can write elisp code to make anything you do (not just
           | writing code) less of a pain.
           | 
           | I agree in principle, but in practice, I find myself writing
           | a lot of ELisp just to work around Emacs' shortcomings. E.g.
           | on macOS, to support dark/light theme switching integrated
           | with the rest of the system, I need an external program[0], a
           | shell script to tell that program to call emacsclient, a
           | LaunchAgent to keep it running, an unholy build of Emacs with
           | all of the GNU-unapproved Cocoa integrations that some kind
           | soul is maintaining, and only THEN a piece of ELisp (which is
           | also calling out to AppleScript) to actually change the
           | theme[1]. And as I wrote this, I realised half of this glue
           | didn't even make it into version control.
           | 
           | [0]: https://github.com/cormacrelf/dark-notify
           | 
           | [1]: https://github.com/rollcat/dotfiles/blob/7f6a6d7/.emacs.
           | d/in...
           | 
           | I've been using Emacs for about 20 years, and with every
           | passing year I just wish there was *less* ELisp for me to
           | think about. The actual useful customisations (like adding
           | the +x bit on shell scripts) are few and far between, most of
           | it is just glue and fixes.
        
             | morelisp wrote:
             | > a shell script to tell that program to call emacsclient,
             | a LaunchAgent to keep it running, an unholy build of Emacs
             | with all of the GNU-unapproved Cocoa integrations that some
             | kind soul is maintaining, and only THEN a piece of ELisp
             | (which is also calling out to AppleScript) to actually
             | change the theme[1]
             | 
             | Why isn't your Emacs session running dark-notify itself,
             | reading its output, and switching accordingly? That seems
             | to remove the need for shell script running emacsclient,
             | the launch agent, and the OSA integration. (But also, I
             | thought ns-do-applescript was stock Emacs? At least I had
             | some ELisp using it and I only ever used emacsformacosox.)
        
         | msla wrote:
         | I absolutely love the default Emacs keystrokes.
        
           | mickeyp wrote:
           | Same. They're generally very good, and there's a lot of logic
           | and fluidity to how movement and editing combine.
        
           | rollcat wrote:
           | Me too :) One of the reasons why I fell in love with macOS -
           | every text editing widget in the whole OS is very
           | consistently using the basic Emacs keys like C-a, C-e, C-k,
           | C-y, C-t, etc. That also makes Xcode (and most other IDEs)
           | much less awful right out of the box ;)
        
           | vq wrote:
           | I do too.
           | 
           | I'm one of those weirdos that disable transient-mark-mode
           | because I don't feel like it does the right thing for all
           | situations where you use mark. Sometimes I want to use mark
           | like a cheap bookmark and C-x C-x between mark and point,
           | sometimes I use the rectangle commands and for those
           | transient-mark-mode only makes things worse.
           | 
           | (I know the CUA mode has some fancy rectangle features, but
           | that's not for me)
        
             | mickeyp wrote:
             | I wrote about marking and exchanging point and mark without
             | activating TMM:
             | 
             | https://www.masteringemacs.org/article/fixing-mark-
             | commands-...
             | 
             | Also, the CUA rectangle stuff's actually mainlined and can
             | be used without CUA (`C-x SPC')
        
               | vq wrote:
               | I didn't know about C-x SPC, thanks for the tip!
               | 
               | I enjoyed your article but I think the solution for me is
               | to leave TMM disabled, though it makes me curious about
               | what else I've missed in the last decade(s). You just
               | made a sale of your book.
        
               | mickeyp wrote:
               | Thanks :) Enjoy! Shoot me an email when you've read it.
               | I'd love to hear about what you've learned.
        
           | nanna wrote:
           | Me too! I've always been baffled by the hate. If you come
           | from vim, just use evil, install Doom Emacs or whatever. End
           | of the day it's all just arbitrary muscle memory so once you
           | get used to it all other keybindings (bar perhap vim) seems
           | absurd.
        
             | robonerd wrote:
             | Evil-mode is incredible, for me Emacs with evil is the best
             | vi-derived editor in the world, beating neovim and vim by
             | miles. But as an ex-Vim user and fairly recent Emacs
             | convert I feel like a guest in a clubhouse full of old
             | timers. It wouldn't be right for me to swagger around their
             | domain, demanding they change things up to accommodate me.
             | Evil mode is already a much warmer welcome than I'm
             | entitled to, so what if it takes a line or two to
             | configure? I'm very grateful to have what I have now, I
             | don't need or want Emacs defaults changed.
        
         | beebmam wrote:
         | I've been using emacs for org-mode for notes for a decade with
         | emacs defaults. Works wonderfully and is absurdly simple to use
        
         | robonerd wrote:
         | > _basic stuff like CUA_
         | 
         | I don't care for the defaults either, but I _also_ don 't care
         | for CUA, so if you had your way the defaults would be just as
         | objectionable to me as they are now. Since you can't make
         | everybody happy, I think the best way forward is to continue
         | the status quo, so at least you won't be forcing configuration
         | on users who were previously fine with the default.
        
           | medo-bear wrote:
           | i too dislike CUA. if you use the terminal CUA usually does
           | not work and insteas we get CUA-ish hacks. emacs bindings are
           | usually readily available on the other hand
        
           | taeric wrote:
           | You have me intrigued. What do you like/use?
        
             | robonerd wrote:
             | evil-mode
        
         | richiebful1 wrote:
         | I've found using Doom Emacs to be a lot easier than handrolling
         | an init file.
         | 
         | I understand the gripes though. Emacs really shines when you
         | have a workflow that is poorly supported by mainstream tooling
         | and you want to write your own. I don't know of any other
         | editor that allows you to add keyboard
         | shortcuts/commands/functionality that easily.
        
           | rollcat wrote:
           | I generally like both Doom and Spacemacs, but they are an
           | additional, huge layer on top of an already complex and
           | complicated editor/runtime/framework. They're great when they
           | give you 99% of what you need, but pretty terrible once you
           | have to start digging.
           | 
           | My dream config file is probably 10-20 lines of my actual
           | preferences, not 40-60k lines on top of which I have to add
           | another several hundred.
        
       | thorw73m wrote:
       | Emacs in itself is worth studying to become better developer. The
       | best minds in the computer industry have worked on this editor's
       | design. For example I used to think single namespace in elisp is
       | bad. But after used it for a while it feels having single
       | namespace is probably good for cognitive ease. In contrast C++
       | offers namespace but when "using namespace" is used at the top of
       | the file, the rest of the file contains only part of the
       | namespace. This makes it harder to grep while reading source
       | code. Although emacs have longer symbol names its cognitively
       | much easier.
        
         | untilted wrote:
         | Elisp now supports "shorthands", a kind of cheap namespace
         | system. It's very recent so virtually unused in the wild.
         | 
         | https://www.gnu.org/software/emacs/manual/html_node/elisp/Sh...
        
       | rtpg wrote:
       | I bought Mastering emacs on a whim after reading it but am still
       | looking for more in-depth stuff about working with Emacs Lisp in
       | particular.
       | 
       | I can do basic stuff alright, being able to jump into source in
       | particular is very helpful to at least find snippets of code
       | doing what I want, but I don't have a good sense of how to work
       | effectively in it.
       | 
       | (For example, when trying to test things out I haven't really
       | found a way much better than typing into scratch, selecting code
       | and running it while staring at messages....)
       | 
       | I would gladly pay money to watch somebody just write and debug
       | emacs lisp code for half an hour cuz I feel wanting for usability
       | when trying to work with this.
        
         | mickeyp wrote:
         | You may like my article on this very subject:
         | 
         | https://www.masteringemacs.org/article/evaluating-elisp-emac...
        
         | tra3 wrote:
         | > (For example, when trying to test things out I haven't really
         | found a way much better than typing into scratch, selecting
         | code and running it while staring at messages....)
         | 
         | Are you talking about when you're noodling, trying to figure
         | how things work, or actually trying to build something?
         | 
         | For playing around, I found that scratch works ok, but I found
         | a better workflow.
         | 
         | I end up using a daily note in org-roam, with #begin_src
         | elisp... I then tag the heading with :REFILE:ELISP: so I can
         | always find it later. Basically evaluate everything inline
         | within that org-babel block.
         | 
         | When I'm building something, or driving towards a specific
         | goal, I use buttercup [0] to write actual unit tests. If I
         | squint, it kinda looks like TDD.
         | 
         | Finally, for debugging of running elisp, take a look at edebug
         | [1]. It's a pretty standard looking debugger (if you used
         | something like gdb). By default emacs uses debug which is not
         | as friendly.
         | 
         | [0]: https://github.com/jorgenschaefer/emacs-buttercup
         | 
         | [1]:
         | https://www.gnu.org/software/emacs/manual/html_node/elisp/Ed...
        
           | LanternLight83 wrote:
           | Just stumbled upon edebug yesterday after looking through the
           | options that you can put in a `declare` form and it's become
           | an invaluable portion of my workflow; if I may ask a noob
           | question, is there an easy way to keep a persistent eye on a
           | closure or arbitrary set of a variables, and is there a way
           | to debug-step through disassembled code? Totally okay if you
           | don't know off the top of your head, I'll have time to search
           | for these eventually.
        
             | tra3 wrote:
             | > is there a way to debug-step through disassembled code
             | 
             | That's what I've been using it for. Once you find a
             | function you're interested in, call `eval-defun` in it.
             | Next time it's executed you should get a prompt with a
             | stack trace and ability to step through the code (with `n`)
             | or evaluate an expression in context (`e`).
             | 
             | > if I may ask a noob question, is there an easy way to
             | keep a persistent eye on a closure or arbitrary set of a
             | variables
             | 
             | I discovered edebug last week when I finally had to; so
             | we're in the same boat. My guess is "yes" :)
        
               | LanternLight83 wrote:
               | Thanks for getting back to me! I didn't know about
               | evaluation in the current context, which should let me
               | inspect and explore the environment like I wanted to.
               | 
               | To clarify for anyone reading, `eval-defun` needs to be
               | called with a prefix argument to instrument the first
               | function, and `edebug-instrument-callee` (`I`) can be
               | used to instrument the function following point in
               | edebug's source-code-buffer, which I think is what you
               | reffered to as a backtrace; I printed the edebug manual
               | and brought it to work with me, in which I see that you
               | can get a real back trace by calling `edebug-pop-to-
               | backtrace` (`d`).
               | 
               | By `disassembled `, I meant bytecode, which after
               | thinking about for a bit, maybe it could be done with
               | lapcode, which is like bytecode made of s-expressions,
               | but what I'd really want is a way to see the stack.
               | Anyway, that seems like a whole 'nother beast, outside
               | the scope of edebug.
               | 
               | Edit: I was looking for an evaluation list, see `edebug-
               | visit-eval-list` (`E`) and `edebug-update-eval-list`
               | (`C-c C-u`) c:
        
       | pech0rin wrote:
       | Mastering emacs is an amazing resource and one I have used
       | countless times over the years. I have used emacs since my time
       | in college (~14 years ago) and I still discover new things about
       | it -- a lot from "mastering emacs". Anyway, thanks for all the
       | great content!
        
         | mickeyp wrote:
         | Thanks! I'm very happy to hear that.
        
           | nanna wrote:
           | Seconded! Thank you Mickey. Your posts consistently expand my
           | Emacs capabilities, and appreciation of Emacs too :)
        
           | tlavoie wrote:
           | Hey Mickey, another happy reader here. One question, looking
           | at your site, I see mention of an "Emacs 28 edition." I've
           | got v3 of the ebook, is there an update version from here?
        
       | yc20220630103 wrote:
       | Personally as somebody who is NOT a software dev Emacs is my
       | favorite tool on Linux and I usually have 1 or 2 windows open at
       | all times. Tramp in particular is like magic, I can natively
       | browse remote directories, copy and edit files and run a terminal
       | remotely through eshell. This is STILL something that VSCode
       | struggles with, the Microsoft "Remote" extension has /bin/bash
       | hardcoded in and fails if the remote machine doesn't have it.
        
         | vdm wrote:
         | What machine does not have /bin/bash
        
       | abrax3141 wrote:
       | I have been using plain out-of-the-box emacs for literally 40+
       | years. (I wrote the initial version of one of the commands that's
       | now built-in.) I do probably a third of my data cleaning work in
       | keyboard macros. I am so used to and efficient with plain emacs
       | that most customization just seems like unnecessary decoration --
       | with the exception of major language modes, because language
       | specific fwd/bkwd (s)expr is so useful.
        
       | zasdffaa wrote:
       | Emacs docs aren't perfect but they are a major, major strength of
       | it and I wish so much other software would learn from it. The
       | devs are really responsive too - good guys!
        
         | thorw73m wrote:
         | C-h r C-s <search_term> - This almost always helps if not
         | google - "<search_term> emacs wiki"
        
           | iLemming wrote:
           | C-h r - info-emacs-manual
           | 
           | Please, try to get into the habit of not only sharing the
           | keystrokes but also commands they bind to. With all different
           | Emacs "distros" popping up, it's hard to track the bindings.
           | "Is it in vanilla, Doom or Spacemacs?..."
           | 
           | My hope is for a convention to emerge where the proper
           | etiquette of Emacs pedagogy would be always mentioning the
           | command.
           | 
           | Also, I think you meant to say C-h r s <search_term>, where
           | <s> binds to Info-search
        
       | kettunen wrote:
       | As an Emacs user, I definitely enjoy always finding new things
       | about it. Thanks to these kinds of discoveries I've been able to
       | make my .emacs.d smaller and smaller in tiny increments due to
       | being able to replace various packages downloaded from ELPA/MELPA
       | with built-in ones.
        
       ___________________________________________________________________
       (page generated 2022-07-06 23:01 UTC)