Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Naah, not really. I've done that emacs exercise countless of times over a few decades and now I use vscode. I don't feel like I'm missing much.


It is easy for people who love Emacs to believe that most people (or most programmers) would come to love (or prefer) Emacs if they would only put in the time to ascend the initial learning curve. But this belief is an instance of what is sometimes called the "typical-mind fallacy": an underestimation of how different people's minds are.

GNU Emacs was my daily driver from 1991 to late last year, when I switched to vscode. I wrote many lines of Emacs Lisp code -- 20,000 lines of which I "kept": I arranged for those lines to get loaded into Emacs every time Emacs starts, and since the code was almost all "UI" code, any particular function or piece of the code ran on average at least several times for every hour I spent using Emacs.

Although I do not regret choosing Emacs in 1991, vscode suits my particular mental make-up better than GNU Emacs did.

To take one example, I spent hours configuring Emacs to be less chatty. I turned off the bell that sounds every time the user makes an error (where for example asking Emacs to scroll down when the bottom of the document is already visible in the window is considered an "error" -- in contrast to vscode's not feeling the need to send a message to the user or get the user's attention when that happens). I tried (and mostly succeeded) in turning off the repetitive messages Emacs displays in the echo area, e.g., displaying "Wrote foo.c" any time Emacs writes to file foo.c and, e.g., (particularly distracting to my train of thought) the "Autosaving..." message that regularly appears in the Echo area X seconds after I stop typing. In contrast, vscode is silent (non-chatty) enough to suit me in its default configuration -- like most GUI apps since the introduction of the Macintosh in 1984 are.

P.S. The way I got rid of the "Autosaving..." message was to turn off Emacs's autosaving functionality altogether and add my own autosaving functionality, which consisted of a call to save-buffers every time the user switches buffers.


Did you use orgmode and mu4e? If so what are you using in their place now?


To read mail, I used (version 5 of) Kyle Jones's VM, but (out of my being too lazy to configure mail fetching and mail sending) switched to gmail.com about 6 years ago.

I never embraced org mode because I didn't want to learn another few dozen keyboard shortcuts ("keys" in Emacs terminology). There are for example in org mode keyboard shortcuts for moving the current line up a line and down a line. Even before I saw vscode my reaction to learning about those 2 shortcuts was that such functionality would be useful (particularly in to-do lists), but I would prefer to execute the functionality by dragging with the mouse, which it turns out that vscode lets me do (in its default configuration): particularly, I click on the line's line number to select the line (to set the mark and activate the region in Emacs terminology) then move the mouse cursor into the selection, then drag. (In emacs, I'd kill and yank to move a line relative to the other lines -- and I configured my emacs to have a menu on the right mouse button with the kill and yank actions on it.)

In general, vscode is a nice environment for keeping to-do lists. Consider for example this next small "hierarchy" of actions:

  buy milk

      drive to store

          find car keys
If we replace "find car keys" above with a string of text too long to fit on one line, then the basic structure of the small hierarchy becomes obscured in Emacs (even with visual-line mode on) but not in vscode as I explain in greater detail here:

https://news.ycombinator.com/item?id=25311743


I do something like this in VSCode as well, Markdown todo lists:

  - [ ] Task 1

    - [ ] Task 1.1

      - [x] Task 1.1.1

    - [ ] Task 1.2
etc.

In particular, I break down yearly goals into quarterly, monthly, weekly and daily, each another node in the tree getting increasingly more specific.

It really helps understand the flow from the highest to the lowest levels of details. Only problem is if goals change midway, it's not propagating up the tree automatically. I just leave it like that though, not gonna manually fix that.


I use https://quire.io to do similar. It's also 100% Markdown, and you can copy the list itself as Markdown to elsewhere.


C-x t


I'm on the same boat as you. I love Emacs, the uniform keybindings and especially Magit, I thought I could never use anything else until I started working with TypeScript React in my current job, which Emacs has very bad support for.

The funny thing is: I don't even consider VSCode a superior text editor, it's just that Emacs is _so slow_. I used Emacs back then because compared to many other editors and IDE it allowed me to work faster, but VSCode despite all its shortcomings has done the very same thing Emacs did for me previously.

I still use Emacs every day at work just for Magit, but whenever Emacs freeze just for a few seconds every time I perform a big merge I just feel like finishing up the task in VSCode


I had a similar experience recently, where I had to spend some time working in TypeScript on a React front-end and my emacs really was falling over unfortunately. Tried tide, tried the LSP, but ultimately I found myself in VSCode in order to make the deadline. Turns out there is a pretty great magit layer in VSCode (https://github.com/kahole/edamagit), and as a former long term vim user that had been using spacemacs, a great spacemacs-like bundle for VSCode (https://github.com/VSpaceCode/VSpaceCode).

It’s the first time I’ve actually felt like I could drop emacs if I wanted to, I actually was enjoying the setup.


> Emacs is _so slow_

That’s exactly what it felt like in 1991: “eight megabytes and constantly swapping!”


Do you use Emacs in windows?


I've used it on Windows before and I think I know what you're talking about. However, right now I'm using it on macOS actually, the mac-port to be more specific.


I can see that for most people. It is really something, though, to watch someone really good with Emacs or Vim fly though something like a complex refactoring.


You can refactor with IDEs too, and I don't remember emacs being better at this than JetBrains is.


I've seen a few text editor pros who just weren't aware of what modern ides are capable of, particularly with strongly typed languages. They thought grep, regex and keyboard shortcuts were impressive.


There is something that I think most programmers have, which is that seeing someone type an arcane-looking combination of characters, press enter, and suddenly a variable has been renamed in every file in the directory is more impressive then clicking on UI elements to get to find and replace, then clicking the "execute" button.

They both do the same thing, probably take the same amount of type to actually complete, but our brains are wired to see the keyboard-only method as some sort of cyberpunk magic.

Or maybe that's just me!


imo this is exactly it.

It reminds me of pre-iPhone Japanese mobile phone culture where the more complicated interfaces were prized because users had to master them like a game or a puzzle.


Sure, I assume you can, but since Emacs/Vim is a sort of environment that encourages terse keybindings, fast call outs to the shell, etc, that's where I've seen more people that can seem to do stuff almost subconsciously.


Only available resources, modern IDEs are like hardware vendors wet dream came true.


Eight MegAbytes of Continuous Swap.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: