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.
Using tmux properly
151–160 of 218 posts
Re: Using tmux properly
#152Re: Using tmux properly
#153Earlier 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 ?
Re: Using tmux properly
#154Earlier 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 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
#155So 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…
Vim + tmux definitely helps with managing loads of things.
Add w3m to the mix.
Re: Using tmux properly
#156https://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
#157So 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)
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
#158Re: Using tmux properly
#159Earlier 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.
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
#160I'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
Reconnected; Started tmux; Started the process; 4 days to go...
I generally know better. Some lessons need to be relearned.