- vim, neovim, Emacs configured with LSP - https://git-scm.com/ - http://aspell.net/ - https://github.com/tmux/tmux - https://github.com/dbcli
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).
- https://www.emacswiki.org/emacs/JiraMode - https://marketplace.atlassian.com/apps/6398/jira-command-lin...
DataGrip wipes the floor with pgcli
How do you find duplicate code with that setup?
"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).
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)
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.
tig is great at that. "tig blame" and "," is the way to go for researching the history of some code.
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.
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.
But I think you mean how do I refactor duplicate code?
lsp-mode (https://emacs-lsp.github.io/lsp-mode/page/main-features/) for smart code navigation or projectile-replace (mentioned in https://with-emacs.com/posts/tutorials/search-and-replacemen...) for dumb replacements.
LITERALLY BUILTIN: - Edit code - Do all that remotely or with containers involved - Spell checking
ALE: - Autocomplete - Navigate code, find references, go to definitions - Run multiple static analyzers simultaneously
DISPATCH: - Run your code - Debug your code - Test your code (including running a specific test) - Profile your code
FUGITIVE: - Use version control and annotate code using version control
By the end of the first sprint you'll have carpal tunnel syndrome.
Ctrl-this, Ctrl-that... Lisp and vimscript... h, j, k, l... fuck you! I want to fucking do my work, not solve a 10,000 pieces puzzle or memorize 100,000 different fucking things that follow no discernible pattern.
It's an excuse to spend all day configuring dotfiles and talking about dotfiles. Fuck dotfiles with fire from a volcano. Fuck vim AND emacs.
And if I am in a SSH session, then I'll use fucking nano. Yes, nano. Any problem with nano? I don't care. At least you can exit the fucking thing. Fuck it.
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.
192.168.0.100 192.168.0.101 ...etc... 192.168.0.199 192.168.0.200
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.
printf '192.168.0.%s ' {100..200} > fuck_vim.txtBut 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 :)
You could memorize the entire Sacred Scrolls from Planet of the Apes, that doesn't make it practical.
See, this is the shit you have to endure from vim users.
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.
It’ll take less than 5 minutes to install a Neovim-based IDE-like environment; batteries included:
bash <(curl -s https://raw.githubusercontent.com/lunarvim/lunarvim/master/utils/installer/install.sh) echo "Fuck vim" > /etc/motdFor 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."
I recommend learning about Unix and the associated philosophies - you sound like there’s a lot more growth in your future!
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.
What are some examples of plugins people commonly use that you think are useless?
Mastering the commandline is of course still important, just please not for editing code.
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.
- 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.