12 ms·

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

by rnhmjoj 10y ago

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, for vim it has definitely been in my experience.

williamdclt 10y ago
I agree a lot with this, for two reasons: the one you gave, and the fact that customizing too much your tools makes them unusable by anyone else. I don't know about you, but at my work we're often working on someone else computer (debugging, pair programming...). Always keep the default config available!
rocqua 10y ago
The thing about tmux bindings is that, as far as I know, very few people like the defaults. I've taken the approach of 'learn the defaults' for vim, but on tmux that simply won't stand because the defaults have so much room for improvement. Pretty much everything I've read on tmux suggests the - and | bindings for window splits, same goes for hjkl bindings for movement. Adding these bindings would go a long way towards standardizing tmux.
- mmagin 10y ago
  Yeah, I learned screen defaults, so ^A is far too strong of a habit to change.
  - rocqua 10y ago
    I never used screen and still did the rebind simply for the easy 1-handed operation. I ignored the prefix change because I've actually hear some people prefer the default ^B. I know of no-one who prefers % and " for pane splits.
  - jabl 10y ago
    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?
    - geofft 10y ago
      At this point it's muscle memory for me to use C-a a to get to the beginning of a line, to the point that when I'm not in screen there will be extra "a"s at the beginning of my commands. As for editors, I use vim. (With almost no customization, as others have advocated.)
    - mivade 10y ago
      > 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.
      - gnuvince 10y ago
        When not using tmux/screen, the complete invocation is C-a a M-x roll-eyes RET Backspace.
        klibertp 10y ago
        This is really easy to remedy: just bind send-prefix to C-a C-a. That way you'll be able to easily go to line beginning inside tmux, and outside you won't type the unnecessary 'a' character. Moreover, I forgot if it's the default or if I set it somehow, but in Emacs a single C-a goes back to the beginning of a line, but C-a C-a goes back to the beginning of text on the line, which is almost always what I want anyway. So I press C-a twice anyway, everywhere, and I don't have the problem you described at all :)
      - jiltedfrog 10y ago
        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
  - sevensor 10y ago
    That, and switching to the vi-like keybindings for copy mode, are the only two things I change. And even so, I can and do use an unconfigured tmux with only minor irritation. Configuration just looks like an elaborate way to make sure you're unable to use other people's systems.
artursapek 10y ago
I think the time I've saved by customizing my tmux far outweighs any time I've lost when clumsily using it on a server.
znpy 10y ago
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 me be instantly capable of intervention on whatever machine i put my hands on. Worst case scenario, i can tell programs to ignore configuration files.
- MaikuMori 10y ago
  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.
  - save_ferris 10y ago
    Regardless of the frequency of such a situation, it can really bite you when something big breaks and you need to ssh into a vanilla server in the middle of the night under pressure. Trying to fix a production fire under the gaze of an angry CEO is stressful enough, but not being able to take care of business on a box because of a missing personal config is truly one of the worst experiences I've ever had in this business. It's only happened to me once, but that one experience made me take a really hard look at my workflow, and years later, I have no regrets about scaling back my configs. I guess it really just depends on your job and on-call/firefighting responsibilities.
    - barrkel 10y ago
      If the only time you see a production box is when it's on fire, I think there's an organizational problem. Occasionally acting as third-line support means real production disasters aren't an unfamiliar zone.
spacelizard 10y ago
It gets worse when you work in ops and are constantly needing to remote into servers and you regularly have tmux within a tmux within a tmux... Littering config files across the datacenter just isn't an option.
- bostand 10y ago
  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.
  - jfoutz 10y ago
    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.
    - anjanb 10y ago
      what are those 3 settings on vim ? I assume line numbers is one of them, which are the other 2 ?
      - jfoutz 10y ago
        shiftwidth, tabstop and expandtab
      - tasuki 10y ago
        For many people, line numbers are the first thing they set up - I never understood that. I customize vim quite heavily, and have tried showing line numbers, but all they do is take up 4-5 characters of precious window width! I can see the current line in bottom right, and when I want to go to a line, I use `45gg`. TL;DR people are different.
        psquid 10y ago
        I've never really gotten into absolute line numbers, but relative ones are a godsend for me since I use <num>j, <num>d, et al a lot but can't really eyeball how many lines away something is once it gets to be more than 2 or 3.
