I think this book would be perfect for me - I have been using Emacs for quite a while, but never mastered elisp: I could never figure out how to structure things properly.
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:
In the first chapter, it tells you basically how to find Elisp functions doing things you need.
In the second, longest chapter, it walks you through writing a complete, useful package, showcasing lots of Elisp features and good practices.
In the third, last chapter, it hints at a few more advanced techniques – functional programming, lexical scoping and regular expressions.
This made me a lot more excited about the contents!
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:
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 │ )
> 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]"!
Uh... well, it would be even more embarassing to admit how long I've been telling myself that I'd start learning emacs-lisp in earnest... so I won't. :)
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!
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.
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.
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).
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.
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.
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.
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.”
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.
> 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.
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.
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.
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.
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.
> 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.
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.
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.
-----ADDED-----
Downloaded 27.2:
Emacs Lisp: 1,171,507
C : 318,611
C Headers : 43,738
(that's without comments)
That's a lot of code to replace, and again, just what's in the core distribution.
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!