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, I would like to split the options up in such a way that we don't end up with similar overloading again, so I'd like to look at making the options control a "purpose" (eg copy/paste) rather than a "place" (eg copy mode). So instead of "mouse-copy-mode" which controls copy and paste and scrolling in modes we would have "mouse-copy-paste" which controls copying and pasting with the mouse (it could be tristate to be always/copy-mode only/never). And instead of "mouse-choose-mode" we would have something like "mouse-select-item" (bad name I know) which controls selecting items with the mouse. But then we are left with the problem of scrolling - do we have a "mouse-scroll-wheel" option as well? It seems a bit unnecessary. So do we just support the scroll wheel if any of the other mouse options are on? > > >>>We could split it up into a few options but what? > What? Clarity and configurability. > >>>Perhaps just two: mouse-copy-paste (copy/paste inside and outside copy > >>>mode) and mouse-in-modes (scroll wheel in copy mode, select in choose > >>>mode, scroll wheel in choose mode too maybe). > No clear separation imho.. but i'll come up with something. > > >So you want to keep it as one option? Then I am going to say this again: > >there is no need to rename just because "it's confusing". > Well if being confusing to users is not a valid reason, then being > configurable more fine-grainedly should be. Yes that is what I have been proposing - rather than just renaming the option, let's look at what it does and decide what the best set of options (finegrained or not) are. > >>>In any case this will wait for 1.9. > >>Why? why release another release with a confusing name? What is the > >>external force demanding an 1.8 release TODAY? > > > >It's been long enough. We've had a period with some major changes > >followed by a period of relative quiet to let them be tested. I'm away > >next week and want things to move forward. Thomas has a window to do it > >this evening. The timing works for us. > Well so be it. The problem is that with every release there's a > higher use base and more config files that need to be changed in > case of a non-backward-compatible change. That was the reason I > tried to get the rename into 1.7, now again into 1.8, and most > definitely again into 1.9. Any period of time or new release is likely to change the userbase, at some point you just need to accept what is done rather than worrying about what could happen later. > > >We've had several releases with mode-mouse. People will survive > >another. It plainly needs more discussion. > Accepted. > > >>>>- pane-active-border-mark option to indicate current pane (as an option > >>>>to the horrible half-line indicator that was committed 12 days ago) > >>>Don't bother with ^v<>, even as an option. I tried it - with UTF-8 > >>>arrows and without - and I don't like it. Get some new suggestions we > >>>both like. > >>Oh YOU don't like it. And regardless who might or might not like it, > >>YOUR new preference becomes the default behaviour for 1.8. That's a > >>reasonable approach, after all free software is neither about choice > >>nor customization. Excuse me? > > >When it comes to tmux, of course my preference trumps yours. > What about the preference of the several thousand users? Of course, > most of them won't care. Let's assume only a few hundred do - ... ah > well let's wait and see. > I think it is a very bad default.. > > >You haven't even TRIED to persuade me why your idea is better (it > >isn't)! Calling my way "broken" and "horrible" is not persuasive! > BECAUSE it is simple un-intuitive! It is highly unusual for a border > separating two regions to have two colors. If you _know_ what it > means, it might be a quick visual queue but it needs active > conscious effort (ok we're raised with the LTR paradigm.. what about > the RTL folks? does the top=left/bottom=right mapping make sense to > them? is it intuitive? can they change it, other by messing with the > general border color scheme?) whereas arrows are much more easily > recognizable. > Here's a direct comparision to make the point: > https://lh3.googleusercontent.com/-u5vhaTO95EM/UVHoJBe5NDI/AAAAAAAAEPU/uGDMB-YTmMg/s1054/tmux-mark-active-pane-new-default.png > https://lh4.googleusercontent.com/-t3-FFb4PaZs/UVHoJAiGmVI/AAAAAAAAEPQ/cabBdWbciRo/s1054/tmux-mark-active-pane-alternative.png I don't agree. I think my way is intuitive. You only need to change pane once to work it out. And your solution has the same problem (especially without UTF-8). Your way is worse in other ways: it is visually ugly, it can differ radically depending both on the font and on UTF-8 support, and the arrow is too small and easy to miss. My way is simple and unobtrusive and is very obvious once you have established the simple fact that the green border is the active pane. > > >>>>- mouse wheel scrolling emulation (yes, it is ready since long) > > >Don't exaggerate. You are the only person to have commented on this and > >you've survived so far. Another release isn't the end of the world. > I never said so. It's just the version a couple of thousand people > will be using for maybe half a year, and I honestly think that many > of these would benefit from a mouse wheel scrolling implementation They will benefit from it just as much in the next release as in this one. We can't always do everything. > and would prefer an intuitive way to discern the active of two > windows. > But they can voice their option themselves, and I can continue > running a custom fork. THX/EOD. Yes, they can and when they do and there is a clear consensus we can make this stuff the highest priority. ------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
