This sounds like a good plan. As for the vim keymap bug, I can't figure out what happens just yet, as pg-down works well in emacs keymap... -- JP
On Tue, May 19, 2009 at 5:49 PM, Corey O'Connor <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
