[vim/vim] Support for plugin authors needs to be improved (poll) (#3573)

[Bram Moolenaar]

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)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub

[unclebill]

Really hop vim-script can be faster! 💯

[Nikolai Aleksandrovich Pavlov]

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 works well and always requires 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.

[Tom Link]

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).

[Tom Link]

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.

[Tom Link]

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.

[Marcin Szamotulski]

It would be nice to add multiline support for quickfix list. Some languages output multi line error messages (Haskell, PureScript, ...) with a lot of information that's not fitting into a single line.

Currently, one has to show each error line as a separate quick fix entry, but this breaks the correspondence between number of entries in quickfix  list and number of errors/warnings, or the jump to error from quickfix list.

It would also be nice to have syntax highlighting for quick fix buffers.

[Qiming zhao]

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 Lakshmanan]

Hi,

On Sun, Oct 28, 2018 at 7:33 AM 'Marcin Szamotulski' via vim_dev
<vim...@googlegroups.com> wrote:
>
> It would be nice to add multi line support for quickfix list. Some languages

> output multi line error messages (Haskell, PureScript, ...) with a lot of
> information that's not fitting into a single line.
>

Vim already supports processing multi line error messages and converting
them into quickfix entries. Please refer to ":help errorformat-multi-line".
Does this work for you or does this need any enhancements?

>
> Currently, one has to show each error line as a separate quick fix entry, but
> this breaks the correspondence between number of entries in quickfix list
> and number of errors/warnings, or the jump to error from quickfix list.
>
> It would also be nice to have syntax highlighting for quick fix buffers.
>

The file syntax/qf.vim already defines some syntax highlighting for the
quickfix entries.

- Yegappan

[Yegappan Lakshmanan]

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

[Prabir Shrestha]

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.

[Prabir Shrestha]

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

[Prabir Shrestha]

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.

[Boris Staletic]

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.

[Prabir Shrestha]

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:

[Prabir Shrestha]

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.

[Prabir Shrestha]

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

[Tony Mechelynck]

@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 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.)

[Ben Jackson]

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)

[Prabir Shrestha]

@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.

[Tony Mechelynck]

@prabirshrestha : Ah I see.

We can discuss it further immediately in a separate thread on the vim_dev list (mirrored by the vim_dev Google Group).

Best regards,
Tony.

[Qiming zhao]

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.

[Qiming zhao]

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 (eg: change of menu filed) from server.

[Qiming zhao]

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.

[Luc Hermitte]

@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

[Luc Hermitte]

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.

[Luc Hermitte]

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.

[Luc Hermitte]

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

[Luc Hermitte]

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. (Current patch is for Vim 8.1.0488)
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

[Christian Brabandt]

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

• sign definitions
• :hi commands

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.

[David Demelier]

I like the way visualstudio adds different color regarding the variable scope. For example, functions arguments, class members and globals variables all have different colors. This is very handy sometimes.

I also miss a recent debugger/terminal integration but maybe something exists these days.

[Cookie Engineer]

@ZyX-I I am with you on this one. The really only thing that annoys me on VIM is syntax highlighting. Not in the sense of customization but in the sense of performance and asynchronous usage. Sometimes large built (or transpiled) files - that contain e.g. RegExp literals in there, too - will break the syntax highlighting completely and VIM is stuck for like 30 seconds until anything reacts.

Syntax highlighting should be done incrementally, only for the current buffer view if necessary with regards to the performance. TBH I don't care whether or not the first two statements of the buffer are not highlighted, but I do care about whether or not the whole VIM instance is unusable while navigating around until syntax highlighting is automatically disabled and sometimes has to be force-killed to get back to work.

[Tom Link]

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.

[Tom Link]

I'd also like to propose the following change to vimlang:

