Live data from Hacker News

Ask HN: If you were rewriting Emacs from scratch, what would you do differently?

news.ycombinator.com

311–320 of 340 posts

Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?

#311

If I leapfrog over my generally cold attitude towards Lisp-like languages and my habit of Vim keys, the main problem is Emacs's sluggishness, even if it is natively compiled. Neovim fully packed with plugins, LSPs, settings and etc without lazy loading (!) is so much faster.

And? GIMP is too, much faster to start than Photoshop, yet there are a number of things for which sometimes you just need the heavy cavalry.

I was doing some API testing today, I pressed a key, then a snippet expansion system added something like this into my notes:

      #+begin_src http 
      GET http://localhost:5003/api/health
      #+end_src
I ran the snippet, it sent the request and it failed.

I realized that I needed a token. It is stored in an env var - not very secure, but it's okay - I'm not testing the prod endpoint. I just had to change the header into this:

    #+begin_src http :var token=(shell-command-to-string "echo $MY_TOKEN")
    GET http://localhost:5003/api/health
    Authorization: Bearer ${token}
    #+end_src
    
I ran that, and Emacs picked up the env-var, fed that into the snippet, sent http request, got me some results. Then, I changed the endpoint to get some more data, I realized that I would like to examine it closer. I could've done this in Python, Javascript, any other language, even Elisp, but I know Clojure, it's good for data manipulation - so I chose that. I just had to feed the http request results to another block in Clojure. I spun up a Clojure REPL, went through the data, looked at the results, typed some Clojure data manipulation functions, right there where my notes were, ran them against the data, added some more notes - documenting my findings.

I've tested some more endpoints, got some unfamiliar http error codes, so I just typed directly in my notes "RFC 2616", Emacs was smart enough to recognize what that was and it opened the RFC document, where I searched for the error code, read about it, refreshing my knowledge.

Then I found the Jira ticket number in my yesterday's notes, copied over to my notes of today - Org-mode has a nice way of organizing daily notes in so-called date-trees. It's just a plain string - "TDL-26478", and once again, Emacs was smart enough to know what that was, I was able to read the description of the Jira ticket, without switching to the browser, without opening any pages, right there, from where I was composing my notes.

And this is all within less than an hour. I was able to send http requests, analyze results, study relevant RFC document, work with Jira, all that while taking extensive notes, without opening a single web-page, without typing a single command in the terminal, all that done inside Emacs. Emacs basically within less than an hour in a single window was able to substitute for me - a note taking app like Obsidian or Notion; API client like Postman; Interactive computing platform like Jupyter; Project management client for Jira; RFC documentation site; Web-browser and the Terminal app. So tell, me which one of any of these activities do you normally do in Neovim? And btw, this is not even remotely "esoteric" stuff I do in Emacs. This is just an ordinary Tuesday for me.

Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?

#312
post #38

> If you were rewriting Emacs from scratch, what would you do differently? UI: Electron, of course. Json to represent the edit buffer in RAM. Each utf8 code point base64 encoded, in a json array, it itself, as a blob, base64 encoded. Now, before you complain that that is gonna blow up the data too much, don’t forget that 1. “Ram is cheap” and 2. “gzipped base64 is about the same size as binary”. So, of course, we’ll…

Prefer Tauri to Electron. It is 2024, after all.

Heh... The obvious choice of course is Unreal Engine. It's almost 2025, after all.

Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?

#313
post #298

Earlier quoted context omitted.

> if you want to build something like Emacs - a REPL that has a built-in text editor, you need a Lisp, because non-homoiconic languages DO NOT HAVE exactly same REPLs. I don't think it makes sense. One can build programmable editors in many interactive languages. The language for an editor doesn't need to be Lisp. It could be Python, JavaScript, Ruby, PERL, Forth, ... Typically a form of EVAL or compile/load is enoug…

> One can build programmable editors in many interactive languages Of course, one can - VSCode is a "programmable editor", no? Emacs is a bit different though, wouldn't you agree? It's rather a Lisp REPL that has a text-editor built on top of it.

A Lisp REPL is a user interface, not an implementation.

The first Emacs wasn't using Lisp at all. Wasn't it literally the Emacs?

> It's rather a Lisp REPL that has a text-editor built on top of it.

Just write an Emacs without a Lisp REPL. It can have the same Dired, just written in Python. There is nothing in Dired, which requires Lisp.

Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?

#314
post #297

Earlier quoted context omitted.

GNU Emacs is a Lisp implementation with an abstraction layer over the hardware and OS. I would like to reserve "Lisp Machine" to computers with an actual Lisp operating system or emulations of those.

Of course. I understand that calling Emacs "a Lisp Machine" is quite a stretch, but due to the lack of any actual prominent hardware-based Lisp machines these days, I think it is a permissible simplification for the orange-site discussions. Yet it is, indeed, an important clarification, I appreciate it.

There are two open source emulators of actual Lisp Machines I would recommend:

Interlisp-D/Medley: https://interlisp.org

MIT CADR: https://tumbleweed.nu/lm-3/

These run an actual Lisp operating system.

Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?

#315
post #296

Earlier quoted context omitted.

> Lisp can evaluate the s-expressions directly. Not generally: in compiler-only implementations this is not provided.

I think you're mixing up other Lisps with Elisp. In this particular thread I'm specifically talking about Elisp, even though, in retrospect, I should've been more explicit about it and not dropped the 'E'. AFAIK, Elisp is an interpreted language by design and always has the ability to evaluate s-expressions directly at runtime, there's no compiler-only implementation of Elisp. There's native compilation introduced in…

