[vim/vim] Vim a writeoff for me after more than 10 years (#4019)
jonshouse1
I would just like to say that changes to the way vim works have written it off as an editor for me.
I use vim BECAUSE is is not mouse driven, BECAUSE it does not autocomplete, BECAUSE search is simple and powerful, all these are now broken features.
The final straw is I now find cut&paste via X is broken between vim instances in xterm. I use a number of machines (physical and virtual) and have (for at least 10 years) cut&paste text between them. This is important to the way I manage various projects.
I have spent many hours today modifying vimrc files on 9 machines and still not find a satisfactory setup. Each new VM I use I have to try and "fix" vim, it is simply not worth the effort.
As vim developers do not seem to think it is important to have at least one configuration file that is READ LAST, I can not find a way to globally configure vim to make it useful again.
I've lost the best part of a day of work (for a second time) trying just to get the editor to work how it has always worked before, I simply give up at this point.
Recent changes make vim behave just like any other editor, with no option to simply back out. I might as well use any other editor, at least configuration for other editors is likely to be more sane.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
mattn
If it is a bug as you comment, we hope to fix as possible. What is your OS? The version that worked fine? The version that does not work? Please provide way to reproduce.
jonshouse1
I added this to /etc/vimrc
"JA disable wizzy stuff
set noincsearch
set nocindent
set nosmartindent
set noautoindent
set mouse=
set ttymouse=
Almost works, but pasting text with the middle mouse button gives a mess (multiple blank lines, indents etc)
I will turn it around.
For ANY newer version of vim, what do I add to which files to turn all this visual shit off ? If I need to add specific variants of text then the game is over. I admin lots of machines, If I cant simply paste some text into a config file and make this all go away then it is not going to work for me....
I want vim today to act as vim of 10 years ago, how ?
依云
Newer Vim actually works better for me for pasting into because of the recently supported bracketed paste mode. Ten years ago I had to use the awkward paste mode and ensure I was in insert mode before pasting.
mattn
jonshouse1
Newer Vim actually works better for me for pasting into because of the recently supported bracketed paste mode. Ten years ago I had to use the awkward paste mode and ensure I was in insert mode before pasting.
Awkward is fine for me. The only thing the vim instances have in common is the X11 desktop they are running on, some are in VMs being X11 forwarded, some via ssh (with no X forwarding). I have a 4k display with 15 to 20 windows, I want to highlight text from one vim instance and paste into any other relying only on the paste buffer in the local UI. Most of the vim instances are curses ANSI text only (or should be).
jonshouse1
set t_BE=
Seems to make no difference, paste is still a mess.
If I exit vim and use cat >x in bash then paste with the middle mouse button it looks fine.
mattn
Well, we still not understand what you get wrong. Could you please take a screenshot? Possibly, BEFORE and AFTER the paste. If you want to paste as you can see is, you can try set paste too.
Gary Johnson
> I added this to /etc/vimrc
>
> "JA disable wizzy stuff
> set noincsearch
> set nocindent
> set nosmartindent
> set noautoindent
> set mouse=
> set ttymouse=
>
> Almost works, but pasting text with the middle mouse button gives a mess
> (multiple blank lines, indents etc)
>
> I will turn it around.
>
> For ANY newer version of vim, what do I add to which files to turn all this
> visual shit off ? If I need to add specific variants of text then the game is
> over. I admin lots of machines, If I cant simply paste some text into a config
> file and make this all go away then it is not going to work for me....
>
> I want vim today to act as vim of 10 years ago, how ?
$VIMRUNTIME/defaults.vim. See ":help defaults.vim". To avoid this
problem, see ":help skip_defaults_vim" and add this line to your
/etc/vimrc
let skip_defaults_vim = 1
HTH,
Gary
jonshouse1
vim-dev ML
Dominique Pellé
Judging from your screenshots, it looks like you forgot to do ":set paste" before
pasting with the middle button. This is not something new.
Although I think that recent vim can detect that it's a paste with the mouse
so can avoid having to do ":set paste" (not sure when that was introduced).
The original report is too vague for people to guess what was the problem.
A short concrete example of what you get when copy/pasting would have made
it clearer rather than a long rant.
—
You are receiving this because you commented.
jonshouse1
Judging from your screenshots, it looks like you forgot to do ":set paste" before
pasting with the middle button. See :help 'paste'.
This is not something new. Although I think that recent vim can detect that
it's a paste with the mouse to can avoid having to do ":set paste" (not sure
when that was introduced).
I have NEVER had to do any kind of intervention with commands in order to paste. If I toggle to insert mode the editor should not be in any way "aware" that is pasted text is anything other than typed.
The original report is too vague for people to guess what was the problem.
A short concrete example of what you get when copy/pasting would have made
it clearer rather than a long rant.
Like the 3 images posted above for example ........
—
You are receiving this because you commented.
jonshouse1
/etc/vimrc let skip_defaults_vim = 1
Thanks Gary, adding that to /etc/vimrc does the trick.
Interestingly googling "let skip_defaults_vim=1" shows a number of mailing list posts from people who also think recent changes are a shit show. As package updates for Debian and other distros based on it are so slow users are only now being impacted.
Users do not have the time to monitor development of well established packages. Please developers: don't fuck with defaults. Important behaviour changes should be opt in - not a never ending struggle to try and opt out.
—
You are receiving this because you commented.
niva...@gmail.com
Out of encountered problem, I'm in the same user case of you. Work with several physical and virtual machine but under win7 (more than 300).
To synchronize vim's files on every machines, why don't you use rsync (used it under msys2, it works well). (equivalent of robocopy under windows)
Best Regards.
NiVa
Bram Moolenaar
> > Newer Vim actually works better for me for pasting into because of
> > the recently supported bracketed paste mode. Ten years ago I had to
> > use the awkward paste mode and ensure I was in insert mode before
> > pasting.
>
> Awkward is fine for me. The only thing the vim instances have in
> common is the X11 desktop they are running on, some are in VMs being
> X11 forwarded, some via ssh (with no X forwarding). I have a 4k
> display with 15 to 20 windows, I want to highlight text from one vim
> instance and paste into any other relying only on the paste buffer in
> the local UI. Most of the vim instances are curses ANSI text only (or
> should be).
and copy/paste with xterm is very nice. Just keep the shift key pressed
to copy/paste using xterm instead of Vim.
Unfortunately quite a few "modern" terminal emulators don't support
this.
For the defaults: It's impossible to please everyone. In the maillist
we only hear from the users who complain, not the users that are happy
with these defaults.
--
The process for understanding customers primarily involves sitting around with
other marketing people and talking about what you would to if you were dumb
enough to be a customer.
(Scott Adams - The Dilbert principle)
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
You are receiving this because you commented.
fritzophrenic
I'm happy with the new defaults! For me, they make it less painful when I start using a new machine, to get some basic editing done before I find time to clone my full config.
But then, I'm a person who likes using a lot of the optional features in Vim and find the old-style edit-over-a-slow-modem vi-compatible mode of Vim to be a major pain. defaults.vim IIRC was designed to show off some of the new features.
—
You are receiving this because you commented.
K.Takata
It seems that the ftplugins were turned on by defaults.vim (see :help defaults.vim). When you opened a *.c file, 'cindent' became automatically turned on, even if you wrote set nocindent in /etc/vimrc.
However, even if 'cindent' is turned on, if you use a terminal emulator that supports the bracketed paste mode (see :help xterm-bracketed-paste), you can paste the content as is without indenting.
I use vim BECAUSE is is not mouse driven,
Why not do cut&paste with keyboard, then?
If your Vim supports the clipboard feature (see :help clipboard), you can paste by "*p in normal more or <C-R><C-O>* in insert mode. You don't need to use a mouse.
—
You are receiving this because you commented.
jonshouse1
I'm happy with the new defaults! For me, they make it less painful when I start using a new machine, to get some basic editing done before I find time to clone my full config.
But then, I'm a person who likes using a lot of the optional features in Vim and find the old-style edit-over-a-slow-modem vi-compatible mode of Vim to be a major pain. defaults.vim IIRC was designed to show off some of the new features.
What you have done in that case is turn a cat into a dog by stretching its legs and pulling its ears. If you want a different editor then it should be a fork, with a new name and new user base rather than a damaged version of the original......
—
You are receiving this because you commented.
fritzophrenic
Yes, all software should forever freeze and never introduce any new features because you don't want to learn how to use them. 🙄
Vim is pretty unique among software in that it's actually possible to configure it to act like the old, featureless, outdated vi of old with fairly high fidelity, for people like you who hate useful features.
Go ahead and configure it that way if you want. You've been told how. The rest of us like having a modern editor.
—
You are receiving this because you commented.
jonshouse1
Yes, all software should forever freeze and never introduce any new features because you don't want to learn how to use them. roll_eyes
LOL ...
If the feature BREAKS the way the editor works then that change to behaviour should not be a default.
Vim is pretty unique among software in that it's actually possible to configure it to act like the old, featureless, outdated vi of old with fairly high fidelity, for people like you who hate useful features.
"Useful" is very much subjective. I do real work, all day, on Linux, nothing else ... when the new "features" break the way I work, in such a way that I need to stop doing paid work and fuck around with configuration files and google searches then yes, I do complain
Go ahead and configure it that way if you want. You've been told how. The rest of us like having a modern editor.
If I wanted a modern editor I would not be using vi. I would almost ANY other editor.
The only useful feature I've seen from vim in recent years is syntax highlighting. All the "auto indent" and search "improvements" have been nothing to me but a delay while I figure out how to turn them off.
—
You are receiving this because you commented.
fritzophrenic
Vim's GitHub repository has history going back to 2004. If you really actually want the Vim of 10 years ago like you said earlier, and you never want it to change, then you may as well download the source code from whatever you consider Vim's "golden age" and just make a build and stick with that. That's really the only way you're ever going to avoid all change in the software you use.
—
You are receiving this because you commented.
K.Takata
Just FYI, we have the vim-history repository. This repository has the history from v1.14 to v6.4. If you need older version before v7.0, you can use this.
—
You are receiving this because you commented.
K.Takata
The only useful feature I've seen from vim in recent years is syntax highlighting.
It was added in v5.0 in 1998, just 21 years ago. 😄
—
You are receiving this because you commented.
Christian Brabandt
Bram Moolenaar
--
A)bort, R)etry, B)ang it with a large hammer
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Florian Heigl
FlorianHeigl left a comment (vim/vim#4019)vim -C sucks a little bit less, i'd still rather have nvi everywhere where there's vim.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
anzz1
anzz1 left a comment (vim/vim#4019)anyone stumbling upon this from google i set up quick instructions how to build 7.4 from source as it used to be in older debian distributions: https://github.com/anzz1/vimconfig
its of course slightly more complicated when apt-get install vim used to suffice, but as long as the old version is buildable from source and keeps working its fine. of course at some point there could be issues when distro maintainers decide to 'deprecate' some dependency.
these editors are very much a muscle memory thing and changing what some keys or mouse actions etc. do isnt something that should be forced upon. its like taking a hammer out of the hand of a craftsman and replacing it with something else.
text editors are a solved thing, but im not against people making new features and taking something into a different direction.
i am against those people forcing the new paradigms on me. let me do things like i have always done, and you can have your new thing and do differently.
in these cases though a separate version should be left as a package for easy access to people, either fork vim to a "nu-vim" for the people looking for new features, or at very least make it so that the old thing still exists, like is the situation for the older "vi".
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christian Brabandt
chrisbra left a comment (vim/vim#4019)I cannot recommend to build such an old Vim version and use it productively. I don't even know if this still builds with todays tool set. Also you will be missing quite a few security and runtime file updates.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Florian Heigl
FlorianHeigl left a comment (vim/vim#4019)2025, 11:43:
> *chrisbra* left a comment (vim/vim#4019)
> <https://github.com/vim/vim/issues/4019#issuecomment-3257736528>
> I cannot recommend to build such an old Vim version and use it
> productively. I don't even know if this still builds with todays tool set.
> Also you will be missing quite a few security and runtime file updates.
>
He posted the literal instructions for doing that, so you know at that
instant that it does build.
—
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAVSVG7HWIYNVG2TZ2Y7SUL3RFLMBAVCNFSM6AAAAAB5KXFMSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENJXG4ZTMNJSHA>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
anzz1
anzz1 left a comment (vim/vim#4019)yeah it does build and fortunately no-one has 'deprecated' any of its dependencies as of today.
unfortunately today everything has drifted away from the original linux ideology of having a "collection of small tools where everything does one thing and does it well" starting from introduction of the monolithic systemd, and now the new generation of programmers seem to have this idea that everything should have to be constantly updated.
some tools in linux are 30 years old with little to no change and there is absolutely nothing wrong with that. for example its nice that no-one hasn't decided yet that we need to change the syntax of bash or replace it with rust or some other thing in vogue.
what about security
when you make a simple tool it is quite possible to ultimately iron out all the coding errors, at that point there are no vulnerabilities left hence no need to ever update
so the fuss of security updates on monolithic big things also became about because of the very monolithicness itself, instead of keeping things simple which also keeps things secure
my point is when you get to a point you've made a hammer and made it perfect, you dont need to keep tinkering with it forever, and move to creating a chisel instead
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
依云
lilydjwg left a comment (vim/vim#4019)the original linux ideology of having a "collection of small tools where everything does one thing and does it well"
This is the UNIX philosophy, not Linux's. I don't think Vim is doing editing well enough though: better than any other editor, but still has quite room to improve.
its nice that no-one hasn't decided yet that we need to change the syntax of bash
Quite some shells has been built to change the syntax of bash in one way or another; zsh, nushell, elvish, to name a few.
replace it with rust
It is happening with the fish shell.
when you make a simple tool it is quite possible to ultimately iron out all the coding errors, at that point there are no vulnerabilities left hence no need to ever update
And then it is dying because it lives in the old times, not suitable for new needs, e.g. TeX.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christian Brabandt
chrisbra left a comment (vim/vim#4019)no-one hasn't decided yet that we need to change the syntax of bash
Bash also gets new features and understands new syntax constructs.
when you make a simple tool it is quite possible to ultimately iron out all the coding errors, at that point there are no vulnerabilities left hence no need to ever update
Who says so? Did you ever check the todo list? Or the open issues here? And regarding no security vulnerabilities: Please make sure you check it: https://security-tracker.debian.org/tracker/source-package/vim
(Note Vim 7.4. has been released in August 2013, so make sure to check all the CVEs between CVE-2025 and CVE-2013)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
anzz1
anzz1 left a comment (vim/vim#4019)This is the UNIX philosophy, not Linux's
The philosophy is the same. The reason for Linux to exist was to create a free version of UNIX. A carbon-copy. UNIX philosophy IS Linux philosophy. Or should I say was, as it is true that the new generation has been changing the philosophy and moving it into a bad direction. But that is not just an issue with just vim, but rather larger cultural shift to a bad direction overall.
I am fearful of what will happen to Linux after Torvalds retires, he already fought the fight to prevent "replace it with C++" happening 20 years ago, but now the same thing is happening with a new generation and "replace it with Rust" but Torvalds has aged and mellowed out and doesn't have the fight in him to push back anymore, and the kernel is heading towards a multi-language mess.
Not particularly an issue of vim per-se, but an example of the direction things are going. Out with the old tried-and-true still-perfectly-valid methods, in with the vibe coding and new shiny things for the sake of being new and different.
Quite some shells has been built to change the syntax of bash in one way or another; zsh, nushell, elvish, to name a few.
My point exactly. They are not bash, they are zsh, nushell, elvish and so on.
They didn't change the original thing, they made a new one.
That is what I meant by saying "you've made a hammer and made it perfect, you dont need to keep tinkering with it forever, and can move to creating a chisel instead".
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
drjoms
drjoms left a comment (vim/vim#4019)the original linux ideology of having a "collection of small tools where everything does one thing and does it well"
This is the UNIX philosophy, not Linux's. I don't think Vim is doing editing well enough though: better than any other editor, but still has quite room to improve.
its nice that no-one hasn't decided yet that we need to change the syntax of bash
Quite some shells has been built to change the syntax of bash in one way or another; zsh, nushell, elvish, to name a few.
replace it with rust
It is happening with the fish shell.
when you make a simple tool it is quite possible to ultimately iron out all the coding errors, at that point there are no vulnerabilities left hence no need to ever update
And then it is dying because it lives in the old times, not suitable for new needs, e.g. TeX.
No one uses "zsh, nushell, elvish, to name a few." in any serious professional environment.
Everyone always use BASH and on occasion SH.
"And then it is dying because it lives in the old times, not suitable for new needs, e.g. TeX." - and that's fine. I bet bottom dollar, someone is using it RIGHT NOW as I type it.
Also, lasers replacing scalpels. Scalpels that were used for several thousand years. So lasers must be better right? Same goes for hammers.
Modern != better.
TeX is used TODAY MORE THAN IT EVER WAS! TeX is used by Gemma AI models, I bet my $ - Gemini uses same. I would bet another one, that GROK and alike use it too.
Gemma uses it for math formulas, etc.
Good tool done once.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you commented.
依云
lilydjwg left a comment (vim/vim#4019)No one uses "zsh, nushell, elvish, to name a few." in any serious professional environment.
Everyone always use BASH and on occasion SH.
What do you mean by "serious professional environment"?
TeX is used TODAY MORE THAN IT EVER WAS! TeX is used by Gemma AI models, I bet my $ - Gemini uses same. I would bet another one, that GROK and alike use it too.
Gemma uses it for math formulas, etc.
TeX's math syntax remains good and popular.
Good tool done once.
But TeX is not good for modern use. If I need anything involving fonts or CJK, I'd better give typst a try.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you commented.
anzz1
anzz1 left a comment (vim/vim#4019)If I need anything involving fonts or CJK, I'd better give typst a try.
Different tools for different uses. You don't change the tool that used to work one way to work differently the next, and then call it the same. You don't transform a hammer to a chisel, and then keep calling it a hammer.
It's pretty insane that such fundamentally simple thing has to be explained and spelled out.
typst is an example how to do it correct, you don't change TeX, but you create a new thing.
If you wanted to create vim with all these new features that replace the simple old functionality, fork it and name it something else god damn it instead of breaking people's workflows. All of this nonsense could have been avoided with that.
But yeah luckily its still possible to use vim 7.4, even though it already has nonsense mouse and incremental search etc. options included at that point, at least they can be easily turned off and it still works like it used to.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you commented.
依云
lilydjwg left a comment (vim/vim#4019)Different tools for different uses.
You are reminding me the era before Unicode and UTF-8 when every country had their own charset.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you commented.
anzz1
anzz1 left a comment (vim/vim#4019)You are reminding me the era before Unicode and UTF-8 when every country had their own charset.
That is a completely different thing and has no bearing to issue at hand. The 7-bit ASCII charset was created literally in the age of the punch card and then 8-bit "extended" ASCII was just bolted on top of that to keep compatibility. And then we got the shitshow when UTF-8 didn't exist yet and UTF-16 was chosen to become the Unicode standard for Windows that had to make all these compatibility layers between (A)NSI and (W)ide character APIs, and finally the UTF-8 which would have been the right choice in hindsight but again that didn't exist yet and has its own issues like not being able to know a string's length without either saving the length separately or parsing the string.
None of it has anything to do with the fact that tools that have existed a long time and people have muscle memory for should be kept as-is, which doesn't mean at all that new tools for new workflows can't be created.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you commented.
Christian Brabandt
chrisbra left a comment (vim/vim#4019)well, I suggest to try tiny vim build then, if you do not want all the bells and whistles.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you commented.
Florian Heigl
FlorianHeigl left a comment (vim/vim#4019)2026, 09:27:
> *chrisbra* left a comment (vim/vim#4019)
>
> well, I suggest to try tiny vim build then, if you do not want all the
> bells and whistles.
>
annyoing.
also have a nosyntax.vim highlighting config etc. but nvi has the advantage
vim stays at defaults for those who like it, and it saves the hassle of
edge cases where behaviour might still differ by a small fraction.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you commented.
drjoms
drjoms left a comment (vim/vim#4019)I am approaching this from a neutral perspective; I have been an Emacs user for many years, but I am currently transitioning to Vi/Vim for certification purposes.
I believe we are seeing a fundamental breakdown in the "social contract" between the tool and its power users. The issue isn't just the introduction of "new features"; it is the disruption of muscle memory. For a tool like Vim, predictability is its most important feature. When updates change established behaviors or break long-standing configuration patterns, they aren't "improving" the tool for the veteran user—they are breaking the user's cognitive ergonomics.
In the Linux ecosystem, there is a standard principle: "Do not break userspace." While Vim is an application and not a kernel, the principle applies here. When a tool becomes part of the infrastructure, its stability and predictable behavior become a requirement, not an option.
I would urge the development team to consider a more bifurcated approach to evolution. If the goal is to move toward a more "modern" editor experience, perhaps the project should maintain a "Classic/LTS" branch for those who rely on the legacy workflow, or clearly distinguish a new, experimental branch (e.g., "Vim-Next") from the stable, predictable core. This allows for evolution without forcing legacy users to fight their own editor every time a new patch is released.
Finally, I'd like to share a thought from my perspective as a newcomer. Witnessing the difficulties and frustration that experienced users are facing makes it difficult to feel confident in committing to Vim as a long-term tool. It is hard to build a foundation on a tool that seems to be moving away from the very people who made it successful. I hope the team can find a way to grow that also protects the stability that makes Vim worth learning in the first place.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you commented.
Christian Brabandt
chrisbra left a comment (vim/vim#4019)Vim has traditionally been very carefuly about making backwards incompatible changes. In fact, you probably can still run Vim with a vimrc that has been setup like 25 years ago, so we already do this. We are just adding new features, but trying to be careful not to break existing features. However, this needs a balance for new users who may expect additional features and settings. For those the defaults.vim file has been made available, but that does not affect existing users.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you commented.
drjoms
drjoms left a comment (vim/vim#4019)@jonshouse1 seems to disagree.
With that said, I will stay silent from my position from now on, as I am not knowledgeable enough on the topic.
You made a claim and addressed my concerns. So if this is true - I am happy with everything.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you commented.
依云
lilydjwg left a comment (vim/vim#4019)So if this is true - I am happy with everything.
Yes, this is mostly true (except when bugs happen of course)---more true than NeoVim. I started using Vim since version 7.2 and have a couple of more-than-10-year-old plugins. They still work as they did.
It did break my config a few times, but that's trivial compared to the time it didn't, and it was easy to fix.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you commented.
jonshouse1
jonshouse1 left a comment (vim/vim#4019)@jonshouse1 seems to disagree. With that said, I will stay silent from my position from now on, as I am not knowledgeable enough on the topic. You made a claim and addressed my concerns. So if this is true - I am happy with everything.
Im older and wiser now :-) 10 years ... wow ....
I added an alias for vi to "vim -C" (as was pointed out by someone in the thread) and most of my issues went away.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you commented.