10 ms·

IDEmacs: A Visual Studio Code clone for Emacs

301 points by nogajun 11mo ago

tiffanyh 11mo ago
I was always bummed OniVim v2 didn't take off. It was a native IDE but fully supported VS Code plugin system. https://web.archive.org/web/20210627210456/https://v2.onivim.io/ https://web.archive.org/web/20210627210456/https://v2.onivim...
- arbitrandomuser 11mo ago
  onivim also seperated the core functionality of the vim editor into a seperate library libvim , this would have been great for other people looking to make their own gui frontend to vim . neovim does not give a libneovim, but exposes an rpc where you communicate with neovim running as another process, this I would have thought have more latency but apparently is fast enough , this is how the vscode plugin for neovim is able to provide a near complete vim experience. Other neovim guis like neovide use this too
- koiueo 11mo ago
  From a quick glance, I can't understand the target audience. Vim users would be annoyed by bizarre input lag of an electron application and perhaps by EULA. VS code users don't really care about Vim...
  - forgotpwd16 11mo ago
    >of an electron application It isn't an Electron application*, that's why GP said native. The EULA part though was probably a block to adoption. *It uses Revery, a, made by OniVim's devs, cross-platform GUI framework (similar to Flutter but build on Reason/OCaml).
    - koiueo 11mo ago
      Oh, ok, now I'm curious to try it despite EULA (although these days the wide choice of (neo)vim distributions utilizing LSP makes their offering less appealing). Thanks for the clarification. The site doesn't stress the not-electron part enough, maybe that contributed to the failure.
      - forgotpwd16 11mo ago
        Should've probably mentioned it before but it actually used a dual-license model by having an MIT version that lagged behind upstream for 18 months (could be found in oni2-mit repo). During last month when development stopped it was fully re-licensed under MIT (hence oni2-mit repo no longer exists).
  - iLemming 11mo ago
    > VS code users don't really care about Vim I disagree. vim-navigation is imperative for a huge number of devs. It's an amazing, practical, beautiful model. I would've never tried emacs if Evil-mode wasn't so fantastic. And that yet another reason for why vscode never is appealing to me - every one and each vim extension for it has tons of glaring deficiencies.
    - koiueo 11mo ago
      I'm not sure what you disagree with. I'm saying VS Code isn't targeting Vim users, and core VS Code user base doesn't care about Vim. I too can't take a seriously an editor which doesn't have Vim keybindigns at least in a very basic form.
      - iLemming 11mo ago
        Ah, I've misinterpreted it then. > I too can't take a seriously an editor which doesn't have Vim keybindigns at least in a very basic form. tbh, I can't take any experienced programmer seriously if they never even tried learning at least some basic vi-navigation commands. I'm like, "what? have they never used `sed`, `less`, `more` or never read man pages? have they never logged to a remote machine? why kind of a coder doesn't know any of this shit?" I mean I get it, it's not universally appealing to everyone, some prefer not to bother. But not knowing it at all? That's weird to me. And yes, I agree - If you're making an editor for coders (standalone, embedded, web or native), modal navigation must be possible.
trenchpilgrim 11mo ago
This would have been great when I was learning Lisp in school! I tried emacs but due to joint issues the keybinds were painful to use, so I gave up and did the course in vim+SBCL's REPL instead.
- dmead 11mo ago
  Which joint issues? Have you tried evil mode?
  - trenchpilgrim 11mo ago
    > Which joint issues? Pretty sure it's rheumatoid arthritis. > Have you tried evil mode? This was like fifteen years ago and I just went back to my working Vim setup I was already using for all my other classes.
    - dmead 11mo ago
      Sorry to hear that. I have a family history of that as well. I think I'm starting to show signs of it. Vim forever I guess. Im typing on a full split with cherry reds (very soft). What are you on?
      - trenchpilgrim 11mo ago
        Started using an Ergodox EZ with a custom map after I shattered one of my wrists in a vehicle crash, have stuck with it since.
- yvdriess 11mo ago
  It is fairly common for emacs users to bind Ctrl or Meta to caps lock for improved ergonomics. There's also a bunch of RSI sufferers that are using foot pedals, which actually makes a lot of sense. I personally switched to emacs for more than just Lisp when I started developing early signs for RSI. Switching to a purely KB driven interface has saved my wrists.
  - 11mo ago
pizlonator 11mo ago
That screenshot is super pretty. Very impressive!
- contrapunctus 11mo ago
  Thank you!
tom_ 11mo ago
C-x, C-c, C-w, C-s, C-k, C-g, C-] - goodness me, somebody absolutely does not give a shit what anybody thinks. I would never use this, but, somehow, I still love it. I dare the author to rebind M-x as well.
- skullt 11mo ago
  In fairness, Emacs has long had cua-mode for rebinding C-c, C-v, C-x, and C-z to copy, paste, cut, and undo, so at least those changes are not too radical.
- az09mugen 11mo ago
  Agree with you. Coming from sublime and always wanting to give emacs a fair try, I found ergoemacs [0] that wanted to expand the cua mode for beginners, but that was not enough for me. I wanted more, and now with IDEmacs it is almost like what I want. With emacs you can do pretty much anything, why not a full cua mode ? [0] : https://ergoemacs.github.io/ https://ergoemacs.github.io/
- Iwan-Zotow 11mo ago
  It was pc mode and then cua mode
charcircuit 11mo ago
I would really like to see this kind of work be done upstream. Emacs still looks the same as it did decades ago despite other editors advancing and becoming more user friendly.
- raincole 11mo ago
  I'm afraid that many people consider "looking the same as decades ago" a feature...
  - compiler-devel 11mo ago
    It is, the default UI is stable and can be changed somewhat easily.
- manithree 11mo ago
  Please, no. Emacs could use some interface/toolkit update, I don't deny that. And I like IDE features. I use tree-sitter, LSPs, copilot.el, copilot-chat.el, and others all day, every day. But don't force me to turn off treemacs, and minimap like I have to do in VSCode all the time just because some useless, space-wasting eye-candy is trendy.
- stackghost 11mo ago
  A huge portion of the emacs community seems resistant to any UI improvement. I think it's a counterculture thing.
  - komali2 11mo ago
    It's because a lot of us resist the implicit argument that UI changes are automatically improvement when in fact it's just as often regression.
    - brabel 11mo ago
      Yep. Look at IntelliJ. It just copied VsCode when it already had a great UI where things were easy to find and consistent. Now it’s got meaningless icons and hides important stuff by default, making it modern but far worse than before. Thank goodness emacs is not trying to chase the latest and stupidest.
