I have applied this.
The first thing I noticed is that you don't have a .project file - which means that it won't be able to compile / run on Windows...

Also, you included some of the header files that you should not have (cl_editor.h, manager.h and some others) - you may only include header files from the Interface, CodeLite and plugin_sdk folder.
I suspect that you noticed that and this is why you modified the generated CMakeLists.txt file - it was intended.

Now, some functionality issues:

• When I save a file, it crashes CodeLite - I will look into this
• The plugin is enabled by default, which I suspect is not the default behavior that the users wants, it should be configurable, I will add a basic settings dialog with option to enable/disable it, disabled will be the default

Few notes about the design:
The current code uses a VimManager class to mange the current commands and the state of each editor.
It will be difficult to maintain the state of each editor (assuming multiple editors are open).
e.g lets say you have 2 editors open, the first is in NORMAL mode and the second is in INSERT mode.
You only have one member named mCurrCmd so you should either have a set of them (so you could remember the correct one each time you switch an editor), or a different approach might be:
Allocate new class of type VimEditor which will handle a specific editor with its own state etc until the actual editor is closed.

What do you think?

Another update: I have added simple UI settings to the vim plugin. Also, I have disabled vim by default, to enable it, you will need to turn it on from: plugins->codelite vim->settings

Hallo,
thanks for merging, quickly replying and adding all these new things.
About the VimManager class, that was the primary idea, insert a middle layer, between the Plugin and the VimCommand to control parallel more editors. But since the VimManager methods started to be less clean, keeping asking the vim Command about the state it is in, I made it a bit simpler, without this additional feature. I will implement regularly (hopefully) new commands and try to solve this issue.

About the issue:

• When I save a file, it crashes CodeLite - I will look into this
  I do not experience such a problem:
  I compiled codelite with
  g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609.
• a problem I experience is the following:
  I am not able to override the combination ctrl+D and ctrl+U:
  such event does not reach the VimManager, but I cannot understand where it is consumed.

the crash no longer occurs, I fixed it.
another issue I found: when in NORMAL mode, BACKSPACE is not handle (i.e. if I did a typo and I want to fix it, I can't)

Hello again, I have fixed the BACKSPACE support when in NORMAL mode.
I have also updated the code to matche CodeLite's coding style (e.g. mCurrCmd -> m_currentCommand). I will keep on investing time improving this.

Some other bugs I have noticed:

• The u (undo) seems to capture another step, I am not sure if we can handle this or not, but I will look into it
• The caret style sometimes is out-of-sync with the actual modus

I will keep on testing/fixing what I see, but keep up the great work

Many thanks for all what you did.
I added in my fork some implementation of new commands, and set up the visual mode.
I will try also to look into the u (undo) command problem.

My idea is to use the int m_cumulativeUndo; to calculate how many times one has to call wxStyledTextCtrl::Undo to be syncronized with what the user expect.
The reason is the implementation of the commands, for example:

• the command 3rf will be parsed as:
  - repeat 3 times

           1. ctrl->CharRight();
           2. ctrl->DeleteBackNotLine();
           3. ctrl->AddText('f');
  

• I guess wxStyledTextCtrl save the history step every single step, and so just one u will only undo the last ctrl->AddText('f');. I this a solution might be to associate to this u, 9 wxStyledTextCtrl::Undo.

You can aggregate actions into a single Undo command like this:

ctrl->BeginUndoAction();
...
ctrl->EndUndoAction();