Hacker News Reader

> I know how to get to any line in any file with less than 3 keystrokes

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?

> 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.

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.

> the minimap is super useful

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.

Yeah I use it all the time - seeing the "shape" of the code is great for jumping around quickly when you don't know the line numbers and it is quicker to look + click once then to find a string in the file instead.

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

If finding a string involves popping up a modal dialog I can understand navigating by the minimap. Finding a string in emacs is really fast - Ctrl-S, start typing the string, and you're there before you know it. The minibuffer is way better for this kind of interaction than a modal dialog is.

In VSCode there is no modal - ctrl-f then type (regex is supported) and it autoscrolls + highlights in the text, the minimap, and the scrollbar. No mouse (unless you want to) - you don't even need to press enter.

So apart from lacking the visual feedback of scrollbars etc, sounds like emacs is the same.

I use the minimap (in Atom, not VS Code) to quickly see touched lines for git purposes, locate errors I know exist due to changes elsewhere, quickly find merge conflict blocks, see search matches at a glance, etc. It can do quite a lot.

The mouse is not a "clumsy" input and there are plenty of situations in which the mouse allows more efficient usage than the keyboard like when navigating through 2D space. For example it is clearly more efficient to place your cursor at a certain arbitrary point in the document using the mouse than to navigate there using keyboard commands.

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.

> Are they on the keyboard right now?

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.

When I’m trying to understand code, my hands are absolutely on the keyboard. This is very common and quite efficient once you learn how to navigate using a code editor.

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).

> The mouse is not a "clumsy" input and there are plenty of situations in which the mouse allows more efficient usage than the keyboard like when navigating through 2D space. For example it is clearly more efficient to place your cursor at a certain arbitrary point in the document using the mouse than to navigate there using keyboard commands.

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 have been numerous studies on this, and the results are basically always: people don’t think that it’s faster to stick with the keyboard, but it is. Yes, even for people who are very familiar with the task, the keyboards, and the mice.

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.

I guess we can't all be 10x geniuses who have their codebase memorized. It's really not crazy to want to take advantage of modern UI, and the idea that you simply don't need to see a file tree is nonsense.

I never said memorized. I do believe if you truly understand your code however (and ours spans 500k+) then you don't need a file browser to know that components live in the "components" folder.

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.

You do have to memorize a ton of arcane key strokes just to get around in your editor though. I bet that time invested is a big reason why some coders hang onto terminal editors.

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.

>Ctrl+P to open any file in your workspace

Vscode fan myself, but that feature came to vim first

When I use emacs, I hardly have any shortcuts memorized. I just use smex, which has fuzzy matching for commands. When I wanted to open a file, I wasn't sure what command would do that, so I pressed M-x and typed "file." One of the suggestions was, "find-file," so I chose that one, and it gave me a prompt for which file to open, I entered the path in an interface that also had similar fuzzy matching, and I was ready to go. Afterwards, a brief hint told me the key command if I don't want to bother typing, "finf," but I don't really use it.

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.

> the idea that you simply don't need to see a file tree is nonsense

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.

I love using the terminal. And I mostly use vim and for raw editing hardly anything can beat it.

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.

NERDTree will give you file hierarchy, CoC will give you insane-levels of autocomplete that rival or beat intellisense and you can use keybindings to navigate directly to method definitions, typings, anything.

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".

Oh, I have vim with tons of plugins and use gvim for simpler discovery of some features I les softne use, thus know that vim isn't strictly bound to the terminal.

But there is a massive difference while browsing code between the IntelliJ style editor and all the vim plugins in the world.

> 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 fluff piece contributed nothing.

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.

Find and replace is laborious in VIM...

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.

> As an architect

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.

I prefer the terminal as well. Maybe he should just take the time to make a proper vimrc file and stop hyperventilating.