List of features to vote on

[Bram Moolenaar]

Now that Vim 9.0 has been released I thought it would be a good moment
to update the list of features:
https://www.vim.org/sponsor/vote_results.php

Although it would be nice to reduce the length of the list, I find it
difficult to decide what items to drop. Perhaps items that won't
happen, such as improving the Athena support?

What I was thinking of adding:
- Multiple cursors, edit in several locations at the same time
- built-in LSP support
- virtual text (e.g. to display type information)
- may hide part of the first line, scroll per screen line

Anything else? I prefer not to add too many items, only things worth
voting on, to avoid the list getting even longer.

Note that this is not an invitation for everybody to call out their
favorite feature!

- Bram

--
It was recently discovered that research causes cancer in rats.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Yegappan Lakshmanan]

Hi Bram,

On Sun, Jul 3, 2022 at 9:46 AM Bram Moolenaar <Br...@moolenaar.net> wrote:
>
> Now that Vim 9.0 has been released I thought it would be a good moment
> to update the list of features:
> https://www.vim.org/sponsor/vote_results.php
>
> Although it would be nice to reduce the length of the list, I find it
> difficult to decide what items to drop. Perhaps items that won't
> happen, such as improving the Athena support?
>
> What I was thinking of adding:
> - Multiple cursors, edit in several locations at the same time
> - built-in LSP support
> - virtual text (e.g. to display type information)
> - may hide part of the first line, scroll per screen line
>
> Anything else? I prefer not to add too many items, only things worth
> voting on, to avoid the list getting even longer.
>

What about including the support for the pending Vim9 script
features (class, enum, interface, custom types etc.)?

Regards,
Yegappan

[Bram Moolenaar]

Yegappan wrote:

> On Sun, Jul 3, 2022 at 9:46 AM Bram Moolenaar <Br...@moolenaar.net> wrote:
> >
> > Now that Vim 9.0 has been released I thought it would be a good moment
> > to update the list of features:
> > https://www.vim.org/sponsor/vote_results.php
> >
> > Although it would be nice to reduce the length of the list, I find it
> > difficult to decide what items to drop. Perhaps items that won't
> > happen, such as improving the Athena support?
> >
> > What I was thinking of adding:
> > - Multiple cursors, edit in several locations at the same time
> > - built-in LSP support
> > - virtual text (e.g. to display type information)
> > - may hide part of the first line, scroll per screen line
> >
> > Anything else? I prefer not to add too many items, only things worth
> > voting on, to avoid the list getting even longer.
>
> What about including the support for the pending Vim9 script
> features (class, enum, interface, custom types etc.)?

Well, that's going to happen anyway. Not sure when, but adding a voting
item isn't going to change it. I sort-of promised supporting classes
when deciding not to support a "dict function" in Vim9 script.

--
Don't read everything you believe.

[Maxim Kim]

> Anything else?

What about popup windows improvement -- it would be really nice to have editable(focused?) popup windows.

It would make all that plugins (fuzzy file finders and the rest) way better/simpler.

воскресенье, 3 июля 2022 г. в 19:46:47 UTC+3, Bram Moolenaar:

[Bhaskar Chowdhury]

Bram,

The four you listed are good enough to ponder on. And it might be worth inducting.

Thanks,

Bhaskar

[bfrg 100]

Bram,

when you say built-in LSP support, do you mean written in C, or as a
vim9script plugin?
And what do you mean with the last item "may hide part of the first
line, scroll per screen line"?

It looks like there are quite a few items in the voting list that can
be removed since they have been added by now, or that won't be
improved (Python, Ruby, TCL interface) since vim9script was added.
There are also a couple of duplicate items that can be merged into one
item (for example the ones on syntax highlighting or insert-mode
completion).

> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20220703164639.577621C091A%40moolenaar.net.

[Bram Moolenaar]

> when you say built-in LSP support, do you mean written in C, or as a
> vim9script plugin?

Written in C. There are plugins but I have heard users argue that it
would be better if it's built-in. Others say that the plugins are good
enough.

