Re: [vim/vim] Vim's future (Discussion #12736)
Peacock
We have to wait for @chrisbra to return from vacation....
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Cthulhux
I’ll continue to make Windows builds, it’s the least I can do.
—
Reply to this email directly, view it on GitHub,.
You are receiving this because you are subscribed to this thread.
Linwei
I am astonished that Bram was still updating vim three weeks ago while suffering bad health situation. He sees Vim as his own child, and he surely hopes that Vim will continue to thrive after his death.
Does he have any last wishes or plans regarding how Vim should continue to develop? Did he leave some words to the community?
This should be the an important thing to figure out, does anyone have connection with Bram's family?
Of course, they are busy preparing for the funeral. It would be appreciated if they could provide some information about this.
In addition, I am glad to see there are so many people ready to offer help but don't know how. The community needs leadership right now, fortunately there are still some people still have access to this repository, I hope they can take on this great responsibility.
One last thing, I wish to donate for whoever can maintain Vim on a monthly basis, but I don't know how to do it.
I believe many people in this community would like to make a donation because we want Vim keep thrive just like Bram did.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
Bram maintained the list of planned Vim enhancements, fixes and future plans in the todo.txt file.
Bram gave importance to fixing crashes, security issues, filetype updates and fixes for existing features over adding new features. I think the first priority should be to incorporate the currently outstanding PRs and fix issues reported against existing features.
He planned for a lot more enhancements to the Vim9 script (e.g. support for types, enums, etc.). It is unfortunate that this is going to take quite a bit of effort for others to implement.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Peter Kolosov
R.I.P. Bram Moolenaar! ❤️
—
Reply to this email directly, view it on GitHub,.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Hi,
I haven't still thought it through, as I am still shocked by the bad news (and I am also a bit afraid of the repsonsibility to maintain Vim and given the high quality Bram has provided over the years)
I am currently thinking to work through the existing PRs and mainly merge any un-contraditionary changes (mostly bug-fixes) and for now I'd like to continue using Brams working method, e.g. each change a new patch number (possibly with the exception of adding minor patches for runtime file updates as well to be able to find changes better).
But this quite likely won't scale well, because we need to increment the minor version with each patch, so we cannot just click the merge button. Once this is done, I'd like to release a vim9.1 or vim 10 quite soon, after which I'd like to move on to a bit more modern working with git and github (not sure about the minor versioning numbers).
Also, given the commitment of Bram, I am afraid we won't be able to keep up with the speed that Bram has provided. I'll probably add a few more people to the Vim Organization who are known for there contribution to Vim as well. But even then I don't think we can spend 7 days/week on working with Vim. So it will most-likely be a more traditional way to add changes. Don't expect big changes for now (like TreeSitter Integration, finishing up the Vim9 Class Definition, etc), it will most likely be Bug-Fixes, and Security Fixes (huntr bugs, etc).
Also there are quite a few areas, which would need some work, and I am not sure we have the knowledge to do so :(
- better/fixed Key-handling in Windows
- renovating the Gui with support for Wayland and/or GTK4
- better integration with the console vim on Windows using the new Windows Terminal
- fixing the terminal options handling (which is quiet complicated)
- infrastructure work (the Vim homepage still has a lot of problems with the Database). Not to mention, the design could be improved a bit. and I am not sure we should stay with osdn.net given the recent problems...
And finally, I don't know yet how to handle ICCF donations, this needs to be worked out with Brams family (if Bram has mentioned how he would like to have this worked out).
So plenty of things to do. These are my rough ideas. Feel free to comment.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christ van Willegen
Hi,
I haven't still thought it through, as I am still shocked by the bad news
I am currently thinking to work through the existing PRs and mainly merge any un-contraditionary changes (mostly bug-fixes)
vim-dev ML
Op zo 6 aug. 2023 18:17 schreef Christian Brabandt <
> Hi,
> I haven't still thought it through, as I am still shocked by the bad news
>
You're not alone there...
I am currently thinking to work through the existing PRs and mainly merge
> any un-contraditionary changes (mostly bug-fixes)
>
I could also read through them to see what they are all about, since you're
still on your holiday. Shall I add a LGTM comment for the PRs I've seen?
Christ van Willegen
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Linwei
As @yegappan and @chrisbra mentioned above:
first priority should be to incorporate the currently outstanding PRs and fix issues reported
I am currently thinking to work through the existing PRs and mainly merge any un-contraditionary changes
I like the conservative and consistent development approach of Vim, which is also prudent when it comes to new features.
This makes Vim more robust, and I will not be afraid of frequently breaking my vimrc.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
fcpg
I tend to believe most old-timers, users and/or contributors, are on the same page, valuing stability, bugfixes in a reasonable time frame, all with a long term view.
Like @skywind3000, I would be willing to donate on a regular basis if this could help the dev efforts, one way or another. Feel free to organize something for donations when the time is right.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Jesse Pavel
He planned for a lot more enhancements to the Vim9 script (e.g. support for types, enums, etc.). It is unfortunate that this is going to take quite a bit of effort for others to implement.
I do agree -- I'm not sure if anyone will grasp Bram's vision and implementation of vim9script in the way he did, and it is a huge undertaking to get up to speed with that aspect of Vim 9.
One of the main "Why Vim 9?" points was to "deprioritize [language] interfaces", but given that, for the time being, the development of vim9script faces significant hurdles, perhaps we should encourage the improvement of the language interfaces once again.
Browsing the histories of if_py and if_lua source files, I see that most improvements already have come from third-party contributors; and for someone generally unfamiliar with the Vim codebase, those interface sources provide a stable gateway of sorts for Vim's internals.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Shougo
I think github sponsor can be used for the donation.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
mattn
Agreed. And we will then have to discuss whether we should add features according to the sponsors' voting priorities.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
savchenko
renovating the Gui with support for Wayland and/or GTK4
How about "outsourcing" this to one of the many GUI clients? Similar to what nVim does.
infrastructure work (the Vim homepage still has a lot of problems with the Database). Not to mention, the design could be improved a bit. and I am not sure we should stay with osdn.net given the recent problems...
This can be handled by the community. I'd be keen to help for example, maybe let's start a separate discussion?
And finally, I don't know yet how to handle ICCF donations, this needs to be worked out with Brams family (if Bram has mentioned how he would like to have this worked out).
Might be the hardest part... Won't comment here, sounds like something that will be driven by people close to him / those with the knowledge about the fund and its activities.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
依云
Similar to what nVim does.
nVim does it very badly: limited GUI capabilities, broken support for clipboards, lack of input method support, etc. There are quite a few nVim GUIs, but none of them is free from these issues. And why do we split force into multiple competing projects?
It's a good idea to split GUI to a dedicate process, but please don't follow nVim's practice.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
nyngwang
"[...] 'benevolent dictator' model " is unnecessary, unless you aren't one of the maintainers.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Linwei
Speaking of voting, there may be something we need to figure out:
- What will be voted by sponsors ?
- What will be voted by the core dev-team (maintainers) ?
- What will be voted by others in the community ?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Linwei
Speaking of voting, there may be something we need to figure out:
- What will be voted by sponsors ?
- What will be voted by the core team (maintainers) ?
- What will be voted by others in the community ?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Linwei
Consider to apply for joining some existing foundation, like Apache Foundation or something, at the right time ?
If they can help raise money.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
h_east
Below are the major ones included of my patch in this year.
patch 9.0.1569: cannot use "this.member" in lambda in class method
patch 9.0.1466: cannot use an object member name as a method argument
patch 9.0.1463: virtual text truncation only works with Unicode 'encoding'
patch 9.0.1373: wrong text displayed when using both 'linebreak' and 'list'
patch 9.0.1164: evaluating string expression advances function line
I did bugfixes such as Vim9 script and text property.
Of course, I don't have a complete grasp of Vim, and I can't support on full-time.
But I think I can help the community a little.🤝
—
Reply to this email directly, view it on GitHub,.
You are receiving this because you commented.
K.Takata
for now I'd like to continue using Brams working method, e.g. each change a new patch number
I'm thinking whether we can use the Squash and merge option of the merge button. (Somehow the patch number must be added to each PR, though.)
For #12740, I think we can safely use the merge button with the Squash and merge option (or with the Rebase and merge option).
@chrisbra Do you have the write access of the FTP server?
Are you going to upload each patch file to FTP? (I'm not sure if it is still needed.)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Rykk
R.I.P Bram, Long live the vim.
I have tested to switch to nvim for awhile a week ago, and failed and back to vim now.
I think nvim is good for newbie, but not suitable for me with my long time maintained vimrc.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christian Brabandt
unfortunately not yet. I don't know, if anybody uses the FTP server for patches, but I'd still like to get access, so that we can keep at least the runtime files up to date (not sure if it is needed). Checking if this is possible.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Devin Weaver
This is me as well. I really really like my current Vim setup I've tweaked and honed over 20+ years. LUA be damned!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Devin Weaver
Is it possible to start a go Fund Me for friends and family. Possibly for continued maintenance of the Vim Ecosystem?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Computer2340
At least for me, this was a thought I had too, not because I selfishly want new Vim features to keep coming down the pipe, but because I want @brammool's baby to keep receiving love and attention. I'm sure there are people who are only concerned about the product but not the person, but unless stated otherwise, I'm going to assume people thinking about the governance of Vim going forward are interested in continuing Bram's legacy.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Yee Cheng Chin
But this quite likely won't scale well, because we need to increment the minor version with each patch, so we cannot just click the merge button. Once this is done, I'd like to release a vim9.1 or vim 10 quite soon, after which I'd like to move on to a bit more modern working with git and github (not sure about the minor versioning numbers).
If we get rid of minor versioning numbers that increments after every commit, I think it should come with a comprehensive change to the release model. There are downstream effects with how different channels that Vim is released to the public (e.g. the Windows gVim binary builds, or MacVim). For MacVim for example, I just manually merge from upstream Vim routinely and use the current Vim's major/minor version number to identify the Vim version. If there's no more minor version number it would be hard for me to distinguish one version from another when I merge from upstream, unless there are frequent explicit minor releases (instead of say an official release every 1-2 years which is too slow). FWIW, the current model is somewhat tricky for MacVim anyway, as I usually have to wait a couple days to make sure there are no breaking changes in Vim before I make a MacVim release, as Vim does not have a proper idea of "release builds" that's well-tested so one version could be perfect while the next one could have some breaking bug. Neovim for example has explicit release cycles and they do code freeze before official releases. Not saying we have to do that but just something to think about.
How about "outsourcing" this to one of the many GUI clients? Similar to what nVim does.
nVim does it very badly: limited GUI capabilities, broken support for clipboards, lack of input method support, etc. There are quite a few nVim GUIs, but none of them is free from these issues. And why do we split force into multiple competing projects (only to create software broken in different ways)?
It's a good idea to split GUI to a dedicate process, but please don't follow nVim's practice.
I have quite a number of loose thoughts (that I need to organize better) on Vim GUIs, and would like to be involved if there are larger refactoring on the GUI interface of Vim, but because I would like to contribute and I have a vested interest in it. (I'm the maintainer of MacVim, the unofficial GUI implementation of Vim on macOS)
I do agree that the way Neovim handles GUI is not perfect, but there are some lessons we can learn from it, e.g. using a separate process, and providing more flexibility / structured information to the UI instead of just treating it like a smart terminal. There are quite a few features that I'm struggling to implement because of the current limitations on the GUI interface (e.g. pixel-smooth scrolling, overlay scroll bars, accessibility features).
Agreed. And we will then have to discuss whether we should add features according to the sponsors' voting priorities.
Personally I think this can easily goes down a tricky path because sponsors are usually going to be a vocal minority, and are usually not Vim developers. I'm not sure how we can balance that with a more coherent vision that the dev team may have. Maybe for prioritization, sponsor voting could work, but I don't think "whether a feature should be added or not" should be up to sponsors to decide. The actual pros and (especially) cons of a feature are usually nuanced. For example, a lot of recent Vim breakages come from adding features that seem innocuous at first glance but add tons of hidden complexities due to interactions with other features. Are sponsors going to fully understand every single feature interactions and how it would be affected by a "simple" feature? While Bram's methods was somewhat old school, one thing he was good at was saying no (including to my PRs) when he felt that the change would be a net negative.
Other than this, I'm also shocked at the recent news… I'm willing to help out more depending on what help is needed.
—
Reply to this email directly, view it on GitHub,.
You are receiving this because you commented.
smekkley
I suggest closing this discussion already.
The scope is too big and already some very details that haven't been really big issues for users are discussed, such as git tagging and even voting which are more of burdens of devs who are already busy with existing issues, PRs and Bram's todolist that yegappan has mentioned.
People who want to discuss some topic such as how to decide about new features and donations that the existing maintainers aren't really asking for so far, should create a new more specific discussion or issue.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
tga
On a side note: I hope we can freeze this repo in honor to Bram's memory and resume development on a fork. Vim without Bram and his development style will be a different software, re-organizing will be a change not unlike neovim.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Brickviking
Personally, having been a long time vim user (since the early 2000s if not the late nineties) I'd rather see this repository continue on. I'm pretty sure Bram would have wanted that to be the case, however I'd like to see some sort of dedication within the opening screen of vim for this upcoming release at least. Disadvantages with forking is that people are going to have to go to another site than this one just to catch up with ongoing development.
That's just my personal opinion.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
tga
Practically yes it might cause some confusion, but Vim has been a primary example of the "benevolent dictatorship" model, I always consider Vim Bram's thing, it's weird to me to just take over and do our own thing to it and assume it's what Bram wants. Personally opinion and I know it's never going to fly, just want to say it out 🙏
—
Reply to this email directly, view it on GitHub,.
You are receiving this because you commented.
Nick Jensen
It has of course always been Bram's project but he has welcomed the contributions of hundreds of other people. If he didn't want others to continue the project after his death, he wouldn't have given maintainers like Christian Brabant the repo access.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Linwei
There can be a compromised solution:
1) freeze 9.0 to commemorate Bram
2) move future patches in 9.1+.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
ObserverOfTime
There can be a compromised solution:
- freeze 9.0 to commemorate Bram
- move future patches in 9.1+.
I like this idea but I'd propose adding one more commit similar to neovim/neovim#24589 before freezing it.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
chdiza
I would hope that Vim continues to have a new micro version number with each patch. I see nothing wrong with this, except that I would also attach micro versions to those occasional runtime file updates. Those micro versions are much easier to deal with than commit hashes are.
I would hope that each such patch continues to be self-contained (the full fix for the "Problem:" mentioned in the commit message), rather than as an unsquashed series of commits.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Linwei
Is it possible to write a CI script for this ? once a PR is merged it will create a standalone commit and mention the previous PR's URL in its message and increase the version number by 1 ?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Devin Weaver
Yes, I think a dedication to Bram in the docs it the right thing to do!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Olivia (Zoe)
They do: https://groups.google.com/g/vim_dev/c/dq9Wu5jqVTw
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
milanglacier
We can also create a dedicated branch and keep the branch forever
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
zaitmambet
I hope Vim will continue to develop, otherwise people will just switch to NeoVim
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Yee Cheng Chin
Is it possible to write a CI script for this ? once a PR is merged it will create a standalone commit and mention the previous PR's URL in its message and increase the version number by 1 ?
I feel like this just doubles the number of commits, making the history very noisy.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
lokithus
Why not merge? It's the right time and it will help both communities. Even in death, Bram helped both projects indirectly.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Shougo
It cannot be merged.
Because neovim has different culture. Vim keeps backward compatibility.
But neovim can break the compatibility if it is needed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Linwei
Vim did break things if needed as well:
- XP support has been dropped, since 9.0.xxx
- C89 compliance since 8.x.x ?
- DOS support since 7.4.xxxx
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
BenYip
Keeping backward compatibility is great. I don't think these two editor can be merged, but Vim should break backward compatibility when it is certainly necessary.
How Emacs handles backward compatibility is reasonable to me. Emacs sends deprecation warning several major versions before a feature is actually removed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
依云
Vim did break things as well
But Vim never breaks things for me :-)
I tried Neovim before. It broke clipboard usage for me among other minor default option changes (that weren't documented). And from time to time I heard about Neovim users rewriting their configuration / plugins in some more excited way (e.g. Lua).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Shougo
Vim may drop some old features.
But neovim's drop is not same. It is more drastically changes.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Shane-XB-Qian
someone did not know the different between sunset with compatibility ?
official vim is pursuing compatibility did not mean keep every old things not sunset !
recently it do changed some workflow style also, seems a bit hurry,
if PR or Change did not review and think a bit strictly or completely, the code quality maybe a bit worried.
that's a bit different like Bram did.
Anyway, we (Vimer) should keep and help Bram's legacy, and help official vim keeping its product quality.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
savchenko
Well... "Destruction breeds creation". In my very humble opinion merge of Vim and NeoVim would be the best outcome for both.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Yee Cheng Chin
While Vim does break some backwards compatibility it's usually done for really old platforms where continuing supporting them is a non-trivial burden. The issue at discussion here is really the culture and goals behind both projects. Neovim is a lot more aggressive on only supporting the "new" stuff.
For example, for macOS, Neovim only supports 10.15+ (source). For Vim I actually don't know the minimum version but MacVim (which operates as a fork of Vim) at least supports down to 10.9, and every time I contemplate bumping MacVim's minimum requirements up there are people coming out of the woodworks saying that they rely on such old macOS versions. Are people here suggesting that these users using old OSes should just… not use updated versions of Vim anymore? Or Neovim should retroactively go back and add support for these old platforms?
Other examples include the :hardcopy command (used for printing files, for those who don't know). Neovim removed it (neovim/neovim#21472) not because it's a serious burden but mostly because it doesn't support the latest features like treesitter. I think the technical details are not as important as the overall decision making process because removing a longstanding feature that people do use (even if not a huge portion of the users) just for certain ideas about what the feature should include feels like a decision that Vim would not make to me.
The APIs have also diverged quite a bit on certain features, like with how the terminals work, jobs, virtual texts etc. When people are suggesting merging, it kind of feels like they are saying that the Vim developers should just move on to Neovim, but that seems irresponsible for the existing users who rely on these features.
—
Reply to this email directly, view it on GitHub,.
You are receiving this because you commented.
savchenko
@ychin , appreciate the points you have raised. Insightful!
When people are suggesting merging, it kind of feels like they are saying that the Vim developers should just move on to Neovim, but that seems irresponsible to the existing users who rely on these features.
This is not something I was suggesting. Would rather see developers of both projects agreeing on a middle ground solution.
For example, :hardcopy is ~3500 lines of C code and still, there are many edge cases it does not handle. On the other hand, nVim supports live preview of substitution regexp via inccommand, functionality that makes sense to keep in base and enabled by default.
This works in both ways.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Shougo
Vim developers and users are very conservative and concerned about backward compatibility.
Conversely, people who chose convenience over compatibility migrated to neovim.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
fcpg
Requests for merging remind me of the famous "can't we all just get along".
Both projects choices and culture are significantly different, it does not make sense to merge them. They are not fiercely competing either, it is understood that if you want more cutting-edge features, you should go with NeoVim, and if you favor stability, pick Vim. This does not mean some features will never be part of Vim, but rather that the actual implementation and technical choices may differ, because things are done differently.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Yee Cheng Chin
I do think that while I think both projects will exist in the forseeable future, it's useful to make sure we keep each other in mind when working on new features and designing new APIs. FWIW some of that happens today, but there isn't always a straightforward way to port Neovim changes to Vim and they are mostly done in an ad-hoc fashion. Neovim does have a wiki entry / system for porting Vim patches over though and they do that frequently.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christian Clason
Would rather see developers of both projects agreeing on a middle ground solution.
But we are: we cooperate on features and runtime files where it makes sense (even though it might not look like it from the outside; there's even personal overlap between the core developers now); we also have long-agreed "middle ground" with vim(8)script, which both projects will continue supporting for a long time.
Anything else just doesn't make sense; "one size fits all" fits none. Most people who work on Neovim do so because they enjoy working on Neovim and would never, ever contribute to Vim (again) -- and vice versa. So the assumption that "merging projects doubles the development speed" is patently false -- in fact, the opposite is true, as together we attract a wider spectrum of contributors (and contributions to one do often if not always end up in the other, at least in some form).
And let's face it, "you should join forces" is usually little more than a thinly veiled "how dare people work on stuff I don't use; they should work on what I use instead!" It has little to do with any concern about the "health of the project" (whatever that means).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Shane-XB-Qian
// this is to answer official vim vs neovim #12736 (comment) thread above
as my experience with Bram in repo and mail, he is very taking care compatibility much than feature,
and follow the existed instr in doc much than some kinds of so called "no harm" changes,
and always official vim first, or work through another way to make it e.g vim9
we should help and keep that, i wish.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
savchenko
@clason ,
Appreciate your position, clearly articulated. However, this:
And let's face it, "you should join forces" is usually little more than a thinly veiled "how dare people work on stuff I don't use; they should work on what I use instead!" It has little to do with any concern about the "health of the project" (whatever that means).
Is blatantly false. There is much more nuance to it.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Linwei
well, several month ago, neovim removed cscope interfaces because, so called, cscope is not maintained for a long time.
They did not extensively seek opinions from users, not a single poll, and even when many people raised objections in the issues / PR, they simply closed the conversation: neovim/neovim#21062 neovim/neovim#20545
I wish this should not happen in Vim.
- There are other tools still using cscope interface like: pycscope for python, starscope for ruby, and gtags-scope for 60+ languages.
- LSP servers are not always available for certain languages or environment.
- LSP still have performance issues in large code base.
- Temporary system, for short term work, you don't want to setup complex LSP systems.
Plugins with job api today can simulate a cscope, I tried some, but none of them can provide same user experience like native cscope interface. and there are already a bunch of existing plugins, like gutentags, atags, gutentags_plus, vim-gtags, have the dependency on the native cscope interface. Replacing it with a plugin implementation will simply break this little ecosystem.
I have been using gtags-cscope for a long time, and it has served me very well, especially in languages that lack proper language servers.
It is a tragedy that neovim remove it without any discussion.
Hope Vim can preserve it.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christian Clason
I have yet to see this "nuance"; none of the comments I've come across (in this and other contexts; there are similar threads on Neovim and Helix "joining forces", for example) offer more than a simple drive-by-comment without details.
Happy to be proven wrong, though, if you can point me towards such a comment with a concrete, spelled out, proposition including a cost-benefit analysis?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christian Clason
It's been repeatedly pointed out that Neovim removed the bundled cscope plugin in favor of an external plugin, which has more features and can be developed faster. Stop making it sound like that functionality was simply removed without a replacement strategy.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Yegappan Lakshmanan
As the author of the Vim9 LSP plugin (https://github.com/yegappan/lsp), I can comment on the limitations of LSP with very large code bases (hundreds of thousands of files and millions of lines of code).
LSP doesn't work properly with a very large C code base (which is typical in many large companies). For example, in these code bases,
a symbol could be defined in multiple places to support different architectures, use cases, etc. Also, it is typical to use '#ifdef' to handle
different architectures and platforms (similar to the Vim code base). The LSP "Goto definition" and other features. doesn't work in these
cases. Also, for many of the LSP functionality to work properly you need to load the files in the LSP server. When you have hundreds
of thousands of files, this simply doesn't work.
Tools like cscope, tags, GNU id-utils, GNU global and opengrok are suitable for handling such large code bases.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Linwei
Too many replies above. If you don’t have enough time to read through them, here’s a TL;DR version:
- Vim is similar to Debian LTS stable, while NeoVim is like Ubuntu testing without LTS.
- Choose at your own risk.
—
Reply to this email directly, view it on GitHub,.
You are receiving this because you commented.
jgb
I hope vim stays vim. I tried neovim, but didn't like it, it's community is too chaotic for my taste.
The amount of plugins showing up for nvim is enormous, but most of them are of low quality and are often not maintained more than a few weeks or months before everybody jumps ship to the newest shiny thing.
I don't care for LSP (it's too slow, and I just don't need it, I've got jedi for python which is perfect), treesitter is slow, buggy and makes my syntax coloring look like a tacky christmas tree and I don't like lua as a language. Also, I would miss gvim too much, I still prefer gvim over vim/nvim in a terminal.
As I said, I hope vim can stay vim, meaning a stable, steady and reliable continuation of Bram's work.
Stability, compatibility and reliability should be preferred over shiny new gimmicks.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Brickviking
As for me, even though I'm currently working with emacs at the moment, I prefer vim on terminal, gvim has some issues with a couple of the themes I like to use. Might be something on my end, so no heat to the project for that. Old systems like mine can run vim no troubles, no idea about neovim under terminal, if it's even a thing.
TL;DR; let us each (vim/neovim) do our own thing. My uninformed opinion is "Build it. They will come." And fighting about it would not be what Bram wished for. I don't know what his opinion was regarding the neovim project, but there never seemed to be any real bad feelings. Let's keep it that way. If we try to integrate everything, it'll be a rare person who can pull it off, and most people probably won't be happy.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
SamPosh
With the lua integration neovim's plugin eco system increased. May be vim can do similar(may be micro-python integration)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Linwei
Can we renovate vim's pum window (native completion window) ?
Vim's pum window was designed 17 years ago, in version 7.0 (2006), It renders many completion systems appear a little outdated.
Here is a side-by-side comparison. The image below showcases a screenshot from nvim-cmp, which transitioned to a custom completion menu several years ago and now boasts a significantly improved and visually appealing appearance:
- The popup can be adorned with a border.
- Various kind fields can be distinguished through distinct highlighting.
- Different kinds can display accompanying text alongside their icons.
- Matched characters can be emphasized through highlighting.
- Looks polished and modernized.
Another screenshot is from YCM, which is using vim's native pum window:
- The kind field is restricted to display only one character, can't provide enough information.
- Can't have a border,
- It is not possible to discern which parts of the candidates are matched.
- Looks a little out-dated.
Vim has got many great completion plugins, some offering superior responsiveness and more accurate completion results. However, when I shared my recommendation with my friends, some of them expressed that the vim could benefit from further polishing the completion window.
There are many plugins using pum window, including:
The maintainer of ycm [said](ycm-core/YouCompleteMe#4180 (comment)_:
My suggestion would be to improve the Vim PUM rather than have every plugin faff around building broken ones.
This is an excellent point, and I wholeheartedly agree. If Vim can revamp the current pum window, all the plugins above can greatly benefit from it, resulting in a modernized and enhanced appearance for Vim overall.
Here are several potential improvements, listed in order of priority from high to low:
- add an optional border for pum.
- can specify a highlight group for each kind item.
- accept longer text in the kind field.
- highlight the matched text.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.