Earlier quoted context omitted.
Same here in regards to Magit. I've tried seriously using Emacs (Spacemacs) for a year or two, but something always doesn't work as intended, code completion and static analysis is extremely hard to configure, especially you have some non-standard project setups. Then switched to a mix of vim for simple stuff or clion/pycharm in vim mode for rust/cpp/python... BUT, subjectively, Magit is the best git client ever crea…
Why do you need to use a git "client"? What's wrong with just using the standard CLI? I use VS code and never bother with its git ui. Just open a terminal and use git commands.
The values of Emacs, the Neovim revolution, and the VSCode gorilla
121–130 of 353 posts
Re: The values of Emacs, the Neovim revolution, and the VSCode gorilla
#122When you finally learn to master and config Emacs, you run circles around all other editors. Emacs is so much more than just an editor. But even if you only use it for coding: Magit is the best git client I have used in years (coming from PyCharm + Git Tower App, which is nice), then there‘s Ztree-Diff (excellent folder diff tool; previously using Kaleidoscope app), then Eshell for interacting with the server from wi…
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.
Re: The values of Emacs, the Neovim revolution, and the VSCode gorilla
#123On the discussion of values, I'd also like to submit "(expected) longevity" for consideration, which I think is distinct from "stability". I made the switch from Vim to Neovim as soon as I felt confident that (1) the project was going to be around for a while, and (2) it was on track to "overtake" Vim (you may choose to disagree with me on this, I found built-in LSP to be a compelling selling point, but the specifics…
I've made that jump a couple of months ago, and so far I love it. There isn't as large of an ecosystem, but Kakoune just feels better integrated with the environment. Is your hesitancy based on some particular feature, or the ecosystem, or something else? Or is there some default that you dislike?
I feel like it doesn't need to have as many maintainers in order to be successful, because its philosophy is much more spartan. The maintainers pretty aggressively keep the project's scope in check.
Re: The values of Emacs, the Neovim revolution, and the VSCode gorilla
#124VSCode has great and convenient language support, but the trade-off is reduced text editing efficiency, slower speed and more bloat. It is a worthy trade-off in many situations, I use it often when working on projects that are written in languages I am not too familiar with. I would like to emphasize how big of a game changer the next release of Neovim 0.5.0 will be. With builtin LSP support it will get code navigati…
Still, I had it in my mind that I wanted to have and fast alternative to vscode so I kept trying to work with Neovim. That is 'till I noticed how much I dislike using vim. You see it has that learning curve that if you've stopped using it for awhile it's a struggle to do basic things. So I used a configuration that made it act more like normal editors. So problem solved? Unfortunately, most extensions are made for a normal vim settup not my easy mode settup. Plus, I started missing having simple things like scrollbars and tabs I could click on and move with the mouse. (I remember the graphical front end for Neovim not meeting these needs at the time.)
So ultimately, I just moved on and stayed with vscode. I would still like an alternative (kedit/k-develop looks promising). However, I'm sort of addicted to the plugins.
Re: The values of Emacs, the Neovim revolution, and the VSCode gorilla
#125I've tried all of them, and still prefer vim because it's the least hassle to install/configure anywhere - my dotfile setup installs my plugins automatically, and I'm set. However, I do use VSCode extensively as well, largely because of the language servers. But sometimes it takes so long to start up (and nags me to do so many updates to itself and extensions) that I just toss the window aside and use a native Mac ed…
By the time I discovered use-package I couldn't believe that I had been tar-balling a mess of crap around all these years.
Re: The values of Emacs, the Neovim revolution, and the VSCode gorilla
#126When you finally learn to master and config Emacs, you run circles around all other editors. Emacs is so much more than just an editor. But even if you only use it for coding: Magit is the best git client I have used in years (coming from PyCharm + Git Tower App, which is nice), then there‘s Ztree-Diff (excellent folder diff tool; previously using Kaleidoscope app), then Eshell for interacting with the server from wi…
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.
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.
Re: The values of Emacs, the Neovim revolution, and the VSCode gorilla
#127Noob question: Is Sublime text still a good text-editor in 2021? Did it just loose momentum or not being open-source is insurmountable? I still think its speed and usability are not easy to match.
Sublime is a perfectly fine and frankly faster editor than VSCode. The problem is the slow nature of the updates, the underwhelming API and people abandoning it in droves because they opt for VSCode makes the extension library not as comprehensive or feature packed. Half the extensions I use in VSCode don't have a parallel in Sublime I still use it to quickly edit text or read some files quickly cause it opens really…
For smaller files, Sublime is great.
Re: The values of Emacs, the Neovim revolution, and the VSCode gorilla
#128> It also shines in areas where Emacs doesn’t: if you’re a programmer working on typical contemporary projects, mostly just wanting to get stuff done, things usually… just work. You install VSCode, open a source code file, get asked to install the extension for that particular language, and that’s it. You get smart completion, static analysis, linting, advanced debugging, refactoring tools, deep integration with git…
>The great thing about Emacs is that everything is a buffer[...] It frustrates me endlessly that this one simple, almost self-evident piece of Emacs wisdom failed to gain traction almost everywhere else. Even the venerable Vim drops the ball hard here, with the various "widgets" it uses in its interface which have slightly different semantics and behaviours. Every time I get a shitty modal with some text I can't copy…
> It frustrates me endlessly that this one simple, almost self-evident piece of Emacs wisdom failed to gain traction almost everywhere else. Even the venerable Vim drops the ball hard here, with the various "widgets" it uses in its interface which have slightly different semantics and behaviours.
Perhaps I don't understand emacs well enough, but I know that every file loaded in vim can be accessed via its buffer number. How it's displayed depends on the window and tab layout. Quickfix, help, and terminal buffers behave differently, but the vast majority of buffers are just associated with open files.
Re: The values of Emacs, the Neovim revolution, and the VSCode gorilla
#129VSCode has great and convenient language support, but the trade-off is reduced text editing efficiency, slower speed and more bloat. It is a worthy trade-off in many situations, I use it often when working on projects that are written in languages I am not too familiar with. I would like to emphasize how big of a game changer the next release of Neovim 0.5.0 will be. With builtin LSP support it will get code navigati…
That’s amazing news. Native LSP would be game changing. I use coc, but it takes a bit of messing about to get everything working smoothly. Also vscode has has a bunch of extra stuff beyond what’s available via LSP for python now, which is a shame because I’d love to get a full pyright + bells experience in vim.
Re: The values of Emacs, the Neovim revolution, and the VSCode gorilla
#130When you finally learn to master and config Emacs, you run circles around all other editors. Emacs is so much more than just an editor. But even if you only use it for coding: Magit is the best git client I have used in years (coming from PyCharm + Git Tower App, which is nice), then there‘s Ztree-Diff (excellent folder diff tool; previously using Kaleidoscope app), then Eshell for interacting with the server from wi…