171–180 of 272 posts
Earlier quoted context omitted.
Why do you care so much what workflow some rando on the internet uses?
Quoted post unavailable.
Earlier quoted context omitted.
Why do you care so much what workflow some rando on the internet uses?
Quoted post unavailable.
I was a terminal poweruser wannabe. For a time I tried just using tmux and Vim on almost all occasions. I still use Vim for something, like writing Puppet code. For everything else: I've just come to embrace to the GUI. Unless you're an absolute terminal power user that can masterfully navigate tmux, vim or whatever tools you use, I don't think it's a good use of time. There certainly are things where the terminal is…
Rather. 99% of what I use tmux for is both: not what I would consider "power user" skills; what I think terminal emulators like kitty or iTerm2 will mimick anyway; and reflects how e.g. VSCode arranges its open files.
I find it convenient to have a session of tabs for a particular task/project, and to switch between the tabs depending on what I want to do.
That said, I rarely make use of split panes (nor a tiled window manager). YMMV, but I almost always want whatever I'm looking at to be fullscreen.
Zellij at least shows the keyboard shortcuts.
Earlier quoted context omitted.
Why do you care so much what workflow some rando on the internet uses?
Quoted post unavailable.
But clearly it isn't for you. It isn't for me either, though I did try. I just don't really have a reproducible workflow (I'm not a dev). In that case the setup overhead does indeed not pay off. If you spend every day in an IDE I could definitely see it working out.
Even on my work mac I often prefer using the cli for things that others would do in the GUI. They find that archaic and overly complex. I find it simple and faster. Opinions vary :)
Earlier quoted context omitted.
Why do you care so much what workflow some rando on the internet uses?
Quoted post unavailable.
But I've discovered that by using vim macros, the tedious parts of using nano became easy and FASTER then nano.
Let's say you have to declare a bunch of IP's and you can't just type a range, you have to type out each one.
192.168.0.100 192.168.0.101 ...etc... 192.168.0.199 192.168.0.200
In nano: copy/paste each line then backspace to change the last octet. TEDIOUS
In vim: write it once record a macro of doing it a second time auto-incrementing the last octet. now type: 199@w (or whatever letter you stored that macro in) BOOM, 199 new lines have been input.
That 1 use case, made me use vim more. Then I got better. Then I got faster.
Now I can edit those same old config files faster then I once did in nano. Please believe me, it's worth the learning curve. There is SO MUCH MORE available then just editing some config files.
Nano is fine. There is nothing wrong with nano. If you only edit (config) files a couple of times a year, then maybe you won't want to switch. But I'm so much better at vim then I was before, I use it to do ALL my writing and editing.
Earlier quoted context omitted.
I've used IntelliJ plenty, and it's pretty bad at most of those tasks. Using the git CLI is much better for version control than the Jetbrains GUI wrapper; using Docker itself rather than a wrapper is much better for containers; etc etc. I'm sort of amazed the question of "can you do version control in a terminal" is even being asked... That's where git originated! That's the git team's primary development focus even…
> Using the git CLI is much better for version control than the Jetbrains GUI wrapper For some things. But for reviewing activity in git, and tracking changes across time, doing it in the terminal is unproductive and sucks. (e.g.: 10 levels deep of git blame) > That's sort of the point of *nix systems: multiple processes running simultaneously. Using the shell is of course going to allow that, especially with somethi…
IDK, my experience with JetBrains is it's leaky abstractions all the way down, outside the core edit/refactor features. Using JetBrains Git without knowing git... I mean, I've seen people do it, but they seem pretty frustrated and confused when things go wrong.
I'd rather just learn the underlying tool once, rather than the underlying tool and also the leaky wrapper around it too.
Earlier quoted context omitted.
Quoted post unavailable.
Literally nobody is asking you to use vim. In fact, I don't recommend it to newbies, and warn that a lot of setup is involved. But I am 100x more productive in it than any other IDE, or seen anyone else with an IDE. It works for me. It may not work for you, that's fine.
Earlier quoted context omitted.
> Using the git CLI is much better for version control than the Jetbrains GUI wrapper For some things. But for reviewing activity in git, and tracking changes across time, doing it in the terminal is unproductive and sucks. (e.g.: 10 levels deep of git blame) > That's sort of the point of *nix systems: multiple processes running simultaneously. Using the shell is of course going to allow that, especially with somethi…
>> Using the git CLI is much better for version control than the Jetbrains GUI wrapper > For some things. But for reviewing activity in git, and tracking changes across time, doing it in the terminal is unproductive and sucks. (e.g.: 10 levels deep of git blame) Magit[1] in Emacs is quite okay. It doesn’t feel duct-taped. I haven’t used fugitive[2] in Vim but that’s a thing that exists too. [1] https://magit.vc/ [2]…
Slack is a tricky one and there are no decent terminal clients available, but I do a LOT of e-mail on mutt as my main client and could not be happier and write all my code in vim. I don't think you can "live" on the terminal, but you can still realistically use it to power a significant part of your work.
I second the need for a good Slack terminal client, or at least a service to proxy Slack to IRC or something like that. The Slack app is super slow.
Earlier quoted context omitted.
Why do you care so much what workflow some rando on the internet uses?
Quoted post unavailable.
It’ll take less than 5 minutes to install a Neovim-based IDE-like environment; batteries included:
bash