[HN Gopher] Emacs Lisp book revived: Marcin Borkowski
       ___________________________________________________________________
        
       Emacs Lisp book revived: Marcin Borkowski
        
       Author : nanna
       Score  : 72 points
       Date   : 2021-05-01 10:15 UTC (12 hours ago)
        
 (HTM) web link (mbork.pl)
 (TXT) w3m dump (mbork.pl)
        
       | nanna wrote:
       | I've found the lack of resources to learning Elisp a challenge. I
       | haven't finished it, but Robert J. Chassell's 'An introduction to
       | programming in Emacs Lisp' seems to run through basic concepts
       | but doesn't really get to the meat of actually putting everything
       | together. (Could be wrong) And the Elisp manual reads like the
       | output of an Elsip macro - so terse, so few examples, so much
       | over my head. I've found Xah Lee's website helpful, but also
       | completely overwhelming in all its detail. I'm after a guide. So
       | I'm looking forward to this book by Marcin Borkowski.
       | 
       | Maybe others have suggestions of other ways to pick up Elisp?
        
         | loosetypes wrote:
         | Interesting, I find that there are plenty of resources but they
         | don't actually cover my pain points.
         | 
         | There are plenty that teach elisp the language or that
         | demonstrate consuming elisp packages, but it seems like not
         | many in using elisp to modify the environment. By that I mean,
         | okay I want to write a major/minor mode and have it update on..
         | keystroke? Any state change? And knowing which hooks/emacs
         | internals to inspect/modify accordingly.
         | 
         | To be fair, I think Xah does a great job of this and most of
         | this can be learned from reading source code. But sometimes I
         | wish there were more direct answers out there.
         | 
         | Anyone know of a "cookbook" of sorts for common design patterns
         | when implementing your own elisp packages that assume you know
         | the basics of elisp?
        
         | tgbugs wrote:
         | Not sure if this is quite what you are looking for, but I found
         | reading through GNU Emacs: Creeping Featurism Is a Strength
         | (chapter 11 of Beautiful Architecture) at the suggestion of Eli
         | Zaretskii to be extremely useful at painting the picture of the
         | environment in which elisp code runs and the assumptions that
         | it makes.
        
         | neilv wrote:
         | Have you tried a combination of the Emacs Lisp Reference and
         | looking through code?
         | 
         | There's one subtle but huge barrier to learning now: it used to
         | be, you'd see Emacs add-ons posted as single text files, and it
         | was all very accessible. And you'd copy that file into your
         | home directory, and edit the Emacs Lisp of your `.emacs` file
         | to connect it. You were already writing Emacs Lisp, and the
         | files with more Emacs Lisp are right there.
         | 
         | Now, some well-meaning people made Emacs package managers (and
         | there is some valid motivation for that) that take away this
         | introduction of toes-dipped-in-the-water with quick transition
         | to jumping in altogether, and then further hide the code from
         | you. And if you ever do find the code, it's often directory
         | trees with a dozen different "professional-looking" bureaucracy
         | files in the top, and the source code buried somewhere else.
         | 
         | Which I assume gives people the impression that it's another
         | "stack" to learn, where a lot of things are automated and have
         | opaque layers of abstraction, and the bulk of the work is
         | simply learning the piles and piles of bureaucracy that other
         | figuring out how to do something despite other people's piles
         | and piles of bureaucracy. And then the next step is Web
         | searches and cargo-culting from solutions of unclear validity
         | from Stack Overflow.
         | 
         | Emacs is supposed to be an exceedingly accessible and
         | incremental thing, where you're changing the code of your
         | running editor, which you realize is a kind of super IDE, as
         | you start to immediately learn its features for this kind of
         | programming.
         | 
         | Consider ignoring your Emacs package managers, get the two main
         | manuals up in Emacs Info mode, start using your ` _scratch_ `
         | buffer to evaluate expressions like you find in the docs, see
         | how to navigate between code and docs and keys, see how to turn
         | on the debuggers, look through some code for some add-on
         | packages, to see how they did those fairly well-scoped things.
         | Somewhere in there, start making Emacs do some small thing that
         | you want it to do -- and maybe make that your initial
         | motivation and task, and everything I just mentioned was as-
         | needed, in support of that activity.
         | 
         | It's a different approach from how we often have to work, in
         | the current brogrammeresque world, and maybe a nice
         | weekend/evening break from paid work. And -- though we might
         | want to pretend otherwise, if we want it to be a change of pace
         | from work -- the exercise of this different approach can mean
         | skills and perspectives that we can bring back to the paid
         | work.
        
           | TeMPOraL wrote:
           | > _take away this introduction of toes-dipped-in-the-water
           | with quick transition to jumping in altogether, and then
           | further hide the code from you. And if you ever do find the
           | code, it 's often directory trees with a dozen different
           | "professional-looking" bureaucracy files in the top, and the
           | source code buried somewhere else._
           | 
           | Here's a bunch of tricks one should know if one wants to
           | learn Elisp:
           | 
           | 1. You can use describe-function (C-h f) or describe-variable
           | (C-h v), as well as various apropos functions (starting with
           | apropos, C-h a), you can find documentation about pretty much
           | everything in Emacs, down to every single internal function
           | or variable of any bit of Elisp code.
           | 
           | 2. When you do that, you get a help buffer that almost always
           | starts with something like "foo is a variable defined in
           | `foo.el`". That "foo.el" bit is a link. You can click on it
           | (or move your point to it and press Enter), and it'll land
           | you _straight at the definition of that function /variable_.
           | This is your shortcut to jumping straight into relevant
           | source code of everything. Including C code, if you dig
           | yourself into Emacs internals.
           | 
           | 3. You can navigate to the help buffer in 2 from plenty of
           | places, including e.g. the list of current modes, or
           | description of a mode.
           | 
           | 4. When you're playing around with Elisp code, xref-find-
           | definitions (M-.) will take you straight to definition of a
           | function under point.
           | 
           | Emacs is thoroughly documented and cross-referenced. Your own
           | installation is its own single, living codebase - and you can
           | navigate through it as such.
        
             | neilv wrote:
             | Thanks, that's what I meant by "see how to navigate between
             | code and docs and keys", but was too lazy to type. :)
             | 
             | One important thing people should keep in mind, if they're
             | starting only with Emacs navigation features for code and
             | docs, is that they're missing crucial information that's in
             | the manuals. One of the manuals is like a combination of
             | the "API docs" you'll find in the docstrings, _plus_ all
             | the narrative around those, which you won 't find in the
             | docstrings. If a newbie is told only to browse docstrings
             | and code, they're doing it on hard-mode.
             | 
             | And if a person makes sure they have the manuals installed
             | (sadly, the Emacs Lisp manual(s) don't come installed by
             | default in distros I've seen, which I think is a tragic
             | mistake for uptake), and learns how load the manual in
             | Emacs Info browser, and learns keys the Info keys like `i`,
             | `s`, `[`, `]`, and `u`, I think they'll be glad they didn't
             | try working from manuals in the Web browser.
             | 
             | Also, I wanted to start with making the code files more
             | accessible and concrete, and generally tell people to try
             | thinking differently about this. The reason is that I've
             | suspected that a systemic barrier to accessible Emacs
             | hacking was being created in the bureaucratic and obscuring
             | direction things were going. (And it sounded like maybe
             | this person was a victim of that suspected problem, since,
             | when I started, it was much easier to get into, in the ways
             | I described.)
             | 
             | (FWIW, I was able to write some Emacs extensions by
             | starting with the approach I've suggested, including:
             | https://www.neilvandyke.org/emacs/ )
        
         | momentoftop wrote:
         | Do you know any other lisps? I got by with the Elisp manual,
         | but I already knew Common Lisp. Maybe a strategy is to find a
         | great book teaching, say, scheme, and learn elisp after?
        
           | nanna wrote:
           | I'm pretty excited by Clojure so thinking of delving more
           | into that, and then hoping it maps back onto Elisp, despite
           | it lacking stuff like tail recursion. Would that make sense,
           | or should I stick closer to the tree?
           | 
           | Maybe CL is the best route to Elisp... If so, any
           | recommendations on how one might learn CL in 2021?
        
             | momentoftop wrote:
             | I actually only know CL and Elisp. I played a bit with
             | Clojure, and its Emacs story looks pretty solid, but I was
             | thinking it might be difficult to translate idiomatic
             | clojure code to Elisp when Clojure has more emphasis on
             | purity.
             | 
             | I'd guess that CL is closest to Elisp, especially when you
             | use the popular "cl-mode", and you have the same mental
             | model of hacking on a live lisp system. I learned CL from
             | Paul Graham's "ANSI Common Lisp" back in the day, but I'd
             | too be interested in what's recommended in 2021.
        
               | jinwoo68 wrote:
               | Yup. The closest is Common Lisp. Clojure's idioms don't
               | match very well with Elisp oftentimes.
        
           | taeric wrote:
           | I'm curious if you have a good sheet on what differences are
           | worth focusing on?
           | 
           | My main blocker is that it was originally tough to realize
           | that the buffer is an essential part of elisp. Reflexively, I
           | would look for ways to manipulate strings and be disappointed
           | at how hard that was to find. As soon as I started seeing
           | elisp as a way to program buffers, things got a lot easier.
        
         | scroot wrote:
         | Dave Wilson is doing "The Lord's Work" when it comes to Emacs
         | outreach, over on his System Crafters [1] YouTube channel. One
         | of the series he is running there is an ongoing guide to Emacs
         | Lisp.
         | 
         | [1] https://www.youtube.com/channel/UCAiiOTio8Yu69c3XnR7nQBQ
        
           | nanna wrote:
           | Thanks, yes that's true Dave Wilson's doing great work.
           | 
           | One other resource I actually found very helpful, pitched
           | just right, is Musa Al-hassy's Elisp Cheatsheet. It's short
           | but it gets straight to the detail. If he ever wrote a book
           | I'd prepreorder it.
           | 
           | https://github.com/alhassy/ElispCheatSheet/blob/master/Cheat.
           | ..
        
             | podiki wrote:
             | Thanks for both of these! I tend to just look up elisp
             | stuff when it isn't clear from my Common Lisp knowledge,
             | cheat sheets are perfect for this.
        
         | mcshicks wrote:
         | I found doing the excercise on excercism.io very helpful. I
         | read the manuals, some books, but actually writing code is the
         | best. The nice thing about excercism.io is the examples have
         | self checking code and you can get mentor feedback.
         | 
         | https://exercism.io/tracks/emacs-lisp
        
           | nanna wrote:
           | Good idea, thanks!
        
         | mcguire wrote:
         | There's also Bob Glickstein's _Writing GNU Emacs Extensions:
         | Editor Customizations and Creations with Lisp_
         | (https://www.amazon.com/Writing-GNU-Emacs-Extensions-
         | Customiz...), which I found quite good at the time. But it's
         | really old. On the other hand, I don't know if it's out of
         | date. :-)
        
       | dilipdasilva wrote:
       | Looking forward to buying the completed book.
        
       | Zilcho wrote:
       | I've looked at a lot of lisp books this week, and this didn't
       | strike me as one I'd find useful, and particularly the sample
       | chapter was uninteresting.
        
       ___________________________________________________________________
       (page generated 2021-05-01 23:01 UTC)