jasonlotito 10y ago
Considering it takes one command to recover a tmux config file, I don't see the value in optimizing for the rare occasion where I won't have the config file already in the environment I'm working in. In fact, if I'm not able to use my config file, chances are, tmux is not available for me to use anyways.
hermanhermitage 10y ago
What i would like is to be able to extend terminal protocols to allow client side dotfiles that could be loaded in preference to the host dotfiles. Limited to user prefs, Key bindings etc. Wouldnt solve everything but would address the basics.
mwfunk 10y ago
This is my experience as well. In my larval hacker days in the '90s, when my primary pastime was messing around with my Linux box all day long, I thoroughly enjoyed sifting through window manager and shell man pages to find each and every thing that could be configured, and I'd then proceed to configure each and every one of them to exactly what I wanted. My fvwm/bash/etc. config files from those days could probably be considered a form of outsider art by someone. A common pattern in mailing lists/forums/etc. is the "just make it an option" guy. People are talking about their wishlists for future versions of <Gimp/emacs/Xorg/LibreOffice/whatever>, and sometimes these wishlists conflict. One group says a UI should be one way, another group says it should be some other mutually exclusive way, and a third group thinks the developers should implement both and just make it an option in a dotfile to make everyone happy. Sometimes "just make it an option" guy is right, but in hindsight it should never be the default resolution to the disagreement. In those days I defaulted to "just make it an option", and really internalized that philosophy because it felt like all benefit and no cost. Why wouldn't you make everyone happy, if you could do that instead of making one group happy at the expense of another group? I think it's a really common trap people fall into early on because they have yet to directly perceive the costs that that approach can incur over time in software development. Sometimes they've also tricked themselves into overvaluing their workflows and muscle memory, which they may have defined in part because it was easier for them to define their own keybindings than memorize what the default ones were, which I now think is an antipattern in itself. The main thing that changed for me is spending the intervening decades doing work on multiple machines all the time, running different versions of different OSes, often times starting from fresh installs. That made it more pragmatic to always learn software in its default config, and only tweak configs if it's absolutely necessary or otherwise pretty important to me. It's also forced me to learn all sorts of useful stuff that I probably wouldn't have otherwise. It also drove home just how much my desire to tweak configs was just because it was fun for me (and I had lots more free time back then), rather than something that made me more effective as an engineer. But that's just from a user perspective. From a developer perspective, having "just make it an option" be the default form of conflict resolution leads to all sorts of unanticipated complications in practice. Every time an alternative code path is added for something, the code becomes a teensy bit more fragile and likely accrues a teensy bit of technical debt. The fragility and technical debt accrues over the years, and eventually can turn even the best software into an unmaintainable mess. I'm not dogmatic about it- some things should be options. It's just never my default position, and I have a much higher bar nowadays for making something an option.
WildUtah 10y ago
Put your dotfiles under version control. Open a repository for them on github. A complete personal install on a fresh box is just useradd and git clone away. Two commands to paradise. Google dotfiles in git. It's easier than you think.
0xCMP 10y ago
I have personally been running in to the problem of TOO many different ways to do the same thing. I am using many tools that all do a certain part better and each one of them share certain features which are accessed in all different ways (or it does something slightly different). i.e. Atom, Emacs, Neovim, and PyCharm. I try to stick to one, but switch around to get the best of each of them. It's been driving me crazy lately thought.
- yjftsjthsd-h 10y ago
  Generally (especially with editors) I try out every new toy as it comes to my attention, but then go back home to vim and recreate whatever I liked, whether as configuration or with an extension. It helps that many of Atom's best features have inspired plugins :-)
wtbob 10y ago
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.
whsheet 10y ago
Very good comment which applies to many console apps. I did this with Vim, the only custom key is 'jk' instead of <Esc>. 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.
baby 10y ago
The problem is that you can't use emacs properly with the default Tmux configuration. To go backward a character, with C-b, you need to do it twice.
yAnonymous 10y ago
This is more tmux' fault for having terrible default keybindings (and settings) and I'd rather not waste my time learning and configuring them. That's where byobu comes in.

