search

gregsexton / MatchTag

Vim's MatchParen for HTML tags
http://www.vim.org/scripts/script.php?script_id=3818
311 stars 30 forks source link

Rename the scripts, as they are not core ftplugins. #14

Closed inkarkat closed 11 years ago

inkarkat commented 11 years ago

Your useful plugin does not provide core ftplugin functionality (like setting 'iskeyword', 'wrap', etc.), but rather ancilliary functionality. Therefore, it should be renamed to html_matchtag.vim (and xml_matchtag.vim), and this guard dropped:

if exists("b:did_ftplugin")
    finish
endif

Otherwise, this prevents the default $VIMRUNTIME/ftplugin/html.vim from becoming effective.

gregsexton commented 11 years ago

No it shouldn't. I don't set b:did_ftplugin I just check for it. If you have more than one html ftplugin in your user directory then you can create a subdirectory and rename as you like. e.g. ~/.vim/ftplugin/html/matchtag.vim

inkarkat commented 11 years ago

My argument still holds. Whether you rename to ftplugin/html/matchtag.vim or ftplugin/html_matchtag.vim is irrelevant. But the ftplugin/html.vim should be reserved to hold the main settings for the filetype, not add-on functionality. Of course, this is just convention, but IMHO a good one.

In add-ons, you do not need to check for b:did_ftplugin; that is just so that a ftplugin in ~/.vim is able to override (again, the main filetype settings of) the system-wide one. With this check in place, your plugin must be sourced before the system-wide one, or else the guard is active. So, if I had a ~/.vim/ftplugin/html.vim override of the system-wide one (and renamed your plugin as you've just suggested), the guard would prevent your plugin from becoming active. As long as your plugin doesn't ship with Vim, there's no need to check the / have a guard; users who don't want this functionality simply don't install your plugin.