Emacs is the 2D Command-line Interface
hongchao.me
hongchao.me
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!).
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.
Maybe language support will get better with LSP; anyone know how that is going in the emacs world?
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.
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!
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.
--
Like it can, but not on our codebase
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...
Clang's developers might appreciate the corresponding bug reports.
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 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
- 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, 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.
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.
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.
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.
I also find myself using emacs short cuts when using Excel, which doesn't work, at all, of course.
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...
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.
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.
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).
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.
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.
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.
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.
Emacs specifically also needs a lot of user interface-side polish to deal with the increase in the complexity of these plugins.
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.
- 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.)
Use it in complex way and you will stumble upon plethora of troubles. That is feature, not bug.
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.
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 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.
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.
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 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.
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.
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.
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.
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.
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.
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
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.
55% according to the Emacs survey 2020 (obviously, take it with a pinch of self-selection bias due to the survey being self selecting).
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 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.
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.
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.
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.
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.
> Do we have any hard data here?
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.
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.)
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.
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
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.
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.
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 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.
2. Did your journey into computing start with CLIs, TUIs, GUIs?
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.
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.
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.
Commercial developers have many internal discussions, with the difference that they will not show it to you.
Sample size = 1.
There is a long standing effort to have it merged into emacs/elpa, so we hope the situation will improve.
I just have a strong dislike of bureaucracy, form-filling, and being "on file" somewhere.
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.
"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])
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.
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.
REBOL/Red are on a similar level.
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.
[0] https://github.com/dungeon-mode/game
[1] https://old.reddit.com/r/emacs/comments/jar7tz/dungeonmode_f...
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.
That's false, as it does have the great Evil editor.
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.
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.
https://www.gnu.org/software/emacs/manual/html_node/eintr/in...
This manual is also the part of the emacs distribution.
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
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!
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.
> 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.
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.
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...
>> 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; <<
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.
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.
> 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.
Vim is... a text editor.
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.
Yes to both.