by rnhmjoj 10y ago

williamdclt 10y ago

I agree a lot with this, for two reasons: the one you gave, and the fact that customizing too much your tools makes them unusable by anyone else. I don't know about you, but at my work we're often working on someone else computer (debugging, pair programming...). Always keep the default config available!

rocqua 10y ago

The thing about tmux bindings is that, as far as I know, very few people like the defaults. I've taken the approach of 'learn the defaults' for vim, but on tmux that simply won't stand because the defaults have so much room for improvement. Pretty much everything I've read on tmux suggests the - and | bindings for window splits, same goes for hjkl bindings for movement. Adding these bindings would go a long way towards standardizing tmux.

mmagin 10y ago
Yeah, I learned screen defaults, so ^A is far too strong of a habit to change.
- rocqua 10y ago
  I never used screen and still did the rebind simply for the easy 1-handed operation. I ignored the prefix change because I've actually hear some people prefer the default ^B. I know of no-one who prefers % and " for pane splits.
- jabl 10y ago
  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?
  - geofft 10y ago
    At this point it's muscle memory for me to use C-a a to get to the beginning of a line, to the point that when I'm not in screen there will be extra "a"s at the beginning of my commands. As for editors, I use vim. (With almost no customization, as others have advocated.)
  - mivade 10y ago
    > 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.
    - gnuvince 10y ago
      When not using tmux/screen, the complete invocation is C-a a M-x roll-eyes RET Backspace.
      - klibertp 10y ago
        This is really easy to remedy: just bind send-prefix to C-a C-a. That way you'll be able to easily go to line beginning inside tmux, and outside you won't type the unnecessary 'a' character. Moreover, I forgot if it's the default or if I set it somehow, but in Emacs a single C-a goes back to the beginning of a line, but C-a C-a goes back to the beginning of text on the line, which is almost always what I want anyway. So I press C-a twice anyway, everywhere, and I don't have the problem you described at all :)
    - jiltedfrog 10y ago
      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
- sevensor 10y ago
  That, and switching to the vi-like keybindings for copy mode, are the only two things I change. And even so, I can and do use an unconfigured tmux with only minor irritation. Configuration just looks like an elaborate way to make sure you're unable to use other people's systems.

artursapek 10y ago

I think the time I've saved by customizing my tmux far outweighs any time I've lost when clumsily using it on a server.

znpy 10y ago

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 me be instantly capable of intervention on whatever machine i put my hands on. Worst case scenario, i can tell programs to ignore configuration files.

MaikuMori 10y ago
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.
- save_ferris 10y ago
  Regardless of the frequency of such a situation, it can really bite you when something big breaks and you need to ssh into a vanilla server in the middle of the night under pressure. Trying to fix a production fire under the gaze of an angry CEO is stressful enough, but not being able to take care of business on a box because of a missing personal config is truly one of the worst experiences I've ever had in this business. It's only happened to me once, but that one experience made me take a really hard look at my workflow, and years later, I have no regrets about scaling back my configs. I guess it really just depends on your job and on-call/firefighting responsibilities.
  - barrkel 10y ago
    If the only time you see a production box is when it's on fire, I think there's an organizational problem. Occasionally acting as third-line support means real production disasters aren't an unfamiliar zone.

spacelizard 10y ago

It gets worse when you work in ops and are constantly needing to remote into servers and you regularly have tmux within a tmux within a tmux... Littering config files across the datacenter just isn't an option.

bostand 10y ago
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.
- jfoutz 10y ago
  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.
  - anjanb 10y ago
    what are those 3 settings on vim ? I assume line numbers is one of them, which are the other 2 ?
    - jfoutz 10y ago
      shiftwidth, tabstop and expandtab
    - tasuki 10y ago
      For many people, line numbers are the first thing they set up - I never understood that. I customize vim quite heavily, and have tried showing line numbers, but all they do is take up 4-5 characters of precious window width! I can see the current line in bottom right, and when I want to go to a line, I use `45gg`. TL;DR people are different.
      - psquid 10y ago
        I've never really gotten into absolute line numbers, but relative ones are a godsend for me since I use <num>j, <num>d, et al a lot but can't really eyeball how many lines away something is once it gets to be more than 2 or 3.

