Live data from Hacker News

Using tmux properly

danielallendeutsch.com

141–150 of 218 posts

Re: Using tmux properly

#141
post #46

Earlier quoted context omitted.

I 120% agree. I once lost my emacs dotfile and suddenly i was almost unable to use Emacs on my own pc. Since then, i've decided to apply as little customisation as possible to software I use, and read the documentation and learn the standard configuration instead. For some reasons nowadays it's trendy to add colors, bells and whistles to things but I've found out that learning the standard/default configuration lets…

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

Just so you know, the fact that you indented your link to make it be monospace font also means it's not clickable.

Re: Using tmux properly

#142

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.

Can you explain further what you want to do? But for me, I keep a github repo with my vimrc (among other configs) and I have a Makefile there that symlinks the repo files to ~/

Re: Using tmux properly

#143
post #68
post #64

Earlier quoted context omitted.

I use screen, and in my book the choice of ^A for the default escape is a giant WTF, and remapping that is the first thing I do on a new account before starting to use screen (I use ^o, for no particular reason I suppose except it's not used by anything else I use). Don't the screen developers ever need to go to the beginning of a line in the shell or editor?

> Don't the screen developers ever need to go to the beginning of a line in the shell or editor? C-a a. Using emacs with screen for many years, this is almost automatic for me.

content of dot screenrc file:

defbce on

defutf8 on

escape ^]^]

markkeys "h=^B:l=^F:$=^E"

setenv LANG en_US.UTF-8

startup_message off

term $TERM

Copy pasted from somewhere, i do not recall from where.

ctrl-A is now ctrl-]

This does not clashes with Emacs, ctrl-A

Re: Using tmux properly

#144
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…

You're not wrong about the problem, but there is an issue: sometimes the defaults are really, really bad — e.g. C-a as a prefix character, when anyone who uses emacs keybindings is used to that keystroke taking him to the beginning of the line.

The solution, of course, is to improve the defaults, but that's not always practically possible. Sometimes the maintainers refuse to do the right thing, and sometimes there is no right thing (e.g. should be use C-{b,f,p,n} or hlkj?).

I'd rather have a system which enables me to mold it to myself — even at the risk of being unable to use the same system configured differently — then have a system which forces me to do the wrong thing.

Re: Using tmux properly

#145
post #64

Earlier quoted context omitted.

I use screen, and in my book the choice of ^A for the default escape is a giant WTF, and remapping that is the first thing I do on a new account before starting to use screen (I use ^o, for no particular reason I suppose except it's not used by anything else I use). Don't the screen developers ever need to go to the beginning of a line in the shell or editor?

A friend suggested remapping the Screen command key to ` (backquote), and it changed my life. Maybe it's because I grew up using Esc key combos a lot (terminals with broken/missing meta keys), but it feels natural to treat it like another modifier key there on the left edge of the keyboard.

I did that as well, and it was Great and Good and obviously the Right Thing — right up until I pasted in a some shell code which used `` instead of $(). Never again.

These days I use C-z for tmux. It works, and C-z z is easy enough to type when I want to put something in the background.

Re: Using tmux properly

#146
post #46

Earlier quoted context omitted.

I 120% agree. I once lost my emacs dotfile and suddenly i was almost unable to use Emacs on my own pc. Since then, i've decided to apply as little customisation as possible to software I use, and read the documentation and learn the standard configuration instead. For some reasons nowadays it's trendy to add colors, bells and whistles to things but I've found out that learning the standard/default configuration lets…

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 keybindings/behaviors (and trying to keep all of the different ones in my head).

Yes it is possible to tinker yourself into oblivion (especially if you change the same items frequently, and never come to a stable state), but that is by no means the inevitible outcome.

I also very much disagree with this line from the fish shell design page:

"Every configuration option in a program is a place where the program is too stupid to figure out for itself what the user really wants, and should be considered a failure of both the program and the programmer who implemented it."

Now I understand what they are getting at, and if they didn't start that sentence with "Every" I would not disagree so much. Yes your program should make it as easy as possible for you to figure out how to do what you want to do. However, not everyone in this world is the same. People have different preferences on how things work, and some of the choices on how to do things are mutually exculsive. So every configuration option is most definitly NOT a failure of the program and the programmer who implemented it.

Granted there are programs out there that were seemingly made to purposefully obfuscate how they work (like the dev who wrote them gets some kind of sick pleasure out of making users' lives difficult :-D ). Obviously you should do your best to avoid that outcome (which almost aways comes not out of programmer malice, but other factors, I'm sure).

There is a place, I think, for a really good set of defaults that are consistent and easy for users to follow. I do not agree, however, that it must come at the price of forbidding users to customize their software. 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. If someone finds your program useful enough to want to customize it to their tastes, you risk losing a valuable customer/user who will move on to something that lets them shape it to work they want it to.

[edited to remove unintentional indent -- can't seem to break that habit of putting spaces at the beginning of the first line of a paragraph :D ]

Re: Using tmux properly

#148
post #116

Earlier quoted context omitted.

Keep your dot files in github. Grab them. No internet, I bet you have them on your laptop that you are ssh'd to the server from. SCP them over. Heck, cut and paste them if needed. If things are so bad nether of these work you have bigger issues and need to consider a design with some redundancy. Clos fabrics and VM/containers and if you have to have bare metal then you should have more then one (cluster or behind a S…

This works fine if your configuration contains nothing too custom. Typically after copying my dotfiles I have to edit them quite substantially to make them actually work - mainly because they rely on outside sources (in .tmux.conf, stuff like `set-option -g default-command "reattach-to-user-namespace -l bash"`, in .vimrc it's usually colours, clipboard hacks etc that break). Maybe I should have a second, trimmed down…

That's why I break out things that are platform-dependent. E.g.:

   if-shell "[ $(uname) = 'Darwin' -a -f ~/.tmux.macos.conf ]" "source-file ~/.tmux.macos.conf"
Technically `reattach-to-user-namespace` is a macOS-specific hack to get tmux working, so there's no need to jam it into your standard config.

Re: Using tmux properly

#149

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

At my employer, we have unix accounts for every employee, and the system automatically synchronizes your dotfiles to each server.

On a production server? You're doing it wrong.

Re: Using tmux properly

#150
post #99
post #51

Earlier quoted context omitted.

I learned to give up making things exactly to my liking and learn to use the default key bindings. Now I can log into any machine and be 100% productive.

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 ?
Post reply on HN