Live data from Hacker News

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

news.ycombinator.com

301–310 of 340 posts

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

#301

Earlier quoted context omitted.

iLemming you clearly know how to interwebs, well met.

Look. In our field of software crafting and Computer Science, conflicting ideas and principles frequently arise, especially when balancing competing concerns. We often need to weigh out performance against readability, abstraction and efficiency, flexibility over simplicity, security vs. usability, consistency over pragmatism, etc. Yet, it's relatively rare for ideas (especially good ones) to become completely invali…

How do you feel about Clojure vs Lisp?

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

#302
post #297

Earlier quoted context omitted.

Dear Cooking Show, I really liked your recipe for the shrimp-avocado salad, and I tried to make it, but since I was out of avocados I just substituted them with potatoes. Also, it turns out I didn't have any shrimp, so I just used some hot dogs I found in my freezer. OMG, this recipe is amazing. You just made my day. --- That's what using X instead of Lisp to make "a better Emacs" sounds like, okay? Emacs is a Lisp-m…

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.

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

#303
post #298

Earlier quoted context omitted.

> I do understand that for you Emacs is a Lisp development environment first It's not "for me", it is what it is. Emacs first and foremost is a Lisp machine, with a text-editor built into it, not the other way around, it's not a text-editor that uses Lisp as its configuration language. "user experience of Emacs" is to be able to send any expression and sub-expression without any preceding ceremony directly to the REP…

> 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.

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

#304
post #299

Earlier quoted context omitted.

> I do think python would make emacs more accessible It would not be Emacs anymore. Emacs is specifically tied to Lisp. Emacs is not a text editor that uses Lisp as the configuration language. Emacs is a Lisp machine that has a text editor built into it. An "Emacs-like" editor built on Python might be interesting, but it wouldn't be a "better Emacs" or even "like Emacs", it would be a completely different thing. You…

> Emacs is specifically tied to Lisp GNU Emacs is tied to Elisp. But Emacs is a much wider family of editors written in a multitude of languages. > Yet somehow, in over forty years nobody has succeeded in dethroning Elisp from ruling Emacs That might have several reason. Maybe few people are interested to reimplement GNU Emacs in a different language. Like nobody has succeeded in dethroning C from the Linux kernel, u…

> 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 Emacs, unless they're explicitly talking about others.

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

#305

Earlier quoted context omitted.

Look. In our field of software crafting and Computer Science, conflicting ideas and principles frequently arise, especially when balancing competing concerns. We often need to weigh out performance against readability, abstraction and efficiency, flexibility over simplicity, security vs. usability, consistency over pragmatism, etc. Yet, it's relatively rare for ideas (especially good ones) to become completely invali…

How do you feel about Clojure vs Lisp?

You mean Clojure vs Common Lisp or Emacs Lisp? In what way? I like them all. They serve different purpose for me, but in general, I like them.

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

#306
post #296

Earlier quoted context omitted.

In this case it would't care. Since it's basically redefining what (lambda) means to the Reader. That is where that notorious distinction of Read-Eval-Print-Loop comes to play. 1. Read: - In Python, the read phase must parse text into an intermediate representation (AST) that is distinct from Python's data structures. During the read phase, Python using built-in tokenizer and parser, parses its infamous indent-based…

> 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 Emacs 28, but it just adds a layer of optimization, the interpreter still exists and can evaluate s-expressions directly, it doesn't turn Elisp into a "compiler-only" implementation.

But yes, there are other Lisps that compile code to machine lang, without an interpreter.

Good catch and a fine note, thank you!

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

#307
post #285

Earlier quoted context omitted.

> Sandboxing is used when the host is concerned about running programs that he doesn't trust. Trust? Trusting criminals doesn't stop them from committing crime. You may trust your emacs color theme author. Pretty colors from an innocent artist. You run the theme code without any sandboxing. Everything is going well. Then the author adds a keyloger, project code scrapper, and phone-home feature in his theme. You updat…

Read my other reply in this tree. > You update all your emacs packages automatically without any code review. Then you start getting emails from your companies security team asking why you uploaded sensitive projects to a 3rd party. If you do not trust the author or maintainers of a random program and refuse to review any code updates before installing it, then you are a moron. I think if there is a concern that peop…

> If you do not trust...

Trust provides no protection.

> refuse to review any code updates before installing it, then you are a moron.

I personally do review every line of Emacs code I run. But I'd wager only a small handful of Emacs users do that.

> Why SHOULDN'T a color theme be allowed to scrape code from your disk?

Security.

> precisely the point you are missing.

Not missing it. nabla9's suggested security measures for extensions. You then asked why security is a concern. You seemed to imply there wasn't any reason for limiting extensions if you trust the author. That's simply not true, as you can easily be sabotaged by the most trusted color theme author.

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

#310
post #299

Earlier quoted context omitted.

> Emacs is specifically tied to Lisp GNU Emacs is tied to Elisp. But Emacs is a much wider family of editors written in a multitude of languages. > Yet somehow, in over forty years nobody has succeeded in dethroning Elisp from ruling Emacs That might have several reason. Maybe few people are interested to reimplement GNU Emacs in a different language. Like nobody has succeeded in dethroning C from the Linux kernel, u…

> 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 would be sufficient for an interactive extension language.

Here is an old Emacs timeline:

https://www.jwz.org/doc/emacs-timeline.html

The actual historic Emacs wasn't written in Lisp and was not extensible in Lisp. It was written on top of TECO and assembly. It was extensible.

The second and third Emacs were both written in Lisp (Zetalisp and Maclisp) and they were completely written in Lisp.

At some point Gosling wrote an Emacs in C and Mocklisp. Stallman took that one and rewrote it into GNU Emacs.

We have lots of Emacs variants written in languages like TECO, C, Fortran, ...

Craig A. Finseth wrote "The Craft of Text Editing: Emacs For The Modern World"

http://www.finseth.com/craft/

Chapter Ten of above book describes what Emacs-type means: http://www.finseth.com/craft/#c10

Extensibility is a general feature and not tied to Lisp or GNU Emacs.

The book contained a list of Emacs implementations. An newer list is here: http://www.finseth.com/emacs.html

You can see that there is a multitude of editors in the Emacs category. The list also mentions the implementation and the extension language.

> GNU Emacs is what people usually mean when they speak about Emacs

That's a bit sad. It's like saying "Linux" and think that its the same as "Debian Linux". Similar there are a lot of different Emacs-like editors. Claiming that there is only a single way to implement Emacs goes against the evidence that there are a lot of Emacs-like editors, which are not implemented in C + Emacs Lisp, including the original first Emacs.

I would think that by far the most important Emacs is GNU Emacs, but I don't think its implementation language choice (C + Lisp) is necessary to implement an extensible Emacs-like editor. Also be aware even though GNU Emacs is a popular Emacs editor, there are some people who are using different Emacs-like editors instead. I typically use a Hemlock variant written in Common Lisp and Zmacs, written in ZetaLisp. Both core designs date back many decades, actually even before GNU Emacs existed.

Post reply on HN