3.1a questions and comments

[nicm]

Ask or discuss any quick questions here about 3.1 or 3.1a only please.

Bug reports please open a new issue with full information, see CONTRIBUTING.

tmux 3.1a is a bug fix release of 3.1 which fixes an issue with iTerm2's tmux integration.

A major effort before this release has been improving the documentation outside the manual page, although it is still not complete. See the wiki here. Also see issue #2163 for minor documentation reports and comments.

The 3.1a CHANGES file is here.

---

• There is a known issue with the allow-rename option that can cause tmux to crash. tmux 3.1b will be released in due course to fix this. allow-rename defaults to off.

---

• Note that using a 3.1 client and a running server of an older version may not work reliably. Make sure you restart tmux entirely after upgrading and that you are running the correct binary at all times.

• tmux 3.1 now tries ~/.config/tmux/tmux.conf if ~/.tmux.conf does not exist. If both exist, both will be loaded. $XDG_CONFIG_HOME/tmux/tmux.conf will also be tried in tmux 3.2.

[temporaryrespite]

I'm on tmux 3.1a on ArchLinux, first time I try tmux too, while in vim I notice that pressing Ctrl+RightArrow would act as if I pressed 5C and thus delete the next 5 lines.(EDIT: happens even while in Insert mode!)
In tmux(TERM=screen or TERM=screen-256color or TERM=tmux-256color) and outside of tmux(TERM=xterm-256color in xfce4-terminal), at command prompt, Ctrl+V, Ctrl+RightArrow show the same output ^[[1;5C; even inside vim in insert mode, the same output.

and while writing this, due to adding the above TERM info, I've just figured out the solution(or is it a workaround?):
set -g default-terminal "xterm-256color" brings back the normal behavior and some of the colors that I got used to. I guess it's not a tmux issue then? However, this is probably bad because:

 default-terminal terminal
         Set the default terminal for new windows created in this session
         - the default value of the TERM environment variable.  For tmux
         to work correctly, this must be set to ‘screen’, ‘tmux’ or a de‐
         rivative of them.

Therefore the question still stands: how to make Ctrl+RightArrow work properly in a vim running under tmux?(it's supposed to skip a word) Note that outside of 'vim'(ie. at command prompt) it works as intended.

Another thing: I've to use either screen-256color or xterm-256color instead of tmux-256color because otherwise pressing eg. shift+F3 inside mc will actually press F5 etc.. I guess this is /usr/share/terminfo/t/tmux-256color is owned by ncurses 6.2-1 on ArchLinux, but it also happens on Gentoo sys-libs/ncurses-6.2-r1 (/usr/share/terminfo/t/tmux-256color), so I guess it's a ncurses issue.

[nicm]

screen-256color does not have the extended function keys like C-Right. Does vim work if you set TERM to tmux-256color inside tmux? mc sounds like a different problem.

[temporaryrespite]

sorry for being unclear, the mc thing is a different problem indeed(with one possible solution), and although it seems to imply that I was using tmux-256color as a workaround for the previous problem, that wasn't the case: tmux-256color is the same as screen-256scolor with regards to vim, ie. it doesn't work. I'm so far using set -g default-terminal "xterm-256color" but I'm unsure in what way tmux wouldn't work correctly.

I guess ignore this one(can't repro. anymore)

There was another issue which I didn't mention which got fixed by `set-option -s escape-time 0`, but without it: pressing&releasing Esc and then pressing a number in `mc` would have no effect (though `Esc,1` would sometimes rarely produce an F1, but I couldn't reproduce the condition when it would happen) This is odd, now I cannot reproduce this anymore, that is, without `escape-time` set at all.

Another question: when I press Shift+PageUp(or Shift+PageDown) I get a 2~(for both cases), how can I assign it to do the equivalent of C-b,PageUp instead ?

Another question: How to scroll with mouse wheel inside vim(which has set mouse= in ~/.vimrc) if tmux has set -g mouse on ? outside of tmux, within xfce4-terminal, the vim cursor is the one that moves during mouse wheel.(which is the same thing that happens when set -g mouse off) EDIT: this applies for scrolling in less also.
EDIT: currently I'm stuck with this ugly workaround(so I can scroll both in vim/less via WheelUp(first) and outside them by re-enabling mouse via C-s,m):

set -g mouse on
bind -T root WheelUpPane   if-shell -F -t = "#{alternate_on}" "send-keys -M ; display 'yes send-keys -M didnt work'; set-option -g mouse off" "select-pane -t =; copy-mode -e; send-keys -M"
bind -T root WheelDownPane if-shell -F -t = "#{alternate_on}" "send-keys -M" "select-pane -t =; send-keys -M"  
bind-key m set-option -g mouse on \; display 'Mouse: ON'
bind-key M set-option -g mouse off \; display 'Mouse: OFF'

[temporaryrespite]

screen-256color does not have the extended function keys like C-Right.

given that info, thank you, I'm able to work around it via .vimrc:

if &term == "screen-256color" || &term == "tmux-256color" || &term == "screen" || &term == "tmux"
    map <esc>[1;5D <C-Left>
    map! <esc>[1;5D <C-Left>
    map <esc>[1;5C <C-Right>
    map! <esc>[1;5C <C-Right>
endif

[nicm]

tmux-256color does have the extended function keys and they are identical to xterm-256color, so my best guess is that vim does not look at them - probably it makes assumptions based on matching TERM to xterm*. I had thought it didn't do this anymore - perhaps you could try a newer vim version, try neovim instead, or ask the vim developers?

I suspect mc is doing the same, you will probably need to configure it manually or ask the mc developers.

less does not support the mouse until very new versions which have a --mouse option. The reason it works outside tmux is probably because your terminal sends Up and Down keys for scroll wheel when the application does not support the mouse. tmux does not do this by default, but you can configure it to do so, here is one example: #1610 (comment)

vim should support the mouse, are you sure you are using the right set mouse=? There are a few, I think you might need xterm2 or something like that?

[nicm]

I have added a much simpler example of enabling Up and Down for the mouse wheel here: https://github.com/tmux/tmux/wiki/Recipes#send-up-and-down-keys-for-the-mouse-wheel

[joaofnds]

Anyone having problems with the 🦠 emoji?

tmux set -g status-right "🦠"

This messes up my tmux status and tmux starts to behave strangely

[nicm]

Most likely your terminal and tmux disagree about the width of this Unicode codepoint. Perhaps try 1) upgrading your terminal 2) a different terminal 3) a different emoji 4) building tmux with --with-utf8proc.

[joaofnds]

1. It was working before with the same alacritty version
2. still brakes on macOS terminal and VSCode integrated terminal
3. couldn't find any other emoji that brakes (also didn't try that many)
4. the issue persists

It's not something important to me (obviously), just wanted to point that out because it looked like a regression, since it was working before

[nicm]

Please show me tmux-server*.log from doing this:

tmux -Ltest -f/dev/null new
tmux set -g status-right "🦠"
exit

[joaofnds]

Here it is

[nicm]

1588419350.224629 Unicode 1f9a0, wcwidth() -1

tmux is unable to establish the width of this codepoint (your system wcwidth() returns an error), so it assumes it is width 1. Are you sure this symbol actually is width 1 on your system?

If I print this symbol in iTerm2 and alacritty, it appears to be width 2. Try this outside tmux to see:

printf '1234\na\360\237\246\240b\n'

Are you absolutely sure you didn't upgrade anything but tmux since this was working? Your operating system, terminal, font? Are you certain you weren't using an older tmux built with utf8proc and now have a tmux built without it?

[nicm]

If you could build a tmux 3.0a or whatever older version you were using, verify it still works, then send me a similar server log file, it would be helpful.

[nicm]

If I build tmux with --enable-utf8proc (sorry, not --with-utf8proc) then the symbol works, so perhaps you did have a build with utf8proc before?

[joaofnds]

--enable-utf8proc fixed it! I tried it before but misspelled it 🤦‍♂️

I never built it myself before, I always used Homebrew(aur on linux) to install it. I don't know what changed from my latest installation that caused this.

Thank you so much for the support. I recently spent two days without tmux (not related to this issue) and noticed how integral it is on my workflow, between running tests, scripts on servers and bootstrapping "workspaces" with tmuxinator, I just don't leave tmux anymore. Thank you for all the time and effort you put into it!

[nicm]

Great stuff, thanks!

[temporaryrespite]

Excellent, much appreciated!

unrelated grrr

gawd damn lockbot locked the thread and I can't thumbs that up; it's not like adding thumbs up to already-existing comments sends any notifications or anything! so why not allow it, GitHub?!! not even using github anymore until this fixed...

[boris-petrov]

A question from me too.

Only search the visible part of the history when marking (highlighting)
  search terms. This is much faster than searching the whole history and solves
  problems with large histories. The count of matches shown is now the visible
  matches rather than all matches.

But I really want the old behavior. Is there a configuration option to return it - the part for the count not showing all matches?

[nicm]

No, why do you want a count of all matches?

[boris-petrov]

Well, 1) it's difficult to see immediately when the search wraps around (I have to keep looking at the line numbers for that) and 2) what's the point in having matches count in just the viewport? I can literally count them. That's not useful information for me. I want to be able to know the total count - for statistics, for knowing where in the results is the last result, etc. I can't even begin to explain, it's so obvious for me that this is useful and what is in 3.1 isn't. 😄

[nicm]

1 is a good point, we can maybe show when the search wraps. I don't think 2 is useful, the purpose of searching is not to show statistics, tmux has always been unusual in showing a match count at all, neither emacs nor vi do, we might be best to remove it altogether.

[boris-petrov]

Yes, vim doesn't have it, but when I "grep" with vim I do have it. Having the total amount of results in a search is one of the two basic functionalities of a search - the other one being showing the results themselves.

You had the feature. I think it's pretty important. Why don't you just return it with some option (disabled by default)? Best of both worlds. Pretty please. 😃

[nicm]

Because if we add an option for every thing that one person likes or doesn't like without very good reasons, we end up with an unmaintainable list of a million options that only one person ever uses (I have been there before!). This was changed for a good reason - having regex search is something useful to many people and the fact is that lots of them increase their history-limit and then searching the full history is too slow with even a relatively simple regex. Even without regexs, multiple people have been complaining that search is slow on and off for years.

There are things we could do, for example we could count for up to a short time period instead of only the visible screen, which would mean you would get a full count if your history was short and your search term simple enough.

But this is not entirely trivial to implement and I'm not convinced - I don't really understand why you want it, it doesn't seem like a basic function of search to me at all. Neither of the two applications we take as a model for copy mode (emacs or vi) offers it when searching interactively.

What do you use it that adding "search wrapped" text wouldn't show? How do you manage it in vi when/ and ? don't show you a count?

[nicm]

Let me take a look and see how hard a 0.5 second timeout or something would actually be...

[nicm]

We already have a 10 second timeout that we probably don't need anymore so we could probably just reduce that and just hide the match count when it is hit.

[boris-petrov]

What do you use it that adding "search wrapped" text wouldn't show? How do you manage it in vi when/ and ? don't show you a count?

That's a good question. But keep in mind that Vim and tmux are used for different things. With Vim I edit my source code, for example. With tmux I run tests. It's not that useful, for example, when I'm editing a file, to know how many times "foo" is present. However, when I'm running my tests or some other command with output on the terminal, I would like to know how many times "Exception" has been displayed. Just an example of the top of my head.

Another thing - I never, until you mentioned it, even realized that I've been using Vim without results count (but I do have them when grepping with Vim as I mentioned which is very useful). But I noticed the change in tmux behavior pretty much immediately. It's that important for me. And I read the release notes and noticed the change. So yes, Vim and tmux are used for different things and perhaps that's why they need somewhat different features here and there.

Thank you for the discussion and the time you'll spend on trying to do something about it!

[nicm]

Hmm OK that is reasonable, let me have a look. It is not trivial because we search from top to bottom not bottom to top but we might be able to do it.

[nicm]

Try this please (against master) which will search the visible text then spend up to 100 ms searching the history entirely as well - if it finishes in less than 100 ms you will get a results count, otherwise you won't: tmux-search-count.diff.txt

[nicm]

Actually, it would be better to do it the other way round - try the whole thing first. Hold on...

[nicm]

Try this instead please: tmux-search-count-2.diff.txt

[boris-petrov]

Try this please (against master) which will search the visible text then spend up to 100 ms searching the history entirely as well - if it finishes in less than 100 ms you will get a results count, otherwise you won't: tmux-search-count.diff.txt

This seems to work great! I would change 2 things - 1) if it doesn't finish in 100 ms just show the total count until that point with a plus sign for example - 1/215+ results - instead of not showing anything. It's still more useful and I guess it's not more code for you. And 2) boost a bit the timeout. 😄 Or make it configurable? It worked for my test but I don't know if it will work for 10k history as I have.