giancarlostoro 11mo ago
I would love to see a project that rebuilds the Emacs UI but keeps the underlying core to give it a modern facelift, some things in emacs blend together and are a pain for my eyes to figure out whats what. It would be nice if the UI was modernized but the core was left as-is. I'm reminded of some of my favorite editors that are niche being Lisp related ones, where if you held down ctrl it would show you shortcuts in the UI itself and what they lead to. I also always enjoyed Racket's import arrows and other small things that are visually amazingly impressive despite being so simple.
- pama 11mo ago
  You mean something like which-key? It existed for a long time as an external package and was added to main emacs recently. https://github.com/emacs-mirror/emacs/commit/fa4203300fde6820a017bf1089652fb95759d68c https://github.com/emacs-mirror/emacs/commit/fa4203300fde682...
  - tiu 11mo ago
    Alternatively beside which-key, hydras exist which are very nice for certain contexts (dired in the particular case for me) and provide a nice shortcut interface whenever activated. Demo at [0]. [0]: https://www.youtube.com/watch?v=_qZliI1BKzI https://www.youtube.com/watch?v=_qZliI1BKzI
  - setopt 11mo ago
    As far as I know, which-key only helps with key sequences. If you press C-c in Org-mode it will show you keys like C-c C-e, but if you hold Ctrl down it won’t show you C-RET for example.
    - pama 11mo ago
      If you want all keybindings, C-h b typically helps, and you can search within the single buffer it returns. Every key in Emacs is bound to something, but a plain modifier key event like Ctrl will not be sent from a terminal to any command that runs inside it, eg Emacs, only the modified key. (There exist modifications/extensions of this protocol, eg kitty, but most combinations wouldnt see these events.)
