4 ms·

Been using tmux for many years and did not know it could copy text

by corndoge 6y ago

ianthehenry 6y ago
Well, I stand corrected then. More discoverability would definitely make the world a better place. :)
- minusf 6y ago
  it's called reading the docs... some tools are so feature packed there's no way to discover/know everything and that's fine. i didn't discover tmux could copy text until i got really annoyed by selecting with the mouse... not annoyed = not discovered :)
  - d33 6y ago
    Docs aren't a replacement for a good UX. Tmux comes from the times when this attitude was okay, but I feel that the standard now is raised and if the UI could give some feedback/help that doesn't require reading through all of the documentation, it's definitely something that should be prioritized. Anti-example - help screens. Press ctr+b, then ?. Compare this to screen's ctrl+a, then ?. Both are quite terrible, but tmux definitely leaves users more disoriented while this isn't something that couldn't be avoided. A simple message saying "you are in XYZ mode, type :help xyz-mode to get help" could go a long way. The RTFM philosophy combined with a wall of single-file manpage with no tutorial is something that I really wish died already.
    - phone8675309 6y ago
      > The RTFM philosophy combined with a wall of single-file manpage with no tutorial is something that I really wish died already. With respect: what do you do for the tools you use to help this situation? The software is open source and accepts patches, and I'm sure they'd love to accept a patch that adds user-friendly documentation to the tool.
      - d33 6y ago
        It sounds like a loaded question, but a perfectly valid one :) If you're asking whether I actually change the tools I complain about then the answer is "no". The reason is that if you hate how, say, coreutils works and have a strong vision of how it should be restructured, it will boil down to being off-putting to the mainteiners at best and - at worst - becoming a rewrite anyway. This is why I see my role as more of a propagator of tools that want to dethrone the current defaults: I look out for new exciting projects that have wildly better ergonomics than what's most common and I recommend them to my friends. And given that I'm running a hackerspace in my city, I have a bit of a reach so I think that this strategy might be a net good. I also try to share knowledge on how to code and keep in touch with FLOSS communities, so while I might not be contributing code directly, I (hopefully) end up bringing contributors anyway. And while we're talking about spreading the word when a project has good ergonomics, here are some examples I personally love: 1. "glances" - a tool that combines a couple of tools like top, iftop, iotop and various other monitoring programs into one CLI dashboard. It's a bit chunky, but its functionality justifies it. 2. "fd" (cargo install fd-find) - a simpler version of "find". instead of crazy "find -iname 'something" you can just do "fd something". It's also faster. 3. "ripgrep" - like fd, but for grep. Defaults to recursive grep and skips .gitignore, so you can just type "rg variableName" and see all occurrences of it within files in your directory tree. But you're right, I love to complain and quite frankly, in many cases I'm disappointed by priorities some projects choose in terms of ergonomics. Disappointed up to the point that I gave up sending patches - or even filing issues (example: GitLab). Perhaps a solution to the problem would be to have something like a GitHub badge signalling "UX feedback is welcome" or "RTFM", depending on one's design philosophy? That would help developers reach their target audience, regardless of which side of the argument they prefer.
    - soraminazuki 6y ago
      > Docs aren't a replacement for a good UX. Tmux is a command line application, and the man page is a well understood convention for anyone operating on the command line. I don't think it's unfair to fault tmux for poor discoverability because its manual is informative, easy to read, and fits in a single man page. It's also unnecessary to "read through all of the documentation" before using tmux, spending 3 minutes to read the first two sections would suffice. > Press ctr+b, then ?. Compare this to screen's ctrl+a, then ?. Both are quite terrible, but tmux definitely leaves users more disoriented. There's no difference between the two. People who refuse to read the manual or any of the abundant online tutorials won't be able to deduce either. > A simple message saying "you are in XYZ mode, type :help xyz-mode to get help" could go a long way. I'd prefer applications like tmux not stand out more than necessary. Displaying that sort of message every time I press some key can get annoying pretty fast.
    - minusf 6y ago
      tmux has bad UX? ever used this unknown program called `git`? ultimately a terminal multiplexer (and an editor) are complicated tools with steep learning curves, that's the price of the power that they enable. it's everybody's own choice how deep they want to get into it and how much time it saves for them. do you have trouble finding tutorials for tmux? youtube is full of them. and there can be so many because the docs are excellent...
square_usual 6y ago
Seconded. Used tmux for basic ops stuff for ~2 years, didn't know about copying.
- chaps 6y ago
  Been using it for about five, and honestly I stopped using this in my workflows a long time ago. My workflow now is to ctrl-a+z to maximize the pane, highlight (with the mouse) and hit ctrl-insert to copy and ctrl-shift-insert to paste, then ctrl-a+z to restore the pane. It's still a bit of a pane, but it's deeply ingrained enough into my muscle memory that it's smooth. But... sublime is my text editor for notes and SQL. Everything else text related is in a terminal with vim mode enabled universally. Not sure why SQL is so annoying with vim..
  - disqard 6y ago
    > It's still a bit of a pane I see what you did there :)
  - boogies 6y ago
    If you `set-option mouse on`, tmux will let you use copy-mode just by clicking and dragging (intelligently within panes, negating the need to resize-pane -Z). But TBH I often do almost the same thing (but Xorg does its part of the copy-pasta without forcing any Emacs-esque three-finger keyboard chording, thank goodness), selecting text is the only thing I ever use the mouse for in the terminal (except rare scrolling, especially overflowed weechat bars), so I keep tmux’s mouse support off.
    - chaps 6y ago
      Ah yeah, I use that configuration option (love it), but I think the issue is that highlighting text doesn't stay highlighted unless I hold shift -- which shifts the mouse functionality to the terminal emulator. Maybe there's a setting to get around that, but it hasn't been a big enough deal to really try and figure out.