I'll try the second diff now.

[boris-petrov]

The second patch works fine too. Not sure what the difference is. I guess my two points are still valid for it too.

Thanks again for your support!

[nicm]

The difference is it doesn't search unnecessarily - if it managed to search everything in 100ms then there is no point in searching the visible text again.

I'll look at (1). I want a short timeout because searching is repeated automatically a lot for example when you scroll. We could bump it to 250 ms probably without too much harm. I don't want an option for this.

[nicm]

I can show 215+ results if we time out but not which result you are on because that result may not have been one of the 215 we found - the count is started from the top not from the cursor position.

[nicm]

OK because it is a timeout the number found can jump around a lot so I just made it show 1000+, 100+ or 10+ instead if it times out otherwise it is just confusing. I also bumped the timeout to 200 ms and will see how it goes.

The easiest way to make it timeout is to make a reasonably big history and then search for . or [a-z]. You will see there is a 200 ms delay every time you scroll. Of course nobody really wants to search for these, but it is easy to do by accident, or to construct a useful regex that also has many matches and is slow to parse.

[nicm]

I've applied this so it is in master now, let me know if you see any problems. Thanks!

[boris-petrov]

Great, thanks a lot!

[sondnm]

EDIT: OK this is weird. I just deleted my tmux-client-12882.log file and everything worked just fine 🤣