jasperry 11mo ago
As a long-time Emacs user, I'm surprised by how easy it has become lately to configure Emacs as an IDE, mainly due to the built-in eglot. You need a lot less elisp code than you used to. A working Python setup is like one line of config. Which is to say, this project isn't really for me, because I'm already familiar with Emacs keybindings. And as for a new user, they're going to eventually have to deal with the underlying configuration. Maybe it's a gateway drug?
- bionsystem 11mo ago
  I used emacs at school some 15 years ago and I remember it being pretty seemless, I had an OCaml repl for one course and a 68000 emulator with memory inspection for another, and gdb integrated for C ; I do NOT remember hours of configuring that, maybe put some files at the right places and that was it. Switched to vim due to work (that was what's installed on remote machines), kept it for years because of the ubiquity. More recently in a new gig I'm finally able to install stuff on my machine (with homebrew) and not just work remotely, wanted to revisit my choice between (neo)vim and emacs again, but I guess muscle memory is too strong and still chose the former, although trying emacs I can tell that it is maybe even better polished now with the package manager and everything. Turns out neovim has the same with lazyvim, mason, etc. Just a bit more friction sometimes maybe. My main pain point right now is the lack of tooling for devops/sre in general. Yes we have LSPs for ansible, groovy, terraform... But they do not cover the entirety of plugins and modules that can be used, and I'm not aware of good tools for testing and debugging. Yes there is teamcity but that needs a license and I can't have that at work apparently. I don't think it is at the editor level though, just the ecosystem is lacking.
pca006132 11mo ago
What I miss from vscode is the remote functionality, can you do it with emacs? For neovim there is distant.nvim, but idk if it is mature enough and configuration seems a bit annoying...
- hirvi74 11mo ago
  There is TRAMP. https://www.gnu.org/software/tramp/ https://www.gnu.org/software/tramp/ I am not sure if it will fit your needs or not.
- stackghost 11mo ago
  I believe the analogous thing in emacs is called TRAMP. I have no idea if it's good, as I never edit files remotely, but it exists.
- brendyn 11mo ago
  Emacs already does that with TRAMP via SSH -- You just open a file like /ssh:user@server:/etc/hosts the main downside is if your connection is laggy Emacs will lock up momentarily. There is an ongoing effort to improve the multithreaded-ness and async-ness of Emacs to make it nicer
- blubber 11mo ago
  What kind of remote functionality? Lately, somebody mentioned https://code.visualstudio.com/docs/remote/tunnels https://code.visualstudio.com/docs/remote/tunnels
- v9v 11mo ago
  I use TRAMP to edit code loaded on robots occasionally. One advantage compared to VSCode is that it doesn't require the installation of anything onto the computer you're connecting to, since it uses the usual linux tools to work. But it can freeze up once in a while.
- valcron1000 11mo ago
  Not at the same level. TRAMP is way behind feature-wise.
bitwize 11mo ago
I don't see a point to this beyond hack value. Turning Emacs into a shitty version of an inferior editor is kind of a waste. If you really want Visual Studio Code, just use Visual Studio Code.
ruguo 11mo ago
If you don’t use it that often, you might wanna try the Emacs plugin for VS Code instead.
- ishiguro_ 11mo ago
  Do you have any recommendations?
  - Myrmornis 11mo ago
    Yes the best one is https://marketplace.visualstudio.com/items?itemName=tuttieee.emacs-mcx https://marketplace.visualstudio.com/items?itemName=tuttieee...
- trenchgun 11mo ago
  What on earth are you talking about?
- aaravchen 11mo ago
  To be clear, this plugin is only a keymap, and just extends the built in Emacs-style keymap option of VSCode. If you did much/any mapping of any keys in Emacs, or are looking to expose more Emacs-like features, you're SOL. VWCode is simply unable to support most Emacs editing features without a significant engine expansion, and that's beyond the ability of plugins to add.
deleted 11mo ago
[deleted]
zozbot234 11mo ago
How does this configuration behave in a non-graphical terminal, e.g. as used with SSH? Can we have something that's at least on par with the UX from the old Borland text-based Turbo Vision IDE's (Turbo Pascal/Turbo C++), with a few modern convenience features?
yanhangyhy 11mo ago
i still use emacs everyday, with the native UI. but i love the idea of this project. Personaly i never get used to the UI of VSCode. seems so hard to understand because in emacs you deal with functions not UI buttons.
- setopt 11mo ago
  > Personaly i never get used to the UI of VSCode. seems so hard to understand because in emacs you deal with functions not UI buttons. I prefer both Vim and Emacs over VSCode, but I teach intro programming at a university and use VSCode in the lectures. VSCode is actually quite decent if you use it as a keyboard-driven thing with a distraction-free interface. By the former, I mean that Cmd-Shift-P does the same as Emacs’ M-x, and from the keybinding hints you quickly learn any recurring useful bindings (or can change them under Cmd-K Cmd-S when they feel bad). By the latter, I mean that nearly every UI element can be disabled (activity bar, tab bar, status bar, scroll bar, most buttons, indent guides, gutters, etc.) and if you spend 30min disabling the fluff it looks as minimal as Emacs. You don’t really need the UI elements if you learn Cmd-Shift-P and basic keybindings, which as an Emacs user you’ll pick up in a week. Not trying to sell VSCode here, as I said I don’t prefer it myself. I really tried to switch some times, but I don’t like the Microsoft monoculture nor the importance of proprietary plugins (like remote development and pylance), and an Electron app usually has some weirdness when it comes to font rendering, UI bugs, etc. compared to native or terminal apps. But if you have to use it, it’s actually not bad if you approach it in the same way you’d approach Emacs: Call functions with Cmd-Shift-P (can rebind to M-x if you want), and invoke more common functions via keybindings instead of UI elements.
  - yanhangyhy 11mo ago
    well, that explains a lot. i guess its me not spending time to learn the basics of VSCode but got lost in the interface. seems a quite elegant design.
  - iLemming 11mo ago
    > Cmd-Shift-P does the same as Emacs’ M-x Only superficially, but not even close in practice. In M-x you can run recursive commands; you have history; you can search through history back and forth; you can scroll the buffer, shrink and widen windows, browse files - all without leaving the M-x menu; you can yank current command or insert directly into the buffer; select multiple commands; act on them; inspect the source; enable tracing; - these are all built-in features. With some packages you can - export the commands list into a fully functional buffer from which you can still run the commands; you can cycle annotations - show description of the command or keys they bind to; you can display commands in a grid or temporarily flatten the menu for unobtrusive view. You can enable full vim-mode in it - in Emacs, M-x is a fully functional buffer, not some dummy input - I can call the LLM and ask it to find me a command while it's still active.
Surac 11mo ago
I like to express my loyalty to the emperor of man and call this heresy
noelwelsh 11mo ago
This won't take me away from Doom Emacs---I prefer the keyboard centric approach of Doom---but I'm really happy to see this. I feel that Emacs has some really innovative UI plugins (things like Vertico) but the out-of-the-box experience is pretty bad. If this makes Emacs more accessible to a different group of people I think it's great.
self_awareness 11mo ago
For me, VSCode implements everything that I've always expected from Emacs/Vim. I've spent years to configure emacs/vim to be a good programming editor. Years, multiple configurations, vanilla configs, space/doom emacs configs, multiple predefined configs for vim/neovim. Something always was broken, something was missing, something was non-optimal just below the tolerance line. Missing features, discontinued packages, initialization errors, bad versions, "known issues", LSPs not starting, packages replaced by some newer shinier package with different usage, cryptic setups that are wrapped in "convenience layers" that obscure details, making it completely incomprehensible. Then VSCode came and it had everything. Remote development is trivial through ssh. Completion simply works without any setups. Massive number of languages supported. It's a mess inside, but the UX is more stable and more consistent than anything I've ever seen in emacs/vim. Sometimes something breaks, but I can restart the window backend without closing the app easily. This is really telling. Despite dedicating years to configure an "infinitely configurable" system, I wasn't able to achieve anything stable. I've given up and i just use VSCode daily. This way, I have more than I ever had with emacs/vim. The only thing I have from vim that's left is the keyboard layout. For this, I'm thankful to Vim, but the editor itself for me is just for editing config files. I don't even have Emacs installed anymore.
- roman_soldier 11mo ago
  This, most people that try and use these legacy editors spend most of their time configuring it get it to be as good as vs code and usually fail. A lot of wasted time and frustration when one click gives you a perfectly modern fast editor with a smorgasbord of great extensions that just work. I do use vim for quick editing of files in the terminal but never for serious work.
  - omnicognate 11mo ago
    Not sure where you get "most" from. Personally I've found the exact opposite: Despite having been forced by work constraints to use most major IDE platforms at one point or another, sometimes for years at a time, I always come back to emacs with great relief and find it better in pretty much every way. I know better than to assume my experience is that of "most" people, though.
imiric 11mo ago
This is great to see, and I'm sure it will nudge some people to give Emacs a try who wouldn't have otherwise. I've been using Emacs with a custom configuration for many years now, but when I needed a good IDE for working with modern frontend stacks about a year ago, I decided to give VSCodium a try, since the TS/LSP integration wasn't that great in Emacs. And funnily enough, I did the reverse of what this project does: I tried to make VSCodium look and behave more like my Emacs setup. It turns out that this is incredibly difficult. Decluttering the UI was easy enough; getting my Vim/evil-mode key bindings to work was relatively straightforward, though not perfect; but it was practically impossible to make VSCode work with the concept of buffers, instead of tabs and tab groups. There are some extensions that emulate this to an extent, but it requires at least one change[1] to work properly that's been ignored for almost 2 years now. So, that, general jank and unresponsiveness, and the idea of my editor being a web browser with all the security concerns of installing random JS extensions, put me off it for good. I went back to my "inferior" Emacs setup, spent some more time on configuring it for TS, and I think it's not so bad right now. Though I switched projects in the meantime, so it probably needs to be brought up to date again. Moral of the story: Emacs is life. I'm sorry I ever doubted it. <3 [1]: https://github.com/microsoft/vscode/issues/204942 https://github.com/microsoft/vscode/issues/204942
- aaravchen 11mo ago
  I did exactly the same, though I wasn't an Evil mode user. I quickly found VSCod(e|ium) lacks the internals to even do many of the basic useful things of Emacs. BTW, if you're an Evil mode user, Zed is probably your better choice. It has more focus on Vim-style keybindings.
  - hollerith 11mo ago
    Similar story here. I used vscode for about 3 months for all my editing needs without even having Emacs installed, but returned to Emacs because of how hard it was to learn how to modify vscode (I'm not a web dev) compared to modifying Emacs and because of a vague impression that vscode is slower in responding to my inputs.
eamonnsullivan 11mo ago
I love these packages (like this, Spacemacs, Doom, etc.), even though I've used Emacs for over 30 years. I don't use them directly, but they give me ideas and alert me to packages I haven't heard of (eat?). And that gives me an excuse to go on another round of config-tweaking, which any Emacs user loves.
- finnjohnsen2 11mo ago
  Hear hear. I poked around at almost all the packages on the top of that idemacs page. «minimap» stood out, and is such a brilliant name for its purpose. I enjoyed that discovery and the smirk it gave me today.
pronik 11mo ago
Whoever thinks that VSCode does not have any learning curve or is somehow magically easy, needs to take a reality check, that thing is overwhelming with all its popups, hovers, sidebars etc. beyond all reason when you first run it (and later too). I'm an Emacs user and I don't in any way support the notion it's somehow easy or intuitively workable, it's most definitely not and never has been. I just think that VSCode is not it either, it's just the more popular tool right now.
- torben-friis 11mo ago
  Every piece of software that’s effectively a professional workbench (IDEs, DAWs, video editing, etc) is going to have some complexity. I can’t imagine the argument that vscode’s level of complexity is even in the same order of magnitude as vim or eMacs though. A 2 minute tutorial or half an hour or fiddling will get you sorted with vscode, I needed a full ebook for neovim.
  - skydhash 11mo ago
    VSCode rely on familiar pattern and UX to let you get started easily. But out of the box, it's pretty much notepad level. Vim and Emacs start from the premises that you need powerful tools. And they give them to you alongside the possibility to integrate external tools easily with the editor workflow. With VSCode any integration needs to be a full project. With emacs and vims, it's a few lines of config.
    - torben-friis 11mo ago
      What kind of integration is a full project? Integrating language support for example is usually just heading to the plugins section, searching for the language and clicking install on the most mainstream result. My config for vscode is just like 5 lines to make keyboard travel between panes a bit more vim like, other than that I never needed to change much from defaults. For neovim the work to make it ide-like is a large list of plugins and its integrations, large enough that I’m comfortable outsourcing the consistency to a distro (lazyvim).
ClimatePaywall 11mo ago
[dead]
johnhamlin 11mo ago
Love to see this. I lost steam working my way through SICP a couple of years ago because I spent so much time trying to figure out Emacs instead of writing Scheme
kleiba 11mo ago
Long-time (25+ years) Emacs user. The first thing I do on a new installation is turn off the GUI features (like, menus and toolbars) - no-one I know who uses Emacs uses the mouse.
- femiagbabiaka 11mo ago
  VSCode users, especially new ones, do. The best property of Emacs is that you can modify the lisp machine to do whatever you want.
  - pxc 11mo ago
    If you use an editor or IDE at work for a year, you might work with it for a thousand hours that first year alone. But a noisy GUI like VSCode's is optimized for just that first 30 minutes of playing around. For me, at least, that kind of thing doesn't end up being very enjoyable long-term.
  - DonaldPShimoda 11mo ago
    > the lisp machine I wonder whether this was intentional or a coincidence, but for others (and maybe you) the "Lisp Machine" was a real hardware architecture unrelated to emacs: https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine
- deleted 11mo ago
  [deleted]
- deleted 11mo ago
  [deleted]
- globular-toast 11mo ago
  Another long time (15+ years) Emacs user here. I similarly use it completely keyboard driven. I have seen someone use it with the mouse, though. My PhD supervisor used completely stock Emacs to do LaTeX and actually used all the menus to do stuff. Quite eye opening for me.
musebox35 11mo ago
As a 15+ years emacs user the only item on my wishlist is client-server remote editing mode similar to that of vs code. Then I can go back to using emacs on cloud VMs. Does anyone know a solution to this that works as good as VS Code even when your latency is high? Hopefully, I will be pissed off with all the weird configuration flags of VS Code enough to write one myself ;-) To be fair its python integration is quite good at least for the usual stuff.
- PessimalDecimal 11mo ago
  Two approaches might work here: 1) Run Emacs on your local machine and use Tramp to edit the remote files 2) Run Emacs on the remote machine with the files you're editing. This likely means running in the terminal itself (emacs -nw or requivalently emacs -t).
