6 ms·

In common understanding of emacs, its use of lisp recieves perhaps too much attention, while its overall wonderful architecture is underappreciated. Emacs isnt

by stiff 13y ago

In common understanding of emacs, its use of lisp recieves perhaps too much attention, while its overall wonderful architecture is underappreciated. Emacs isnt just an editor with embedded lisp, its more a vm for bootstrapping editors. You could do an emacs with python, but the hard part is providing an environment where the extensions dont interfere with the user input loop, with buffer redisplay etc., while still staying easy to write. The emacs buffer-based async handling of external processes is a masterpiece of software engineering, much better than things like unix pipes. Doing extension languages for interactive programs is much harder than it seems at first, and emacs is a prime example of doing it right.

leephillips 13y ago
"The emacs buffer-based async handling of external processes is a masterpiece of software engineering, much better than things like unix pipes." This sounds intriguing. Do you have a pointer to something I could read that might expand on what you're saying here? (Aside from the emacs source.) Amusing coincidence: the only Pratchet book I've read is The Fifth Elephant.
- mr_luc 13y ago
  Seconded! Like a lot of Emacs users, sure, I love Lisp. But I don't really understand how it's architected. Sure, I understand that there is this abstraction of a Buffer. But it's quite abstract. I'd love to know what's happening under the hood. I think a blog post that even gave a 37signals-blog-post-sized expansion of the grandparent's comment would probably be frontpaged on HN.
- thirdtruck 13y ago
  Just wanted to recommend reading more Pratchett. :) I bought a couple more novels last week and couldn't help but finish one (Equal Rites) less than twenty four hours later.
  - terhechte 13y ago
    I've read more than 20 Pratchett books (I think I didn't read the last 2-3) and there're two absolutely great books among them: - Nightwatch: Great idea, fantastically written - Going Postal: Great book for everybody who reads HN. Great characters, storyline, and fantasy meets hacking.
    - thirdtruck 13y ago
      And I very nearly picked up both of those that night. I'd grab them right away if my physical to-read stack didn't already stand a few feet high.
    - zem 13y ago
      my top two as well! third is probably "men at arms"
    - mjcohen 13y ago
      That latter title made me think of the story "Spacial Delivery" by Gordon Dickson in his collection 'The Right to Arm Bears'. A fun read.
    - thirdtruck 13y ago
      Having just listened to the Snuff audio book, I can't wait to read/hear the further adventures of the Nightwatch and its captain.
- stiff 13y ago
  I will try to explain. When I came to emacs as a user, a "buffer" seemed just a weird way of saying "tab" without displaying actual tabs. The word choice only started making more sense once I wrote non-trivial amounts of emacslisp. The buffer is the fundamental emacs data structure, like the file is the fundamental unix data structure, so it's really important to understand it well. The definition is really simple: a buffer is just a bunch of text from some unknown source, but in fact it is a very powerful abstraction, for two reasons. First, every time you do something in Emacs when simply editing files, you are really executing emacslisp functions on the buffer that is currently displayed. A lot of things you learn in Emacs can be used in three ways: interactively in editing sessions, when automating editing tasks with emacslisp, and finally when doing programming in general, even when it has nothing to do with editing files. Second, a buffer can represent anything, it can of course contain the text of a file, but also of only fragments of a file, or a directory file listing, and, what's really great, Emacs binds TCP/FTP/HTTP/... network connections and external processes to buffers as well, allowing asynchronous streaming of incoming data into buffers, so that a emacslisp callback is called every time new text arrives from the process or socket, you can transform it as you wish and insert into the buffer the part to be shown to the user or kept for future processing. Then there are lisp primitives implemented in C like save-excursion which let you execute functions on buffer off-screen, so the same commands that are used for editing can be used for processing HTTP requests or grep output without the user noticing the cursor jumping back and forth or anything of this kind. So, when I am processing HTTP requests in Emacs, I use the same commands I sometimes use in interactive editing sessions, for example I can use re-search-forward to check if the headers were sent completely already and to get number of bytes they contain (the location in the buffer of the end of the headers, in other words). A lot of the weird emacs word like point, mark etc. that seem like anachronistic words for interface elements really are powerful abstractions that apply as much to programming as to the interactive editing. Then there is a lot of other stuff that makes this yet more powerful, you can have buffer-local variables, timers that check buffer input periodically, transaction queues for those asynchronous processes, modes that define buffer-specific key-bindings, menus and behaviours etc., it goes on an on. It's a lot like node.js or other asynchronous networking stacks. There is also lot of magic that makes all this work concurrently without Emacs having implemented threads, and that makes it not interfere with the user interface. A lot of the cool things Emacs does follows from this architecture, like the SLIME package for interacting with Common Lisp interpreters (local or remote), Dired for editing directory contents, Tramp for editing files on remote servers, Comint for running interactive processes of various kind inside Emacs etc. It's a really great lesson in how naturally features flow out of powerful design ideas. As for resources, I learnt by reading the GNU Emacs Lisp Reference [1], and have done a lot of M-x describe-function and source code reading in the process of writing some elisp more sophisticated than just small editing helpers. E.g. the process stuff is described here: http://www.gnu.org/software/emacs/manual/html_node/elisp/Processes.html http://www.gnu.org/software/emacs/manual/html_node/elisp/Pro...