Hi. Thanks for the great application.

I have just upgraded from tmux 3.1 to 3.1a using brew and couldn't open tmux any more due to a crash. It exits and outputs weird text tmuM2 3.3.9n. The previous version 3.1 works fine

• terminal: iTerm2 3.3.9
• shell: fish 3.1.2 / bash 3.2.57
• tmux version 3.1a

Fish + iTerm2

Bash + iTerm2

Fish + default Terminal

Here is my configuration. I removed all the config but the error still happens

set -g default-terminal "screen-256color"
set -g history-limit 10000
set -g status-left ''
set -g status-right ''
set-option -g history-limit 10000

# Set prefix
set -g prefix2 C-s

# First window index is 1 instead of 0
set -g base-index 1
set-window-option -g pane-base-index 1
set -g renumber-windows on

# Set window title automatically
set-window-option -g automatic-rename on
set-option -g set-titles on

# Mouse mode
setw -g mouse on

# No delay for escape
set -sg escape-time 0

# Reload tmux config
bind r source-file ~/.tmux.conf

bind C-b send-prefix
bind C-s send-prefix -2

# Vim like movements
setw -g mode-keys vi
set -g status-keys vi
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R
bind p previous-window
bind n next-window
bind v split-window -h
bind s split-window -v

# Resize and select panes using Alt
bind -n M-j resize-pane -D
bind -n M-k resize-pane -U
bind -n M-h resize-pane -L
bind -n M-l resize-pane -R