jamesgill 11mo ago
Emacs for programming is definitely one important use case. This tool seems to focus on that use case, though I think I can get 75% of it by just using Emacs keybindings with regular VSCode. But Emacs is so much more than an ‘IDE’. I realize some don’t like the Emacs approach of ‘here’s a box of parts and tools, build it the way you want’, but that’s the point of Emacs. Besides the functional approach, of course, there is the philosophical stance: freedom. Emacs is an elegant weapon from a more civilized age. But some people prefer blasters, and that’s okay.
- skulk 11mo ago
  > Besides the functional approach Nitpick, but emacs and emacs lisp don't seem remotely "functional" to me insofar as expressing computation in terms of pure functions and immutable datatypes. The core datastructures that an elisp program interacts with (buffers, variables) are all mutable and functions (setq, buffer-string, etc) are decidedly impure.
  - jamesgill 11mo ago
    I wasn't talking about programming.
cmrdporcupine 11mo ago
I've got a whole labouriously created setup for my emacs that is roughly equivalent to my RustRover setup in terms of capabilities (though not [mostly] in terms of keybindings because my fingers are fine with default emacs bindings). And I still barely use it, and I continue to fire up RustRover constantly. Because it just never feels snappy and fluid and responsive and stable. RustRover is a slow dog at times, but even it outperforms emacs for a lot of things. The lack of proper multithreading in GNU Emacs is a problem.
deleted 11mo ago
[deleted]
jlarocco 11mo ago
Next up, how to make your Ferrari into a Fiero clone. Seriously, though, this seems kind of counterproductive. The power of Org mode and some of the other tools in Emacs comes from being integrated into the rest of Emacs and the synergies from Emacs idioms and concepts working everywhere in Emacs. Just my opinion, but the time spent learning this front end would be better spent just learning the Emacs UI. It's really not that difficult, and pretending you can't learn it just makes it more difficult in the long run.
- aaravchen 11mo ago
  It's more like how to put a modern day car dash over an F16 fighter jet. One has modern expectations and standards everyone is already familiar with but far less power and features, while the other existed before usability was even an idea but has more power and features than even most experts can handle. And in this case (and analogy), you can always slowly remove parts of the interface that hide the more powerful features. I say this as a 10 year Emacs user who left for VSCode and Zed because I decided I'd rather discover new modern features when they became useful (VSCode/Zed) rather than having to hunt them down when I became too fed up with the status quo and then have to spend weeks figuring out how to get them working (Emacs). That said, I keep itching to go back for some of the power features. If only it weren't a full time job just maintaining a basic emacs config.
  - jlarocco 11mo ago
    > It's more like how to put a modern day car dash over an F16 fighter jet. Yeah, that's probably a better analogy. > If only it weren't a full time job just maintaining a basic emacs config. I've heard that before, and I don't get it. I might spend 20 minutes a month updating my config, but it's really a set it and forget it thing for me. What are people doing that requires so much work?
    - aaravchen 11mo ago
      > What are people doing that requires so much work? 15 years ago I was in the same boat as you.I just had a set it and forget it config. But about 6 years ago I had to start adding addition languages support to my config, and started having to switch machines at work every year or so. Emacs package manager has always been abysmal at reusing an existing config on a different machine, and always required significant updates to the config for the latest versions of the packages (which frequently have/had breaking changes every coupe years). So it became a config update every year or so, that would take a couple days at minimum. Then the language support had to be addressed. With the couple days of updating every year or so, I start eying what other solutions are providing, especially since I was delving into new areas and toolsets. A few years ago simple dumb syntax and identifier fuzzy completion stopped being sufficient and table stakes became intelligent context-aware autocomomplete. Emacs setup for that was incredibly bad and has been extremely poor for years up until very recently. Only in the last year-ish has actual working LSP support finally been added and isn't bolted into a system that can barely cope. That means there was literally a gap of a few years where Emacs at best failed to meet the minimim to even be considered as a primary editor. Even still, the setup is very manual to get even the most basic integration. A similar rush of features is now pretty normal in editors, and Emacs is simply not keeping up. It's now a question of trade offs: how much do I want those crazy editing features of Emacs, and how many one-click support and integration features that are standard across almost all competitors am I willing to go without or spend hours every couple weeks setting up?
wiggles4cash 11mo ago
As someone who doesn't use emacs how do i install this? edit: i'm on windows
thdhhghgbhy 11mo ago
Does the fixed window layout really work with emacs though? In the past when trying this type of setup, I'd end up in the treemacs side panel showing a code buffer instead of the file viewer that is supposed to be there.
masfoobar 11mo ago
This is an interesting project and the picture can certainly fool you for a moment. I do wonder who the target audience is. Sure, this is a nice tryout if you are a VSCoder and want to try emacs. This essentially comes down to new users of emacs and trying to replicate it like another editor. Sounds you are skipping the basics of emacs training. Perhaps I am wrong, here? At the end of the day - it's just an .emacs file with the appropriate packages. I would recommend learning those packages individually, allowing you the freedom to express emacs that suits you. If there is something you still like with editors or IDEs like VSCode, you can adapt it. Emacs is a customisation program! I have been a C# developer for nearly 20 years (and an emacs user for about the same) I have been using emacs for practically all languages except for C# with Visual Studio (IDE). However, as the years passed.. have slowly moved over to emacs. By the time .NET Core was introduced (I think VSCode was around this time, also) I realised that I have most if not all tools I need to do some serious .NET work in Emacs. -- Today.. I pretty much use emacs with odd exceptions. My emacs is very simple. I have my lsp-mode (csharp-ls) as well as the usual magit, yasnippet, etc. With a nice dark theme, I have all I need to navigate about my project/solution. It's funny... when my co-workers see me with emacs they just assume I am "trying to be different" for the sake of it. However, when they watch me.. and without the use of a mouse.. they soon understand why I use it. I have also added additional functions to create solutions, projects, building, deployments.. all visible from a custom screen.
enbugger 11mo ago
Until Emacs resolves the performance issues on Windows, all those custom distributions are questionable for me.

301 points by nogajun 11mo ago

I was always bummed OniVim v2 didn't take off. It was a native IDE but fully supported VS Code plugin system. https://web.archive.org/web/20210627210456/https://v2.onivim.io/ https://web.archive.org/web/20210627210456/https://v2.onivim...

arbitrandomuser 11mo ago
onivim also seperated the core functionality of the vim editor into a seperate library libvim , this would have been great for other people looking to make their own gui frontend to vim . neovim does not give a libneovim, but exposes an rpc where you communicate with neovim running as another process, this I would have thought have more latency but apparently is fast enough , this is how the vscode plugin for neovim is able to provide a near complete vim experience. Other neovim guis like neovide use this too
koiueo 11mo ago
From a quick glance, I can't understand the target audience. Vim users would be annoyed by bizarre input lag of an electron application and perhaps by EULA. VS code users don't really care about Vim...
- forgotpwd16 11mo ago
  >of an electron application It isn't an Electron application*, that's why GP said native. The EULA part though was probably a block to adoption. *It uses Revery, a, made by OniVim's devs, cross-platform GUI framework (similar to Flutter but build on Reason/OCaml).
  - koiueo 11mo ago
    Oh, ok, now I'm curious to try it despite EULA (although these days the wide choice of (neo)vim distributions utilizing LSP makes their offering less appealing). Thanks for the clarification. The site doesn't stress the not-electron part enough, maybe that contributed to the failure.
    - forgotpwd16 11mo ago
      Should've probably mentioned it before but it actually used a dual-license model by having an MIT version that lagged behind upstream for 18 months (could be found in oni2-mit repo). During last month when development stopped it was fully re-licensed under MIT (hence oni2-mit repo no longer exists).
- iLemming 11mo ago
  > VS code users don't really care about Vim I disagree. vim-navigation is imperative for a huge number of devs. It's an amazing, practical, beautiful model. I would've never tried emacs if Evil-mode wasn't so fantastic. And that yet another reason for why vscode never is appealing to me - every one and each vim extension for it has tons of glaring deficiencies.
  - koiueo 11mo ago
    I'm not sure what you disagree with. I'm saying VS Code isn't targeting Vim users, and core VS Code user base doesn't care about Vim. I too can't take a seriously an editor which doesn't have Vim keybindigns at least in a very basic form.
    - iLemming 11mo ago
      Ah, I've misinterpreted it then. > I too can't take a seriously an editor which doesn't have Vim keybindigns at least in a very basic form. tbh, I can't take any experienced programmer seriously if they never even tried learning at least some basic vi-navigation commands. I'm like, "what? have they never used `sed`, `less`, `more` or never read man pages? have they never logged to a remote machine? why kind of a coder doesn't know any of this shit?" I mean I get it, it's not universally appealing to everyone, some prefer not to bother. But not knowing it at all? That's weird to me. And yes, I agree - If you're making an editor for coders (standalone, embedded, web or native), modal navigation must be possible.

trenchpilgrim 11mo ago

This would have been great when I was learning Lisp in school! I tried emacs but due to joint issues the keybinds were painful to use, so I gave up and did the course in vim+SBCL's REPL instead.

dmead 11mo ago
Which joint issues? Have you tried evil mode?
- trenchpilgrim 11mo ago
  > Which joint issues? Pretty sure it's rheumatoid arthritis. > Have you tried evil mode? This was like fifteen years ago and I just went back to my working Vim setup I was already using for all my other classes.
  - dmead 11mo ago
    Sorry to hear that. I have a family history of that as well. I think I'm starting to show signs of it. Vim forever I guess. Im typing on a full split with cherry reds (very soft). What are you on?
    - trenchpilgrim 11mo ago
      Started using an Ergodox EZ with a custom map after I shattered one of my wrists in a vehicle crash, have stuck with it since.
yvdriess 11mo ago
It is fairly common for emacs users to bind Ctrl or Meta to caps lock for improved ergonomics. There's also a bunch of RSI sufferers that are using foot pedals, which actually makes a lot of sense. I personally switched to emacs for more than just Lisp when I started developing early signs for RSI. Switching to a purely KB driven interface has saved my wrists.
- 11mo ago

pizlonator 11mo ago

That screenshot is super pretty. Very impressive!

contrapunctus 11mo ago
Thank you!

tom_ 11mo ago

C-x, C-c, C-w, C-s, C-k, C-g, C-] - goodness me, somebody absolutely does not give a shit what anybody thinks. I would never use this, but, somehow, I still love it. I dare the author to rebind M-x as well.

skullt 11mo ago
In fairness, Emacs has long had cua-mode for rebinding C-c, C-v, C-x, and C-z to copy, paste, cut, and undo, so at least those changes are not too radical.
az09mugen 11mo ago
Agree with you. Coming from sublime and always wanting to give emacs a fair try, I found ergoemacs [0] that wanted to expand the cua mode for beginners, but that was not enough for me. I wanted more, and now with IDEmacs it is almost like what I want. With emacs you can do pretty much anything, why not a full cua mode ? [0] : https://ergoemacs.github.io/ https://ergoemacs.github.io/
Iwan-Zotow 11mo ago
It was pc mode and then cua mode

charcircuit 11mo ago

I would really like to see this kind of work be done upstream. Emacs still looks the same as it did decades ago despite other editors advancing and becoming more user friendly.

raincole 11mo ago
I'm afraid that many people consider "looking the same as decades ago" a feature...
- compiler-devel 11mo ago
  It is, the default UI is stable and can be changed somewhat easily.
manithree 11mo ago
Please, no. Emacs could use some interface/toolkit update, I don't deny that. And I like IDE features. I use tree-sitter, LSPs, copilot.el, copilot-chat.el, and others all day, every day. But don't force me to turn off treemacs, and minimap like I have to do in VSCode all the time just because some useless, space-wasting eye-candy is trendy.
stackghost 11mo ago
A huge portion of the emacs community seems resistant to any UI improvement. I think it's a counterculture thing.
- komali2 11mo ago
  It's because a lot of us resist the implicit argument that UI changes are automatically improvement when in fact it's just as often regression.
  - brabel 11mo ago
    Yep. Look at IntelliJ. It just copied VsCode when it already had a great UI where things were easy to find and consistent. Now it’s got meaningless icons and hides important stuff by default, making it modern but far worse than before. Thank goodness emacs is not trying to chase the latest and stupidest.

giancarlostoro 11mo ago

I would love to see a project that rebuilds the Emacs UI but keeps the underlying core to give it a modern facelift, some things in emacs blend together and are a pain for my eyes to figure out whats what. It would be nice if the UI was modernized but the core was left as-is. I'm reminded of some of my favorite editors that are niche being Lisp related ones, where if you held down ctrl it would show you shortcuts in the UI itself and what they lead to. I also always enjoyed Racket's import arrows and other small things that are visually amazingly impressive despite being so simple.

