[HN Gopher] Customizing tmux
___________________________________________________________________
Customizing tmux
Author : EPendragon
Score : 71 points
Date : 2025-08-04 15:41 UTC (7 hours ago)
(HTM) web link (evgeniipendragon.com)
(TXT) w3m dump (evgeniipendragon.com)
| sjbr wrote:
| you could also use Oh my tmux!: https://github.com/gpakosz/.tmux
| EPendragon wrote:
| I have checked it out initially. It hd a good set of defaults.
| I didn't like everything that came with it, but I did read
| through its config file and borrowed a couple of lines from
| there into my own setup. IMO the problem with using a prebuilt
| config like that is that it requires you to learn all of its
| keybinds, styling, layout. I would rather build my own
| incrementally but have a sense of knowing everything that is
| going on in my setup.
| benrutter wrote:
| I love tmux! Using it as a tool suddenly enabled me to do so many
| things. Lately I've been using Zellij, which I'd massively
| recommend for anyone _not_ wanting to do a load of customisation.
| It just works great out the box (but probably has less wiggle
| room to "make your own")
|
| https://zellij.dev/
| EPendragon wrote:
| I will definitely check it out. Thanks for the suggestion! What
| would you say is different between tmux and Zellij, and why did
| you start using the latter?
| imcritic wrote:
| Another ex-tmux user here: for it was text selection with
| mouse without extra line breaks, introduced by line wrapping
| when long strings are rendered.
| EPendragon wrote:
| I gotta admit that the initial experience in copy mode in
| tmux made me cringe a lot. The fact that scrolling up
| scrolled through the history of the terminal's commands was
| the most unexpected thing. After I enabled mouse use, it
| became usable for me.
| benrutter wrote:
| If you've used Neovim vs Helix, I'd say the comparison is
| pretty close.
|
| Tmux is more customisable, but a lot messier out the box.
| It's much older so has picked up a little cruft along the
| way.
|
| Zellij is newer so has the benefit of being a clearer
| implementation. But it's designed as an "out the bix"
| experience, not one you can customise to your hearts content.
|
| Edit: if you did want to try out zellij, I should point out
| there's a "no install, try in shell" option on their
| website's main page which is a super quick way to get a
| taste!
| EPendragon wrote:
| > Tmux is more customisable, but a lot messier out the box.
|
| I have definitely felt that. Customization wasn't
| necessarily straightforward - just required some time spent
| reading the docs.
|
| I appreciate the heads up about the "no install, try in
| shell" option. I will make sure to take a look!
| EPendragon wrote:
| I feel that "make your own" has been the major driver behind
| looking into the configs myself. Learning other configs feels
| like a chore. I would rather learn and make it as I go. In the
| end I will have a sense of complete ownership. I will know what
| needs to change if I decide to change it. I think investing
| time into making your own wins in the long run.
| mikepurvis wrote:
| The article is focused on interactive use, but I would be
| interested to also hear from folks using tmux as a process
| manager / dashboard for server-type environments. I was pretty
| unenthused about this practice when I first encountered it, but
| it's grown on me as a way to quickly get a sense of state from
| onboard a running system without having to rely on off-board
| dashboard or log parsers / alert systems.
|
| In particular, I'm curious about libtmux/tmuxp and how well it
| works to have a more declarative bringup than just a bash script
| launching things into the background and then attaching tmux
| windows to them.
|
| And I guess the broader question of whether this approach is an
| evolutionary dead end-- like does it just become a pile of hacks
| as one discovers the need for restart policies, backoffs,
| ordering, whatever other stuff that is built into a "normal"
| process manager like systemd or runit? If you _do_ end up wanting
| to send process stdout /stderr elsewhere or do alerting, is that
| now annoying if those streams are "trapped" in tmux sessions vs
| being written into log files or the journal?
| kachapopopow wrote:
| yep, that's how roughly 99.99% of major minecraft servers are
| ran up to this day. (and I hate migrating them)
| Filligree wrote:
| Systemd just does a poor job giving you a TTY on demand.
| hnlmorg wrote:
| I've seen people use this approach (and screen too) but
| personally I hate it for anything other than services that are
| interactive but you want detachable. Eg long running installs.
|
| All the other examples I've seen where people have used it as a
| shortcut for daemonizing a service, it's felt like just as much
| effort as writing a systemd service file.
|
| I guess I could forgive people more back in the days of sysv-
| style initd. Writing those shell scripts was seldom fun. But
| with systemd, it's literally a 5 minute task. And I say that as
| someone who dislikes numerous decisions made regarding the
| approach systemd takes.
| accrual wrote:
| > I would be interested to also hear from folks using tmux as a
| process manager / dashboard for server-type environments
|
| Sure! I use tmux on most of my OpenBSD systems and copy the
| same .tmux.conf file around, but rarely tweak it other than to
| set a hostname.
|
| My status bar is at the top and looks approximately like this:
| --~ msg auth pf hostname. Mon Aug 04 15:05
|
| * The first two windows (--) are regular shells.
|
| * The tilde window (~) is where I do stuff as root.
|
| * The message window (msg) tails `/var/log/messages` and
| `/var/log/daemon`, or `journalctl -f` and `journalctl -k -f` on
| Linux.
|
| * The auth window (auth) tails `/var/log/authlog` to monitor
| login attempts and usage of doas and sudo.
|
| * The pf window (pf) runs a script to monitor the packet filter
| rules (pass, block, match).
|
| * hostname is just the hostname. The period (.) means no mail,
| it turns to an exclaimation mark (!) when I have mail.
|
| * Simple date/time.
|
| This setup gives me quick access shells, important logs, mail
| status, date/time, and works the same on every server I manage.
| I add extra windows to tail other app logs as needed.
| quesera wrote:
| > _but rarely tweak it other than to set a hostname_
|
| In case helpful: You can use `#h` in a status line string to
| get the hostname
| godelski wrote:
| So many people miss the point of tmux.
|
| The only reason to still use tmux (or screen) is because you use
| remote sessions. All modern terminal emulators are already
| capable of doing tabs and panes (okay, maybe not sessions, but
| some can locally). If you're using tmux for this reason, stop. Go
| pick up a modern terminal like ghostty, Alacritty, or WezTerm.
|
| But why tmux still exists today is because people are working on
| computers they aren't sitting in front of. Because I don't want
| to have to be running nohup or detaching, moving to the
| background, and resetting the session so error messages don't
| appear in my active instance. Hell, technically I can do this
| with vim and get something pretty similar to tmux by using the
| terminal. But that's a pain.
|
| Tmux is for * _terminals*_
| EPendragon wrote:
| For me tmux ended up being the solution for my dev needs. With
| a little bit of time, I learnt the ropes and became more or
| less productive with the default setup. Afterwards, I made it
| my own.
|
| Like you mention, tmux sessions was one of the biggest features
| that I enjoyed about this tool: it does the job and does it
| well. Aside from that I love that I can use Vim-bindings with
| it, that it feels very similar to Neovim for me, so using them
| together is a no-brainer. Learning a couple of specific
| keyboard shortcuts is all it takes to make me productive.
|
| I haven't needed to use a remote session yet like you note.
| While working with tmux locally I have learnt about all of
| these other features that I will definitely be looking forward
| to using once the opportunity arises.
|
| I don't doubt that tools like ghostty, Alacritty, or WezTerm
| are great. I have heard lots about the first two. And I do
| intend to check them out.
|
| What would you say is your favorite terminal and why as it
| relates to local development experience use? Are there features
| that these tools have that tmux lacks?
| godelski wrote:
| > What would you say is your favorite terminal
|
| So far, ghostty. I do also like Alacritty and WezTerm, and
| think kitty is overhyped (and Warp is a privacy nightmare). A
| thing I really like about ghostty is it is incredibly easy to
| maintain. By far my smallest config file. Basically my theme
| and a few custom bindings. To be honest, there isn't a huge
| difference between all of them, with some being better at one
| thing than another, but I think ghostty gets things good all
| around.
|
| Btw, vim bindings should already be available in your
| emulator, without the need for tmux. You can set bash to use
| them (set -o vi) but I suggest migrating to zsh if you like
| using the cli. I'll also give you one fun command most people
| don't know. While holding control, press x then e (if you are
| already using zsh you might need to add `zle -N edit-command-
| line` to your rc file but <C-x><C-e> needs no config in
| bash). I guess I should also mention that in vim you can open
| a terminal (:help term) > why as it relates
| to local development experience use?
|
| All these emulators can do, locally, everything tmux can do
| _and_ more. You just have to remember that a session is the
| same thing as a window. All these emulators have tabs and
| splits. So there is no real advantage to tmux.
| > Are there features that these tools have that tmux lacks?
|
| First off, switch because your emulator is probably more
| resource intensive. It may also be missing modern features
| like being able to view images (see sixel, chafa, or the
| kitty graphics protocol), ligatures, and a lot of other
| features.
|
| Second, tmux lacks many of these modern features. Doing a
| passthrough can help but dealing with images is not a great
| experience. I have found no configuration where I can
| reliably view images and never have been able to produce
| images of the same quality. I always drop out of my session
| if I am entering a file browser like yazi or fzf (I'll use
| fzf but it limits the capabilities of previewing).
| EPendragon wrote:
| Appreciate the detailed answer! I will need to take a look
| at different terminals to see if there is any other one
| that can better fit my needs.
|
| I prefer the idea of having one tool to manage everything:
| from local flow to remote sessions. And I usually do not
| view images in the terminal. But I'm willing to put them to
| the test and see if I like one of those more.
| godelski wrote:
| > I prefer the idea of having one tool to manage
| everything: from local flow to remote sessions.
|
| This is still achieved. But as outlined here and
| elsewhere, a single extra keypress is not so much a
| hindrance as it is a reminder of be being local vs
| remote.
|
| I'll add that your muscle memory will adapt to whatever
| pretty quickly. Like I was switching between a mac and a
| linux machine with a keyboard frequently and it only took
| a week to forget where my pinky needed to go to hit ctrl.
| Same is true even if your bindings for whatever are not
| identical local or remote (though mine are very similar,
| just differing in the prefix). So I'd say when testing
| things make sure you include a burn-in time, otherwise
| _any_ change is going to make all other options feel
| worse. > I usually do not view images in
| the terminal.
|
| I work in computer vision (ML) so this is a very useful
| feature. But given that essentially everything else is
| the same, things don't really feel that different when
| remote vs local. Just a little purposeful visual
| indication and a different prefix (which is on purpose).
| apazzolini wrote:
| > The only reason to still use tmux (or screen) is because you
| use remote sessions
|
| Do you think it's possible that someone might have a different
| workflow from you and tmux fits their use case in a way you
| haven't thought of?
| godelski wrote:
| Yes, of course. What I'm trying to communicate is that if
| you're just doing things locally you can get all the benefits
| (sin sessions) from modern terminal emulators. Most people
| are using panes and tabs but switching to another terminal
| emulator will get you these and much more. If you're using
| the default terminal emulator, you should probably switch
| (you're installing a program anyways, right?).
|
| That said, I still use tmux. Almost every day in fact.
| Because all my work is being done on a machine I'm not
| sitting in front of. This even includes at home. My main
| desktop is connected to a TV for videogames and movies. When
| I want to do work on it there's no difference if I'm sitting
| in front of my laptop or it other than it sitting in my
| livingroom keeps it cooler and gives it better air flow.
|
| Edit:
|
| Locally: my terminal emulator (ghostty) can do everything
| tmux can. I can do sessions (windows), panes, tabs, and all
| that. But with ghostty I also get images, a lower memory
| footprint (than stock emulator), lower CPU usage (than stock
| emulator), ligatures, and everything else. It is strictly
| better.
|
| But I can't do {widows,panes,tabs} with remote connections.
| Hence, tmux. Which in that case, I will frequently give up
| capabilities (like images) for that.
| newlisp wrote:
| You don't mention the persistence of tmux sessions, which I
| find very useful for local development. Does ghostty have a
| client-server architecture too?
| godelski wrote:
| You mean like `window-save-state`[0]? (Windows and
| sessions are the same thing)
|
| You don't need a server to handle this feature. Using a
| non-server solution even allows restoring after power
| cycles!
|
| [0] https://ghostty.org/docs/config/reference#window-
| save-state
| quesera wrote:
| Using tmux locally lets me use a single interface and
| interaction model for multiple sessions, regardless of whether
| they are local, remote, or a mix of both.
| kombine wrote:
| I always find it annoying to manage nested tmux sessions so I
| usually use Kitty's keyboard driven tab management and tmux
| for server side sessions.
| EPendragon wrote:
| It is interesting to see that you use tmux and Kitty
| together. Is it faster or more convenient than using just
| one tool?
| quesera wrote:
| I have a status line indicator to show whether tmux is in
| Control mode.
|
| So, even when nested, it's always clear what will happen.
| One nested session (two total) is manageable. Adding
| another gets annoying, but the need is rare.
| godelski wrote:
| I've also tried the status line indicator but it's
| difficult to balance between being too visible and
| invisible. So just leads to doing the right commands on
| the wrong session. Though I find any nested session is
| rarely needed. I mean locally, a session is a window so I
| do that.
| quesera wrote:
| I haven't had a problem with indicator visibility, but I
| remember spending some time getting it to a place that
| worked for me.
|
| Here's what I use: set -g status-left
| "#{?client_prefix,#[bg=colour76]^,#[bg=colour235]_} [#S]"
| set -g status-right ' | #[fg=colour76]#h#[fg=default]
| %H%M%Z'
|
| Right side included just for completeness. The
| conditional colour setting was the useful part, IIRC.
| godelski wrote:
| I don't mean rendering of an icon so much as I mean that
| humans become blind to persistent things (and frequent
| things). Losing glasses on your head kinda thing. I don't
| find a mirror as helpful as having a fixed location to
| put my glasses when I'm done with them. Same strategy
|
| But yeah, when I didn't have splits and things in my
| emulator I used something like you did. Make a remote
| section visually distinct. To a lot of extent I still do,
| just this isn't necessary through tmux anymore
| godelski wrote:
| I'm not quite sure I understand your pattern. Can you explain
| it more so I can better understand? Maybe I'm missing
| something and I'm always looking to improve my workflow.
|
| Locally, I don't get the point. I can do tabs and splits. A
| session? That's another window. I can also hide that and use
| keyboard shortcuts to navigate towards it. Am I missing a
| local benefit?
|
| The session is the thing I use, and I do use tmux every day,
| but I exclusively use it when in ssh as on a local machine I
| have everything I need. You mention the hybrid, but isn't the
| point that the connection is ephemeral? We don't exactly want
| to keep it alive unless we are actively using the connection,
| right? This is what I'm not understanding about your mixed
| scenario. What is the difference between what you do and me
| just opening another pane in ghostty and doing the ssh there.
| I can't detach from ghostty, but I can save the window state
| (or move to a different window in a different workspace or
| just cycle through windows like I would a session) so when I
| quit it it resumes, but honestly, I rarely quit it. Keeping a
| remote connection alive while there's no active usage seems
| like a waste and it's just going to disconnect when I walk
| away from my machine anyways. So what is the difference?
|
| I do find sessions tend to get unruley easily, and more
| easily than windows just do to being hidden another level
| deeper. It's not too bad when single user, but I'd still
| suggest organizing tabs over multiple sessions, in most
| cases. That's because it is easy to just leave something like
| an editor open and accidentally overwrite files. Someone just
| logs back in after awhile and types :x into vim (or :x!)
| without thinking. It's also just too easy to let sessions
| stale. I haven't worked with a single person (myself
| included) who did not have a tmux session that was inactive
| for at least a month more than their last login time. (Better
| than all the hanging VSCode sessions though) That's like
| people using srun to run slurm jobs instead of submitting a
| batch job into the queue. That's totally fine to do when
| you're sitting in front of the sim but if you walk away and
| the code errors or just ends before your session ends then
| you're just hogging a machine that could be used (there
| wasn't even a benefit to this either!). Locally, it's pretty
| much the same thing except locally I can do all my tabs and
| splits and sessions without tmux.
| Zizizizz wrote:
| I use ghostty and native splits, however there is no way to
| move a pane to a new tab. Which you can do in tmux very easily.
| That's one thing I wish it could do.
| godelski wrote:
| While this doesn't address that issue you can move a tab to a
| new window (session) as well as merge. I do wish this feature
| existed, but I use it so rarely that honestly I don't notice.
| Rarely are more than one pane essential in a given tab, so
| usually I solve this by cleanup. But yeah, I will acknowledge
| that limit.
| urquhartfe wrote:
| > okay, maybe not sessions
|
| Okay, but sessions are one of the best things about tmux.
|
| Sessions aside, in my opinion tmux's flow is just better than
| terminal emulators I've tried. It slots into my brain in a way
| no terminal emulator's tabbing support ever has, and I have
| never found a terminal emulator who supported keybindings in
| such a sophisticated and seamless manner as tmux does.
|
| I also concur with other commenters, who mention that having
| uniform multiplexing of shell windows between local and remote
| environments is super useful for muscle memory.
| accrual wrote:
| > having uniform multiplexing of shell windows between local
| and remote environments is super useful for muscle memory.
|
| Yep, this is why I use the same .tmux.conf on my servers and
| my local machines. I don't have to care about my terminal
| emulator - I might be using a fully featured Windows Terminal
| or iTerm, or I might be using xterm or st on some spartan
| system. My navigation works the same everywhere.
| godelski wrote:
| > My navigation works the same everywhere.
|
| Is this really a requirement of tmux though? I have
| essentially this. Essentially, because I purposefully
| change my prefix for my emulator to remind me if I'm local
| or remote (tmux), but other than that it is fairly uniform.
| EPendragon wrote:
| Keybindings and uniform experience across machines is what
| does it for me.
| godelski wrote:
| > Okay, but sessions are one of the best things about tmux.
|
| Locally or remotely? Remotely I fully agree. But remotely I
| can't open a new window and my machine doesn't have different
| workspaces. > Sessions aside
|
| I'm curious about this actually. The opposite has been true
| in my experience. What keybindings are you missing? I can
| keybind essentially any script I want or any set of
| keystrokes. > uniform multiplexing of shell
| windows between local and remote environments is super useful
| for muscle memory.
|
| I actually have the opposite experience. I mean I can bind
| ghostty splits to be identical to my tmux bindings, that's
| not an issue and trivial to merge. But I keep them separate
| because it contextualizes if I'm "here" or "there". Similarly
| I ensure that remote sessions have a different PS1 line so
| there are visual indications of where I am other than one
| small icon. Without this I find that it is easy to forget
| which machine I'm in. Had too many problems where I was
| running commands on one machine thinking I was in another.
| osmsucks wrote:
| I would mostly agree, but I like that I can use tmux locally
| _and_ remotely and thus have the same interface wherever I do
| my work (and regardless of what terminal I use).
|
| Then, there's the fact that some terminals capture too many
| keybindings and get in the way of some terminal code editors
| I'd like to use (e.g. recently I was again trying to use flow
| <https://github.com/neurocyte/flow> and its next-tab and
| previous-tab shortcuts clash with Ghostty's). If I had a
| terminal that 1) was nothing but a black box with the
| capability to display Unicode font glyphs and ligatures
| correctly, 2) works under Wayland, and 3) captures as few
| keybindings as possible, I'd use it locally with tmux and live
| happy.
| godelski wrote:
| > I like that I can use tmux locally and remotely and thus
| have the same interface wherever I do my work
|
| The reason I don't do this (even though a trivial config
| could make this possible) is I want more indications that I'm
| remote vs local. I'll even change the remote status bar
| (sometimes theme) so there's more visual indication (an icon
| helps, but it quickly becomes invisible, just like the
| hostname). To be clear, I don't have a pattern for every
| machine, just 2: local vs remote. Everything remote starts
| with my tmux binding (<C-b> sucks and requires an absurd hand
| movement, so I use <C-s> because who freezes these days?).
| With this I still keep all my muscle memory but have a clear
| signal of "remote vs local" and prevents silly mistakes.
| > (e.g. recently I was again trying to use flow
| <https://github.com/neurocyte/flow> and its next-tab and
| previous-tab shortcuts clash with Ghostty's)
|
| I don't think I understand this example. There's only so many
| keybindings and clashes aren't uncommon. There's only 45
| control commands (without shift or f-keys) and less than half
| are convenient due to reach (<C-6> sucks!). Even fewer when
| you start thinking about "sane defaults" and unfortunately
| those are biased by the past, so collisions become more
| likely.
|
| Like I use vim so frequently hit <C-w> while typing and when
| I'm not on mac I kill browser tabs (probably for the best
| lol). But the benefit of all CLI programs is the config.
| There's no "one-size-fits-all" solution, so having
| configuration is the next best thing. > If I
| had a terminal that
|
| I'm not sure what emulator doesn't meet these goals. Foot is
| a barebones solution, so that might be good for you. But if
| the issue is clashing with keybindings then that's an
| unavoidable problem, though luckily solvable. At least the
| emulators tend to provide better flexibility in this respect
| than most programs do.
| osmsucks wrote:
| > I don't think I understand this example. There's only so
| many keybindings and clashes aren't uncommon.
|
| That's precisely my point! Many terminals these days try to
| do too much and by default end up capturing keybindings
| that I want to use for _something else_. The terminal
| should allow me to do that something else, not get in the
| way. A simple terminal wouldn 't get in my way and I could
| insert tmux in the more complex scenarios (even for local
| sessions). I know I can reconfigure most terminals, but not
| everything is configurable, plus everyone knows the best
| tools are the ones that don't require to be reconfigured to
| be great. :)
|
| Thankfully my main editor is Helix and by default it
| doesn't clash with anything because it's a modal editor
| where commands are regular keystrokes and not key
| combinations.
|
| > Foot is a barebones solution, so that might be good for
| you
|
| I'm aware of foot, and it works fine, but it doesn't
| correctly display the fancy icons used by foot (and other
| programs). For a visual comparison, here's foot on the
| left, Ghostty on the right: <https://v1.imgpaste.net/images
| /public/21baee04-b4a5-4693-8a8...>
| godelski wrote:
| > The terminal should allow me to do that something else,
| not get in the way.
|
| What terminal gets in the way? If there's a clash you do
| a remap.
|
| I mean I really don't understand. Do you expect the
| terminal developer to know all the keybindings you
| currently use and will use in the future? That's a really
| big ask! Or are you asking that the terminal comes with
| _no_ keybindings? I can understand that one, but I think
| it is not going to be popular. For most people that means
| _more_ configuration. You can disable anything you don 't
| like. > Thankfully my main editor is
| Helix
|
| FWIW I don't have clashes with vim despite vim having
| both of those > I'm aware of foot
|
| What font is foot using? It's been awhile, but I don't
| remember having this issue with foot. But IIRC on foot,
| and some other terminals, they don't know to use a nerd
| font by default or maybe just fail to find or prioritize.
| triyambakam wrote:
| Setting a single key as my leader 10 years ago has been really
| nice. Personally it is back tick for me, but space is probably a
| good one too.
| EPendragon wrote:
| For me, I use Spacebar as a leader key in Neovim, so I think
| they would conflict.
|
| Does it ever create issues for you if you need to type the
| backtick in the terminal?
|
| I found that Ctrl-A does a great job: it is conveniently
| located in relation to other keys that I need to interact with
| after I activate the prefix, and is in general easy to use.
| xiaomai wrote:
| I also use backtick for my tmux leader key. It doesn't create
| issues for me in the terminal (but you need to tap it twice
| when you want a literal backtick). This became natural for me
| pretty quickly.
| EPendragon wrote:
| Good to know. Thanks for the tip!
| homebrewer wrote:
| Ctrl+A conflicts with readline's "go to the start of line"
| (unless you're using vim key bindings in your shell, which I
| find uncomfortable).
|
| I've been using Ctrl+Q, it replaces an almost completely
| useless key combo (flow control if I'm not mistaken), and is
| easy to press.
| aaronbaugher wrote:
| I use F2. Doesn't sound convenient, but it's just the right
| distance that when I reach out my middle finger hits it
| accurately.
| hnlmorg wrote:
| I use F2 too. I can't even remember why I started using it. I
| think maybe because KDE already had a similar binding so it
| because my de facto control pallet binding back before
| control pallets were a thing.
| alfiedotwtf wrote:
| When I was a Vim user, tmux was always the first thing I ran when
| connecting to a machine...
|
| But the after moving to Emacs and using Tramp for remote
| sessions, followed by VS Code with its built-in session
| management, I never feel the need to even leave the editor let
| along manage sessions
| jnpnj wrote:
| I just found out about https://stackoverflow.com/a/52838493
| Host myhost Hostname host User user
| RequestTTY yes RemoteCommand tmux new -A -s foobar
| homebrewer wrote:
| This breaks rsync & many other things that rely on SSH as
| transport. Try: alias ssh="ssh -o
| RequestTTY=force -o RemoteCommand='tmux new -A -s foobar'"
| idatum wrote:
| Or just use a different myhost, like "t-myhost" (i.e.
| myhost != hostname)?
| homebrewer wrote:
| Which would require creating a couple of hundred (in my
| case) duplicate host aliases instead of adding one shell
| alias that can be used with any host, including those not
| mentioned in ~/.ssh/config.
| godelski wrote:
| You can resolve this with a conditional. See the `Match`
| keyword.
|
| Though I agree, probably not the best solution to start
| all sessions with tmux. There's other issues it can
| cause.
| valcron1000 wrote:
| How do you deal with persistent sessions in VSCode? I have a
| remote VM to which I connect through SSH using VSCode, but I
| need to have certain programs running even after I disconnect
| from the VM. It's the only reason why I use tmux and I haven't
| been able to get rid of it.
| EPendragon wrote:
| For me the value in using a tool like tmux is that it remains
| scriptable - startup scripts - and could be used in conjunction
| with other cli tools. The same applies to Vim/Neovim. Both of
| these tools remain unrivaled in regards to combining them with
| other flows and pipelines.
| aboardRat4 wrote:
| >I felt overwhelmed by the very poor default UI that it offers
| and the amount of options and shortcuts that I needed to know to
| operate it well and be productive
|
| Typical Macintosh user.
| EPendragon wrote:
| lol, that's likely part of the problem :D
|
| I have started using nvim about a year ago, and that one also
| took three separate tries before it finally stuck with me :)
| After that, about 8 months ago I found tmux and had a harsh
| "first impression".
|
| These days I enjoy using both of those tools and get more
| excited the more I learn about them.
| EPendragon wrote:
| @HNModerators, I don't know why it was necessary to change the
| title of my post from "Customizing tmux and making it less
| dreadful" to "Customizing tmux". The point of the title was not
| the overview of all of the customization options, but the effort
| to make it more usable, convenient, and pleasant to use.
| accrual wrote:
| It may have happened automatically at submission time.
| Otherwise, my best guess is that it appeared like an
| editorialized title.
|
| https://news.ycombinator.com/newsguidelines.html
| EPendragon wrote:
| I have noticed that about an hour ago, so I don't think it
| was automatic. I guess I'm just curious why it was found to
| be against the guidelines or not representative of the topic
| in the post.
| akkartik wrote:
| _" When I first started using tmux, I felt overwhelmed by the
| very poor default UI that it offers and the amount of options and
| shortcuts that I needed to know to operate it well and be
| productive. It took me several tries before I started to feel
| more or less comfortable with it. One of the things that stood
| out to me right away was how dreadful UI looked. Not only it felt
| uninviting, but it almost felt "gatekeepy" - if you don't know
| how to use it in this configuration, then might as well forget
| about it."_
|
| EPendragon elaborate on this. It seems like you understand the
| shell enough to use it productively and customize it to be how
| you like it. The screenshot this quote is talking about looks
| like a shell? In what way is it dreadful, and in what way do your
| customizations make it not dreadful?
|
| For example, it seems like a valid criticism that shells are not
| very discoverable and a prompt and blinking cursor can be
| intimidating to a noob, and that surely applies to tmux as well.
| But then changing the shortcuts doesn't really address that, does
| it?
|
| To me it seems your article is either saying, "tmux is a pig, and
| here's me putting some lipstick on it," :) or the problems are
| not insurmountable, and the solutions are nice but not life-
| changing.
|
| It's great that you like it better now, and we're all having fun
| chatting around it about how we configure our tools here on the
| Hacker News :) But I don't see why it's "dreadful". It's just..
| computers, no? Tmux seems no more gatekeepy than any other aspect
| of computers. And I say this as someone who stopped using tmux a
| few years ago after getting super annoyed with it.
| EPendragon wrote:
| Hey, akkartik!
|
| The initial experience where I saw a lot of elements on the
| screen without knowing what's what was a lot. And sure enough -
| a lot of it had to do with just learning how it works and
| what's what. But in addition to the UI that is unintuitive for
| the beginner, most of the keybindings either didn't make sense
| or were not convenient (talking about prefix).
|
| For example, splitting panes in my opinion are much better done
| with | and - symbols rather than " and %. I can see what they
| were going for with double quotes and the percent sign, but IMO
| vertical line and a hyphen make more sense. I do not need to be
| actively thinking about which one should I use for a vertical
| vs horizontal split.
|
| There was some aspect of "putting a lipstick on it" - for sure.
| Making it more pleasant to look at didn't improve function -
| just looks. I just think making your tools look the way you
| like and enjoy them will create a more pleasant experience and
| help you learn the tool faster too.
|
| The dreadfulness did come from not understanding it completely
| and being a noob early on. Fixing the style and function also
| put me into a process of being intentional about learning how
| the tool works and adjusting things that I didn't like.
|
| And you're right - it is not more gatekeepy that other tools
| per se. I was simply describing my experience and what I ended
| doing about that.
| akkartik wrote:
| Thanks! I'm glad I asked, because there does seem something
| here I can learn from. I care very much about what makes a
| power tool with a high ceiling gatekeepy.
|
| What were the "lot of elements" in the screenshot? Ignoring
| shell stuff, is it the bar at the bottom? Is it the "[0]" and
| the "0:bash*"? The "Macbook-pro" might seem familiar to
| someone familiar to the shell, who is used to seeing it in
| the prompt of an uncustomized shell. The date and time
| likewise seem obvious what they mean. Am I missing anything?
|
| I think the keybindings being non-mnemonic there's only so
| much you can do about. Vim's hjkl were mnemonic on the VT-100
| terminal, but keybindings outlast mortal hardware. So the
| ability to rebind is in some ways the best you can get IMO.
|
| Zooming out, the best power UI I've been able to come up with
| is a combination of a Wordstar-like always-on menu showing
| common keybindings, and a command palette. Here are a couple
| of UIs I've made, I'm curious what you think of them:
|
| https://merveilles.town/@akkartik/108766067153506592
|
| https://github.com/akkartik/mu/blob/main/html/20210624-shell.
| ..
| lemonwaterlime wrote:
| The best way I have found to use tmux is to unbind everything and
| set only the things I use for my workflow. Then the configuration
| (.tmux.conf) becomes the docs.
|
| I was inspired by the "How to Configure tmux from scratch" post
| [1].
|
| I came up with my use cases:
|
| - I want to create sessions
|
| - I want to open and close windows
|
| - I want to create split panes
|
| - I want to use vim-style text select
|
| - etc.
|
| Then I made mappings for the things I care about for my workflow
| specifically.
|
| Before this, I would accidentally hit a keybinding while doing
| something else and not know how I got to that state, taking me
| out of flow to troubleshoot.
|
| Afterwards, only the keybindings I have defined take action.
|
| Now tmux fits like a glove. Because tmux is so stable, I haven't
| had to touch my config in years. It's worth the one time effort.
|
| [1] https://ianthehenry.com/posts/how-to-configure-tmux/
| burnt-resistor wrote:
| I was sad to discover that not all string-like config items
| accept input from external processes. I had to resort to on-the-
| fly sed templating as a hackaround.
|
| Glad that that it supports XDG though.
___________________________________________________________________
(page generated 2025-08-04 23:00 UTC)