Search code examples
vimmacos-sierravim-plugin

Vim's 'dot-separated' double filetype fashion


I'm happily loading either Notes and Txtfmt plugins in neovim, command line version, on Mac Os Sierra.

Both greatly working on their own, but no chance to have 'em loading together in a file of filetype notes.txtfmt as per Vim documentation about dot-separated filetypes.

First attempt I made was following Notes documentation to be able to work together with Txtfmt and creating the file

$/.vim/after/ftplugin/notes.vim

with the content:

" Enable Txtfmt formatting inside notes.
setlocal filetype=notes.txtfmt

As stated in this discussion this approach does not work, creating an infinite loop. Next, as suggested by bpstahlman in the mentioned post, I added to my .vimrc the following autocommand:

augroup TxtfmtInNotes
au!
au FileType * if expand("<amatch>") == "notes" | setlocalft=notes.txtfmt|endif
augroup END

Now, it seemed that could be working, in that it declares a 'notes.txtfmt' filetype in Vim status bar, immediately after opening a new :Note buffer.
The bad news: txtfmt plugin does not load, no mapped command is working.

The funny: doing again :setlocal ft=notes.txtfmt (which is supposed to have already been done by the suggested autocommand) everything gets properly loaded.

In other words it looks like in my case the autocommand works in changing filetype but not in loading the txtfmt plugin, which is loaded only repeating the filetype command.

Any suggestion on this?

Thanks


Solution

  • If the Notes plugin had a filetype detection (apparently it hasn't, and the filetype is only set by the commands the plugin provides), I would overwrite that to

    :au BufNewFile,BufRead *.note setf notes.txtfmt
    

    In your case, instead of using a compound filetype, I would simply emulate its effects in ~/.vim/after/ftplugin/notes.vim:

    runtime! ftplugin/txtfmt.vim ftplugin/txtfmt_*.vim ftplugin/txtfmt/*.vim
    

    I haven't tested it, but it's more straightforward and therefore hopefully more robust than your current solution of hooking into the FileType event.