1. 24

Talk given by Perry E. Metzger at EmacsConf 2019

  1.  

  2. 14

    I don’t like the direction he wants to go with HTML and web integration. If I want webmail and web chat and perfect HTML rendering, I’ll open my browser. I don’t think the core of Emacs should be bogged down with a browser engine. I understand that some people want to use Emacs for everything, but at the end of the day it is supposed to be a text editor and not a web browser.

    It’s easy enough to say “Just turn it off”, but it’s bound to be a security mess, bloat the memory use, and make the code base even more complicated, so there are side effects even for people who don’t want these features.

    1. 13

      at the end of the day it is supposed to be a text editor and not a web browser.

      It’s supposed to be an operating system; more of a Lisp Machine refugee camp, making do with what’s available on Unix.

      1. 2

        Maybe, but the modern web is a product of Unix, continued on with technical compromises and consumer friendliness. If Emacs were to become a text browser, sure I would not have to leave Emacs anymore, but the product would really not be the computational environment built on free software any more – rather it would just be reduced to another, probably sub-par browser.

        1. 2

          Done right, I think that it would very much not be just another browser, and done right it need not be sub-par. I can easily imagine a Lisp-extensible editor with enough knowledge of HTML, JavaScript and CSS to be indistinguishable from Firefox or Chrome.

          What I can’t easily imagine is the FSF, GNU or the Emacs project itself having the resources to build such a thing. And sadly, no-one with those resources cares enough about Lisp or Emacs to do it either.

          1. 1

            I can easily imagine a Lisp-extensible editor with enough knowledge of HTML, JavaScript and CSS to be indistinguishable from Firefox or Chrome.

            If it’s indistinguishable, what’s the point?

        2. 1

          Guixsd already exists, and uses a better lisp!

        3. 4

          I don’t think the core of Emacs should be bogged down with a browser engine.

          Emacs already has a web browser and if you haven’t noticed it by now then I doubt a new one getting added is going to bogg anything you already use down.

          1. 3

            I know, and I use it almost every day. I have it set as my default browser in Emacs. I use it to open Org mode web links, browse documentation, do web searches/research while working, and occassionally use github and sourcehut. It’s nice because I can avoid the distraction of Slack, email, Lobste.rs, and the rest of the web.

            I guess my argument is that Eww already supports the right amount of HTML for a browser embedded in a text editor. Obviously, very much IMO.

          2. 4

            For the emacs-y browser, there is/will be the Next browser :)

            1. 2

              Rust and Erlang are not the only programming languages with a good concurrency model. C is not dead or dying. Type systems do not objectively make it easier to program. Dynamically typed languages are not on the way out, obsolete or in any way bad. People do not need parametric polymorphism in their fucking text editor extension language. Emacs does not need a fucking web browser to ‘keep up with the kids’ or whatever ridiculous reasoning is being given. And Visual Studio Code isn’t even remotely close to Emacs in any respect at all, it’s a text editor you can write extensions for, just like virtually every other popular text editor in history. Taking lessons from Visual Studio Code is like taking lessons from Sublime Text or any other momentarily popular editor that is and will be forgotten about within a couple of years.

              What Emacs should be taking note from is not Visual Studio Code, it’s vim. Vim is everything Emacs is not: fast, ergonomic and with a language that’s PERFECT for writing very small snippets of but an awful pain to write extensions with. Emacs Lisp is what you get if you write commands to your text editor in a proper programming language (100s of characters just to swap two shortcuts) while Vimscript is what you get if you write extensions to your text editor in a command language (sometimes harder to understand than TECO).

              Vim is also evidence that trying to fix extensions with bindings to extra languages is a terrible idea. Vimscript needs to be improved, not replaced. Emacs Lisp is the same: improvements are necessary, not its replacement with something else. It’s not just bad to replace Emacs Lisp entirely, adding a new language beside it and making Emacs Lisp ‘legacy’ also means that in order to access new parts of the Emacs infrastructure, extensions/modes need to be rewritten anyway.

              The contention made that C needs to go to make contributing to Emacs more accessible is.. frankly insane. C is one of the most widely known languages in the world. It’s very easy and accessible to learn. Rewriting code parts of Emacs in an obscure, esoteric language like Rust is not going to make contributing to Emacs easier, it’s going to make it much harder. It should also be made quite clear that Rust is not a ‘guaranteed safe language’ as is claimed here. Not even close. It’s not at all safe. It literally has a keyword called unsafe that escapes all the safety that the language provides. Under certain conditions that are very easy to check Rust is totally safe, which is what it provides over C, and even outside those conditions, any spots that introduce unsafety are enumerated with grep -Re unsafe, but it’s absolutely untrue that Rust is safe, and any gradual move from C to Rust in Emacs would involve HUGE swathes of unsafe Rust to the point where it’s probably safer to do it in C++ than in Rust, simply because the infrastructure for checking C++ programs for safety are stronger than the infrastructure for checking Rust-programs-that-are-full-of-unsafe for safety.

              A very statically typed language like Rust makes no sense for a text editor like Emacs. The strength of Emacs is that it’s insanely dynamic. It has a relatively small bit written in C, and most of it is actually written in Elisp.

              1. 4

                Yeah, I very much disagree with his desire to get away from a real Lisp. The value proposition of Emacs is very much about having a dynamic, dynamically-typed, dynamically-scoped (yes, I am aware of the optional lexical scoping) Lisp extension language.

                You are right that vim makes simple things simple, but man-oh-man is VimScript a hideous misfeature of an extension language. I do think that Emacs could probably stand to have some more sugared ways to do some basic config out of the box — use-package is an example of improved keybinding, for example.

                I wouldn’t mind a Rust-based runtime, but what I would really love to see is a Lisp-based runtime: a core in Common Lisp, with a full Elisp engine to run all the code from the last fourty-three years, and with full programmability in Common Lisp.

                But then, I’d also like to see an updated Common Lisp which fixes things like case, pathnames, argument ordering and a few other small bits. And I want a pony.

                1. 3

                  Lisp is probably one of the few things that makes emacs actually interesting, and I’m not even an emacs user or a lisp user…

                2. 3

                  It literally has a keyword called unsafe that escapes all the safety that the language provides

                  This is not true, and this (very common) misunderstanding highlights the fact that one should think about – for lack of a better term – marketing, even when creating the syntax for a programming language. unsafe sure makes it sound like all the safety features are turned off, when all it does is allow you to dereference raw pointers and read/write to mutable static variables – all under the auspices of the borrow checker, that is still active.

                  1. 2

                    It is true. As soon as unsafe appears in a program all safety guarantees disappear. That’s literally why it’s called ‘unsafe’. The rust meme that it doesn’t take away all the guarantees ignores that.

                    It turns off enough safety guarantees that you no longer can guarantee safety…

                3. 1

                  Parallel extension languages running on a shared runtime reminds me of Erlang / Elixir on the BEAM, or Java / Clojure on the JVM. That could be pretty interesting.