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 --~--~---------~--~----~------------~-------~--~----~ Yi development mailing list [email protected] http://groups.google.com/group/yi-devel -~----------~----~----~----~------~----~------~--~---
