Björn wrote:
> >> Ok, here is the updated patch. I've renamed the keys as follows:
> >>
> >> <ScrollWheelUp>
> >> <ScrollWheelDown>
> >> <ScrollWheelLeft>
> >> <ScrollWheelRight>
> >>
> >> These all scroll the _window_ in the direction indicated. So if I
> >> push UP on my scroll wheel, the window moves up but the lines are
> >> actually scrolled down (this is the most intuitive way of thinking
> >> about scrolling in my opinion). Similarly, dragging my finger to the
> >> LEFT on a laptop's trackpad scrolls the window to the left but the
> >> columns are actually scrolled right.
> >
> > Looks good to me. With the Ctrl+scrollwheel changes, I was able to test
> > this by mapping <C-ScrollWheel{Up|Down}> to <ScrollWheel{Left|Right}>
> > and it seems to work fine in both term and GTK2.
> >
> > The only thing I might change would be the symmetry of using 3 for the
> > default increment. Maybe 5 or 10 would be better for horizontal
> > scrolling? (With the default, horizontal scrolling seems much slower
> > than vertical scrolling.)
>
> I increased the default number of lines to scroll to 6 -- any higher
> and it was difficult to just scroll "a little" (with my track pad).
> The docs have also been updated to reflect this.
>
> >> It is still possible to use <MouseUp> as a synonym for
> >> <ScrollWheelDown>, and to use <MouseDown> as a synonym for
> >> <ScrollWheelUp>. I've updated all the help docs to reflect these
> >> changes.
> >
> > The new list of the default keys seems very cluttered with the tags
> > listed all on one line. The old layout also had the benefit of ':help
> > <S-MouseUp>', etc. jumping to exactly the right line.
>
> Sure, I tried changing it back and it seems a bit more readable that way.
>
> The attached patch contains these minor updates.
>
> Bram: could you indicate if there is any chance this is making it for
> 7.3 (or at all)? It seems this feature would mostly be used by Mac
> users (since "all" Macs have horizontal scrolling abilities) and a few
> users have asked for this feature. If you'd rather hold off merging
> this patch I'll merge it with the MacVim source code so that it gets
> tested properly and then you can take a look at it later.
It looks fairly good. It's a bit big to include at the last moment,
but we still have some time for testing.
Can you change the argument for the direction to use an enum or #defined
value? Using 0, 1, -1 and -2 is a bit confusing.
For style, instead of:
if (val < 0) val = 0;
use:
if (val < 0)
val = 0;
gui_find_longest_lnum() is missing a prototype.
--
If cars evolved at the same rate as computers have, they'd cost five euro,
run for a year on a couple of liters of petrol, and explode once a day.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
