Is it a good practice to setlocal bomb in ftplugin?
Maxim Kim
I have a (ft)plugin that overrides filetype of .wiki extension from
flexwiki to vimwiki. Everything seems quite good except for a state of
just opened buffer that is in 'changed' one.
As far as I can see FlexWiki ftplugin does :setlocal bomb command that
puts vim's buffer in a 'changed' state.
As a workaround I suggest vimwiki users to delete a line from
filetype.vim or use another file extension for vimwiki's files.
It looks like this is the only standard ftplugin that sets bomb on
it's files.
But anyway, shouldn't vim revert setlocal stuff?
I can see:
let b:undo_ftplugin = "setl tw< wrap< lbr< et< ts< fenc< bomb< ff<"
in flexwiki.vim and it doesn't work for bomb.
PS
To test it:
:e ~/aaa.wiki
:w
:set ft=html
:q
E37: No write since last change ...
Tony Mechelynck
Personally, I use "setglobal bomb" in my ~/.vimrc. Not sure if it's
"good practice", but when it gives me a problem I'll manually use either
":setlocal nobomb" or ":setlocal fenc=latin1" (depending on
circumstances) on the problematic file.
I don't think ftplugins should change the 'bomb' status of existing
files; however... I've noticed that the shebang on the first line of
executable scripts is not recognized if there is a bomb, so maybe I
ought to add a ~/.vim/after/ftplugin/sh.vim with the line
setlocal fenc=latin1 nomod
in it.
E37 is normal if you try to |abandon| a 'modified' file, and changing
'fenc' and/or 'bomb' and/or 'ff' also sets 'modified' because any of
those changes alters the disk representation of the file. In that case,
use ":x" (or ":wq") instead of ":q" and Vim will save the file before
closing its window.
Note that altering any of these three options in an undo_ftplugin line
is courting disaster: Vim has a separate mechanism to detect these
options' values when opening an existing file, and the results are
usually correct; for new files, you might have set them manually to
something else than the global default, and if I did that I would expect
Vim to respect my choice even if I later change the filetype.
Best regards,
Tony.
--
"I used to get high on life but lately I've built up a resistance."
Maxim Kim
On 16 мар, 16:20, Tony Mechelynck <antoine.mechely...@gmail.com>
wrote:
> ...
> is courting disaster: Vim has a separate mechanism to detect these
> options' values when opening an existing file, and the results are
> usually correct; for new files, you might have set them manually to
> something else than the global default, and if I did that I would expect
> Vim to respect my choice even if I later change the filetype.
let b:undo_ftplugin = "setl bomb<"
setlocal bomb
in ftplugin, should him?
Tony Mechelynck
IMHO, ftplugins should normally leave that option well enough alone,
except maybe in exceptional cases, which would then deserve a comment in
the ftplugin script and/or a prominent paragraph in the help section for
that filetype (probably in the |ftplugin-docs| section of
$VIMRUNTIME/doc/filetype.txt for ftplugins distributed with Vim, or in
some adhoc helpfile for other ones).
If you're convinced that some ftplugin improperly sets 'bomb' (or that
it includes some other bug which you think you know how to fix), what
you can do is:
1. Make sure you have the latest runtime files and check that the bug is
still there. (If it isn't, you're done.)
2. If that ftplugin is distributed with Vim, copy it to
$VIM/vimfiles/ftplugin/ (creating directories if necessary).
3. Make the changes there. (You should never modify anything in the
$VIMRUNTIME directory tree, because any upgrade may silently wipe out
your changes.)
4. (If possible) send a context diff of your changes to the plugin
maintainer, explaining why you believe they were necessary.
If the plugin is "well-written" (and includes at the start something like
if exists('did_ftplugin')
finish
endif
let did_ftplugin = 1
), step 1 above will make the copy override the original, which will
then quit without doing anything.
Best regards,
Tony.
--
System administrators are just like women: You can't live with them and
you can't live without them.
pansz
>
> Personally, I use "setglobal bomb" in my ~/.vimrc. Not sure if it's
> "good practice",
As far as I know gcc will not compile any file with a utf-8 bomb. so I
don't think :setglobal bomb is a good practice unless you never use gcc
to compile your C source code.
Please correct me if I'm wrong.
bill lam
I guess under linux if you choose utf-8 in locale, everything should
already assume to be utf8. And I don't think any command tools (such
as head sort) will generate bomb on output or expect bomb in
stdin/stdout. That being said, I guess utf-8 bomb would be more
relevant in windows because it has no utf-8 locale. Personally I do
not use utf-8 bomb unless for files that are intended to be opened
with notepad.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩250 李頻 渡漢江
嶺外音書絕 經冬復立春 近鄉情更怯 不敢問來人
pansz
> I guess under linux if you choose utf-8 in locale, everything should
> already assume to be utf8. And I don't think any command tools (such
> as head sort) will generate bomb on output or expect bomb in
> stdin/stdout. That being said, I guess utf-8 bomb would be more
> relevant in windows because it has no utf-8 locale. Personally I do
> not use utf-8 bomb unless for files that are intended to be opened
> with notepad.
I've done a short experiment which shows that gcc will fail at bomb
regardless of locale, seems that this issue is not locale related, and
is not utf-8 specific, ucs2 and utf16 also suffers.
One of the most important use of Vim is to write programs, so if the
most widely used compiler gcc complains about the bomb we certainly
should *not* globally enable bomb in vim.
My argument is against globally enable bomb in vim.
Tony Mechelynck
I don't write C programs, and if I did they would probably be in Latin1
'fileencoding' (where the 'bomb' status is irrelevant).
The only C code that I compile is Vim; I often view it in Vim, I rarely
modify it in Vim, I never (so far) wrote a new module. So my ":setglobal
bomb" is irrelevant, what comes into play is my ":set
fencs=ucs-bom,utf-8,latin1" which clears 'bomb' locally when reading an
existing file which has no BOM.
Best regards,
Tony.
--
A mathematician named Hall
Has a hexahedronical ball,
And the cube of its weight
Times his pecker's, plus eight
Is his phone number -- give him a call..
Matt Wozniski
>
> On 17/03/09 02:01, pansz wrote:
>>
>> Tony Mechelynck 写道:
>>>
>>> Personally, I use "setglobal bomb" in my ~/.vimrc. Not sure if it's
>>> "good practice",
>>
>> As far as I know gcc will not compile any file with a utf-8 bomb. so I
>> don't think :setglobal bomb is a good practice unless you never use gcc
>> to compile your C source code.
>>
>> Please correct me if I'm wrong.
>
> I don't write C programs, and if I did they would probably be in Latin1
> 'fileencoding' (where the 'bomb' status is irrelevant).
But regardless, I think it's pretty easy to see that a :setlocal bomb
in an ftplugin is almost certainly a bad idea, and that :setglobal
bomb in ~/.vimrc is *definitely* a bad idea.
~Matt
Tony Mechelynck
In an ftplugin, probably, since those are usually meant to be used by
various users with various editing habits.
In a vimrc, I don't agree, because a vimrc is essentially personal: a
different user will have a different vimrc. In my case, practically all
the files I create in Vim are of one of the following kinds:
(a) Latin1 files (where Vim won't write a BOM regardless of the 'bomb'
setting);
(b) UTF-8 text files which will perhaps be printed by my browser, since
multibyte support in ":hardcopy" is less than satisfactory -- in
particular, I haven't yet succeeded to print, in Vim, a file containing
mostly French text but with one Hebrew word in the Hebrew alphabet.
Gecko does it flawlessly.
(c) HTML pages: those that are in UTF-8 also have <meta
http-equiv="Content-Type" content="text/html; charset=utf-8" /> in the
<head> part but, depending where I store them (locally or on which
server), the latter is not always enough.
Files in categories (b) and (c) are shared between Vim and SeaMonkey,
and the presence of a BOM ensures correct encoding detection by both Vim
and the browser (also by the server if uploaded and by the mailer if
sent as attachment) in all cases.
Best regards,
Tony.
--
The verdict of a jury is the a priori opinion of that juror who smokes
the worst cigars.
-- H. L. Mencken