A variable foo (when defined in should refer to the first one of l:foo, a:foo, g:foo. Or simply support proper lexical scoping.

[thinca]

Multiple sign columns.

There are many plugins that use sign column for various reasons, but they can not be used at the same time.
Plugin users must choose one of them and give up the other plugins.

(It is related to the latest comment, but it is a coincidence. 😃)

[Christian Brabandt]

@tomtom
That's one of the things I meant with a proper VimScript API.

[bbtdev]

native LSP support

[Romain Lafourcade]

A proper plugin API that:

• allows registering and unregistering features,
• handles overlap gracefully,
• somehow enforces best practices.

[Romain Lafourcade]

Asynchronous variants of every function or command. Or an optional way to make them asynchronous.

[Romain Lafourcade]

A cleaner decoupling between netrw and built-in features. See gf.

[Romain Lafourcade]

Extend the notion of fooprg to more features: completeprg, syntaxprg, searchprg, etc.

[Romain Lafourcade]

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

[mattn]

IMO, I don't prefer native LSP since LSP spec will go up versions faster than implementing on Vim core. I think Vim should provide features that plugin authors can implement LSP.

[KillTheMule]

A folding API that makes it possible for async jobs to reliably create folds. Right now one just has to hope no one changed the buffer in a window or the current window while the job did its computation.

[Thomas Berry]

More syntax based fold methods for languages other than C.

[EoE]

a very modern GUI interface for user optimize.

[Christian Brabandt]

as a user, I'd like to have a strong encryption available (e.g. fix for issues #638 and #639)

[Christian Brabandt]

Not to forget the vote results from www.vim.org:

https://www.vim.org/sponsor/vote_results.php

[Łukasz Jan Niemier]

@chrisbra I think that encryption should be removed or made read-only as it is always better to use external tools for that. There is no single case where built in encryption would be better than external tool.

For me multiline completion is something that I am waiting for, as this will allow better integration with LSP and skippering systems without hacks. With that it would be nice to have marks/variables in CompleteDone that would contain first and last character inserted via completion. This would make a lot of things much easier for me.

[machakann]

I would like to have a kind of API to handle dot command (:help single-repeat).

Currently, there is no way to know what happens if . key is pressed before doing it; even after doing it, what I can get is only the result. Sometimes, it is not obvious what kind of function was triggered. I think this situation makes difficult to debug an user-defined operator plugin.

Additionally, it would be nice if we can set/restore a dot command function without using g@.

[Łukasz Jan Niemier]

Add 'findprg' that works the same way as 'keywordprg' so we could improve built in :find command performance as built in can be really slow in deep trees.

[Naruhiko Nishino]

Vim-TabSideBar(To show tab pages vertically on Vim)

http://rbtnn.github.io/vim/

[Mladen Mijatov]

Primarily I'd love to see GTK3 version get proper Wayland support and native clipboard support through it. This would get rid of X.org dependency and would improve rendering speed.

Along the way nasty issue with white color around the window would disappear.

[Mladen Mijatov]

I would love to see support for digraphs in GVim. Some fonts which are targeting us developers, such as Iosevka, have started using these extensively to help improve readability of the code.

[machakann]

I want a general function to get a string of a specific region on the buffer, such as "a character under the cursor" and "a text currently visually selected". Even now, we can do but it sometimes becomes a painful task, especially playing with multibyte texts and block-wise visual.

There could be better idea, but what is now in my mind is:

" a character under the cursor
let cursorpos = getpos('.')
let type = 'char'  " type of the region, 'char', 'line', 'block'
                   " or a return value of visualmode()
let c = gettext(cursorpos, cursorpos, type)

" a string currently selected
let str = gettext("'<", "'>", visualmode())

[Tony Mechelynck]

@MeanEYE

Primarily I'd love to see GTK3 version get proper Wayland support and native clipboard support through it. This would get rid of X.org dependency and would improve rendering speed.

I think that means having GTK developers develop a version that can use the Wayland protocol — I don't think Vim can do anything about that.

[Mladen Mijatov]

@MeanEYE

Primarily I'd love to see GTK3 version get proper Wayland support and native clipboard support through it. This would get rid of X.org dependency and would improve rendering speed.

I think that means having GTK developers develop a version that can use the Wayland protocol — I don't think Vim can do anything about that.

It's already there and has been for years now. All GTK3 applications by default use Wayland rendering backend if it's available. GVim doesn't for some reason and goes through XWayland.

[Joe Reynolds]

A native alternative to plugins like vim-sandwich and vim-surround

[Christian Brabandt]

I would love to see support for digraphs in GVim.

@MeanEYE
digraph support is available in Vim. I guess you are talking about ligature support?

[Mladen Mijatov]

I would love to see support for digraphs in GVim.

@MeanEYE
digraph support is available in Vim. I guess you are talking about ligature support?

Right you are. I made a mistake. Thanks, I'll fix the original post.

[Christian Brabandt]

related issue and patch #418

[callum]

When you install vim it comes with a fairly plain vimrc. For new users, constantly looking up the help menu or online for help settings could be a big barrier to using vim.

My proposal is simple: when a new user downloads vim, provide an additional 3 or so different dummy vimrc's in the package to show a new user how different vanilla settings can interact together. They can then build out of their favourite given one.

[Luc Hermitte]

@callumfrance The topic is about how the life of plugin authors could be improved. You suggestion, while interesting, addresses another public.

[Luc Hermitte]

While trying to improve folding support in C in C++, I remember having ran into something that looks like abundant recursions. In the end, I wasn't able to provide a performant folding implementation and I had to rely on internal caches, which are often out-of-sync.

It'd be interesting to check what can be done to improve the performances of folding.

[mattn]

I want flexible <cWORD>. For example:

• <cWORD?https\?//\S\+> for matching URL.
• <cWORD?[0-9]\+> for number.

[Łukasz Jan Niemier]

@mattn the last one you can easily do with temporalily switching 'iskeyword'.

[mattn]

@hauleth It's not enoguh to match/extract URL on cursor locaation.

[Nguyễn Gia Phong]

Since noone seems to mention it, please somehow add a proper terminal that at least can curse. I feel like a disabled everytime I use python shell in vim.

[machakann]

A constant representing the maximum length of a line, let's say v:maxcol. (Though, simply v:maxcol == 2147483647 in almost all supported environments.)

[presuku]

I want to a function which return list of built-in ins-completion matches (e.g. i_CTRL-N, i_CTRL-X_CTRL-L). It is like getcompletion() in command-line.
And I also want to a function to raise popup-menu with list.

[machakann]

@presuku The latter one is probably the complete()?

[Łukasz Jan Niemier]

@mattn according to docs, non-ASCII are always included. And for the URL it is better to use <cfile> IMHO, as this will work much better (this is also what netrw uses for gx).

[mattn]

@hauleth This is not a thing for limited on URL. For example, Go's identify can be contained utf-8 letters. But Vim can't handle below's 漢字 as identify since isident/iskeyword can not contain them.

var 漢字 string

And we want easy to extract any works matched as pattern.

[Łukasz Jan Niemier]

Multi-byte characters 256 and above are always included, only the
characters up to 255 are specified with this option.
For UTF-8 the characters 0xa0 to 0xff are included as well.

Excerpt form docs. So it is included by default. I also have tested with :echo expand( and all returned expected string 漢字. When I mixed CJK with latin then <cword> returned wrong result but both <cWORD> and <cfile> worked as expected.

[presuku]

@presuku The latter one is probably the complete()?

@machakann Oh, I forget about it. you are right.

[Emily St.]

I recently wrote a plugin which enables itself in Visual mode and disables itself in all other modes. In the absence of an autocmd event which triggers on mode changes, I have to set up a timer to fire regularly to detect these. I think it would be nice to add an autocmd event along the lines of ModeChanged or even one for each mode, such as VisualEntered/VisualLeft, NormalEntered/NormalLeft, and so on.

My entire plugin would probably be redundant if listchars could be made configurable only to appear within visual selections, though.

[mattn]

@hauleth unfortunately, expand('<cWORD>') contains & too. And expand('<cword>') doesn't include non-ASCII. So it can't extract thisIs漢字 from foo(&thisIs漢字).

[mattn]

FYI, I am not sticking to add regular expressions into `expand ('<cWORD?PATTERN>'). Because I can imagine that it will be very slow.

[Qiming zhao]

Add a documentation window that could be shown with popup menu side by side, like VSCode:

The preview window would cause vim's layout change so I don't like it.

[Romain Lafourcade]

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.

That's already handled by the menu and info keys.

[Łukasz Jan Niemier]

@chemzqm in general: floating windows. This would provide framework for doing that and much more.

[chdiza]

Allow the function specified with &opfunc to get passed more than one argument in a mapping.

E.g., I want to be able to do something like this:

fu MyFunc(one, two, three)
  some stuff
endf

nmap some_lhs  :<C-U>se opfunc=<SID>MyFunc(b:for_two, b:for_three)<CR>g@ 

Currently AFAIK I have to do this:

fu MyFunc(one)
  let two=b:for_two
  let three=b:for_three  
  some stuff
endf

nmap some_lhs  :<C-U>se opfunc=<SID>MyFunc<CR>let b:two=b:for_tow<CR>let b:three=b:for_three<CR>g@ 

[traycerb]

There a few features which remain outside the scope of plugin authors, though some have tried approximations First, a few features relate to long lines (as may be found in prose):

1. Visual line selection doesn't work on soft-wrapped lines
2. Scrolling in texts with long soft-wrapped lines doesn't behave as it would if those lines were hard broken
3. The Cursorcolumn option if used as a visual marker to locate your cursor does not work on a soft-wrapped line.

Some of these have been tried in plugins but it ends up being imperfect and hacky.

[traycerb]

Tabbar on the side would be nice, and has been attempted, both as plugin and in source.

[traycerb]

I don't have a need for it, but Bidirectional text is also outside the scope of plugins. Subject has been broached on Neovim and OSS implementations exist.

[Takuya Fujiwara]

Tabbar on the side

@traycerb comment is collapsed but already exists #3573 (comment)

[Edward Murphy]

Multiline (block) comments in .vimrc config file

This would make my in-line documentation for my various configurations cleaner

[Michael Doyle]

Real-time keyboard input display.

[James Upjohn]

Quitting.

[Łukasz Jan Niemier]

@whatupmiked you mean like 'showcmd'?

[Tony Mechelynck]

@traycerb

2. Scrolling in texts with long soft-wrapped lines doesn't behave as it would if those lines were hard broken

In 'wrap' mode, the first visible character in the current window is always the first character of a (physical) line, except when the current line alone is longer than the current window. IMHO this is a valid "feature" of Vim.

Bidirectional text is also outside the scope of plugins.

Full-bidi is outside the scope of Vim itself, not only of plugins. The only way to display full-bidi text as full-bidi in Vim is by running it in a full-bidi terminal such as mlterm, and when Vim notices that it is running in mlterm it will set 'termbidi' at startup and let the terminal handle any bidirectionality in the displayed text. However not every Linux distro distributes mlterm nowadays (mine doesn't) and you have to get it (in source form IIRC) from SourceForge at http://mlterm.sourceforge.net/ and then compile it yourself.

[David Briscoe]

Add a :push analog to :pop.

Allowing plugin writers (i.e., jedi, omnisharp) to :push symbol-name before jumping to 'symbol-name' would let them integrate with the tagstack. This approach wouldn't solve the "support CTRL-W ] and similar" problem or allow custom sources for :tselect.

Or a function for pushing and popping from the tagstack.

#3336

[Jerome Dalbert]

Separate threads for vimscript, so that the main process is not blocked when plugins are loading or working.

[David Briscoe]

Separate shell quoting from shellslash so plugins don't break (or have to do a workaround) on Windows with cmd.exe and sensible slashes.

In todo.txt:

shellescape() depends on 'shellslash' for quoting. That doesn't work when
'shellslash' is set but using cmd.exe. (Ben Fritz)

Ref: shell quote shouldn't depend on shellslash on vim-dev

[mattn]

system() but no use shell. I know job_start can start job without shell, but job/channel doesn't have a way to wait the job. So I want spawn() or exec().

[David Briscoe]

Fix ":pedit %" so plugins can display current file in preview window (and not resort to hacks like this).

In todo.txt:

":pedit %" with a BufReadPre autocommand causes the cursor to move to the
first line. (Ingo Karkat, 2008 Jul 1) Ian Kelling is working on this.
Similar problem with ":e". (Marc Montu, 2014 Apr 22)

[Simon Weil]

Native support for multiple cursors