[HN Gopher] Emacs Lisp Elements
       ___________________________________________________________________
        
       Emacs Lisp Elements
        
       Author : robenkleene
       Score  : 152 points
       Date   : 2025-04-12 15:09 UTC (7 hours ago)
        
 (HTM) web link (protesilaos.com)
 (TXT) w3m dump (protesilaos.com)
        
       | precompute wrote:
       | Great! This could serve as an easy introduction for users new to
       | Elisp.
        
       | mfld wrote:
       | Nice - I feel this introductory guide fills a gap. Also, I really
       | like his video tutorials.
        
       | algo_lover wrote:
       | One of the good things to happen in emacs was the inclusion of
       | `seq.el`. It makes easy functional operation over sequences, so
       | no longer need `dash.el` or `cl-lib.el`. (dash still has many
       | more functions inspired by clojure which is awesome when you need
       | them)
       | 
       | But I still wish the emacs community could adopt a modern data
       | structure library. It's difficult to consolidate usage of
       | sequences (lists/vectors) with alists and plists. This would make
       | it so much more accessible.
        
         | tom_ wrote:
         | Thanks for the tip. I'd managed to miss the addition of these.
         | I _had_ somehow noticed the addition of the newer string-
         | functions though, and immediately found them a huge improvement
         | over the mishmash of randomly-named crap that was there before,
         | so I expect seq- to be similarly transformative.
         | 
         | I immediately notice there's seq-filter, which can kill off one
         | of my helper routines. And then (now I'm looking...) I've
         | discovered this was always equivalent to cl-remove-if-not. But
         | I never realised, because of the mystery meat naming
         | conventions.
        
       | ajross wrote:
       | Seems clear and useful. That said, there's nothing particularly
       | bad or inaccessible about the _actual_ Emacs Lisp manual:
       | https://www.gnu.org/software/emacs/manual/html_mono/elisp.ht...
       | 
       | Or the official tutorial:
       | https://www.gnu.org/software/emacs/manual/html_mono/eintr.ht...
       | (which to be clear I haven't read, but have heard nice things
       | about).
       | 
       | Of all the things for which emacs can be criticised,
       | documentation rigor is really not one.
        
         | db48x wrote:
         | Agreed; Emacs is the gold standard for documentation. It comes
         | with a reference manual (400k words), an Emacs Lisp reference
         | (600k words), _and_ 64 other manuals for individual Emacs modes
         | or features including one just for Calc mode (250k words), a
         | manual just for Org mode (130k words), one for Gnus (180k
         | words) etc. All told it adds up to about 2.6 million words of
         | documentation.
         | 
         | Still, another manual written from a different perspective
         | probably won't hurt anything.
        
           | beepbooptheory wrote:
           | The Gnus manual in particular has certain whimsical
           | Pratchett-esque charm to it that I love so much.
        
       | mijoharas wrote:
       | It's a shame it doesn't really go into keywords, or
       | alists/plists. (Or different argument lists, he mentions `&rest`
       | but there's optional, and more too iirc)
        
       | tikhonj wrote:
       | I've had a great time using Emacs Lisp over the past 15 years:
       | it's one of the easiest ways to quickly whip up personalized
       | tools for my own use, and, at the same time, my code has been
       | surprisingly resilient and stable over this time.
       | 
       | And this is despite the fact that Emacs Lisp routinely flouts
       | every single software engineering "best practice". The language
       | is dynamically scoped by default! It simply doesn't have
       | namespaces! Static types? Hah! (And I, an inveterate Haskeller,
       | don't even miss them.) You can--and people routinely do--hook
       | directly into all sorts of implementation details from other
       | parts of the codebase.
       | 
       | And yet _it just works_. And it works remarkably well.
       | 
       | My theory: what matters isn't "best practices", it's have a
       | coherent conceptual design and code that reflects that design.
       | Emacs is designed around a small but expressive set of core
       | concepts that it uses in a consistent manner. Text with
       | properties, buffers, modes, commands, customization variables...
       | Almost everything more complex in Emacs is structured out of
       | these (+ a handful more), and, once you've internalized them,
       | it's surprisingly easy to both learn new higher-level tools _and_
       | to write your own.
       | 
       | The design of both the user interface _and_ the code directly
       | reflect these concepts which gives us a naturally close
       | connection between the UI and the code (it 's almost trivial to
       | jump from an interaction to the code that powers it), makes both
       | UI _and_ code units effortlessly composable and generally makes
       | it easier to understand what 's going on and how we can change
       | it.
        
         | nothrabannosir wrote:
         | _> My theory: what matters isn 't "best practices", it's have a
         | coherent conceptual design and code that reflects that design._
         | 
         | Just because something has a >0 level of success doesn't mean
         | there are no negatives. "Best practices don't matter because
         | Emacs Lisp doesn't follow them and it just works" isn't a valid
         | argument: it could very well be that Emacs (Lisp) would shine
         | fifteen-fold brighter if it _did_ also follow those practices.
         | It just happens that having those elements you mentioned as
         | positives are enough to keep the train going _in spite_ of the
         | shortcomings.
         | 
         | I use Emacs and program in Emacs Lisp to scratch my itches, and
         | I agree that there are elements that make it work and hey, I'm
         | still here, but I will bet good money that a parallel universe
         | with Emacs Lisp', Now With Namespaces would work even better.
         | 
         | "Working" isn't binary.
        
           | tikhonj wrote:
           | That's certainly true!
           | 
           | But based on my holistic experience using Emacs--more than a
           | binary "it works"--I'm convinced that the conceptual design
           | carries most of the weight.
           | 
           | Would namespaces, lexical scoping, etc be _better_? Almost
           | definitely. But it would be a marginal improvement, a
           | difference in degree not kind. Other  "best practices" like
           | more aggressive information hiding would go _against_ Emacs
           | 's design and make it _worse_ as a whole.
           | 
           | Most "best practices" are neither necessary nor sufficient
           | and, in most cases, not even particularly effective, even
           | when they offer strict improvements over the status quo.
        
             | TeMPOraL wrote:
             | > _Would namespaces, lexical scoping, etc be better? Almost
             | definitely. But it would be a marginal improvement, a
             | difference in degree not kind._
             | 
             | That's the thing - it probably _would not be_.
             | 
             | IMO, the key things that allow Emacs to succeed and last,
             | while being somewhat unique in how it "routinely flouts
             | every single software engineering "best practice"", are not
             | merely conceptual, but cultural or even _philosophical_.
             | The most fundamental of those, IMO, is that Emacs is
             | ultimately owned by users, who are treated as intelligent
             | partners in the relationship. Everything is designed with
             | extensibility in mind. There 's no hard boundary between
             | "core developers", "third-party extension developers" and
             | "end-users" - everyone can be any of them, including all
             | three, at any time.
             | 
             | Maximizing extensibility and interoperability, not
             | demanding "users" to coordinate with "developers" and ask
             | for permission, not chasing user growth (it's all Free
             | Software), expecting that everyone is a responsible adult,
             | encouraging users to make Emacs "their own" - all that
             | leads to an approach that goes the opposite to standard
             | software development practice, because the standard
             | practice is built around entirely opposite assumptions.
        
           | teddyh wrote:
           | > _Emacs Lisp ', Now With Namespaces_
           | 
           | Do you mean lexical binding, available as an option since
           | 24.1?
        
       | sauercrowd wrote:
       | Prot - the author - is a pretty incredible guy. He maintains a
       | bunch of nice Emacs packages and themes.
       | 
       | But maybe even more remarkable: he got kicked out of his flat in
       | Greece, couldn't afford a new place, bought a small plot of land
       | in the mountains and started building a hut from materials he was
       | able to afford or from things neighbours gave him. Really the
       | bare minimum (he often sat in his hut with a jacket in winter
       | cause it wasn't well isolated/heated)
       | 
       | Absolutely inspiration, all documented on his YouTube channel
       | https://youtube.com/@protesilaos?si=MnjV7MhKtsT5RDSM
        
         | hollerith wrote:
         | A video of the inside of the hut:
         | https://www.youtube.com/watch?v=W2T_lihBs9I
        
         | kleinishere wrote:
         | He also offers 20EUR/hr eMacs coaching. For those jumping in or
         | graduating to a new level.
         | 
         | https://protesilaos.com/coach/
        
       | NeutralForest wrote:
       | When Prot writes something I try to make place to read it. He's a
       | very nice person and also inspiring, he's living following his
       | values and is very insightful.
        
       ___________________________________________________________________
       (page generated 2025-04-12 23:00 UTC)