- ehudla 13y ago
  The classic Emacs architecture paper: https://www.gnu.org/software/emacs/emacs-paper.html https://www.gnu.org/software/emacs/emacs-paper.html

by stiff 13y ago

leephillips 13y ago

"The emacs buffer-based async handling of external processes is a masterpiece of software engineering, much better than things like unix pipes." This sounds intriguing. Do you have a pointer to something I could read that might expand on what you're saying here? (Aside from the emacs source.) Amusing coincidence: the only Pratchet book I've read is The Fifth Elephant.

mr_luc 13y ago
Seconded! Like a lot of Emacs users, sure, I love Lisp. But I don't really understand how it's architected. Sure, I understand that there is this abstraction of a Buffer. But it's quite abstract. I'd love to know what's happening under the hood. I think a blog post that even gave a 37signals-blog-post-sized expansion of the grandparent's comment would probably be frontpaged on HN.
thirdtruck 13y ago
Just wanted to recommend reading more Pratchett. :) I bought a couple more novels last week and couldn't help but finish one (Equal Rites) less than twenty four hours later.
- terhechte 13y ago
  I've read more than 20 Pratchett books (I think I didn't read the last 2-3) and there're two absolutely great books among them: - Nightwatch: Great idea, fantastically written - Going Postal: Great book for everybody who reads HN. Great characters, storyline, and fantasy meets hacking.
  - thirdtruck 13y ago
    And I very nearly picked up both of those that night. I'd grab them right away if my physical to-read stack didn't already stand a few feet high.
  - zem 13y ago
    my top two as well! third is probably "men at arms"
  - mjcohen 13y ago
    That latter title made me think of the story "Spacial Delivery" by Gordon Dickson in his collection 'The Right to Arm Bears'. A fun read.
  - thirdtruck 13y ago
    Having just listened to the Snuff audio book, I can't wait to read/hear the further adventures of the Nightwatch and its captain.
stiff 13y ago
I will try to explain. When I came to emacs as a user, a "buffer" seemed just a weird way of saying "tab" without displaying actual tabs. The word choice only started making more sense once I wrote non-trivial amounts of emacslisp. The buffer is the fundamental emacs data structure, like the file is the fundamental unix data structure, so it's really important to understand it well. The definition is really simple: a buffer is just a bunch of text from some unknown source, but in fact it is a very powerful abstraction, for two reasons. First, every time you do something in Emacs when simply editing files, you are really executing emacslisp functions on the buffer that is currently displayed. A lot of things you learn in Emacs can be used in three ways: interactively in editing sessions, when automating editing tasks with emacslisp, and finally when doing programming in general, even when it has nothing to do with editing files. Second, a buffer can represent anything, it can of course contain the text of a file, but also of only fragments of a file, or a directory file listing, and, what's really great, Emacs binds TCP/FTP/HTTP/... network connections and external processes to buffers as well, allowing asynchronous streaming of incoming data into buffers, so that a emacslisp callback is called every time new text arrives from the process or socket, you can transform it as you wish and insert into the buffer the part to be shown to the user or kept for future processing. Then there are lisp primitives implemented in C like save-excursion which let you execute functions on buffer off-screen, so the same commands that are used for editing can be used for processing HTTP requests or grep output without the user noticing the cursor jumping back and forth or anything of this kind. So, when I am processing HTTP requests in Emacs, I use the same commands I sometimes use in interactive editing sessions, for example I can use re-search-forward to check if the headers were sent completely already and to get number of bytes they contain (the location in the buffer of the end of the headers, in other words). A lot of the weird emacs word like point, mark etc. that seem like anachronistic words for interface elements really are powerful abstractions that apply as much to programming as to the interactive editing. Then there is a lot of other stuff that makes this yet more powerful, you can have buffer-local variables, timers that check buffer input periodically, transaction queues for those asynchronous processes, modes that define buffer-specific key-bindings, menus and behaviours etc., it goes on an on. It's a lot like node.js or other asynchronous networking stacks. There is also lot of magic that makes all this work concurrently without Emacs having implemented threads, and that makes it not interfere with the user interface. A lot of the cool things Emacs does follows from this architecture, like the SLIME package for interacting with Common Lisp interpreters (local or remote), Dired for editing directory contents, Tramp for editing files on remote servers, Comint for running interactive processes of various kind inside Emacs etc. It's a really great lesson in how naturally features flow out of powerful design ideas. As for resources, I learnt by reading the GNU Emacs Lisp Reference [1], and have done a lot of M-x describe-function and source code reading in the process of writing some elisp more sophisticated than just small editing helpers. E.g. the process stuff is described here: http://www.gnu.org/software/emacs/manual/html_node/elisp/Processes.html http://www.gnu.org/software/emacs/manual/html_node/elisp/Pro...
ehudla 13y ago
The classic Emacs architecture paper: https://www.gnu.org/software/emacs/emacs-paper.html https://www.gnu.org/software/emacs/emacs-paper.html