I personally use mode-mouse only for scrolling text. I do not use it for
select-pane.
For copy-mode I prefer to use keyboard keys, since it is much efficient.
If I want to select just a word, I use shift + mouse click (or double
click) and copy it into the X11 default clipboard.
On Wed, Apr 10,
Yes we could do but TBH I'm not sure it's worth the extra code. I'd
really like to hear from people who do use the mouse - what options do
they turn on? If they don't turn on mode-mouse, why not?
I only use mouse-select-pane myself
On Sat, Apr 06, 2013 at 04:12:50AM +, Ben Boeckel wrote:
> O
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
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
> 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
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
>
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
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
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
Hello all,
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 to satisfy
the sy
24 matches
Mail list logo
