Does something like this exist?
In Vim this is called an autocommand. The relevant help topic can be found by typing :h autocommand (sic!)
An example code to put into vimrc:
augroup typescript_save | au!
autocmd BufWritePost *.ts !tsc <afile>:p:S
it doesn't seem to pass in the argument
Because you haven't passed it. The right syntax is:
command! -nargs=1 Vres vertical resize <args>
Simply read :help :command until the very end to know all the options.
The problem is that, in the body of your EchoMessage() function, text does not refer to the value passed in, but instead to a different local variable. Use a: to refer to parameters passed in:
See :help internal-variables (and specifically :help function-argument) for more details.
You can use :h <mods> to do this, it expands to modifier or nothing. It's added at patch 7.4.1898
command Foo call FooSplit(<q-mods>)
exe a:mods 'new'
Above example use <q-mods> instead of <mods>, as you need it as a string.
Using the -range flag when defining a user-command usually allows the user to provide a range to the command:
command -range Mine echo <range> <line1> ',' <line2>
" the next one is equivalent to .Mine by default
However, sometimes you want to be able to do
Or else use the number provided as a <count>:
Can it be written?
Possibly, but it might be a lot harder than expected. Because, what do you do with commands that close the current window? Or commands, that add lines above the current cursor position?
One problem you are running into is described unter :h function-search-undo.
The last used search pattern and the redo command "."
will not be changed ...
I’d recommend an <expr> mapping—make the following changes:
nnoremap <expr> <Leader>b BuildSystemTask()
And then in your function:
return ':make! '
An alternative would be to use the feedkeys() function
You must add -nargs=1 to your command:
:command -nargs=1 FooCommand :call Foo(<q-args>)
This tells Vim not to treat white space as separator. Only white space between the command name and the first non-white space character is removed from the argument passed to Foo(). All other spaces and tabs, even trailing ones, are included in the argument.
Am I missing something here?
Yes, as written in :h 'isfname':
If the character is '@', all characters where isalpha() returns TRUE
are included. Normally these are the characters a to z and A to Z,
plus accented characters. To include '@' itself use "@-@".
So @ in isfname, iskeyword etc. actually means "all alphas", not literal "@". And you still ...
To change the behavior of <Del> so that it only deletes the character under the cursor and doesn't behave like backspace when at the end of the line, you can use the following mapping:
cnoremap <expr> <Del> getcmdpos() <= strlen(getcmdline()) ? "\<Del>" : ""
See @D.BenKnoble's answer for a solution to deleting until the end of ...
You can use the following function:
let l:cmd = getcmdline()
let l:pos = getcmdpos()
let l:newcmd = strpart(l:cmd, 0, l:pos - 1)
To use it on the command line, you need to do (I choose <C-x> arbitrarily since it wasn't used for anything else, and reminds me of X in normal mode):
You're missing a final <CR> at the end of your normal command. If at the end of normal you have an incomplete command, it will cancel it as if <Esc> or <C-c> was pressed.
So this should fix it:
execute "normal! :'<,'>retab\<CR>"
(Using \r inside the double quotes is also possible.)
But in this case, there's probably no need ...
There actually is a built-in map which does this, <c-^> or control+^
If you don't like this (it is indeed difficult to press), you can remap it simply.
nnoremap gb <c-^>
Note: I am using gb here since B is already a vim command. You can use B if you really want, but be aware that you would be overriding a built-in.
I am also going to show ...
Hmm. This is interesting. Here's what get saved as the command (:com Test0):
nnoremap <NL> :echom "c-j"<CR>
(<C-J> is equivalent to <NL> in Vim)
So what do we know about the <> format? That it can be used in mappings and abbreviations as a substitute for the represented keys/chars. That it can be used in exe command arguments ...
It's faster as :buf won't reload the file from disk, whereas :edit will, which is different behaviour.
This is why it's slightly slower in some cases. For most purposes, this is not a huge issue, although it can be over NFS connections, or with larger files. The performance should be identical when opening files that are not yet loaded by Vim.
You can test/...