> And what do you mean with the last item "may hide part of the first
> line, scroll per screen line"?

Currently the first line is always displayed from the first column (when
'wrap' is on). This feature would allow for it to start after each
wrap, thus some screen lines are above the window and invisible.

> It looks like there are quite a few items in the voting list that can
> be removed since they have been added by now, or that won't be
> improved (Python, Ruby, TCL interface) since vim9script was added.
> There are also a couple of duplicate items that can be merged into one
> item (for example the ones on syntax highlighting or insert-mode
> completion).

Well, even though it's unlikely that some things will be worked on, it
is still useful to know what users vote for. I am surprised to see that
there are a lot of votes for Python integration. We can at least make
sure the existing interface keeps working.

Please be specific about what items you refer to.

It seems currently login to vim.org doesn't work...

--
hundred-and-one symptoms of being an internet addict:
68. Your cat always puts viruses on your dogs homepage

[Bram Moolenaar]

I wrote:

> It seems currently login to vim.org doesn't work...

That was just me using the wrong password.

--
hundred-and-one symptoms of being an internet addict:

72. Somebody at IRC just mentioned a way to obtain full motion video without
a PC using a wireless protocol called NTSC, you wonder how you never
heard about it

[Dominique Pellé]

Bram Moolenaar wrote:

> > when you say built-in LSP support, do you mean written in C, or as a
> > vim9script plugin?
>
> Written in C. There are plugins but I have heard users argue that it
> would be better if it's built-in. Others say that the plugins are good
> enough.

Builtin LSP could also be written in Vim9 script I think.
I can't think of anything time critical which would benefit being in C.
But I'm not sure TBH.

Other than that, I don't see support of Tree-Sitter, which could be
useful for things like:
- syntax highlighting
- folding
- text objects defined by syntax (to e.g. select or move by
function/class/string/statement...)
- and probably other things (e.g. being able to show syntax info)

Improving spelling would also be nice as Vim only supports
a subset of Hunspell and some recent Hunspell file can't be
used in Vim anymore (e.g. French dictionary). Not sure if this
would be done by improving what currently exists or whether
it would be supporting the hunspell lib for example. I recall
that Hunspell doc is unfortunately rather dry.

Syntax highlighting of Ex command line would be nice (but probably
complex for arguable benefit).

Regards
Dominique

[Bram Moolenaar]

Dominique wrote:

> Bram Moolenaar wrote:
>
> > > when you say built-in LSP support, do you mean written in C, or as a
> > > vim9script plugin?
> >
> > Written in C. There are plugins but I have heard users argue that it
> > would be better if it's built-in. Others say that the plugins are good
> > enough.
>
> Builtin LSP could also be written in Vim9 script I think.
> I can't think of anything time critical which would benefit being in C.
> But I'm not sure TBH.

OK, perhaps this item is a bit hard to understand and not worth voting on.

> Other than that, I don't see support of Tree-Sitter, which could be
> useful for things like:
> - syntax highlighting
> - folding
> - text objects defined by syntax (to e.g. select or move by
> function/class/string/statement...)
> - and probably other things (e.g. being able to show syntax info)

There was a discussion about what engine to use for parsing, and
tree-sitter was considered old and difficult to use. Let's leave out
the name and just say "fast syntax parser".

> Improving spelling would also be nice as Vim only supports
> a subset of Hunspell and some recent Hunspell file can't be
> used in Vim anymore (e.g. French dictionary). Not sure if this
> would be done by improving what currently exists or whether
> it would be supporting the hunspell lib for example. I recall
> that Hunspell doc is unfortunately rather dry.

That is the problem, Hunspell, as the name suggests, was mainly done by
a group for supporting Hungarian, and they were less interested in
"doing it right". This has made things complicated.

Anyway, I consider this maintenance. Voting on it won't really make a
difference, it takes someone for each language to dig into it and
suggest what spell items need to be added. I know that German
suggestions are very slow for longer words, because of how compounding
works. There are simply too many possibilities to score.

