Live data from Hacker News

IDEmacs: A Visual Studio Code clone for Emacs

codeberg.org

181–190 of 191 posts

Re: IDEmacs: A Visual Studio Code clone for Emacs

#181

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.

> and becoming more user friendly.

Familiar UX is not the kind of multiplier. Learning Lisp REPL idioms is the multiplier. Selling Emacs with "easy" may have adverse effects in the long run - it sets the wrong expectations from the get-go. Every Emacs discussion typically gets a few "I tried Emacs for a long time and it just didn't work for me..." type of comments. When you dig deeper, you typically hear that they've been trying to use mostly the editor, ignoring much of the Lisp functionality. Unlocking the power of Lisp is what gets you into "turbo" mode in Emacs.

I get it - Elisp is an absolute opposite of being easy and intuitive, even experienced coders who already used modern Lisps like Clojure often complain that it just doesn't feel comfortable. Common Lispers don't like it either. Schemers have little love to share for it as well - it's a common theme.

Unfortunately, that's the Lisp we have, and until we figure out a better alternative, we have no choice. FWIW, it's still a Lisp, and it's still far better than anything else that's non-lispy. The simplicity and dynamism of Lisp is what allows you to quickly move forward, to build things that defy expectations, extend things beyond common sense when required.

We have many examples of when people with no programming background grind through the Elisp tutorial without any prejudice and start building things that eventually turn into legendary packages. Perhaps it's more valuable to cater "beginner Emacs experience" for these kinds of personalities, rather than trying to appeal to reactjs/springboot/django divas with "decades of programming experience" that demand tabs, sidebars and minimaps; twist their faces whenever they have to stare at Elisp stacktraces and complain that "Emacs doesn't look modern enough"?

Re: IDEmacs: A Visual Studio Code clone for Emacs

#182

Earlier quoted context omitted.

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 impro…

No issues here, except for you being an Emacs user :D > IntelliJ is to blame for why my transition to Emacs took me two years ... It was a bit opposite for me, I jumped around so many editors, and, then I fell in love with VIM, spent so many hours to get the config that meets my need, dissed many Emac users. And, now after many years, as I grew, I realized, these are tools, and at the end, it's all on the user who ma…

> No issues here, except for you being an Emacs user

I am a die-hard vimmer. I just one day woke up and realized that Emacs vims better than Vim. Seriously though - it's not about concrete implementations, it's all about the [abstract] ideas.

I use vim navigation everywhere - in my editor, my browser, my terminal (I use nvim too), my WM, remote sessions. I control my music, video-playback, app switcher - all, using mostly just home row keys. I never need to touch arrow keys and rarely have to reach for the mouse.

Idea of vim navigation is an absolutely brilliant, beautiful, practical model, it speaks to me and I have zero reasons for not using it. What keeps me with Emacs is another immeasurably brilliant idea - the idea of practical notation for lambda calculus, which is known as Lisp. Lisp probably can be crowned as one of the most important ideas in computer science. It's just hard to think of anything more influential than Lisp.

There's a notable shared trait between these two - they both entail tacit knowledge. You're probably well aware of what I'm hinting at. You see, trying to teach someone who never rode a bike is challenging for a similar reason. You may show them countless videos, explain how gyroscopic effect and caster effect keep the bicycle stable, you can draw diagrams and try to inspire them with names of all famous people who loved riding - none of it can explain the simple joy of an ordinary bike ride on a straight line. Until they've tried for themselves, nothing will ever make them feel what they can never unlearn later.

> I use both IntelliJ and (n)vim almost side-by-side

I perfectly pictured my own younger self - I absolutely had maintained the same setup not too many years ago, before diving into Emacs. And then it became three things side-by-side. Eventually, I had to stop this madness and forced myself to use only one. I made a promise that instead of reaching to the familiar and cozy confines and warmth of WebStorm, whenever I had to get something done, I would try to google and find ways to achieve the same things in Emacs. I really wanted to figure it out and make the decision once and for all. My plan was to time-box that experiment for a week, fully expecting that in the end it will replace Vim, but certainly not WS. After a week I decided I liked it and I wanted to keep going. Two months later I realized - I had not had to run WebStorm even once. Five month later I decided not to extend my license for next year, but it was never about the money.

