sublime API request

[vim]

ohhh! i didn't know that one.

searched the forum, read jon's email, i will have to play some with this...

[jps]

If you're interested in making a proper vi mode, then I'm happy to help out on the API side of things. I've done part of what's required already (commandMode, times, sequence, and key binding namespaces all come from some initial work to support vi emulation), but more still needs to be done.

You'll want to use key binding namespaces at some point, e.g.:

Code: Select all

<binding key="d" command="deleteRange ${motion}"><context name="option" value="commandMode"/></binding>

<namespace name="motion">
   <binding key="w" command="words 1"/>
   <binding key="b" command="words -1"/>
   <binding key="j" command="lines 1"/>
   <binding key="k" command="lines -1"/>
   <binding key="enter" command="lines 1"/>
   <binding key="shift+enter" command="lines -1"/>
   <binding key="h" command="characters -1"/>
   <binding key="l" command="characters 1"/>
   <binding key=" " command="characters 1"/>
   <binding key="shift+space" command="characters -1"/>
   <binding key="$" command="eol"/>
   <binding key="^" command="bol"/>
   <binding key="G" command="eof"/>
</namespace>


(You'll need to implement deleteRange for the above to be useful, of course)

The basic cursor movement commands will all need to be reimplemented for vi mode, because a few of the principles are different: the cursor can only move to EOL - 1, rather than to EOL, for example.

For entering / exiting insert mode, I reccomend something along the lines of:

Code: Select all

class InsertModeCommand(sublimeplugin.TextCommand):
   def run(self, view, args):
      print "entering insert mode"
      
      view.options().set('commandMode', False)
      view.runCommand('markUndoGroupsForGluing')
      
      if len(args) > 0:
         if args[0] == 'bol':
            view.runCommand('moveTo bol')
         elif args[0] == 'eol':
            view.runCommand('moveTo eol')
         elif args[0] == 'append':
            view.runCommand('move characters 0')
            

class CommandModeCommand(sublimeplugin.TextCommand):
   def run(self, view, args):
      print "entering command mode"
      
      view.options().set('commandMode', True)
      view.runCommand('glueMarkedUndoGroups')


Code: Select all

<binding key="i" command="insertMode"><context name="option" value="commandMode"/></binding>
<binding key="I" command="insertMode bol"><context name="option" value="commandMode"/></binding>
<binding key="a" command="insertMode append"><context name="option" value="commandMode"/></binding>
<binding key="A" command="insertMode eol"><context name="option" value="commandMode"/></binding>


The otherwise unused commands markUndoGroupsForGluing and glueMarkedUndoGroups are used so that all actions done in insert mode will be combined into a single entry in the undo stack, which in turn allows repeat (i.e., '.' in vi) to work as expected.

More API support will be required, such as displaying the current mode on the status bar, and allowing the cursor to be drawn under a character rather that between characters while not in insert mode, is still required, but I'm happy to add these.

[jps]

If you don't have them, it won't cause any problems, so I wouldn't think it's related.

Normally, when running several different commands, you'll get several different undo groups, each one of which will get undone in turn when ctrl+z is pressed.

'markUndoGroupsForGluing' simply records the current location in the undo stack.

glueMarkedUndoGroups' takes every entry in the undo stack between the marked one and the current one, and combines them into a single undo group. This means that a single ctrl+z will undo them all in one go.

[vim]

this is actually one of the differences from Vi. on Vi, when having two key bindings that over lap, e.g. d - action1 and dd - action2, after you press d once, Vi will wait for a short period of time (half a sec +/-) and if no more inputs it will decide you wanted action1 (d). Sublime Text it will wait till it sure what is the key sequence you entered, so when you enter d once it will wait till your next key press, to see if it's another d (->action2) or another key (->action1 and use the other input as normal key stroke).

this have always seems odd to me, because due to this behavior i can't bind frequent commands to shorter sequences. i would prefer to be able to group similar commands, like that:

Code: Select all

   <binding key="ctrl+h"      command="open"/>
   <binding key="ctrl+h,2"    command="openIn"/>
   <binding key="ctrl+h,2,a"  command="openInSomething"/>
   <binding key="ctrl+h,p"    command="openProj"/>
   <binding key="ctrl+h,p,p"  command="openProj quickpanel"/>

[vim]

anyway, check this out:

i have pushed this: http://code.google.com/p/sublime-text-c ... /trunk/Vim

do you think this is the right direction to go with?

[jps]

Looks good to me, yeah.

[vim]

this is actually one of the differences from Vi. on Vi, when having two key bindings that over lap, e.g. d - action1 and dd - action2, after you press d once, Vi will wait for a short period of time (half a sec +/-) and if no more inputs it will decide you wanted action1 (d). Sublime Text it will wait till it sure what is the key sequence you entered, so when you enter d once it will wait till your next key press, to see if it's another d (->action2) or another key (->action1 and use the other input as normal key stroke).

this have always seems odd to me, because due to this behavior i can't bind frequent commands to shorter sequences. i would prefer to be able to group similar commands, like that:

Code: Select all

   <binding key="ctrl+h"      command="open"/>
   <binding key="ctrl+h,2"    command="openIn"/>
   <binding key="ctrl+h,2,a"  command="openInSomething"/>
   <binding key="ctrl+h,p"    command="openProj"/>
   <binding key="ctrl+h,p,p"  command="openProj quickpanel"/>

quoting my self anyway, there is a real issue here, when i bind sequences that overlap shorter sequences, the shorter become unpractical to use. need to think ho to solve this, the VIM way is some kind of timer (which has its drawbacks - lag on response for the shorter keybindings), but maybe there are better ways.