> Syntax highlighting of Ex command line would be nice (but probably
> complex for arguable benefit).

You can use the command-line window for that.

--
Q: How many legs does a giraffe have?
A: Eight: two in front, two behind, two on the left and two on the right

[Ernie Rael]

On 7/7/22 5:30 AM, Bram Moolenaar wrote:
> Dominique wrote:
>
>> Bram Moolenaar wrote:
>>

[...]

>
>> Other than that, I don't see support of Tree-Sitter, which could be
>> useful for things like:
>> - syntax highlighting
>> - folding
>> - text objects defined by syntax (to e.g. select or move by
>> function/class/string/statement...)
>> - and probably other things (e.g. being able to show syntax info)
> There was a discussion about what engine to use for parsing, and
> tree-sitter was considered old and difficult to use. Let's leave out
> the name and just say "fast syntax parser".
>

When I read one long vim thread about additional parser system. I came
away with the impression that it was TextMate that was old and
difficult, and TreeSitter that was more modern(of course, could be
wrong); in particular it is actually a language parser rather than regex
based. I bring this up not to start a flame war in this thread, but to
mention that accuracy is another dimension, not just speed.

It might be heresy, but it would be cool if a separate thread could
dynamically calculate syntax/folding/... info; it is at least
conceivable if the parsing system is independent from vim, doesn't use
vim functions.

-ernie

[Bram Moolenaar]

> >> Other than that, I don't see support of Tree-Sitter, which could be
> >> useful for things like:
> >> - syntax highlighting
> >> - folding
> >> - text objects defined by syntax (to e.g. select or move by
> >> function/class/string/statement...)
> >> - and probably other things (e.g. being able to show syntax info)
> > There was a discussion about what engine to use for parsing, and
> > tree-sitter was considered old and difficult to use. Let's leave out
> > the name and just say "fast syntax parser".
> >
> When I read one long vim thread about additional parser system. I came
> away with the impression that it was TextMate that was old and
> difficult, and TreeSitter that was more modern(of course, could be
> wrong); in particular it is actually a language parser rather than regex
> based. I bring this up not to start a flame war in this thread, but to
> mention that accuracy is another dimension, not just speed.

It's easy to mix up different parsers. TextMate is also considered a
problem in this discussion: https://github.com/microsoft/vscode/issues/50140

Perhaps there is a third alternative?

> It might be heresy, but it would be cool if a separate thread could
> dynamically calculate syntax/folding/... info; it is at least
> conceivable if the parsing system is independent from vim, doesn't use
> vim functions.

Yes, but multi-threading is very tricky to get right in C. And
debugging problems very time consuming. Using a separate process might
work better.

--
hundred-and-one symptoms of being an internet addict:

81. At social functions you introduce your husband as "my domain server."

[Ernie Rael]

Yeah, it might. I was thinking that the parser would only read
vim-buffers, and that vim would only read parser results, and vim would
message the parser about where the buffer is changed, fairly simple
interaction model. I've never used, or considered, C multi-threading, so
I don't know of any special issues; there is needing to use the
threading versions of the libs. Thinking of separate process, which
seems safer, it seemed like data sharing is more expensive or more of a
hassle, unless all of vim-buffers could be in shared memory segments.

-ernie

[Bram Moolenaar]

Well, that sounds simple, but it's actually the start of where things go
wrong. The current low-level buffer implementation keeps only one line
available. If another thread requests a different line it would cause
the current line to be released, while it might be in use. Thus this
can only be allowed when Vim is waiting for a character to be typed.
And then it may cause file I/O to the swap file.

We already have taken care of asynchronous I/O for channels, better use
that intead of adding another tricky mechanism. One could use channels
between threads, I suppose.

--
ASCII stupid question, get a stupid ANSI.

[Ernie Rael]

The first clue that that I didn't know enough about the problem space.

With care and foresight, an implementation using channels and a separate
process could be easily (another one of those danger words) migrated a
thread solution if the IPC overhead was too high.