jasonlotito 10y ago

Considering it takes one command to recover a tmux config file, I don't see the value in optimizing for the rare occasion where I won't have the config file already in the environment I'm working in. In fact, if I'm not able to use my config file, chances are, tmux is not available for me to use anyways.

hermanhermitage 10y ago

What i would like is to be able to extend terminal protocols to allow client side dotfiles that could be loaded in preference to the host dotfiles. Limited to user prefs, Key bindings etc. Wouldnt solve everything but would address the basics.

mwfunk 10y ago

This is my experience as well. In my larval hacker days in the '90s, when my primary pastime was messing around with my Linux box all day long, I thoroughly enjoyed sifting through window manager and shell man pages to find each and every thing that could be configured, and I'd then proceed to configure each and every one of them to exactly what I wanted. My fvwm/bash/etc. config files from those days could probably be considered a form of outsider art by someone. A common pattern in mailing lists/forums/etc. is the "just make it an option" guy. People are talking about their wishlists for future versions of <Gimp/emacs/Xorg/LibreOffice/whatever>, and sometimes these wishlists conflict. One group says a UI should be one way, another group says it should be some other mutually exclusive way, and a third group thinks the developers should implement both and just make it an option in a dotfile to make everyone happy. Sometimes "just make it an option" guy is right, but in hindsight it should never be the default resolution to the disagreement. In those days I defaulted to "just make it an option", and really internalized that philosophy because it felt like all benefit and no cost. Why wouldn't you make everyone happy, if you could do that instead of making one group happy at the expense of another group? I think it's a really common trap people fall into early on because they have yet to directly perceive the costs that that approach can incur over time in software development. Sometimes they've also tricked themselves into overvaluing their workflows and muscle memory, which they may have defined in part because it was easier for them to define their own keybindings than memorize what the default ones were, which I now think is an antipattern in itself. The main thing that changed for me is spending the intervening decades doing work on multiple machines all the time, running different versions of different OSes, often times starting from fresh installs. That made it more pragmatic to always learn software in its default config, and only tweak configs if it's absolutely necessary or otherwise pretty important to me. It's also forced me to learn all sorts of useful stuff that I probably wouldn't have otherwise. It also drove home just how much my desire to tweak configs was just because it was fun for me (and I had lots more free time back then), rather than something that made me more effective as an engineer. But that's just from a user perspective. From a developer perspective, having "just make it an option" be the default form of conflict resolution leads to all sorts of unanticipated complications in practice. Every time an alternative code path is added for something, the code becomes a teensy bit more fragile and likely accrues a teensy bit of technical debt. The fragility and technical debt accrues over the years, and eventually can turn even the best software into an unmaintainable mess. I'm not dogmatic about it- some things should be options. It's just never my default position, and I have a much higher bar nowadays for making something an option.

WildUtah 10y ago

Put your dotfiles under version control. Open a repository for them on github. A complete personal install on a fresh box is just useradd and git clone away. Two commands to paradise. Google dotfiles in git. It's easier than you think.

0xCMP 10y ago

I have personally been running in to the problem of TOO many different ways to do the same thing. I am using many tools that all do a certain part better and each one of them share certain features which are accessed in all different ways (or it does something slightly different). i.e. Atom, Emacs, Neovim, and PyCharm. I try to stick to one, but switch around to get the best of each of them. It's been driving me crazy lately thought.

yjftsjthsd-h 10y ago
Generally (especially with editors) I try out every new toy as it comes to my attention, but then go back home to vim and recreate whatever I liked, whether as configuration or with an extension. It helps that many of Atom's best features have inspired plugins :-)

wtbob 10y ago

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.

whsheet 10y ago

Very good comment which applies to many console apps. I did this with Vim, the only custom key is 'jk' instead of <Esc>. 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.

baby 10y ago

The problem is that you can't use emacs properly with the default Tmux configuration. To go backward a character, with C-b, you need to do it twice.

yAnonymous 10y ago

This is more tmux' fault for having terrible default keybindings (and settings) and I'd rather not waste my time learning and configuring them. That's where byobu comes in.