Keep finding new bicycles to ride. Even when you don't feel like it, and especially when it feels kinda scary.

Re: IDEmacs: A Visual Studio Code clone for Emacs

#183
post #128

Earlier quoted context omitted.

The problem is that you need to spend 20 years to get out of the "beginner" zone.

I’m 25 years in and still firmly in the beginner zone

There are no "Emacs experts". Bedrock of Emacs is Lisp. Lisp is the essence of computation itself. It's both simple to understand (5 basic special forms) and impossible to master at the same time - you can construct entire universes with those 5 basic building blocks - quote, if, lambda, let, and set. If someone finds something cannot be achieved in Emacs they either are wrong, or wrong at the point in time - theoretically, anything can be done in Emacs, it's just a matter of time. So, technically, it's impossible to capture all possible features of Emacs, the totality is infinite.

In comparison most other languages are 'closed' - e.g., C is a closed language. Its spec is finite and fixed (C99, C11, C17, etc.). You can genuinely master it: all keywords, all standard library functions, all undefined behaviors, all edge cases. There's a ceiling.

Lisp is unusual, The language itself is a tool for language-building. Lisp is 'open'. There's no canonical "complete" set of what exists. Thus there's never completion or "mastery"

Re: IDEmacs: A Visual Studio Code clone for Emacs

#184

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…

I actually agree with that. I should have added a qualifier to my previous comment (grandparent), namely, I use Emacs mainly for things other than programming, and if I ever start programming full-time in a language other than Lisp, then, yeah, (for the reasons you give) I'd probably use vscode instead of Emacs to do that.

I use Emacs for managing files (with Dired) running shell commands, bookkeeping, keeping notes and chatting with LLM services.

Re: IDEmacs: A Visual Studio Code clone for Emacs

#185

Earlier quoted context omitted.

No issues here, except for you being an Emacs user :D > IntelliJ is to blame for why my transition to Emacs took me two years ... It was a bit opposite for me, I jumped around so many editors, and, then I fell in love with VIM, spent so many hours to get the config that meets my need, dissed many Emac users. And, now after many years, as I grew, I realized, these are tools, and at the end, it's all on the user who ma…

> No issues here, except for you being an Emacs user I am a die-hard vimmer. I just one day woke up and realized that Emacs vims better than Vim. Seriously though - it's not about concrete implementations, it's all about the [abstract] ideas. I use vim navigation everywhere - in my editor, my browser, my terminal (I use nvim too), my WM, remote sessions. I control my music, video-playback, app switcher - all, using m…

Ah, bicycles, something that I love so much. Yes, agreed, someone who never rode will never realize how amazing it is feel the air in your face, the gentle sound of the tire rolling. I miss it so much.

But, when you keep changing your bikes, and start fiddling with the mechanics of it, you forget, what made it worth in the first place! What was the thing that gave you the pure joy.

PS: Using nvim and IntelliJ(Ultimate) side by side is for a personal reason. I have to be away from my main desktop for a really long time. So have to SSH into my desktop using a Surface Pro 3 (Running Linux) to work. It's a really portable setup, and works well as a thin client. And it is an experiment to fully utilize CLI tools, to get my work done.

Re: IDEmacs: A Visual Studio Code clone for Emacs

#186
post #30

Earlier quoted context omitted.

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...

> 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.

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.

Re: IDEmacs: A Visual Studio Code clone for Emacs

#187
post #186

Earlier quoted context omitted.

> 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.

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.

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.

Re: IDEmacs: A Visual Studio Code clone for Emacs

#188
post #83

Earlier quoted context omitted.

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.

wait foot pedals ?

It pops up a surprising number of times.

Keysets or chorded keyboards have been around since The Mother of all Demos, but never really seemed to have caught on. It makes sense to me to put them at your feet to chord some common actions or modifiers.

Re: IDEmacs: A Visual Studio Code clone for Emacs

#189

Earlier quoted context omitted.

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.

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...

I will absolutely try this one out, it looks a lot more useful than binding caps lock.

Re: IDEmacs: A Visual Studio Code clone for Emacs

#190

Earlier quoted context omitted.

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 f…

> 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?

> 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?

Post reply on HN