The big issue with elisp is how alien it is to read code in it with so many parens and the tendency by elisp programmers to inline huge gobs of code in function calls.
Emacs Users Are Like Terry Pratchett’s Igors (2013)
11–20 of 58 posts
Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)
#12Emacs is 43 years old. When it was written, the kernel had to be written in C. Elisp is slow.
It’s probably possible today to write an Emacs in a high-performance Lisp.
Elisp has no support for concurrency, for example.
“Some 359,000 lines of C code comprise its kernel, and 1,637,000 lines of Emacs Lisp take the rest of it.1”
Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)
#13Can anyone recommend an editor like Emacs that doesn’t use LISP? I find the syntax to be an abomination.
Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)
#14I lack even a reference for the sorts of things that can be done. How have Emacs users here customized their workflow?
Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)
#15Earlier quoted context omitted.
The codebase is as coherent as the author wants it to be, without the language imposing metaphors like objects or a pure functional style where they're not needed. Lisp won't force you to write bad code, but that means it can't force you to write good code, either: If your Lisp code is incoherent, that's on you.
>> If your Lisp code is incoherent, that's on you. It's actually on anyone who comes after. That might be just me, or if the code is public it could be anyone.
The phrase "that's on you" means "it's your fault".
Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)
#16Emacs is 43 years old. When it was written, the kernel had to be written in C. Elisp is slow. It’s probably possible today to write an Emacs in a high-performance Lisp. Elisp has no support for concurrency, for example. “Some 359,000 lines of C code comprise its kernel, and 1,637,000 lines of Emacs Lisp take the rest of it.1”
Whenever I open a file of code that is ~2000 lines or more, emacs slows to a crawl. It takes 5 seconds to redraw the visible text after hitting "page up" or "page down".
I don't think emacs should be made any slower than it already is.
Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)
#17Can anyone recommend an editor like Emacs that doesn’t use LISP? I find the syntax to be an abomination.
It is arguable that no such editor exists.
Take away the Lisp and you are already very unlike Emacs.
Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)
#18People who don't know how to program emacs don't get how easy it is to write some code in it to make your life easier. Some say Atom and VSCode also have plugins. That's true, but can you write code to extend some VSCode functionality in a minute? You just go to the scratch buffer, write some code, evalute it and it instantly becomes part of the editor. I don't know if there are other editors which can replicate this…
Can you recommend a good starting-point for learning emacs internals?
Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)
#19I lack even a reference for the sorts of things that can be done. How have Emacs users here customized their workflow?
I'm currently working on an extension to modify the built-in symbolic calculator to display its stack entries in rendered LaTeX--it already has various language modes for displaying its s-expression based formulas, including LaTeX, so this honestly isn't that big of a lift.
Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)
#20People who don't know how to program emacs don't get how easy it is to write some code in it to make your life easier. Some say Atom and VSCode also have plugins. That's true, but can you write code to extend some VSCode functionality in a minute? You just go to the scratch buffer, write some code, evalute it and it instantly becomes part of the editor. I don't know if there are other editors which can replicate this…
For VS Code, it’s like developing for another web browser, your VS Code IDE launches another instance of VS Code with your plugin running, and you can “Refresh” the second instance of VS Code to reload your plugin’s changes. Installing a plugin once developed is of course possible, but as far as I know there’s no hot-reload outside of this Extension Development Host window. Basics at https://code.visualstudio.com/api/get-started/your-first-ext... and you can run automated tests also in that second IDE window.
That said, VS Code isn’t as flexible—there’s a distinction between building VS Code and building an extension, and the two aren’t equivalent. The closest analogy I can think of is developing an old-fashioned XUL Firefox extension vs a new Chrome-style extension. The former used the same building blocks the app used, the latter was intentionally sandboxed and sanitized.
That said, you can do a heck of a lot with VS Code extensions, enough that I don’t want to install any I don’t trust —they can run programs and never prompt you for permissions, etc. So with great power comes great responsibility ;-)
And it could be argued that in a perfect world, VS Code should have both a live-edit-and-reload experience for plugin development alongside a more formal, sandboxed approach with signing and permissions and everything.