[HN Gopher] Tmux lets you select and copy text with your keyboard
       ___________________________________________________________________
        
       Tmux lets you select and copy text with your keyboard
        
       Author : ianthehenry
       Score  : 306 points
       Date   : 2021-04-02 02:00 UTC (21 hours ago)
        
 (HTM) web link (ianthehenry.com)
 (TXT) w3m dump (ianthehenry.com)
        
       | enthdegree wrote:
       | critical point
       | 
       | >tmux's copy commands [may not] integrate with the system
       | clipboard [by default on all terminal emulators]
        
         | tjoff wrote:
         | But you can configure it. And it is quite usable even without
         | it. The copy-buffer exist for all tmux session on the same
         | system (tmux-server) so you can share between different
         | panes/windows in current session as well as other sessions.
        
           | mkhnews wrote:
           | Exactly. Granted, I've spent some time on my tmux config, but
           | it is just how I want it, and it's incredibly productive. I
           | can copy to/from the clipboard/selection just fine, between
           | windows and vim and firefox, etc. using the keyboard or
           | mouse. I can go into copy-mode-vi (scrollback buffer) with
           | the PageUp key or mouse wheel from the shell (not from within
           | apps). And the added bonuses of, for example, popping a tmux
           | window of fzf git branch output to choose from for a checkout
           | is nice.
        
       | tomphoolery wrote:
       | ...so does zsh with vim mode turned on :P
        
       | donio wrote:
       | I use this snippet in my .zshrc to make M-v enter copy mode and
       | start scrolling up like it does in Emacs:
       | tmuxup(){tmux copy-mode -u}         zle -N tmuxup         bindkey
       | '^[v' tmuxup
       | 
       | The advantage of this is that you don't hijack M-v from a real
       | emacs running in tmux. It's only active when I need it to: while
       | sitting at the shell prompt.
       | 
       | I guess you could also bind it to PgUp or C-u if you are using
       | the wrong editor.
        
       | Parae wrote:
       | It makes me think of insert mode and selection mode of Termite.
       | It uses many command from Vim, it's useful and well done !
        
       | SomaticPirate wrote:
       | iTerm2 has copy-mode with Vi keybindings by default with Cmd +
       | Shift + C. Feels like a natural extension of Cmd + C.
       | 
       | It also plays wonderfully nice with tmux
        
       | groundCode wrote:
       | Not Tmux, but one of my favourite things about iTerm2 is the
       | search/copy functionality from the keyboard. I often find myself
       | reaching for it, for example
       | 
       | git log - see a commitish I want to fixup cmd-f type first few
       | letters hit tab to get to the end of the commitish cmd-c esc
       | cmd-v to paste it
       | 
       | The other great thing is when you have cmd-f going and there are
       | multiple hits in your terminal, hitting enter cycles you through
       | them backwards.
        
       | spicybright wrote:
       | The fact an article like this exists speaks to how bad the
       | keyboard shortcuts for tools like tmux are. It shouldn't be
       | revolutionary to use basic features of a program.
       | 
       | I'm a huge fan of a command window, where you type words to do a
       | fuzzy search of all the commands in a program.
       | 
       | Sublime text and jetbrains products have it down so well to the
       | point of me not needing to memorize key shortcuts. I just have to
       | remember the first few letters and I'm good to go.
        
         | swiley wrote:
         | I've been messing with Emacs lately, tab completion in M-x is
         | amazing. The editor is surprisingly discoverable because of its
         | "minibuffer" command window.
        
         | G3rn0ti wrote:
         | > The fact an article like this exists speaks to how bad the
         | keyboard shortcuts for tools like tmux are
         | 
         | Well, tmux is not an editor but a terminal multiplexer -- its
         | keyboard shortcuts are like this as to make sure they don't
         | interfere with any editor's shortcuts running in the terminal.
        
         | ryanmarsh wrote:
         | Same, I thought I'd be cool and learn tmux (after 25 years of
         | Linux/Unix use). After a year I realized it's just easier to
         | learn the keyboard shortcuts of my favorite terminal client and
         | tile the windows.
        
         | leejoramo wrote:
         | I first encountered the fuzzy search command bar shortly after
         | I started using Mac OS X 20 years ago when I discovered
         | LaunchBar. This revolutionized my computer usage. Basically
         | bringing the power of CLI to GUI
         | 
         | It took quite a few years fir this to be picked up by
         | SublimeText, but wow that was another huge boost. No longer
         | needing to learn tons of keyboard commands to navigate an
         | application.
         | 
         | I wish an OS would deeply bake this idea in. Apple has done
         | good job with Spotlight for the system level (I still use
         | LaunchBar on my own systems) , but I want this functionality to
         | be shared between System and Apps
        
           | pacifika wrote:
           | Apple has that its command /
        
             | leejoramo wrote:
             | Yes thanks for mentioning that Apple's cmd-/ I fell it gets
             | us about a third of the way to a command bar. I prefer this
             | to Windows alt key navigation of menus.
        
           | CodeGlitch wrote:
           | This is what Ubuntu tried to achieve with Unity. Even as far
           | as being able to search for GUI commands within individual
           | applications. I thought it worked pretty well and was gutted
           | when they scraped it.
        
             | leejoramo wrote:
             | I only grokked what Unity was about after it was cancelled
             | when I was searching for ways to make the Linux GUI more
             | keyboard centric.
             | 
             | I never tried it, seems like such a wasted opportunity.
        
           | lanstin wrote:
           | The large numbers of keyboard shortcuts is a feature - like
           | learning a piano piece or something, once you have muscle
           | memory you can fly thru the commands. Having to look at
           | anything other than the output of your command, like a
           | suggested completion is slower.
        
             | leejoramo wrote:
             | Lets just say I am very keyboard centric. I have used
             | computers for nearly 40 years. I automate the my systems
             | with extensive Keyboard Maestro and AHK scripts, use
             | multiple layers on my programmable hardware keyboard,
             | LaunchBar or Keypirinha. When editing text I seldom touch
             | the mouse or use the menus. I have mostly made Windows 10
             | bend to my highly MacOS inspired keyboard focus
             | 
             | On Linux, I mostly restrict myself to the CLI. When I try
             | Linux GUIs, I am frustrated with the lack of keyboard
             | consistency in the GUI, but I have also never given it the
             | months of time it would take to bend the Linux GUI to my
             | way. (I do customize the heck out of the CLI)
        
         | toyota86 wrote:
         | Cringe. The copy and paste buffer is inspired by vi btw. Do you
         | have a problem with vi in addition to tmux?
         | 
         | That is to say, it's dead simple once it's explained to you.
         | The issue is with documentation, not the keyboard shortcuts
         | themselves.
         | 
         | Sublime Text and Jetbrains are also vi-inspired. For where
         | Jetbrains doesn't go far enough there is a vim mode plugin. I
         | would say these are strong indicators of vi's dominance among
         | keyboard shortcut layouts.
        
           | [deleted]
        
           | bobmaxup wrote:
           | How is "Jetbrains" vi inspired?
        
             | jalk wrote:
             | The 'file' hotkeys in Idea are Norton Commander: F4 edit,
             | F5 copy, F6 move. Iirc early versions of Idea had a two-
             | pane file 'commander' built in
        
           | blux wrote:
           | I read the documentation; and the shortcut is explained in
           | the documentation. I've been using it for years already. I
           | think that maybe the problem is partly that people just do
           | not bother to read the documentation, and expect the tool to
           | take them by their hand. Do we expect that from the tools we
           | use? Is that good software?
        
           | alpaca128 wrote:
           | I use Vim every day and love it. And I found tmux'
           | configuration style and controls so confusing that I gave it
           | up completely.
           | 
           | You want Vim-like controls? Use dvtm. It lets you open the
           | content of any terminal in Vim, and from that point you can
           | do anything from selecting/copying text up to saving a
           | snippet in a file with a simple ":w foo".
           | 
           | All that aside, clipboard copy-pasting in Vim is absolutely
           | horrible out of the box.
           | 
           | > Jetbrains are also vi-inspired
           | 
           | Not sure about that. The tab management and window splitting
           | alone feel near unusable to me, because like many other
           | modern apps they are convinced I only want to switch tabs in
           | a seemingly random order(instead of, you know, the order
           | that's literally shown on screen), and none actually have
           | Vim's tabbing where a tab can contain multiple buffers, not
           | the other way around. And guess what, no Vim plugin I know
           | ever touched tabs. Probably because people not using Vim
           | think the UX is all just in some arcane keybindings.
        
             | mrighele wrote:
             | > because like many other modern apps they are convinced I
             | only want to switch tabs in a seemingly random
             | order(instead of, you know, the order that's literally
             | shown on screen),
             | 
             | If you mean the behavior of Ctrl-Tab, yes, that's confusing
             | for me too. But you can switch using the order shown on
             | screen though, by using Alt-Left / Alt-Right.
        
               | alpaca128 wrote:
               | > But you can switch using the order shown on screen
               | though, by using Alt-Left / Alt-Right.
               | 
               | Can I also press a button to swap those keybindings back
               | to the old behaviour so I don't have to work against my
               | own muscle memory?
               | 
               | Or better, can I tell it to switch tabs on Spacebar-l and
               | Spacebar-h like I have it setup in Vim? I often wonder if
               | it's too demanding to expect keybinding flexibility that
               | was available decades ago. I get that it's a niche use,
               | but then again it's marketed towards professionals and
               | power users.
        
             | ufmace wrote:
             | I use Vim for basically everything too. I do find it a bit
             | irritating that most GUI editors do tabs within splits,
             | instead of splits within tabs as Vim does it. I guess the
             | behavior of tabs within splits is baked into most GUI APIs
             | and frameworks so deeply that it would be virtually
             | impossible to change at this point though. Oh well.
             | 
             | I'm more irritated though that Vim has nice keybindings for
             | any sort of changes you might want to make to your tab and
             | split setup. I don't think any of the GUI tools support
             | keyboard commands for any of that. Or at least if they do,
             | I haven't been able to figure out what they are, and am
             | probably honestly too lazy to try to develop muscle memory
             | for how they work.
        
               | alpaca128 wrote:
               | > I guess the behavior of tabs within splits is baked
               | into most GUI APIs and frameworks
               | 
               | Yes, that is probably a common assumption. On the other
               | hand it may not be that hard to just do the tab bar and
               | split containers separately and handwire them together
               | via input events. At least web UIs aren't exactly famous
               | for their adherence to any standard.
               | 
               | So the more likely reason is that most developers just
               | don't have a reason to do it. Because in the end Vim's
               | approach is just more an exception and as far as I know
               | Vim tabs weren't even originally intended for the same
               | purpose - and I can confirm buffer switching within a tab
               | can be pleasingly fast and precise thanks to the tab
               | completion.
        
           | opan wrote:
           | Last I checked, tmux binds are all emacs-like until you
           | change your config. I remember the copying stuff suddenly
           | being easy once I toggled the vi-like keys. Maybe you haven't
           | used an unconfigured tmux in a while.
        
             | ianthehenry wrote:
             | tmux actually tries to be clever here and guess if you're a
             | vim user or not: if your $EDITOR contains the string "vi",
             | you get vi-style keybindings by default. If it doesn't, you
             | get emacs.
             | 
             | But unfortunately it _doesn 't_ look at $VISUAL, so...
             | yeah, you usually have to set it explicitly.
        
         | raverbashing wrote:
         | Completely agree. I love these tools, but the usability (and
         | defaults) are awful
         | 
         | Not to mention they all seem to come from an "old unix"
         | perspective, with weird combinations and few use of bound
         | combinations
         | 
         | Hence why I prefer keeping my terminal tabs not on tmux but on
         | iTerm (or your favourite terminal emulator - except for the
         | Gnome one)
        
         | easytiger wrote:
         | Thats completely unfair to the point of being plain wrong.
         | 
         | For a start tmux does have similar interfaces, ability to
         | search all panes etc.
         | 
         | Also comparing tmux to an ide is also possible wrong.
        
         | gertlex wrote:
         | I learned of byobu several years ago from a coworker. I think
         | of it as (but may be technically incorrect) a wrapper on top of
         | tmux (or optionally screen; behaves the same-ish either way?)
         | 
         | It's hotkeys are... less arcane to remember by virtue of being
         | primarily the F-keys at the top of the keyboard.
         | https://manpages.ubuntu.com/manpages/eoan/en/man1/byobu.1.ht...
        
           | spookthesunset wrote:
           | +1 for this tool. Really makes it obvious what is going on.
        
         | ianthehenry wrote:
         | I don't think that's fair: this is not news to anyone who has
         | ever used tmux. This post was written for people who have never
         | tried tmux, but who might want to if they knew about this
         | feature. I think tmux actually has good command discoverability
         | (once you install it) -- prefix + question mark lists all the
         | keybindings, with user-friendly descriptions of what they do.
         | 
         | That said, I agree with your larger point completely -- I love
         | Sublime's command palette, and I love using ivy/counsel for M-x
         | in emacs. It would be even better if tmux had something like
         | that.
        
           | tomphoolery wrote:
           | fzf could in theory be used for this
        
           | lucideer wrote:
           | tmux user. This is news to me.
        
           | oblio wrote:
           | I've been using tmux for a while and I didn't know about
           | this.
           | 
           | Just because an app has some features doesn't mean that
           | everyone knows about them. In fact the opposite is true, most
           | features are never discovered and even fewer are used, even
           | "obvious" ones.
        
           | EamonnMR wrote:
           | I used Tmux as my tiling window manager for a while and I
           | didn't know this.
        
           | rekoros wrote:
           | I've used tmux for 10 years, and for 10 years I've struggled
           | to copy text in tmux. To my defense, the documentation is
           | impenetrable.
           | 
           | That said, so looking forward to copying text in tmux going
           | forward. The instructions in the OP didn't work for me, but I
           | found two other posts - one from 2013, one from 2016, the
           | combination of which worked. Not only can I copy text to a
           | tmux buffer now, but it automatically goes to the system
           | clipboard. This feels like overcoming a major disability.
        
             | russellendicott wrote:
             | I've been using tmux buffers for quite some time now but
             | what always throws a wrench in my plans is when using tmux
             | in SSH sessions there are always gotchas when getting
             | access to my host's clipboard buffer depending on the
             | platform (windows/mac/nix). The whole reason I dev remotely
             | through SSH is so it doesn't matter what platform I'm
             | coming from.
             | 
             | For example, from Windows these days I'm having to vim yank
             | to file ~/clipboard and then I have a Windows keyboard
             | shortcut to pscp that file locally && notepad file. Hacky,
             | yes, but the muscle memory is there now so meh.
             | 
             | But that's just the flavor of the month this month...
        
             | simias wrote:
             | tmux's keyboard copy is rather intuitive... If you know
             | emacs.
        
               | nobleach wrote:
               | The crazy thing there is that it uses Vim visual mode for
               | selecting text `v` or `V`.
        
             | AzzieElbab wrote:
             | I am by no means a tmux expert but I think I discovered
             | copy paste-yank paste by accident because I use vi keys.
             | Also, tmux on Mac feels weird compared to Linux terminal
        
             | res0nat0r wrote:
             | I'm not sure why everyone goes so crazy over tmux, I've
             | been using screen for 20 years now and it's generally
             | installed everywhere by default, even on remote servers I
             | don't have root on, so I don't have any real reason to
             | switch. 99% of both of these things both do what I need
             | daily, so I usually don't use tmux unless screen doesn't
             | happen to be available for some reason and tmux does. But
             | more power to the devs for wanting to rewrite screen to be
             | more modern with some additional features.
        
               | irateswami wrote:
               | Screen is incredibly inefficient though.
        
               | gbraad wrote:
               | Still using screen to easily run a background which I can
               | occasionally check up on. Never (perhaps once a year)
               | seem to do this with tmux.
        
               | res0nat0r wrote:
               | That's always been the argument, but it's always been
               | perfectly fine for me. I'm using it to run long running
               | background tasks, or just let me switch between multiple
               | remote hosts patching / debugging them, not to render
               | some kind of HD game.
        
               | fl0wenol wrote:
               | Genuinely curious: In what way?
               | 
               | Also: How is tmux about serial ports/USB->serial
               | adapters?
        
               | mprovost wrote:
               | And yet... I've been using screen for 20 years and it
               | never seemed inefficient, even when running on a 180MHz
               | Pentium Pro. These days I have to believe whatever it's
               | doing must be pretty minor compared to the overall system
               | performance, but I'd be interested in hearing what it
               | does so inefficiently.
        
               | guenthert wrote:
               | It worked fine in the early nineties on a '386. I can't
               | tell how efficient it is, because I never had reason to
               | worry about it.
        
             | 0xEFF wrote:
             | You may already know, but in case not, you can also use
             | this tmux feature from your editor. For example in vim
             | :w !tmux load-buffer -
             | 
             | Writes whatever you have selected in vim into the tmux
             | buffer through standard in.
             | 
             | Elsewhere you can paste like pbpaste.                 :r
             | !tmux save-buffer -
             | 
             | The save-buffer command is't the most intuitive name, but
             | it's saving to a file, stdout in this case.
        
           | rgoulter wrote:
           | One feature to improve the discoverability of sequences of
           | keypresses/chords is a which-key style UI. e.g. a panel will
           | show the available set of next inputs which can be handled,
           | and what their command is. https://github.com/justbur/emacs-
           | which-key#more-examples
        
           | blueblob wrote:
           | I agree with the command discoverability. Not only does
           | prefix+? show you the commands, it is also searchable, and if
           | you use vi-mode, it uses the same search commands.
        
           | corndoge wrote:
           | Been using tmux for many years and did not know it could copy
           | text
        
             | square_usual wrote:
             | Seconded. Used tmux for basic ops stuff for ~2 years,
             | didn't know about copying.
        
               | chaps wrote:
               | 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..
        
               | boogies wrote:
               | 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 wrote:
               | 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.
        
               | disqard wrote:
               | > It's still a bit of a pane
               | 
               | I see what you did there :)
        
             | ianthehenry wrote:
             | Well, I stand corrected then. More discoverability would
             | definitely make the world a better place. :)
        
               | minusf wrote:
               | 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 wrote:
               | 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 wrote:
               | > 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 wrote:
               | 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 wrote:
               | > 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.
        
           | iopq wrote:
           | I've used it, but I use it like a retard so it's useful to
           | me.
        
         | Galanwe wrote:
         | > Sublime text and jetbrains products have it down so well to
         | the point of me not needing to memorize key shortcuts.
         | 
         | Right, but you dont run things _inside_ sublime text. Keep in
         | mind tmux has to play well with hundreds of existing shortcuts
         | that people expect to work.
         | 
         | When you are attached to a tmux, you don't want to override the
         | shortcuts of something you may run inside the tmux.
         | 
         | All the terminal shortcuts are expected to work (Ctrl-E, Ctrl-
         | Arrow, Ctrl-A, Ctrl-E, Ctrl-E, Ctrl-Q, etc..). All main program
         | shortcuts are expected to work (vim, emacs, etc) And of course
         | not desirable to override screen shortcuts.
        
           | wahern wrote:
           | I never used GNU screen as its command prefix, ctrl-k,
           | conflicted w/ the command prefix for my preferred editor,
           | JOE, and I was always too lazy to reconfigure the bindings.
           | tmux uses ctrl-b by default, which smoothed the way to using
           | tmux. I'm still too lazy to learn any tmux commands; the only
           | one I know off-hand is ctrl-b-d, for detaching, which is
           | sufficient for my needs. Scrolling is annoying in tmux
           | sessions because I don't remember the commands, but I
           | compensate by avoiding tmux when I might need the scroll
           | buffer or by tee'ing output to temporary files.
        
             | pwg wrote:
             | I just moved screen's command prefix to ctrl-j, for the
             | same reason, it did not conflict with Joe (in JStar mode)
             | command keys.
             | 
             | That reconfiguration occurred very soon after I was
             | introduced to screen, circa. 1993 or thereabouts.
        
             | andrewzah wrote:
             | Piping output to a file is much more preferable in my
             | opinion, but you can access scrollback with ctrl-b [, then
             | j/k for up down and ctrl-u/ctrl-d for jumping up/down.
        
             | usr1106 wrote:
             | I'm suprised anybody uses JOE as their preferred editor. I
             | have never met anybody even mentioning it, but obviously
             | people have different backgrounds.
             | 
             | I've used Unix in the 1980s the first time and learned that
             | whatever your preferred editor is, you need to know vi,
             | because vi is always installed. That has been true in my
             | experience with a single exception. In a recent embedded
             | Linux I used they had only nano available.
             | 
             | So what is the story behind JOE and what is good about it?
        
               | pm215 wrote:
               | I use JOE in its "emacs-ish keybindings" mode (which you
               | get if you run it as 'jmacs') for small "just run an
               | editor in a terminal to edit this config file" jobs. I
               | wanted an editor which was fast to start up, terminal-
               | based, and emacs-like, and this was the one I found 20
               | years ago. It's always been reliable and it's always been
               | available as a Debian package, so I've never felt a need
               | to look for something else.
               | 
               | For long running edit sessions I use real emacs; I know
               | you can set that up in a client-server arrangement to
               | avoid the startup speed problem, but I never had the
               | effort to investigate that; besides, sometimes you want
               | to edit a file as root, who won't have a long-running
               | emacs.
        
               | michael-ax wrote:
               | try this: emacsclient [-n] -c -a ""
        
               | opan wrote:
               | For editing a file as root in emacs, you can use TRAMP to
               | connect to your same machine as the root user. I think
               | you also have to toggle a read-only mode afterward.
        
               | Kliment wrote:
               | I used JOE for a long time back in the day and I remember
               | it fondly for plastering its documentation right onto the
               | screen so you didn't have to look stuff up, as a
               | beginner. This sounds embarrassing but I suspect others
               | have had the same problem so here goes:
               | 
               | Back in the day (in the 90s) I was just starting out with
               | linux, and had to install slackware from floppies I
               | carried to school and to the library, a handful of
               | packages at a time. I didn't have documentation packages
               | installed yet, but I did have some howtos. So I had to
               | edit some files, and I tried the "standard" editors - vi
               | and emacs. I didn't know how to quit vi or emacs. I'd end
               | up trapped in them, and eventually figured out I could
               | Ctrl-Z and kill the process for vi. This didn't work on
               | emacs so I'd end up switching to a second virtual
               | terminal and then kill the emacs process. I had no idea
               | what I was doing, and being unable to get out of a
               | program and get back into a safe known state was quite
               | traumatic to teenage me just getting into unixy stuff.
               | JOE was there for me. It did what I needed it to do, it
               | told me how to operate it, and I never once got stuck in
               | it. Out of gratitude, I used it exclusively for years.
               | It's zero bullshit, it edits files, it doesn't let you
               | down.
        
               | chx wrote:
               | wordstar. If you are used to wordstar, joe is a blessing.
               | 
               | There are a few greybeards and I mean that literally who
               | swear on WordStar, GRRM most famous of them but Robert J.
               | Sawyer does too. So it's not unreasonable to think there
               | are other, less famous people who still use it? and want
               | to use an editor with the familiar keybindings.
               | 
               | Not me. I am _completely_ up to date with software and my
               | favorite word processor is WordPerfect 5.1.
        
               | liotier wrote:
               | Also, Turbo Pascal 3.x's editor took Wordstar shortcuts.
               | Only years later high school me only learnt that those
               | strange ctrl-k commands were archeological artifacts...
        
               | chx wrote:
               | I am ashamed but I forgot the Turbo Pascal hotkeys :(
               | it's been ... a long , long time since I opened
               | TURBO.COM. Some of these do fall out of memory. I once
               | knew the full 300+ opcode list for the Z80 so I could
               | read machine code and disassemble it in my head, now I
               | only remember C9 being RET :( I blame high school, it was
               | too intensive and it crowded this out of my head.
        
               | nobleach wrote:
               | I launched it a couple of years ago to show my kids what
               | I did as a kid. I had forgotten pretty much every bit of
               | Pascal (and I actually wrote Object Pascal at the end of
               | the 90s!) But all that writeln stuff has left my brain.
        
             | devin wrote:
             | I think you mean ctrl-a for screen's default leader.
             | 
             | ctrl-b ? is helpful if you can't remember the hot keys.
        
         | y04nn wrote:
         | Tmux is a great replacement for screen, but it's true that
         | keyboard shortcuts are atrocious, I think every shortcuts that
         | I use daily are remapped in my tmux.conf. Also when I copy in
         | tmux it automatically change the clipboard and vice-versa, very
         | useful to copy errors or paste snipped of code from internet.
         | And with 'mode-keys vi' it's even faster.
        
         | sime2009 wrote:
         | The general problem with these kinds of TUI apps isn't the
         | shortcuts but the complete lack of discoverability of the
         | commands and their shortcuts. The expectation that people have
         | to go and the read the documentation and then memorise the
         | shortcuts is ridiculous.
         | 
         | GUIs for decades have demonstrated practical ways of making
         | commands discoverable and also teaching users the keyboard
         | shortcuts. All without having to ask people to RTFM. It is a
         | pity that so many TUI apps haven't learnt the same lessons.
         | 
         | There is a reason why Nano became such a popular default editor
         | for email. The shortcuts are printed at the bottom of the
         | screen(!)
         | 
         | I hope more TUI apps pick up on the idea of the command palette
         | though. It is a fast and keyboard friendly way of improving
         | usability.
        
           | ufmace wrote:
           | I see it as a kind of trade-off. Good GUI apps do make it
           | much easier for commands to be discoverable to new users of
           | that application. What they sacrifice is generally smooth and
           | rapid keyboard control and more sophisticated composable
           | commands. To make use of that, you pretty much have to be a
           | power user and spend a lot of time drilling keyboard commands
           | and how they can chain together into your head. Once you do
           | that though, you can do a ton of advanced things really fast
           | while hardly even thinking about it.
        
           | spookthesunset wrote:
           | If tmux or screen had two rows worth of UX like nano does...
           | it'd use them way more. I see the value of those programs but
           | they are so _not_ core to my workflow that I can never bother
           | to remember the keyboard shortcuts.
           | 
           | Ubuntu has some wrapper for tmux called byobu that does
           | exactly this. It is the only time I really enjoy using this
           | sort of tool.
           | 
           | https://www.byobu.org/
        
           | renox wrote:
           | Good GUIs can be discoverable yes, but what about about
           | Windows XP's file explorer _shift_ right-click option (to
           | make reappear  'Open with..'), Windows 10 _right_ click on
           | the  'start' menu? Do you find these things discoverable?
           | 
           | The truth is that being pretty/fashionable matter more than
           | discoverability..
        
             | ropeladder wrote:
             | It's not about being flashy. Those Windows commands are
             | hidden precisely because they are for power users and
             | Microsoft presumably thinks that average users don't want
             | or need them. Which is a whole different can of worms.
        
               | renox wrote:
               | These commands should be also provided behind an
               | 'advanced' submenu which would make them both
               | discoverable AND not used by default by normal users.
        
         | king_magic wrote:
         | I've had no trouble reading a guide to tmux's keyboard
         | shortcuts and then using them.
        
       | edoceo wrote:
       | See also https://tmuxcheatsheet.com/
        
       | X6S1x6Okd1st wrote:
       | I've been using neovim as my terminal multiplexer for a couple
       | years now. I can use all the same key commands for yanking and
       | pasting buffers from a file buffer to a terminal buffer.
        
         | phasnox wrote:
         | I tried this once, but I can't recall why I stopped.
         | 
         | Do you have any particular issue? Does it give you a real tty?
        
           | gkop wrote:
           | For me, when I went and tried a vim terminal buffer a few
           | years back, I learned that my habituation to the emacs-style
           | shell shortcuts (ctrl-a, ctrl-e, etc) was a significant (and
           | dumb) barrier, that I didn't care to overcome.
        
         | ma2rten wrote:
         | Is that very different from the Terminal in Vim 8.1+?
        
           | u801e wrote:
           | I haven't used neovim, but it certainly is possible to use
           | vim with its terminal feature as a terminal multiplexer. The
           | way I do it is to use a single instance of vim to handle the
           | multiplexing and just run whatever I need in different split
           | windows or tabs.
           | 
           | If I need to copy, I'll use the terminal normal mode (ctrl-w
           | N) and visually highlight text and copy it to the + register.
           | Then I can paste the contents in another application. The
           | only issue I've encountered is that some text that's not
           | supposed to be wrapped has line breaks added at the screen
           | width. In that case, I'll paste the text into another vim
           | buffer first and remove the line breaks using gJ. then copy
           | and paste it into another application.
           | 
           | For copying text from another application back into vim, I'll
           | just highlight it with the mouse and paste it into vim using
           | ctrl-w "*
        
           | X6S1x6Okd1st wrote:
           | I started using it before that was introduced. I haven't
           | tried going back.
        
       | krisgenre wrote:
       | Been using Tmux for around 6 months. I frequently use prefix + [
       | shortcut but always thought of it as "Scroll mode", never
       | realized that its called "Copy mode" nor that one could copy text
       | using keyboard.
        
         | nobleach wrote:
         | I've used Tmux for around 8 years, and I've never had a
         | pleasant copy/paste experience. This is not for lack of reading
         | plenty of Google search results, installing different plugins,
         | aliasing long command strings, to keyboard shortcuts. In the
         | end, I'm still back where I started. I grab my mouse, highlight
         | the text and pray that it's not longer than what fits on the
         | page. I then hit Control+Shift+c, and I have the text on my
         | clipboard. I've heard that there is a way to do this in a more
         | vim-like fashion, but I've never actually gotten it to work. I
         | used "Copy mode" every single day to be able to read what's in
         | my scrollback buffer (test results, error output, etc) but
         | using a key to start highlighting and copying contents to my
         | clipboard? Man, that'd be awesome.
        
           | ianthehenry wrote:
           | I am curious to hear about your experience. What OS and
           | terminal emulator do you use? Do you run tmux on a remote
           | host that you SSH into?
           | 
           | If your terminal emulator doesn't support copy escape codes,
           | and you're running it on a remote server, you need to ssh
           | with X forwarding in order to share your system clipboard.
           | 
           | I realized over the course of this thread that I know a weird
           | amount about configuring tmux. I rely on this feature pretty
           | heavily, so I've had to set up system clipboard integration
           | on Mac and Linux across on multiple different terminal
           | emulators. I'd be happy to help you get a config that works
           | on your system, if you want.
        
             | nobleach wrote:
             | I've used quite a few combinations over the last few years.
             | These days I'm using Termite locally on Linux. In the past
             | I've used iTerm on macOS/OSX.
             | 
             | To be very clear here, I can copy text from pane to pane.
             | (using control+] to paste)
             | 
             | Judging by some recently commented lines in my tmux.conf.
             | I've tried: # bind C-y run "tmux save-buffer - | xclip
             | -selection c"\; display-message "Buffer copied to
             | clipboard" # bind y "xsel -i --clipboard" # bind-key -T
             | copy-mode-vi y send-keys -X copy-pipe "xclip"
        
               | ianthehenry wrote:
               | The last one looks pretty close to working, but I don't
               | know if xclip works with no arguments. This is what I
               | use:                 bind-key -T copy-mode-vi y send-keys
               | -X copy-pipe "xclip -i -selection clipboard"
               | 
               | That should just work if you're running tmux locally, or
               | if you're connected to a remote session with X
               | forwarding.
        
               | nobleach wrote:
               | I'll definitely give it a shot. Although I didn't reply
               | to this thread expecting "tech-support", it certainly is
               | appreciated when fellow tech folks are willing to share
               | what they've learned. So, thank you.
        
       | mssundaram wrote:
       | At my first SWE job I pair programmed every week with a greybeard
       | who used vim and tmux (and didn't own a cellphone). I continue to
       | be grateful for his mentorship
        
       | jftuga wrote:
       | This is my .tmux.conf along with a brief tutorial. It uses the
       | "screen" prefix of Ctrl-A (instead of the default, Ctrl-B).
       | 
       | https://github.com/jftuga/universe/blob/master/tmux.conf
        
       | TBurette wrote:
       | To me, copy/paste is a weakness of a workflow using tmux.
       | 
       | With tmux you end up with four distinct copy/paste buffers: the
       | OS, tmux, the shell, vi/emacs. You do get used to the mental
       | gymnastic of juggling all those but it's not ideal.
       | 
       | Same goes with managing the windows of the OS, tmux and vi/emacs.
        
         | bengalister wrote:
         | I use the vi mode for tmux and my shell (zsh). I configured
         | tmux and neovim to copy into the system clipboard (not for the
         | shell, I did not search to be honest)
         | 
         | Thus to copy I use the y (yield) key, with optional selection
         | keys like iw (in word), t<char> (to <char> included), f<char>(
         | to <char> not included), etc.
         | 
         | But my mouse selection copy works differently between vim and
         | tmux. In vim, when I select text with the mouse I have to press
         | y to copy it. In tmux it is copied without pressing any key. So
         | there is improvement here because often the paste fails after
         | selecting text in vim because I forgot to press the y key.
         | 
         | tmux is what made drop tiling window managers after I realized
         | I was only using tiling in a terminal. (I use Gnome on Linux.)
        
           | bengalister wrote:
           | I realized that the mouse selection automatic copy is due to
           | the tmux yank plugin.
        
         | cryptonector wrote:
         | It's three. The shell doesn't do copy-paste, unless you mean
         | the terminal emulator, but then that's copy-paste as in "the
         | OS". This is actually great because you get many more cut
         | buffers this way. There used to be a utility called xcb(1) to
         | manage X11 cut-buffers (yes, there's more than one!), but even
         | so, that requires too much mouse use. With tmux and
         | vi/vim/emacs you get many cut-buffers. If, like me, you run a
         | $EDITOR per-pane, then the tmux cut buffers are most useful
         | when cutting and pasting between panes, while $EDITOR cut
         | buffers are most useful when cutting and pasting within a file.
        
           | ianthehenry wrote:
           | You can copy and paste in bash and zsh with emacs keybindings
           | (by default). I will sometimes start typing git commit -m
           | "something...", then hit ctrl-a ctrl-k, then stage another
           | file, and then later ctrl-y to finish the commit. But ctrl-q
           | basically does that same thing, in a nicer way. I don't know
           | how to get bash/zsh to integrate with the system clipboard.
        
         | vulcan01 wrote:
         | FYI, you can use vim's clipboard register * on linux/Mac (might
         | be + on Windows?) to make it use the system clipboard.
         | 
         | (Or `:set clipboard=unnamed`)
        
         | ianthehenry wrote:
         | Oh, yeah. I can't keep multiple clipboards straight. I
         | configure everything to share the OS clipboard (except my
         | shell... but I don't really use my shell's copy buffer since I
         | got in the habit of using ctrl-q).
         | 
         | tmux will copy to your system clipboard by default _if_ your
         | terminal emulator supports the right escape sequences. If it
         | doesn 't, then you do need to configure it to shell out to
         | xclip or pbcopy or whatever. It's annoying, but I find it less
         | annoying to configure it than to try to keep multiple copy
         | buffers straight.
        
         | revscat wrote:
         | Echoing others: I have the tmux copy/paste mapped to my system
         | pasteboard. Ditto nvim. I do not use the shell buffers.
         | 
         | The cognitive load you are concerned about can be configured
         | away, and for me is a solved problem.
        
           | nikisweeting wrote:
           | Same on macOS with iTerm's Tmux integration, everything just
           | uses the system clipboard buffer seamlessly, even when
           | copying inside tmux on a remote ssh connection.
        
       | josteink wrote:
       | So does GNU screen?
        
         | totetsu wrote:
         | Ctrl+a ESC arrows to start Enter arrows to end Enter. Ctrl+a ;
         | to paste? .. of the top of my head
        
         | tarkin2 wrote:
         | Came to say that
         | 
         | - ctrl-a [
         | 
         | - move to the text you want
         | 
         | - press space to start selection
         | 
         | - press space to end selection
         | 
         | - go to another screen, ctrl-a ] to paste
         | 
         | copy mode and scrollback in gnu screen is great to quickly scan
         | tail -f commands.
        
       | sigjuice wrote:
       | For me, the killer feature of tmux is actually the mouse support
       | (e.g. clickable window names, pane selection, scrolling,
       | copy/paste), which works even over ssh.
        
         | enriquto wrote:
         | Yes, but it's a shame that tmux is not a good "x11 citizen". If
         | you select some text inside tmux, you cannot middle-click on
         | another window to copy it. Likewise, if you select some text on
         | a non-tmux window, you can copy it everywhere, _except_ on your
         | tmux session. For me this means that the mouse support is
         | severely broken, and I actually prefer to use  "tmux set mouse
         | off", by which all goodies are lost, but at least I can copy-
         | paste like a human being.
        
           | opan wrote:
           | If you hold shift, you can bypass tmux and copy/paste at the
           | terminal emulator level.
        
             | enriquto wrote:
             | Yes, that's what I've been doing for years, and I hate it
             | (to the point of disabling mouse support). It is
             | _extremely_ annoying to have to press SHIFT for normal
             | operations that work out of the box in every other program.
             | 
             | Fortunately, thanks to ianthehenry's solution on this
             | thread, you can do the same thing without pressing shift!
        
             | elteto wrote:
             | And Ctrl-Shift for block selection (in some terminal
             | emulators).
        
           | ianthehenry wrote:
           | Yeah. It's not _completely_ tmux 's fault -- it's doing what
           | it can, in a terminal emulator -- but it could be smarter.
           | You can make it behave the way it should with a couple lines
           | in ~/.tmux.conf:                 # copy on select       bind-
           | key -T copy-mode-vi MouseDragEnd1Pane send -X copy-pipe-no-
           | clear 'xclip -i -selection primary'            # paste on
           | middle click       bind-key -n MouseDown2Pane { select-pane
           | -t=; run 'tmux set-buffer "$(xclip -o -selection primary)"';
           | paste-buffer }
           | 
           | (s/xclip/xsel, depending on your system.)
        
             | enriquto wrote:
             | wow, many thanks! This is a neat hack. I wonder why this
             | very natural behaviour is not the default.
             | 
             | Your solution is almost perfect. The "paste" code works as
             | expected. But the "copy" code, apart from copying the
             | selection into the clipboard, leaves the tmux pane in an
             | odd state (copy mode) from which you have to exit manually.
             | Would it be possible to bind the command to something that
             | quits copy mode afterwards?
        
               | ianthehenry wrote:
               | Yep! Use copy-pipe-and-cancel instead of copy-pipe-no-
               | clear.
               | 
               | I don't think tmux has any, like, OS-aware anything. It
               | can copy to the system clipboard, but only by asking your
               | terminal emulator to copy. To work the way you expect,
               | tmux would need to know to use xclip on Linux and
               | pbcopy/pbpaste on macOS or whatever. Which would be
               | pretty nice! That would be a great, easy feature that
               | would cover ~99% of users. But it seems like it
               | deliberately doesn't want to (?). I'm speculating there.
        
               | enriquto wrote:
               | Thank you very much, you made my day with that!
        
       | patricius wrote:
       | Vim's :term command has become my go-to way to open up a terminal
       | nowadays. It gives you nice terminal emulation, but also lets you
       | stay in Vim and use all the Vim keyboard mappings. When a
       | terminal window has focus, you can go into Normal mode with
       | `Ctrl+W N`, which will let you search and yank stuff like you're
       | used to.
        
         | clipradiowallet wrote:
         | TIL `:term`. I've been using vim/tmux (and before that,
         | vim/screen) for nearly 30 years. I never knew about `:term`
         | before that, thanks for posting.
         | 
         | PS: And when the terminal session exits, the history is still a
         | vim buffer - that's awesome!
        
           | leephillips wrote:
           | Even more awesome: vim-repl (https://github.com/sillybun/vim-
           | repl) uses the :term feature to provide convenient
           | communication with any REPL, with extra support for some
           | languages such as Python.
           | 
           | (In fact there are a host of these; for example, vim-slime
           | now can communicate with Vim's built-in terminal.)
        
           | graywh wrote:
           | it hasn't been in Vim very long, added in 8.1 ~3 years
           | 
           | https://www.vim.org/vim-8.1-released.php
        
       | fphilipe wrote:
       | I can highly recommend these tmux plugins that enhance the
       | selection experience:
       | 
       | - https://github.com/tmux-plugins/tmux-yank
       | 
       | - https://github.com/tmux-plugins/tmux-open
       | 
       | - https://github.com/tmux-plugins/tmux-copycat
        
       | rrradical wrote:
       | I wish tmux had the ability to pipe the buffer to some external
       | program, e.g. vim. Their vi-mode is okay, but it's never going to
       | be the same as native vim with my configs, plugins, etc.
       | 
       | That aside, I do really enjoy tmux and appreciate the hard work
       | of the devs!
        
         | ianthehenry wrote:
         | You can do that!                 tmux capture-pane -p -S - |
         | vim -
         | 
         | Or bind that to a key. -p is "print to stdout", -S specifies
         | where to start and - means "the beginning of history" (by
         | default capture-pane just gives you the visible contents). I'm
         | not sure how to do the same thing with the current selection --
         | copy-pipe doesn't seem to work with vim, for some reason.
        
           | rrradical wrote:
           | Thanks, that seems close to what I'm looking for, but I'm not
           | sure how to get a keybind that has behavior similar to
           | scrollback mode. I think tmux is missing the ability to give
           | control over to an arbitrary shell command. For example, if I
           | bind that to a key, I can only run it in the background
           | right?
        
           | vbsteven wrote:
           | In the same vein, I use this in my .tmux.conf:
           | bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \;
           | new-window -n "urlview" '$SHELL -c "urlview < /tmp/tmux-
           | buffer"'
           | 
           | And with that I can just hit `<prefix> u` to pipe the current
           | pane into urlview. Typical use is for example when pushing to
           | a branch and bitbucket prints the URL to create a PR to
           | stdout. I hit `<prefix> u`, `<enter>` and the link is open in
           | Firefox.
        
       | CodeGlitch wrote:
       | One thing I've tried recently is running the terminal command
       | inside vim. You have vims features of tabs and windows, plus
       | being able to copy and paste between the terminal and editors all
       | within vim. I'm still undecided if this is a good workflow or
       | not.
        
       | seqizz wrote:
       | I'm using extrakto[0] for it, so far it works nice.
       | 
       | [0]: https://github.com/laktak/extrakto
        
         | ianthehenry wrote:
         | That looks great! Someone also pointed me at tmux thumbs, which
         | takes a more vimium approach to this. I've got to try both of
         | these.
         | 
         | https://github.com/fcsonline/tmux-thumbs
         | 
         | asciinema demo here:
         | 
         | https://asciinema.org/a/232775?autoplay=1
        
         | nandkeypull wrote:
         | extrakto is really a "killer" plugin. I'm starting to wish for
         | an emacs plugin with similar functionality.
        
         | betoharres wrote:
         | i use this plugin everyday for my workflow; it's amazing how
         | fast I became to copy/paste things from terminal. Sometimes I
         | don't even see what's being shown, I just type and hit enter
         | and I know that text is copied.
        
       | tjoff wrote:
       | Only glanced at it but didn't see it mention 'V' which selects
       | rows rather than characters. Which can be quite useful.
       | 
       | There are also tmux plugins to make some operations smoother.
       | 
       | https://github.com/fcsonline/tmux-thumbs
       | 
       | Like keyboard driven browsers uses hints, so file paths, git SHAs
       | etc. are highlighted using a small hint and if you press it it is
       | copied.
       | 
       | https://github.com/laktak/extrakto
       | 
       | Fuzzy search in current pane to insert/copy things of interest.
        
       | jcard wrote:
       | Using the tmux vi keybindings to copy and paste between panes is
       | great if you haven't tried it.
       | 
       | This copy/paste workflow is really nice for working with
       | kubernetes on the command line.
       | 
       | E.g., imagine that you need to delete a kubernetes pod.
       | 
       |  _You 'd run a few commands like this:_
       | 
       | 1. `kubectl get pods`
       | 
       | 2. Find the pod id, and copy it using mouse & some shortcut
       | 
       | 3. `kubectl delete pod <pasted-pod-id>`
       | 
       |  _Instead of this mouse workflow, you could do something like
       | this in tmux:_
       | 
       | 1. `kubectl get pods`
       | 
       | 2. Find pod id, `Ctrl+b [` to enter tmux's vi selection mode
       | 
       | 3. Navigate to the section you'd like to copy; e.g. `k6ww` (up
       | six lines and over two words, for example)
       | 
       | 4. Press space bar to start selection, and use common vim
       | movements to highlight what you'd like to copy (e.g. w or $)
       | 
       | 5. Press return/enter to copy the selection
       | 
       | 6. This text can be pasted with either Cmd/Ctrl+v (it gets copied
       | to the system clipboard for me on macOS 11.2.1 with tmux 3.1c_1
       | from brew), or using the default tmux shortcut `Ctrl+b ]`. So
       | that would allow you to type `kubectl delete pod Ctrl+b ]`.
       | 
       | So yeah, it's a few more steps, but it's a lot faster for me.
       | 
       |  _These are the relevant sections of my ~ /.tmux.conf file:_
       | # Use vim keybindings in copy mode       setw -g mode-keys vi
       | # Use emacs keybindings in the status bar       set -g status-
       | keys emacs
       | 
       | (I mention the `set -g status-keys emacs` config line just as an
       | FYI since it's been really helpful for me with tmux. I've never
       | liked using readline-type inputs with vi-mode.)
        
         | nobleach wrote:
         | I think this may be an iTerm thing. By default, using the steps
         | you've posted, the highlighted text will not go to a system
         | clipboard.
        
           | jcard wrote:
           | Ah! Thanks for pointing that out. That's the piece I forgot
           | about here. iTerm is populating the system clipboard from
           | tmux because of the tmux integration [1].
           | 
           | [1] https://iterm2.com/documentation-tmux-integration.html
        
         | Exuma wrote:
         | Can you give me the bare minimum tmux config that does what you
         | are saying? ALl these tutorials in this thread don't do
         | anything (i just installed tmux and I'm using iTerm 3 and oh-
         | my-zsh on OSX). I'm assuming because my tmux config is empty (I
         | also dont want to disable other features like the original link
         | because I use tmux for actually attaching to sessions)
        
           | jcard wrote:
           | AFAIK, you'll need to have at least `setw -g mode-keys vi` in
           | your ~/.tmux.conf file to allow tmux to use vi keybindings in
           | copy mode (`Ctrl+b ]`). Make sure to fully exit all tmux
           | sessions and start a new session after making that change.
           | 
           | I have basically the same setup as you, and I think that's
           | the only thing I've manually configured. I also run the oh-
           | my-zsh tmux plugin, and iTerm2's tmux integration, which
           | seemed to work out of the box for me.
        
           | ianthehenry wrote:
           | The parent describes how to do this with tmux right out of
           | the box -- you don't need anything in your config to get this
           | to work. Did you start tmux? If you haven't set up iTerm to
           | connect to a tmux session by default, any new tabs/splits you
           | make won't be running it. You should be able to tell by the
           | presence of the status bar at the bottom.
        
         | basilisks wrote:
         | This sounds terribly convoluted compared to turning on mouse
         | mode and selecting the text with your mouse. It should copy
         | immediately after you release the button, and you should be
         | able to paste with your standard shortcut if you set up tmux to
         | use the clipboard of your choice.
        
           | simias wrote:
           | Mouse-driven flows are always a little more intuitive and
           | discoverable, but keyboard shortcuts are more precise and can
           | be lightning fast once you have muscle memory.
           | 
           | Listed the way the parent does it seems very complicated, but
           | if you have the sequence memorized and trained it can be
           | executed very quickly and without moving your hands from the
           | keyboard.
        
         | oftenwrong wrote:
         | That's all fine, but why not use kubectl's excellent tab
         | completion?                   kubectl delete pod <tab>
         | 
         | and it lists the pods.
         | 
         | For bash or zsh:                   source <(kubectl completion
         | $(basename $SHELL))
        
           | jcard wrote:
           | That's a fair point! The kubernetes example I gave is
           | somewhat contrived, but I will say that I prefer to have
           | whatever resource id I'm working with in my clipboard vs.
           | relying on myself to select the correct one in a tab
           | completion menu.
           | 
           | Where I really like this tmux copy/paste workflow is for
           | grabbing multiple lines of command output. From there I can
           | paste that into some message on slack, or use it as the body
           | of a PR message that describes some error or shows some
           | output.
           | 
           | For the latter case, I have a zsh function that calls `hub`
           | to open a PR, drops me off into vim, and once I `:wq`, it
           | will send the API request to open the PR, and then open my
           | browser up to it. This is the command I have in the function:
           | `hub pull-request --push --file "$filename" --browse
           | --draft`.
        
         | Leo_Verto wrote:
         | Have you tried k9s [1]? Just being able to run common
         | operations directly on k8s entities is so much better than
         | having to run a separate command. It also uses vi-style
         | hotkeys.
         | 
         | [1]: https://k9scli.io/
        
           | jcard wrote:
           | I haven't tried it, but that looks pretty great! Kind of like
           | a TUI version of something like Lens.
        
       | a-dub wrote:
       | for next level ninja copy paste, use vim-slime to send regions of
       | text from vim into a repl running in a tmux window using
       | bracketed paste mode.
        
       | vptr wrote:
       | I think a more killer feature of tmux is that you can send
       | keystrokes to apps running inside tmux (with send-keys). It just
       | opens a door for scripting CLI apps that otherwise would not be
       | scriptable. e.g. irc clients and similar full screen apps.
        
         | ianthehenry wrote:
         | To add to this, I have used tmux for automated testing of full-
         | screen interactive command-line apps. It comes out like
         | PhantomJS: send-keys + capture-pane is pretty awesome (once you
         | overcome dumb timing stuff).
        
         | cryptonector wrote:
         | You might want to look into expect(1).
        
         | 2OEH8eoCRo0 wrote:
         | That's sick and good to know. I can use that on my current
         | project.
        
       | [deleted]
        
       | alexsuslin wrote:
       | Is there any decent tmux tutorial (more structured than official
       | documentation in case of learning), preferable videos with some
       | exercises?
        
       | 1vuio0pswjnm7 wrote:
       | I prefer to copy text from outside tmux using capture-pane and
       | load-buffer.
       | 
       | Outside tmux, to send buffers to stdout, I use save-buffer.
       | 
       | I usually paste inside tmux. I re-attach then paste with the
       | keyboard sortcut "Ctrl-B ]"
       | 
       | I put tmux commands like capture, load-buffer, save-buffer and
       | list-buffers in one line shell scripts with short names for use
       | outside tmux.
       | 
       | Otherwise typing the commands is too verbose, e.g.,
       | tmux capture -t0 -p|grep -o PATTERN|tmux loadb -;tmux lsb
        
       | avinassh wrote:
       | I use iTerm 2, I like its copy mode[0]. Feels quite natural with
       | mac's keys. Check these simple instructions [1]
       | 
       | 1. Enter copy mode with cmd+shift+c.
       | 
       | 2. Basic Vim keybinding, many keystrokes can active different
       | actions.                  - v to select by character.        -
       | shift+v to select by line.        - ctrl+v for rectangular
       | selection.        - ctrl+space to stop selecting.        - y to
       | yank/copy the selection (also exits copy mode).        - q to
       | exit copy mode.
       | 
       | [0] - https://iterm2.com/documentation-copymode.html
       | 
       | [1] - https://kevinjalbert.com/iterm2-mouseless-copy/
        
       | cauthon wrote:
       | Does this work for a tmux session on a remote host? Seems like it
       | would only work with access to the local system clipboard
        
         | jcard wrote:
         | This should work the same locally & on remote hosts. Tmux
         | doesn't care that you're ssh'd into some host.
         | 
         | As long as your system & version of tmux supports copying to
         | the local clipboard, you should have no problems pasting with
         | either Ctrl/Cmd+v or `Ctrl+b ]`.
         | 
         | Otherwise, if the clipboard is broken for some reason, you can
         | stick to using `Ctrl+b ]` to paste.
        
         | ianthehenry wrote:
         | It... depends.
         | 
         | If your terminal emulator supports the clipboard escape codes,
         | then yes -- it just works, and there's nothing for you to do to
         | set it up. This is because when you hit "copy" tmux just prints
         | a bunch of escape codes, and ssh will re-print the escape codes
         | locally, and your terminal emulator will see them, and know to
         | set the contents of the system clipboard.
         | 
         | If your terminal emulator doesn't support the clipboard escape
         | codes, then you have to configure an explicit copy-pipe
         | command, like this:                 bind -T copy-mode-vi y send
         | -X copy-pipe 'xclip -i -selection clipboard'
         | 
         | And that will work on a remote tmux, as long as you ssh to the
         | remote server with X forwarding (ssh -X or -Y).
         | 
         | If you're not using X _and_ your terminal emulator doesn 't
         | support the escape codes, then I _think_ the answer is no. Like
         | if you 're using a Mac and using Terminal.app instead of iTerm,
         | I'm not sure how you would make this work.
        
           | bryogenic wrote:
           | I took this tmux config line to the next level because:
           | 
           | - I want it yanked into both the selection AND the default
           | clipboard
           | 
           | - I want tmux to exit copy mode after yanking
           | bind -T copy-mode-vi y send -X copy-pipe-and-cancel 'xclip
           | -in -selection default; xclip -o | xclip -in -selection
           | clipboard'
        
       | forgotpwd16 wrote:
       | Urxvt users can use the keyboard-select Perl extension instead.
        
         | jolmg wrote:
         | Biggest reason why I stick to urxvt.
        
       | jhvkjhk wrote:
       | I think the most intuitive way to select and copy is selecting
       | with mouse and click the middle button to paste.
       | 
       | Tmux don't support this with `set -g mouse on`, but you can add
       | this to your tmux.conf:
       | 
       | ``` unbind-key MouseDown2Pane bind-key -n MouseDown2Pane run
       | "tmux set-buffer \"$(xclip -o -sel clipboard)\"; tmux paste-
       | buffer" ```
       | 
       | However, this only works fine within tmux alone. When you select
       | text in tmux, you can't use middle button to paste them into
       | other programs, the opposite is the same. I don't know why.
        
         | ianthehenry wrote:
         | If you set up this binding:                 bind-key -T copy-
         | mode-vi MouseDragEnd1Pane send -X copy-pipe-no-clear 'xclip -i
         | -selection primary'
         | 
         | (or -T copy-mode, if you use emacs-flavored tmux)
         | 
         | Then you can paste your tmux selections into other programs
         | with middle-click -- I think by default tmux only uses the
         | "clipboard" selection, but middle click pastes the "primary"
         | selection.
        
           | jhvkjhk wrote:
           | Wow thank you, this binding works very well! It used to be
           | very annoying to copy-paste between tmux and other softwares,
           | but there won't be any problems in the future!
        
         | yomly wrote:
         | Presumably you need some callback attached to tmux set-buffer
         | to make an xclip -i call
         | 
         | But my tmux-fu isn't really up to scratch on how you do that...
        
           | jhvkjhk wrote:
           | Thank you, the author gives a working binding in another
           | reply(https://news.ycombinator.com/item?id=26669079), and the
           | binding uses xclip -i like you said.
        
       | [deleted]
        
       | bassdropvroom wrote:
       | Two things I've struggled to get working on my tmux is with mouse
       | selection. While I use the keyboard way more, sometimes a mouse
       | is easier.
       | 
       | Anyway, when I select something with a mouse, it is not possible
       | (or at least I've not found a solution) to let go of the MB1, and
       | that automatically quits visual mode. And the other thing is when
       | you scroll down to the bottom, it automatically quits visual
       | mode.
        
         | ianthehenry wrote:
         | You can have your mouse copy and get you out of copy mode like
         | this:                 # native mode, if your terminal supports
         | it       bind-key -T copy-mode-vi MouseDragEnd1Pane send -X
         | copy-selection-and-cancel            # or if you're using X,
         | and want it to work like any other program       bind-key -T
         | copy-mode-vi MouseDragEnd1Pane send -X copy-pipe-and-cancel
         | 'xclip -i -selection primary'
         | 
         | The scroll thing is a little hairier looking:
         | bind -n WheelUpPane if -Ft= "#{mouse_any_flag}" { send -M } {
         | if -Ft= "#{pane_in_mode}" { send -M } { copy-mode -t= }
         | 
         | That's just the default binding for WheelUpPane, except using
         | bare copy-mode instead of copy-mode -e (-e is auto-exit when
         | you scroll to the bottom).
        
       | yoz-y wrote:
       | Is this different from the ctrl+[ ctrl+space ctrl+b ] workflow?
       | as those are not mentioned.
        
       | lou1306 wrote:
       | I'm probably an outsider here, but as an iTerm user my usual way
       | to copy short pieces of text from tmux is to just disable mouse
       | reporting, select the text with my mouse, and do the good old
       | cmd-c. Not really a sophisticated approach but it gets the work
       | done, and works just as fine on remote tmux sessions.
        
         | mdaniel wrote:
         | If you weren't already aware, you can just drag the selected
         | text slightly and it will retype it at the current prompt
         | position, without dirtying your clipboard. QTerminal does the
         | same on Linux, and likely other terminal emulators, too
         | 
         | Or if you are copying it out of iTerm, replace "slightly" with
         | "to the other terminal" :-)
        
       | ibraheemdev wrote:
       | Alacritty has this feature too (and much more) with vi mode [0].
       | 
       | 0:
       | https://github.com/alacritty/alacritty/blob/master/docs/feat...
        
         | colordrops wrote:
         | Alacritty is a different thing from tmux. Alacritty is a
         | terminal, tmux runs in a terminal. They go well together.
        
           | ibraheemdev wrote:
           | I understand that. My point is, if you use tmux only to copy
           | paste text, know that terminal emulators can do that too :)
        
         | ianthehenry wrote:
         | Oh, cool! I've never heard of alacritty.
         | 
         | I tried playing with it but it doesn't seem to recognize my
         | control key (???) which makes a lot of things... hard. A quick
         | google and glance through the settings didn't reveal any likely
         | culprits, but I expect it's some macOS thing. Anyone know
         | what's up with that?
        
           | vulcan01 wrote:
           | Most (all?) Alacritty commands use the command key on Mac:
           | command+c to copy, etc.
           | 
           | Or maybe it's something with .alacritty.yml or keybinding?
        
             | ianthehenry wrote:
             | Yeah, I couldn't figure it out looking through the default
             | alacritty.yml. I'm not trying to use the normal system
             | shortuts, but like, ctrl-d to EOF and ctrl-c to SIGINT and
             | that sort of thing.
        
           | petepete wrote:
           | Not really answering your question but you might have more
           | luck with Kitty. Like Alacrity it's very fast but Kitty has a
           | more features.
           | 
           | https://sw.kovidgoyal.net/kitty/
        
       ___________________________________________________________________
       (page generated 2021-04-02 23:02 UTC)