[vim/vim] Is it possible to execute commands after filetype detection and plugins are done? (Discussion #16760)
David Mandelberg
I currently set textwidth=80 in my vimrc because I want that to be the default if there's nothing filetype-specific. But some ftplugins won't set textwidth after that line in my vimrc, e.g.:
I'm currently just adding lines like setlocal textwidth=72 to my ~/.vim/ftplugin/mail.vim to get the per-filetype defaults, but it would be nice to not need to do that for every filetype that sets textwidth in that way. Is there any way to leave textwidth at 0 initially, but set it to 80 after ftplugins are run if it's still 0 and hasn't been explicitly set to 0 by the ftplugin? I was thinking of using the FileType event, but that doesn't seem to trigger for buffers with no filetype, which does make sense.
If that's not possible, would it make sense to add a new option like g:prefer_filetype_textwidth so that mail.vim and similar ftplugins could do this instead?
if &tw == 0 || g:prefer_filetype_textwidth setlocal tw=72 endif
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Gary Johnson
> I currently set textwidth=80 in my vimrc because I want that to be the default
> if there's nothing filetype-specific. But some ftplugins won't set textwidth
> after that line in my vimrc, e.g.:
>
> https://github.com/vim/vim/blob/56957ed4109fb0c37922c6c37d5926cfe0a3313b/
> runtime/ftplugin/mail.vim#L20-L22
>
> I'm currently just adding lines like setlocal textwidth=72 to my ~/.vim/
> ftplugin/mail.vim to get the per-filetype defaults, but it would be nice to not
> need to do that for every filetype that sets textwidth in that way. Is there
> any way to leave textwidth at 0 initially, but set it to 80 after ftplugins are
> run if it's still 0 and hasn't been explicitly set to 0 by the ftplugin? I was
> thinking of using the FileType event, but that doesn't seem to trigger for
> buffers with no filetype, which does make sense.
>
> If that's not possible, would it make sense to add a new option like
> g:prefer_filetype_textwidth so that mail.vim and similar ftplugins could do
> this instead?
>
> if &tw == 0 || g:prefer_filetype_textwidth
> setlocal tw=72
> endif
set the 'o' in 'format options:
autocmd FileType * setlocal formatoptions-=o
I put this in my vimrc _after_
filetype plugin indent on
so that it is executed after all the filetype plugins.
You could something like this (untested):
set tw=80
autocmd FileType * if &l:tw != 0 | setl tw=80 | endif
I don't think you need to care that this is not executed for buffers
with no file type because no filetype plugins will be sourced for
them, either.
Regards,
Gary
vim-dev ML
> if there's nothing filetype-specific. But some ftplugins won't set textwidth
> after that line in my vimrc, e.g.:
>
> https://github.com/vim/vim/blob/56957ed4109fb0c37922c6c37d5926cfe0a3313b/
> runtime/ftplugin/mail.vim#L20-L22
>
> I'm currently just adding lines like setlocal textwidth=72 to my ~/.vim/
> ftplugin/mail.vim to get the per-filetype defaults, but it would be nice to not
> need to do that for every filetype that sets textwidth in that way. Is there
> any way to leave textwidth at 0 initially, but set it to 80 after ftplugins are
> run if it's still 0 and hasn't been explicitly set to 0 by the ftplugin? I was
> thinking of using the FileType event, but that doesn't seem to trigger for
> buffers with no filetype, which does make sense.
>
> If that's not possible, would it make sense to add a new option like
> g:prefer_filetype_textwidth so that mail.vim and similar ftplugins could do
> this instead?
>
> if &tw == 0 || g:prefer_filetype_textwidth
> setlocal tw=72
> endif
set the 'o' in 'format options:
autocmd FileType * setlocal formatoptions-=o
I put this in my vimrc _after_
filetype plugin indent on
so that it is executed after all the filetype plugins.
You could something like this (untested):
set tw=80
autocmd FileType * if &l:tw != 0 | setl tw=80 | endif
I don't think you need to care that this is not executed for buffers
with no file type because no filetype plugins will be sourced for
them, either.
Regards,
Gary
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
David Mandelberg
That does the opposite of what I want. That would make my preference for 80-by-default override the filetype plugins, but I want the filetype plugins to override my preference.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Gary Johnson
> 80-by-default override the filetype plugins, but I want the filetype plugins to
> override my preference.
'textwidth' to any value, including 0, it gets trickier.
In fact, I thought I had a solution with a combination of
BufNewFile, OptionSet and BufWinEnter autocommands, but I can't get
an OptionSet autocommand to respond when the mail.vim ftplugin sets
'textwidth'. I know that autocommands are inhibited during startup,
but the OptionSet autocommand seems to be inhibited during ftplugin
loading as well.
Upon the BufWinEnter event, you could parse the output of ":verbose
set tw?" to see if any plugin set it, but that's more work than
I have time for at the moment.
Regards,
Gary
vim-dev ML
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
David Mandelberg
Yeah, it's not worth a lot of work in my personal configs for this. There are only a handful of files that do it, and I've already added overrides for each one.
$ grep -r 'if.*&\(tw\|textwidth\)' -- runtime/ftplugin/
runtime/ftplugin/changelog.vim: if &textwidth == 0
runtime/ftplugin/mail.vim:if &tw == 0
runtime/ftplugin/vim.vim:if &tw == 0
runtime/ftplugin/hamster.vim:if &tw == 0
runtime/ftplugin/verilog.vim:if &textwidth == 0
If this is something other people want, then I think changing each of those to something like if &tw == 0 || g:prefer_filetype_textwidth would be the simplest option. If I'm the only one who cares, then I'll keep overriding it for those filetypes in my dotfiles.
(I only started looking into this in the first place because I've been trying to go through my dotfiles and contribute anything upstream that would be useful to other people. With the side benefit of getting rid of code from my dotfiles after upstreaming it.)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.