Coders or lemmy, what editors do you use? Is it worth learning a new one?
-
Yeah I agree, I like that aspect too!
-
Ahhh nice, I have thought about trying out Kakoune as it supports plugins. Do you use many plugins/find them useful?
Helix does have a pipe command also.
-
-
-
I just use Vim out of habit. I've been using it as my main text editor since I was like 13 or so, maybe more like 10 I don't really remember. It works perfectly well for the vast majority of my use cases. I use Jetbrains IDEs if I feel I need the power of a full IDE. Jetbrains has an IdeaVim plugin if you want it to be a modal editor, or if your fingers are accustomed to Vim keybindings.
-
VS Code with your favorite plugins is pretty fantastic for any editing in my experience. I've tried others and they do seem to work well, but not well enough to warrant switching, and they often come with quirks that are just annoying enough to make me want to switch back.
I suggest trying others to know what's out there, even if you ultimately end up back on VS Code.
-
-
Ghidra seems intense when gdb is right there. Lol. What advantages do you see in using Ghidra on your own code? It seems interesting.
-
Amateurs. I manipulate the delicate flutters of butterfly wings.
-
+1 for Helix. Selection then action always made more sense to me than action then selection.
-
cat << EOF # [[content here]] EOF > file.txtOn a more serious note: Neovim for quick file-edits, doom-emacs as my IDE.
Doom-emacs does most of the stuff you are already using out of the box, is highly configurable and it lets you use vim-keybindings. It's also free (as in freedom) software!
-
Have you tried
ed? -
Sublime text, vi, eclipse, emacs depending what I'm doing
-
-
Have you ever tried Rider? I found it such a pleasure to use in place of Visual Studio and I've never looked back.
Any times I've loaded VS since it just feels so slow in comparison.
-
Input speed is not "just" input speed. Note: I'm not about to argue for or against modal editors, I just want to answer: why is input speed really really really important, when (we agree) its not a big percent of total time.
5min at 80mph over a bumpy dirt path, ripping around turns is very very different than 5min of flat smooth straight driving.
A senior and junior dev could spend the same amount of time to rename a var across 15 files, move a function to a new file, comment out two blocks, comment one back in, etc. But. When I try to have a conversation while they do that, or when I change my mind and tell the junior to undo all that, its a massive emotional drain on them... because (if they're fast) they're driving 80mph over a crappy dirt road.
The input speed isn't a big deal because its a large chunk of time, it's a big deal because pausing a conversation/mental thread for 5 seconds while you wait for some typing to finish is incredibly disruptive/jarring to the thought process itself.
Those mental pause-and-resumes cause untold number of bugs, and THAT is where the real time sink happens.
If you're already at the point where there's no "pauses in the conversation" then I'd agree, there's not much benefit in increasing input speed on its own. BUT there's almost always some task, like converting all vars (but not imported methods) in a project to camel case from snake case, that are big enough to choke the conversation even for a senior dev. Increasing input speed is often decreasing how often the conversation gets interrupted.
-
-
Fresh from university I found a job with terrible keyboards. After about 4 months I started to feel constant pain in my wrists. I then switched to vim.
And it solved my wrists issue. But also, I discovered a way to edit text that was so much optimized fat beyond my expectations.
I wrote this article for people that would like to familiarize with vi keybindings.
https://yannesposito.com/Scratch/en/blog/Learn-Vim-Progressively/
-
I personally enjoy using pycharm and vscode, depending on what I'm working on and what tools I need/want.
-
I get this, but an IDE should be invisible and grow as you ...
Why not "I get this, and an IDE should ..." ?
I don't think your idea goes against the idea of watching skilled devs to know what you are/are not missing
