I'm not being funny but why do people prefer writing out lines of command line text versus right click and select in two clicks?
For many people, writing out the command text is faster. Fantastically faster, when you take advantage of the efficiency improvements like tab completion, readline hotkeys, aliases, scripts, etc. And you don't lose time from whatever you do before and after, by taking your fingers off the keyboard.
How I'm still not using GUIs in 2019: A guide to the terminal
191–200 of 248 posts
Re: How I'm still not using GUIs in 2019: A guide to the terminal
#192Earlier quoted context omitted.
Of course, you can bind terminal commands to keys in VSCode (or virtually any other environment) just as easily. Personally I think these terminal vs. IDE discussions always revolve around straw man arguments and mythical divides. I can chain 5 unix commands together and use my IDE to navigate through code with my mouse. I don't have to choose one or the other and then feel superior about excluding a whole branch of…
> Of course, you can bind terminal commands to keys in VSCode (or virtually any other environment) just as easily. But what if those terminal commands need to interact with your editor? How would you set up a simple VSCode key bind to take the currently selected text, run a shell script using the selected text as input and then replace your selected text with the output of the shell script? With Vim, this kind of men…
Yes, there is a plugin to VSCode to do exactly that. But it doesn't matter. Different software has different features and all features are possible depending on what you care about. Vim is Vim. Vim doesn't have features because of some GUI vs. command line distinction -- it just has different features because it's a different product. Nothing stops a GUI IDE like VSCode from having those same features. And nothing stops you from using GUI windows and mouse in a desktop version of Vim.
Re: How I'm still not using GUIs in 2019: A guide to the terminal
#193Earlier quoted context omitted.
Using the terminal at least makes you proficient with the lowest common denominator of tools. I know I can SSH into any random machine, and edit a config with the copy of vi/vim it has, even if it doesn't have my fancy plugins. And if I get a new machine, all I have to do is install my tools via Apt/Brew/etc, clone my dotfiles repo, and run an install script.
> I know I can SSH into any random machine, and edit a config with the copy of vi/vim it has, even if it doesn't have my fancy plugins. The android phone I'm currently messing around with had neither vi nor vim... Yes, knowing the lowest common denominator is great. But doesn't make a great dev environment. OP is describing how to set up a customized one for exactly that reason.
Re: How I'm still not using GUIs in 2019: A guide to the terminal
#194Earlier quoted context omitted.
> Of course, you can bind terminal commands to keys in VSCode (or virtually any other environment) just as easily. But what if those terminal commands need to interact with your editor? How would you set up a simple VSCode key bind to take the currently selected text, run a shell script using the selected text as input and then replace your selected text with the output of the shell script? With Vim, this kind of men…
This is what I mean about straw men and mythical divides. Yes, there is a plugin to VSCode to do exactly that. But it doesn't matter. Different software has different features and all features are possible depending on what you care about. Vim is Vim. Vim doesn't have features because of some GUI vs. command line distinction -- it just has different features because it's a different product. Nothing stops a GUI IDE l…
Which plugin does that? Link?
Re: How I'm still not using GUIs in 2019: A guide to the terminal
#195I'm a game developer mainly writing/reading/debugging C++ on a codebase that's well over a million lines of code. As with most game-dev I'm developing almost entirely using Visual Studio, and I can't imagine trying to navigate code using a terminal based editor. Maybe it's just because this is what I'm used to, however I just don't see how some of the tools would even be displayed in a terminal (parallel stacks windo…
Learning a text editor plus ctags (etags) plus how to integrate your text editor to N compilers (syntastic) will make you equally proficient without fiddling with one IDE for each language. It sounds lame early in your career, but after a while, switching between C++, java, JavaScript (ok this one requires a little more involvement because the browser is the compiler of sorts), typescript, etc is very easy. When you…
Re: How I'm still not using GUIs in 2019: A guide to the terminal
#196I always find the benefits of portability to be a rather funny one: It's always immediately followed by 800 lines of dotfiles that do an incredible amount of customization. The IDE vs. vim/emacs purist debate is always crazy to me. There are some places where IDE's are almost certainly better: Java in a large project in IntelliJ has to be 100x better than in Vim. For new languages or languages where there isn't subst…
I'm not seeing a contradiction, given that config files are trivial to move around. Yes, I have a possibly excessive number of dotfiles, but they work fine on everything from Arch Linux to Termux on Android to OpenBSD and are just a clone away.
Re: How I'm still not using GUIs in 2019: A guide to the terminal
#197Earlier quoted context omitted.
It's faster, which I discovered after switching to it for Javascript/Typescript development. Also has better autocomplete plugins. Vim plugins just don't seem to have taken advantage of the async features yet.
Most of the nvim autocomplete plugins work on vim too.
Re: How I'm still not using GUIs in 2019: A guide to the terminal
#198Earlier quoted context omitted.
On the other hand I have worked on code bases in the 50M lines of code that would bring VS on its knees; people ended up just using it as a glorified text editor. Note I'm not knocking down on IDEs; as an Emacs user I would love reliable semantic indexing and navigation, but all the solutions that I have tried (rtags was the best) consume a lot of time and CPU indexing and switching branches often forces a rebuild. C…
I have nearly the same setup you do but recently switched from ag to ripgrep (with deadgrep emacs plugin). It's a bit faster and allows filtering by files, etc. You may want to give a test
Re: How I'm still not using GUIs in 2019: A guide to the terminal
#199Earlier quoted context omitted.
It's common to think that the goal of UI design is always about being as intuitive as possible, to minimize potential learning curves until they're basically non-existent. I don't think that's the only worthy goal, though. Intuitiveness and power are often opposing goals. You often see a way to make an interface more powerful, let the user work more effectively and/or efficiently, at the cost of intuitiveness and hav…
I largely agree with your post, but disagree with the idea that intuitiveness and power are often opposing. I believe that intuitiveness always helps with power. It’s just that the audience when defining intuitiveness shouldn’t only be limited to newbies. Unfortunately, we seem to conflate “intuitiveness” with “intuitiveness for newbies”. However, if you’re creating new power features, those features will always be b…
> Unfortunately, we seem to conflate “intuitiveness” with “intuitiveness for newbies”.
I either can't think of another kind of "intuitiveness" or we have different ideas of what constitutes a "newbie".
> However, if you’re creating new power features, those features will always be better served if they are more intuitive for the intended users, I.e. power users. (conversely, they will be worse off for power users if they are designed to be intuitive to newbies).
Ok, yeah we have different ideas of what's a "newbie", and apparently what's a "power user". I think your definitions depend on how much experience they have with computers in general. Actually, no. I think it depends on what kind of programs a user has experience with. Like users of GUI are newbies and users of CLI are power-users. That's the only way making something intuitive for power users makes sense. After all, making something intuitive is about following existing conventions, so we're differentiating "newbies" vs "power-users" based on the conventions they follow. Sorry, if I misunderstood you here.
For me, "newbie" and "power user" do not imply anything about their experience with other related systems, only with the system that is the object of conversation. In that respect, by definition, you can't make something intuitive for power users. Every person on first touching a system (a software program or otherwise) is a newbie, regardless if that newbie is not a newbie anymore in another system.
A "power user", for me, is someone willing to accept a learning curve to best do whatever a system is designed to do. That basically means someone that is willing to read a manual of what he uses, though they can also do other things like practicing and reading the source.
So, on first touching a piece of software, everyone is a newbie, and some become power-users.
Designing for intuitiveness vs power is about favoring those that wouldn't be willing to study a little and become power-users vs those that would.
When I say that, I don't mean that power will always come at the cost of intuitiveness, but I do mean that some design decisions could be made that favor power at the cost of intuitiveness.
An example of this is vi's modal editing and its normal mode language. If you put someone that's never touched a computer before in front of 2 computers, one with Windows's notepad and the other with vi, with no documentation whatsoever of either, which will he be able to use most effectively first? notepad. The user just needs to press any letter key and he'll see the characters appear on screen. He'll be writing paragraphs in seconds (if his lack of touchtyping ability wasn't an issue). In this respect, vi's modal editing is not intuitive. It's a cost vi paid for implementing a mode that allowed a whole keyboard's worth of buttons to communicate to vi different editing and navigation procedures most efficiently.
> I believe that intuitiveness always helps with power.
With the context of the above, getting rid of normal mode would make vi more intuitive, but it would certainly not help with power.
Re: How I'm still not using GUIs in 2019: A guide to the terminal
#200Earlier quoted context omitted.
For many people, writing out the command text is faster. Fantastically faster, when you take advantage of the efficiency improvements like tab completion, readline hotkeys, aliases, scripts, etc. And you don't lose time from whatever you do before and after, by taking your fingers off the keyboard.
With wireless mice you can move your hand nearer than they keyboard and even with tab completion navigation between files is hard compared to just a couple of clicks?
As far as what is considered to be hard, it depends on the individual.
For many of us that spend a great deal of time on the command line, many multi-step activities, including those related to file manipulation, become like a single action. Consider the difference between touch typing and hunting and pecking. To an experienced secretary, the phrase "to whom it may concern" can become a single action, executed by the fingers without any thought whatsoever, while for an inexperienced typist that's 20 individual actions. Similarly, a whole series of file manipulations, git actions, SSH actions, become hardwired into our muscle memory and we don't even think about the steps. We just decide that we're going to do something, and let our fingers take care of it. This is much easier and faster then manipulating a GUI with a mouse.