Support for plugin authors needs to be improved (poll)

[brammool]

Vim has many features that plugin authors can use to achieve their goal. But what is still missing? What could be simplified? What is currently impossible?

Please use one comment for each suggestion. Use the thumbs-up and thumbs-down to express whether you agree with a specific answer/request (you can find that in the header of the comment on the top right, looks like a smiley face).

NOTE: Let's delete comments that are older than 24 hours that are not items to vote on. Otherwise the list gets too long and confusing. This issue is not for discussing alternatives, the author can update the suggestion when needed (but don't change the meaning, otherwise previous votes are miscounted).

(I tried starting this on stackoverflow, but apparently opinions are not welcome there)

[UncleBill]

Really hope vim-script can be faster! 💯

[ZyX-I]

Currently syntax highlighting is strictly regex-based. This is not fit for some languages*, is occasionally slow and attempts to highlight identifiers based on their type (e.g. like in C highlighting function-like macros separately from functions and functions separately from variables which are pointers to functions) rarely work well and always require quirky hacks, matchaddpos or not. It would be good to be able to define highlighting in a loadable C library while still allowing matches/&hlsearch, diff/sign/… highlighting, etc work without needing to care about them in that library.

* Based on poor (in terms of semantic) performance of highlighting of VimL itself (like e.g. highlighting certain identifiers as commands while they are inside expressions: check let foo = fu + bar, why is fu highlighted like let?) it is one of the victims.

[tomtom]

