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