[HN Gopher] IDEmacs: A Visual Studio Code clone for Emacs
___________________________________________________________________
IDEmacs: A Visual Studio Code clone for Emacs
Author : nogajun
Score : 289 points
Date : 2025-11-16 00:56 UTC (22 hours ago)
(HTM) web link (codeberg.org)
(TXT) w3m dump (codeberg.org)
| tiffanyh wrote:
| 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...
| arbitrandomuser wrote:
| 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 wrote:
| 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 wrote:
| >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 wrote:
| 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 wrote:
| 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).
| trenchpilgrim wrote:
| 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 wrote:
| Which joint issues? Have you tried evil mode?
| trenchpilgrim wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| contrapunctus wrote:
| I use kmonad to make Space act as Control when held, and it's
| absolutely life-changing - not just in Emacs, but in all
| applications.
|
| This is my configuration -
|
| https://codeberg.org/contrapunctus/dotfiles/src/branch/produ.
| ..
|
| And here's my blog post about it -
|
| https://contrapunctus.codeberg.page/blog/keyboard-
| machinatio...
| qiine wrote:
| wait foot pedals ?
| newcup wrote:
| Or an accordion!
| https://x.com/ykarikos/status/1038145486618861573
| pizlonator wrote:
| That screenshot is super pretty. Very impressive!
| contrapunctus wrote:
| Thank you!
| tom_ wrote:
| 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 wrote:
| 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 wrote:
| 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/
| charcircuit wrote:
| 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 wrote:
| I'm afraid that many people consider "looking the same as
| decades ago" a feature...
| compiler-devel wrote:
| It is, the default UI is stable and can be changed somewhat
| easily.
| manithree wrote:
| 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 wrote:
| A huge portion of the emacs community seems resistant to any UI
| improvement. I think it's a counterculture thing.
| komali2 wrote:
| 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 wrote:
| 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.
| anon291 wrote:
| There is no better UI for text editing that I have ever come
| across. I'm not sure why so many people are resistant to the
| idea that emacs has the correct answer to most UI issues.
| More programs would stand to take lessons from emacs. Emacs
| is, in its own right, a very successful piece of software.
| When eclipse was a thing everyone was saying how great it was
| vs emacs. But eclipse is gone (I think?) and emacs is still
| GOATed.
|
| There's a particular kind of hubris from non emacs users
| (especially those who swear by new ides), that us losers are
| somehow deprived. We are not and don't need your advice.
| Nothing to do with counterculture. I tried many editors
| before I became obsessed with emacs.
| charcircuit wrote:
| >But eclipse is gone (I think?) and emacs is still GOATed.
|
| The 2024 stack overflow developer survey [0] puts Eclipse
| at over double Emac's market share. If Eclipse is gone,
| then Emacs is double gone. Emacs struggles to attract and
| retain new users. This advice is not calling existing Emacs
| users deprived. It's rooted from the bad defaults giving
| new users a bad impression of Emac's viability because the
| default is so bad. If emacs built out proper telemtry they
| could actually track how the defaults they provide affect
| the new user experience in order for them to optimize it
| and figure out what users are looking for.
|
| [0] https://survey.stackoverflow.co/2024/technology
| anon291 wrote:
| > If emacs built out proper telemtry they could actually
| track how the defaults they provide affect the new user
| experience in order for them to optimize it and figure
| out what users are looking for.
|
| I can't tell if this is an attempt at humor or something
| people actually believe
| jibal wrote:
| Nonsense. Many emacs users spend their whole lives inside of
| it so they're quite sensitive to what is actually an
| improvement and what is not. The arrival of the various
| modern completion packages -- vertico, orderless, consult,
| etc. have been welcomed ... but note that these are all add-
| on packages. Likewise, all of the "improvements" provided by
| the OP are a matter of loading and configuring packages.
|
| People who aren't regular emacs users tend not to understand
| it and are not reliable reporters about the editor or its
| community.
| natrys wrote:
| It can hardly be called resistance to improvement, when
| everyone do improve it - just in their own ways. The default
| isn't some fashion statement, some aesthete that's
| objectively good (though I am sure some people do
| subjectively like it). But it's meant to be sort of a least
| presumptuous blank state that everyone can radically
| overhaul. So arguably it's an encouragement for improvement
| just like everything else in Emacs, which focuses on making
| the tools for improvement easier.
|
| It's just that "improvement" as a matter of public consensus
| that everyone can agree on to elect the next blank slate has
| been to impossible to settle on. But the counterculture here
| broadly might be extreme reluctance to inconvenience even a
| minority of existing users, in pursuit of market
| share/growth.
| allarm wrote:
| It's not counterculture. It's understanding of what's
| important. Functionality, discoverability and extendability
| over opinionated UI/UX that nobody asked for.
| roman_soldier wrote:
| Well people will vote with their mouse clicks, and they
| have, < 1% of devs use Emacs vs VS Code which is probably
| 20-30x.
| allarm wrote:
| I mean, okay? That's their choice. Not everything is a
| competition.
| ssivark wrote:
| Switching the default experience away from what people have
| grown used to over decades seems incredibly rude (despite what
| commercial software has normalized).
|
| The magic of emacs is infinite customizability. And it's quite
| easy for users to find and start with emacs "distributions" or
| "starter packs". So that's probably the best route forward.
|
| Potential improvements:
|
| 1 Base emacs continues to make it easier to try out a bunch of
| configurations and switch between them, obviating solutions
| like chemacs
|
| 2 There's a web repository of a a variety of starter packs with
| screenshots and reviews and installation instructions, to help
| beginners find everything in one place.
|
| 3 ...
| ares623 wrote:
| Could be done with a flag tbh. One version to opt in. Next
| version it's opt out.
| fergie wrote:
| Emacs is probably the most user-friendly editor. Its just not
| very beginner-friendly.
| self_awareness wrote:
| The problem is that you need to spend 20 years to get out of
| the "beginner" zone.
| hbogert wrote:
| The curse as a power user is that you want to know how it
| works. I let that feeling go with emacs. I've been happily
| using it since. My first gateway and killer use case was
| magit. Life with git will never be the same.
| fergie wrote:
| I'm 25 years in and still firmly in the beginner zone
| allarm wrote:
| > Emacs still looks the same as it did decades ago
|
| That's a good thing. I don't want to change my habits every
| time a designer of whatever product I use decides that he
| deserves a raise and breaks my workflow in some subtle way.
| imiric wrote:
| I didn't downvote you, but you have a misconception.
|
| There's no such thing as an Emacs "look". Its appearance, UI
| and UX, are wildly different depending on how the user wants it
| to look and behave. Considering that it is a very configurable
| system that happens to expose building blocks for a text
| editor, every Emacs installation is thus different from
| another.
|
| We could say that the Emacs GUI toolkit and perhaps its
| internals are dated by modern standards, but even those would
| be personal preferences. Being single-threaded is arguably
| holding it back in some aspects, though that isn't a major
| limitation for most use cases.
| charcircuit wrote:
| My comment is discussing the defaults. Most users will use
| the defaults and not customize their editor, especially if
| they are just using it for the first time. The defaults are
| important.
|
| The single threaded issue is a problem, but one that can be
| somewhat worked around. I consider emac's bad deals an
| existential issue that significantly hurts adoption.
| imiric wrote:
| > Most users will use the defaults and not customize their
| editor
|
| But those are not the users who choose Emacs in the first
| place. Emacs is _made_ for customization.
|
| Besides, there are many preconfigured distributions of it,
| such as the one discussed here, which can effectively be
| used as the defaults, if you don't like the ones shipped
| OOB.
|
| > I consider emac's bad deals an existential issue that
| significantly hurts adoption.
|
| Well, I reckon you're wrong. Emacs in all of its
| incarnations has been in use for nearly half a century, and
| its adoption has never been greater. Some people will point
| to low percentages in developer surveys, but that is the
| wrong metric to focus on. Its usage will never reach
| mainstream numbers, which is probably for the best, but it
| will continue to be enjoyed by enthusiastic users for a
| long time to come.
| giancarlostoro wrote:
| 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 wrote:
| 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/fa4203300fde682...
| tiu wrote:
| 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
| setopt wrote:
| 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 wrote:
| 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.)
| setopt wrote:
| Sure, I know about C-h b and C-h m and find those useful.
| But I think what the GP post describes is more
| contextual: A way to not display every keybinding, but
| only those directly accessible by pressing the currently
| held modifier combo followed by one key (so holding
| Ctrl+Meta for more than a couple of seconds might remind
| you of all structural editing commands for example).
|
| This is indeed not possible in a classical terminal
| emulator (don't know if kkp for example has extensions
| for it). But most GUI apps can detect individual
| modifiers being pressed and released, even as separate
| events. Some editors like VSCode can also bind modifier
| taps to actions using this ability. In Emacs however this
| is AFAIK not possible even in the GUI, because of how
| keybindings are handled deep down.
|
| The UI pattern described by the GP does exist in some
| other apps and platforms. For example, if you connect an
| external keyboard to an iPad, holding down the Cmd
| modifier for a couple of seconds will show you a popup
| which-key-like overview of all Cmd+key keybindings.
| skydhash wrote:
| A good shortcut is "C-h m" which shows the help for the
| major mode (and current active minor modes). It will also
| shows all the bindings that those modes define.
| koiueo wrote:
| I'd argue the opposite. UI is ok, it can be configured to look
| timeless (not modern).
|
| But the core with its single thread processing and constant
| hangs, requiring you to repeatedly hit C-g at least once a day,
| is first in line for "facelift".
| setopt wrote:
| > requiring you to repeatedly hit C-g at least once a day
|
| And bind `pkill -SIGUSR2 emacs` or similar to a OS-level
| keybinding...
| yvdriess wrote:
| Agree, those hangs are especially bad when programming with
| eglot or project management over a slow Tramp (remote)
| connection. An auto save hijacking your time for two seconds
| at random is flow breakingly frustrating. It's something that
| could perfectly well run in the background.
| Myrmornis wrote:
| You can make it look modern: get rid of all menus and bars so
| that there is nothing on screen except for the text you're
| editing. (e.g. search for minimal.el) It looks
| indistinguishable from any other modern editor / IDE in zen
| mode. Menus and bars are not necessary in these sorts of
| applications if you use then daily -- more efficient and
| powerful to use the command palette and key bindings.
| koiueo wrote:
| > nothing on screen except for the text you're editing
|
| Just wanted to clarify, to me that's timeless. Modern would
| be having modern menus, pop-up configuration screen et al..
| All the candy that appeals to a less experienced user, who
| worked with Idea, Sublime of VS code before.
| Myrmornis wrote:
| I guess I'm not really sure that menus are modern. But
| anyway I hate the stubbornness over the vanilla emacs UI.
| The nonsense in the menus and the stupid pixelated
| pictures of scissors or whatever.
|
| But I've never really got the idea of why emacs should
| appeal to less experienced users. I think that's
| misguided: the entire point of Emacs is that you write
| some emacs lisp. If you're not interested in writing any
| lisp, then you definitely shouldn't bother with emacs (I
| used emacs intensively for 20 years and am the author of
| Emacs packages). And if you're less experienced and
| looking for Idea/Sublime experience then at this point in
| your life there's a good chance you aren't interested in
| writing lisp.
| skydhash wrote:
| There's a reason there's no beginner car, no beginner
| guitar, and no beginner drill. Those are either tools or
| toys. If all you want is to type some text, notepad (or
| the equivalent in other OS) is enough. But programmers do
| more with text. So they should know what tools provide
| those and how to use those tools. But then you'll find a
| lot of programmers barely go one level up from notepad
| with their tools.
| ffaser5gxlsll wrote:
| Second this. The "ui" is perhaps useful when learning to
| use emacs, but every emacs user I've seen after a while has
| all of it disabled.
|
| I've been using emacs with the "lucid" build since forever,
| as it's the leanest build that still gets a graphical
| window working on X11 and see none of the actual "toolkit".
|
| I guess the pgtk build is required nowdays for native
| wayland support.
| volemo wrote:
| So we all agree we need Emacs 2.0(tm), rewriting both the UI
| and the guts? /j
| znpy wrote:
| I would actually change as little as possible.
|
| The current UI has it quirks, but has the great advantage that
| it looks the same irrespective of whether you're in an
| graphical environment (Xorg/Wayland/Windows/MacOS) on in a
| terminal (either local or remote via ssh).
|
| I *love* that treemacs looks pretty much the same everywhere.
| setopt wrote:
| It doesn't really look the same by default.
|
| Most new users end up disabling the toolbar, menu bar, scroll
| bars, etc. and only then does it look the same in the
| terminal. Even then, many themes and packages frivolously
| change font sizes or switch to non-monospace fonts in some
| GUI contexts, so for users that like the uniformity of the
| interface you need to do extra work to disable these
| features.
|
| (I personally like the terminal aesthetic, and configure the
| GUI to look like a terminal. That basically required advising
| load-theme to loop over all faces and disable font properties
| I don't like after each theme change...)
| chiffaa wrote:
| It's not exactly what you're looking for but you might be
| interested in Lem[0]. It's an emacs-style editor but written
| completely in Common Lisp on top of curses/SDL2. I haven't used
| it that much (same for Emacs itself, really), but it looks like
| a very solid foundation
|
| [0]: https://github.com/lem-project/lem
| giancarlostoro wrote:
| Does look interesting, in the meantime I've been hooked on
| Zed which has users building support for missing Vim
| features, they claim their goal isn't to 100% emulate Vim
| functionality, but I would not be shocked if it just winds up
| having most if not everything most people like about Vim
| fully baked in.
| jasperry wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| There is TRAMP.
|
| https://www.gnu.org/software/tramp/
|
| I am not sure if it will fit your needs or not.
| stackghost wrote:
| 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 wrote:
| 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 wrote:
| What kind of remote functionality? Lately, somebody mentioned
| https://code.visualstudio.com/docs/remote/tunnels
| v9v wrote:
| 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 wrote:
| Not at the same level. TRAMP is way behind feature-wise.
| skydhash wrote:
| You mean like the way VSCode does by installing a whole mini
| version of itself on the remote computer?
| bergheim wrote:
| Well, I guess? Using TRAMP with large projects is not a
| pleasant experience. It works great for one-off files and
| remote bookmarks etc, but for working with large projects
| you're better off mosh/ssh-ing into the server and using
| Emacs there. With things like term-keys [1] you can use all
| the keys there as well. Basically only missing out on
| images and variable fonts, both of which are none issues
| for me at least when programming.
|
| 1: https://github.com/CyberShadow/term-keys
| bitwize wrote:
| 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 wrote:
| If you don't use it that often, you might wanna try the Emacs
| plugin for VS Code instead.
| ishiguro_ wrote:
| Do you have any recommendations?
| Myrmornis wrote:
| Yes the best one is https://marketplace.visualstudio.com/item
| s?itemName=tuttieee...
| trenchgun wrote:
| What on earth are you talking about?
| zozbot234 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| Surac wrote:
| I like to express my loyalty to the emperor of man and call this
| heresy
| noelwelsh wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| roman_soldier wrote:
| The data shows VS Code is used by double digit % of
| developers, whereas Emacs is less than 1%, I think that
| qualifies for most.
| iLemming wrote:
| > one click gives you a perfectly modern fast editor with a
| smorgasbord of great extensions that just work
|
| I use over 300 hundred packages in my Emacs setup. I honestly
| not sure if I can install even half of that number of VSCode
| extensions and expect it to still run smoothly, maybe people
| do that, I just don't know.
|
| They are called "packages" and not "extensions" for a reason
| - an extension that e.g., ships with a browser has
| limitations. In Emacs I can reuse functions of one package in
| another - in VSCode they have to be explicitly exposed via
| public API, must be activated in order, they need to be aware
| of their extension IDs, there's no discovery mechanism - in
| Elisp, I don't have to deal with any of that.
|
| in Emacs I can explore, modify and bend the source code of
| _any_ package - built-in or third-party. I can do it in a way
| that is simply impossible anywhere else. I can granularly
| change selected behavior of any command without having to
| rewrite it fully.
|
| That "just works(tm)" part I don't ever buy it - all software
| is faulty by nature. In Emacs, when something fails - I know
| exactly how to troubleshoot it, to the specific line in the
| specific package code; I can profile; debug and trace it. I
| can modify code in question in a scratch buffer and
| immediately check how it affects things. Not only I don't
| have to restart anything, I don't even have to save that code
| anywhere.
|
| You call it "a legacy editor" without the slightest clue of
| what Emacs hackers are capable of doing - for what the most
| "modern" alternatives simply have no answers.
|
| I agree, Emacs is not for the faint-hearted - many people
| (maybe most) lack the patience required to grok it. Yet make
| no mistake, those who have tamed this beast are not staying
| in it simply because "they don't know any better". They know
| - something better is yet to be made, if ever. VSCode is
| great, yet still not better.
|
| Learning Emacs has liberated me from experiencing tool-FOMO
| ever again - I can switch to VSCode without abandoning Emacs,
| and I can even probably figure a way to control one from
| another if I get annoyed enough; I just never found a
| pragmatic reason to use VSCode more. So really, I have zero
| envy or crave to even become a full-time VSCode user; if
| anything, I might be forced into it by circumstances, and
| that's just fine.
| iLemming wrote:
| > For me, VSCode implements everything that I've always
| expected from Emacs/Vim.
|
| Good. For me, VSCode unlikely will ever become anything that I
| expect from my _text_ editor.
|
| For coding, sure, Emacs may not be great for any specific
| language except some Lisps, but for plain text manipulation,
| OMG, Emacs still is the king.
|
| I just can't see it ever replacing it for note-taking - just
| yesterday I was showing someone "reproducible research"
| workflow example in Org-mode where I had a source block that
| sends http requests, then passes that into a bash block where
| the results get converted to EDN, then connected it to a
| Clojure REPL, explored and visualized data in it. Name one
| system that allows you to seamlessly pipe results of one
| computational block into another, mixing different languages.
|
| Today I made a table with some formulas to calculate some
| numbers. Does your note-taking app has spreadsheets-capable
| tables and embedded math formulas?
|
| Two weeks ago I was dealing with a slew of logs coming from k8s
| pod, and I want it to explore it in my editor - I piped from
| terminal directly into an Emacs buffer. I can similarly pipe
| the content of any given buffer into a different unix command.
|
| I control video playback directly from Emacs - it's very nice
| when I'm taking notes. My pdf documents blend-in into my color
| theme, which btw. changes based on time of day automatically -
| Emacs has a built-in solar and lunar calendars.
|
| I search through my browser history and through open tabs
| directly from Emacs - it's great for finding and grabbing
| specific piece of text from the browser - so I can put it into
| my notes.
|
| I rarely need to open Jira in my browser, Emacs understands
| that "XYZ-12345" is a ticket and shows the ticket description
| in a tooltip, I can browse its content in-place, same is for
| RFCs. My Emacs understands that a url is a PR and allows me to
| review it in-place. It knows when it's looking at a GitHub repo
| url and allows me to clone it with a keypress, or explore
| CircleCI logs.
|
| I never type anything longer than three words in any app. I've
| built a workflow that allows me to quickly move the text into
| my editor and back into the app. Why would I do it differently?
| I have all the tools I need - thesaurus, spellchecker,
| translation, etymology lookup, LLMs, etc.
|
| Finally, once I got the plain text under control, I realized
| that code is nothing but structured text. I have things like
| fetching the path to exact line on GitHub, while supplementing
| the fully-qualified name of the function - my colleagues don't
| have to guess what they're staring at, they can simply see it
| without ever opening the link.
| imiric wrote:
| 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
| eamonnsullivan wrote:
| 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 wrote:
| 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 wrote:
| 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.
| kace91 wrote:
| 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 wrote:
| 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.
| kace91 wrote:
| 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).
| t_mahmood wrote:
| Yeah, now see, you need to do that for every programming
| language, or tool for vscode.
|
| With Lazyvim you get all at once. And you can ignore many
| plugins if you want,
|
| Sure it's not ide level, but with proper configuration
| vim/Nvim is much more powerful than vscode. And thanks to
| Lazyvim, you can set it up faster
|
| but Nvim or vim even without plugins can do many things
| that vscode can not do. So without plugins vscode is just
| an editor, while Nvim/vim are powerful utilities
| skydhash wrote:
| There's a reason almost every good editor (on unix) have
| the pipe to/from shell feature. With that you have the
| whole power of the os at your disposal. And in vim, you
| get the quickfix list for fast navigation according to
| the output of a grep/build tool.
|
| Someone could make a config to make vim/emacs beginner
| friendly. But there's a reason there's no beginner
| friendly truck or plane.
| kace91 wrote:
| >Sure it's not ide level, but with proper configuration
| vim/Nvim is much more powerful than vscode.
|
| I'm not arguing against that, I actually moved to neovim
| and I enjoy it - plus I can now stop worrying that my
| daily driver will be rug pulled.
|
| I just don't agree with the idea that neither nvim or
| eMacs have similar levels of ability to onboard new
| users. Not when grokking something as simple as closing a
| tab will get you through a history lesson on the
| alternate namings of tabs, buffers and windows for
| example.
| skydhash wrote:
| No one is arguing that. Just that VSCode is also complex
| too. But it's just that out of the box, there's nothing
| special. Then you add a few tools through plugins and
| that's the extent of of workflow customization most
| people stay at. If you want more, you have to start a
| whole new project, and the complexity of that is high
| while the return is not as good as you can have with
| emacs/vim.
|
| With emacs/vim, getting started is fairly easy (there's a
| tutorial). The learning phase is linear, but it's just
| practice and using the software. Creating your own tool
| is very easy as you can jumpstart from where other's
| plugins are and add your own stuff. In VSCode, it's
| starting from scatch everytime.
| skydhash wrote:
| With emacs, you can just use "customize" (for options)
| and "M-x" (for commands) and never care about anything
| else. Yes, it's not as visible as vscode, but it's very
| much the same thing.
|
| But once you learn elisp, then you have the power of a
| full VM at your disposal and not wait for a plugins to
| exist and hopefully implement your workflow. And adhoc
| integration (like having ticket number in comments be
| clickable) is not easily feasible.
| slaymaker1907 wrote:
| You absolutely don't need extensions for JS development. It
| is absolutely NOT notepad level. In my experience with
| beginners, installing an extension is also incredibly easy
| compared to getting them to edit some vim/emacs config.
| iLemming wrote:
| > incredibly easy compared to getting them to edit some
| vim/emacs config
|
| Yet, extending just about _any_ functionality of Emacs
| for an experienced user is _far_ simpler than in anything
| else - you can write some expressions in a scratch buffer
| and change the behavior of any command - built-in or
| third-party. Not only wouldn 't you even have to restart
| anything - you wouldn't even need to save that code on
| the file system.
|
| There's a strong correlation between perceived difficulty
| at the beginning and notable simplicity at later stages.
| Things that are seemingly harder to grok often open up
| avenues for clarity later. Conversely, things that seem
| easy to get into, later often become full of bottlenecks
| and complexity.
|
| Imagine attempting to replace all the knobs, controls,
| buttons and switches in an Airbus A380 cockpit with a
| single touch-based display a la Tesla and claim it's now
| easier to train new pilots, but you've just made them
| dependent on a system they don't deeply understand,
| you've traded 6 months of training for a lifetime of
| brittle expertise.
|
| I am forever indebted to my younger self for investing
| some time in understanding the grand ideas behind Vim and
| Emacs, and never, even once, have I regretted my choices.
| Rather the opposite - I regret wasting a big chunk of my
| life chasing popular trends aimed at "intuitive use",
| "easy start" and "it just works(tm)". I would have never
| developed the true "hacker's mindset" without them.
|
| Undeniably, there's an immense pedagogical value in tools
| that make it easy for beginners, but there's also a
| mental trap there. It's ingrained into human nature - the
| brain simply doesn't like the grit; it naturally
| gravitates toward comfort and minimal effort - it just
| wants to remain lazy. Yet there's a compounding effect of
| initial investment that pays off later. Sadly, we keep
| trying to find ways to dumb things down.
| skydhash wrote:
| VSCode is familiar in its UX. Here is the file tree, here is
| the editor. oh that's the terminal, or I can complete with tab,
| and these are extensions that I can install? And that's pretty
| much the extent of the interaction most people have with it. If
| it does not come out of the box or prepackaged into an easily
| extensible extension, they are not using it.
| totetsu wrote:
| I get so frustrated watching people fuss around in VSCode
| because they're stuck in it and they've never had the
| opportunity to see all the intuitive and more workable tools
| that a.. just part of the basic OS they are using. .. like
| keeping their console a tab taking up 1/4 the screen and trying
| to read a stack-trace ..
| frumplestlatz wrote:
| I've been using emacs for very many years, and have a
| configuration that has evolved over a decade.
|
| I was able to pick up VSCode in an hour. It's not complicated.
| I'm using it with the Haskell extension and it's great.
|
| Honestly, I'm tired of Emacs' performance, bugs, complexity,
| and poor UI that requires an enormous amount of hacking to make
| a usable IDE.
|
| VSCode is a breath of fresh air. The only things I'm not using
| it for are languages that don't have extensions yet -- Cryptol
| and SAW.
| iLemming wrote:
| > requires an enormous amount of hacking to make a usable
| IDE.
|
| When you're using it for one, specific purpose, like an IDE
| for specific language(s), then yes, sure, it may feel like
| that.
|
| Yet Emacs is so much more. It's not an IDE (but it could be);
| it's not [the best] source control tool; it's not [greatest]
| note taking app; it's not an [amazing] mail client; it's not
| [most beautiful] pdf reader; nor a [feature rich] terminal
| app; etc. Emacs is not even an editor, to be brutally honest.
| It's not the greatest concrete implementation of any of these
| things.
|
| What Emacs actually is - it's a concrete implementation of an
| abstract idea - a Lisp REPL with a baked-in text editor into
| it. That, for a second, is an absolutely fascinating
| commodity. Once you grok the essence of that idea, it's
| really difficult not to see the extreme value of it.
|
| I'm sorry, I just have hard time to believe anyone who says:
| "used it for many years... yet abandoned it anyway".
|
| It typically means that they've been using it from a narrow,
| small focused point of view, without ever exploring the
| possibilities that "true" Lisp REPL can grant them. I just
| don't see myself ever escaping Emacs, because there's simply
| no practical, comparable alternatives to it. Comparing VSCode
| to Emacs is like comparing it to Thunderbird - you didn't
| like how Emacs handled your emails and now using something
| else? Congrats, and that's just fine, only it's not fair and
| proper comparison by any means.
| cholantesh wrote:
| >that thing is overwhelming with all its popups, hovers,
| sidebars etc.
|
| I think it's fairly normal if you're coming from heavy IDE use,
| eg: Eclipse. If you've spent most of your time editing using
| tmux/[vi|nano|emacs]], maybe that's not the case, but I can't
| really speak to that as I've never really worked that way.
| pxc wrote:
| I'm also a daily Emacs user. I'm no wizard; I've leaned on
| starter kits like Spacemacs and Doom my whole Emacs life.
|
| Likewise, I find VSCode overstimulating and, for lack of a
| better word, _rude_.
|
| I just tried setting up RustRover for a side project at work on
| Friday. It's my first time using an IDE since I was a Scala
| developer near the beginning of my professional career. I only
| had an hour or two to play, but I ended up unable to get a
| working run configuration, or at least one that showed me
| anything at all except sometimes when it failed. It was a lot
| of clicking around.
|
| I'll sort it out next week, I'm sure. But pointy-clicky turned
| out not to be as ez-pz as I'd hoped it would be.
| t_mahmood wrote:
| IntelliJ shines when you use the command pallet, keyboard
| shortcuts, and IdeaVIM
|
| Double shift, to bring up the pallet, and start typing.
| Though it also have a ton of shortcuts, and shortcuts can be
| assigned for almost every command.
|
| Try this: https://plugins.jetbrains.com/plugin/9792-key-
| promoter-x/
|
| Whenever you don't use keyboard shortcut for any action, this
| suggests you the available keyboard shortcut.
| iLemming wrote:
| IntelliJ is an amazing feat of software engineering,
| there's no denying that. I'm not saying that to make you
| (or any other WebStorm/Pycharm/etc. user) feel better - I
| know that from years of dedicated use.
|
| I just want to share my anecdotal, personal story. I used
| IntelliJ professionally for almost a decade. I learned some
| advanced and undocumented features. I've collaborated with
| Jetbrains team members to help improving the features. It
| felt like I work for them. I still occasionally receive
| YouTrack notification emails for the bugs I posted circa
| 2009, that are still not fixed today, btw.
|
| IntelliJ is to blame for why my transition to Emacs took me
| two years - I carried the fear of investing too much into a
| new thing. I feared of liking it, and someday not finding
| some features I was so attached to in IntelliJ. I was
| scared that I will be intellectually and emotionally
| "locked in", while I was already vendor locked-in and
| condemned to be using IntelliJ forever.
|
| I was so wrong - not only have I found everything I needed,
| and more, I have developed a true hacker's mindset.
| Honestly, the only regret I still carry today, even after
| years of Emacs use, is that I did not attempt to learn it
| sooner. I no longer experience FOMO - I can easily pick up
| IntelliJ whenever I want again, I just haven't found a
| real, pragmatic reason to do so. In fact, I do fire it up
| on occasion, just to get the feel of how things evolving
| there, to steal some good ideas, etc.
|
| > and IdeaVIM
|
| Gary Bernhardt famously said - "There's no such thing as
| vim-mode". And to the degree, he was right - pretty much
| every editor/IDE that tries to integrate Vim features
| invariable ends up having glaring deficiencies. IdeaVIM is
| good enough, but only to the point - for an expert vimmer
| it may feel annoying. VSCode vim experience is similar, and
| Sublime as well - there's really no good comparison between
| them to say which one is really "better", they all have a
| spectrum of weird, quirky behaviors. There's one notable
| exception - Evil-mode in Emacs is fantastically good -
| sometimes you even forget that it's not a built-in feature,
| but a third-party extension, an afterthought.
|
| > shortcuts can be assigned for almost every command
|
| In Emacs, you can bind keys to anything, conversely -
| everything is a command - every keypress, every mouse click
| and mouse-scroll. And since Emacs is inherently a modal
| editor, you can do stuff like binding commands to a double,
| triple, etc. keypresses. Like for example, when I'm typing
| fast, to autofix most recent typo I'd just tap comma twice
| - this is just one example of unbelievably fast way to stay
| focused.
|
| Most devs, once they find their favorite tool would settle
| with it and don't even explore other options. "I don't have
| time for that.", "I don't want to be building my editor",
| "I am already so good with what I have, why?", they would
| say. My suggestion is to always stay skeptical of current
| choices and curious about unknown. It's not the concrete
| implementations, but rather abstract ideas that may grant
| some surprising and unexpected benefits.
| jrm4 wrote:
| Here's the thing (as someone who did Emacs for a year and then
| gave it up)
|
| The possibility and ease of _interoperability_ with other
| general program styles is far more important that the idea is
| given.
|
| Look, there are too many other good tools out there that do
| things like have a standard file picker, use CUA bindings etc.
| This is primarily why I left Emacs for non programmy things
| (and am happier with a hacked zim-wiki, though I imagine
| obsidian et al might work too)
| johnhamlin wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| globular-toast wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| I wasn't talking about programming.
| cmrdporcupine wrote:
| 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.
| jlarocco wrote:
| 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.
| wiggles4cash wrote:
| As someone who doesn't use emacs how do i install this?
|
| edit: i'm on windows
___________________________________________________________________
(page generated 2025-11-16 23:01 UTC)