pama 11mo ago
You mean something like which-key? It existed for a long time as an external package and was added to main emacs recently. https://github.com/emacs-mirror/emacs/commit/fa4203300fde6820a017bf1089652fb95759d68c https://github.com/emacs-mirror/emacs/commit/fa4203300fde682...
- tiu 11mo ago
  Alternatively beside which-key, hydras exist which are very nice for certain contexts (dired in the particular case for me) and provide a nice shortcut interface whenever activated. Demo at [0]. [0]: https://www.youtube.com/watch?v=_qZliI1BKzI https://www.youtube.com/watch?v=_qZliI1BKzI
- setopt 11mo ago
  As far as I know, which-key only helps with key sequences. If you press C-c in Org-mode it will show you keys like C-c C-e, but if you hold Ctrl down it won’t show you C-RET for example.
  - pama 11mo ago
    If you want all keybindings, C-h b typically helps, and you can search within the single buffer it returns. Every key in Emacs is bound to something, but a plain modifier key event like Ctrl will not be sent from a terminal to any command that runs inside it, eg Emacs, only the modified key. (There exist modifications/extensions of this protocol, eg kitty, but most combinations wouldnt see these events.)

jasperry 11mo ago

As a long-time Emacs user, I'm surprised by how easy it has become lately to configure Emacs as an IDE, mainly due to the built-in eglot. You need a lot less elisp code than you used to. A working Python setup is like one line of config. Which is to say, this project isn't really for me, because I'm already familiar with Emacs keybindings. And as for a new user, they're going to eventually have to deal with the underlying configuration. Maybe it's a gateway drug?

