They also don’t bother to announce a Vim or Emacs one either. VS Code provides good default and most people don’t care about editor fluency. Which is why they keep using it.

▲

kamaal 4 days ago | parent [-]

>>They also don’t bother to announce a Vim or Emacs one either.

vim has a universal and in many ways a eternal use case. You have to edit a file at some point on a server, be it a self hosted or even on ec2. Thats kind of the only real use case for vim.

In these days of AI assisted coding, no one really 'edits' code. A lot of editor short cuts and fluency related concepts kind of in many ways are not relevant in this paradigm.

The thing is vscode just works, like just works, for nearly all the usecases. In case of emacs, learning it and mastering it takes lots of time in ones career. In case of vscode you don't have to do this, you can straight away work on the project that you want to get done.

emacs is some what like a massive distraction from the actual task you want to achieve. Instead of writing code to build a project, you have to first write code to make emacs work, then use emacs to write the project code. In vscode you just write project code.

▲

skydhash 4 days ago | parent | next [-]

I don't know if you're trolling or not, but there's one thing that VSCode and nearly all other "normal" editors don't have and I want: Non-tied Windows (pane) and buffers (opened files). One of my most used layout is one main window and two smaller ones. Layout like this are my mental frame, but what I actually want to look at may vary at any moment. It may be a test result, a git diff, or going down a reference link. It's like a moodboard instead of a stack of paper you can only look at one at a times.

Emacs and Vim has this built-in. Other editors kinda have that, but it's clunky. I can suffer IDE because they provide a lot more than editing.

> Instead of writing code to build a project, you have to first write code to make emacs work, then use emacs to write the project code

That's only done once. It's like adjusting the mirrors and seats of a car. Once it's comfortable, you don't have to touch it. Using VS Code feels like borrowing a car with a very limited range of adjustments. Why is the explorer on the left and the terminal at the bottom? Why are they always there?

▲

iLemming 4 days ago | parent | prev [-]

Have you even ever watched someone experienced using Emacs or you're making assumptions on your (I suppose limited experience)?

The "distraction" framing assumes everyone has the same preferences and working style, I for one find VSCode (and IDEs in general) massively distracting from productively solving many tasks. No, it's not "a skill" issue - I have used InteliJ every single day for almost a decade, diving into some profoundly advanced and non-documented features, and I do open VSCode from time to time.

I feel your argument conflates initial learning curve with ongoing productivity, and assumes VSCode's approach is universally optimal rather than just different.

▲

kamaal 2 days ago | parent [-]

>>Have you even ever watched someone experienced using Emacs or you're making assumptions on your (I suppose limited experience)?

I am one of those experienced Emacs users myself. Wrote more stuff in Emacs and even vim than most devs today will even write code over their careers.

Its just vscode now does simply too many things out of the box, you obviously can recreate that in Emacs, but its a pointless exercise. Time consuming, and distracts your from your real job. My job is to write code, not build emacs to write code.

I totally stopped using Org-mode, because Google docs do it way better.

At some point you have to move on. For some people like that point arrived a little early.

	▲	iLemming 2 days ago \| parent [-]
		> Wrote more stuff in Emacs Can you name Emacs packages you've authored, maintained or contributed to? > vscode now does simply too many things out of the box Oh yeah? Can you edit your filesystem in VSCode like a wiki? Changing directories and filenames as if you're editing plain text? Can any of thousand of its extensions provide "indirect buffer" experience? Can you bind a double tap of the comma to navigate to the last error and automatically fix it? Can you at all bind to double/tripple comma or just about any arbitrary key based on context in VSCode? Keyboard macros with counters - e.g. to transform lists into numbered lists? True buffer based (not file oriented) workflows? Occur-mode style search and replace? Comint style process interaction? Are there any extensions that allow you to move the cursor to the piece of a plain text like "rfc-3540" or "myproj#4044", intelligently recognize it and allow you to browse the RFC document or review a Pull-Request - Emacs does. Can you run a shell command and pipe it into a buffer, or pipe the content of a buffer through series of shell commands and into another buffer? > I totally stopped using Org-mode, because Google docs do it way better. Don't be ridiculous. They are completely different classes of products. If you are even having to compare Org-mode with GDocs, perhaps you don't know well either or both. GDocs can't manage my dotfiles. I can't use it to annotate books or academic papers. I can't have inline LaTeX formulas in GDocs. It can't let me control a videoplayer and type my notes at the same time. I can't use it to manage my flashcards or keep the log of my LLM interactions there. I can't have executable blocks of code - in org-mode I can explore APIs or send SQL queries while passing them into data transforming code blocks. There are no TODO states/keywords in GDocs, no agenda views, no scheduling/deadlines, no time tracking/clocking, no habit tracking, no pomodoro timers, no dynamic time tables, no tag-based filtering, no capture/refile system. > At some point you have to move on Like I told you already, you're assuming too broadly. Both VSCode and Google Docs are excellent products - no denying that, but they are not universally better. If you came to the opposite conclusion, it is yours, and yours only.