Emacs Lisp Elements(protesilaos.com)
protesilaos.com
Emacs Lisp Elements
https://protesilaos.com/emacs/emacs-lisp-elements
58 comments
My Emacs wouldn’t be the same without Prots modus themes[1], which I found to be a great foundation to build my own theme on top of. I am grateful for all the work he did for the Emacs community.
I also enjoy watching his videos where he talks about various philosophical topics from a very clear, pragmatic and down-to-earth perspective. My impression is that he is a really kind and humble person and that he lives by his philosophical insights, without bragging about his lifestyle or judging about how other people live their lifes.
[1]: https://protesilaos.com/emacs/modus-themes
I also enjoy watching his videos where he talks about various philosophical topics from a very clear, pragmatic and down-to-earth perspective. My impression is that he is a really kind and humble person and that he lives by his philosophical insights, without bragging about his lifestyle or judging about how other people live their lifes.
[1]: https://protesilaos.com/emacs/modus-themes
Modus themes are so rad - they look bleak at first, but after a while they grow on you. Then you try some other theme and notice how terrible it is to look at due to lack of contrast. I am convinced now that most theme makers have not the slightest idea what they are doing. Modus and PragmataPro font are two things which spoiled themes and fonts for me.
But, Prot also has other incredible packages - I am a user of denote, his notetaking package. Then there are ef-themes, for those who like themes with more color. There are gems there, but really, one should try modus for a while first.
But, Prot also has other incredible packages - I am a user of denote, his notetaking package. Then there are ef-themes, for those who like themes with more color. There are gems there, but really, one should try modus for a while first.
They handle other packages so nicely too, as well as switching between light and dark and using variable pitch for UI parts.
He also offers 20EUR/hr eMacs coaching. For those jumping in or graduating to a new level.
https://protesilaos.com/coach/
https://protesilaos.com/coach/
He also accepts donations
https://protesilaos.com/donations/
https://protesilaos.com/donations/
"emacs". It is called "emacs"
This happens with iOS autocorrect → https://en.wikipedia.org/wiki/EMac
"Wouldn't it make life easier for us at Apple if we added all of our product name capitalizations like iMac, iPod, etc. into the autocorrect dictionary? Marketing would probably love it too." -Someone at Apple, probably, circa 2006
And here we are.
And here we are.
Its page calls it Emacs: https://www.gnu.org/software/emacs/
A video of the inside of the hut: https://www.youtube.com/watch?v=W2T_lihBs9I
A digital rishi.
Thank you for sharing this. This is really interesting.
Dam emacs people are really built different ;p
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.
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.
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.
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.
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.
What a great find. Not sure why I have not discovered Prot before. Bookmarked the article and this thread.
I have been using Emacs for about 40 years, and as a crazy side effect of the mountain of LLMs hype, with a lot of productivity enhancing goodness, I think that Emacs can only gain in popularity because of several excellent Emacs LLMs packages. Most of the world is exploiting LLMs with VSCode and its variants, but Emacs is also just about perfect for integrating LLMs into workflows and for having fun and playing around.
I have been using Emacs for about 40 years, and as a crazy side effect of the mountain of LLMs hype, with a lot of productivity enhancing goodness, I think that Emacs can only gain in popularity because of several excellent Emacs LLMs packages. Most of the world is exploiting LLMs with VSCode and its variants, but Emacs is also just about perfect for integrating LLMs into workflows and for having fun and playing around.
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.
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.
> 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.
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.
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.
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.
> 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.
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.
[deleted]
I don't see what any of that has to do with namespaces. You can have all of that and not clobber your functions together. It's just a way to delineate groups of functions, not a organizational mandate.
Same with lexical scoping? Not really following you.
Same with lexical scoping? Not really following you.
Lexical scoping is now available as a toggle and recommended for ELisp code, but Emacs was a mature project and ecosystem when this was introduced, so people know when to use it or not use it. Most languages and environments that start with lexical scoping don't even provide dynamic scoping as an option, failing to recognize when it's useful. And to be fair, it's primarily useful in the thing that Emacs does way more than most software - that is, the ability for some code to override behavior of other code up the call stack, regardless of how that other code got to be called, and without involving intermediate callees in this.
(Or, in short, what you're doing each time you're setting environment variables in a shell call. Environment variables are dynamic scoping, just one level up.)
Namespaces are mostly fine if they're only helping against name clashes, and not trying to do access control. Even then, given the Lisp nature and high extensibility of Emacs (two sides of the same coin, actually), normal namespaces you see in other programming languages are a bad fit, as they don't play well with symbols and various patterns around using symbols as designators resolved at runtime. You'd need a namespacing solution like packages in Common Lisp, which is quite different than what people are used to.
In general, none of that would be a show-stopper - it's more that Emacs always leaned on being easy to extend, including extend interactively (via REPL, or more commonly, just selecting and eval-ing blocks of code), and things like namespaces tend to make it more annoying.
(Or, in short, what you're doing each time you're setting environment variables in a shell call. Environment variables are dynamic scoping, just one level up.)
Namespaces are mostly fine if they're only helping against name clashes, and not trying to do access control. Even then, given the Lisp nature and high extensibility of Emacs (two sides of the same coin, actually), normal namespaces you see in other programming languages are a bad fit, as they don't play well with symbols and various patterns around using symbols as designators resolved at runtime. You'd need a namespacing solution like packages in Common Lisp, which is quite different than what people are used to.
In general, none of that would be a show-stopper - it's more that Emacs always leaned on being easy to extend, including extend interactively (via REPL, or more commonly, just selecting and eval-ing blocks of code), and things like namespaces tend to make it more annoying.
Dynamic scoping is a feature in the Emacs ecosystem. It plays a similar role to dependency injection in other languages. It is what allows you to change global state for some function call. Dynamic scoping together with buffer-local, file-local, directory-local variables is similar to scopes in dependency injection libraries --- a powerful organizational tool.
A better way of phrasing that would be: "It's entirely possible to create a rotting hot mess while following all the best practices. It's also possible to create a very good program while ignoring some of the best practices".
> Emacs Lisp', Now With Namespaces
Do you mean lexical binding, available as an option since 24.1?
Do you mean lexical binding, available as an option since 24.1?
I mean namespaces, like Common Lisp namespaces.
It does have those:
*** Welcome to IELM *** Type (describe-mode) or press C-h m for help.
ELISP> +
*** Eval error *** Symbol’s value as variable is void: +
ELISP> #'+
+
Yes I meant packages :)
> My theory: what matters isn't "best practices", it's have a coherent conceptual design and code that reflects that design.
I think so too; that said, the language could definitely be better. It suffers from a lot of primitive obsession. Instead of structs, you often find either vectors or lists with predefined element positions; instead of map, ordered map, and multimap types, it's just various kinds of lists everywhere. They're not even used consistently: for the same thing, one package may use an alist and another a plist.
I think so too; that said, the language could definitely be better. It suffers from a lot of primitive obsession. Instead of structs, you often find either vectors or lists with predefined element positions; instead of map, ordered map, and multimap types, it's just various kinds of lists everywhere. They're not even used consistently: for the same thing, one package may use an alist and another a plist.
Yeah, I could also see some improvements like that. But, compared to other codebases I've worked with that had the same problem (cough nixpkgs cough), it's amazing how much better the Emacs programming experience has been.
Yes, nixpkgs is definitely missing the self-documenting part, or even the documenting part for most of it.
I’ve consistently failed to make writing elisp net positive for me for basically anything. I use it as a configuration language, and even then, for functions longer than a few lines, it’s still a lot of coding for very little benefit. I just can’t find things to improve in such a way that it’ll actually be worth writing elisp code for, especially compared to other tools (like a quick Python script or even a bash one-liner), or things within Emacs. What are the things you’ve written in elisp that have helped you?
> I’ve consistently failed to make writing elisp net positive for me for basically anything.
That's sad to hear, because I somehow have the exact opposite experience. First, it was about fixing things in my config. Then I often would catch myself in a "why can't I do this better" state. And it could be anything. Like one day I was copying the current URL in the browser, and then switched again to copy the description. Next day I caught myself doing that again. And I realized - "shit, I never thought before how often I have to do this crap". Then I wrote a helper.
These days, I don't even blink, if I need something, I'll just start whipping up some shitty Elisp in my scratch buffer. And with help of LLM packages like gptel - it's a breeze. What's awesome is that I can play with that code even without having to save that shit anywhere. Sometimes, I realize the solution is not as easy to make as I initially thought, so I'd just leave it there in my scratch buffer. It sits there, sometimes marinating for weeks - I have a persistent scratch buffer. I even get excited when I stumble on a problem I want to optimize.
Few weeks ago I was in a pair-programming Zoom, and my colleague, let's call them Matthew, was screen sharing. I couldn't help distracting Matt asking questions like, what is that? Can you share this link? Wait a minute, don't scroll away, I need to write that down. etc.
After that I thought of solving that dilemma. I sat down and wrote a helper that calls tesseract to OCR text from an image in clipboard. Took me no more than 20 minutes. https://github.com/agzam/.doom.d/blob/main/modules/custom/wr...
That's sad to hear, because I somehow have the exact opposite experience. First, it was about fixing things in my config. Then I often would catch myself in a "why can't I do this better" state. And it could be anything. Like one day I was copying the current URL in the browser, and then switched again to copy the description. Next day I caught myself doing that again. And I realized - "shit, I never thought before how often I have to do this crap". Then I wrote a helper.
These days, I don't even blink, if I need something, I'll just start whipping up some shitty Elisp in my scratch buffer. And with help of LLM packages like gptel - it's a breeze. What's awesome is that I can play with that code even without having to save that shit anywhere. Sometimes, I realize the solution is not as easy to make as I initially thought, so I'd just leave it there in my scratch buffer. It sits there, sometimes marinating for weeks - I have a persistent scratch buffer. I even get excited when I stumble on a problem I want to optimize.
Few weeks ago I was in a pair-programming Zoom, and my colleague, let's call them Matthew, was screen sharing. I couldn't help distracting Matt asking questions like, what is that? Can you share this link? Wait a minute, don't scroll away, I need to write that down. etc.
After that I thought of solving that dilemma. I sat down and wrote a helper that calls tesseract to OCR text from an image in clipboard. Took me no more than 20 minutes. https://github.com/agzam/.doom.d/blob/main/modules/custom/wr...
I wrote a few simple helpers for special things I want to do in (mostly) org-mode, but 99% of "my" elisp is code that I copy-pasted into init.el from someone else. I love that small additions like that can be done by pasting a few lines of elisp into init.el instead of having to depend on full packages.
A few days ago I happened to see my 1998 .emacs file in an old backup. It was only around 100 lines, but I think most of those lines have survived into my current init.el. The oldest lines are probably over 30 years old now. The API is reasonably stable, but not perfect. My current file has lots of logic to handle running in older Emacs versions.
A few days ago I happened to see my 1998 .emacs file in an old backup. It was only around 100 lines, but I think most of those lines have survived into my current init.el. The oldest lines are probably over 30 years old now. The API is reasonably stable, but not perfect. My current file has lots of logic to handle running in older Emacs versions.
> What are the things you’ve written in elisp that have helped you?
Usually tools to alleviate working with dumbass web-based (supposedly needing the corporate-approved browser) stuff for $DAY-JOB.
Oh, and an extension to allow emacs-w3m to handle lynx-style multibookmarks.
Usually tools to alleviate working with dumbass web-based (supposedly needing the corporate-approved browser) stuff for $DAY-JOB.
Oh, and an extension to allow emacs-w3m to handle lynx-style multibookmarks.
> > What are the things you’ve written in elisp that have helped you?
>
> Usually tools to alleviate working with dumbass web-based (supposedly needing the corporate-approved browser) stuff for $DAY-JOB.
>
> Oh, and an extension to allow emacs-w3m to handle lynx-style multibookmarks.
This sparks my interest as I am in the early days of both customizing Emacs and attempting to displace some of my browsing with it as well. Could you elaborate further on this multibookmarks concept and perhaps an example of one of those alleviations for working with web-based workflows?
This sparks my interest as I am in the early days of both customizing Emacs and attempting to displace some of my browsing with it as well. Could you elaborate further on this multibookmarks concept and perhaps an example of one of those alleviations for working with web-based workflows?
Lynx is a web browser, bookmarking a page is done by hitting "adX" as in (a)dd (d)ocument to file (X). Or (a)dd (l)ink to (X). Nice and quick.
The X is usually a lower case ASCII letter corresponding to a file. You can enable this mode (and the specific bookmark files) in lynx's config file. The Emacs extension uses the same keystrokes and, optionally, the same files.
Alleviations are (I'm intentionally vague here) for getting rid of finding a link, clicking through, repeat, repeat, repeat, repeat, just to get to where I need to be (like adding an update to a ticket). I usually only automate processes that are intended for use by mouse/pointer-driving users with an ability to comprehend what (and where) icons are - I have a self-imposed problem withe former and a physically/mentally imposed hard time with the latter.
Alleviations are (I'm intentionally vague here) for getting rid of finding a link, clicking through, repeat, repeat, repeat, repeat, just to get to where I need to be (like adding an update to a ticket). I usually only automate processes that are intended for use by mouse/pointer-driving users with an ability to comprehend what (and where) icons are - I have a self-imposed problem withe former and a physically/mentally imposed hard time with the latter.
The biggest things have been utilities for running shells in Emacs (totally changed my day-to-day programming workflow for the better) and org-mode stuff (notes, slides for presentations, todos/scheduling/etc)
But a lot of other things have been more like small conveniences or one-off improvements—things that would not make sense if they took more than 20 minutes to write, but do make sense in Emacs. A few random examples: some custom ways to enter Unicode characters; a command to insert TODO comments; a different way to manage Emacs windows; a little package for jumping to locations I care about; a way to insert a file path into a buffer; a work-specific tool to go from UUIDs to internal URLs; some random stuff for authoring a book with Pandoc + LaTeX; a command to insert Haskell LANGUAGE pragmas (contributed upsteam!); and a bunch more that I'm forgetting.
As a bonus, writing these meant I didn't have to "learn" them in the sense that I know they exist and, if I gave them a keybinding, I did not have to memorize it.
None of these are a big deal on their own! But having an environment that reduces the friction to make small improvements is. Having a tool that I can orient around the way I want to work is qualitatively different from having a tool that makes me orient around how it works.
It's not even that much customization in some absolute sense; everything fits into a few thousand lines of Elisp spread across a few files in my dotfiles repo[1].
[1]: https://github.com/TikhonJelvis/dotfiles/tree/main/home/emac...
But a lot of other things have been more like small conveniences or one-off improvements—things that would not make sense if they took more than 20 minutes to write, but do make sense in Emacs. A few random examples: some custom ways to enter Unicode characters; a command to insert TODO comments; a different way to manage Emacs windows; a little package for jumping to locations I care about; a way to insert a file path into a buffer; a work-specific tool to go from UUIDs to internal URLs; some random stuff for authoring a book with Pandoc + LaTeX; a command to insert Haskell LANGUAGE pragmas (contributed upsteam!); and a bunch more that I'm forgetting.
As a bonus, writing these meant I didn't have to "learn" them in the sense that I know they exist and, if I gave them a keybinding, I did not have to memorize it.
None of these are a big deal on their own! But having an environment that reduces the friction to make small improvements is. Having a tool that I can orient around the way I want to work is qualitatively different from having a tool that makes me orient around how it works.
It's not even that much customization in some absolute sense; everything fits into a few thousand lines of Elisp spread across a few files in my dotfiles repo[1].
[1]: https://github.com/TikhonJelvis/dotfiles/tree/main/home/emac...
I wasn’t satisfied with any of the pop up terminal libraries so I threw my own together in less than 50 LoC
Don't forget the self-documenting aspect. The manual is included, the api documentation is included, you can ask emacs which command is executed when you click somewhere or when you press a button. I recently tried to do the same thing in Intellij, pita. Not only, can you find documentation, you can jump to the source code, inspect variable values at runtime, and debug or profile everything. All of that from inside the environment.
Absolutely!
Seems like the conceptual design helped with that too, reducing the activation energy needed for clear, interactive documentation. The code and the UI are both designed against the same set of consistent concepts, which naturally brings them together and, in turn, makes it so much easier to tie them from one to another. Simplest example: every interaction in the UI is a "command" and commands are reflected in elisp, so having a way to jump from an interaction to the corresponding code and documentation just makes sense. The documentation can be organized along the same conceptual lines as the code and the UI.
Emacs really is an amazing design study.
Seems like the conceptual design helped with that too, reducing the activation energy needed for clear, interactive documentation. The code and the UI are both designed against the same set of consistent concepts, which naturally brings them together and, in turn, makes it so much easier to tie them from one to another. Simplest example: every interaction in the UI is a "command" and commands are reflected in elisp, so having a way to jump from an interaction to the corresponding code and documentation just makes sense. The documentation can be organized along the same conceptual lines as the code and the UI.
Emacs really is an amazing design study.
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.
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.
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.
Still, another manual written from a different perspective probably won’t hurt anything.
The Gnus manual in particular has certain whimsical Pratchett-esque charm to it that I love so much.
The manual (https://www.gnus.org/manual.html) starts with:
> See what the critics say about the manual:
> “Often when I read the manual, I think that we should take a collection up to have Lars psycho-analysed.”
> See what the critics say about the manual:
> “Often when I read the manual, I think that we should take a collection up to have Lars psycho-analysed.”
One reasons Prot himself was able to become a bonafide Emacs Guru in just a few years is because he's the kind of person who reads manuals. He speaks highly of the included docs, and often credits them for his knowledge.
And he wasn’t even a programmer by trade. AFAIK he used to work in Brussels at the European Commission, he started using Emacs for his writing and taught himself Emacs Lisp as a first programming language, probably by diving deep into the Emacs manual.
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)
[deleted]
Great! This could serve as an easy introduction for users new to Elisp.
Hmm, there seems to be no mention of dynamic vs. lexical binding, which is a difference from some other Lisps I was hoping to gain some insight on.
If you're still interested: https://www.gnu.org/software/emacs/manual/html_node/elisp/Le.... Basically modern Emacs Lisp works like Common Lisp.
Nice - I feel this introductory guide fills a gap. Also, I really like his video tutorials.
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