1

Re: Modes and keymapping

Hi J:

I promised to post some of my thoughts on improving ViEmu (which is already quite wonderful!), and here goes:

I'm quite interested in seeing key remapping working, both map and imap. Specifically, I would like to do something like:
    map <Tab> :bn<CR>
    map <S-Tab> :bp<CR>
    imap <Up> <Esc>lk
    imap <Down> <Esc>lj
    imap <Right> <Esc>ll
    imap <Left> <Esc>

The point of the first two is to quickly cycle through buffers. Better buffer control is something I'm very much looking forward to. I agree with user Tak in a previous post that VS buffer ordering is annoying and unuseful. Why not simply use the ordering visible on screen given by the ordering of the tabs?

The point of the four imap lines above is to return to command mode early and often. This is something I would very much like to see developed further. I would like ViEmu to go to command mode when I click almost anywhere in VS (e.g., reposition the cursor in the buffer, change to another buffer or use some toolbar/other window) or in some other way interrupt my editing. User sticks also commented along these lines.

Something I find quite annoying is that when I'm done doing something in insert mode, Intellisense might have a tooltip open, and when I press escape only the tooltip closes, but ViEmu does not return to command mode, and I end up having lots of command characters in my buffer. I realize this might be difficult to fix, but as a temporary fix I'm considering to have escape emit two escapes when I'm using ViEmu. This has lots and lots of drawbacks, but I don't really know if it's usable before I've tried. Is it even possible/have anybody tried it?

Less pressing matters are: search highlighting (which I also realize is difficult), tab completion when using :e for instance, and command execution using :!

Regards,
Ulrik

Last edited by Ulrik (2006-05-01 14:38:45)

2

Re: Modes and keymapping

Ulrik,

Thanks for the suggestions and for the detailed rationale behind them.

