Live data from Hacker News

Using tmux properly

danielallendeutsch.com

151–160 of 218 posts

Re: Using tmux properly

#151
post #41

Earlier quoted context omitted.

The session doesn't actually persist between boots. I think what the parent must be referring to is the ability to create tmux session configurations. Then after a reboot if you try to connect to the session which no longer exists the conf will spin it up for you.

Gotcha. I'll have to look up some docs on that, sounds useful.

Yeah, I use https://github.com/tmux-plugins/tmux-continuum to auto save sessions, and https://github.com/tmux-plugins/tmux-resurrect to restore them when tmux is started.

Re: Using tmux properly

#153
post #150
post #99

Earlier quoted context omitted.

Yeah, this is a good approach. I have memorized how to set up three settings for vim I just have to have, but I can usually do that in less than a minute.

what are those 3 settings on vim ? I assume line numbers is one of them, which are the other 2 ?

shiftwidth, tabstop and expandtab

Re: Using tmux properly

#154

Earlier quoted context omitted.

That's why I have public dotfiles. Also this situation happens rarely. The whole beauty of software is that you can customize it and make it your own. The only downside I see with customization is that it can be huge timesink. I guess to each his own, but I think you're really missing out. P. S. Backups.

Does anyone have a good solution for deploying dot files to vim easily? Like a vim package manager that's easily installed.

I now use https://github.com/junegunn/vim-plug - you can setup a one-liner in your Vimrc to download and set it up, then :PlugInstall and you're done (similar to what they have in the readme but I linked to a specific hash on GitHub instead of master).

I also keep a separate file that lists the plugins to install and the source that from my main .vimrc. A lot of my coworkers have wanted my main vimrc for an "out of the box setup" of Vim and found it best for them to specify their own plugins rather than just blindly use mine - it also makes it easier for them to grab the latest copy without any conflicts.

Re: Using tmux properly

#155

So this may mark me out as different, but apart from persistent remote connections, I've never really felt the need for screen/tmux. I've been trying to figure out what the fuss is about, and I still really don't understand (apart from persistence and screen sharing.) When I want multiple terminals, I just fire up another terminal window and hey presto, jobs a goodun. I have a fairly high res screen and small fonts,…

Vim + tmux with custom bindings makes moving between vim and a terminal seamless. The same keystrokes for moving between panes in vim can be used to move to tmux panes. Also, as a vim user I loathe to reach for the mouse, so having quick and easy keybindings for launching and arranging tmux panes is great and preferred to the imperfect and slow arrangement using a mouse. Lastly, I can have tabs and window panes that…

Same boat here.

Vim + tmux definitely helps with managing loads of things.

Add w3m to the mix.

Re: Using tmux properly

#156
In my config, some better mouse support, 256color, history saving, config reload, and emoji-weather (temp + icon) in the status bar.

https://github.com/philippeback/dotfiles/blob/master/.tmux.c...

Emoji-weather is to be taken from https://github.com/justincampbell/emoji-weather

Got this from Justin Campbell on LiveCodingTV. He has pretty good dotfiles https://github.com/justincampbell/.dotfiles

His Vim one pretty much takes the cake: https://github.com/justincampbell/.dotfiles/blob/master/.vim...

and this tmux-pomodoro is sweet. https://github.com/justincampbell/tmux-pomodoro

definitely more stuff than in mine https://github.com/philippeback/dotfiles/blob/master/.vimrc

Re: Using tmux properly

#157

So this may mark me out as different, but apart from persistent remote connections, I've never really felt the need for screen/tmux. I've been trying to figure out what the fuss is about, and I still really don't understand (apart from persistence and screen sharing.) When I want multiple terminals, I just fire up another terminal window and hey presto, jobs a goodun. I have a fairly high res screen and small fonts,…

What happens when you're remoted into another box? Multiple terminals is fine on local, but when you've SSHed into some remote, screen is your friend for managing multiple parallel sessions of work. (In addition, as you mentiond, to persistent sessions -- if you break off, you can always reattach to any of your sessions)

Its just never really been a problem, ssh'ing into remote boxes has literally no cost (I have auto complete hostnames, and sshkey pairs.)

for processes taking longer than a day normally need something like screen, however thats so rare, most things are run inside another execution environment(jenkins, render manager, grid engine/mesos etc)

Re: Using tmux properly

#159
post #63

Earlier quoted context omitted.

Funny you mention that. I tried i3 last year but quickly realized I already have the good parts in tmux. I am now trying to simplify my workflow by only using tmux and emacs. It's minimal and works on almost any system I log into.

Isn't the emacs philosophy to never leave emacs? Doesn't using tmux go against that? Or do you run tmux inside of emacs? I use spacemacs and coming from vim, its taking some getting used to but I'm still always trying to do more things in emacs and not switch to my terminal workspace.

Yeah, but I don't like the emacs terminal.

I feel spacemacs is just a vim clone with really bad cpu and ram utilization. If I am going that road, why not use an ide like eclipse or visual studio instead?

Re: Using tmux properly

#160

I'd argue that using a terminal multiplexer like tmux or screen on a production server (as this article implied) often means you are doing things wrong. It is better to set up a service (systemd or other) and configure it to start correctly rather than relying on a tmux session to manage long running processes. By going this route you get logging, auto restarting, starting on boot, monitoring etc for free.

There's difference to daemons and Kong running process. Long process might be tar up all these files, or copy all these. Things that takes 10 s of minutes to hours. Things you don't want to bomb out just cause network died. Things that are one off and variable enough it doesn't make sense to write a server for them. And of course any you don't want to be interiors part way. Like upgrade or deployment

I just now went through this, which makes this post perfectly apt for my morning. 4-day running process. SSH disconnects on day 3.5.

Reconnected; Started tmux; Started the process; 4 days to go...

I generally know better. Some lessons need to be relearned.

Post reply on HN