Especially since many compiler-only implementations can evaluate Lisp code at runtime, just fine, even though they don't execute s-expressions in an Interpreter. Thus an compiler-only Lisp can be used to implement Emacs just fine. I used for many years an Emacs on top of a compiler-only Common Lisp.

Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?

#316
post #310

Earlier quoted context omitted.

> Emacs is a much wider family of editors written in a multitude of languages. Sure, there's Guile Emacs, there's MicroEmacs - both not Elisp-based, still built on top of Lisp dialects; there's XEmacs, Remacs - both still use Elisp, there's also mg which afaik completely not lisp-based, but I don't know how much of it still 'emacs-like'. In general though, GNU Emacs is what people usually mean when they speak about E…

If you say only Lisp can be used to implement Emacs, would you mean a specific Emacs or an editor belonging to the larger family of Emacs-like editors? When I would speak about how to implement "an Emacs", I would include the option to use different programming languages. For example I could imagine that C and Python is a valid combination, even Python alone would be an option. Python can be used interactively, which…

> I typically use a Hemlock variant written in Common Lisp and Zmacs, written in ZetaLisp.

So, I still can't see how that doesn't prove my point even further. These Emacs variants are based on Lisps, like you just said. I don't see anything "Emacs-like" today that's hugely based on a non-homoiconic language. Please, if you know any editor that allows me to modify the behavior of any given function/procedure/command with the same level of granularity as the advising mechanism of GNU Emacs, I would love to know about it.

Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?

#317
post #310

Earlier quoted context omitted.

If you say only Lisp can be used to implement Emacs, would you mean a specific Emacs or an editor belonging to the larger family of Emacs-like editors? When I would speak about how to implement "an Emacs", I would include the option to use different programming languages. For example I could imagine that C and Python is a valid combination, even Python alone would be an option. Python can be used interactively, which…

> I typically use a Hemlock variant written in Common Lisp and Zmacs, written in ZetaLisp. So, I still can't see how that doesn't prove my point even further. These Emacs variants are based on Lisps, like you just said. I don't see anything "Emacs-like" today that's hugely based on a non-homoiconic language. Please, if you know any editor that allows me to modify the behavior of any given function/procedure/command w…

Look at the list of Emacs-type editors. Plenty of them were not written in Lisp.

> Please, if you know any editor that allows me to modify the behavior of any given function/procedure/command with the same level of granularity as the advising mechanism of GNU Emacs, I would love to know about it.

Zmacs did that before GNU Emacs existed. It also allowed ALL parts of the editor to be changed, not just the ones written in Emacs Lisp for GNU Emacs. Remember, the core of GNU Emacs - both the core Lisp implementation and some core editor and UI functionality - is written in C.

Btw., on a real Lisp Machine the editor (Zmacs) was not the main user interface. For example on a Symbolics (but also in Interlisp-D), the listener and a file browsers were their own applications. Zmacs in Genera has a Dired mode, but no listener. Also Genera can run multiple Zmacs windows in the same Lisp, running concurrently -> the Lisp supports multiple threads and the applications use that feature.. Something which GNU Emacs can't easily do. It's mostly blocking and single threaded. Something which can't be easily fixed in Emacs Lisp.

Run Lisp code in GNU Emacs in the REPL (m-x ielm) and it blocks the UI. That can't trivially fixed and is a major implementation fail of GNU Emacs.

Other Emacs-like editors can run multiple things, without blocking the user interface.

Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?

#318
post #317

Earlier quoted context omitted.

> I typically use a Hemlock variant written in Common Lisp and Zmacs, written in ZetaLisp. So, I still can't see how that doesn't prove my point even further. These Emacs variants are based on Lisps, like you just said. I don't see anything "Emacs-like" today that's hugely based on a non-homoiconic language. Please, if you know any editor that allows me to modify the behavior of any given function/procedure/command w…

Look at the list of Emacs-type editors. Plenty of them were not written in Lisp. > Please, if you know any editor that allows me to modify the behavior of any given function/procedure/command with the same level of granularity as the advising mechanism of GNU Emacs, I would love to know about it. Zmacs did that before GNU Emacs existed. It also allowed ALL parts of the editor to be changed, not just the ones written…

> It also allowed ALL parts of the editor to be changed

Like interactively, without restarts and all? Wow.

> That can't trivially fixed and is a major implementation fail of GNU Emacs.

Yes, that is a real big, sad flop.

Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?

#319
post #314

Earlier quoted context omitted.

Of course. I understand that calling Emacs "a Lisp Machine" is quite a stretch, but due to the lack of any actual prominent hardware-based Lisp machines these days, I think it is a permissible simplification for the orange-site discussions. Yet it is, indeed, an important clarification, I appreciate it.

There are two open source emulators of actual Lisp Machines I would recommend: Interlisp-D/Medley: https://interlisp.org MIT CADR: https://tumbleweed.nu/lm-3/ These run an actual Lisp operating system.

These are interesting from historical educational point of interest, but they rather don't have practical use for modern software development, do they?

Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?

#320
post #313

Earlier quoted context omitted.

> One can build programmable editors in many interactive languages Of course, one can - VSCode is a "programmable editor", no? Emacs is a bit different though, wouldn't you agree? It's rather a Lisp REPL that has a text-editor built on top of it.

A Lisp REPL is a user interface, not an implementation. The first Emacs wasn't using Lisp at all. Wasn't it literally the Emacs? > It's rather a Lisp REPL that has a text-editor built on top of it. Just write an Emacs without a Lisp REPL. It can have the same Dired, just written in Python. There is nothing in Dired, which requires Lisp.

Dired is a file browser, sure, it can be written in anything. But what about something like Org-mode - with all its source-block magic, code execution, etc. etc.?
Post reply on HN