VIM - :b command support

[b]

Using vi/vim mode, I catch myself constantly wanting to quickly move to different named buffers using :b <buffer>.   A couple revs back, the :b command was partially implemented.  You can reference a numbered buffer (e.g., :b 1 to go to buffer 1).   But I catch myself not remembering the number, but the file name.

In vim, you can name the buffer and do the same thing:   :b Makefile
Moreover, vim supports tab expansion so I could execute:  :b Ma<tab> and have it expand the file of the buffer loaded that matches.  These time savers would be really appreciated if they were added to SlickEdit.

[Clark]

There are some interesting possibilities that could be done for the ":b" command.

Please try the "e" command since it has some interesting features you really need to try.  Press Ctrl+A to get to the SlickEdit command line. If you have a buffer named /a/b/c/Makefile, type "e Makefile". You should see completion listed for the full name. You can either just press Enter or select from the completion list. Better yet, if you have a workspace open with a ton of files in it, type "e name.cpp" where you have a file named /a/b/c/name.cpp in your workspace and this will be opened. This feature is called smart open. The same feature is the Open tool window has.

Maybe the :b command should use the same logic as the "e" command when the argument is not a number?

[b]

With vim, the only difference between the :e and :b is that :e will open a new/existing file, where :b will only make the buffer of the matching filename that is already open, active.   

I was able to confirm that the :e does open a buffer of the same name if matched.   Although, my habit of hitting <tab> to expand my options still is deeply ingrained in my fingers (and tab expansion is not implemented and highly desired as you are aware with the native slickedit commands).

Thanks for the alternate.

[Clark]

I'm not talking about ":e" which uses the EX command line. I'm talking about the SlickEdit command line "e" command. I hope that makes sense.

[b]

Sorry, my mistake.  Thanks for the info.

[Clark]

It would make more sense to have ":e" do what the "e" command does since the both support existing buffers and opening new files. Then ":b" should only do the buffer related smart open stuff. I'm just throwing out some ideas. What do you think?

It's trivial to make :e do what the "e" command does (except for the auto completion part). The only potential confusion is with ":e file" where you already have a buffer named "file" in a different directory but really want to create a new one in the current directory. This doesn't happen that much. The work around is to type ":e ./file" instead. IMO the upsides totally out way the downsides but it would be a difference from VIM.

[b]

I've been playing with the e command and, yes, it is a tad bit different, but appears close enough.  I'd be fine with it (I don't know what other customers using the VIM CUA would think). 

I do have a question, though, how do you delete the last <whitespace> delimited word? 

I can delete the last natural word, but that only deletes the word back to the first encountered /.  If I tab to fast, I lose what I first started typing and find I have to delete the entire command bar and try again (e.g., e fo<tab> may go to e some/really/long/path/to/formulate.c when I needed to get at some/other/path/foo.c)   I'd rather a single keystroke that would delete the entire path and let me reenter (sort of like a ^W in vim mode with any of the : commands).

I didn't see anything obvious looking at the online help (other than multiple keystrokes to essentially perform the single keystroke I'm used to)

[Clark]

There isn't a path delete command. Wouldn't be hard to write but you'd have to find a key to bind it to.

[b]

Not so much a path delete, as much as a whitespace delimited word delete.   

This may give me an excuse to play with the macros.

[Clark]

The current word commands work off the language specific word characters but there are some emulation options which muck with this simplicity. I think the buffer property name is p_word_chars. This property is stuffed into a Slick-C syntax character set regex (i.e. "[p_word_chars]").

You can either cut out code from existing word commands to write your own or try wrappering an existing command and temporarily modifying p_word_chars and other options.

I would expect a space delimited word match to be easier.

[Clark]

Using vi/vim mode, I catch myself constantly wanting to quickly move to different named buffers using :b <buffer>.   A couple revs back, the :b command was partially implemented.  You can reference a numbered buffer (e.g., :b 1 to go to buffer 1).   But I catch myself not remembering the number, but the file name.

In vim, you can name the buffer and do the same thing:   :b Makefile
Moreover, vim supports tab expansion so I could execute:  :b Ma<tab> and have it expand the file of the buffer loaded that matches.  These time savers would be really appreciated if they were added to SlickEdit.

For v20.0.1, we will enhance :b so when a non-number buffer id is specified (like ":b Makefile"), it will search buffers ending with that name (uses smart open feature). Also :e will be enhanced so it will use smart open on the file name argument so it find buffers, workspace files, and files in the same directory as the current buffer.

[b]

I'll look forward to the new feature (and my finger memory thanks you in advanced).