[vim/vim] runtime(filetype): set bash scripts to bash filetype (PR #16309)

Luca Saccarola

unread,

Dec 26, 2024, 4:49:13 PM12/26/24

to vim/vim, Subscribed

Hi,
I think this makes more sense... I don't know why it isn't the default

You can view, comment on, or merge this pull request online at:

https://github.com/vim/vim/pull/16309

Commit Summary

1d4ac16 runtime(filetype): set bash scripts to bash filetype

File Changes

(1 file)

M runtime/autoload/dist/ft.vim (1)

Patch Links:

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

Luca Saccarola

unread,

Dec 26, 2024, 5:01:52 PM12/26/24

to vim/vim, Push

@saccarosium pushed 1 commit.

b21c5b9 runtime(filetype): set bash scripts to bash filetype

—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.

Luca Saccarola

unread,

Dec 26, 2024, 5:20:14 PM12/26/24

to vim/vim, Push

@saccarosium pushed 1 commit.

7bedf16 runtime(filetype): set bash scripts to bash filetype

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Dec 27, 2024, 9:57:01 AM12/27/24

to vim/vim, Subscribed

thanks

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Dec 27, 2024, 10:11:42 AM12/27/24

to vim/vim, Subscribed

Closed #16309 via b9b762c.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

D. Ben Knoble

unread,

Dec 27, 2024, 4:00:36 PM12/27/24

to vim/vim, Subscribed

Has anyone checked that this still loads appropriate syntax, ftplugins, etc.? Now I’ve got to (personally) duplicate my sh runtime files to bash, make sure ALE knows what to do when the filetype=bash, etc.

I think this is going to lead to churn for many folks :)

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

D. Ben Knoble

unread,

Dec 27, 2024, 4:01:33 PM12/27/24

to vim/vim, Subscribed

Alternatively, the default bash runtime files could runtime the shell files, which they may already?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

D. Ben Knoble

unread,

Dec 27, 2024, 4:03:29 PM12/27/24

to vim/vim, Subscribed

Ok, should have done my homework first: the bash runtime support already redirects to the shell support. So ALE is the last place I personally need to check.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

D. Ben Knoble

unread,

Dec 29, 2024, 11:01:52 AM12/29/24

to vim/vim, Subscribed

See dense-analysis/ale#4888

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Rob Foehl

unread,

Dec 29, 2024, 12:28:52 PM12/29/24

to vim...@googlegroups.com

On Fri, 2024-12-27 at 13:03 -0800, D. Ben Knoble wrote:
> Ok, should have done my homework first: the bash runtime support already redirects to the shell support. So ALE is the last place I personally need to check.

Sounds like both you and the submitter should do a bit more homework:
this breaks in several ways, which the extant ftplugin/bash.vim is not
sufficient to handle.

The number of randomly broken filetypes in the last year is getting
worrisome.

-Rob

vim-dev ML

unread,

Dec 29, 2024, 1:44:53 PM12/29/24

to vim/vim, vim-dev ML, Your activity

(Argh, resending due to conflicting list headers... Also get the
distinct impression that the Github crowd aren't paying attention to the
mailing lists.)

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

D. Ben Knoble

unread,

Dec 29, 2024, 6:53:57 PM12/29/24

to vim/vim, vim-dev ML, Comment

Sounds like both you and the submitter should do a bit more homework: this breaks in several ways, which the extant ftplugin/bash.vim is not sufficient to handle. The number of randomly broken filetypes in the last year is getting worrisome.