# Shift arrow to switch windows
bind -n S-Left  previous-window
bind -n S-Right next-window

# Local
if-shell "[[ -f ~/.tmux.conf.local ]]" 'source ~/.tmux.conf.local'

Here is the tmux-client.log
tmux-client-12882.log

[evmorov]

A question from me too.

Only search the visible part of the history when marking (highlighting)
  search terms. This is much faster than searching the whole history and solves
  problems with large histories. The count of matches shown is now the visible
  matches rather than all matches.

But I really want the old behavior. Is there a configuration option to return it - the part for the count not showing all matches?

@boris-petrov have you found a solution? I want to have the old behaviour as well. For me, it was the feature why I started using Tmux

[boris-petrov]

@evmorov - I've pinned my tmux version to 3.0_a until 3.2 comes out (which, I think, has the feature again).

[bigeast]

EDIT: OK this is weird. I just deleted my tmux-client-12882.log file and everything worked just fine 🤣

Hi. Thanks for the great application.

I have just upgraded from tmux 3.1 to 3.1a using brew and couldn't open tmux any more due to a crash. It exits and outputs weird text tmuM2 3.3.9n. The previous version 3.1 works fine

@sondnm same problem as you, but find no reply here. I read this issue again and find this at the very begining:

• Note that using a 3.1 client and a running server of an older version may not work reliably. Make sure you restart tmux entirely after upgrading and that you are running the correct binary at all times.

So I exit my running tmux session, and it works again.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.