SlickEdit 12.0.2 Vim Emulation Bugs

[shardin]

Vim emulation bugs in SlickEdit 12.0.2:

:%s/apple/cherry       - Bug? Replaces "apple" globally in the file as if /g option was specified

:%s/apple/cherry/i     - Bug.  Supposed to case-insensitive, but performs case-sensitive replace

:%s/apple/cherry/gc   - "Invalid option" error

BUT, these work and might be useful in providing a hotfix:

:%s/apple/cherry/gic   - works (global case-insensitive confirmed replace in the file)

:%s/apple/cherry/gi    - works (global case-insensitive replace in the file)

:%s/apple/cherry/g    - works (globally replaces "apple" with "cherry" in the file)

:%s/apple/cherry/c    - works (asks confirmation to replace each "apple" found in the file)

[Ryan]

I'm looking into these now (also http://community.slickedit.com/index.php?topic=1863.0)...but isn't the first one ok?  I always thought that the argument before s specifies a range, and that % is equivalent to the entire file...akin to 1,$  .

Also, I don't get invalid option when I do :%s/apple/cherry/gc ...it works for me.

- Ryan

[shardin]

Ryan, you are correct on both!  I'm sorry for the mistake and will test much more carefully before posting.  I updated original post.

On the other hand, the problems with next_window are confirmed and appear to be caused by Vim emulation:

1. close all files in SlickEdit
2. Ctrl+A and open several files with one command:
    e file1.cpp file2.cpp file3.cpp
3. click on the Window menu and notice only file3.cpp is listed (so next_window won't work with only 1 window)

Same steps using CUA avoids the problem.  But this happens with Vim emulation.

[Clark]

The reason the window menu does not show all the buffers is because "One file per window" is off.  The window menu is only supposed to show windows and not buffers.  The "One file per window" option is on Tools>General>General Tab.  Try turning it on to see if you like it.

[Ryan]

Ryan, you are correct on both!  I'm sorry for the mistake and will test much more carefully before posting.  I updated original post.

No worries!  We welcome any and all bug reports that make our product better .  Attached is a new version of ex.e which should fix the case sensitivity problems in Vim search/replace.  Backup your ex.e in your macros directory, save this version to the same directory, and load via Macro > Load Module...

- Ryan

[Tom Plunket]

One of the guys here is complaining that when he's got a selection active and types ':w' into the commandline, it silently does a "save selection over current file".  ...after which he gets a prompt that an external process has modified the file, and upon reloading he finds the file contents are only the selected text.

Is this intentional?

[Ryan]

One of the guys here is complaining that when he's got a selection active and types ':w' into the commandline, it silently does a "save selection over current file".  ...after which he gets a prompt that an external process has modified the file, and upon reloading he finds the file contents are only the selected text.

When I do this, I get the standard SlickEdit "Write Mark" dialog...which tells me that the file already exists, and asks me if I really want to save it.  I'll keep seeing if I can reproduce this, but...no, it's not intended behavior.  What platform is he running on, and do his files reside locally?  This happens every time he does said command?

Seems that in Vim, you shouldn't be able to do this unless you do a :w!...in which case it should silently save the selection over the file, so I will change this.  He can make use of the Backup History tool window to restore any of his files.

- Ryan

[Tom Plunket]

The situation is remedied (at least mostly) by checking "deselect on copy" and "auto-deselect" the "problem" seems to go away.  So yeah, in gvim he got a prompt that said "have to use :w!", but SlickEdit (silently) allowed simply :w to save the selection.  Not sure what other options might affect this, but as soon as he hits : the command line adds '<,'> (but that was un-noticed at first) and then the w then I guess operated on the selection.  So this may illuminate more of the "problem."

thanks,