Been using tmux for many years and did not know it could copy text

ianthehenry 6y ago

Well, I stand corrected then. More discoverability would definitely make the world a better place. :)

minusf 6y ago
it's called reading the docs... some tools are so feature packed there's no way to discover/know everything and that's fine. i didn't discover tmux could copy text until i got really annoyed by selecting with the mouse... not annoyed = not discovered :)
- d33 6y ago
  Docs aren't a replacement for a good UX. Tmux comes from the times when this attitude was okay, but I feel that the standard now is raised and if the UI could give some feedback/help that doesn't require reading through all of the documentation, it's definitely something that should be prioritized. Anti-example - help screens. Press ctr+b, then ?. Compare this to screen's ctrl+a, then ?. Both are quite terrible, but tmux definitely leaves users more disoriented while this isn't something that couldn't be avoided. A simple message saying "you are in XYZ mode, type :help xyz-mode to get help" could go a long way. The RTFM philosophy combined with a wall of single-file manpage with no tutorial is something that I really wish died already.
  - phone8675309 6y ago
    > The RTFM philosophy combined with a wall of single-file manpage with no tutorial is something that I really wish died already. With respect: what do you do for the tools you use to help this situation? The software is open source and accepts patches, and I'm sure they'd love to accept a patch that adds user-friendly documentation to the tool.
    - d33 6y ago
      It sounds like a loaded question, but a perfectly valid one :) If you're asking whether I actually change the tools I complain about then the answer is "no". The reason is that if you hate how, say, coreutils works and have a strong vision of how it should be restructured, it will boil down to being off-putting to the mainteiners at best and - at worst - becoming a rewrite anyway. This is why I see my role as more of a propagator of tools that want to dethrone the current defaults: I look out for new exciting projects that have wildly better ergonomics than what's most common and I recommend them to my friends. And given that I'm running a hackerspace in my city, I have a bit of a reach so I think that this strategy might be a net good. I also try to share knowledge on how to code and keep in touch with FLOSS communities, so while I might not be contributing code directly, I (hopefully) end up bringing contributors anyway. And while we're talking about spreading the word when a project has good ergonomics, here are some examples I personally love: 1. "glances" - a tool that combines a couple of tools like top, iftop, iotop and various other monitoring programs into one CLI dashboard. It's a bit chunky, but its functionality justifies it. 2. "fd" (cargo install fd-find) - a simpler version of "find". instead of crazy "find -iname 'something" you can just do "fd something". It's also faster. 3. "ripgrep" - like fd, but for grep. Defaults to recursive grep and skips .gitignore, so you can just type "rg variableName" and see all occurrences of it within files in your directory tree. But you're right, I love to complain and quite frankly, in many cases I'm disappointed by priorities some projects choose in terms of ergonomics. Disappointed up to the point that I gave up sending patches - or even filing issues (example: GitLab). Perhaps a solution to the problem would be to have something like a GitHub badge signalling "UX feedback is welcome" or "RTFM", depending on one's design philosophy? That would help developers reach their target audience, regardless of which side of the argument they prefer.
  - soraminazuki 6y ago
    > Docs aren't a replacement for a good UX. Tmux is a command line application, and the man page is a well understood convention for anyone operating on the command line. I don't think it's unfair to fault tmux for poor discoverability because its manual is informative, easy to read, and fits in a single man page. It's also unnecessary to "read through all of the documentation" before using tmux, spending 3 minutes to read the first two sections would suffice. > Press ctr+b, then ?. Compare this to screen's ctrl+a, then ?. Both are quite terrible, but tmux definitely leaves users more disoriented. There's no difference between the two. People who refuse to read the manual or any of the abundant online tutorials won't be able to deduce either. > A simple message saying "you are in XYZ mode, type :help xyz-mode to get help" could go a long way. I'd prefer applications like tmux not stand out more than necessary. Displaying that sort of message every time I press some key can get annoying pretty fast.
  - minusf 6y ago
    tmux has bad UX? ever used this unknown program called `git`? ultimately a terminal multiplexer (and an editor) are complicated tools with steep learning curves, that's the price of the power that they enable. it's everybody's own choice how deep they want to get into it and how much time it saves for them. do you have trouble finding tutorials for tmux? youtube is full of them. and there can be so many because the docs are excellent...

square_usual 6y ago

Seconded. Used tmux for basic ops stuff for ~2 years, didn't know about copying.

chaps 6y ago
Been using it for about five, and honestly I stopped using this in my workflows a long time ago. My workflow now is to ctrl-a+z to maximize the pane, highlight (with the mouse) and hit ctrl-insert to copy and ctrl-shift-insert to paste, then ctrl-a+z to restore the pane. It's still a bit of a pane, but it's deeply ingrained enough into my muscle memory that it's smooth. But... sublime is my text editor for notes and SQL. Everything else text related is in a terminal with vim mode enabled universally. Not sure why SQL is so annoying with vim..
- disqard 6y ago
  > It's still a bit of a pane I see what you did there :)
- boogies 6y ago
  If you `set-option mouse on`, tmux will let you use copy-mode just by clicking and dragging (intelligently within panes, negating the need to resize-pane -Z). But TBH I often do almost the same thing (but Xorg does its part of the copy-pasta without forcing any Emacs-esque three-finger keyboard chording, thank goodness), selecting text is the only thing I ever use the mouse for in the terminal (except rare scrolling, especially overflowed weechat bars), so I keep tmux’s mouse support off.
  - chaps 6y ago
    Ah yeah, I use that configuration option (love it), but I think the issue is that highlighting text doesn't stay highlighted unless I hold shift -- which shifts the mouse functionality to the terminal emulator. Maybe there's a setting to get around that, but it hasn't been a big enough deal to really try and figure out.