prefix ] works.. this means that everything was fine with my tmux
configuration and it's just that I kept using command k to paste
selections...
Thanks so much for your patients and help!
On Tue, Mar 26, 2013 at 5:56 PM, Nicholas Marriott <
nicholas.marri...@gmail.com> wrote:
> On Tue, Mar 26,
On 26 March 2013, at 22:59, Nicholas Marriott wrote:
> Yes you can capture a pane in a different window with eg -t:0.0
Thanks, that's exactly what I wanted.
> but there is no way to capture multiple panes from a window together, it is
> one pane only.
No, I don't need that.
I was just confuse
Yes you can capture a pane in a different window with eg -t:0.0 but
there is no way to capture multiple panes from a window together, it is
one pane only.
On Tue, Mar 26, 2013 at 09:47:49PM +, Stroller wrote:
>
> On 26 March 2013, at 21:33, Thomas Adam wrote:
>
> > On 26 March 2013 21:18,
On Tue, Mar 26, 2013 at 07:36:53PM +0100, Marcel Partap wrote:
> >You might want to disable ALL mouse support and that has to be
> >possible. In fact, it has to be the default.
> Ok if so, then it needs at least one more option in addition to
> "mouse-copy-mode".. "mouse-choose" or something.
Well
On 26 March 2013, at 21:33, Thomas Adam wrote:
> On 26 March 2013 21:18, Stroller wrote:
>> Hello,
>>
>> I'm sorry if this is a dumb question, but all I want to do is grab
>> everything from window 0 and stuff it in a text file, so I can tail it or
>> open it in a text editor.
>
> How many p
On 26 March 2013 21:18, Stroller wrote:
> Hello,
>
> I'm sorry if this is a dumb question, but all I want to do is grab everything
> from window 0 and stuff it in a text file, so I can tail it or open it in a
> text editor.
How many panes are in this window? A window always contains at least
*
Hello,
I'm sorry if this is a dumb question, but all I want to do is grab everything
from window 0 and stuff it in a text file, so I can tail it or open it in a
text editor.
It seems to be possible to grab all the text from a pane using capture-pane,
but not from a window. Is that right?
TIA,
Hi all,
I'm pleased to announce the release of tmux 1.8. Please take a look here:
https://sourceforge.net/projects/tmux/files/tmux/tmux-1.8/
for the release tarball and changes introduced in to 1.8.
Please let any packagers know of this release.
Any questions, do please ask.
On behalf of eve
OK. How do I know if my selection was copied to the tmux clipboard? How do
you paste the copied stuff? I tried command+V and the pasting didn't work..
Am I not doing it in the right way?
Yeah, the description in my last email also happen when I start tmux
normally.
On Tue, Mar 26, 2013 at 12:44 P
> You might want to disable ALL mouse support and that has to be
> possible. In fact, it has to be the default.
Ok if so, then it needs at least one more option in addition to
"mouse-copy-mode".. "mouse-choose" or something.
>>> We could split it up into a few options but what?
What? Clarity and
That's what's supposed to happen :-). When you released the mouse it
copied it to the tmux clipboard.
Doesn't that happen when you start tmux normally?
On Tue, Mar 26, 2013 at 12:40:32PM -0500, Junchen Gu wrote:
>What happened was, I clicked left button on my mouse to select abcedf,
>the
Hmm. This is weird. tmux is definitely getting the drag events.
So nothing on screen at all changes when you drag?
On Tue, Mar 26, 2013 at 12:26:02PM -0500, Junchen Gu wrote:
>Sure. Here you go.*
>
>On Tue, Mar 26, 2013 at 12:23 PM, Nicholas Marriott
><[1]nicholas.marri...@gmail.com
On Tue, Mar 26, 2013 at 05:35:09PM +0100, Romain Francoise wrote:
> Nicholas Marriott writes:
>
> > I don't understand what master has to do with it, are you building
> > packages from master rather than from a tag?
>
> Yes, I build packages for Debian's experimental suite from master, usually
>
Would you mind attaching the server log please? If you include them in
the mail itself then the control codes in the mouse sequences are lost
:-(.
On Tue, Mar 26, 2013 at 12:18:53PM -0500, Junchen Gu wrote:
>Here are the log files:
>1. tmux-client-16248.log
>got 3 from server
>2.*
We don't do unnecessary renames, and we don't carry about unnecessary
compatibility code for them.
Seriously, the confusion here is so minor and backed by so little
evidence it's not worth the hassle.
If you want to help the confused then extend the mode-mouse entry in the
man page, or add a new
Here are the log files:
1. tmux-client-16248.log
got 3 from server
2. tmux-server-16250.log
server started, pid 16250
socket path /tmp//tmux-20074/test
new client 8
got 14 from client 8
got 14 from client 8
got 14 from client 8
got 14 from client 8
got 14 from client 8
got 14 from client 8
got 14
On Tue, Mar 26, 2013 at 05:41:24PM +0100, Marcel Partap wrote:
> >>- renaming mode-mouse to mouse-copy-mode (multiple incidents of
> >>confusion because of the too-general name)
> >
> >Not enough. Just renaming it is not ok. mode-mouse does this:
> >- Click to paste outside copy mode.
> >- Copy tex
...
> isn't going to happen now, since I'm about
> to cut a release for 1.8.
Uhm ok.
> But adding in your changes now -- even by delaying 1.8 by a few days --
> simply is not an option.
Because?
> We would need much more time to ensure new code
> isn't going to introduce bugs
Much more time? The
..ok that was meant to be a reply to
<20130326160843.ga22...@yelena.nicm.ath.cx> sorry^^
--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for rec
- renaming mode-mouse to mouse-copy-mode (multiple incidents of
confusion because of the too-general name)
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 an
Nicholas Marriott writes:
> I don't understand what master has to do with it, are you building
> packages from master rather than from a tag?
Yes, I build packages for Debian's experimental suite from master, usually
every couple of weeks. For unstable I use the latest official release, of
cours
There are other naming warts if we want to break everybody's configs
good and well:
- We have display-time but message-fg/bg/attr.
- What IS the difference between 'list' and 'show' anyway?
- split-window should be split-pane.
- I hate the name 'server-info'. And surely 'info-server' to match t
I don't think we need backwards compatibility, it isn't a big ask for
people to change their configs - especially now they can use
if/run-shell synchronously to do it and ignore the error. But it isn't
something we want to ask unnecessarily, just to fix naming nit.
On Tue, Mar 26, 2013 at 03:58:
On Tue, Mar 26, 2013 at 04:08:12PM +0100, Marcel Partap wrote:
> > On Tuesday evening -- I'm planning to release tmux 1.8.
> > Any questions, please let me know.
> Yes, would you be so kind and delay the release a couple of hours. Only
> just took notice of it and imho some of the patches I sent i
Hi,
On Tue, Mar 26, 2013 at 04:08:12PM +0100, Marcel Partap wrote:
> > On Tuesday evening -- I'm planning to release tmux 1.8.
> > Any questions, please let me know.
> Yes, would you be so kind and delay the release a couple of hours. Only
> just took notice of it and imho some of the patches I s
> Oh and the recent merge does look ugly indeed - cherry-picking is a much
> better way to deal with situations like that
...further diving into the git history, I dismiss my previous
statement.. cherry-picking from obsd-master is obviously not a real
option.. but is there no way to merge without
I'm not comfortable adding more features now, if we want to release this
week we have no more time for testing.
If you have the osdep changes ready before Thomas does the release I
will look at them.
The rest will wait for 1.9.
On Tue, Mar 26, 2013 at 04:08:12PM +0100, Marcel Partap wrote:
> >
> On Tuesday evening -- I'm planning to release tmux 1.8.
> Any questions, please let me know.
Yes, would you be so kind and delay the release a couple of hours. Only
just took notice of it and imho some of the patches I sent in a year ago
and then again couple of months back should really really
On Tue, Mar 26, 2013 at 01:29:53PM +0100, Romain Francoise wrote:
> Nicholas Marriott writes:
>
> > If we have nice history it is a bonus but if it's easier then it'll be
> > messed up. Why is this a problem? Every change is there at least once,
> > nothing is lost. What can you no longer do here
Nicholas Marriott writes:
> If we have nice history it is a bonus but if it's easier then it'll be
> messed up. Why is this a problem? Every change is there at least once,
> nothing is lost. What can you no longer do here?
It's fundamentally broken to have every change in there twice, one of
whi
I am happy to look at this stuff but I don't think we should actually
include this change at least until we are also adding something that
uses it. Don't know if I didn't make that clear before :-).
On Mon, Mar 25, 2013 at 04:15:12PM +, Philip Herron wrote:
> Yeah i understand what you mean.
You make a good point, although there is good reason for TMUX_SOCKET too
:-). Still, nobody has asked for it yet.
Your change looks fine - I will apply it after 1.8 is done.
On Mon, Mar 25, 2013 at 12:36:39PM -0400, Ben Boeckel wrote:
> On Fri, Mar 22, 2013 at 08:35:10 +, Nicholas Marriott w
If we have nice history it is a bonus but if it's easier then it'll be
messed up. Why is this a problem? Every change is there at least once,
nothing is lost. What can you no longer do here?
I do like to make things easy for packagers but I'd also like to make
minimal promises about history or the
Thomas Adam writes:
> On Tuesday evening -- I'm planning to release tmux 1.8. To this end,
> I've updated the "master" branch on SF to reflect what will be in it.
> To most people this won't be news because it should contain everything
> it used to beforehand, but I've had to rewrite the history
* Remove/rename some variables which were no longer being used.
* Added #include
---
cmd-queue.c |1 +
control-notify.c |4
control.c|1 +
window.c |9 -
4 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/cmd-queue.c b/cmd-queue.c
inde
35 matches
Mail list logo
