I agree that moving the point drive to a window specific property is correct. However control-b and control-f in the vim keymap no longer scroll in any case. I think something is still missing.
I would like to push the management of the window region and insertion point into a true controller layer in the MVC sense. Modifications to view properties would be coalesced by a controller and then applied only after the modifications were vetted against a set of constraints. Constraints that would be invalidated by the modifications could choose to resolve the conflict by adjusting other view properties or rejecting the modifications outright. What conflict resolution process is picked could depend on the requested modification. I think that would resolve this issue, enable new features (such as keep N lines around the cursor always in view) and captures the current concept of point drive. The process for scollB would then be: # scrollB would post a modification to the window region to the view controller. # The view controller would validate the modification against the constraint that the insertion point is always within the window region. # If the constraint is satisfied then the modification is applied otherwise the controller tries to find a resolution for the conflict. # The conflict is resolved by moving the insertion point within the window view. This resolution is picked because the modification requested was to the window region not the insertion point. The process for cursor movement would then be: # cursor movement posts a modification to the window's insertion point to the view controller. # The view controller would validate the modification against the constraint that the insertion point is always within the window region. # If the constraint is satisfied then the modification is applied otherwise the controller tries to find a resolution for the conflict. # The conflict is resolved by moving the window region to satisfy the "insertion point is within window region" constraint. This resolution is picked because the modification requested was to the insertion point and not the window region. Fully implementing this abstraction is lkely more aggressive than required right now but it is the direction I'd like to move. Hopefully this would also have tho side effect of moving controller logic out of each UI's implementation. -Corey O'Connor On Tue, May 19, 2009 at 8:14 AM, Jean-Philippe Bernardy <[email protected]> wrote: > > I pushed patches which simplify the code and (hopefully) fixes this > the "proper" way. > > Cheers, > JP. > > On Tue, May 19, 2009 at 5:45 AM, Corey O'Connor > <[email protected]> wrote: >> >> Mon May 18 23:37:57 EDT 2009 [email protected] >> * Fixes scrolling when > 1 window views the same buffer in the current tab >> Previously scrollB did not behave correctly in the following case: >> 1. Split the current window into two windows onto the same buffer. (Vim: >> control W S) >> 1. Scrol the current window down (Vim: Control f) >> The new window would get "stuck" and scrollB would appear to have no effect. >> Instead of moving the from mark of the MarkSet this patch changes scrollB >> to move the insertion >> point. With pointDrive = True this results in scrolling working for all >> windows onto a buffer. >> Scrolling behavior is still odd. I'd expect to be able to define a window a >> range of lines; scrollB >> to shift the range of lines; and the insertion point associated with a >> window to be adjusted >> to satisfy a given constraint. >> >> M ./Yi/Buffer/HighLevel.hs -5 +5 >> >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ Yi development mailing list [email protected] http://groups.google.com/group/yi-devel -~----------~----~----~----~------~----~------~--~---
