While trying out vim, I noticed that the files in Misc/Vim are very poor compared to what is otherwise provided by the vim community:
- highlighting including 3.x syntax: http://www.vim.org/scripts/script.php?script_id=974
- PEP 8 indentation: http://www.vim.org/scripts/script.php?script_id=974

Also, the vimrc uses "au BufRead,BufNewFile *.py" style selection, while the recommended modern style seems to use a ".vim/ftplugin" filetype-specific file instead.

Does it still make sense to maintain these files separately?

So the irony of saying that the files are poor is that I took that code from the highlight file from Vim itself and simply automated the creation of the files.

As for the more proper way of selecting when to apply the highlights, I would not be surprised that I am wrong.

The entire point of the Misc/Vim directory was so that we had files which were as up-to-date as svn is. I personally got tired of not having new keywords be recognized. I'm no Vim expert -- just a happy user -- so I'm sure there could be better out there. If we drop the files we will just have to go back to manually editing files to support new syntax until the community picks it up. But maybe devolving responsibility like that is not a bad thing.

And your link for the Python 3 syntax is incorrect; it's the same as the PEP 8 indentation file.

Those files are useful for me, even if I had to tweak them slightly.

So I just looked at the syntax file linked by Antoine and that is definitely *not* what he meant to link to; probably meant http://www.vim.org/scripts/script.php?script_id=790 . As for the indentation file, it's out-of-date and so doesn't support 'with' statements (looks like people have already started to fork it: http://www.vim.org/scripts/script.php?script_id=3003).

At this point I'm willing to either hand maintenance of the files over to someone else or to delete the files and shift what we point people at.

On Sun, Dec 12, 2010 at 09:52:27PM +0000, Brett Cannon wrote:
> At this point I'm willing to either hand maintenance of the files
> over to someone else or to delete the files and shift what we point
> people at.

I think, just pointing to the script at vim.org location is a good
idea. It is maintained and updated by vimmers and we dont have to
bother about it. But a README would be helpful as what scripts we
"recommend", so that it sufficient to meet the style guidelines of
PEP8 and PEP7.

“It is maintained and updated by vimmers and we dont have to bother about it” is trumped by “I personally got tired of not having new keywords be recognized”.

But if you have a local copy of the Vim files from the community what is preventing you from editing them for new keywords and sending a patch to the maintainer so that the rest of the community is brought up to speed that much faster?

I suspect that not many people beyond core devs use the Misc/Vim file while more people in the community use the vim.org files.

On Mon, Dec 27, 2010 at 07:59:46PM +0000, Brett Cannon wrote:

> But if you have a local copy of the Vim files from the community
> what is preventing you from editing them for new keywords and
> sending a patch to the maintainer so that the rest of the community
> is brought up to speed that much faster?

You mean the Python Core Dev maintaining a set of Vim files as a fork
from the vim.org maintained files and adding new features when they
come up and be submitted the vim.org.

If that is the idea, it is indeed a good one.

But often it has happened that someone at the vim.org has noticed the
changes in Python and updated the files and the scripts at vim.org
remain updated.

> I suspect that not many people beyond core devs use the Misc/Vim
> file while more people in the community use the vim.org files.

Possibly and perhaps that is reason to discard our Misc/Vim in favor
of vim.org files.

But if you think there *should* be an official recommendation, some
pointers would definitely serve.

Alright, let me change my opinion: Let’s replace the Vim files by a README.vim file explaining where to get good helper files (like Misc/README.emacs added in r85927).  Then I will learn how to manage my Vim configuration to keep it updated (and adequate for each Python version), and when needed contact the Vim community to request updates.

OK, I like Eric's idea of the README.vim file explaining where to grab the community-maintained files and how to get set up. Anyone care to take a stab at writing the file?

Here is a first pass at the README.vim file. Suggestions welcome from VIM power-users!

> To download the current release of python.vim, which is an enhanced
> version of the python syntax highlighting script that conforms with
> PEP 8, and is actively maintained by the Vim community.
s/python/Python/

I think the bit about “enhanced version” could be puzzling.  Either say “an enhanced version of the python.vim file that used to be included in the Python repository”, or just delete that part (my preference).

> To update your .vimrc configuration file with Python-appropriate
> settings, use the sample file from Misc/Vim/vimrc.
The idea is to delete all of Misc/Vim.

> More comprehensive integration of Vim with Python tools and
> frameworks can be found at:
>
>    http://sontek.net/turning-vim-into-a-modern-python-ide
I’m not sure we want to add links to specific articles; for example, I had to combine tips from many websites/blogs to have an efficient setup.  I suggest our README.vim only points to wim.org pages, and other links can be added to the Vim wikis.

Files removed in 7e37a6c76e36.

Did you decide against including README.vim after all or just forgot that part?

I decided against it. If Emacs doesn't already have one I figured Vim shouldn't either.

I had forgotten that README.Emacs was moved to the devguide.  Adding doc about Vim support can be another bug report.  Thanks.

The files weres indeed removed but Misc/Readme was not updated accordingly. The last line needs to be removed.

New changeset afd17a514117 by Brett Cannon in branch 'default':
Issue #9893: remove an outdated mention of the Vim-related files.
http://hg.python.org/cpython/rev/afd17a514117

Thanks for the info, Févry.