Earlier quoted context omitted.
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…
> Yes, there is a plugin to VSCode to do exactly that. Which plugin does that? Link?
How I'm still not using GUIs in 2019: A guide to the terminal
201–210 of 248 posts
Re: How I'm still not using GUIs in 2019: A guide to the terminal
#202> GUIs are bloatware. This is only true, firstly, when what you're trying to represent can be accurately, completely, and most concisely represented by plain text. That's actually a fairly narrow range, unless you're a programmer. And secondly, it's only true when you're not interested in using common interface conventions to teach your users how to use your program. While that can certainly be done -- the -? and --h…
> This is only true, firstly, when what you're trying to represent can be accurately, completely, and most concisely represented by plain text. That's actually a fairly narrow range, unless you're a programmer. You would be surprised. I encourage you to visit the lands of Emacs at some time. The reason Emacs feels like an OS is because it turns out that quite a lot of tasks can be accurately, completely and concisely…
> It's not difficult. It's just people have been trained to have a strong aversion to learning, where it comes to computers. Everything must be easier to use than your hair dryer, or it's garbage.
Damn right! It's crazy how much people are against learning even a little bit.
I don't know if it's either that greater adoption of computers is exposing this, or if people have actually become less willing to learn, maybe because of what they call "information overload" from consuming so much more information day-by-day through the web.
Re: How I'm still not using GUIs in 2019: A guide to the terminal
#203I'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…
> I'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. I'm working with vim on a ~5 million line C++ code base. Thanks to rtags[1] I've all I need: auto completion, goto definition, even semantically correct re…
Can you share your vim setup?
Re: How I'm still not using GUIs in 2019: A guide to the terminal
#204> GUIs are bloatware. This is only true, firstly, when what you're trying to represent can be accurately, completely, and most concisely represented by plain text. That's actually a fairly narrow range, unless you're a programmer. And secondly, it's only true when you're not interested in using common interface conventions to teach your users how to use your program. While that can certainly be done -- the -? and --h…
I agree.
I used to use git only on command line but after switching to a GUI I find I'm way more productive.
Re: How I'm still not using GUIs in 2019: A guide to the terminal
#205Earlier quoted context omitted.
Navigation is rarely the limiting factor in development speed. I'd take better auto completion / integrated tools over faster navigation every day.
I hope that language servers fully take off. This way, Vim and Emacs can gain semantic autocomplete & navigation. To be clear: it's not that they can't have that in principle, it's just that engines for semantic operations are difficult and expensive to write, so they were made primarily by IDE companies - and until recently, it meant they were tied to those IDEs. With that, the only remaining thing in which IDEs are…
I've never been a big debugger user, but I thought if you like LSP, you might be interested in Microsoft's analogous debugger protocol:
https://code.visualstudio.com/api/extension-guides/debugger-...
I imagine Emacs, vim, and friends could implement their own frontends for this, much as has been happening with LSP.
Re: How I'm still not using GUIs in 2019: A guide to the terminal
#206Earlier quoted context omitted.
What kind of navigation are you relying on that could not possibly work faster on a terminal? Horrible ascii graphs look horrible, but they are arguably more functional in that you can navigate them with your keyboard.
Navigation is rarely the limiting factor in development speed. I'd take better auto completion / integrated tools over faster navigation every day.
> Navigation is rarely the limiting factor in development speed
Here in spaghetti enterprise land it is. Quite often the biggest challenge to any given story is understanding the impact of a single line change on a code base.
And since we decided to split a single bowl of that spaghetti into nuget packages the more "primitive" tools like ctags are the best way to navigate the project, they don't care about pesky things like dll boundaries.
Re: How I'm still not using GUIs in 2019: A guide to the terminal
#207Earlier quoted context omitted.
> I'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. I'm working with vim on a ~5 million line C++ code base. Thanks to rtags[1] I've all I need: auto completion, goto definition, even semantically correct re…
Can you share your vim setup?
Regarding rtags? I am just using the plugin: https://github.com/lyuts/vim-rtags.
Re: How I'm still not using GUIs in 2019: A guide to the terminal
#208I'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…
For games, especially non-trivial ones, GUIs are fucking great. I couldn't possibly imagine writing game code without them. Anything else really visual, like CSS, and I need a GUI to feel productive. It's because the changes in the system are dynamic and cascade in unexpected ways. You make a box a little thinner and a heading flows to a new place and now the space between the heading and the image is off, etc. But I…
For CSS i find a text editor and two browsers live showing the changes to be most efficient. I have one or more live real browsers even with a IDE environment.
Re: How I'm still not using GUIs in 2019: A guide to the terminal
#209Earlier quoted context omitted.
This is why defaults matter. People sometimes downplay changes with "well, you can just tweak it if you don't like it", but in the long run tweaking the install every time is effort. Especially when you're working on non-internet connected machines. It's why I get annoyed when for example Ubuntu stops shipping the ability to burn DVDs on the install disk.
The default vim config is pretty weird: incremental search is off by default for some reason, I think it still defaults to using tabs for indentation, it doesn't change the working directory to the current file's.
Change working directory seans like the most stupid idea i ever heard... That would make:
vim module/code.cpp
:make
Re: How I'm still not using GUIs in 2019: A guide to the terminal
#210Earlier quoted context omitted.
Do people write programs that work like that anymore? I guess there is Linux's make config, but make menuconfig seemed so much faster. Basically, text adventures for doing productive tasks, doesn't sound very productive to me, but I'd love to be wrong.
TUI text editors, debuggers, pagers, music players are still very much used, if maybe not very actively developed. I guess even style escape codes would break line printers? This would discard a vast amount of tools I personally use daily. I would be happy to receive UNIX-philosophy arguments, but until such tools that bring the same functionality appear, TUIs are often the best of all worlds for me.
Most of the debuggers I use would be fine with a line printer, at the level of sophistication I'm capable of using them. A pager would be ok, as long as you're using more and not less.
I use plenty of interactive tools in a terminal, but almost all of them are screen oriented, very few are line oriented.
I would say the distinguishing thing to make something usable on a printer / a real teletype is that the paper only moves in one direction.