bionsystem 11mo ago
I used emacs at school some 15 years ago and I remember it being pretty seemless, I had an OCaml repl for one course and a 68000 emulator with memory inspection for another, and gdb integrated for C ; I do NOT remember hours of configuring that, maybe put some files at the right places and that was it. Switched to vim due to work (that was what's installed on remote machines), kept it for years because of the ubiquity. More recently in a new gig I'm finally able to install stuff on my machine (with homebrew) and not just work remotely, wanted to revisit my choice between (neo)vim and emacs again, but I guess muscle memory is too strong and still chose the former, although trying emacs I can tell that it is maybe even better polished now with the package manager and everything. Turns out neovim has the same with lazyvim, mason, etc. Just a bit more friction sometimes maybe. My main pain point right now is the lack of tooling for devops/sre in general. Yes we have LSPs for ansible, groovy, terraform... But they do not cover the entirety of plugins and modules that can be used, and I'm not aware of good tools for testing and debugging. Yes there is teamcity but that needs a license and I can't have that at work apparently. I don't think it is at the editor level though, just the ecosystem is lacking.

pca006132 11mo ago

What I miss from vscode is the remote functionality, can you do it with emacs? For neovim there is distant.nvim, but idk if it is mature enough and configuration seems a bit annoying...

hirvi74 11mo ago
There is TRAMP. https://www.gnu.org/software/tramp/ https://www.gnu.org/software/tramp/ I am not sure if it will fit your needs or not.
stackghost 11mo ago
I believe the analogous thing in emacs is called TRAMP. I have no idea if it's good, as I never edit files remotely, but it exists.
brendyn 11mo ago
Emacs already does that with TRAMP via SSH -- You just open a file like /ssh:user@server:/etc/hosts the main downside is if your connection is laggy Emacs will lock up momentarily. There is an ongoing effort to improve the multithreaded-ness and async-ness of Emacs to make it nicer
blubber 11mo ago
What kind of remote functionality? Lately, somebody mentioned https://code.visualstudio.com/docs/remote/tunnels https://code.visualstudio.com/docs/remote/tunnels
v9v 11mo ago
I use TRAMP to edit code loaded on robots occasionally. One advantage compared to VSCode is that it doesn't require the installation of anything onto the computer you're connecting to, since it uses the usual linux tools to work. But it can freeze up once in a while.
valcron1000 11mo ago
Not at the same level. TRAMP is way behind feature-wise.

bitwize 11mo ago

I don't see a point to this beyond hack value. Turning Emacs into a shitty version of an inferior editor is kind of a waste. If you really want Visual Studio Code, just use Visual Studio Code.

ruguo 11mo ago

If you don’t use it that often, you might wanna try the Emacs plugin for VS Code instead.

ishiguro_ 11mo ago
Do you have any recommendations?
- Myrmornis 11mo ago
  Yes the best one is https://marketplace.visualstudio.com/items?itemName=tuttieee.emacs-mcx https://marketplace.visualstudio.com/items?itemName=tuttieee...
trenchgun 11mo ago
What on earth are you talking about?
aaravchen 11mo ago
To be clear, this plugin is only a keymap, and just extends the built in Emacs-style keymap option of VSCode. If you did much/any mapping of any keys in Emacs, or are looking to expose more Emacs-like features, you're SOL. VWCode is simply unable to support most Emacs editing features without a significant engine expansion, and that's beyond the ability of plugins to add.

deleted 11mo ago

[deleted]

zozbot234 11mo ago

How does this configuration behave in a non-graphical terminal, e.g. as used with SSH? Can we have something that's at least on par with the UX from the old Borland text-based Turbo Vision IDE's (Turbo Pascal/Turbo C++), with a few modern convenience features?

yanhangyhy 11mo ago

i still use emacs everyday, with the native UI. but i love the idea of this project. Personaly i never get used to the UI of VSCode. seems so hard to understand because in emacs you deal with functions not UI buttons.

setopt 11mo ago
> Personaly i never get used to the UI of VSCode. seems so hard to understand because in emacs you deal with functions not UI buttons. I prefer both Vim and Emacs over VSCode, but I teach intro programming at a university and use VSCode in the lectures. VSCode is actually quite decent if you use it as a keyboard-driven thing with a distraction-free interface. By the former, I mean that Cmd-Shift-P does the same as Emacs’ M-x, and from the keybinding hints you quickly learn any recurring useful bindings (or can change them under Cmd-K Cmd-S when they feel bad). By the latter, I mean that nearly every UI element can be disabled (activity bar, tab bar, status bar, scroll bar, most buttons, indent guides, gutters, etc.) and if you spend 30min disabling the fluff it looks as minimal as Emacs. You don’t really need the UI elements if you learn Cmd-Shift-P and basic keybindings, which as an Emacs user you’ll pick up in a week. Not trying to sell VSCode here, as I said I don’t prefer it myself. I really tried to switch some times, but I don’t like the Microsoft monoculture nor the importance of proprietary plugins (like remote development and pylance), and an Electron app usually has some weirdness when it comes to font rendering, UI bugs, etc. compared to native or terminal apps. But if you have to use it, it’s actually not bad if you approach it in the same way you’d approach Emacs: Call functions with Cmd-Shift-P (can rebind to M-x if you want), and invoke more common functions via keybindings instead of UI elements.
- yanhangyhy 11mo ago
  well, that explains a lot. i guess its me not spending time to learn the basics of VSCode but got lost in the interface. seems a quite elegant design.
- iLemming 11mo ago
  > Cmd-Shift-P does the same as Emacs’ M-x Only superficially, but not even close in practice. In M-x you can run recursive commands; you have history; you can search through history back and forth; you can scroll the buffer, shrink and widen windows, browse files - all without leaving the M-x menu; you can yank current command or insert directly into the buffer; select multiple commands; act on them; inspect the source; enable tracing; - these are all built-in features. With some packages you can - export the commands list into a fully functional buffer from which you can still run the commands; you can cycle annotations - show description of the command or keys they bind to; you can display commands in a grid or temporarily flatten the menu for unobtrusive view. You can enable full vim-mode in it - in Emacs, M-x is a fully functional buffer, not some dummy input - I can call the LLM and ask it to find me a command while it's still active.

Surac 11mo ago

I like to express my loyalty to the emperor of man and call this heresy

noelwelsh 11mo ago

This won't take me away from Doom Emacs---I prefer the keyboard centric approach of Doom---but I'm really happy to see this. I feel that Emacs has some really innovative UI plugins (things like Vertico) but the out-of-the-box experience is pretty bad. If this makes Emacs more accessible to a different group of people I think it's great.

self_awareness 11mo ago

For me, VSCode implements everything that I've always expected from Emacs/Vim. I've spent years to configure emacs/vim to be a good programming editor. Years, multiple configurations, vanilla configs, space/doom emacs configs, multiple predefined configs for vim/neovim. Something always was broken, something was missing, something was non-optimal just below the tolerance line. Missing features, discontinued packages, initialization errors, bad versions, "known issues", LSPs not starting, packages replaced by some newer shinier package with different usage, cryptic setups that are wrapped in "convenience layers" that obscure details, making it completely incomprehensible. Then VSCode came and it had everything. Remote development is trivial through ssh. Completion simply works without any setups. Massive number of languages supported. It's a mess inside, but the UX is more stable and more consistent than anything I've ever seen in emacs/vim. Sometimes something breaks, but I can restart the window backend without closing the app easily. This is really telling. Despite dedicating years to configure an "infinitely configurable" system, I wasn't able to achieve anything stable. I've given up and i just use VSCode daily. This way, I have more than I ever had with emacs/vim. The only thing I have from vim that's left is the keyboard layout. For this, I'm thankful to Vim, but the editor itself for me is just for editing config files. I don't even have Emacs installed anymore.

roman_soldier 11mo ago
This, most people that try and use these legacy editors spend most of their time configuring it get it to be as good as vs code and usually fail. A lot of wasted time and frustration when one click gives you a perfectly modern fast editor with a smorgasbord of great extensions that just work. I do use vim for quick editing of files in the terminal but never for serious work.
- omnicognate 11mo ago
  Not sure where you get "most" from. Personally I've found the exact opposite: Despite having been forced by work constraints to use most major IDE platforms at one point or another, sometimes for years at a time, I always come back to emacs with great relief and find it better in pretty much every way. I know better than to assume my experience is that of "most" people, though.

imiric 11mo ago

This is great to see, and I'm sure it will nudge some people to give Emacs a try who wouldn't have otherwise. I've been using Emacs with a custom configuration for many years now, but when I needed a good IDE for working with modern frontend stacks about a year ago, I decided to give VSCodium a try, since the TS/LSP integration wasn't that great in Emacs. And funnily enough, I did the reverse of what this project does: I tried to make VSCodium look and behave more like my Emacs setup. It turns out that this is incredibly difficult. Decluttering the UI was easy enough; getting my Vim/evil-mode key bindings to work was relatively straightforward, though not perfect; but it was practically impossible to make VSCode work with the concept of buffers, instead of tabs and tab groups. There are some extensions that emulate this to an extent, but it requires at least one change[1] to work properly that's been ignored for almost 2 years now. So, that, general jank and unresponsiveness, and the idea of my editor being a web browser with all the security concerns of installing random JS extensions, put me off it for good. I went back to my "inferior" Emacs setup, spent some more time on configuring it for TS, and I think it's not so bad right now. Though I switched projects in the meantime, so it probably needs to be brought up to date again. Moral of the story: Emacs is life. I'm sorry I ever doubted it. <3 [1]: https://github.com/microsoft/vscode/issues/204942 https://github.com/microsoft/vscode/issues/204942

aaravchen 11mo ago
I did exactly the same, though I wasn't an Evil mode user. I quickly found VSCod(e|ium) lacks the internals to even do many of the basic useful things of Emacs. BTW, if you're an Evil mode user, Zed is probably your better choice. It has more focus on Vim-style keybindings.
- hollerith 11mo ago
  Similar story here. I used vscode for about 3 months for all my editing needs without even having Emacs installed, but returned to Emacs because of how hard it was to learn how to modify vscode (I'm not a web dev) compared to modifying Emacs and because of a vague impression that vscode is slower in responding to my inputs.

eamonnsullivan 11mo ago

I love these packages (like this, Spacemacs, Doom, etc.), even though I've used Emacs for over 30 years. I don't use them directly, but they give me ideas and alert me to packages I haven't heard of (eat?). And that gives me an excuse to go on another round of config-tweaking, which any Emacs user loves.

finnjohnsen2 11mo ago
Hear hear. I poked around at almost all the packages on the top of that idemacs page. «minimap» stood out, and is such a brilliant name for its purpose. I enjoyed that discovery and the smirk it gave me today.

pronik 11mo ago

Whoever thinks that VSCode does not have any learning curve or is somehow magically easy, needs to take a reality check, that thing is overwhelming with all its popups, hovers, sidebars etc. beyond all reason when you first run it (and later too). I'm an Emacs user and I don't in any way support the notion it's somehow easy or intuitively workable, it's most definitely not and never has been. I just think that VSCode is not it either, it's just the more popular tool right now.

torben-friis 11mo ago
Every piece of software that’s effectively a professional workbench (IDEs, DAWs, video editing, etc) is going to have some complexity. I can’t imagine the argument that vscode’s level of complexity is even in the same order of magnitude as vim or eMacs though. A 2 minute tutorial or half an hour or fiddling will get you sorted with vscode, I needed a full ebook for neovim.
- skydhash 11mo ago
  VSCode rely on familiar pattern and UX to let you get started easily. But out of the box, it's pretty much notepad level. Vim and Emacs start from the premises that you need powerful tools. And they give them to you alongside the possibility to integrate external tools easily with the editor workflow. With VSCode any integration needs to be a full project. With emacs and vims, it's a few lines of config.
  - torben-friis 11mo ago
    What kind of integration is a full project? Integrating language support for example is usually just heading to the plugins section, searching for the language and clicking install on the most mainstream result. My config for vscode is just like 5 lines to make keyboard travel between panes a bit more vim like, other than that I never needed to change much from defaults. For neovim the work to make it ide-like is a large list of plugins and its integrations, large enough that I’m comfortable outsourcing the consistency to a distro (lazyvim).

ClimatePaywall 11mo ago

[dead]

johnhamlin 11mo ago

Love to see this. I lost steam working my way through SICP a couple of years ago because I spent so much time trying to figure out Emacs instead of writing Scheme

kleiba 11mo ago

Long-time (25+ years) Emacs user. The first thing I do on a new installation is turn off the GUI features (like, menus and toolbars) - no-one I know who uses Emacs uses the mouse.

femiagbabiaka 11mo ago
VSCode users, especially new ones, do. The best property of Emacs is that you can modify the lisp machine to do whatever you want.
- pxc 11mo ago
  If you use an editor or IDE at work for a year, you might work with it for a thousand hours that first year alone. But a noisy GUI like VSCode's is optimized for just that first 30 minutes of playing around. For me, at least, that kind of thing doesn't end up being very enjoyable long-term.
- DonaldPShimoda 11mo ago
  > the lisp machine I wonder whether this was intentional or a coincidence, but for others (and maybe you) the "Lisp Machine" was a real hardware architecture unrelated to emacs: https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine
deleted 11mo ago
[deleted]
deleted 11mo ago
[deleted]
globular-toast 11mo ago
Another long time (15+ years) Emacs user here. I similarly use it completely keyboard driven. I have seen someone use it with the mouse, though. My PhD supervisor used completely stock Emacs to do LaTeX and actually used all the menus to do stuff. Quite eye opening for me.

musebox35 11mo ago

As a 15+ years emacs user the only item on my wishlist is client-server remote editing mode similar to that of vs code. Then I can go back to using emacs on cloud VMs. Does anyone know a solution to this that works as good as VS Code even when your latency is high? Hopefully, I will be pissed off with all the weird configuration flags of VS Code enough to write one myself ;-) To be fair its python integration is quite good at least for the usual stuff.

PessimalDecimal 11mo ago
Two approaches might work here: 1) Run Emacs on your local machine and use Tramp to edit the remote files 2) Run Emacs on the remote machine with the files you're editing. This likely means running in the terminal itself (emacs -nw or requivalently emacs -t).

