161–170 of 191 posts
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…
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
I have a job to get done, and my job isn’t screwing around with my Emacs configuration. And honestly, even if that was my job, I wouldn’t want to spend all my time messing around with a fragile, slow, untyped lisp REPL in the first place. I used Emacs because it helped me get my job done, not because I have any particular affinity for lisp. I truly do not — in fact, I have even less affinity for it now that I’ve wast…
> I have a job to get done Yeah, it so totally fair to hear it from a Haskellite, I'm so convinced now... /s "I have a job to get done, and my job isn't learning category theory, monads, type families, fighting compiler's cryptic messages and pragmas. I don't have any particular affinity for FP. I truly do not - in fact, I have even less affinity for it now that I've wasted so much time making Haskell do basic I/O an…
I wrote a lot of lisp making Emacs work the way I wanted it to. VSCode has been a remarkable improvement. Writing extensions for it has been a breeze. I have zero interest in going back.
Earlier quoted context omitted.
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.
It's definitely slower when doing any intensive background activities that Emacs would normally offload. But I've found VSCode has features readily available as one-click installs that are very difficult and convoluted to setup in Emacs. For some of those you end up either settling for less-ideal tools in Emacs, or because you're not an expert in the specifics of the tool being integrated, you end up with a much less…
Emacs is single threaded and can't offload any elisp code. Even the stuff it can offload as background OS processes report in to the main loop and share time with editing, so a chatty background process can and does frequently lock up Emacs. So I'm surprised that VSCode, whose runtime is better suited to async jobs, ever feels slower than Emacs.
Earlier quoted context omitted.
> I've installed emacs now on I never had what you describe. The variability there could be almost random - which version of Emacs you're installing? How are you installing it? Are you trying to build it from source? What renderer are you using - there are several: Lucid, Motif, GTK, NS, W32, Haiku, Android, Cairo, Pgtk. Perhaps it's installing different renderer instead of using pgtk. Maybe it's not a bug with Emacs…
Yes, I'm always having "special" problems. It's probably due to the fact that I jump around platforms a lot between Linux, macOS and Windows, mixed GUI and ssh. For example, macOS emacs always starting at the bottom of the window stack instead of the top. macOS emacs having different font notation than Linux emacs, so maintaining common config is hard. Terminal emacs -nw having its own set of rules, and M-x needs to…
The tradeoff is that Emacs does let you handle it all - you're not forced to accept platform defaults like in some editors. Most editors have their UI/behavior largely baked in by the platform. You can customize colors and keybindings, but the fundamentals - window management, font rendering, how system keys work, terminal integration - are mostly dictated by whether you're on Mac, Windows, or Linux.
So when you have mac Emacs behaving differently than Linux Emacs, it's not because the software forced you into that corner - it's because the underlying systems are different and Emacs exposes that difference rather than hiding it behind a unified abstraction layer.
Emacs gives you the rope to make things consistent across platforms, but also the rope to hang yourself. Other editors pre-tie the knot for you.
Earlier quoted context omitted.
> 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 b…
> In Emacs I can reuse functions of one package in another You say like it's some kind of feature, but for me it sounds like a potential for name clash, and using private API which is prone to change/break. > You call it "a legacy editor" without the slightest clue of what Emacs hackers are capable of doing The thing is that is was VSCode which has brought us LSP, not "emacs hackers". It was VSCode which has brought…
Oh, you just have no idea. It feels absolutely empowering and immensely liberating to have access to EVERY single line of code running and affecting your system editor. Whenever I need to solve a problem, I don't need to ask permissions, send PRs, dig through API documentation, google for answers, yell at LLM for not giving me answers - I can modify any behavior of any function on the fly and just move on. All that "it just works™" promise of other editors quickly evaporates when I, as a programmer, feel out of control of whatever happens on MY computer. Sure, yes, there's always a possibility that my "stupid hacks" just break for no apparent reason. Except, it rarely happens in practice, and when it does, I know how to quickly fix or put a workaround, because I precisely can pinpoint the exact line of code. Last time when something broke and it took me more than ten minutes to figure it out was about two years ago - the combination of multiple upstream updates and my lousy customization on top confused me for some time - it's all about trade offs, I'm happy to spend 15 minutes once every few years to fix some shit, if that gets me complete and total control over my environment.
I'm a hacker, not a florist - I want precision and complete transparency, not pretty buttons. I don't want any magic - I can't trust some extension to "just work" on a button click, without precisely knowing what it installs, where, and to what extent.
> what's the Emacs answer to those?
Ah, just like I said before, you're talking about things as if you're staring at the surface of the calm water of a lake. Except for an ocasional splash, it may seem lifeless to you, yet you don't have the faintest idea of its depths or what lies beneath.
There's currently an implosion of different LLM packages for Emacs - gptel, gptel-agent, ECA, agent-shell, claude-code, claude-code-ide, monet, claude-repl - and numerous others I haven't even heard of, these are just off the top of my head.
Emacs community may not be big enough and may lack incentives to constantly innovate, but they have no problem borrowing ideas from other places.
> All editors are catching up to VSCode
Wake me up when they figure out things like indirect buffers and executable source blocks in different PLs that can pipe data into one another, or when someone uses VSCode to control their window manager. Or when I can use literate programming to manage my dotfiles. And I haven't even gotten to the REPL part, even with Joyride it still falls short - there's no "I can hook to everything and redefine anything" in Code.
Earlier quoted context omitted.
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".
So we all agree we need Emacs 2.0™, rewriting both the UI and the guts? /j
Earlier quoted context omitted.
> I have a job to get done Yeah, it so totally fair to hear it from a Haskellite, I'm so convinced now... /s "I have a job to get done, and my job isn't learning category theory, monads, type families, fighting compiler's cryptic messages and pragmas. I don't have any particular affinity for FP. I truly do not - in fact, I have even less affinity for it now that I've wasted so much time making Haskell do basic I/O an…
Yikes. I’ve spent 40 years in this industry. My work is in formal verification. My comprehension isn’t the problem here. I wrote a lot of lisp making Emacs work the way I wanted it to. VSCode has been a remarkable improvement. Writing extensions for it has been a breeze. I have zero interest in going back.
Share the Emacs packages you wrote. I'm saying this unironically - someone might be interested to keep improving them, maybe they'd find some interesting ideas to extract from them. Don't be like some ungrateful jerk who benefited from communal work for years when it suited them and then has nothing to leave but grumpy resentment when they're done.
Earlier quoted context omitted.
> 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 b…
> In Emacs I can reuse functions of one package in another You say like it's some kind of feature, but for me it sounds like a potential for name clash, and using private API which is prone to change/break. > You call it "a legacy editor" without the slightest clue of what Emacs hackers are capable of doing The thing is that is was VSCode which has brought us LSP, not "emacs hackers". It was VSCode which has brought…
LSP is a great thing to have, but it's actually much less capable than something like SLIME. If you've used SLIME, you'll see there's no comparison. LSP is a lot better than the nonsense I had to go through to get Java completions in the early 2000s, and I'm thankful to have it.
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,…
> 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 "repro…
I'll install it again. I hope you're happy.
Having a text based Jira frontend seems attractive. (I've actually written myself a cmdline tool that uses Jira API so I don't need to visit the website)