Vim has plugins that seem to address most of what you note. Nerdtree gives you see semblance of a graphical UI. I rarely use it since installing fzf and getting better at using buffers. It's much, much easier to press a shortcut and type a partial name. I use Nerdtree when I need to browse the hierarchy. I also previously had ranger integrated into vim which is really nice Vim has tons of user extensions. Yeah, the p…
Why don’t we have good code editors?
51–60 of 74 posts
Re: Why don’t we have good code editors?
#52Earlier quoted context omitted.
> 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…
> 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.
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
Re: Why don’t we have good code editors?
#53Earlier quoted context omitted.
No
OK... what is the difference, as you see it?
The real power of these is twofold. First you can build muscle memory that lets you move around a text file, precisely select text, and edit the text as fast as you can think. Secondly, all of the commands used to edit text can be recorded into a macro, letting you systematically and repeatedly edit text in a way more powerful than find and replace with high-level regex support (which vim and emacs also have). An example macro could be jump to the next define keyword, then jump to the next set of parenthesis (which would typically be a function parameter)and then reverse the parameters of the function. This macro can be repeated to reverse the parameters of every function in a file, as well as in many files in your workspace. This is fast editing of the semantic structure and convention in a workspace. While this is a contrived example, This editing functionality is very useful for many tasks like re-arranging the structure of each object in a large JSON document to fit to a new schema, refactoring code as well as any task that requires automating many repeated edits. Other editors and IDEs have macro functionality, but without the composable structural editing commands in vim (these are also in emacs) you don't quite have the same kind of power. These kind of edits would otherwise need to be done by a separate script, but the interactivity of NORMAL mode commands and macros let you know that it works for one case, repeat the macro individually and check each case as you go to make sure that it worked, and then edit the macro if the command macro needs to be modified for new structures.
Edit: I forgot to mention that normal mode is also very fast and simple which is much more convenient than CTRL-P for a command. 'w' for moving to the next word. 'b' for moving to the previous words. The command chaining is also relatively consistent for editing as well with 'ciw' for 'change inner word' to select the entire word the cursor is on delete it and then enter insert mode and 'ci('for the same but selecting all the text within the first set of parenthesis that contain the cursor. Many vim emulation plugins don't even feature these commands and only have basic modes and hjkl cursor movement.
Re: Why don’t we have good code editors?
#54Earlier quoted context omitted.
> 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…
Re: Why don’t we have good code editors?
#55Earlier quoted context omitted.
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…
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.
So apart from lacking the visual feedback of scrollbars etc, sounds like emacs is the same.
Re: Why don’t we have good code editors?
#56Earlier quoted context omitted.
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 y…
Vscode fan myself, but that feature came to vim first
Re: Why don’t we have good code editors?
#57>a terminal does not a pleasant user experience make Author doesn't establish this, just takes it as a given. I wonder what features terminal emulators/editor programs would lack that are afforded by GUIs? I consider the terminal text editing experience far more efficient
Efficient is not necessarily a pleasant user experience though, is it? I am not downplaying anyone's preference of one over the other. However, a better UX would mean that the initial learning curve to start with something should be low, which isn't usually with terminals.
Depends how you define better. If you do something very often a steep learning curve with long term payoff can be the better UX seen as a whole.
I use almost only VSCode mind you, but I can see the argument here. I know a bit of vim and it is practical when configuring servers via PUTTY. For bigger projects I find it very lacking.
Re: Why don’t we have good code editors?
#58> In all seriousness though, a terminal does not a pleasant user experience make. 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…
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...…
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...
Re: Why don’t we have good code editors?
#59Earlier quoted context omitted.
> 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…
> 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.
Re: Why don’t we have good code editors?
#60Earlier quoted context omitted.
Basically, having two ways of interacting with the file: one mode lets you execute commands to edit the file, the other mode lets you type like in a typical GUI editor.
While editing a file in VSCode, I can press CTRL+P, which opens a small command box in which I can type to find a command with autocomplete - like a souped-up version of vim's "colon prompt" (not sure what it's called!) - does that count?