[implementations-list] Visual region (was: vimpulse)
On Wed, Jul 1, 2009 at 11:31 AM, Alessandro Piras <[email protected]> wrote:
Hi Fabian, I was looking at the viper source code to see how to add the '<,'> functionality to ex commands. It turns out it's quite boring to add it. Viper does not recognize the '< and '> marks, and the characters recognized as mark identifiers are hard coded in the ex command parser. I could easily change the parser to let it recognize '< '>, but that would be yet another viper function redefinition. I also think I'd have to change it in other places, like in the ' command, and god knows where else (as there are also other functions that check if the character is a valid mark, and it seems viper uses some sort of registers (the same code used for "a "b etc) to store markers. To avoid another redefinition, I can do 2 things: - put the line numbers that identify the current visual selection automatically after ":" - this would work almost the same, but then you would have to remember the line numbers if you want to issue a second command on the visual selection after it is turned off - use two marks, for example y and z, instead of < and >, and automatically put 'y,'z after the : when : is issued in visual mode.
Why not ask Michael Kifer for write access to the Viper source code repository, if there is one? [ Please CC me or the list when you write to him; then, if it turns out there isn't one, I or you could offer to make one for him on Assembla. :-) ]
By the way, I'm forwarding this mail to the mailing list, so to hear other opinions too. I also invite you to subscribe to the mailing list, and direct your feature/fix requests there :)
Thanks Alessandro. Just remember that if you leave out your email address from the top of the file, and put the list email address in its place, then *all* emails will go to list :-)
Hi Jason :) Didn't you already talk with Michael Kifer times ago? I remember he said something like not being interested in vim keybindings, but maybe I remember wrong. I tried to follow the 'y,'z path, and still I had to redefine yet another viper function. It works like vim, except that instead of '< and '> it uses 'y and 'z. I'm feeling like entering kludge-world, and this is not a good thing. Recognizing '< and '> would mean injecting even more kludges, and directly modifying viper to be more vimpulse-friendly would mean: a) injecting ugly kludges to make viper aware of my code (that's what has been done redefining viper's functions btw) b) refactoring viper to be more easily extended, and to be sure that the refactoring doesn't break anything a better viper knowledge than mine is needed I think. I will think about it these days :) Meanwhile, suggestions on what to do are welcome ^^ 2009/7/1 Jason Spiro <[email protected]>
On Wed, Jul 1, 2009 at 11:31 AM, Alessandro Piras <[email protected]> wrote:
Hi Fabian, I was looking at the viper source code to see how to add the '<,'> functionality to ex commands. It turns out it's quite boring to add it. Viper does not recognize the '< and '> marks, and the characters recognized as mark identifiers are hard coded in the ex command parser. I could easily change the parser to let it recognize '< '>, but that would be yet another viper function redefinition. I also think I'd have to change it in other places, like in the ' command, and god knows where else (as there are also other functions that check if the character is a valid mark, and it seems viper uses some sort of registers (the same code used for "a "b etc) to store markers. To avoid another redefinition, I can do 2 things: - put the line numbers that identify the current visual selection automatically after ":" - this would work almost the same, but then you would have to remember the line numbers if you want to issue a second command on the visual selection after it is turned off - use two marks, for example y and z, instead of < and >, and automatically put 'y,'z after the : when : is issued in visual mode.
Why not ask Michael Kifer for write access to the Viper source code repository, if there is one? [ Please CC me or the list when you write to him; then, if it turns out there isn't one, I or you could offer to make one for him on Assembla. :-) ]
By the way, I'm forwarding this mail to the mailing list, so to hear other opinions too. I also invite you to subscribe to the mailing list, and direct your feature/fix requests there :)
Thanks Alessandro. Just remember that if you leave out your email address from the top of the file, and put the list email address in its place, then *all* emails will go to list :-)
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
On Wed, Jul 1, 2009 at 2:17 PM, Alessandro Piras <[email protected]> wrote:
Hi Jason :) Didn't you already talk with Michael Kifer times ago? I remember he said something like not being interested in vim keybindings, but maybe I remember wrong.
Yes, I spoke with him. I was discussing vimpact, which was the precursor to vimpulse. He said[1] that eventually maybe things could be merged in.
I tried to follow the 'y,'z path, and still I had to redefine yet another viper function. It works like vim, except that instead of '< and '> it uses 'y and 'z. I'm feeling like entering kludge-world, and this is not a good thing. Recognizing '< and '> would mean injecting even more kludges, and directly modifying viper to be more vimpulse-friendly would mean: a) injecting ugly kludges to make viper aware of my code (that's what has been done redefining viper's functions btw) b) refactoring viper to be more easily extended, and to be sure that the refactoring doesn't break anything a better viper knowledge than mine is needed I think.
Maybe Michael could help. I think you should CC him on all emails where you think he could be a big help; or you should forward him those emails. Like this one. :) ^ [1]. http://snipurl.com/kiferreply (points to an archived copy of his reply on Nabble)
participants (2)
-
Alessandro Piras -
Jason Spiro