Perhaps you could elaborate on what else is broken? (In particular, if there's interest in building a case for reverting this, having such a list might help.)

I expect the list to include many plugins, but I couldn't think of much else in Vim's tree that might break. I'm happy to be wrong.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

vim-dev ML

unread,

Dec 29, 2024, 10:16:59 PM12/29/24

to vim/vim, vim-dev ML, Your activity

On Sun, 2024-12-29 at 15:53 -0800, D. Ben Knoble wrote:
> Perhaps you could elaborate on what else is broken?

There are at least two, arguably three, issues with this that should be
painfully obvious to anyone who understands how Vim does filetype
detection and plugin loading, and I'm being deliberately vague about
what they are to underscore the point that the submitter doesn't, nor
has put forth any discernible effort to do so. That's not okay,
especially when the only justification is "I like this better".

The several more subtle issues with the specifics might have been
otherwise forgivable -- but even then, that's kind of the point of
review, and that didn't happen here, either.

> (In particular, if there's interest in building a case for reverting this, having such a list might help.)

It should be reverted, if for no other reason than trying to fix it up
after the fact is still pointless without a complete rework of the
existing sh filetype. Having two names for a single filetype that still
has to do a bunch of guesswork -- and requires testing the result
everywhere, e.g. is_bash and friends -- is adding failure modes for
absolutely no benefit.

> I expect the list to include many plugins

Probably, although some of it has more to do with the mechanisms Vim
provides for external code to consume. Your first assumptions about
what this might break were heading in the right direction, and I'm only
picking on the follow up since you also specifically mentioned doing the
homework :)

-Rob

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Dec 30, 2024, 3:43:12 AM12/30/24

to vim/vim, vim-dev ML, Comment

I'm being deliberately vague about what they are to underscore the point that the submitter doesn't, nor has put forth any discernible effort to do so.

Sorry, that is not a convincing argument for reverting the change, and I am not going to take any request to revert such a change serious, when the submitte stays deliberately vague.

I can tell you why I considered merging this change of a new filetype:

The former method of using vim script variables seems like a hack, especially when both the bash and Posix shell scripts are more and more deviating. It does hurt maintaining runtime scripts and one always needs to consider if a change only affects a single filetype of several ones. Since we had the bash filetype already for a while, and it sources the existing shell runtime files, it did not feel like a big risk other than a differently named filetype.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

D. Ben Knoble

unread,

Dec 30, 2024, 10:24:31 AM12/30/24

to vim/vim, vim-dev ML, Comment

I second the comment RE: vagueness; while I understand and appreciate the position that the patch may not have accounted for all possible affects, deliberately withholding knowledge of defects will make it difficult to repair them!

I will continue to try to fix problems as I notice them, assuming for now we plan to keep the new filetype split. At the moment, I haven't come across any other than plugins, but I also am still on 9.1.0730 and haven't picked up this change yet.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Luca Saccarola

unread,

Dec 30, 2024, 3:14:56 PM12/30/24

to vim/vim, vim-dev ML, Comment

The previous behavior was a little confusing because it wasn't consistent... I was getting like 20% of the time the bash filetype and 80% the sh one. I get what you guys are saying but at the same time I believe that was really confusing. In my book either I did this or I would remove the bash filetype completely.

Having two names for a single filetype that still has to do a bunch of guesswork

Note that I will make some PRs to separate the logic between filetypes.

As Chris is saying bash and POSIX shell are diverging more and more it doesn't make sense to have bash logic mixed with sh logic.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

vim-dev ML

unread,

Dec 30, 2024, 9:22:55 PM12/30/24

to vim/vim, vim-dev ML, Your activity

On Mon, 2024-12-30 at 00:43 -0800, Christian Brabandt wrote:
> Sorry, that is not a convincing argument for reverting the change, and I am not going to take any request to revert such a change serious, when the submitte stays deliberately vague.

I wouldn't expect otherwise. I would, however, expect a higher bar for
accepting random changes from people that keep breaking config that's
likely older than they are.

There was no review, and the change breaks existing behavior.

Again.

I don't buy the argument that those who suffer the consequences bear the
burden of cleaning up the mess, and that division of responsibility
certainly doesn't stand in any other context. There is no apparent
return on investment for spending time trying to fix any of this when
there is no apparent willingness to acknowledge why that's necessary in
the first place, so why do it?

> The former method of using vim script variables seems like a hack, especially when both the bash and Posix shell scripts are more and more deviating.

It is a hack. But this change doesn't do anything about that, it just
makes the situation worse.

Here's what should have been a blatantly obvious miss, spelled out:

autocmd FileType sh ...

Oops. Easy enough to fix, though? Everyone can just change them all to
FileType bash,sh -- except that wasn't necessary before, so we're back
to laying responsibility on the victims.

But that fix doesn't quite work, either: if whatever such an autocmd
calls cares about the differences between sh and bash, it has to do the
is_bash dance itself. And it still does, since the underlying filetype
scripts are all the same, just now with an added layer of indirection.

Okay, so maybe fix that with a doautocmd in ftplugin/bash.vim. Now you
can write FileType autocmds that only trigger for bash, and all the
existing ones for sh still work... Right? But you can't really remove
any of the is_bash crap from those, since you still have to deal with
the potential for both of them running. Oh, and you can't be sure about
all of the detection cases, so sometimes ft=sh is still true for bash,
and you're back where you started.

And that doesn't consider did_filetype() at all, so maybe it still won't
work... Maybe that's not even fixable without breaking at least one
other path through the whole mess.

Even all of that doesn't account for cross-version compatibility, nor
that bash is only one of several possible specializations of sh, nor the
subtle -- or indeed sometimes not so subtle -- differences between
initial ftplugin loading and doing a wholesale runtime! all/the/things
from another filetype after the fact, and so on.

And that's still far from everything wrong with this.

> Since we had the bash filetype already for a while, and it sources the existing shell runtime files, it did not feel like a big risk other than a differently named filetype.

The bash filetype was only added to allow for an override of Vim's
assumptions via modelines. It says so right in the script.

Vim has had a better solution to filetype specialization since the dot
syntax for multiple types was introduced in early 7.0. Unfortunately, a
lot of the ftplugin/syntax/etc. scripts predate that, and most aren't
built with composability in mind; how to do that properly isn't really
written down anywhere, and may be something of an open question.

That there are already numerous attempts at solving this baked into the
runtime files that ship with Vim suggests that it's a problem worth
solving in the general case. (See e.g. the html syntax, for which there
are at least three distinct methods of loading it from -- or before --
other types, and at least one full copy of its contents in another
script.)

In the specific case of bash vs. sh, a better way to do this would be,
to a rough approximation:

- Change ftplugin/bash.vim to only load the sh filetype if that hasn't
happened already (preserving the ft=bash modeline behavior)

- Change the filetype detection to setf sh.bash for all is_bash cases,
rather than a unique filetype

- Fix up the cases where that doesn't really work correctly, and
generalize the pattern for use elsewhere

That would preserve *all* existing behavior, and allow for piecemeal
migration of the bash-specific stuff into the subordinate type. Same
for external consumers.

It's curious that the separate change for Guile vs. Scheme started down
this path, came to the opposite conclusion, then stumbled into one of
the myriad workarounds already present...

-Rob

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

vim-dev ML

unread,

Dec 30, 2024, 9:36:15 PM12/30/24

to vim/vim, vim-dev ML, Your activity

On Mon, 2024-12-30 at 12:14 -0800, Luca Saccarola wrote:
> The previous behavior was a little confusing because it wasn't consistent... I was getting like 20% of the time the bash filetype and 80% the sh one.

Vim doesn't set ft=bash anywhere. If you're getting that at all, it's
either from a modeline -- the intended use -- or from some other piece
of your own config, possibly third party.

> > Having two names for a single filetype that still has to do a bunch of guesswork
> Note that I will make some PRs to separate the logic between filetypes.

You've quite badly misunderstood the point of that statement. Doubling
down on separating them without accounting for existing uses is making
it worse.

> As Chris is saying bash and POSIX shell are diverging more and more it doesn't make sense to have bash logic mixed with sh logic.

They aren't diverging. Syntactically, bash is a superset of POSIX
shell. It doesn't make sense to duplicate any of the base parts.

-Rob

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

Shane-XB-Qian

unread,

Dec 31, 2024, 3:15:04 AM12/31/24

to vim/vim, vim-dev ML, Comment

> > I'm being deliberately vague about what they are to underscore the point that the submitter doesn't, nor has put forth any discernible effort to do so.
>

> Sorry, that is not a convincing argument for reverting the change, and I am not going to take any request to revert such a change serious, when the submitte stays deliberately vague.

> I can tell you why I considered merging this change of a new filetype:

> The former method of using vim script variables seems like a hack, especially when both the bash and Posix shell scripts are more and more deviating. It does hurt maintaining runtime scripts and one always needs to consider if a change only affects a single filetype of several ones. Since we had the bash filetype already for a while, and it sources the existing shell runtime files, it did not feel like a big risk other than a differently named filetype.

to linuxer, i think mostly used to treat .sh as bash, only few cases there are different;
if you like to separate sh with bash, then do you plan to separate sh with dash (a 'd') ?

--
shane.xb.qian

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Shane-XB-Qian

unread,

Dec 31, 2024, 4:00:18 AM12/31/24

to vim/vim, vim-dev ML, Comment

to be clear, to this topic, i donot mind really (since i am only using bash), but just a question↟↟

--
shane.xb.qian

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.

Shane-XB-Qian

unread,

Dec 31, 2024, 4:15:41 AM12/31/24

to vim/vim, vim-dev ML, Comment

but changing this, i think it do may make some messy, external cmd may had its logic to judge ft,
but now "you" telling it confirmed is a "bash", i imaged would be some conflict

--
shane.xb.qian

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Luca Saccarola

unread,

Dec 31, 2024, 10:14:01 AM12/31/24

to vim/vim, vim-dev ML, Comment

Ok Rob, your point is much clearer and I think now we should rework better the sh filetype and use the compound filetype instead. I just don't understand why you are been such a cook about it. If you have some edge case that you like to be considered when changes. Just create some tests...

We all have different workflows and ways to do things. Even if I "did my homework" I probably wouldn't have the same problem that you are having simply because I don't use it like you are using it. Vim is built by the community and you help is needed we all work for free here and nobody has in mind every edge case when changing or developing. We all work for free and invest our own free time into this.

If you have issues on how thing are done speak up in a polite matter and come up with actual solutions without all the mining less digs to unpaid volunteers. The point you are making is valid but with your attitude is very difficult to actually taking you seriously...

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Shane-XB-Qian

unread,

Dec 31, 2024, 4:03:05 PM12/31/24

to vim/vim, vim-dev ML, Comment

i am not Rob, but Luca, i have some words to you too:
you may need to find out why it was working like that before rushed to change something~ :smile:

happy new year~
// btw: in the past, there 'vim calendar', tho i never get one, aha~

--
shane.xb.qian

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Shane-XB-Qian

unread,

Dec 31, 2024, 4:17:49 PM12/31/24

to vim/vim, vim-dev ML, Comment

and i thought Rob was worrying some conflict on ft judgement
and that used way had been fitted for many code, i guess so.

--
shane.xb.qian

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Gary Johnson

unread,

Jan 17, 2025, 12:37:14 PMJan 17

to reply+ACY5DGG76UDOXZYBXG...@reply.github.com, vim...@googlegroups.com

I thought this was going to be fixed. Or is what we have now the
fix? I just updated to Vim 9.1.1029 and noticed that one of my
plugins that tests for the filetype being "sh" fails because the
filetype is now "bash". This also affects the nrrwrgn.vim plugin.

Regards,
Gary

vim-dev ML

unread,

Jan 17, 2025, 12:37:40 PMJan 17

to vim/vim, vim-dev ML, Your activity

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

D. Ben Knoble

unread,

Jan 17, 2025, 12:55:22 PMJan 17

to vim/vim, vim-dev ML, Comment

I thought this was going to be fixed. Or is what we have now the fix? I just updated to Vim 9.1.1029 and noticed that one of my plugins that tests for the filetype being "sh" fails because the filetype is now "bash". This also affects the nrrwrgn.vim plugin. Regards, Gary

I don't know if consensus was reached on reverting this (see also dense-analysis/ale#4888 where this is confusion on what is happening).

This seems like a classic example of Chesterton's Fence

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Christian Brabandt

unread,

Jan 17, 2025, 1:31:21 PMJan 17

to vim/vim, vim-dev ML, Comment

Alright, I'll revert it

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

chdiza

unread,

Jan 19, 2025, 11:49:45 AMJan 19

to vim/vim, vim-dev ML, Comment

This seems like a classic example of Chesterton's Fence.

Yup.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Shane-XB-Qian

unread,

Jan 19, 2025, 12:41:23 PMJan 19

to vim/vim, vim-dev ML, Comment

:smile:

--
shane.xb.qian

________________________________
From: chdiza ***@***.***>
Sent: Monday, January 20, 2025 12:49:38 AM
To: vim/vim ***@***.***>
Cc: Shane-XB-Qian ***@***.***>; Comment ***@***.***>
Subject: Re: [vim/vim] runtime(filetype): set bash scripts to bash filetype (PR #16309)

This seems like a classic example of Chesterton's Fence.

Yup.

—

Reply to this email directly, view it on GitHub<https://github.com/vim/vim/pull/16309#issuecomment-2600939133>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADHMHQMXQND5ITEK4MNGWV32LPJR7AVCNFSM6AAAAABUHXKR7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBQHEZTSMJTGM>.
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.

Christian Brabandt

unread,

Jan 19, 2025, 4:28:42 PMJan 19

to vim/vim, vim-dev ML, Comment

This seems like a classic example of Chesterton's Fence.

May you explain that to me like I am 5? I am not sure I understand what you are tryin to say.

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

D. Ben Knoble

unread,

Jan 19, 2025, 5:06:56 PMJan 19

to vim/vim, vim-dev ML, Comment

This seems like a classic example of Chesterton's Fence.

May you explain that to me like I am 5? I am not sure I understand what you are tryin to say.

Quoting the linked article:

There exists […] let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."

In other words, only when all the tradeoffs of the change and when all the implications of the current situation are accounted for can we really say what's best.

"All" is intentionally hyperbolic: certainly not plausible for every single change. The reach of the change should inform the completeness of the due diligence, probably.

In other words, the more likely there is some impact, the more cautiously and informed we should probably tread.

(This particular change did not seem to account for "why is it like this" and "what else might be affected," so I imagine it felt hasty to myself and others. I hope we can all learn something about the nature of widely-used projects :) I certainly don't mean to imply anybody did anything wrong. Just that I might have made decisions differently, or that I wish other perspectives had weighed in.)

Feedback welcome; it has been difficult to put my sentiments into words around this in ways that are uplifting.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.

Christian Brabandt

unread,

Jan 19, 2025, 5:31:59 PMJan 19

to vim/vim, vim-dev ML, Comment

The problem is, it is not always entirely obvious how likely the impact of a change is. I still believe, it makes sense to handle bash as a separate filetype, after all, that's what a filetype is for. Yes I know bash is kind of a superset of sh, but that doesn't mean it shouldn't be a separate filetype.

However, I didn't expect this backlash and often we will notice such impacts only once a change is merged into master. It can sit around in the pull-request and we wouldn't notice the impact until is has been merged, no matter how-long we carefully think about a change. So it is hard to estimate if a change is causing trouble or not. I do usually think about such changes before merging, but my conclusion may not always be the same as yours or other users, so it's hard to make the right decision here.

In any case, I am trying to not cause any backwards incompatibility and while still allowing for some way to move on forward. But sometimes we may have to try things out and revert it if it causes issues. That's all what I can say to this.

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

Shane-XB-Qian

unread,

Jan 19, 2025, 10:39:53 PMJan 19

to vim/vim, vim-dev ML, Comment

let me try to help to answer:
(sorry jumping in I have tried to reduce joining)
I think you are skilled and experienced, but
the problem is your personal preference is stronger than (or you thought others personally against you) that actually was vim's classic mission or admitted truth, which that we or your _role_ actually should be fully insist, for example to us official vim's backwards complitable commit or its unique license etc is higher priority than someone from neovim's demand.

--
shane.xb.qian

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Luca Saccarola

unread,

Jan 20, 2025, 2:25:28 AMJan 20

to vim/vim, vim-dev ML, Comment

I think you are skilled and experienced, but
the problem is your personal preference is stronger than (or you thought others personally against you) that actually was vim's classic mission or admitted truth

What does that even mean? Listen, I'm tired of you and your not really thought through arguments. Bram had personal preferences himself and a lot of what you are proclaiming as gospel is simply his personal preference.

I will reiterate WE ARE VOLUNTEERS. We work for free. Chris had to step up and start doing a lot more work and spend a lot of time, that maybe he would have spent in other ways, in managing changes and merging patches. Do you have an idea of the mental energy to do that? Do you understand that every stupid comments you make drains that finite energy? TBH if was Chris I would have ban you from the repo a long time ago but he so kind that wants to here you out Even though you are beening so freaking annoying.

To quote Chris in the other discussion #16368 (comment):

I am sorry, but you seem to really discourage working on and improving Vim. You are free to disagree but please don't try to cause frustration

I don't know where it has found the patience to respond to you like that but you are beening really annoying and really unreasonable to talk to.

So the lessons I would like you to learn are:

Think at least 10 times before commenting something because there are other people behind that screen that would like to do 1000 other things that read you stupid comments
Instead of talking DO actual work. You are not good with English but you can talk with patches instead...

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Shane-XB-Qian

unread,

Jan 20, 2025, 2:38:03 AMJan 20

to vim/vim, vim-dev ML, Comment

> So the lessons I would like you to learn are:

> 1. Think at least 10 times before commenting something because there are other people behind that screen that would like to do 1000 other things that read you stupid comments
> 2. Instead of talking DO actual work. You are not good with English but you can talk with patches instead...

thanks, but shut up your mouth, i donot like to listen your "stupid" comment too;
i am a contributor of netrw and vim too, i have right to comment, donot silly think you did wounderful job but actually broken so much;
and take your stupid English, either, i am chinese.

--
shane.xb.qian

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Luca Saccarola

unread,

Jan 20, 2025, 2:56:00 AMJan 20

to vim/vim, vim-dev ML, Comment

On January 20, 2025 8:37:54 AM GMT+01:00,

>and take your stupid English, either, i am chinese.

FWIW I'm italian and a lot of people in this repo don't have english as their first language. It's not done with malice or prejudice but if more that one people is telling you they find difficult to understand you... Put 2 and 2 toghether...

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Shane-XB-Qian

unread,

Jan 20, 2025, 3:03:41 AMJan 20

to vim/vim, vim-dev ML, Comment

> >and take your stupid English, either, i am chinese.
>
> FWIW I'm italian and a lot of people in this repo don't have english as their first language.

Yup, that's what i mean, donot silly think others think you did well-skilled and vim-style job, or speak wonderful English either.
People behind with Patient to see/endure your broken, but just i directly said it online.

--
shane.xb.qian

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

D. Ben Knoble

unread,

Jan 20, 2025, 8:13:06 AMJan 20

to vim/vim, vim-dev ML, Comment

@chrisbra well, this has certainly gone in the opposite direction of what I hoped for in my reply (and thank you for your thoughtful reply). Perhaps we lock this thread for a while to give folks time to cool off ?