My Emacs Lisp book is finished(mbork.pl)
mbork.pl
My Emacs Lisp book is finished
http://mbork.pl/2021-11-06_The_Emacs_Lisp_book_is_finished
63 comments
> I have been using Emacs for quite a while, but never mastered elisp
You are not alone in that boat :-)
You are not alone in that boat :-)
As a developer, I find it a bit embarassing that I started using Emacs in 2000, that at some point I even read my email with it, and that I never took the time to really learn emacs-lisp. Still, some day I will. This book might help me. :)
I'm just a devops person, not a coder by any stretch of the imagination, but I found that maintaining my .init.el in git helped me to learn enough elisp to be useful/dangerous.
I really dig that it's a full on language used for the configuration files. It just makes so much sense to do it that way. (I also like VSCode's json prefs)
Also I love sharing snippets of my .init.el:
I really dig that it's a full on language used for the configuration files. It just makes so much sense to do it that way. (I also like VSCode's json prefs)
Also I love sharing snippets of my .init.el:
40 │ ;; Taken from https://karl-voit.at/2017/02/11/my-system-is-foobar/
41 │ ;; Check if system is Darwin/macOS
42 │ (defun my-system-type-is-darwin ()
43 │ "Return non-nil if system is darwin-based (Mac OS X)."
44 │ (string-equal system-type "darwin")
45 │ )
...
65 │
66 │ (when (my-system-type-is-darwin)
67 │ ;; EXAMPLE: (global-set-key (kbd "C-z") 'shell)
68 │ ;; https://www.gnu.org/software/emacs/manual/html_node/emacs/Init-Rebinding.html#Init-Rebinding
69 │ (global-set-key (kbd "s-/") 'comment-or-uncomment-region-or-line)
70 │ (global-set-key (kbd "s-<backspace>") '(lambda () (interactive) (kill-line 0)))
71 │ )system-type is actually a symbol, so you can do (eq system-type 'darwin) for the same effect. here's my macOS section: https://github.com/bklebe/.emacs.d/blob/b0ca255032d1240942ff...
Nice! I'll definitely take a close look at that.
> I found that maintaining my .init.el in git helped me to learn enough elisp to be useful/dangerous.
The snippets you gave of your init.el are really basic but I do agree with you: working on init.el (and using Git to revert SNAFUs) helped me learn enough elisp to be dangerous too.
The elisp I write is certainly not idiomatic but it gets the job done. I have some functions I wrote more than a decade ago and they still "Just Work [TM]"!
The snippets you gave of your init.el are really basic but I do agree with you: working on init.el (and using Git to revert SNAFUs) helped me learn enough elisp to be dangerous too.
The elisp I write is certainly not idiomatic but it gets the job done. I have some functions I wrote more than a decade ago and they still "Just Work [TM]"!
[deleted]
I would love a dead tree version too. I've never managed to get on well with ebooks and PDFs.
I've been happily reading the updates as they were released. Fell behind on the last one, actually. Very fun book that I think shines for showing some fun of using emacs. Highly recommended!
I felt like Superman the first time I hacked some emacs lisp. One of the most enjoyable programming experiences of my life. Thanks for this book.
Great to see resources being created for Emacs.
How does this compare to https://www.gnu.org/software/emacs/manual/html_node/elisp/in... ? That's a great manual and available in Info format (popular amongst Emacs users).
How does this compare to https://www.gnu.org/software/emacs/manual/html_node/elisp/in... ? That's a great manual and available in Info format (popular amongst Emacs users).
Ah it sits between the intro ( https://www.gnu.org/software/emacs/manual/html_mono/eintr.ht... ) and the reference manual.
Thanks for the submission. I was hoping it would be finished and didn't want to purchase an incomplete book, so it's helpful.
i have used "Writing GNU Emacs Extensions" available here: https://www.oreilly.com/library/view/writing-gnu-emacs/97814... from a long time past for elisp programming.
mentioning it here in the hope that it is is useful to others as well...
mentioning it here in the hope that it is is useful to others as well...
I've still got my physical copy and will never get rid of it.
Since that book is over 20 years old, is it still relevant and useful?
Yes.
Emacs takes backwards compatibility seriously. Not kernel-level seriously, but seriously.
Moreover, a book written 20 years ago was still written more than 20 years after initial Emacs release. By then, a lot of best practices were already discovered and they remain common in Elisp code to this day.
There was a lot of development in that time and many things became easier to do, but the basics of writing Elisp programs didn't change.
IMO the book is especially worth a read if you want to change your perspective: it does a really good job at showing that Emacs is, in essence, a runtime environment and a development platform akin to web browsers, with a huge stdlib of libraries and applications, and focused on mostly-text display. Next time you find yourself reaching for ncurses, stop and go for Elisp instead. You'll get the (optional) GUI and sane defaults for free, along with rich text editing functionality where needed.
Emacs takes backwards compatibility seriously. Not kernel-level seriously, but seriously.
Moreover, a book written 20 years ago was still written more than 20 years after initial Emacs release. By then, a lot of best practices were already discovered and they remain common in Elisp code to this day.
There was a lot of development in that time and many things became easier to do, but the basics of writing Elisp programs didn't change.
IMO the book is especially worth a read if you want to change your perspective: it does a really good job at showing that Emacs is, in essence, a runtime environment and a development platform akin to web browsers, with a huge stdlib of libraries and applications, and focused on mostly-text display. Next time you find yourself reaching for ncurses, stop and go for Elisp instead. You'll get the (optional) GUI and sane defaults for free, along with rich text editing functionality where needed.
Are there any good guides or examples on using elisp to build an environment like ncurses?
You can take a look at basically any of the larger apps, like M-x magit, speedbar, neotree, treemacs, calc, undo-tree, proced, tetris, gnus, epa, dired... (some built-in, some 3rd party). By default, when you start Emacs, you are in the lisp-interaction-mode app, which allows you to write (and execute) Elisp code. But, if you start any of the apps above, you'll get window(s) with semantics having nothing in common with editing text. They still display with text (or emoji under GUI), but they treat the buffer contents as something else than just text, and you can create panes with such content anywhere on the screen. I think this is more or less what you get with ncurses.
Here's an example of Emacs running in the terminal with a few apps open: https://klibert.pl/statics/images/emacs_terminal.png You can see treemacs, helm, dired and magit in action.
I could probably give a better example if you said what exactly you'd like to build. There's a lot of apps written for Emacs, not many of them are truly standalone (meaning they tend to integrate into Emacs instead of integrating Emacs into the app), but there are a few like that, too (ie. music players or games).
Here's an example of Emacs running in the terminal with a few apps open: https://klibert.pl/statics/images/emacs_terminal.png You can see treemacs, helm, dired and magit in action.
I could probably give a better example if you said what exactly you'd like to build. There's a lot of apps written for Emacs, not many of them are truly standalone (meaning they tend to integrate into Emacs instead of integrating Emacs into the app), but there are a few like that, too (ie. music players or games).
Thanks, this is a good starting point for me.
Ok, thanks, good to know.
Pretty much, yes. I'm sure there's a few things that have changed, and a newer book is welcome, but Emacs hasn't really changed much in 30 years.
I don't know my Emacs timeline very well, but I'd be nervous about lexical scope and the more recent cooperative async features of Emacs (lisp) not being represented in a 20 year old book.
EDIT: Yeah, Emacs 24 had support for lexical scope, and that was in 2012. You'd be doing a disservice to yourself, IMO, to write dynamically scoped Elisp today, unless you had a specific reason. And if you don't even KNOW that lexical scoping is an option, it would be unfortunate.
EDIT: Yeah, Emacs 24 had support for lexical scope, and that was in 2012. You'd be doing a disservice to yourself, IMO, to write dynamically scoped Elisp today, unless you had a specific reason. And if you don't even KNOW that lexical scoping is an option, it would be unfortunate.
I checked the book's TOC and was surprised to see that lexical scoping was introduced in the last chapter.
https://github.com/alphapapa/emacs-package-dev-handbook#lexi... says using lexical scoping is a best practice.
https://github.com/alphapapa/emacs-package-dev-handbook#lexi... says using lexical scoping is a best practice.
This is very exciting and I will definitely be looking into this when I have a little more time! I’ve tried writing my own Emacs packages before, and I have never felt like I knew what I was doing. A guided tutorial like this is filling an important hole in the Emacs documentation I feel.
Also, I love the Brandon Sanderson quote. Absolutely excellent epic fantasy.
Also, I love the Brandon Sanderson quote. Absolutely excellent epic fantasy.
as author calls it "intermediate-level book", what would be a more suitable resource for an elisp beginner?
thanks! I thought whole gnu manual is a dry reference, but linked intro looks exactly what I was looking for!
https://www.gnu.org/software/emacs/manual/html_node/eintr/Wh...
"Emergency Elisp" by Steve Yegge.
I'm on mobile but check the sample, the author mentions an introductory resource.
Cool, always glad to see more Emacs stuff out there.
Congratulations!
As a curiosity, how did you set the page width?
I find it a bit wide, making it difficult to read.
As a curiosity, how did you set the page width?
I find it a bit wide, making it difficult to read.
Sokolof's comment elsewhere in this thread: Intro of the book confirms: “It is written in Org-mode, first made by Carsten Dominik and then developed by many other people. Diego Zamboni wrote the Org exporter to convert Org-mode syntax to Markua, expected by Leanpub.”
So the page width probably was set by Leanpub themselves during typesetting. I am assuming that the Markua language is converted to LaTeX, with the page size/layout being set in that language.
So the page width probably was set by Leanpub themselves during typesetting. I am assuming that the Markua language is converted to LaTeX, with the page size/layout being set in that language.
But did you write it in Emacs, using Texinfo? ;)
I would bet it was written in orgmode.
Intro of the book confirms: “It is written in Org-mode, first made by Carsten Dominik and then developed by many other people. Diego Zamboni wrote the Org exporter to convert Org-mode syntax to Markua, expected by Leanpub.”
For anyone else curious about Markua: https://leanpub.com/markua/read
Any chance you offer regional pricing?
Eh is the book GPL though :-/ Can somebody confirm
I enjoyed reading the O'Reilly "Writing Emacs Extensions" book years ago. I just never got into the mode of using Elisp on a daily basis and it's faded from memory.
I'm excited about this book. And, I really wish there was a book that showed how a developer using a more modern language like JavaScript could use it to customize Emacs.
This is why VSCode is winning, because it embraces modern languages in a really powerful way. When I install a new Emacs into a new debian machine, i still struggle to get package installation working. But I'm getting really worried about the direction Microsoft is taking with VSCode and wish I could be as productive in Emacs. Opening up that environment to modern developers who could tweak their own tools would be amazing and revolutionary.
I'm excited about this book. And, I really wish there was a book that showed how a developer using a more modern language like JavaScript could use it to customize Emacs.
This is why VSCode is winning, because it embraces modern languages in a really powerful way. When I install a new Emacs into a new debian machine, i still struggle to get package installation working. But I'm getting really worried about the direction Microsoft is taking with VSCode and wish I could be as productive in Emacs. Opening up that environment to modern developers who could tweak their own tools would be amazing and revolutionary.
Try neovim to see what this approach might look like, yes it's vi not emacs, but they allow python and rust plugins and have a plugin framework now. It's killed sublime for me. And I used to use emacs over vi.
Personally I'd like emacs a lot more if it's plugins system just worked like vscodes does and as you said let me use languages I'm familiar with.
Personally I'd like emacs a lot more if it's plugins system just worked like vscodes does and as you said let me use languages I'm familiar with.
Unfortunately it looks like it's a dead project, but https://github.com/kiwanami/emacs-epc builds out an RPC framework for emacs. This would theoretically allow you to use any language you want. The repo shows node.js, python, and ruby integration.
> This is why VSCode is winning, because it embraces modern languages in a really powerful way.
This notion that Javascript is superior to (e.g. elisp) because JS is new and elisp is "old" is really irritating. The reasons JS exists has absolutely zero to do with any issues with elisp or lisp or C or haskell or any other programming language. The fact that you know it and do not know elisp is a real thing, but it says nothing about the qualities and properties of either language.
This notion that Javascript is superior to (e.g. elisp) because JS is new and elisp is "old" is really irritating. The reasons JS exists has absolutely zero to do with any issues with elisp or lisp or C or haskell or any other programming language. The fact that you know it and do not know elisp is a real thing, but it says nothing about the qualities and properties of either language.
its such an absurd idea. look at the top contributors for VSCode, and how many of them are employed at Microsoft:
https://github.com/microsoft/vscode/graphs/contributors
How can you possible separate vscode "winning because of javascript" and "it has development budget X times the budget of Emacs"
https://github.com/microsoft/vscode/graphs/contributors
How can you possible separate vscode "winning because of javascript" and "it has development budget X times the budget of Emacs"
No one said it was superior, but more people know it.
The claim was the VSCode is "winning" because it "embraces modern languages". To me that implies at least some kind of superiority.
No, it doesn’t, it implies that it uses a language which is widespread and most everyone knows. Languages themselves being superior tends to be an opinion.
> "Most everyone knows".
Pardon my age or something. but if you're a software developer who doesn't work on web-dev, you probably do not know JS, certainly not enough to code much in it.
Maybe "most everyone" leaves enough room to describe all the people who do embedded and native development - I don't know the actual numbers.
But the sentence didn't say: "VSCode is winning because its extension language widespread and most everyone knows it". It said "modern languages". Haskell is a modern language. Rust is a modern language. Lua is a modern language. If VSCode (somehow) used them as its extension language, would it still be winning? Clearly, no.
Pardon my age or something. but if you're a software developer who doesn't work on web-dev, you probably do not know JS, certainly not enough to code much in it.
Maybe "most everyone" leaves enough room to describe all the people who do embedded and native development - I don't know the actual numbers.
But the sentence didn't say: "VSCode is winning because its extension language widespread and most everyone knows it". It said "modern languages". Haskell is a modern language. Rust is a modern language. Lua is a modern language. If VSCode (somehow) used them as its extension language, would it still be winning? Clearly, no.
I should have said "modern and more popular languages." For the record, I like elisp/lisp, I just don't use them at my day job and have a hard time customizing emacs with them. Emacs is still my favorite editor, but for my day job, I can get much more done in VSCode because it "embraces" (whatever that means) JS much better than Emacs. I wish it wasn't so, and I'm worried about it long term.
Elisp is a really poor language compared to almost anything else, more work should be done to allow Emacs to be configured in other languages.
> Elisp is a really poor language compared to almost anything else
What makes Elisp a "poor language" in your opinion?
Elisp is actually a really good language. Especially compared to other languages used for scripting, like Lua or JS. In some areas Elisp is significantly more advanced than either: pattern matching (pcase, dash), object orientation (multimethods, multiple inheritance), iteration (loop), data types (Lua has 3, JS a bit more, while Elisp gives you lists (pairs, proplists, assoc lists, trees), vectors, maps, unicode strings with optional metadata, queues, rings, and more. While the lack of reader macros is unfortunate, the macro system along with hooks and advice allow for writing libraries that integrate seamlessly into the environment, and ones that cleanly hide a lot of complexity (ie. use-package). Additionally, Elisp performance is not very bad (though of course worse than JITed languages) and it got AOT native compiler recently, which should help improve upon it.
Namespaces are the only lacking feature at this point. I mean, there are lots of places where Elisp could and should be improved, but it's in quite good shape already. Definitely not "really poor", especially compared to the other scripting languages.
What makes Elisp a "poor language" in your opinion?
Elisp is actually a really good language. Especially compared to other languages used for scripting, like Lua or JS. In some areas Elisp is significantly more advanced than either: pattern matching (pcase, dash), object orientation (multimethods, multiple inheritance), iteration (loop), data types (Lua has 3, JS a bit more, while Elisp gives you lists (pairs, proplists, assoc lists, trees), vectors, maps, unicode strings with optional metadata, queues, rings, and more. While the lack of reader macros is unfortunate, the macro system along with hooks and advice allow for writing libraries that integrate seamlessly into the environment, and ones that cleanly hide a lot of complexity (ie. use-package). Additionally, Elisp performance is not very bad (though of course worse than JITed languages) and it got AOT native compiler recently, which should help improve upon it.
Namespaces are the only lacking feature at this point. I mean, there are lots of places where Elisp could and should be improved, but it's in quite good shape already. Definitely not "really poor", especially compared to the other scripting languages.
Emacs and Elisp are too intertwined at this point. This interview https://www.youtube.com/watch?v=LKegZI9vWUU of the creator of Doom Emacs talks about this exact problem.
Maybe if you would elaborate on why you think that, you would not be down voted so much. Having said that, if you don't like it maybe you should find an editor that suits you more?
To be fair, the parent is not talking about the editor but rather its configuration language. Indeed, there have been attempts to replace elisp with other languages, such as Scheme (guile) and Common Lisp.
There is apparently a Guile enabled version of Emacs available.
https://www.emacswiki.org/emacs/GuileEmacs
https://www.emacswiki.org/emacs/GuileEmacsBuild
https://www.emacswiki.org/emacs/GuileEmacs
https://www.emacswiki.org/emacs/GuileEmacsBuild
Can you give some reasons why you dislike Elisp?
What language would you re-write Emacs configurations in?
What language would you re-write Emacs configurations in?
I believe your second question needs to be rephrased as "What language would you re-write Emacs in?"
I don't remember what the core to elisp fraction is, but it's not that big.
I don't remember what the core to elisp fraction is, but it's not that big.
Emacs is written in C and Emacs Lisp. I’m not able to download the source right now, but from some googling the C portion is around 20-25%. So 75-80% lisp. That’s a rather substantial amount of code that would need to be rewritten, not to mention that probably does not include all the lisp code that’s not included in the core distribution. Tons of packages out there that would need to be rewritten.
That's a lot of code to replace, and again, just what's in the core distribution.
-----ADDED-----
Emacs Lisp: 1,171,507
C : 318,611
C Headers : 43,738
That's a lot of code to replace, and again, just what's in the core distribution.
Dude, I think you might have a problem
Looking at the book landing page, I think I would have passed on it because the Table of Contents make it look a bit like the book is just covering specific tasks (about rearranging sentences) rather than general tasks, like using best practices for creating packages.
It would be good to include the paragraph from your blog in the book landing page:
This made me a lot more excited about the contents!