Everything up to and including spell checking, yes. In fact none of those first items are remotely unreasonable to do in a terminal, rather surprising to see them being used as arguments against the terminal.
Emacs also exists which runs in the terminal mostly (I only miss image rendering personally).
Collaborative editing is something I don't do much of but would guess there's a neovim plugin which could be used for backend sync.
Interacting with your issue tracker depends on the issue tracker software you use (flat file would work for example, Jira has unofficial clients, etc).
I've used IntelliJ plenty, and it's pretty bad at most of those tasks. Using the git CLI is much better for version control than the Jetbrains GUI wrapper; using Docker itself rather than a wrapper is much better for containers; etc etc. I'm sort of amazed the question of "can you do version control in a terminal" is even being asked... That's where git originated! That's the git team's primary development focus even today!
"Can you run multiple static analyzers simultaneously"... That's sort of the point of *nix systems: multiple processes running simultaneously. Using the shell is of course going to allow that, especially with something like tmux!
Most of the editor questions were also answered by my original post (and the answer was yes).
> Using the git CLI is much better for version control than the Jetbrains GUI wrapper
For some things. But for reviewing activity in git, and tracking changes across time, doing it in the terminal is unproductive and sucks. (e.g.: 10 levels deep of git blame)
> That's sort of the point of *nix systems: multiple processes running simultaneously. Using the shell is of course going to allow that, especially with something like tmux!
I meant getting a consolidated list of from them, and also having the ability to run corrective actions.
> Most of the editor questions were also answered by my original post (and the answer was yes).
Sure, but how much crap do you have to memorize? It's not a unified experience. It's a duct-taped Frankenstein where every subsystem works differently.
> For some things. But for reviewing activity in git, and tracking changes across time, doing it in the terminal is unproductive and sucks. (e.g.: 10 levels deep of git blame
The shit I've seen IntelliJ users do in git repos is insane. Somehow they create merge commits between their local branch and the origin version of their branch. They've lost changes, rewritten history, all sorts of shit, with 0 understanding of what or why. I'm guessing the warnings come as a pop-up and people instinctively just click ok without reading.
> Sure, but how much crap do you have to memorize? It's not a unified experience. It's a duct-taped Frankenstein where every subsystem works differently.
From your replies it's pretty obvious you have made up your mind. But what you are describing is my exact experience with JetBrains. The good thing about JetBrains tools is that their language analysis stuff is truly state of the art and significantly better than the equivalent LSP stuff out there. Apart from that everything is a Frankenstein setup that works differently.
In vim, all those plugins are just splits. So I can navigate between them with just ctrl+w->h/j/k/l (most people rebind to ctrl + h/j/kl). Each split supports the vim hotkeys by default, because that is the design of vim.
In intellj it's an incoherent mess. Every pane has some weird fucking hotkey that makes 0 sense. You cannot just go "select the pane on the left). The hotkey is ctrl+shift+alt+7 or something insane, to the point where it's not worth it and you just need to click everything.
Sure, but how much crap do you have to memorize? It's not a unified experience. It's a duct-taped Frankenstein where every subsystem works differently.
IDK, my experience with JetBrains is it's leaky abstractions all the way down, outside the core edit/refactor features. Using JetBrains Git without knowing git... I mean, I've seen people do it, but they seem pretty frustrated and confused when things go wrong.
I'd rather just learn the underlying tool once, rather than the underlying tool and also the leaky wrapper around it too.
>> Using the git CLI is much better for version control than the Jetbrains GUI wrapper
> For some things. But for reviewing activity in git, and tracking changes across time, doing it in the terminal is unproductive and sucks. (e.g.: 10 levels deep of git blame)
Magit[1] in Emacs is quite okay. It doesn’t feel duct-taped. I haven’t used fugitive[2] in Vim but that’s a thing that exists too.
It's not only some rando on the internet. There's always that one co-worker with a wannabe-vim-hacker setup, that you have to help occasionally with some real work task and nothing in their setup ever works effectively (bonus points for only using DVORAK). After showing them how much easier things are with autocompletion in intellij, next week they proudly show their latest installed emacs-plugin, that only does half-assed keyword completion, without being aware of variables, imports and the program structure. Such a waste of time. Lately I've started to just refuse cooperating under such circumstances, unless they truly show they know their tools.
Mastering the commandline is of course still important, just please not for editing code.
If you want half-assed keyword based completion, you don't need any plugins at all (e.g. ctrl-n in vim).
And if you install a proper plugin that uses language servers, you're at the same level of VSCode, which I'm pretty sure is the most used editor by a wide margin.
Your rant sounds more like you're more annoyed by "wannabe-vim-hackers" than any actual limitations of the tools.
Not OP, but to me, software that requires installing multiple plugins and extensions on top of it and requires much configuration in order to be useable is basically "unfinished software". It's 2022. Software not just has to work out of the box (or out of the download), it has to be packaged with everything needed to actually use it. It has to come fully configured for the most common use cases, or be able to fully configure/adapt itself at runtime. The days of sitting there installing plugins and tweaking settings and looking up how to configure it to do Common Use Case Xyz should be long behind us.
For example browsers. Whenever there is a Must Have extension that basically everyone downloads and installs, we should not be saying "See! It's great that software has plugins and extensions!" We should be saying "The development team totally missed this."
To be honest, VIM doesn't require plugin installation to be fully functionnal.
The main problem with VIM is that nobody reads the documentation, and jumps directly trying to configure vim to imitate what they experienced with other softwares.
Most VIM users never understand VIM philosophy and inner mechanism supporting it. They just try to bend VIM into another graphical code editor.
It's like the meme about "exiting vim". It is pointless. Once you understand VIM you never need to exit it. Just Ctrl-z or use neovim terminal if needed.
The best challenge i was given by VIM guru, when i was asking help installing dozen of plugin, was to read the vim doc (:help) and just use for 6 months a VIM pure vanilla, without any plugin and minimal vimrc.
After more than 20 years using VIM daily, i just understood i never learn how to use VIM and were just an adept of CARGO-CULT, victim of mass spread anti-pattern.
I guess you could shell out to check for errors (for example), but isn't it in general nicer to get error messages as you go? Or how about actually intelligent autocomplete? Stock vim simply cannot do those.
What are some examples of plugins people commonly use that you think are useless?
I'm a sysadmin, and most of what I do (editing config files) is very efficiently done in nano.
Edit a vhost in apache/nginx.
Change a port number on a service.
edit rc.conf,
etc...
But I've discovered that by using vim macros, the tedious parts of using nano became easy and FASTER then nano.
Let's say you have to declare a bunch of IP's and you can't just type a range, you have to type out each one.
In nano: copy/paste each line then backspace to change the last octet.
TEDIOUS
In vim: write it once
record a macro of doing it a second time auto-incrementing the last octet.
now type: 199@w (or whatever letter you stored that macro in)
BOOM, 199 new lines have been input.
That 1 use case, made me use vim more.
Then I got better.
Then I got faster.
Now I can edit those same old config files faster then I once did in nano.
Please believe me, it's worth the learning curve. There is SO MUCH MORE available then just editing some config files.
Nano is fine. There is nothing wrong with nano.
If you only edit (config) files a couple of times a year, then maybe you won't want to switch. But I'm so much better at vim then I was before, I use it to do ALL my writing and editing.
Literally nobody is asking you to use vim. In fact, I don't recommend it to newbies, and warn that a lot of setup is involved. But I am 100x more productive in it than any other IDE, or seen anyone else with an IDE. It works for me. It may not work for you, that's fine.
You might be well served by not seeking out the company of vim users then. There’s better things to spend this life on than arguing about editors, plugins, and keybindings.
Yes there's a learning curve but once you've learned that it can be more efficient. For some people key bindings are easy to remember. For others a menu is better even though it's slower to navigate.
But clearly it isn't for you. It isn't for me either, though I did try. I just don't really have a reproducible workflow (I'm not a dev). In that case the setup overhead does indeed not pay off. If you spend every day in an IDE I could definitely see it working out.
Even on my work mac I often prefer using the cli for things that others would do in the GUI. They find that archaic and overly complex. I find it simple and faster. Opinions vary :)
I've been using Vim since college and nothing else and I could retire at 33 from my FAANG RSUs so it worked for me. Have fun "getting shit done" in VSCode or whatever. Honestly if someone told me they hated memorizing commands or configuring their environment in an interview I would see that as a big red flag, but you do you.
Most of it unvested stock and not enough to retire at 33.
Thanks to the great people running the economy, if you get to survive all layoffs taking place and vest that money, you'll be able to buy an avocado toast made of soylent green in the metaverse of the future. You will own nothing and be happy.
Yeap, what the other guy said. I prefer byobu to vanilla tmux, but the idea is the same. Create a byobu session, detach, give it group permissions, group collaborators attach, enjoy the nano editing party. :)
The commandline is more powerfull than an IDE due the very logic the things work, and has much higher skillcap. You apparently have some skill in an IDE, little skill in the commandline, and draw the incorrect conclusion that the IDE is better.
- Edit code
- Autocomplete
- Navigate code, find references, go to definitions
- Run your code
- Debug your code
- Test your code (including running a specific test)
- Profile your code
- Run multiple static analyzers simultaneously
- Use version control and annotate code using version control
- Do all that remotely or with containers involved
- Query a database and get results in a tabular format
- Spell checking
- Have collaborative editing
- Work with issue tracker tickets
- And more...
The sad reality is that for 99.9% of people using vim is reinventing the square wheel to produce a worse development experience and inferior code.