Live data from Hacker News

How I'm still not using GUIs in 2019: A guide to the terminal

lucasfcosta.com

211–220 of 248 posts

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#211
post #41

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

Incremental Search - This can be incredibly slow on large files and/or network mounted files. It can also interact with line wrapping and highlight search to slow vim to a crawl. So I think it makes sense to leave it off.

Tabs - That's the way god intended it. Stop trying to force your indentation width on me.

Stable working directory - This is how every text editor I'm aware of works. I can see use cases where you might want to change it manually or automatically, but I don't want to have to guess which directory I'm in every time I open a file.

Even some seeming no brainers like turning syntax highlighting on can be terrible because it doesn't work well with dark backgrounds or other random colour schemes.

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#212

Earlier quoted context omitted.

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.

Wow, thanks!

And it turns out, Emacs and vim do implement their own frontends for this - [0], [1]. My wish just literally came true!

[0] - https://github.com/emacs-lsp/dap-mode

[1] - https://github.com/puremourning/vimspector

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#213

Earlier quoted context omitted.

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…

> 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. Do you have some GUI for manipulating CSS with click&drag? Otherwise, isn't this use case handled by having an editor and a bro…

Slight tangent, but may be interesting.

I do a decent amount of CSS / HTML editing live in the chrome dev tools. I even sometimes move elements around by dragging them in the DOM tree UI. It can be a nice way of experimenting with UI design, as the feedback loop has less friction and can be much quicker, in some cases.

One workflow is to write out an initial sketch of the HTML structure, with little to no CSS. The first round of the styling is then done in the dev tools, tweaking until it seems ok, then copying those styles from the inspector stylesheet into my code and saving, and then iterating further as necessary.

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#214
post #56

Earlier quoted context omitted.

I feel most people that have used a command line workflow that need a GUI for debugging GDB's TUI is generally adequate even with large debugging projects. It's not a perfect 1:1 to the magic that Visual Studio gives you, but it is useful even with very large projects. Then again people who are terminal oriented usually use/look for other styles of debugging compared to people who have a solid IDE where the debugger…

The goal is not to stick to a particular style- it's to use the best tools for the job. why settle for gdb when there is VS Which is light years ahead. just like why use vscode when there is vim which is light speed faster?

While I agree on the "pick the right tool for the job" part, your comment makes me suspect that you have not had a look at GDB for very long (or at all).

I have to use the VS debugger at my workplace, and even as someone who has merely dabbled in GDB a bit, I recognize that it's so far out of VS' league, it isn't even funny.

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#215

Earlier 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?

> and even with tab completion navigation between files is hard compared to just a couple of clicks?

Since when?

Editor speaking, I can navigate / open files / select faster with keyboard than it would take to move the hand to the mouse. Not move the mouse and click, just in time it takes to switch the right hand I can launch three of four keystrokes, and that's enough to complete arbitrary operation in vim or Emacs. By the time I'd complete that op by clicking, I could do a dozen more from keyboard. Mousing is that slow.

Terminal speaking, sure, typing even portions of file names + arcane flags may seem a bit slower than pointing and clicking. But then I can type: | some-other-command --flags, and good luck doing that with mouse in reasonable time. And then, satisfied with my result, I can go back to the initial command and shove a "*" somewhere, and now I'm in batch mode, and with one Enter press repeating the same operation on a dozen or thousands of files. At this point, pure-GUI user would have to get on the web to find specialized software...

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#217

I 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…

Just wait for the vim guy who will be like "but muh java plugins make it more efficient then IntelliJ"... I think i am more productive in an IDE, faster. Sure if you have this insane VI/EMACS setup that you have tuned for years. Good for you, you probably are a fucking wiz. My standard right now is a terminal & IDE combo. Working in the cloud era as a data person, you need to be comfortable with terminal & vi/emacs (…

> Just wait for the vim guy who will be like "but muh java plugins make it more efficient then IntelliJ"...

I think you described the base of most arguments in that direction right there. The problem to either side isn't so much what the other side's doing (who cares, really? To each their own…).

Usually, those discussions are fueled by people asserting how obviously the respective other side is inferior without having even had a proper look at it. My bias tells me there's much more of those on the IDE side, but I expect that's due to the way people are introduced to programming (if one "population" tends to be much bigger than the other, I suppose there's a higher chance of someone belonging to it starting a flamewar. And, of course, if it's also prone to have more newbies in it, the probability of… unaware statements also rises).

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#218

Earlier quoted context omitted.

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?

> and even with tab completion navigation between files is hard compared to just a couple of clicks? Since when? Editor speaking, I can navigate / open files / select faster with keyboard than it would take to move the hand to the mouse . Not move the mouse and click, just in time it takes to switch the right hand I can launch three of four keystrokes, and that's enough to complete arbitrary operation in vim or Emacs…

I would like to see data on this, any studies done?

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#219

Earlier quoted context omitted.

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?

No no, the problem isn't reaching across the desktop. The problem is literally taking your fingers off of home row. It's fine if you're in a phase of your activity where you're moving slowly, contemplatively. But if there's a series of tasks that we want to accomplish and we already know what they are, lifting your fingers off of home row will slow us down! Wireless vs wired mice have nothing to do with this. As far…

I would like to see data on this, any studies done?

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#220

Earlier quoted context omitted.

> and even with tab completion navigation between files is hard compared to just a couple of clicks? Since when? Editor speaking, I can navigate / open files / select faster with keyboard than it would take to move the hand to the mouse . Not move the mouse and click, just in time it takes to switch the right hand I can launch three of four keystrokes, and that's enough to complete arbitrary operation in vim or Emacs…

I would like to see data on this, any studies done?

You need studies for something you can trivially test for yourself with a stopwatch?
Post reply on HN