Emacs is the 2D Command-line Interface(hongchao.me)
hongchao.me
Emacs is the 2D Command-line Interface
https://hongchao.me/cli-and-emacs/
180 comments
I was fully down the path you're talking about, and would have agreed with you... until COVID happened and I've been stuck working from home on a fairly low bandwidth (rural) Internet connection with source code that can't (because of BigCorp policy) be on my local machine. So it's SSH for most things, and suddenly my 25+ year old emacs skills (such as they are) have come back to be a big help.
That and even when I was able to do development locally, it has been on a massive codebase (Chromium) that CLion literally cannot index (freezes, fails, lags etc.) and yet somehow clangd & lsp etc. don't have problems.
So hoorah for the continued excellence of emacs and assorted related open source tools. They may not be slick or well packaged but they are on the whole resilient because they're flexible.
That and even when I was able to do development locally, it has been on a massive codebase (Chromium) that CLion literally cannot index (freezes, fails, lags etc.) and yet somehow clangd & lsp etc. don't have problems.
So hoorah for the continued excellence of emacs and assorted related open source tools. They may not be slick or well packaged but they are on the whole resilient because they're flexible.
TRAMP used to be my reasons to use emacs too, but VS code's ssh remote plug in is amazing.
He meant running Emacs on the remote server which IMO is even better than using vscode's remote plugin.
Yeah, I do use Tramp mode, but have, at times, had problems with it and actually found an smb mount to be more reliable (ha!) when editing files. But often what is the case is that I'm using a variety of bash tools while ssh'd in, and then quickly find I need to edit a file and so launch the server's copy of emacs. Theoretically, I could do everything in Emacs terminal mode, or eshell, either using Tramp, or in the remote instance of Emacs, but I never seem to find that it works hassle free, which is too bad, because I really like being able to move about the terminal field as if it were a text file (e.g. doing a regex on already existing output, etc.).
Remote SSH plus indexing a code base of my size over a 10mbpsa connection is just... oh nope, no way. Can't even reliably index it locally.
The indexing runs on the remote server. Now, not sure what traffic autocomplete and such ends up using, but most of the hard work happens remotely.
Don't get me wrong, a lot of these problems aren't really Emacs's fault. Jetbrains puts a lot of money and effort into its IDEs. If some commercial or nonprofit entity was actually committed to developing and maintaining elisp packages providing superb language support, then Emacs would have it.
Maybe language support will get better with LSP; anyone know how that is going in the emacs world?
Maybe language support will get better with LSP; anyone know how that is going in the emacs world?
I’ve used lsp-mode for python, go, typescript, rust, and haskell. Had to do a little bit of fiddling with settings and trying different servers to get something performant for a very large python codebase, and I did some more fiddling to adjust some delays and whatnot to get everything feeling snappy with the way I edit text. I still find that it feels faster on Linux than on Mac, but I don’t use the latter much anymore anyway.
My general impression of lsp-mode is that it’s great, once you get the settings the way you like them. Errors and warnings are nicely integrated into flycheck, and the lsp-ui package provides some niceties like automatically showing function signatures, showing error information inline with the code, and so on.
My general impression of lsp-mode is that it’s great, once you get the settings the way you like them. Errors and warnings are nicely integrated into flycheck, and the lsp-ui package provides some niceties like automatically showing function signatures, showing error information inline with the code, and so on.
It does actually sound like things have improved since when I started moving away from primary development in emacs circa 2016-17. It might be time to revisit my config file. I still end up coding in emacs a lot of the time.
Emacs 27 helped a ton with language server performance, I believe because they reworked the JSON parser to be quite a lot faster.
There’s also a “native-comp” feature that’s available experimentally in 28, which does native compilation of most of the .el files in emacs. I’ve played with it a bit and it does seem like a significant speed up across the board.
Definitely a lot of exciting things happening!
There’s also a “native-comp” feature that’s available experimentally in 28, which does native compilation of most of the .el files in emacs. I’ve played with it a bit and it does seem like a significant speed up across the board.
Definitely a lot of exciting things happening!
Yup, Emacs switched to Jansson[0] for JSON parsing. Since LSP uses JSON a lot, this means big performance improvements there.
Also seconding "native-comp" branch. It's technically experimental, but in practice it's pretty much stable. I've been running on it daily for the past 6+ months, with zero problems.
The way it works is, it uses GCC (libgccjit) to compile Emacs Lisp down to native (vs. the EL bytecode Emacs normally uses) on the fly, and then replaces the byte-compiled function with its native-compiled version. It does it transparently, across all elisp code you use - built-in and thrid party alike. What you get is a huge performance boost, and occasional messages that something gets compiled, when you run some new elisp for the first time.
--
[0] - https://digip.org/jansson/
Also seconding "native-comp" branch. It's technically experimental, but in practice it's pretty much stable. I've been running on it daily for the past 6+ months, with zero problems.
The way it works is, it uses GCC (libgccjit) to compile Emacs Lisp down to native (vs. the EL bytecode Emacs normally uses) on the fly, and then replaces the byte-compiled function with its native-compiled version. It does it transparently, across all elisp code you use - built-in and thrid party alike. What you get is a huge performance boost, and occasional messages that something gets compiled, when you run some new elisp for the first time.
--
[0] - https://digip.org/jansson/
It doesn't really work for C++
Like it can, but not on our codebase
Like it can, but not on our codebase
I use lsp for python and c++. It's usually good, but lsp will sometimes have the clang seever crash repeatedly, which can usually only be fixed by restarting emacs.
I do debugging with gdb, which is rather nice actually (you can easily set breakpoints and it will show the pointer walking through all the files), but even there there are some rough edges (the in/output buffer will show up on all frames for example, and will pop up, closing the gdb buffer itself)
All in all this is a rather good setup imo, with a little polishing I'd never have to use anything else I think. Maybe I'll try out Doom again, it might be that my config is contributing to the unstableness...
I do debugging with gdb, which is rather nice actually (you can easily set breakpoints and it will show the pointer walking through all the files), but even there there are some rough edges (the in/output buffer will show up on all frames for example, and will pop up, closing the gdb buffer itself)
All in all this is a rather good setup imo, with a little polishing I'd never have to use anything else I think. Maybe I'll try out Doom again, it might be that my config is contributing to the unstableness...
If Clang server crashes, surely that means some bug in it was triggered? lsp-mode only converses with it over JSON, after all.
Clang's developers might appreciate the corresponding bug reports.
Clang's developers might appreciate the corresponding bug reports.
I use Emacs professionally for Ruby development and LSP (Solargraph) is a huge part of what makes it work smoothly.
I also do a lot of hobby Flutter/Dart development and the same is true there.
Languages that I’ve tried to work with this way but failed include Java, Kotlin, Swift, and C#. But I could see any of them working great if the LSP implementation was robust enough.
I also do a lot of hobby Flutter/Dart development and the same is true there.
Languages that I’ve tried to work with this way but failed include Java, Kotlin, Swift, and C#. But I could see any of them working great if the LSP implementation was robust enough.
I use lsp. It's not as good as pycharm, et al, but it's good.
I use LSP for Rust (rust-analyzer) and C++ (ccls) and I would say the experience is pretty good. For C++ projects I generate a compile_commands.json (Ninja, CMake or meson should help) and after that it's smooth sailing. I get contextual auto complete suggestions (yasnippet and complete even fills function arg placeholders), definition lookups, find all references, alternate between header and source, etc.
JetBrains has a straightforward way to pay for all that development and polishing time, which is lacking (due to sound but foundational reasons) on the emacs side.
I hear what you're saying, as I regularly run up against the rough edges of emacs too, but buffers and org-mode are absolute gamechangers for me and my productivity.
I have ADHD, so not being able to switch between active files/tabs/whatever + my TODO list at lightning speed + having to constantly use the mouse devastates my productivity.
That's to speak nothing of the embrace-extend-extinguish behaviors Microsoft has been exhibiting in its development of VS Code -- e.g., deprecating their open source, editor-agnostic Python language server in favor of a proprietary, closed-source VSCode-only server[1].
I regularly update and play around with VSCode in an effort to keep an open min, but frankly I haven't found it to offer anything worth the trouble + spiritual taint (I'm saying this sort of tongue in cheek!) of switching
[1] https://github.com/microsoft/pylance-release/issues/4
I have ADHD, so not being able to switch between active files/tabs/whatever + my TODO list at lightning speed + having to constantly use the mouse devastates my productivity.
That's to speak nothing of the embrace-extend-extinguish behaviors Microsoft has been exhibiting in its development of VS Code -- e.g., deprecating their open source, editor-agnostic Python language server in favor of a proprietary, closed-source VSCode-only server[1].
I regularly update and play around with VSCode in an effort to keep an open min, but frankly I haven't found it to offer anything worth the trouble + spiritual taint (I'm saying this sort of tongue in cheek!) of switching
[1] https://github.com/microsoft/pylance-release/issues/4
I'm in the same position. I've used Emacs intensively for 20 years and I'm the author of Emacs packages that other people use. Nowadays I work on Python, Rust, and Typescript/$JSFramework projects. Here are some of the requirememts:
- Completions need to take the type system into account (even in Python), etc.
- Emacs has to provide intelligent completions, linting, type-checking, compiler error annotations, type information, format-on-save, jump-to-definition, code search, etc
- It has to be easy to set the interpreter path for every one of the executables involved.
- This all must work in a dockerized development environment, including setting breakpoints in 3rd party code that may exist only in a container volume.
Clearly nowadays this has to be done with LSP.
I initially got a bad impression of lsp-mode and tried Eglot. However, (a) Eglot has been under heavy development, and (b) it has a complicated relationship to other core Emacs modules such as eldoc and flycheck/flymake (who can remember which is which) and (c) it threatens to become part of Emacs which means that its development will no longer be done openly with PRs but in an old-school mailing list with a lot of bickering.
So, it now looks like I'm switching to VS Code for programming on real projects, but sticking to Emacs for Magit and everything else.
- Completions need to take the type system into account (even in Python), etc.
- Emacs has to provide intelligent completions, linting, type-checking, compiler error annotations, type information, format-on-save, jump-to-definition, code search, etc
- It has to be easy to set the interpreter path for every one of the executables involved.
- This all must work in a dockerized development environment, including setting breakpoints in 3rd party code that may exist only in a container volume.
Clearly nowadays this has to be done with LSP.
I initially got a bad impression of lsp-mode and tried Eglot. However, (a) Eglot has been under heavy development, and (b) it has a complicated relationship to other core Emacs modules such as eldoc and flycheck/flymake (who can remember which is which) and (c) it threatens to become part of Emacs which means that its development will no longer be done openly with PRs but in an old-school mailing list with a lot of bickering.
So, it now looks like I'm switching to VS Code for programming on real projects, but sticking to Emacs for Magit and everything else.
> it has a complicated relationship to other core Emacs modules such as eldoc and flycheck/flymake (who can remember which is which)
It, uh, depends on the 1st and the 3rd of the mentioned packages.
> it threatens to become part of Emacs which means that its development will no longer be done openly with PRs but in an old-school mailing list with a lot of bickering
Joao has been saying that for a while, but seems like he has noticed after all that only a tiny percentage of the users get around to reporting bugs to Debbugs. Hopefully, that idea is dead now, or at least very much dormant.
On the other end, lsp-mode has been making strides in becoming more stable and polished, and making bells-and-whistles easy to turn off. So maybe try it again too.
It, uh, depends on the 1st and the 3rd of the mentioned packages.
> it threatens to become part of Emacs which means that its development will no longer be done openly with PRs but in an old-school mailing list with a lot of bickering
Joao has been saying that for a while, but seems like he has noticed after all that only a tiny percentage of the users get around to reporting bugs to Debbugs. Hopefully, that idea is dead now, or at least very much dormant.
On the other end, lsp-mode has been making strides in becoming more stable and polished, and making bells-and-whistles easy to turn off. So maybe try it again too.
To the four bullet points you mention, I'll add a meta-point: this all needs to be easy to set up simultaneously, per language. That's where commercial IDEs and editors shine - you get all these things properly set up out of the box.
In Emacs, I ordinarily have to wire half a dozen components to get this to work, and a different language may use different components. LSP is a great step forward here, in that most of the data and actions for aforementioned features come through a single pipe, so it's a matter of patching up the UI to taste.
In Emacs, I ordinarily have to wire half a dozen components to get this to work, and a different language may use different components. LSP is a great step forward here, in that most of the data and actions for aforementioned features come through a single pipe, so it's a matter of patching up the UI to taste.
It's definitely possible in principle with LSP in Emacs I think at the very least if I'm going to put time in the future into getting this working well in Emacs then it makes sense to take a break and see what the cutting edge is like in a mainstream thing like VS Code, so I know what we're really aiming for in Emacs.
[deleted]
Is Eglot the go-to for LSP in Emacs these days?
I think the answer is no there's heathy competition between Eglot and lsp-mode. I'm not aware of others yet personally.
Thanks.
Don't you miss having the same keyboard shortcuts across programs?
Or the tiny things, like, does backspace at the beginning of text delete one space, back to the nearest indentation (e.g. 4 spaces) or back to the beginning of the line?
Moving between sublime on MacOS and VSCode on windows is death by a thousand needles to me. I can only imagine what moving between 3-4 editors must be like.
Or the tiny things, like, does backspace at the beginning of text delete one space, back to the nearest indentation (e.g. 4 spaces) or back to the beginning of the line?
Moving between sublime on MacOS and VSCode on windows is death by a thousand needles to me. I can only imagine what moving between 3-4 editors must be like.
A sizable portion of the Jetbrains IDE functionality can be accessed by the keyboard. Moreover, the keybindings can be configured very similar to Emacs quite easily (I don't want to live without C-x C-2 etc. for splits for instance). There's a couple of helpful plugins, too. And for hardcore, straightforward editing I've bound Cmd-e to launch emacsclient right at cursor position. This goes quite a long way, IMHO.
Personally, I miss Notepad++'s tab and shift-tab behavior with multiple selected lines on nearly everything, but except for that, I don't usually miss a tool behavior on another tool.
It helps that I set tooling based on language, so if I decide to use Pycharm for Python¹, I will expect Pycharm's behavior on every Python file. But I won't expect it on C, or Haskell, or SQL.
1 - I do change my opinnion over "a specialized IDE is best than emacs when it exists" a lot, currently I'm liking the interaction-free emacs interface more.
It helps that I set tooling based on language, so if I decide to use Pycharm for Python¹, I will expect Pycharm's behavior on every Python file. But I won't expect it on C, or Haskell, or SQL.
1 - I do change my opinnion over "a specialized IDE is best than emacs when it exists" a lot, currently I'm liking the interaction-free emacs interface more.
That's less of a problem when you use Vim keybindings everywhere.
A lot of IDEs have options to enable emacs-like key bindings. But the mapping is imperfect, and sometimes it gets frustrating. But I tend to work in one environment at a time, so after the initial frustration, I'm fine.
I also find myself using emacs short cuts when using Excel, which doesn't work, at all, of course.
I also find myself using emacs short cuts when using Excel, which doesn't work, at all, of course.
All my IDEs share common settings for copy paste, searching and basic text editing, for everything else there is mouse and graphical tooling.
I'm a Vim user, not Emacs and don't know anything about the ecosystem, but I just wanted to say I've never ever convinced myself that the hundreds of hours I've put into hacking on my Vim setup is "productivity". It's all recreational. I really enjoy it and it comes with a nice shot of adrenaline when you're able to tweak your environment just how you want it. I imagine it's the same for many Emacs users.
> I really enjoy it and it comes with a nice shot of adrenaline when you're able to tweak your environment just how you want it.
This is so true. I too enjoy tweaking my Vim setup recreationally. It’s fun for me. Sometimes my wife will ask what I’m doing on the computer, and I have to try and figure out a way to explain that I’m customizing a text editor...
This is so true. I too enjoy tweaking my Vim setup recreationally. It’s fun for me. Sometimes my wife will ask what I’m doing on the computer, and I have to try and figure out a way to explain that I’m customizing a text editor...
A heads-up that VSCode's remote extensions and Python LSP (pylance) are proprietary. So they can't be used in forks like VSCodium. Pylance is set to replace the current Python LSP.
So, it's like android - touted as open source but with gotchas that you stumble upon once you are invested in the software, and that creates a lock-in effect. Also, the VSCode binaries released by Microsoft are non-FLOSS licensed and contain telemetry. That's why VSCodium exists, but they are crippled due to at least 2 core extensions being proprietary.
Possibly more core extensions could become proprietary.
PS: I know MS created LSP, so no need to remind in reply.
So, it's like android - touted as open source but with gotchas that you stumble upon once you are invested in the software, and that creates a lock-in effect. Also, the VSCode binaries released by Microsoft are non-FLOSS licensed and contain telemetry. That's why VSCodium exists, but they are crippled due to at least 2 core extensions being proprietary.
Possibly more core extensions could become proprietary.
PS: I know MS created LSP, so no need to remind in reply.
https://news.ycombinator.com/item?id=26513727
Why do you keep creating throwaway accounts for this?
Write a full blog post about it and get it on HN. People will for sure upvote it to the front page.
Why do you keep creating throwaway accounts for this?
Write a full blog post about it and get it on HN. People will for sure upvote it to the front page.
Everything except magit. magit is life magit is love.
Magit was the emacs killer app for me. I'm now slowly learning other parts of emacs, such as org-mode.
I was in college around the svn days, then git came then IDEs tried to integrate.. at best you had cute crud. First use of magit was a shocker. It's so good it makes you usage better.. crafting thin coherent commits in 2 seconds.
Out of curiosity and objectivity I tried Eclipse / IDEA git integration (a few years ago tbf).. they were still complex and distracting.
I'm not fond of org-mode it's too large imo but maybe it will fit your brain and you'll have a blast. Best feature to me is the source block (~tiny adhoc notebook).
Out of curiosity and objectivity I tried Eclipse / IDEA git integration (a few years ago tbf).. they were still complex and distracting.
I'm not fond of org-mode it's too large imo but maybe it will fit your brain and you'll have a blast. Best feature to me is the source block (~tiny adhoc notebook).
Yes code snippets is most of the reason why I forced myself to learn org-mode. I have several *.notes files (node.notes, ruby.notes, linux.notes) in which I place important things I've learned about a particular subject, but the code snippets in them aren't executable (yet).
Ultimately I want the code snippets in them to be executed in a docker container so that I won't have to install various dev tools in my host machine.
Ultimately I want the code snippets in them to be executed in a docker container so that I won't have to install various dev tools in my host machine.
Org-mode is too big, but you don't have to use all of it. You can only learn the tiny subset you need and simply ignore the rest.
its funny, I still haven't tried. I almost always use git on the command line
To each his own, but magit is the most transparent git UI I ever ran into. it's hard to describe.
Same experience here, but as a Vim and IntelliJ user. I can edit a single file or a few buffers in Vim maybe twice as fast as I can in IntelliJ. However, I can navigate through a codebase 5x as fast, which means that when I’m doing anything that requires an understanding of parts of the codebase I haven’t memorized (95% of it), my IDE is speeding up my development by nearly 5x.
I used to try out Vim binding plugins every six months or so, until I realized that my IDE is forcing me to adopt a kind of hammock-driven-development, by being significantly faster at codebase comprehension while being significantly slower at codebase manipulation. With Vim I would never clone of a repo of a compiled 3rd party dependency in order to understand the dependency. I’d be forced to read through its repo on GitHub, since Vim’s speed-up of navigating through unfamiliar code is marginal. But with IntelliJ, I always clone the repo, create a project, and in a short time find the knowledge I’m looking for.
I used to try out Vim binding plugins every six months or so, until I realized that my IDE is forcing me to adopt a kind of hammock-driven-development, by being significantly faster at codebase comprehension while being significantly slower at codebase manipulation. With Vim I would never clone of a repo of a compiled 3rd party dependency in order to understand the dependency. I’d be forced to read through its repo on GitHub, since Vim’s speed-up of navigating through unfamiliar code is marginal. But with IntelliJ, I always clone the repo, create a project, and in a short time find the knowledge I’m looking for.
That's an insightful comment, thank you, and one that mirrors my own experience.
I don't hate you :). You have a good point.
But in my experience, it's a wash. I've wasted a lot of time customizing my Emacs over the years, but I also wrought a lot of time savings out of it, which compound over time.
It's also a part of a bigger discussion about automation and developing support tools. The popular opinion is, better not spend time on it[0], but I feel that we tend to err too much on the side of doing things the hard way and waiting until someone on the Internet develops just the tool we need.
--
See https://xkcd.com/974/, https://xkcd.com/1205/ and https://xkcd.com/1319/ for the common arguments.
But in my experience, it's a wash. I've wasted a lot of time customizing my Emacs over the years, but I also wrought a lot of time savings out of it, which compound over time.
It's also a part of a bigger discussion about automation and developing support tools. The popular opinion is, better not spend time on it[0], but I feel that we tend to err too much on the side of doing things the hard way and waiting until someone on the Internet develops just the tool we need.
--
See https://xkcd.com/974/, https://xkcd.com/1205/ and https://xkcd.com/1319/ for the common arguments.
> Now I use Pycharm for python and web development for things that can reasonably be called a "project"; the level of language support, introspection, and intelligent code prediction exceeds anything I ever achieved in Emacs.
It can be said for any other text editor. Of course, specialized tools are better most of the time.
The open source community should pool resources to create code inspection, refactoring libraries for all kinds of languages, so all extendable editors can use these libraries to provide these features.
LSP is a first step for this, but there needs to be a deeper language integration to give intelligent tips, refactoring operations, etc. for all popular languages.
It can be said for any other text editor. Of course, specialized tools are better most of the time.
The open source community should pool resources to create code inspection, refactoring libraries for all kinds of languages, so all extendable editors can use these libraries to provide these features.
LSP is a first step for this, but there needs to be a deeper language integration to give intelligent tips, refactoring operations, etc. for all popular languages.
>LSP is a first step for this, but there needs to be a deeper language integration to give intelligent tips, refactoring operations, etc. for all popular languages.
Emacs specifically also needs a lot of user interface-side polish to deal with the increase in the complexity of these plugins.
Emacs specifically also needs a lot of user interface-side polish to deal with the increase in the complexity of these plugins.
As usual it boils down to the right tool for the job.
Emacs hits the mark a great deal and it is a very versatile and adaptable tool, but of course it will have it limitations. As much as one truly desires to find the silver bullet, one will be always disappointed.
Having said that, I do often wonder what emacs could be been if it saw the adoption levels Vim has seen.
Emacs hits the mark a great deal and it is a very versatile and adaptable tool, but of course it will have it limitations. As much as one truly desires to find the silver bullet, one will be always disappointed.
Having said that, I do often wonder what emacs could be been if it saw the adoption levels Vim has seen.
I thought about it a lot, and realized there's one big obstacle for Emacs to be as close to a silver bullet as you can get - reconciling the following needs:
- Everything - especially any GUI element - having a fallback to text, so that you can get equivalent workflow for terminal and GUI.
- Everything being kept "in the open", in easily parseable data structures, from the POV of Elisp, so that things can easily interoperate with each other.
- Rendering arbitrary fonts and graphics, which is super useful for more advanced UI elements, and about any time you need something from the Web.
The usual "next step" for an editor to suddenly gain a lot of functionality would be, "embed a webview". Except this fails the first two points. But on the other hand, there's only so much you can do with text if you want to use more complex tools for the mind - like graphs. Or even if you want to pack data more densely (overlapping icons, semi-transparent or pixel-aligned popups, whatnot).
Perhaps what we need to advance Emacs is to first standardize on terminal emulators, and associated protocols, that can render pixel and vector images - and some kind of mental framework to make them seamlessly work with text, in a way that doesn't turn into DOM.
(And also threading. If we could just get proper multithreading to work reliably in Emacs, things would improve greatly.)
- Everything - especially any GUI element - having a fallback to text, so that you can get equivalent workflow for terminal and GUI.
- Everything being kept "in the open", in easily parseable data structures, from the POV of Elisp, so that things can easily interoperate with each other.
- Rendering arbitrary fonts and graphics, which is super useful for more advanced UI elements, and about any time you need something from the Web.
The usual "next step" for an editor to suddenly gain a lot of functionality would be, "embed a webview". Except this fails the first two points. But on the other hand, there's only so much you can do with text if you want to use more complex tools for the mind - like graphs. Or even if you want to pack data more densely (overlapping icons, semi-transparent or pixel-aligned popups, whatnot).
Perhaps what we need to advance Emacs is to first standardize on terminal emulators, and associated protocols, that can render pixel and vector images - and some kind of mental framework to make them seamlessly work with text, in a way that doesn't turn into DOM.
(And also threading. If we could just get proper multithreading to work reliably in Emacs, things would improve greatly.)
Could you name one thing that you use every day in PyCharm but that is not available in Emacs?
Use Emacs in simpler way like you use other editors and it will always work.
Use it in complex way and you will stumble upon plethora of troubles. That is feature, not bug.
Use it in complex way and you will stumble upon plethora of troubles. That is feature, not bug.
Haha... Good joke. But jokes apart, I've been using it to write book, refcards, blogs and programs I've never faced this 'feature'. In a proficient hand a good tool shines; Emacs ia no exception.
Can you clarify this? It makes no sense to me, and I'm a daily emacs user. How is that a good thing?
I love Emacs, but I think it’s safe to say that it’s a lot harder to use than Visual Studio Code, which is vastly more popular. I think what made VSCode popular was the availability of many high-quality extensions for major languages. Unfortunately, my experience with Elisp packages is that they tend to be much less stable. This is changing some with LSP mode, of course, but I think the Emacs community would do well to focus on improving the story for plug-in stability in the long-term. I already have to install use-package to make handling packages reasonable, which is not something I have to do in other editors. Manually setting up hooks for them is a pain in the ass too.
I once submitted a bug to the Emacs mailing list and after determining it was indeed a defect, a flame war ensued between maintainers of different subsystems that were competing over how a specific feature was supposed to be used, which was the source of the bug. It was offputting and felt juvenile. Social problems are inevitable in any open source project, but I can’t help but wonder if the highly dynamic nature of Emacs Lisp causes more problems than a less dynamic language would.
I once submitted a bug to the Emacs mailing list and after determining it was indeed a defect, a flame war ensued between maintainers of different subsystems that were competing over how a specific feature was supposed to be used, which was the source of the bug. It was offputting and felt juvenile. Social problems are inevitable in any open source project, but I can’t help but wonder if the highly dynamic nature of Emacs Lisp causes more problems than a less dynamic language would.
I agree that VS Code is easier to edit code in, but Emacs is easier to program and extend. Ease of use simply isn't why people use Emacs and I think that at this point it would be hard for it to ever compete with VS Code on that front.
VS Code is like the Java of text editors. It relies on a universally understood and accepted model of editing text (non-modal, leveraging the mouse heavily), one that is familiar to all users, even those who might prefer a more idiosyncratic and keyboard-driven interface. This is analogous to how Java facilitates a certain style of OO programming that is familiar to the vast majority of programmers, even those that may prefer and see value in other, less popular / accessible modes of programming.
By comparison Emacs would of course be the Lisp of text editors. One could try and make Lisp as accessible and nailed down as Java, after all its extreme customisability lends itself to that, but at that point you'd just be writing a poor man's Java instead of Lisp.
This is not to say that Emacs can't or shouldn't be made easier to use, just that I don't think its survival depends on it catching up to editors like VS Code which I perceive as being for a different purpose altogether. I do, however, somewhat suspect that the crucial difficulty of Emacs comes from its messiness, from the huge number of people writing interesting extensions in it, and how they don't always quite play nicely with each other without a bit of glue code.
I'd love to be wrong about that, though, and one day get the best of both worlds.
VS Code is like the Java of text editors. It relies on a universally understood and accepted model of editing text (non-modal, leveraging the mouse heavily), one that is familiar to all users, even those who might prefer a more idiosyncratic and keyboard-driven interface. This is analogous to how Java facilitates a certain style of OO programming that is familiar to the vast majority of programmers, even those that may prefer and see value in other, less popular / accessible modes of programming.
By comparison Emacs would of course be the Lisp of text editors. One could try and make Lisp as accessible and nailed down as Java, after all its extreme customisability lends itself to that, but at that point you'd just be writing a poor man's Java instead of Lisp.
This is not to say that Emacs can't or shouldn't be made easier to use, just that I don't think its survival depends on it catching up to editors like VS Code which I perceive as being for a different purpose altogether. I do, however, somewhat suspect that the crucial difficulty of Emacs comes from its messiness, from the huge number of people writing interesting extensions in it, and how they don't always quite play nicely with each other without a bit of glue code.
I'd love to be wrong about that, though, and one day get the best of both worlds.
> I agree that VS Code is easier to edit code in, but Emacs is easier to program and extend. Ease of use simply isn't why people use Emacs and I think that at this point it would be hard for it to ever compete with VS Code on that front.
I don't program in Emacs except to fix bugs or make small modifications to my init.el. I use Emacs because it's the easiest editor to use. The keybindings are ubiquitous: they are standard in the command line of bash and other shells as well as numerous other programs, and all throughout the macOS GUI. By sticking to Emacs as an editor I am using the most widely available keybindings anywhere and that helps me be productive in a multitude of places. Emacs has modes for all the languages I use, and especially now with LSP, they generally Just Work. I start Emacs as a server when I log in, and I can connect to it from any shell on the same machine, and my open files are there waiting for me. I guess you might find VS Code better if you like the mouse, but I don't want my hands to leave the keyboard while editing as I find it counterproductive.
I don't program in Emacs except to fix bugs or make small modifications to my init.el. I use Emacs because it's the easiest editor to use. The keybindings are ubiquitous: they are standard in the command line of bash and other shells as well as numerous other programs, and all throughout the macOS GUI. By sticking to Emacs as an editor I am using the most widely available keybindings anywhere and that helps me be productive in a multitude of places. Emacs has modes for all the languages I use, and especially now with LSP, they generally Just Work. I start Emacs as a server when I log in, and I can connect to it from any shell on the same machine, and my open files are there waiting for me. I guess you might find VS Code better if you like the mouse, but I don't want my hands to leave the keyboard while editing as I find it counterproductive.
I will also add that I think Emacs is a better text editor than VS Code, and easier to edit code with. What I don't think it's better at is intelligent autocomplete, live static analysis, etc. It turns out I value those things more than I value having a hyper-flexible text editor, but that doesn't mean I don't miss the flexibility when using VS Code.
>I do, however, somewhat suspect that the crucial difficulty of Emacs comes from its messiness, from the huge number of people writing interesting extensions in it, and how they don't always quite play nicely with each other without a bit of glue code.
There's no excuse for Emacs to be as inaccessible as it is though. What is "crucial difficulty?" You write an awful lot of words to excuse why the world's most powerful text editor does not have a high level of polish or usability out of the box. Usability is not at odds with power: it's complementary. The rich extension ecosystem is amazing, and there are tools in it that cannot be had anywhere else (Magit is my git client for everything, even when using IntelliJ and VSCode). But the number of extensions that exist to fix bad and/or obsolete defaults, and the number of extensions that add basic usability improvements, is really high as well.
I'm not advocating for eliminating what makes Emacs Emacs. I'm advocating for improving the out-of-the-box usability story so that the editor isn't putting people off before they get a chance to understand and experience its power. In short: I don't believe its messiness is an inevitable effect of its power. I think it's a product of the attitude that certain things about it should suck to weed out users who don't fully agree with its ideology.
>By comparison Emacs would of course be the Lisp of text editors. One could try and make Lisp as accessible and nailed down as Java, after all its extreme customisability lends itself to that, but at that point you'd just be writing a poor man's Java instead of Lisp.
I say this as an OCaml and Elixir programmer: there's nothing wrong with writing Java. The world runs on Java, not Lisp. Statistically speaking more Emacs users probably use it to write Java than any other programming language. If we're not going to meet the world where it's at, we will fail eventually.
There's no excuse for Emacs to be as inaccessible as it is though. What is "crucial difficulty?" You write an awful lot of words to excuse why the world's most powerful text editor does not have a high level of polish or usability out of the box. Usability is not at odds with power: it's complementary. The rich extension ecosystem is amazing, and there are tools in it that cannot be had anywhere else (Magit is my git client for everything, even when using IntelliJ and VSCode). But the number of extensions that exist to fix bad and/or obsolete defaults, and the number of extensions that add basic usability improvements, is really high as well.
I'm not advocating for eliminating what makes Emacs Emacs. I'm advocating for improving the out-of-the-box usability story so that the editor isn't putting people off before they get a chance to understand and experience its power. In short: I don't believe its messiness is an inevitable effect of its power. I think it's a product of the attitude that certain things about it should suck to weed out users who don't fully agree with its ideology.
>By comparison Emacs would of course be the Lisp of text editors. One could try and make Lisp as accessible and nailed down as Java, after all its extreme customisability lends itself to that, but at that point you'd just be writing a poor man's Java instead of Lisp.
I say this as an OCaml and Elixir programmer: there's nothing wrong with writing Java. The world runs on Java, not Lisp. Statistically speaking more Emacs users probably use it to write Java than any other programming language. If we're not going to meet the world where it's at, we will fail eventually.
> I'm advocating for improving the out-of-the-box usability story so that the editor isn't putting people off before they get a chance to understand and experience its power.
There are atleast a couple of projects like spacemacs and doom-emacs that already do that. The problem with the point you are making is someone has to do that hard work and also need to market it to the beginners. There isn't any money to make Emacs friendly to beginners. So i doubt it's ever going to be better than it already is through collaborative efforts of people with different goals.
There are atleast a couple of projects like spacemacs and doom-emacs that already do that. The problem with the point you are making is someone has to do that hard work and also need to market it to the beginners. There isn't any money to make Emacs friendly to beginners. So i doubt it's ever going to be better than it already is through collaborative efforts of people with different goals.
>There are atleast a couple of projects like spacemacs and doom-emacs that already do that.
Both of which are not really true to the core Emacs philosophy in several ways though. And thus, they add a whole new layer to have to debug when something breaks.
>So i doubt it's ever going to be better than it already is through collaborative efforts of people with different goals.
But there are plenty of open source projects that succeed at usability despite having different people working on different goals. The question is whether we want Emacs to be the best text editor for everyone, or the best text editor for an elite few.
>The problem with the point you are making is someone has to do that hard work and also need to market it to the beginners. There isn't any money to make Emacs friendly to beginners. So i doubt it's ever going to be better than it already is through collaborative efforts of people with different goals.
Of course someone has to do this work, but how hard did Microsoft market VSCode? VSCode's rise has been fueled by word of mouth and strong first-party support for popular tooling. "Marketing" in this case is overstated. You need a product good enough to sell first.
I'm not at all denying this would be a lot of work, but I think it's worthwhile. If you think it's a problem that work is not being done in this area then we don't disagree.
Both of which are not really true to the core Emacs philosophy in several ways though. And thus, they add a whole new layer to have to debug when something breaks.
>So i doubt it's ever going to be better than it already is through collaborative efforts of people with different goals.
But there are plenty of open source projects that succeed at usability despite having different people working on different goals. The question is whether we want Emacs to be the best text editor for everyone, or the best text editor for an elite few.
>The problem with the point you are making is someone has to do that hard work and also need to market it to the beginners. There isn't any money to make Emacs friendly to beginners. So i doubt it's ever going to be better than it already is through collaborative efforts of people with different goals.
Of course someone has to do this work, but how hard did Microsoft market VSCode? VSCode's rise has been fueled by word of mouth and strong first-party support for popular tooling. "Marketing" in this case is overstated. You need a product good enough to sell first.
I'm not at all denying this would be a lot of work, but I think it's worthwhile. If you think it's a problem that work is not being done in this area then we don't disagree.
> The question is whether we want Emacs to be the best text editor for everyone, or the best text editor for an elite few.
I can answer that for you. Emacs definitely wants B). They might pay some lip service to A), but as usual, keep your eye on what people do, not on what they say.
To offer a comparison point, Neovim. Neovim is also an Open Source project, but it wants to make Vim more powerful <<and>> more user friendly. So they've removed obscure stuff, made the default configuration newbie friendly, etc.
Emacs is too afraid of this. It has a ton of long term users that just don't want their defaults changed. There's a reason this XKCD is about Emacs: https://xkcd.com/1172/
I think Emacs will change over the following decades. Not because its users will <<change>>, but because its <<users>> will change. To clarify, it's like that saying about science: science advances, one funeral at a time.
I can answer that for you. Emacs definitely wants B). They might pay some lip service to A), but as usual, keep your eye on what people do, not on what they say.
To offer a comparison point, Neovim. Neovim is also an Open Source project, but it wants to make Vim more powerful <<and>> more user friendly. So they've removed obscure stuff, made the default configuration newbie friendly, etc.
Emacs is too afraid of this. It has a ton of long term users that just don't want their defaults changed. There's a reason this XKCD is about Emacs: https://xkcd.com/1172/
I think Emacs will change over the following decades. Not because its users will <<change>>, but because its <<users>> will change. To clarify, it's like that saying about science: science advances, one funeral at a time.
> It has a ton of long term users that just don't want their defaults changed.
For all we know, there might be just a dozen of them, but with the (low) popularity of the mailing lists, they are certainly making themselves heard.
> I think Emacs will change over the following decades. Not because its users will <<change>>, but because its <<users>> will change. To clarify, it's like that saying about science: science advances, one funeral at a time.
Right. Hopefully it won't alienate the newer generations of users too much by that time.
For all we know, there might be just a dozen of them, but with the (low) popularity of the mailing lists, they are certainly making themselves heard.
> I think Emacs will change over the following decades. Not because its users will <<change>>, but because its <<users>> will change. To clarify, it's like that saying about science: science advances, one funeral at a time.
Right. Hopefully it won't alienate the newer generations of users too much by that time.
> the crucial difficulty of Emacs comes from its messiness, from the huge number of people writing interesting extensions in it, and how they don't always quite play nicely with each other without a bit of glue code.
This is actually how I feel about VS Code! I'm a VIM user (both in and out of VS Code), and there are things I regularly go to MacVim for that the VS Code plugin doesn't support.
The thing that keeps me coming back to VS Code isn't the quality of the editor or the quality of any one thing. It's the quantity of "good enough" plugins and its integration of a good enough terminal.
This is actually how I feel about VS Code! I'm a VIM user (both in and out of VS Code), and there are things I regularly go to MacVim for that the VS Code plugin doesn't support.
The thing that keeps me coming back to VS Code isn't the quality of the editor or the quality of any one thing. It's the quantity of "good enough" plugins and its integration of a good enough terminal.
> but Emacs is easier to program and extend.
That is only true for the low level tasks out of the box. Adding a simple command is very easy. But doing something more complex can be very painful in emacs.
VS Code on the other side is out of the box focusing on flawless experience and supports hacking only through hidden paths. Though, install a simple extension and it's as simple as emacs. While having still a better experience on more complex tasks.
> VS Code is like the Java of text editors. It relies on a universally understood and accepted model of editing text (non-modal, leveraging the mouse heavily)
This again is just the out of the box-experience. Modal editing is possible, though it's true that there is still place for improvments. Which is ok for an editor which is just 5+ years old. The project seems to play a strategy there it unfolds from a safe corridor of stability and adding more and more abilitys, instead of starting from open chaos and trying to control it.
That is only true for the low level tasks out of the box. Adding a simple command is very easy. But doing something more complex can be very painful in emacs.
VS Code on the other side is out of the box focusing on flawless experience and supports hacking only through hidden paths. Though, install a simple extension and it's as simple as emacs. While having still a better experience on more complex tasks.
> VS Code is like the Java of text editors. It relies on a universally understood and accepted model of editing text (non-modal, leveraging the mouse heavily)
This again is just the out of the box-experience. Modal editing is possible, though it's true that there is still place for improvments. Which is ok for an editor which is just 5+ years old. The project seems to play a strategy there it unfolds from a safe corridor of stability and adding more and more abilitys, instead of starting from open chaos and trying to control it.
> I love Emacs, but I think it’s safe to say that it’s a lot harder to use than Visual Studio Code
Emacs discussions on HN are always unsatisfying, because everyone seems to want to compare it with IDEs or other programming editors.
Only a small portion of the article is about SW development.
The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is. Comparing it to VSCode is meaningless to them. Kind of like having a discussion about PCs, and having people repeatedly talking about how iPods are better. Yes, lots of people use PCs to listen to music, but the comparison is rather silly.
Emacs discussions on HN are always unsatisfying, because everyone seems to want to compare it with IDEs or other programming editors.
Only a small portion of the article is about SW development.
The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is. Comparing it to VSCode is meaningless to them. Kind of like having a discussion about PCs, and having people repeatedly talking about how iPods are better. Yes, lots of people use PCs to listen to music, but the comparison is rather silly.
>Only a small portion of the article is about SW development.
The article, is, however written by a software developer.
>The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is.
Do we have any hard data here? Or is this just an anecdote?
Sure, Emacs is usable for a lot of stuff outside programming. I personally use it for org-mode and as a general-purpose git client. That doesn't mean that the Emacs usability story could be better overall. Obviously I don't think Emacs should be as narrowly focused as VSCode. Greater usability would benefit users who don't program.
The article, is, however written by a software developer.
>The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is.
Do we have any hard data here? Or is this just an anecdote?
Sure, Emacs is usable for a lot of stuff outside programming. I personally use it for org-mode and as a general-purpose git client. That doesn't mean that the Emacs usability story could be better overall. Obviously I don't think Emacs should be as narrowly focused as VSCode. Greater usability would benefit users who don't program.
> Do we have any hard data here? Or is this just an anecdote?
55% according to the Emacs survey 2020 (obviously, take it with a pinch of self-selection bias due to the survey being self selecting).
[1] https://emacssurvey.org/2020/
55% according to the Emacs survey 2020 (obviously, take it with a pinch of self-selection bias due to the survey being self selecting).
[1] https://emacssurvey.org/2020/
You're completely misreading that graph, I think. And that graph actually proves his point.
91.4% of Emacs users use it for coding (so the overwhelming majority, as you'd expect), and then some of them use it for something else.
Those groups are not separate, if you look at the percentages, they add up to a lot more than 100%. So people could check multiple options.
All this tells us is that:
A) Emacs is primarily used by devs (hardly surprising :-) )
B) The devs that use it also use it for other side tasks (also hardly surprising, considering Emacs' kitchen sink philosophy).
91.4% of Emacs users use it for coding (so the overwhelming majority, as you'd expect), and then some of them use it for something else.
Those groups are not separate, if you look at the percentages, they add up to a lot more than 100%. So people could check multiple options.
All this tells us is that:
A) Emacs is primarily used by devs (hardly surprising :-) )
B) The devs that use it also use it for other side tasks (also hardly surprising, considering Emacs' kitchen sink philosophy).
The grandfather'ed post was:
> The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is.
Whether it was used by developers or not, didn't have any bearing on the question/data.
I don't know whether I would draw the conclusion they primarily use it for coding or "other tasks" from the graph; for example a developer using Emacs for `org-mode` only with the occasional git usage would check both boxes.
Just as you've reached the conclusion that 90% means all of them use it primarily for coding, an equally valid conclusion is that 50% use it primarily for /not/ coding.
I don't make that leap - but it seems strange to discount one possibility heavily it favour of another; could you elaborate why?
> The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is.
Whether it was used by developers or not, didn't have any bearing on the question/data.
I don't know whether I would draw the conclusion they primarily use it for coding or "other tasks" from the graph; for example a developer using Emacs for `org-mode` only with the occasional git usage would check both boxes.
Just as you've reached the conclusion that 90% means all of them use it primarily for coding, an equally valid conclusion is that 50% use it primarily for /not/ coding.
I don't make that leap - but it seems strange to discount one possibility heavily it favour of another; could you elaborate why?
And yet that same survey says 91% use it for software development, too.
Yet there is no hard data for my claim:
> The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is.
I didn't claim most users don't use it for SW development. I didn't even claim most users don't use it primarily for SW development. I said the number of people who primarily use it for other stuff is larger than most people think.
If HN thinks the number is 5%, and in reality it is 20%: The survey does not have data either way.
And as I noted in another post: The survey is flawed in that it didn't contain a representative sample. In particular, people on the Emacs mailing list were quite opposed to filling out the survey, and one of their concerns was what is happening right here: People drawing conclusions from a very poorly executed survey.
> The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is.
I didn't claim most users don't use it for SW development. I didn't even claim most users don't use it primarily for SW development. I said the number of people who primarily use it for other stuff is larger than most people think.
If HN thinks the number is 5%, and in reality it is 20%: The survey does not have data either way.
And as I noted in another post: The survey is flawed in that it didn't contain a representative sample. In particular, people on the Emacs mailing list were quite opposed to filling out the survey, and one of their concerns was what is happening right here: People drawing conclusions from a very poorly executed survey.
I'm not drawing any conclusions about the community, you're the person who started making claims about the demographics of users.
> In particular, people on the Emacs mailing list were quite opposed to filling out the survey, and one of their concerns was what is happening right here: People drawing conclusions from a very poorly executed survey.
But the outcome here is that their point of view was not represented, flawed though the survey may be.
> In particular, people on the Emacs mailing list were quite opposed to filling out the survey, and one of their concerns was what is happening right here: People drawing conclusions from a very poorly executed survey.
But the outcome here is that their point of view was not represented, flawed though the survey may be.
> That doesn't mean that the Emacs usability story could be better overall. Obviously I don't think Emacs should be as narrowly focused as VSCode. Greater usability would benefit users who don't program.
My comment had nothing to do with usability. I merely find the incessant comparisons with VSCode to be (mostly) noise. I'm not even here to advocate for Emacs (although I love it). People want better usability? Fine. But let's not let SW development be the benchmark for how good Emacs is. It's just one use for Emacs.
> Do we have any hard data here? Or is this just an anecdote?
Very much an anecdote. Thing is, so is any other perception. There is no hard data out there. Having said that, hang out on places like the Emacs subreddit and quite a lot of submissions are not related to SW development. Looking at it right now, only 3 submissions on the front page are related to coding/SW. If you follow the weekly Emacs news, you'll similarly find that the bulk of it is not related to coding/SW.
My comment had nothing to do with usability. I merely find the incessant comparisons with VSCode to be (mostly) noise. I'm not even here to advocate for Emacs (although I love it). People want better usability? Fine. But let's not let SW development be the benchmark for how good Emacs is. It's just one use for Emacs.
> Do we have any hard data here? Or is this just an anecdote?
Very much an anecdote. Thing is, so is any other perception. There is no hard data out there. Having said that, hang out on places like the Emacs subreddit and quite a lot of submissions are not related to SW development. Looking at it right now, only 3 submissions on the front page are related to coding/SW. If you follow the weekly Emacs news, you'll similarly find that the bulk of it is not related to coding/SW.
> There is no hard data out there.
MELPA has download-numbers. This is hard enouhg to give a rough impression on general package-usage. Looking at them, most people are doing software-work, markdown or enhance emacs itself. Even org-packages have only a rather low usage-number.
Which could mean the alternative usages of emacs are all with pre-installed packages or from other sources. Quite possible that there are million org-users who are happy with the basic setup und don't need additional packages from MELPA.
MELPA has download-numbers. This is hard enouhg to give a rough impression on general package-usage. Looking at them, most people are doing software-work, markdown or enhance emacs itself. Even org-packages have only a rather low usage-number.
Which could mean the alternative usages of emacs are all with pre-installed packages or from other sources. Quite possible that there are million org-users who are happy with the basic setup und don't need additional packages from MELPA.
> This is hard enouhg to give a rough impression on general package-usage.
Not really, because it doesn't have all the numbers for built-in features. As you noted: A huge number of users use Emacs for org-mode, which is built in, and many don't feel the need to upgrade org mode often (I myself upgrade it once every year or two).
Also, the sets overlap. Those who use, say, lsp-mode may also use mu4e. That lsp-mode may have more downloads doesn't mean a given user used it more.
I myself use Emacs for SW development. Yet the bulk of my Emacs usage is not SW development. It's mail, tracking TODOs, writing notes, keeping track of things, etc.
Not really, because it doesn't have all the numbers for built-in features. As you noted: A huge number of users use Emacs for org-mode, which is built in, and many don't feel the need to upgrade org mode often (I myself upgrade it once every year or two).
Also, the sets overlap. Those who use, say, lsp-mode may also use mu4e. That lsp-mode may have more downloads doesn't mean a given user used it more.
I myself use Emacs for SW development. Yet the bulk of my Emacs usage is not SW development. It's mail, tracking TODOs, writing notes, keeping track of things, etc.
>> The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is.
> Do we have any hard data here?
https://emacssurvey.org/2020/
> Do we have any hard data here?
https://emacssurvey.org/2020/
The data there is heavily biased as it was advertised and promoted in only a few select places (e.g. Reddit).
I use Emacs primarily for things other than editing and navigating code:
I maintain many files of notes;
I rename files and view directory listings (using Dired);
I pass command lines to Bash to be run. (End of list.)
More to the point, whereas vscode would prove a mostly satisfactory replacement for Emacs for editing and navigating code, it is unlikely I will find a mostly satisfactory replacement for Emacs for the tasks listed above. (And I have been looking: I evaluated for example the most likely of the recent spate of vscode extensions for maintaining notes in markdown files.)
(I don't like keyboard-only UIs; like 68.1% of the Emacs users who responded to a recent survey [1] I never use a terminal or terminal emulator to interact with my Emacs.)
I guess I should explain why a terminal app such a Gnome Terminal would not be a mostly satisfactory replacement for Emacs for submitting command lines to Bash. Like at least one other participant [2] in this comment section, I appreciate being able to use the same set of operations on the output of the Bash process as I use on any other file being edited (without my first needing to copy the output from my terminal app, then paste it into my editor). I also appreciate the fact that the Emacs Lisp code that runs when I send a line of code to Bash is vastly easier to modify than Gnome Terminal would be.
[1] https://emacssurvey.org/2020/
[2] "I really like being able to move about the terminal field as if it were a text file" in https://news.ycombinator.com/user?id=jonnycomputer
I maintain many files of notes;
I rename files and view directory listings (using Dired);
I pass command lines to Bash to be run. (End of list.)
More to the point, whereas vscode would prove a mostly satisfactory replacement for Emacs for editing and navigating code, it is unlikely I will find a mostly satisfactory replacement for Emacs for the tasks listed above. (And I have been looking: I evaluated for example the most likely of the recent spate of vscode extensions for maintaining notes in markdown files.)
(I don't like keyboard-only UIs; like 68.1% of the Emacs users who responded to a recent survey [1] I never use a terminal or terminal emulator to interact with my Emacs.)
I guess I should explain why a terminal app such a Gnome Terminal would not be a mostly satisfactory replacement for Emacs for submitting command lines to Bash. Like at least one other participant [2] in this comment section, I appreciate being able to use the same set of operations on the output of the Bash process as I use on any other file being edited (without my first needing to copy the output from my terminal app, then paste it into my editor). I also appreciate the fact that the Emacs Lisp code that runs when I send a line of code to Bash is vastly easier to modify than Gnome Terminal would be.
[1] https://emacssurvey.org/2020/
[2] "I really like being able to move about the terminal field as if it were a text file" in https://news.ycombinator.com/user?id=jonnycomputer
> I love Emacs, but I think it’s safe to say that it’s a lot harder to use than Visual Studio Code
I actually find the opposite. As much as I dislike the clumsy GUI, I just keep coming back to Emacs for some things, for the sole reason that it's easier in Emacs. I find Emacs to be the easiest way to customize my text editor, and that's what makes it easy to get my work done. I've tried VS Code many times and I just don't see what's special about it.
I actually find the opposite. As much as I dislike the clumsy GUI, I just keep coming back to Emacs for some things, for the sole reason that it's easier in Emacs. I find Emacs to be the easiest way to customize my text editor, and that's what makes it easy to get my work done. I've tried VS Code many times and I just don't see what's special about it.
I first used emacs 25ish years before VSCode existed and VSCode was pretty much immediately easier to use and customize; to be fair, it's not like I was using Emacs heavily in the intervening quarter century, but I was using it fairly regularly.
OTOH, I have no problem believing someone using Emacs as a daily driver for years would find it easier (but I think most developers, and particularly newer developers—where the JS to Lisp familiarity ratio is much higher than for, say, those who got into coding in the 1980s or earlier—are going to more productive more quickly with VS Code.)
OTOH, I have no problem believing someone using Emacs as a daily driver for years would find it easier (but I think most developers, and particularly newer developers—where the JS to Lisp familiarity ratio is much higher than for, say, those who got into coding in the 1980s or earlier—are going to more productive more quickly with VS Code.)
VSCode will likely get you to 80% productivity compared to Emacs pretty fast. The question how easy is to get from 80% to 100%. It is like a prototype vs. polished code: you can create something that provides 80% of the result over a weekend and then spend 2 years polishing it, to get remaining desired functionality.
For example, I'm sure VSCode does git but does it as well as Magit? Everyday things can be done on muscle memory, most other things are much more discoverable than I've seen in any git interface (using other git interfaces is like walking in a office with your eyes closed vs open with magit). http://emacsrocks.com/e17.html
I'm sure VSCode does notes too but does it as well as Org mode? Org mode for me is an extension of my brain: it is a working memory that supports executing whatever task I do, it helps organize/automate tasks, it helps focus, etc. For people with ADHD like symptoms, I expect a life changing experience thanks to Org mode -- while other people should just become more productive in it.
Every keystroke is a programmable command in Emacs. VSCode is close. I expect parity for programming modes. Most Emacs interactions are likely less pointy-n-clicky compared to VSCode: somehow pressing keychords steals my focus less than doing actions with a mouse for everyday things freeing the conscious brain to work on the task at hand. Emacs provides a unified interface for me e.g., searching/filtering lists https://writequit.org/denver-emacs/presentations/2017-04-11-...
Emacs doesn't do web browsing very well. I have to survive with Vimium. Does VSCode perform better here?
VSCode is much more popular today. Emacs is GPL -- I expect it to be there in 20 years too. I won't trust Microsoft long term.
For example, I'm sure VSCode does git but does it as well as Magit? Everyday things can be done on muscle memory, most other things are much more discoverable than I've seen in any git interface (using other git interfaces is like walking in a office with your eyes closed vs open with magit). http://emacsrocks.com/e17.html
I'm sure VSCode does notes too but does it as well as Org mode? Org mode for me is an extension of my brain: it is a working memory that supports executing whatever task I do, it helps organize/automate tasks, it helps focus, etc. For people with ADHD like symptoms, I expect a life changing experience thanks to Org mode -- while other people should just become more productive in it.
Every keystroke is a programmable command in Emacs. VSCode is close. I expect parity for programming modes. Most Emacs interactions are likely less pointy-n-clicky compared to VSCode: somehow pressing keychords steals my focus less than doing actions with a mouse for everyday things freeing the conscious brain to work on the task at hand. Emacs provides a unified interface for me e.g., searching/filtering lists https://writequit.org/denver-emacs/presentations/2017-04-11-...
Emacs doesn't do web browsing very well. I have to survive with Vimium. Does VSCode perform better here?
VSCode is much more popular today. Emacs is GPL -- I expect it to be there in 20 years too. I won't trust Microsoft long term.
> Every keystroke is a programmable command in Emacs. VSCode is close.
VSCode does not even have keyboard macros. Either "every keystroke is a programmable command" is not exactly what is going on in VSCode, or the VSCode users do not exactly understand what this "Open Source" thing is, because so far there has been 5 years of whining and 0 patches: https://github.com/Microsoft/vscode/issues/4490
VSCode does not even have keyboard macros. Either "every keystroke is a programmable command" is not exactly what is going on in VSCode, or the VSCode users do not exactly understand what this "Open Source" thing is, because so far there has been 5 years of whining and 0 patches: https://github.com/Microsoft/vscode/issues/4490
> VSCode does not even have keyboard macros.
https://marketplace.visualstudio.com/search?term=macros&targ...
> Either "every keystroke is a programmable command" is not exactly what is going on in VSCode
There are commands (JavaScript-Functions) which one can be bind to keys. But who knows whether all keys have a command behind them? An with a GUI, I wondern whether all interactions are bindable commands. Mouse-Interaction, especially in context of some widget might be more complex to handle than just recording an input-flow.
> because so far there has been 5 years of whining and 0 patches: https://github.com/Microsoft/vscode/issues/4490
Which only means it has no priority. But considering there are 4.7k open issues and 103k closed, taking a single issue is just a hint that the community is likely not pushing hard enough for this specific issue.
https://marketplace.visualstudio.com/search?term=macros&targ...
> Either "every keystroke is a programmable command" is not exactly what is going on in VSCode
There are commands (JavaScript-Functions) which one can be bind to keys. But who knows whether all keys have a command behind them? An with a GUI, I wondern whether all interactions are bindable commands. Mouse-Interaction, especially in context of some widget might be more complex to handle than just recording an input-flow.
> because so far there has been 5 years of whining and 0 patches: https://github.com/Microsoft/vscode/issues/4490
Which only means it has no priority. But considering there are 4.7k open issues and 103k closed, taking a single issue is just a hint that the community is likely not pushing hard enough for this specific issue.
Since you were too lazy to check, I did the work, and I can say there is nothing that provides keyboard macros in the search link you posted.
Here is the documentation that explains keyboard macros: https://www.gnu.org/software/emacs/manual/html_node/emacs/Ke...
> But who knows whether all keys have a command behind them?
Yes, they literally do in Emacs. That is the whole point of this discussion.
> An with a GUI, I wondern [sic] whether all interactions are bindable commands. Mouse-Interaction, especially in context of some widget might be more complex to handle than just recording an input-flow.
Mouse events result in commands. You can record them as part of keyboard macros, although I have never had a need to do that and cannot think of one.
> Which only means it has no priority. But considering there are 4.7k open issues and 103k closed, taking a single issue is just a hint that the community is likely not pushing hard enough for this specific issue.
Let me explain how this "Open Source" thing works: you can submit a patch, you don't need to "push hard" on Daddy Microsoft.
Here is the documentation that explains keyboard macros: https://www.gnu.org/software/emacs/manual/html_node/emacs/Ke...
> But who knows whether all keys have a command behind them?
Yes, they literally do in Emacs. That is the whole point of this discussion.
> An with a GUI, I wondern [sic] whether all interactions are bindable commands. Mouse-Interaction, especially in context of some widget might be more complex to handle than just recording an input-flow.
Mouse events result in commands. You can record them as part of keyboard macros, although I have never had a need to do that and cannot think of one.
> Which only means it has no priority. But considering there are 4.7k open issues and 103k closed, taking a single issue is just a hint that the community is likely not pushing hard enough for this specific issue.
Let me explain how this "Open Source" thing works: you can submit a patch, you don't need to "push hard" on Daddy Microsoft.
> Since you were too lazy to check, I did the work, and I can say there is nothing that provides keyboard macros in the search link you posted.
Seems you were to lazy to look deep enough...
> Let me explain how this "Open Source" thing works: you can submit a patch, you don't need to "push hard" on Daddy Microsoft.
Kinda funny how you have no clue how Open Projects are really working. Yes, Submiting a patch is an option. You can do that for VS Code too. Just nobody seem to have done this in this case.
And here comes into play how projects really work, even open source-projects. People complain and except the dev to implement something and than call it a day. And sometimes you have people doing some halfassed crap that makes more problems than it solve, and devs are not obligated to accept the patch. Any partly decent open source-project is doing this. Funny Uncle Emacs is doing this all the time. There is absolutly no difference in how both projects are working.
Seems you were to lazy to look deep enough...
> Let me explain how this "Open Source" thing works: you can submit a patch, you don't need to "push hard" on Daddy Microsoft.
Kinda funny how you have no clue how Open Projects are really working. Yes, Submiting a patch is an option. You can do that for VS Code too. Just nobody seem to have done this in this case.
And here comes into play how projects really work, even open source-projects. People complain and except the dev to implement something and than call it a day. And sometimes you have people doing some halfassed crap that makes more problems than it solve, and devs are not obligated to accept the patch. Any partly decent open source-project is doing this. Funny Uncle Emacs is doing this all the time. There is absolutly no difference in how both projects are working.
>VSCode is much more popular today. Emacs is GPL -- I expect it to be there in 20 years too. I won't trust Microsoft long term.
VSCode is open source, too. There are forks with the Microsoft IP removed from it. I believe Eclipse and RedHat maintain one now as well.
Other than that I basically agree with you. I much prefer Emacs to VSCode, but there are annoying things about it that mean I don't want to use it full time.
VSCode is open source, too. There are forks with the Microsoft IP removed from it. I believe Eclipse and RedHat maintain one now as well.
Other than that I basically agree with you. I much prefer Emacs to VSCode, but there are annoying things about it that mean I don't want to use it full time.
Many of the popular extensions developed by Microsoft (pylance for example), which are installed by default when you’re working on a given language, are proprietary.
VSCode has a Magit port and at least two roam/org clones.
[deleted]
1. How long have you been using Emacs?
2. Did your journey into computing start with CLIs, TUIs, GUIs?
2. Did your journey into computing start with CLIs, TUIs, GUIs?
1. About a decade probably.
2. It started in the 1980s, back when GUIs were considered a luxury upgrade for the wealthy. This was the first computer I ever owned: https://oldcomputers.net/trs80pc1.html
I'd say the biggest reason for the difference is because (by my understanding) you use JSON for configuration and write functions to extend VS Code using Typescript. I've never been a web developer and I've done very little with Typescript (and not much more with Javascript). OTOH, I've been using Lisp in various forms since forever. For me to pop open my .emacs, add an interactive function, and start using it is usually a couple minutes at most.
Now I think most users of VS Code probably feel more comfortable with Typescript and JSON, but Emacs for me is just a dead easy thing due to my ability to customize tasks almost trivially.
2. It started in the 1980s, back when GUIs were considered a luxury upgrade for the wealthy. This was the first computer I ever owned: https://oldcomputers.net/trs80pc1.html
I'd say the biggest reason for the difference is because (by my understanding) you use JSON for configuration and write functions to extend VS Code using Typescript. I've never been a web developer and I've done very little with Typescript (and not much more with Javascript). OTOH, I've been using Lisp in various forms since forever. For me to pop open my .emacs, add an interactive function, and start using it is usually a couple minutes at most.
Now I think most users of VS Code probably feel more comfortable with Typescript and JSON, but Emacs for me is just a dead easy thing due to my ability to customize tasks almost trivially.
From what I can tell, the relative instability of Emacs comes from two things: the lack of well-supported concurrency primitives and defadvice. The former is the source of UI lockups, and if you're really out of luck, you'd have no other choice but to kill the Emacs process. The latter is a footgun in Elisp that allows you to replace or hook into any function defined in Emacs.
I think the concurrency problem is solvable given tremendous time and effort. However, I doubt there is anything that could be done about defadvice. For all its shortcomings, defadvice is a defining feature of Emacs that makes it more extensible than any of the competition.
I think the concurrency problem is solvable given tremendous time and effort. However, I doubt there is anything that could be done about defadvice. For all its shortcomings, defadvice is a defining feature of Emacs that makes it more extensible than any of the competition.
Yeah, I wouldn't touch defadvice itself. We can talk about reminding elisp developers to use it only as a last resort, but ultimately, it is a very important feature, that lets you make modules cooperate even if they don't want to.
I have to disagree -- in part -- about the advice system: used sparingly, I think it's one of the killer features that lets me tweak emacs exactly how I want it.
That said, yes, I think packages should be (at least) discouraged from using it. A highly dynamic and patch-able software system is a huge asset IF you're the only person working on it, which is true for my own emacs config. But having third parties simultaneously monkeying with the same component without knowing about each other is certainly a recipe for instability, even indeterminism.
That said, yes, I think packages should be (at least) discouraged from using it. A highly dynamic and patch-able software system is a huge asset IF you're the only person working on it, which is true for my own emacs config. But having third parties simultaneously monkeying with the same component without knowing about each other is certainly a recipe for instability, even indeterminism.
> I once submitted a bug to the Emacs mailing list and after determining
> it was indeed a defect, a flame war ensued between maintainers of
> different subsystems that were competing over how a specific feature
> was supposed to be used, which was the source of the bug. It was
> offputting and felt juvenile. Social problems are inevitable in any
> open source project, but I can’t help but wonder if the highly dynamic
> nature of Emacs Lisp causes more problems than a less dynamic language
> would.
Commercial developers have many internal discussions, with the difference that they will not show it to you.
Commercial developers have many internal discussions, with the difference that they will not show it to you.
At least in my discipline (statistics) the Emacs extensions for R and latex seem to be better than Vim, VSCode, etc.
Sample size = 1.
Sample size = 1.
Emacs has a lot of amazing extensions! Magit is unparalleled for working with Git. The problem is that they break more frequently, in my experience. The very fact that I have to install a 3rd-party DSL to have a sane package management experience is beyond the pale from a usability perspective.
Thank you for this thoughtful comment. I assume you are talking about use-package? I've been using it for several years.
There is a long standing effort to have it merged into emacs/elpa, so we hope the situation will improve.
https://github.com/jwiegley/use-package/issues/282
There is a long standing effort to have it merged into emacs/elpa, so we hope the situation will improve.
https://github.com/jwiegley/use-package/issues/282
Yes, I think it should be merged. Although the fact that this has been open since 2015 also highlights how the copyright assignment requirement slows down the pace of development.
Honestly, it's kept me from contributing to packages, too. I have no problem with the outcome, my patch being "owned" by the project -- that would be my intention by contributing.
I just have a strong dislike of bureaucracy, form-filling, and being "on file" somewhere.
I just have a strong dislike of bureaucracy, form-filling, and being "on file" somewhere.
Clunky interface aside (a given with emacs), what's wrong with package-list-packages and customize? It's essentially no different to installing and configuring packages in vscode. Why do you think use-package is necessary?
use-package + eschewing customize makes it easier to manage your Emacs configuration as code, and keep it synced across Emacs installations on different machines.
Otherwise, package-list-packages and customize are awesome. The interface isn't even that clunky, and it's more powerful than equivalent interfaces in other software. Particularly customize, I'm very impressed by how it works.
Otherwise, package-list-packages and customize are awesome. The interface isn't even that clunky, and it's more powerful than equivalent interfaces in other software. Particularly customize, I'm very impressed by how it works.
Tying configurations and customizations to a package, inter-package configurations, etc. are taken care by use-package. Disable a package, its related configuration is also cleanly disabled.
This happened all the time at a couple of companies I worked for. The advantage there however was the customer who filed the bug report couldn’t see all the emails bouncing around between teams over who was to blame and who needed to fix the problem.
I left emacs for vscode. The intellisense and code snippets did it for me.
As an Emacs and Lisp lover, the description of text-based tools and the power of using text to me just screams why something like Lisp is so powerful: homoiconicity. (And at least one big difference for elisp compared to Bash.) To quote Wikipedia [0] for anyone unfamiliar with the term, as I was until learning some Lisp:
"A language is homoiconic if a program written in it can be manipulated as data using the language, and thus the program's internal representation can be inferred just by reading the program itself. This property is often summarized by saying that the language treats "code as data"."
[0] https://en.wikipedia.org/wiki/Homoiconicity
(Edit: and if you want a good terminal emulator, you have eshell (emacs-y), ansi-term, and my current fave vterm [1])
[1] https://github.com/akermu/emacs-libvterm
"A language is homoiconic if a program written in it can be manipulated as data using the language, and thus the program's internal representation can be inferred just by reading the program itself. This property is often summarized by saying that the language treats "code as data"."
[0] https://en.wikipedia.org/wiki/Homoiconicity
(Edit: and if you want a good terminal emulator, you have eshell (emacs-y), ansi-term, and my current fave vterm [1])
[1] https://github.com/akermu/emacs-libvterm
I've been hearing the "code is data" mantra often, but the reason I never thought this was a desirable property is that it seems trivial to define any number of languages as their own AST. But there is a good reason that we don't program by writing out ASTs - it's relatively hard to read and manipulate. Does the Lisp implementation just happen to be particularly readable?
In a word, yes. S-expressions are a decent representation for data (lists and hierarchical structures) and the sort of code you write in a language derived from the lambda calculus, which is function calls. This is not by accident, though, since it is very desirable to manipulate code via macros.
The ast of a lisp program is essentially the same as the code of lisp itself. There is no intermediary step. Practically I'm sure there is, but conceptually that is they way it behaves.
The AST and the parse tree are basically the same. You only need to rename the bracket nodes to their first element.
LISP syntax is a data format. Unlike JSON though, its only structured data type is linked lists. `(a . b)` represents a linked list node (a pair or a `cons`) with the symbol `a` as first element and `b` as the second. The syntax `(a b c)` is a shorthand for `(a . (b . (c . nil)))`, with `nil` representing the empty list. It is commonplace to define what we nowadays call embedded DSLs using macros, which are just functions that manipulate LISP data structures before the interpreter evaluates them.
It is the first dynamic programming language, and arguably the most dynamic one. The only other non-esoteric language that comes close is PL/I, which also had macros and where every keyword could be redefined. But its standard is ungodly long, while Scheme dialects can be descriped in a few tens of pages. Also, it is quite easy to write an interpreter for core LISP: 100 to 200 lines, depending on your desire for readability.
Edit: Yes, this means there are lots of parentheses, which can be hard to read.
It is the first dynamic programming language, and arguably the most dynamic one. The only other non-esoteric language that comes close is PL/I, which also had macros and where every keyword could be redefined. But its standard is ungodly long, while Scheme dialects can be descriped in a few tens of pages. Also, it is quite easy to write an interpreter for core LISP: 100 to 200 lines, depending on your desire for readability.
Edit: Yes, this means there are lots of parentheses, which can be hard to read.
> It is the first dynamic programming language, and arguably the most dynamic one. The only other non-esoteric language that comes close is PL/I, which also had macros and where every keyword could be redefined
REBOL/Red are on a similar level.
REBOL/Red are on a similar level.
It is quite a bit more readable comparing (for example) to what you'd do in Python, basically a matter of few extra quotes. Here's an example https://github.com/magnars/dash.el/blob/a17b6b5409825891423b...
Another benefit apart from macros is that you can replace whole subexpressions to modify the function code: https://github.com/raxod502/el-patch#el-patch Although arguably you can achieve the same with source code and other languages: https://github.com/adamchainz/patchy#patchy
Although (as a keen Emacs user & someone who often hacks into existing librairies) user I'm not really convinced either that homoiconicity plays that huge of a role in Emacs malleability in particular -- to me it's more about hooks/advice system and being able to dynamically override things to tweak into the way I want them to behave -- and I don't see a good reason why this couldn't be possible in other languages.
Another benefit apart from macros is that you can replace whole subexpressions to modify the function code: https://github.com/raxod502/el-patch#el-patch Although arguably you can achieve the same with source code and other languages: https://github.com/adamchainz/patchy#patchy
Although (as a keen Emacs user & someone who often hacks into existing librairies) user I'm not really convinced either that homoiconicity plays that huge of a role in Emacs malleability in particular -- to me it's more about hooks/advice system and being able to dynamically override things to tweak into the way I want them to behave -- and I don't see a good reason why this couldn't be possible in other languages.
In addition to the other replies, I think it always takes time to learn a new language and its syntax, preferred formatting, etc. So I don't know what is more "natural," as that would depend on your background, but once I learned s-expressions it is my favorite way to read code. (Combine that with Emacs to handle all formatting, parens matching, and so on, and you can just think about code rather than decipher it too.)
It's kinda of a messy concept. Source code is never like an AST, because an AST is a tree on a computer's memory, with pointers and everything, while source code is text.
I see no reason why a language can not have a more complex source -> AST transformation, while still keeping code as readable data that can be manipulated by macros. So, if you want homoiconicity with a slightly more complex syntax, I don't think it won't bring any problem.
But if you keep making your language's syntax more and more complex, you will make macro creation harder and harder, so there is probably a practical limitation somewhere. Operators and statement sequences are very likely not complex enough to be a problem, but I don't think anybody will ever make native C++ macros work.
I see no reason why a language can not have a more complex source -> AST transformation, while still keeping code as readable data that can be manipulated by macros. So, if you want homoiconicity with a slightly more complex syntax, I don't think it won't bring any problem.
But if you keep making your language's syntax more and more complex, you will make macro creation harder and harder, so there is probably a practical limitation somewhere. Operators and statement sequences are very likely not complex enough to be a problem, but I don't think anybody will ever make native C++ macros work.
This is pretty tangential, but I don't understand why there isn't a roguelike framework available for Emacs. It seems like the perfect roguelike platform for playtesting and hacking on and would on-board a lot of new people into the Emacsen ecology without any real difficulty. The standard roguelike library libtocd has bindings for every other language--why not elisp?
There is dungeon-mode [0]. (I spotted this over on r/emacs [1], and it's on the FSF directory [2])
[0] https://github.com/dungeon-mode/game
[1] https://old.reddit.com/r/emacs/comments/jar7tz/dungeonmode_f...
[2] https://directory.fsf.org/wiki/Dungeon-mode
[0] https://github.com/dungeon-mode/game
[1] https://old.reddit.com/r/emacs/comments/jar7tz/dungeonmode_f...
[2] https://directory.fsf.org/wiki/Dungeon-mode
Well, it's not Elisp, but:
https://github.com/Ruin0x11/OpenNefia
It's an engine rewrite of an old roguelike I used to play in Lua. I'm trying to experiment with making a game where the engine is similar in flexibility to Emacs.
It has an Emacs frontend, and I designed it with the zealotry of an Emacs user, meaning it has advice, hooks, interactive evaluation and runtime module hotloading. You can run anything the engine can run from a REPL (and cause all the state to become broken easily).
To be clear, it's not a general-purpose roguelike engine, but it proves that with enough effort such an iterative developer experience of modding a game can be achieved.
https://github.com/Ruin0x11/OpenNefia
It's an engine rewrite of an old roguelike I used to play in Lua. I'm trying to experiment with making a game where the engine is similar in flexibility to Emacs.
It has an Emacs frontend, and I designed it with the zealotry of an Emacs user, meaning it has advice, hooks, interactive evaluation and runtime module hotloading. You can run anything the engine can run from a REPL (and cause all the state to become broken easily).
To be clear, it's not a general-purpose roguelike engine, but it proves that with enough effort such an iterative developer experience of modding a game can be achieved.
Hm, there's nethack-mode, but that's not what you mean, is it? You want a framework for building roguelikes, not for playing a particular one?
I've wondered the same thing! In particular, the highly polished and powerful interfaces of some roguelikes (DCSS comes to mind) strongly remind me of Emacs. It seems like the scriptability and power of Emacs interfaces is a natural fit for roguelikes.
That's funny. I've wondered that too, and from the other replies it seems you and I aren't the only ones. I half-assumed it existed and was just called something-incomprehensible-mode so I never heard of it.
I used to play Nethack within Emacs using nethack-el. It was really useful being able to bind a shortcut to something that could copy the map and append it to a text file with a note. :)
I was thinking about this a couple weeks ago as well.
I think specifically, transient.el is the 2d CLI. https://github.com/magit/transient
>One of the most popular arguments against Emacs is that it is “a great operating system, lacking only a decent editor”
That's false, as it does have the great Evil editor.
That's false, as it does have the great Evil editor.
Emacs is a text UI (though it can show images too) on top of a cross OS programming platform where you can create quick UIs for any kind of task you have (interfacing with APIs, command line programs, editing tasks, etc.).
Once you learn how Emacs works and how it can be programmed, you can create interactive tools extremely quickly to make lots of tasks you encounter day to day easier. I do this all the time.
Once you learn how Emacs works and how it can be programmed, you can create interactive tools extremely quickly to make lots of tasks you encounter day to day easier. I do this all the time.
Do you have any references/tutorials/examples on how to do this?
"Writing GNU Emacs Extensions" by Bob Glickstein is a solid introduction. After that, the Emacs Lisp reference manual (available as "info elisp" in the shell) gives much more detail.
Inside Emacs, you can:
- "M-x apropos" to search for commands of interest
- "C-h f" to get documentation for particular functions by name
- "M-x find-function" to jump to the definition of a particular function
- "M-x find-library" to load a library into a buffer so you can read and (depending on your permissions) edit it.
The Elisp reference is very good, and most libraries are well documented. Between that, the ability to jump around the code base, and trying things out in the "scratch" buffer (it's an Elisp REPL disguised as an editing buffer), you should be able to get quite far.
Inside Emacs, you can:
- "M-x apropos" to search for commands of interest
- "C-h f" to get documentation for particular functions by name
- "M-x find-function" to jump to the definition of a particular function
- "M-x find-library" to load a library into a buffer so you can read and (depending on your permissions) edit it.
The Elisp reference is very good, and most libraries are well documented. Between that, the ability to jump around the code base, and trying things out in the "scratch" buffer (it's an Elisp REPL disguised as an editing buffer), you should be able to get quite far.
Emacs has built in documentation. Learning emacs lisp is a good start:
https://www.gnu.org/software/emacs/manual/html_node/eintr/in...
This manual is also the part of the emacs distribution.
https://www.gnu.org/software/emacs/manual/html_node/eintr/in...
This manual is also the part of the emacs distribution.
The author is definitely right in saying that Emacs is an OS, because it runs "programs" that interact with a common datasource. The issue is that those "programs" are not the ones of your baremetal host.
The sequel that makes sense would be a text editor that allows host programs to be run seamlessly on the text. Once again the geniuses behind Plan 9 have shown how novel their system was by creating acme (https://www.youtube.com/watch?v=dP1xVpMPn8M). It allows any program to interact with whatever is in the text, so it clearly is the 2D cli the author is looking for
The sequel that makes sense would be a text editor that allows host programs to be run seamlessly on the text. Once again the geniuses behind Plan 9 have shown how novel their system was by creating acme (https://www.youtube.com/watch?v=dP1xVpMPn8M). It allows any program to interact with whatever is in the text, so it clearly is the 2D cli the author is looking for
Its also a daemon that does a lot of work for me from the shell!
I meta-click to capture xterm output, call dired, make it give me popup-windows to edit short scripts and long command lines, i query the feed-reader, get my backup-schedule, have it popup for debrief when new voice notes are downloaded, serve as an emergency window manager, capture into multiple bins while browsing, turn into a presentation tool, create pdf reports and write-ups, prompt me to check-in any leftovers at the end of the day, work seamlessly across my machines, provide menus to give access to files, clickable functions, org-summaries, fantastic spreadsheets .. oh wait, that's going beyond shell.
so yes, it made my beard grey. big deal, i can shave. sure it not perfect, sure its infuriating, surely i'm insane for continually investing into my future while tweaking something to compound its benefits.
but none of this makes emacs anything but a lisp machine -- so well loved and so close to the metal that it will be here after you and me. Call it a general purpose computing shell, not an OS, and please compare it to the living, not the dead!
I meta-click to capture xterm output, call dired, make it give me popup-windows to edit short scripts and long command lines, i query the feed-reader, get my backup-schedule, have it popup for debrief when new voice notes are downloaded, serve as an emergency window manager, capture into multiple bins while browsing, turn into a presentation tool, create pdf reports and write-ups, prompt me to check-in any leftovers at the end of the day, work seamlessly across my machines, provide menus to give access to files, clickable functions, org-summaries, fantastic spreadsheets .. oh wait, that's going beyond shell.
so yes, it made my beard grey. big deal, i can shave. sure it not perfect, sure its infuriating, surely i'm insane for continually investing into my future while tweaking something to compound its benefits.
but none of this makes emacs anything but a lisp machine -- so well loved and so close to the metal that it will be here after you and me. Call it a general purpose computing shell, not an OS, and please compare it to the living, not the dead!
Can you do all of those without emacs ? My point is that yes Emacs can do so many things, but 1) it's all accessible from Emacs only and 2) it uses Emacs-only components. This is fine if you live inside Emacs, but it doesn't really integrate with the rest of your system
Emacs is your system. You can't integrate all that well in the other direction, because host OS platforms don't let software interop as well. Even the Unix family.
The deep interop of course comes at the expense of security. There's no sandboxing or restrictions in Emacs world. One day somebody will release a piece of elisp malware, and a lot of people - myself included - will lose their crown jewels. But until then, we get to enjoy the only remaining relatively mainstream OS with deep interoperability.
The deep interop of course comes at the expense of security. There's no sandboxing or restrictions in Emacs world. One day somebody will release a piece of elisp malware, and a lot of people - myself included - will lose their crown jewels. But until then, we get to enjoy the only remaining relatively mainstream OS with deep interoperability.
Actually you can interop in the Unix family, that's what ACME is doing: write specific text to specific files and the content of your editor windows change. That allows the editor to implement any command you could find elsewhere, such as indent, put the contents of a directory, display compile errors...
I didn't realize that. I'll need to dig into ACME (and the history behind its ideas - I suspect there are many gems lost to time, like it is the case with Lisp machines).
> write specific text to specific files
Is that all plaintext, UNIX-style? Part of me wishes we could leave the era of unstructured text, and every tool carrying its own ad-hoc, bug-ridden, poorly specified parser and serialization logic - and send richly typed data structures (or objects) instead.
> write specific text to specific files
Is that all plaintext, UNIX-style? Part of me wishes we could leave the era of unstructured text, and every tool carrying its own ad-hoc, bug-ridden, poorly specified parser and serialization logic - and send richly typed data structures (or objects) instead.
That's kind of like asking "Can you do all the cool things Linux provides without installing UNIX?"
There is nothing genius about ACME.
Just like Emacs is a poor imitation of the developer experience on Lisp Machines, ACME is a poor imitation of developer experience on Oberon and Mesa/Cedar.
Just like Emacs is a poor imitation of the developer experience on Lisp Machines, ACME is a poor imitation of developer experience on Oberon and Mesa/Cedar.
How is it a poor imitation ? What is lacking ? (I've never used any of those predecessors)
On Oberon, Mesa/Cedar and Lisp Machines, the experience extends to the whole OS and any application, or REPL, not just a plain text editor.
Althought I haven't mentioned, Smalltalk also provides a similar experience.
Here are some videos that try to convey it, from my playlists,
"Eric Bier Demonstrates Cedar"
https://www.youtube.com/watch?v=z_dt7NG38V4
"Emulating a Xerox Star (8010) Information System Running the Xerox Development Environment (XDE) 5.0"
https://www.youtube.com/watch?v=HP4hRUEIuxo
"SymbolicsTalk28June2012"
"SYMBOLICS S-PACKAGES 3D GRAPHICS AND ANIMATION DEMO"
https://www.youtube.com/watch?v=gV5obrYaogU
"Symbolics Lisp Machine demo Jan 2013"
https://www.youtube.com/watch?v=o4-YnLpLgtk
The Native Oberon demos available at
https://www.youtube.com/channel/UCw6NbzmjW-wLvqVbxOXj7Ug/vid...
Althought I haven't mentioned, Smalltalk also provides a similar experience.
Here are some videos that try to convey it, from my playlists,
"Eric Bier Demonstrates Cedar"
https://www.youtube.com/watch?v=z_dt7NG38V4
"Emulating a Xerox Star (8010) Information System Running the Xerox Development Environment (XDE) 5.0"
https://www.youtube.com/watch?v=HP4hRUEIuxo
"SymbolicsTalk28June2012"
"SYMBOLICS S-PACKAGES 3D GRAPHICS AND ANIMATION DEMO"
https://www.youtube.com/watch?v=gV5obrYaogU
"Symbolics Lisp Machine demo Jan 2013"
https://www.youtube.com/watch?v=o4-YnLpLgtk
The Native Oberon demos available at
https://www.youtube.com/channel/UCw6NbzmjW-wLvqVbxOXj7Ug/vid...
I'm surprised to find no discussion about the fact that emacs is single threaded. You can achieve a lot but at some point (eg: running it as a window manager) it becomes a little less snappy.
This is the only reason why emacs is no longer my default editor. I value customization, but I learned I value snappiness more.
If you don't mind sharing, what is your current default editor?
Intellij idea for project based coding, nvim/emacs for quick edits. I've gone from "my life lives in emacs and org mode" to "I use a couple made for purpose apps and live with the fact that not everything is a buffer in a self modifying strange loop."
I saw a post on hacks to bring video/animations into Emacs using :base_uri svg functionality going in the direction of subwindow glyph functionality.
The type of interface of Emacs is not the CLI, but "roguelike" interface. ESR in "Unix Interface Design Patterns":
>> The Roguelike Pattern
Programs obeying this pattern are legion: The vi(1) text editor in all its variants, and the emacs(1) editor; elm(1), pine(1), mutt(1), and most other Unix mail readers; <<
http://www.catb.org/esr/writings/taoup/html/ch11s06.html
>> The Roguelike Pattern
Programs obeying this pattern are legion: The vi(1) text editor in all its variants, and the emacs(1) editor; elm(1), pine(1), mutt(1), and most other Unix mail readers; <<
http://www.catb.org/esr/writings/taoup/html/ch11s06.html
Unix philosophy to use single programs for one task has its particular context, and Emacs does not fit into the context, just as no other programming language is made "for single text". Your comparison is out of the context.
So is vim? Not to rehash the same battle that’s likely older than most of us are, but both emacs and vim are text editors taken to their logical conclusion. Both can do pretty much the exact same thing as each other, if only because some neckbeard in the 80s wrote that feature to score points in the great vim/emacs saga.
The way I see it, emacs is really an idea.
Vim is a text editor that grew into an ecosystem of people bolting on additional functionality. While extensibility is possible, it's nowhere near as transparent and consistent as the emacs environment. In fact no system I know of comes even close.
Emacs paved the way for the features we take for granted in graphical applications like undo, copy+paste, search, find+replace, spell check, project navigation, code completion, auto-formatting, and of course, plugins.
These days, indeed much of the appeal is gone if all you're doing is comparing features at a surface level.
Yes, it looks like all editors "do the same thing" but really emacs is quite different in spirit.
Vim is a text editor that grew into an ecosystem of people bolting on additional functionality. While extensibility is possible, it's nowhere near as transparent and consistent as the emacs environment. In fact no system I know of comes even close.
Emacs paved the way for the features we take for granted in graphical applications like undo, copy+paste, search, find+replace, spell check, project navigation, code completion, auto-formatting, and of course, plugins.
These days, indeed much of the appeal is gone if all you're doing is comparing features at a surface level.
Yes, it looks like all editors "do the same thing" but really emacs is quite different in spirit.
If emacs adopted vim-like keybindings early on the war would have ended. It's the only reason I stick with vim, and I suspect I'm not alone. Yes, yes, evil mode and whatever, but it's not seamless - you still have to get familiar with emacs keybindings.
I'm not sure I agree keybindings were/are the significant factor. The editors have a completely different history and their authors come from very different backgrounds.
I'm talking about the war of usage/mindshare rather than a war between the authors.
I am not sure. Sure with deamon mode and lazy loading emacs can be really fast to start up and open files nowadays, but the old joke was EMACS stood for "eights megs and constantly swapping". Evil mode is just the more recent iteration of vim keybindings in EMACS that go all the way back to modes like viper mode.
Most vi users actually use vim or neovim with complicated configs and dozens of plugins - setting up daemon mode and lazy loading would not be a problem. Emacs would be my daily driver if it had native vi keybindings. And i could go back to vi/vim if I logged into a server and had to edit a file.
It they do a vim emulation that is good enough, then Emacs will eventually vanish... everyone will effectively use vim on different implementations.
Emacs was 21-ish when vim came along
vi and emacs were released in the same year.
The fact that vi iMproved became the dominant implementation isn't particularly relevant here.
The fact that vi iMproved became the dominant implementation isn't particularly relevant here.
> The fact that vi iMproved became the dominant implementation isn't particularly relevant here.
I think it is. Most vim users I know have never used vi and would hate it.
As a reminder: In vi, when you go into "insert" mode, you cannot edit anything prior to where the cursor was when you entered insert mode. vim got rid of such annoyances.
I think it is. Most vim users I know have never used vi and would hate it.
As a reminder: In vi, when you go into "insert" mode, you cannot edit anything prior to where the cursor was when you entered insert mode. vim got rid of such annoyances.
The topic of discussion was:
> If emacs adopted vim-like keybindings early on
I consider it obvious that "vim-like" keybindings are also "vi-like" keybindings, and that emacs could in fact have adopted them before the invention of vim.
It wouldn't have of course; when the Editor Wars were truly raging, the modal vs. modeless debate was at the heart of the partisanship. But that's a separate question.
> If emacs adopted vim-like keybindings early on
I consider it obvious that "vim-like" keybindings are also "vi-like" keybindings, and that emacs could in fact have adopted them before the invention of vim.
It wouldn't have of course; when the Editor Wars were truly raging, the modal vs. modeless debate was at the heart of the partisanship. But that's a separate question.
Are vim users going to be able to use vi? Genuine question. I’ve barely used either.
Yes, vim is a superset of vi
Vi/m won the distribution war. It’s everywhere. It’s on every Unix-like system I’ve ever used.
Discovering emacs on OS X Tiger was my first true introduction to the power of TUI/CLI. I use vim now, and Atom with vim bindings, but I have to agree that there’s something special about the spirit of emacs.
Emacs is a good programming environment, but it's a bad editor. They should have spent a little more time thinking about decent keybindings.
Emacs is an elisp execution environment that by default executes some elisp that is useful for editing text.
Vim is... a text editor.
Vim is... a text editor.
Vim is... an extensible text editing language.
This is spot on, I use Emacs as an X window manager, terminal, file manager and so on, not just as an editor.
Not interested in editor wars, but regarding the OP, Emacs has a fundamentally different architecture to vim and always has, lending it to the sort of customizability the article focuses on. It's essentially just a lisp interpreter that you can customize completely.
It is still a mono system.
An OS is really not care you run c, lisp, VM and another os fundamentally. In this sense emacs is not an OS. And is mono. Just like Common Lisp.
An internal “closed” system can have diversity. But not put external as first object, just as OS would not normally running OS task as the most important thing but running user land task.
A “closed system” like emacs and Common Lisp is unlike say OS and vs code, they are not the kind that you as the user program of the emacs or Common Lisp can be of a totally different idea of how in addition to what and still co-exist nicely. Can you write a program of c and run under and with emacs and Common Lisp ...
Even Api and extension need to be purposed for external interaction as it needs to assume difference that with a totally different approach.
Totalitarian can say harmony with difference but in real it is just totalitarian. Democracy can be suppressed but ultimately is a diverse system.
An OS is really not care you run c, lisp, VM and another os fundamentally. In this sense emacs is not an OS. And is mono. Just like Common Lisp.
An internal “closed” system can have diversity. But not put external as first object, just as OS would not normally running OS task as the most important thing but running user land task.
A “closed system” like emacs and Common Lisp is unlike say OS and vs code, they are not the kind that you as the user program of the emacs or Common Lisp can be of a totally different idea of how in addition to what and still co-exist nicely. Can you write a program of c and run under and with emacs and Common Lisp ...
Even Api and extension need to be purposed for external interaction as it needs to assume difference that with a totally different approach.
Totalitarian can say harmony with difference but in real it is just totalitarian. Democracy can be suppressed but ultimately is a diverse system.
> Can you write a program of c and run under and with emacs and Common Lisp
Yes to both.
Yes to both.
Don't hate on me. I use Emacs just about every day. I used to use Emacs as my go to editor for writing code ... and it almost worked. But it was never hassle free, and things often worked more poorly than I would have liked, or ended up requiring too much fiddling to get it to work right, or packages were inadequately maintained. So now, I tend to use it for quick, short code writes, especially when I'm remoted in to a server. I also use it for org-mode, and for writing my book.
Now I use Pycharm for python and web development for things that can reasonably be called a "project"; the level of language support, introspection, and intelligent code prediction exceeds anything I ever achieved in Emacs.
I use VSCode for quick scripts, and for when I need to do maintenance work on some old php code. I like it fine. It fits in this really nice place between a full IDE and a bare bones text editor like Notepad or even BBEdit (ha!).