IMHO the only feature really missing is some sort of overlays (à la emacs: https://www.gnu.org/software/emacs/manual/html_node/elisp/Overlays.html). This would provide for region-local maps, variables etc. This way information could be stored with some part of the text (and it would move with the text).

[tomtom]

The last time I tried, I found it rather difficult to work with subprocesses reliably across OSs -- e.g. linux + windows. Cross-plattform compatibility could be improved maybe.

[tomtom]

It would be great to have a standardized APIs for project-related information (e.g. file lists, root directory, VCS type, a way to set project-specific buffer-local options / variables etc.). Much of this can be implemented in vim plugins but it would be preferable if vim provided a standard way to do this.

[chemzqm]

Add an option to enable fuzzy match and smart case when filter complete items(with noinsert in completeopt), vim does the filter by strict match. Complete plugin could help to do that, but that would cause additional redraw of the screen.

[chdiza]

It would be great if there were more commands or functions removing :highlight attributes without having to do a :hi clear or :syn clear and starting all over, and without forking and maintaining one's own tweak of a colorscheme, and without having to parse the output of :highlight. For example, there should be...

• A way to remove all occurrences of bold that appear in a guifg={,}bold{,} at one time with one command, while leaving all other highlighting intact.

• Or for removing underline, etc, from everything while leaving all other things set by a colorscheme intact.

• Or even for setting some sort of "blocking" that will prevent a colorscheme from being able to set certain elements in the first place. E.g., :highlight disable italic *, which would mean that a colorscheme which tries to highlight something as italic will be prevented from doing so.

[yegappan]

Add support for compiling Vim plugin code into byte code. This will help in improving the
performance of Vim plugins.

[prabirshrestha]

Add support for async autocmd. BufWritePreAsync, so that plugins can run format the code or auto fix lint issues before it is saved to disk. Useful to implement LSP plugins.

[prabirshrestha]

Ability to go to full screen :FullScreen and :ToggleFullScreen in gvim without dll hacks.

Edit - Merging Thread - Update 1 by @tonymec

@prabirshrestha :

Ability to go to full screen :FullScreen and :ToggleFullScreen in gvim without dll hacks.

What dll hacks? :set lines=99 columns=999 has always been good enough for me, and if the distance of up to one character cell width and/or height between the gvim screen and the edges of the video screen troubles you, you can always use the Maximize button, usually near the top right corner.

Getting out of full screen programmatically may be less evident if you used that Maximize button (there is always the Unmaximize aka Restore button), but if you didn't, it is just a matter of setting 'lines' and 'columns' to some lower value, or to their original values if you saved them before going into full screen mode, e.g. by means of something like the following (which assumes 'nocompatible' so continuation lines can be used):

au GUIEnter * command SetFullScreen -nargs=0 -bar
    \ let s:FullScreen=1
    \| set lines=99 columns=999
au GUIEnter * command ClearFullScreen -nargs=0 -bar
    \ let s:FullScreen=0
    \| let &lines = s:SaveLines
    \| let &columns = s:SaveColumns
au GUIEnter * command ToggleFullScreen -nargs=0 -bar
    \ if exists('s:FullScreen') && s:FullScreen
        \| ClearFullScreen
    \| else
        \| SetFullScreen
    \| endif
au GUIEnter *
    \ let s:SaveLines = &lines
    \| let s:SaveColumns = &columns
    \| SetFullScreen

(Omit the last | line if you don't want to start up in fullscreen mode.)

Merging Thread - Update 2 by @prabirshrestha

@tonymec by full screen I don’t mean maximize. Full screen as in no task bar and title window. I want my vim to be in one monitor and take all the pixels there similar to watching a movie.

For now might be we shouldn’t pollute this thread. Might be worth waiting for few days and when these gets moved to own separate github issue we can discuss further.

[prabirshrestha]

Add support for QuickPick similar to VsCode and SublimeText - https://code.visualstudio.com/docs/extensionAPI/vscode-api#QuickPick

This is basically what ctrlp.vim/fzf/fzy/vim-fz does but better. As a plugin author it is very difficult to support all these plugins to get fuzzy search. sometime I don't even use those and it becomes a maintenance headache for me to support it. I would like to see vim provide one of those UI so as a plugin author I only need to support one of them. Similar to how we have loclist and quickfix list. Ship it by default so I don't need to tell users to install more plugins to get fuzzy picker working.

Problems with current fuzzy search.

1. Not fast with pure vimscript (ctrlp), hence need to use external command line such as fzf/fzy or install python/c bindings to ctrlp
2. Able to change the query on the fly. for example, If I want to create a npm install plugin which allows us to search npmjs.org I can't download the entire results and tell user to search. If the user pauses while searching I need to be able to cancel and reset the search but without closing and opening the QuickPick.
3. Fuzzy Search and highlighting matches should be done in a different thread so the main UI thread is not blocked.

Simple api.

const items = [
    { 'label': 'git merge', description: 'Git merge', 'detail': 'Merge branches or commits in git', 'data': 'custom_data1' },
    { 'label': 'git commit', description: 'Git commit', 'detail': 'Create a git commit', 'data': 'customdata2' },
];

vscode.window.showQuickPick(items);

Use cases: Fuzzy search for files/buffers/windows/tabs/symbols such as functions/classes or anything that the user want.

[bstaletic]

A second non-interactive pop-up menu for function parameter hints and overload lists would allow a nice interface for every plugin that is doing any kind of completion.

There has already been a lot of work done by me and @puremourning.

The detailed RFC is here
The vim-dev thread is here
And the work-in-progress code can be found in my vim fork.

However, I couldn't figure everything out, especially the interaction with the <C-x> mode.

[prabirshrestha]

Add support for TreeDataProvider similar to vscode - https://code.visualstudio.com/docs/extensionAPI/vscode-api#TreeDataProvider
Needs to support async expansion of child nodes.

Use cases: Searching dependencies.

File explorer:

Navigation around symbols:

[prabirshrestha]

Add support for easily making http calls via vimscript without spawning curl in the background.
Also needs to support the following:

1. gzip/br encoding.
2. Useful for searching npm packages online when integrated with QuickPick
3. Add support for aborting http requests.
4. Uri parser. (Also useful for Language Server Protocol)

[prabirshrestha]

First class encoding/decoding support and utils function

1. md5 (Useful to validate md5 hash when the download is complete)
2. sha
3. HtmlEncode/HtmlDecode
4. UrlEncode/UrlDecode

https://github.com/mattn/webapi-vim

[tonymec]

@prabirshrestha :

Ability to go to full screen :FullScreen and :ToggleFullScreen in gvim without dll hacks.

What dll hacks? :set lines=99 columns=999 has always been good enough for me, and if the distance of up to one character cell width and/or height between the gvim screen and the edges of the video screen troubles you, you can always use the Maximize button, usually near the top right corner.

Getting out of full screen programmatically may be less evident if you used that Maximize button (there is always the Unmaximize aka Restore button), but if you didn't, it is just a matter of setting 'lines' and 'columns' to some lower value, or to their original values if you saved them before going into full screen mode, e.g. by means of something like the following (which assumes 'nocompatible' so continuation lines can be used):

    au GUIEnter * command SetFullScreen -nargs=0 -bar
        \ let s:FullScreen=1
        \| set lines=99 columns=999
    au GUIEnter * command ClearFullScreen -nargs=0 -bar
        \ let s:FullScreen=0
        \| let &lines = s:SaveLines
        \| let &columns = s:SaveColumns
    au GUIEnter * command ToggleFullScreen -nargs=0 -bar
        \ if exists('s:FullScreen') && s:FullScreen
            \| ClearFullScreen
        \| else
            \| SetFullScreen
        \| endif
    au GUIEnter *
        \ let s:SaveLines = &lines
        \| let s:SaveColumns = &columns
        \| SetFullScreen

(Omit the last \| line if you don't want to start up in fullscreen mode.)

[puremourning]

A way to post messages or status updates to the user asynchronously such as status messages of a downstream process. Typical use case might be showing the parse or startup status of a background syntax checker, linter, completion engine.

It’s possible currently but options aren’t great:

• echo from callback (bad, as this can overwrite/be overwritten by other things)
• open another buffer/window and write to it. (uses a lot of screen real estate, tricky because cursor moves fire autocommands, setting up scratch buffers is nontrivial, etc.)
• statusline expression (expensive, and requires users to set a specific stl, or use some statusline plugin etc)

[prabirshrestha]

@tonymec by full screen I don’t mean maximize. Full screen as in no task bar and title window. I want my vim to be in one monitor and take all the pixels there similar to watching a movie.

For now might be we shouldn’t pollute this thread. Might be worth waiting for few days and when these gets moved to own separate github issue we can discuss further.

[chemzqm]

Add autocmd for window scroll event or emit event on scroll, so it could be possible to add information for visible lines after scroll. The codeLens feature of LSP requires that.

[chemzqm]

Expose selected complete item on select change of completion(could just use TextChangedP), and make pupup menu could reflact the change of selected completion item for resolved infomation (ex: change of menu filed) from server.

[chemzqm]

Add event/autocmd for visual selection start & end, so plugin could add signs to indicate that there're possible actions could be done for select region, just like VSCode's lightbumb feature.

[LucHermitte]

@tomtom said:

It would be great to have a standardized APIs for project-related information (e.g. file lists, root directory, VCS type, a way to set project-specific buffer-local options / variables etc.). Much of this can be implemented in vim plugins but it would be preferable if vim provided a standard way to do this.

It looks quite similar to my project feature and its p:variables that I'll love to see natively supported. => +1

[LucHermitte]

I'd like a better way and simpler way to fetch the current callstack. I did open a RfC on the subject: #1125.

TL;DR: it can be used for logging, for DbC, for unit testing. At this time it can be emulated but there are two problems: 1- it's extremely slow, 2- we need to take the locale into account, which is slow, and which is quite complex on non *nix platforms.

[LucHermitte]

I'd like fast functions that permit to work on lists. At this time, I'd like to see find/find_if functions, and a reduce one as well.

More generally, I'd like most of the list and dictionary related functions I've implemented in lh-vim-lib to be standard.

[LucHermitte]

Check the functions implemented in existing library plugins. Most of them would be welcomed as standard functions.

I've a non exhaustive list at the end of the README of my core library plugin: https://github.com/LucHermitte/lh-vim-lib#some-other-vim-scripting-libraries

[LucHermitte]

I'd like to be able to run vim script command in background threads. For instance, running mkspell or adding thousand of new keywords to highlight is too slow to be automated after ctags has been ran on a file we've just saved.

[cecamp]

Bram Moolenaar wrote:

Vim has many features that plugin authors can use to achieve their goal. But what is still missing? What could be simplified? What is currently impossible? Please use one comment for each suggestion. Use the thumbs-up and thumbs-down to express whether you agree with a specific answer/request (you can find that in the header of the comment on the top right, looks like a smiley face). (I tried starting this on stackoverflow, but apparently opinions are not welcome there)

I'd like a way to rename a buffer that didn't have side effects. Sure would help me get an updated version of netrw out! Regards, Chip Campbell

[h-east]

CLPUM(Command-line mode PopUp Menu)
http://h-east.github.io/vim/

Get a patch from here.
http://h-east.github.io/vim/#how-to-get-the-patch

vim_dev thread:
https://groups.google.com/d/topic/vim_dev/E3zq6C_b23k/discussion

[chrisbra]

Better VimScript APIs for some of the existing functionalities, e.g.

• sign definitions
• :hi commands
  Update
• digraph output (get digraphs, create digraphs, return digraph from 2 characters), see also #3572 and my unicode plugin

One can use the existing :sign or :hi interface commands, but working with those is awkward and slow. So having dedicated functions for manipulating those features directly would be highly appreciated.

[tomtom]

Better VimScript APIs for some of the existing functionalities, e.g.

* sign definitions

This reminds me of another point: IMHO the current signs API is broken. There is no easy way to find out if an ID is already in use. As a consequence, it happens that signs from other plugins are accidentally overwritten, deleted etc.

[tomtom]

@idbrii You can define a command in vimL that displays another buffer instead of the current one so that the layout doesn't change when a buffer is deleted by the user (I personally use something based on vimtip1078). This doesn't provide any guarantees for when a plugin or vim itself creates a new buffer, deletes an old one etc.

[Maelan]

Deprecate VimL for new plugins. (Extend significantly the Python API.)

I hope not. Not everybody wants to use python.

I don’t quite understand. Some authors would not like to use any of VimL and Python. Still, they have no choice. As for why would someone prefer VimL over Python, could you be more specific? Python isn’t the best language of the world, but VimL is a terrible, terrible programming language.

For instance, Javascript programmers agreed at some point that eval() was evil; yet in VimL, :execute often is the only and idiomatic way. Inconsistent syntax makes it practically impossible to get escaping right (many snippets given on StackOverflow and such are wrong because of that). The syntax of regexes changes according to user options. And so on, and so on. Hell, even Vim has a hard time linting VimL, as someone pointed out earlier.

That, plus VimL being a niche language, by contrast with the widely-known, general-purpose Python.

[fritzophrenic]

Why use VimL? Because learning VimL is just learning Vim itself. Almost anything you learn in VimL can be used in daily interactive editing, and anything you use in daily interactive editing can be used in VimL. Though you are probably correct it is not ideal for heavyweight programming tasks, it is wonderful for when you already have a series of commands or tasks, which you already know how to do interactively, and just want to make a plugin to do it automatically instead of typing it out every time. It's also guaranteed to work on (almost) any Vim install, whereas Python and other languages must have support compiled in, and the appropriate library installed.

[tonymec]

Deprecate VimL for new plugins. (Extend significantly the Python API.)

I hope not. Not everybody wants to use python.

I don’t quite understand. Some authors would not like to use any of VimL and Python. Still, they have no choice. As for why would someone prefer VimL over Python, could you be more specific? Python isn’t the best language of the world, but VimL is a terrible, terrible programming language.

For instance, Javascript programmers agreed at some point that eval() was evil; yet in VimL, :execute often is the only and idiomatic way. Inconsistent syntax makes it practically impossible to get escaping right (many snippets given on StackOverflow and such are wrong because of that). The syntax of regexes changes according to user options. And so on, and so on. Hell, even Vim has a hard time linting VimL, as someone pointed out earlier.

That, plus VimL being a niche language, by contrast with the widely-known, general-purpose Python.

From a Vim point of view, Vim script is not a niche language: it is the native language of Vim commands. Every serious Vim user knows Vim script, which is the language of the vimrc.

From a Vim point of view, Perl, Python, Tcl, Ruby, lua and Scheme are niche languages, supported only by means of optional features; and C can be used too but only by recompiling the editor, so it is usable for built-in features (standard or optional) but not for plugins. All other languages are simply out of context, not part of the "universe of discourse".

Oh, and BTW, anyone who thinks that Vim script (which I might loosely label an Algol-like structured language) is "terrible" and that Lisp (a prefix-Polish notation with lots of parentheses) is "great" is losing his/her time discussing Vim, what (s)he should use is Emacs. 😛

Best regards,
Tony.

[romainl]

Some authors would not like to use any of VimL and Python. Still, they have no choice.

They can already write their plugins in Python, Perl, Ruby, Scheme, Lua, Perl, and even Tcl. That's plenty of choice.

As for why would someone prefer VimL over Python, could you be more specific?

I have no use whatsoever for Python or any of the languages above so I don't want to have to learn any of them in order to configure/extend my text editor.

For instance, Javascript programmers agreed at some point that eval() was evil; yet in VimL, :execute often is the only and idiomatic way.

Different languages; different paradigms. Get over it. That meme is just as baseless in vimscript as it has always been in JavaScript. Also, we, JavaScript "developers", never agree on anything for more than a couple weeks so it's hard to take us seriously and use our shenanigans as an example of something done right.

Inconsistent syntax makes it practically impossible to get escaping right (many snippets given on StackOverflow and such are wrong because of that).

What's inconsistent, exactly? And what does SO has to do with any of this?

The syntax of regexes changes according to user options.

Not if the plugin author cared to read :help magic.

Hell, even Vim has a hard time linting VimL, as someone pointed out earlier.

Well, Vim doesn't even have a single built-in function or command for linting its scripting language so… what does that even mean?

That, plus VimL being a niche language, by contrast with the widely-known, general-purpose Python.

All languages are niche languages. As a web frontend developer I couldn't care less about learning Python, Ruby, Lua, or elisp, has I have zero use for them in my line of work. Those languages are niche languages from my point of view.

Vimscript is just the commands you use every day, plus a bunch of useful functions. You don't learn vimscript: you learn Vim and vimscript comes along the way.

[puremourning]

This would help I think: Simplify and sanitise the execution environment for vim scripts.

This could include Script-local settings Or sand boxing of options within scripts plugins and mappings.

Many if not all scripts must use certain tricks to ensure they execute with know options, such as setting and restoring cpo, magic and remembering to include thinks like \v\c in regexes.

Perhaps this could include defining a set of option values with which which all plugins execute (such as the Vim defaults). This could be opt-in eg opting in with a single command.

I see a lot of vim scripts that break eg when settings like ignorecase and such are changed.

[ZyX-I]

Different languages; different paradigms. Get over it. That meme is just as baseless in vimscript as it has always been in JavaScript. Also, we, JavaScript "developers", never agree on anything for more than a couple weeks so it's hard to take us seriously and use our shenanigans as an example of something done right.

eval gets in the way of optimizations, is potentially a security issue and a number of times code with it looks ugly. Now while VimL has no optimizations, :execute does affect performance if you are unreasonable enough to use it in a high performance loop (eval not really: there is much less overhead on evaluating expressions). Though if you do have a high performance loop the best thing you may do is do all job in a condition expression, leaving loop body missing: evaluating commands always has much bigger overhead then evaluating expressions, all :execute does is making the overhead twice as big for each command which needs to be executed.

Eval/execute being a security issue is not the case in most places where it is used in VimL plugins though. But there are good habits out there which make :execute/eval() look bad not because it actually looks bad (in many places it is not, especially after you learn to write :execute "cmd" arg (I mean, omit explicit space and concatenation)), but because it is considered last resort technique in other languages developer is writing it for the reasons stated.

What's inconsistent, exactly? And what does SO has to do with any of this?

For example, escaping: there is different escaping for options, comma separated options, specific comma separated options (like viminfo where you do not escape comma, but put n at the end of the string), commands accepting one argument, commands accepting multiple arguments, commands accepting filenames on Windows, commands accepting filenames on linux, commands accepting expressions, :put =, commands accepting " as a comment, double quoted strings.

Try to create a table where rows are dedicated to some place you may want to put filename in (list is above) and columns are dedicated to characters which need to be escaped and list how you put literal character in each slot. List of characters: space, newline (it is possible to have newlines within file names on linux), %, $ (it is possible to have dollars within file names on both linux and Windows), \ (may be directory separator or part of the file or directory name, depending on the system), comma, ", |.

There are also inconsistencies like :highlight/:sign/:syntax having positional and keyword arguments like foo=bar with positional before keyword (with :sign and :syntax also having mandatory subcommand argument and :highlight not), :command having keyword arguments like -foo=bar and positional now after keyword, :autocmd having only positional arguments and not being too good at detecting them (you can define autocmd group named BufReadPost, guess what it will do with autocmd BufReadPost * :call MyFunc()?) while still really needing some optional arguments (lots of cases where * is used as a pattern and there would not be a problem with BufReadPost augroup if group was accepted as group=BufReadPost rather then just as a positional).

There is also inconsistency of what :command -complete does: -complete=command defines only completion, -complete=file forces glob expansion, environment expansion and command substitution in addition to defining completion.

I can also remember substitute flags: adding g inverts gdefault, always taking it into account and forcing plugin authors to use :execute every time they need :s, adding i or I makes ignorecase (and smartcase) ignored.

Also what does newline mean when reading VimL code from a file and when using :execute are two different things. You can’t have line continuation inside :execute string too.

Not if the plugin author cared to read :help magic.

If you only read :help magic all you can do is add \m, \M, \v or \V at the start of each and every regular expression. This is what help has suggested at the end of that section. And nobody likes to remember things for no good reason.

[yegappan]

Expose the tagstack feature through at least settagstack() and gettagstack().

The gettagstack() and settagstack() functions are supported now by patch 8.1.0519.

[tyru]

The virtual text feature of Neovim.
I didn't know that because I don't use Neovim, but this pull request simply describes the convenience.
dense-analysis/ale#2056

It makes various cases easy to implement:

• Show warnings / errors on cursor without seeing command-line at bottom like what ALE does
• Show informational text on existing text without a hack modifying buffer temporarily like what EasyMotion does
• Show variable names at function call like what Android Studio does

This is not the same as the conceal feature. Because

• The conceal feature can only replace with one character (:h :syn-cchar)
• The conceal feature can only set its position by pattern, because it is the sub-feature of :syntax
  • Vim regexp pattern can also specify position by line, column (/\%l, /\%c), but ...
  • I want the virtual text feature to follow the position like the above ALE example. I think it can combine with mark feature (:h mark) and highlight group (neovim seems to support setting highlight group to virtual text)

" setvirttext({text}, {mark}, {hl_group})
" Please see the below comment for {mark}.
call setvirttext('this is example text of virtual text', 'myplugin_markA', 'Error')

[tyru]

• I want the virtual text feature to follow the position like the above ALE example. I think it can combine with mark feature (:h mark) and highlight group (neovim seems to support setting highlight group to virtual text)

While writing above comment, I remember that I wanted the APIs of mark feature (:h mark).
Because mark is very useful to track position even the buffer is changed.
I want it to provide open APIs to add also custom mark by vim plugins.

Here is the example:

" It can set the information of the specified mark.
" It returns getpos() function's information (and more?):
" {
"   'bufnr': <buffer number>,
"   'lnum': <line number>,
"   'col': <column number>,
"   'off': <offset number when virtualedit is used>,
" }
echo getmark('a')

" And it can set mark too
"   setmark({mark}, {lnum}, {col} [, {options}])
call setmark('a', line('.'), col('.'), {
"\ optional, default: current buffer number
 \  'bufnr': bufnr(''),
"\ optional, default: 0
 \  'off': 0,
 \})

" Also it can get / set own mark
call setmark('myplugin_markA', line('.'), col('.'))

" After editing text ...

" Where is the position of the mark?
echo getmark('myplugin_markA')

I also edited my above comment to add the example of virtual text API.
The setvirttext() function only takes text, mark, highlight group.

[bfredl]

@tyru Note the Nvim API allow you to supply a list of chunks with different highlights [["text ", "Comment"], ["more text", "ErrorMsg"]], it would be good if an eventual vim API does the same. Also even though you supply a literal linenr to add the text, it still tracks changes (though only to line numbers so far, deeper refactors neovim/neovim#5031 are needed to also track column positions).

Also only after-EOL text (as in the ALE example) + highlighting of existing text is implemented so far in Nvim, anything that involves shifting of existing text (as in the android studio example) will be more tricky.

[tyru]

@bfredl Well, what is the difference from assigning different marks?

call setvirttext('text', 'myplugin_mark', 'Comment')
call setvirttext('more text', 'myplugin_mark_more', 'ErrorMsg')

Why does neovim support supplying chunks for same ID?

[bfredl]

Well, what is the difference from assigning different marks?

@tyru that it is two separate things with completely different purposes? The chunks in the Nvim API I mentioned, are differently colored chunks of the same text annotation, not different messages at different places. Consider a linter or expression evaluator (in the style of Light Table) that gives colored output, the API allows that coloring to be preserved verbatim.

Why does neovim support supplying chunks for same ID?

Why should we not allow such a thing? If the plugin just cares about updating all its annotations of a buffer in bulk, why shouldn't it be able to just delete the entire old state in one call? But if the plugin wants a separate ID per item, we are allowing that also.

[mattn]

shellshash for insert mode. On Windows, we use noshellslash in default. But we hope to use slash instad of backslash while editing HTML.

[machakann]

I think it's good to have heredoc-like syntax for Vim script.

Sometimes I make a script to generate multiple text files from a template. In some points, Vim script is a useful measure to handle such text processing, but one thing embedding a long template is not so easy now.

Usually, I prepare another file as a template. However, it would be better if we could just embed the template to a script file. Currently, it is possible to write:

let longtext = "The first line.\n
\The second line\n
\The third line.\n"

But, adding leading "\" and trailing "\n" is a little tedious (and also this is not highlighted correctly). It seems similar syntax is already in Vim script for :python, :ruby, :lua commands and so on. I guess it may be relatively harmless.

[lifecrisis]

One feature I use quite a bit is copying a region of VimL and sourcing it with the :@" ex command. This is useful for trying out bits of code while writing a plugin (something that needs to be done quite a bit).

This doesn't work when lines are continued with \ characters. For example:

let g:x =
        \ 'example'

... the above is valid VimL but can't be yanked and sourced like I would expect. This issue crops up enough to be frustrating.

[bfrg]

@lifecrisis

command! -bar -range Execute silent <line1>,<line2>yank z | let @z = substitute(@z, '\n\s*\\', '', 'g') | @z

From: https://stackoverflow.com/a/20262740

[liushapku]

I would like to request for arbitrarily user-defined marks with names not predefined by vim (including a-zA-Z0-9 and several other special marks like <, >, .).

Marks are very good facilities in vim which can be used to track positions. They are aware of the changes to the buffer. For example, the mark position will be adjusted automatically while there is deletion and insertion of lines before the mark.

In plugins, especially those use background async jobs provided by vim 8, we frequently have the needs to update the buffer at a certain position and this position should be adapted to buffer changes. This can be achieved by marking the position first and retrieve its position later using the mark.

However, the named marks provided by vim is exposed to the user and have shared access by all plugins. Therefore, one plugin has no way to protect the special marks which it relies on. The functionality of the plugin could easily break if the user or other plugins changed the mark position.

I then request to have user defined mark names for which the plugin users can create, just like the user defined match groups as provided by function matchadd(). For matchadd(), the id variable can be arbitrary as long as it is not used and IDs 1, 2, 3 are predefined by vim as used in :match :2match :3match.

I would like to thank @chrisbra and @inkarkat for referring this wonderful site to me and their suggestions on this issue. The original discussion can be found in vi.stackexchange.com

---

Just realized that @tyru already created a similar request. If you feel this post doesn't provide more information than his, please feel free to delete this one.

[tyru]

@liushapku it already exists
#3573 (comment)

[liushapku]

@tyru Thanks for having already done the work. My bad to not have read all the threads here.
I am very glad to know that there are others also want this appealing feature. Let's see whether it can be got in.

[liushapku]

@tyru, as for the api, I would recommend to use the same signature as that of setpos, i.e.

function setmark({markname}, {list})

the {list} parameter can be got using getpos.

Then you can simply call

call setmark('myplugin_markA', getpos('.'))

[LucHermitte]

(I've completely forgotten)

I don't find the current (viml) debugger ergonomic. It does the job, but it does not permit to see the code side by side with the current debugging state. Having an UI similar to TermDebug would be nice.

Note that I understand it would be really complex to debug vim scripts in a running session of vim.

[LucHermitte]

Still about debugging our vim scripts, it would be nice to have fail-fast assertions.

My issues with current assertions are:

• they don't abort the execution, they just cache the errors
• they don't give access to the callstack when they fail

I've implemented fail-fast assertions [1] that permits us to chose between:

• "ignore and continue",
• "open the debugger",
• "abort",
• and "display the callstack, and chose between any of the 3 previous options"

It works, but it's quite convoluted, and it would be nice if this could be a standard feature.

[1] https://github.com/LucHermitte/lh-vim-lib/blob/master/doc/DbC.md

[ZyX-I]

The debugger UI should not actually be run in the same Vim instance. That makes it hard to implement suggestions like @LucHermitte’s and additionally forces you to choose between seeing Vim screen state or seeing your debug session, additionally making it impossible to see old parts of debugging session after seeing screen state. Not to mention that forcing :redraw to see screen state may show you different results then what you would see without debugging active: e.g. after you did edits to the buffer in a debugged function redraw will not happen unless somehow forced or script finishes.

[brammool]

I am closing this now. Thanks everybody for your input!
See the VimConf slides and presentation for (a part of) the followup.