FWIW it is 2 key strokes in VSCode (ctrl-g, then the line number or -n to index back from the end of the file) out of the box. Ctrl-p takes you to any fuzzy-matched file in your workspace.
My point is that VSCode has a lot of shortcuts too - you don't need to use the mouse if you really do need those extra couple of seconds time savings in your 8 hour work day in order to meet your deadlines. But on the plus side you can use they keyboard or the mouse as you see fit - best of both worlds.
If you really are working in such a sweatshop where saving a couple of seconds a day is something you need to think about, then you have my pitty and condolences! At least for me, not every single waking second of my work day is spent hammering out code - I am probably only actively typing in new code perhaps 20-25% of the time max with the rest going on reading existing code, stepping through a debugger, dealing with tickets/bugs, running tests, doing emails, meetings etc etc.
For me, something like VSCode offers some nice visual benefits, e.g. the minimap is super useful, subtle indentation lines, line-length rulers, intellisense popups near where I am actually looking, spelling squigglies etc. I would not be surprised to learn that vi/Emacs can do the same, but if you are adding all that to a text mode editor, why bother and not just use a modern visual editor and just be done with it? Just muscle memory?
The reason to not having to move your fingers/arms much is not about time. You just stay in the zone longer, you have less possibilities of distractions... It is about comfort and not disturbing the flow.
It's the same with music (wether is jazz or blues at least). Good intrumentists just don't move their hands much, lest their instrument goes in the way of their improvisation. 60% of the time, our job is quite boring, so make sure you really enjoy the 40% that's left.
Is that really something you use all the time? I tried to switch from emacs to vscode in 2017, but in practice the minimap didn't do that much for me. Nor did the graphical file view to the left. The emacs experience is just too fast and good, even though it means I need to carry my customizations with me everywhere to get those intellisense popups and spelling squigglies.
VSCode is fast - certainly as fast as my brain. Atom was crap IME but MS have done a really good job regarding performance for VSCode. Start-up time is a bit slow, but you only do that once when you reboot every few days/weeks/months
So apart from lacking the visual feedback of scrollbars etc, sounds like emacs is the same.
I'm also not really convinced about the "hands on the keyboard" argument... What percentage of the time that you work are your hands actually on the keyboard and ready to input? Are they on the keyboard right now? Because that seems like an uncomfortable way to sit at a workstation. I also don't think it takes very much time to switch between the input devices unless maybe you don't have practice with that workflow.
Have you ever used emacs? If not theres a mode called ace-jump, which I'm pretty sure beats every interaction with a mouse to get to a certain point within a document. I'd wager that, if we'd start at the same time, I'd be at that point before you actually touch the mouse with the hand that you just lifted. Honestly, it's worth checking out. There is a lot of things that emacs and vim are brilliant at, they had tens of years to figure things out after all...
There are some interactions where switching to the mouse and back is faster; things like drawing and navigation through irregular shapes (I.e. “not grids or lists”).
Whether that difference is important to you or not is far more about your specific circumstances than anything else. Comfort is important also.
Of course they're not on the keyboard while I'm exclusively reading. But while I'm in vim, my hands certainly are on the keyboard nearly at all times, resting on the home row.
This is similar to the way a mathematician will often ‘read’ math with a pencil and paper, or a musician will ‘read’ music with an instrument in hand.
When I’m reading prose, I often don’t have either a keyboard or a mouse, but that’s a very different operation (uses different parts of the brain, etc).
I agree with taking advantage of a modern UI, all programs could benefit from advancements. I find the article was written with little research or thought put into what is available on the terminal.
IMO you shouldn't have to do "research" to setup your editor or even simply to use it effectively. With VS Code everything that you need is already integrated and clearly stated - Ctrl+Shift+P to find any command Ctrl+P to open any file in your workspace (no file browser needed). When you want to expand - you have the integrated Extensions marketplace.
And all things are accessible via the keyboard in Code as well as in my preferred desktop environments (XFCE or Windows - macOS, not so much, which is why I don't prefer it). Having the mouse to fall back to is not a bad thing, particularly when you visit someone else's station where they might have configured their editor or desktop differently than you.
If someone gave you a different 500k+ file codebase to maintain, I'd bet that you'd need to browse around a bit before you got familiar enough with things to not need a file browser.
The command pallette in VSCode is pretty nice too, but I don't recall having quite as nice an experience using it. I still do my professional work in VSCode, though. Emacs is for fun.
Vscode fan myself, but that feature came to vim first
Have somebody who uses emacs show you sometime how they navigate the file tree. The "modern UI" graphical representation with a little icon for each node of the tree isn't an advantage.
But there are things which a terminal can't to. The article mentionedd the ability of IntelliJ (and derived IDEs) to show the code of functions in a mouse over tooltip. A proper tree to show hierarchy of code. The ability to click and browse and so on. They are really useful things when exploring a code base.
Claiming the terminal doesn't do these things demonstrates the lack of time invested time to learn or discover what's available. Again to each their own, but it seems to be the author claims there are no good editors when they simply are just too eager to "open up vscode".
But there is a massive difference while browsing code between the IntelliJ style editor and all the vim plugins in the world.
I mean, I use vim too. Any project that is sufficiently large benefits greatly from a file handler, there is nothing to be proud about for remembering each and every subfile. Why not just put it right there in view? You can't possibly argue it somehow rots the brain; i mean we aren't even talking about writing code here, it's just accessing files.
https://www.linux.com/tutorials/vim-tips-basics-search-and-r...
In Notepad++ it's easier to do for me... I use Find & Replace VERY frequently as I inherit apps developed by others, Some developers don't need to use it at all because they work on a Single Page App...
We're truly in the era of "If it works for me it's great for everyone", which is truly a bad posture to adopt, because now developers dictate features based on opinion rather than research, polling, testing and facts like they used to in the early days. This is why apps, like Android dialer become annoyingly dysfunctional, because it's made and tested on a small group who have 2 hands rather than also on people who only have one hand (and can't afford 2 clicks to get to a keypad as easily).
CLI has been around forever in terms of development. I understand there are use cases where it's highly useful, but in a world where development should be getting LESS complex, it's a dinosaur that preserves job security because of a huge learning curve.
As an architect I frequently work with non-technical people, and using abstract tools to do my work only complicates my ability to get them to understand what I do. Things should be getting simpler, but they're not.
I'll take that at face value, and commend you on your programming knowledge. If you're actually a code jockey, let me intone:
Software architects are not architects. Software engineers are not engineers. Computer science is not science.
Yes, yes it does. At my fingertips I have access to every single tool and program without needing to clumsily navigate through folders or Finder, whatever it is. Moving my hand away from my keyboard to my mouse to check TS typings is biggest waste of time when I know how to get to any line in any file with less than 3 keystrokes.
> The way these editors achieve this is through graphical representation of the project hierarchy – the file sidebar
I work on a site which is part game engine, part marketplace, and part React application. I have never once used a file tree because I don't need it to understand the code. This isn't a flaw of terminal editors, it's classic PEBKAC.
Terminal editors don't suck. They require learning and discipline, something that some might argue is becoming a lost art in this field. In the days of "gluing modules together", maybe vim isn't for you, but it's for me and this piece contributed nothing.