jamesgill 11mo ago

Emacs for programming is definitely one important use case. This tool seems to focus on that use case, though I think I can get 75% of it by just using Emacs keybindings with regular VSCode. But Emacs is so much more than an ‘IDE’. I realize some don’t like the Emacs approach of ‘here’s a box of parts and tools, build it the way you want’, but that’s the point of Emacs. Besides the functional approach, of course, there is the philosophical stance: freedom. Emacs is an elegant weapon from a more civilized age. But some people prefer blasters, and that’s okay.

skulk 11mo ago
> Besides the functional approach Nitpick, but emacs and emacs lisp don't seem remotely "functional" to me insofar as expressing computation in terms of pure functions and immutable datatypes. The core datastructures that an elisp program interacts with (buffers, variables) are all mutable and functions (setq, buffer-string, etc) are decidedly impure.
- jamesgill 11mo ago
  I wasn't talking about programming.

cmrdporcupine 11mo ago

I've got a whole labouriously created setup for my emacs that is roughly equivalent to my RustRover setup in terms of capabilities (though not [mostly] in terms of keybindings because my fingers are fine with default emacs bindings). And I still barely use it, and I continue to fire up RustRover constantly. Because it just never feels snappy and fluid and responsive and stable. RustRover is a slow dog at times, but even it outperforms emacs for a lot of things. The lack of proper multithreading in GNU Emacs is a problem.

deleted 11mo ago

[deleted]

jlarocco 11mo ago

Next up, how to make your Ferrari into a Fiero clone. Seriously, though, this seems kind of counterproductive. The power of Org mode and some of the other tools in Emacs comes from being integrated into the rest of Emacs and the synergies from Emacs idioms and concepts working everywhere in Emacs. Just my opinion, but the time spent learning this front end would be better spent just learning the Emacs UI. It's really not that difficult, and pretending you can't learn it just makes it more difficult in the long run.

aaravchen 11mo ago
It's more like how to put a modern day car dash over an F16 fighter jet. One has modern expectations and standards everyone is already familiar with but far less power and features, while the other existed before usability was even an idea but has more power and features than even most experts can handle. And in this case (and analogy), you can always slowly remove parts of the interface that hide the more powerful features. I say this as a 10 year Emacs user who left for VSCode and Zed because I decided I'd rather discover new modern features when they became useful (VSCode/Zed) rather than having to hunt them down when I became too fed up with the status quo and then have to spend weeks figuring out how to get them working (Emacs). That said, I keep itching to go back for some of the power features. If only it weren't a full time job just maintaining a basic emacs config.
- jlarocco 11mo ago
  > It's more like how to put a modern day car dash over an F16 fighter jet. Yeah, that's probably a better analogy. > If only it weren't a full time job just maintaining a basic emacs config. I've heard that before, and I don't get it. I might spend 20 minutes a month updating my config, but it's really a set it and forget it thing for me. What are people doing that requires so much work?
  - aaravchen 11mo ago
    > What are people doing that requires so much work? 15 years ago I was in the same boat as you.I just had a set it and forget it config. But about 6 years ago I had to start adding addition languages support to my config, and started having to switch machines at work every year or so. Emacs package manager has always been abysmal at reusing an existing config on a different machine, and always required significant updates to the config for the latest versions of the packages (which frequently have/had breaking changes every coupe years). So it became a config update every year or so, that would take a couple days at minimum. Then the language support had to be addressed. With the couple days of updating every year or so, I start eying what other solutions are providing, especially since I was delving into new areas and toolsets. A few years ago simple dumb syntax and identifier fuzzy completion stopped being sufficient and table stakes became intelligent context-aware autocomomplete. Emacs setup for that was incredibly bad and has been extremely poor for years up until very recently. Only in the last year-ish has actual working LSP support finally been added and isn't bolted into a system that can barely cope. That means there was literally a gap of a few years where Emacs at best failed to meet the minimim to even be considered as a primary editor. Even still, the setup is very manual to get even the most basic integration. A similar rush of features is now pretty normal in editors, and Emacs is simply not keeping up. It's now a question of trade offs: how much do I want those crazy editing features of Emacs, and how many one-click support and integration features that are standard across almost all competitors am I willing to go without or spend hours every couple weeks setting up?

wiggles4cash 11mo ago

As someone who doesn't use emacs how do i install this? edit: i'm on windows

thdhhghgbhy 11mo ago

Does the fixed window layout really work with emacs though? In the past when trying this type of setup, I'd end up in the treemacs side panel showing a code buffer instead of the file viewer that is supposed to be there.

masfoobar 11mo ago

This is an interesting project and the picture can certainly fool you for a moment. I do wonder who the target audience is. Sure, this is a nice tryout if you are a VSCoder and want to try emacs. This essentially comes down to new users of emacs and trying to replicate it like another editor. Sounds you are skipping the basics of emacs training. Perhaps I am wrong, here? At the end of the day - it's just an .emacs file with the appropriate packages. I would recommend learning those packages individually, allowing you the freedom to express emacs that suits you. If there is something you still like with editors or IDEs like VSCode, you can adapt it. Emacs is a customisation program! I have been a C# developer for nearly 20 years (and an emacs user for about the same) I have been using emacs for practically all languages except for C# with Visual Studio (IDE). However, as the years passed.. have slowly moved over to emacs. By the time .NET Core was introduced (I think VSCode was around this time, also) I realised that I have most if not all tools I need to do some serious .NET work in Emacs. -- Today.. I pretty much use emacs with odd exceptions. My emacs is very simple. I have my lsp-mode (csharp-ls) as well as the usual magit, yasnippet, etc. With a nice dark theme, I have all I need to navigate about my project/solution. It's funny... when my co-workers see me with emacs they just assume I am "trying to be different" for the sake of it. However, when they watch me.. and without the use of a mouse.. they soon understand why I use it. I have also added additional functions to create solutions, projects, building, deployments.. all visible from a custom screen.

enbugger 11mo ago

Until Emacs resolves the performance issues on Windows, all those custom distributions are questionable for me.