Mapping as you describe it is already working for the next major release of ViEmu (there are other parts which aren't, that's why it isn't available yet). The only vim mapping feature not supported is multiple key chord mapping. So, I think you will be able to implement all those features without problems.

With regards to ViEmu getting back to command mode at most general events, I think a user setting will be necessary, as other users have requested the opposite behavior (it actually used to work like you describe in older versions, but I moved to the current model to follow vim's behavior).

I'll have a look at the Escape-swallowing problem. It shouldn't happen, and as far as I've noticed, it does not happen for me. Could you list which VS version you are using, and what (if any) other 3rd party plugins are installed?

Search highlighting is also due for the next major version, and the other features (proper buffer numbering, command line tab completion, and external filters) will also come in some time.

Thanks again!

3

Re: Modes and keymapping

I'm not sure if we're talking about a similar issue or not, but one thing I find quite annoying is that ViEmu does not return to command mode after executing a command in visual mode (yank or delete). IE:

   - enter visual mode, select a couple lines
   - CTRL-Y to yank
   - still in visual mode ... vim would normally have returned to command mode at this point

Any thought?

Thanks,

Johan.

4

Re: Modes and keymapping

Hm.... Ctrl-Y should actually scroll the window one line, in ViEmu the same as in vim (as long as Ctrl-Y has been unbound from any assignment in Tools|Options|Keyboard, else it will have that behavior). I also tried 'y' in visual mode, which does return to normal mode.

So I also tried Y in visual mode... and you're right, it had a bug. I've fixed it, 1.4.5-alpha-6:

  http://www.viemu.com/ViEmu145a6.msi

You need to manually uninstall the previous version before installing this one.

It also implements :clo[se] and Ctrl-W c to close the current window/split.

Thanks for the feedback!

5

Re: Modes and keymapping

Sorry, I meant Shift-Y of course  and yes I realised it was *only* yanking that caused the issue.

Thanks heaps for the fix! You rock!

6

Re: Modes and keymapping

JNG wrote:

Thanks for the suggestions and for the detailed rationale behind them.

You're most welcome. :-)

Mapping as you describe it is already working for the next major release of ViEmu (there are other parts which aren't, that's why it isn't available yet). The only vim mapping feature not supported is multiple key chord mapping. So, I think you will be able to implement all those features without problems.

Great!

With regards to ViEmu getting back to command mode at most general events, I think a user setting will be necessary, as other users have requested the opposite behavior (it actually used to work like you describe in older versions, but I moved to the current model to follow vim's behavior).

As long as I can get it to work like I want, e.g., via a user setting, I'm perfectly satisfied.

I'll have a look at the Escape-swallowing problem. It shouldn't happen, and as far as I've noticed, it does not happen for me. Could you list which VS version you are using, and what (if any) other 3rd party plugins are installed?

I use VS2005 with Visual Assist X 2005.11.25. True, the problem only occurs with Visual Assist enabled. But I've become pretty happy with Visual Assist, so I hope it can be made to work.

Search highlighting is also due for the next major version, and the other features (proper buffer numbering, command line tab completion, and external filters) will also come in some time.

Superb!

Thanks again!

Thank you!

7

Re: Modes and keymapping

I'll have a look at the Escape-swallowing problem. It shouldn't happen, and as far as I've noticed, it does not happen for me. Could you list which VS version you are using, and what (if any) other 3rd party plugins are installed?

I use VS2005 with Visual Assist X 2005.11.25. True, the problem only occurs with Visual Assist enabled. But I've become pretty happy with Visual Assist, so I hope it can be made to work.

I'll try to reproduce & fix it. ViEmu already goes to great lengths to be as Visual Assist compatible as (humanly) possible. I won't go into the nasty details. Thanks for reporting that the problem is due to an interaction with VAX. I'll let you know as soon as something is ready.

8

Re: Modes and keymapping

I use ViEmu with DevExpress's CodeRush installed, and I've just installed Visual Assist to try it out.

After disabling a few features to stop it from clashing with DevExpress setup (which works perfectly with ViEmu BTW as long as you have nothing bound to Esc in their shortcuts menu), I noticed that Visual Assist is swallowing my escapes also -- which is a shame, because I really like the extended syntax highliting features - finally I can make everything look like 'elflord'!

Anyway, just thought I'd add my 0.02c.

9

Re: Modes and keymapping

Johan, thanks for the feedback. I'll certainly have a look at it as soon as possible.

By the way, there is one problem with ViEmu<>CodeRush, which I managed to provide a fix for last week or so (with the help of the customer who was experiencing it and the nice guys from DevExpress). It deals with automatically entering insert mode when using the inline variable rename refactoring method in CodeRush, and consists in a DXCore plugin that has to be installed in their plugins directory. Let me know if you're interested, as I haven't gotten around to making it available publicly.

10

Re: Modes and keymapping

I tend to turn all the refactoring stuff in CodeRush off, and refuse to install their Refactor package as it causes my IDE to slow to a crawl!

I am always interested fixes for CodeRush stuff (my manager spends a lot of time reporting bugs to them and talking to the dev team over their), so I'd like to get my hands on it if possible.

11

Re: Modes and keymapping

Oh and interestingly enough, Visual Assist has stopped swallowing my escapes all together .....I have no idea why.

12

Re: Modes and keymapping

Johan,

Sure, download the following file:

  http://www.viemu.com/DXViEmuCompat.dll [Update May 25: the link was broken!]

and copy it into your DXCore plugins directory (typically c:\Program Files\Developer Express Inc\DXCore for Visual Studio .NET\1.1.\Bin\Plugins). You need to have ViEmu version 1.4.5-alpha-4 or later - the latest one is the following one:

  http://www.viemu.com/ViEmu145a7.msi

Which also fixes the cursor position after the :d command (you need to manually uninstall your current version of ViEmu before installing this one).

The net effect is that ViEmu will enter insert mode automatically when you use one of the CodeRush commands that enters "llinked identifier editing".

As always, I'm amazed by the randomness of the Visual Assist interaction problems. That only makes them more annoying and harder to fix.

BTW, the DevExpress people were very helpful in fixing the interaction, supplying a DXCore plugin skeleton from which I could detect the event. The customer who originally notified the problem also hacked it a bit until the behavior was perfect. All in all, a satisfying experience.

13

Re: Modes and keymapping

JNG wrote:

As always, I'm amazed by the randomness of the Visual Assist interaction problems. That only makes them more annoying and harder to fix.

I like both tools, ViEmu and Visual Assist X but yes, the randomness of the interaction problems can be very annoying.

I had some thoughts, don't know if they are possible or not.

A lot of my annoyances with Visual Assist X and ViEmu could be solved by ViEmu turning off Visual Assist X's 'Autotext' feature when ViEmu is in command mode.  Not all of Visual Assist X, just the Text Editor -> Suggestions...  Without changes to Visual Assist X that's probably not possible though.  I doubt that sending a message to set that control would work as it's the typical windows thing of the options dialog not being live, it requires an apply and or ok to take effect.

Most of my other thoughts involved minor changes to Visual Assist X to make it behave better.   I posted them to the Visual Assist X suggestions forum.  e.g. A minimum number of characters to type before suggestions kicks in.  When I am using h, j, k, l to navigate in ViEmu command mode or use a, o, i to enter edit mode, I really don't want those keys to be used as the basis of a suggestion, hence the turning it off in ViEmu command mode and turning it back on in text entry mode.  But to me, probably as a Vi user who hates the arrow keys, a single character will hardly ever produce a useful suggestion so when I use the suggestions, which I do a lot, I type until it's disambiguated and I never go to the arrow keys.  Hmmm... now if Visual Assist X had it's own vi mode for navigating the list box by hitting escape (in stead of escape dismissing the box) that would be kind of nifty.

Another suggestion I had for Visual Assist X involved the 'Autotext' editing.  If they just had the option to have an Autotext thing completely override any suggestions instead of complementing them and having them cabable of producing no suggestion list that would solve my single key press suggestions being annoying and producing useless suggestions issue as well.

Anyway, most of this is really for Visual Assist X and not ViEmu but I thought I'd post here as well.

14

Re: Modes and keymapping

Jeff, thanks a lot for the feedback. ViEmu already goes to gret lenths to try to avoid VAX's auto-suggestion feature. It was the 1st thing I had to do. Here's the deal: both ViEmu and VAX subclass the editor window and filter keypresses, doing their things. Given that VAX assumes you are typing and brings up the autocompletion box, I try to subclass the window *after* VAX does. In that way, I can get hold of the keypress first, and not pass it on to VAX. How do I do I try to do it? I actually subclass the window *twice*, the first time quite early, but the second time actually only when an actual keypress or mouse action happens. The first subclassing doesn't do anything but show a block cursor (else it would be confusing) and trigger the second, 'real', subclassing.

For some reason that isn't clear to me, it seems this doesn't work reliably. I don't use VAX myself, so I only tested when I initially tried to address the compatibility problems.

I will try to get in touch with them directly and see if they can be of help - if they could point out exactly when they subclass the window, I could try to ensure I always do it afterwards. I'll let you know what comes up.

With regards to other features such as vi keybindings in their autocompletion window... I can't even know when it's been shown. Actually, not VS's own Intellisense let me know whether it's active...

15

Re: Modes and keymapping

In case anyone else is checking, the developers from Whole Tomato have kindly provided information that enables ViEmu to work properly alongside VAX. I have a new build in testing and I will make it available in the next few days.

16

Re: Modes and keymapping

Hi J,
I think that you may have answered this in a prior post in this thread, but I'd like to ask it explicitly anyway.

Would it be possible to have viemu ignore the first 'esc' if there is an intellisense popup? Right now if you want to type something that is not in intellisense and hit 'esc' you have to hit 'i' to get back to editing. If possible, then I'd suppose it'd certainly be a user preference thing...

thanks, nathan

17

Re: Modes and keymapping

Nathan,

In the past, I've asked the developers from Microsoft for a way to detect whether there is an Intellisense dropdown on display. I haven't been successful in obtaining an answer (and there isn't a documented way). I will ask them again and see whether I can get some way to detect the condition.

Thanks!

18

Re: Modes and keymapping

In case anyone checks this, I released a (non-official yet) version with specific provisions for Visual Assist and Resharper compatibility yesterday. Details and link to download here:

  http://forums.ngedit.com/viewtopic.php?id=44

[ EDIT: The official release is now available as described here: http://forums.ngedit.com/viewtopic.php?id=45 ]