On 5 April 2013 17:24, Thomas Nemeth wrote:
>
> Hi.
>
> I've been using tmux for a long time and a fact stroke me: even
> when using strftime, the date is always displayed in english. I've
> been compiling tmux after each new version in order to have the
> date in my language.
On non-US keyboards, there often are infrequently used keys that make
excellent prefix key choices, such as § on a Swedish keyboard (just left of
1, beneath Escape).
Can we get support for using these as prefix keys in tmux? I believe a
utf-8 terminal would produce the sequence 0xC2 0xA7 for this
Hi.
I've been using tmux for a long time and a fact stroke me: even
when using strftime, the date is always displayed in english. I've
been compiling tmux after each new version in order to have the
date in my language.
Would it be possible to integrate my patch ?
He
Hi,
tmux 1.8 failed with an error when I did a "#make" on Solaris. The bug and
it's minor fix are given below. I have also attached the patch in this mail.
Bug:
gcc -DPACKAGE_NAME=\”tmux\” -DPACKAGE_TARNAME=\”tmux\”
-DPACKAGE_VERSION=\”1.8\” -DPACKAGE_STRING=\”tmux\ 1.8\”
-DPACKAGE_BUGREPORT=\”\”
There was one old bug about this on pinentry-curses:
https://bugs.g10code.com/gnupg/issue1203
Are you using an older version by any chance ?
-Ashwin
On Sat, Apr 6, 2013 at 12:31 PM, Erik Johnson wrote:
> I use gpg-agent (with ssh support enabled), and when I use pinentry-curses
> from within
I use gpg-agent (with ssh support enabled), and when I use pinentry-curses
from within tmux, the pinentry prompt rarely appears in the current pane.
Sometimes it appears in a different window, sometimes it appears on tty1,
there doesn't seem to be a rhyme or reason to it (though there is probably
s
On Tue, 26 Mar, 2013 at 16:08:43 GMT, Nicholas Marriott wrote:
> Not enough. Just renaming it is not ok. mode-mouse does this:
>
> - Click to paste outside copy mode.
> - Copy text on drag outside copy mode.
> - Copy text on drag inside copy mode.
> - Scroll up and down in copy mode.
> - Select ite
This fixes a bug in control mode. It occurs when unlinking the last
window in the current session. The %end guard is not printed because
the client's session is NULL after the last window is unlinked and the
session is automatically destroyed. As far as I can tell there's no
reason to require a non