Where to submit patches for runtime files

[Tim Lee]

Where should I submit patches for runtime files? Is it to the runtime
file's maintainer, or can I make a pull request to Vim on GitHub?

According to the contributing instructions for runtime files
(https://github.com/vim/vim/blob/master/CONTRIBUTING.md#syntax-indent-and-other-runtime-files):

> If you find a problem with one of these files or have a suggestion for
improvement, please first try to contact the maintainer directly.

Could you clarify what is meant by "suggestion for improvement"? Does
"suggestion for improvement" include patches, or does it only mean
"feature requests"?

[Tony Mechelynck]

1. Where to submit patches.

As is often the case with Vim, the answer is not unique. One possible
place is the vim_dev list, preferably as a "context" or "unified" diff
sent as attachment to an email message (with explanations in the
message text about which problem the patch is supposed to fix).
Another possible place is as pull-request on the Vim github site. For
runtime files which have a maintainer, the maintainer MUST be made
aware of anything you write about his (or her) package, either by
writing directly to him/her, or by adding them on the To or Cc line of
a message sent (also) to the vim_dev list.

In any case, each submitted patch should fix one single problem: if
you think you can fix two different problems, please submit two
different patches.

2. What is a "suggestion for improvement"?

There is no sharp separation between a minor bug and a request for
improvement. You could say that an RFI is what you write when the
present behaviour of the software is not faulty, but could be made
better by means of a minor improvement. However what one user regards
as a "Vim quirk" with which, after getting used to it, one can live,
will be felt by another user as a minor but annoying bug. Always check
the documentation (i.e. Vim's built-in help) however: if some
behaviour is documented, then it is a feature, not a bug.

It is always better to submit a patch with an RFI, it helps it go
forward; but it is not an absolute requirement. If you look at ":help
todo.txt", you will find a huge number of RFIs with no patches; some
of them have been there tens of years for lack of someone both capable
and willing to program and test the necessary change.


Best regards,
Tony.