2009/5/22 Corey O'Connor <[email protected]>: > > On Thu, May 21, 2009 at 5:30 PM, Colin McQuillan <[email protected]> > wrote: >> 2009/5/19 Corey O'Connor <[email protected]>: >>> >>> 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 >>> >> >> You could say that scrollB is already passing a message to Yi.UI.Vty >> by clearing the pointDrive flag. But this involves IO and ties buffer >> commands to the refresh code. > > I agree. How Yi uses the pointDrive flag is consistent with pointDrive > being a message. So using a message passing system for propagating > view changes to the UI does satisfy our current requirements. > >> I have made an attempt at moving the scrolling behavior nearer the >> buffer commands. There's no view controller, but there are separate >> functions for handling the two processes you describe. Splitting >> scrolling from rendering allows optimizations that reduce the number >> of renders, and pasting is now fast (from 10s to 1s in my test). > > A nice bonus! > >> However, scrollB is a value of type BufferM (). BufferM actions don't >> have access to the window width so cannot calculate the end mark from >> the start mark. scrollB would also require a algorithm to lay out >> lines independently of the UI. (The Pango frontend currently uses >> Pango linebreaking.) This layout algorithm would need to be kept in >> sync with the rendering routines, which means duplication of code. > > This makes sense if you consider BufferM to represent the model layer > in a Model-View-Controller system. Placing controller and view logic > within the model encounters these types of difficulties. > >> So in my patch, the window heights are hard-coded. It won't handle >> split windows or wrapped lines correctly. The display size is set to >> 24x80. Of course this patch shouldn't be applied until these issues >> are fixed, but you might like to take a look. > > Let's consider line-wrapping later. That's a complicated issue that, I > think, can be separated from scrolling for now. Won't be perfect but > OK for most uses to ignore it for now IMO. > > Instead of placing the scroll logic within BufferM creating a new > action that represents view changes of this type should be easier. > This means that instead of scrollB the keymaps would issue a scrollW > (scroll window. Or maybe scrollV for scroll view) message. A UI > controller would consume these messages and, as it manages the layout > of windows, would have all the state information required. This would > likely be done by adding a new action type to Yi.Keymap.Action. > > Cheers, > Corey >
This doesn't sound too drastic. Apart from scroll*, no buffer actions use the window height, and only winRegionB uses the from/to marks. The UI controller could keep track of the from mark, and would just need to implement middleB, scrollB and winRegionB. --~--~---------~--~----~------------~-------~--~----~ Yi development mailing list [email protected] http://groups.google.com/group/yi-devel -~----------~----~----~----~------~----~------~--~---
