Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using tmux properly

danielallendeutsch.com

Post reply on HN
Print view View original

161–170 of 218 posts

Re: Using tmux properly

#161

Post by hibbelig »

heywire wrote: post #114
wyclif wrote: post #112

Earlier quoted context omitted.

Yep, I don't understand why people think you can't clone your dotfiles and copy over your ~/.tmux.conf to your home directory on the server. It's the first thing I do when I get an account set up, along with the ~/.zshrc and ~/.vimrc, and I have it all automated as a script. Makes everything easy.

I'm willing to bet many employers really don't like their employees putting personal config files on a production server...

What do they gain from me having to type "ls -lah" instead of "ll"?

Re: Using tmux properly

#162

Post by whsheet »

git-pull wrote: post #121

I am author of The Tao of tmux , a book I just finished a few weeks ago. You can read it publicly at https://leanpub.com/the-tao-of-tmux/read . One of the things I stress in my book is that there is no "correct" way to use tmux. The approach I take to teaching tmux is separating it into its objects: The server, sessions, windows and panes. Then where they stand in relation to one another, how configurations work, and…

Out of curiosity: Why do you write a book and let it be read publicly if you sell it as well? Why should somebody buy a book when all the content is available for free? Is this done to create some awareness for the book and thus to improve SEO (e.g. generating good backlinks, etc.). And later you restrict the public available content once SEO backlink power is generated?

Our of curiosity 2: Are you happy with the sales, how many books could you sell already (if you don't mind to tell us)? Would you write again a book about a console-based app?

Out of curiosity 3: Are you happy with Leanpub?

Thanks!

Re: Using tmux properly

#164

Post by whsheet »

rnhmjoj wrote: post #33

Yesterday I was helping a friend setting a box with no graphical session: I fired up tmux in the linux virtual terminal and then proceeded to realize without my tmux.conf I couldn't do a thing because I have always been using entirely different keybindings from the default. This is the problem with too much customization. Learning to use the default configuration may be difficult but it's probably worth the effort, f…

Very good comment which applies to many console apps. I did this with Vim, the only custom key is 'jk' instead of . But Vim has really good and sensible defaults. But tmux' % and " (for vertical and horizontal splits) are so counterintuitive, I kept them but still after many years, I still have to think a millisecond every time which of them to press and on top you need to press Shift as well which makes it even more cumbersome.

Re: Using tmux properly

#165

Post by ridiculous_fish »

nocman wrote: post #146
nighthawk454 wrote: post #113

Earlier quoted context omitted.

Totally agree. I think a lot of the replies miss the point - that having non-standard configuration is inherently more complex, because it adds a layer of abstraction. It is simpler to not have this layer. Related note, check out fish shell [1], whose design document has an interesting argument against configurability in software. [1] http://fishshell.com/docs/current/design.html

"having non-standard configuration is inherently more complex" I disagree. It can be more complex, but it is not at all inherent. If I configure my shell, my editor, my whatever software to work more like other software I use (keybindings, etc), I can actually make it less complex for me, because copying over a few config files on those rare occassions I need to is much faster than trying to learn a whole new set of…

fish shell dev here.

> People have different preferences on how things work, and some of the choices on how to do things are mutually exculsive.

Yes! But asking the user to manually configure the system is a lame way to accomodate those preferences. It's better if the software can learn from the user. For example, if the user runs a certain command frequently, don't wait for the user to define an alias, just suggest it while the user types. Your shell can become more customized to you, with no configuration necessary.

This doesn't work for everything - key bindings for example. But it captures the "no configuration" world view.

> Tuck those customization options away if you must (if your philosophy is to encourage the use of the defaults), but I think it is a mistake to forbid user customization.

Not all configuration options are there to enable user customization. A lot of configuration is just punts on hard problems or decisions. For example, options like zsh's RC_QUOTES or bash's histappend. These don't reflect user preferences. They're just legacy or churn. The shell should just define its own language, and not make the user decide how '' is interpreted.

Every configuration point incurs a cost. The user who moved on to the über-flexible system discovered which plug-ins require which options, and which combinations are incompatible with each other.

This is where a layered approach really shines: have a rigid core with a flexible exterior. Allow the user to set the prompt, colors, key bindings, wrap commands likeΩ `grep` and `ls` to set colors, etc. Prefer open-ended customization (let the user write the function) instead of enumerated configuration (pick from N behaviors), an keep the core consistent so that there's something stable to build on. That's fish's philosophy.

Re: Using tmux properly

#166

Post by ZenoArrow »

heywire wrote: post #114
wyclif wrote: post #112

Earlier quoted context omitted.

Yep, I don't understand why people think you can't clone your dotfiles and copy over your ~/.tmux.conf to your home directory on the server. It's the first thing I do when I get an account set up, along with the ~/.zshrc and ~/.vimrc, and I have it all automated as a script. Makes everything easy.

I'm willing to bet many employers really don't like their employees putting personal config files on a production server...

Using Emacs config files as an example, what's the issue with storing config files on a server? Even if it's a 'production' server it's not like they contain much in the way of sensitive information. Does it matter if others have access to a list of keybindings, aliases, colour schemes, plugins, etc...?

Re: Using tmux properly

#167

Post by vegabook »

Honestly, tmux is not hard to use. It has some contorted key bindings, sure, but its benefits are so immediately huge that the motivation to learn its quirks is huge too. And, unlike say, vim, it only has 3 things you really need to know: panes, windows, detach. Most people who use tmux, even casually, will inevitably be using it 'properly', within a week, and fluidly within a month. So this blog post is quite redundant.

Re: Using tmux properly

#168

Post by wyclif »

heywire wrote: post #114
wyclif wrote: post #112

Earlier quoted context omitted.

Yep, I don't understand why people think you can't clone your dotfiles and copy over your ~/.tmux.conf to your home directory on the server. It's the first thing I do when I get an account set up, along with the ~/.zshrc and ~/.vimrc, and I have it all automated as a script. Makes everything easy.

I'm willing to bet many employers really don't like their employees putting personal config files on a production server...

To be clear, I'm talking about your user account, not root or anything like that.

Re: Using tmux properly

#169

Post by wyclif »

ZenoArrow wrote: post #166
heywire wrote: post #114

Earlier quoted context omitted.

I'm willing to bet many employers really don't like their employees putting personal config files on a production server...

Using Emacs config files as an example, what's the issue with storing config files on a server? Even if it's a 'production' server it's not like they contain much in the way of sensitive information. Does it matter if others have access to a list of keybindings, aliases, colour schemes, plugins, etc...?

Especially if your dotfiles are in a public repository anyway.

Re: Using tmux properly

#170

Post by wyclif »

robgibbons wrote: post #136
KaiserPro wrote: post #75

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)

The remote server I happen to do most of my work on right now has tmux installed, so I don't even need to bother with screen anymore (at least for now).
Post reply on HN