Ecosystems change all the time, even if you've been coding in C for decades chances are that you've dealt with a bunch of build and package systems over the years.
The more time passes the more I value ecosystem- and language-agnostic tools. Dummy completion, tag-based cross-reference (admittedly not completely language-agnostic, but close enough), find, (rip)grep, fzf etc...
No setup, no configuration, it's lightning fast and it just works.
I'm not arguing that my approach is better than yours btw, if you like more integrated environments then go for it. I just sometimes wonder if "kids these days" even consider that there's a world outside of Visual Studio and ultra-heavy language runtimes. The zen of a 10 line Makefile.
That's a huge burden.
Now, if you implement LSP, you get "for free" support for C#, C, Python, Rust, etc etc. People can evaluate your editor on its merits as a text editor, not on whether you had the time and energy to add support for their favourite language.
But learning tools such as vim and learning how to configure those really helps you get out of the comfort zone
I was a regular vscode user but after using vim my workflow really improved
I have nothing against vscode users but sometimes getting out of comfort zone really helps you
Having the tools all work together in one environment is honestly a far superior experience than having each tool live in its own bubble and requiring you to do all the coordination work yourself, with all of the repetition and scope for mistypes in the process.
Anything else is a klundge.
If I have to thank anyone, it is Xerox PARC, TI, Genera, Apple and Borland, long before Microsoft mattered at all.
Yours was a very ungrounded commentary.
I think vim is a messy pile of hacks, and I would love to see that changed. Neovim is nice with the extend and evolve approach but I'm always looking for something that can really provide a clean base for extensions to build on. (Yes ,yes, I know emacs is an editor-writing IDE)
On the other hand I see nothing about plugins here. I think the approach to extensions is a very important question to answer early on.
Its a workflow we are looking into supporting, but its difficult. VSCode has extensions that are licenesed in a different way to the rest, which includes all the remote development ones (WSL/SSH/Docker).
Their license can be found on the marketplace, but broadly they can "only be used with Visual Studio Family products" (or something of similar wording, i.e. Code only, some are VS only). They are also fully closed source as well, the GH repos are just for issues.
So we'd like to support that sort of workflow, but it will mean more work on our end since we can't use that existing work due to the license.
No, Evil mode is not better than Vim itself. For one it's slower, defining keybindings is much more verbose, everything outside the actual text file has completely different controls, and I lose most of the seamless interoperability with other terminal tools. And it runs within an environment that tries to be literally every text-related tool by itself, making it overly complicated in many aspects.
Emacs provides a convincing Vim layer on top of a hackable LISP runtime. While there's not much point in trying to decide which one is "better," it's not an entirely unfounded point.
> For one it's slower
Could you be more specific? At least for me, there's no noticeable lag when using Evil mode.
> defining keybindings is much more verbose
This is why some use Vim? I don't see how this:
(define-key evil-normal-state-map (kbd "w") 'some-function)
nnoremap w :<C-u>call some-function()<CR>
> everything outside the actual text file has completely different controls
It's because Emacs is more of a runtime for elisp applications. As such, it makes sense to have different behaviors for each key depending on context. FWIW evil-collection does a pretty good job of making keybindings feel consistent outside of ordinary text buffers, so you won't have to fall back to Emacs keybindings these days.
> I lose most of the seamless interoperability with other terminal tools
This is plainly false. Shell interoperability in evil works exactly the same as in Vim.
> overly complicated in many aspects
This doesn't mean much without specifics. Implementation complexity isn't inherently a bad thing as long as it provides value.
Besides, Emacs is a just a LISP interpreter at its core. If anything, it's easy for programmers to grasp and hack on.
Long-time Vim user here. I tried switching to Doom Emacs for a few months. I really, really wanted to like it. As a nerd, the infinite customizability is like catnip to me. It has a really mature plugin ecosystem and you can have a really comfy computing setup with magit, org mode, dired, mu4e, etc...
But Emacs is intrinsically slow as molasses. The nail in the coffin for me was the scrolling performance. And I don't mean line-by-line. Even going half a page, or a full page at a time, pegs a CPU core and there is noticeable latency. The Doom Emacs documentation straight up admits it [0]. They recommend crazy things like turning off line numbers. Even with newfangled native Elisp compiler, it doesn't come even close to vim on alacritty.
[0] https://github.com/hlissner/doom-emacs/blob/develop/docs/faq...
Just to play devils advocate (in reality I'm a die-hard-never-use-anything-else vim user, and have been since 1996-ish), I did once manage to set up vim with so many highlighting and display options that I made my i7 crawl whenever I tried to scroll.
(The main thing that pegged the core to 100% was ':set cul' with ':set number' and various different syntax highlighting for numbers, highlighted numbers, highlighted line, syntax-highlighting within a highlighted-line, etc).
So, yeah, vim can be slow too if you nerdgasm all over the config :-)
1. you spam the scroll key
2. you're viewing a exceptionally large buffer
3. syntax highlighting happens to perform badly on the buffer
4. some plugin is blocking the editor
For Vim, the forth situation has vastly improved with async APIs pioneered by Neovim, but it still can happen nonetheless.
As for the advice about turning off line numbers, that's just a micro-optimization. I've seen similar advice with Vim too. set nonumber nocursorline etc etc... I don't follow any of those overzealous optimization advice either on Vim or Emacs, and scrolling performance is just fine most of the time. Though for Vim, "set lazyredraw" did make a big difference in terms of scrolling performance, but that piece of advice isn't the sort that hampers usability so I don't think it really counts as an overzealous micro-optimization.
But back to Emacs, my view is that general editing performance is just fine. When you think about it, if general editing performance were noticeably horrid, that would be a deal breaker for pretty much everyone. It's mostly blocking operations that's causing problems, but that's a slightly different situation from Emacs being sluggish in general. Vim used to have this problem too up until a few years ago, but it ceased to be a major source of pain after plugins adopted async APIs. I just wish Emacs would follow suite.
There are zero excuses for a widely used editor program to lag that badly in 2021, on very strong hardware nonetheless.
One "hack" I found is to have your font not contain emojis. That was literally the only thing that actually helped.
And Emacs itself isn't at fault that LSP does its thing in a synchronous manner in the same main UI thread and makes Emacs super slow. I know that. But I also know that NeoVIM does the same thing asynchronously and doesn't stutter.
Sadly I'll be done with Emacs soon. I like it quite a lot but I'm not seeing any will to make it adequately fast or, at the very least, make it so its main UI thread can't be blocked.
This sends a message to me that the maintainers are using Emacs in a specific way and don't care about how others are using it. Which means that it's time to part ways.
Not sure what you mean by this
> lose most of the seamless interoperability with other terminal tools
It's not like VIM is more or less interoperable than Emacs is with other shell tools. They live in their own space, you don't (often) pipe stuff in or out of it.
Though there's not much to read into my comment, it was an attempt of being witty, but evil mode is the best VIM implementation found in any editor and just for the fact that Elisp >> Vimscript, makes evil mode a better environment than VIM itself.
Well that's not true at least for vim.
: read !FOO
will run the FOO command and read the results back into the current buffer. I usually search my codebase by reading the results of a grep into a temporary buffer and 'gf'ing to the appropriate file
Recent versions of evil have the option of choosing undo backend, and I have found the new buildin one impeccable thus far.
I used to do that too, I now use the Ack plugin which is almost instantaneous on a codebase that grep used to take 2s-3s long to search. The speed isn't what matters though, it's the fact that Ack only searches source code, not all files so my results is less polluted with irrelevant matches.
...huh? I pipe things into vim absolutely all the time.
I don’t mean to be rude but this is exactly the sort of thing OP meant by “people recommending evil don’t understand why people like vi(m)”.
whatever_command | vim -
Yes you can pipe stuff in and out, you can do in Emacs as well.
My point being that VIM isn't better than Emacs on this aspect, and they're not like other shell tools where COMMON usage is by piping stuff in and out; they're not like cat, more, wc. They live in their own space.
https://gist.github.com/deviantfero/45b9354b433f44450de51c82...
make sure you add `:ensure t` if you don't have it automatically set to true.
* web-mode for general html/css/typescript/javascript editing
* tide + company for autocompletion
* flycheck for eslint support
* prettier for auto format on save if configuration is present
lsp is good for many other languages, but for javascript/typescript it's just not there yet
All these years and I was starting to believe I had imagined light table. How else could one explain no editors adopting inline, always-on evaluation?!
Lately I prefer purpose built IDEs for whatever task is needed. I’m over with editor evangelism. :)
Funny thing is a lot of the features are... just like a file system or Perl script to rip through and replace strings.
Large language ecosystems are only good when you don't need them. If they're just gravy, then life is good. If you need a lot of stuff to be moderately productive, that sucks.
LSP is the shining hope here, but you suddenly get into questions about your build environment, and that's another rabbit hole just to get decent completions.
What’s awful about VSCode? Genuinely curious. I use it daily and enjoy it. I love all the extensions I have access to.
> If you need a lot of stuff to be moderately productive, that sucks.
I don’t see why I would ever not have access to my extensions, nor is it very difficult to copy-paste my extensions.json file to a new machine and press “install all”.
- palpably slow on a recent 16-inch high-specced MBP
- does a lot of extra distracting stuff that can’t be easily turned off (I know I opened a .java file, I don’t need you to open an extra tab that takes focus to tell me I don’t have a Java extension installed. I especially don’t need you to try and launch several Java-related daemons that you know I don’t have and then also put up some notifications about failure to find them)
Re:extensions: great when they work well. But they tend to move fast, and come and go fast. That makes combinations of them brittle. If they're conveniences, that's no problem. But if they're necessary parts of my workflow, then life can suck.
I use vim extension which works well for editing the files themselves. Accessing pretty much almost anything else can be done using the command palete and you can manually assing keybinds to it as well.
This. With some elisp knowledge, you can bend Emacs your way. No need to write full-blown packages. A function here and there can get ya very far. I wrote about this yesterday[1]
You don't work with Git as a DVCS? Or you work with Git and Emacs but don't use Magit!?
My point overall was that I see all of these as a collection of tools. Which one I choose depends a lot on context, and it's served me well to be baseline comfortable with all of them rather than depending too heavily on my emacs setup.
(magit is brilliant, but for some reason it's never stuck with me, unless I want to interactively stage a few specific chunks, and then it's much nicer than using the cli).
1. It takes nine times as long as Vim to open a minified JavaScript file, and then format it with Prettier: https://twitter.com/robenkleene/status/1285631026648276993
2. It takes 14 times as long to open an empty text file than BBEdit: https://twitter.com/robenkleene/status/1257724392458661889
I'm just as surprised as you are that people do see it, that some people don't see it. I have no idea what the explanation is, but there's something radically different about me versus people who can tolerate VSCode's slowness (I'll use VSCode if I have to, but I'll avoid it if at all possible, just because it's slow).
There's some truth to your comment though, in that VSCode's optimizations are very on rails, i.e., if you go the slightest bit off the beaten path (like I opened a file from the Finder, instead of from the sidebar, in the BBEdit/VSCode video), then VSCode approach to optimization falls apart (you can find accounts of the tricks VSCode uses to appear fast online, there's a lot of smoke and mirrors based around specific workflows -- I think making a new tab is actually the example they use). It wouldn't surprise me if part of the reason I perceive it as so slow is I expect every feature to be fast, not just to most common ones. And I think this is a perfectly fair metric to measure by. Emacs, Vim, BBEdit, and Sublime Text are all fast at everything they do, therefore I think it's fair to call VSCode a slow editor, even if technically it's average for a couple of features.
Granted, it's not a high-end workstation, just a laptop from 2016. But I don't think it's slow; when Vim first released it could have beaten the fastest supercomputer. Now of course that's a matter of perspective, but I hope I'm not the only one who thinks editing a package.json shouldn't make any modern PC sweat.
^ not just slower, vim annoyingly skips scroll events if they arrive too fast. My system is configured for 6-7 lines per WM_SCROLL, and I guess that adds to the problem. As a result I have to scroll slower (at 6600 box) for vim to scroll faster.
On editors in general: I’d like to have an editor as a library for which I could create modes/cli/behaviors myself. I believe that the sharpest tool is the one you sharpened yourself and for basic editing there is notepad2 and alikes. Vscode is much closer to that, but it’s too cumbersome to create/update personal extensions, so dumb vim hacks be it.
this is what emacs is and what makes everything else feel so poor by contrast.
I think 4coder[1] might be close to what you want. It's been popularized by being used in the HandMade Hero streams.
In IntelliJ command B will take me where something is defied, be it system library or in code base. Not perfect but close.
I’ve not had luck getting vim to do this.
Vim also supports the same LSP implementations that VSCode uses via Coc.nvim (https://github.com/neoclide/coc.nvim), which provides the same code navigation features that VSCode has, including jump to definition.
VSCode load times are heavily correlated to what files I had open last and what extensions I have installed that trigger because of my previously opened files.
When I freshly install VSCode on a machine, it feels blazingly fast. A couple months later when I've loaded up a few linting extensions? Not so much. Of course, the power of these extensions is why I'm using VSCode in the first place. I've yet to see an IDE that can integrate these types of features and not slow-down in some aspect, and VSCode does seem to try to stay as lightweight as possible.
VScode also often has notification prompts when I open it, either from extensions, or as popups generated from the editor itself. This doesn't add load time perse, but it does add to my mental perception of it's load time.
I also literally only use VSCode when I have to work with Typescript.
Try SciTE if you want something super lightweight!
There’s no point in them continuing to invest in fragmenting the dev community by developing 2 competing platforms now that they own GitHub so I’m not expecting to see any increased investments in Atom.
For me, plain vim is a great thing. My computer is hot enough without another electron app, and for that reason I've never tried VSCode (ium) -- I feel there is a vast amount I still have left to learn in vim, and although I've been using it for >10 years, I'm far from an advanced user. It just works, is fast, and matches my brain.
Microsoft also has a very, very long way to win back my headspace. I take it this new editor -- which I will give a quick go to -- doesn't come with telemetry and nonfree core code, for example.
I use emacs not because I'm a neckbeard, but because I can script it to do whatever the hell I like. I switch to vscode when I want to do something my emacs setup isn't yet good for (like, working with Typescript).
On the flip side, I use sublime text as a notepad replacement because it's that fast. I still use nano as my default editor for commit messages. Sometimes I use vim because that's what I happened to type to open a file.
This isn't a comment on helix editor itself...just that, it's a pretty saturated space and I'm keen to see something as novel as light table play out again, but only more successfully.