autowriteall set by vimwiki

[GoogleCodeExporter]

For some reason vimwiki plugin sets the option 'autowriteall' on file 
ftplugin/vimwiki.vim, at line 22:

    setlocal autowriteall

This option is global, so it changes all buffers despite it uses setlocal.

It is not clear why this option is set. If it is necessary for some reason, it 
would be useful to have a plugin option to control this behavior. It would 
prevent users that doesn't like 'autowriteall' from editing the file to comment 
out that line.

Original issue reported on code.google.com by marcmo...@gmail.com on 14 Sep 2012 at 7:13

[GoogleCodeExporter]

My understanding is that in order to enable navigation between wiki files via 
wiki-links, the easiest, safest and most convenient thing to do is to 
automatically save the file.  

Notice that this setting does not apply to non-vimwiki files.  If this setting 
is affecting all of your files, then I believe there is an error somewhere; 
that type of greedy option setting is unnecessary and _would_ be annoying, I 
agree.

Personally, I find autowriteall incredibly helpful within vimwiki.  Although, I 
am curious as to why this behavior is not appreciated ...

Original comment by stu.andrews on 31 Dec 2012 at 3:37

[GoogleCodeExporter]

Ha!  I was wrong on a few counts:

1. It turns out the autowriteall options does apply to all filetypes.  (Can 
someone please confirm this behavior?)
2. Since autowriteall applies to all filetypes, then, apparently, it doesn't 
annoy me after all.  In fact, I didn't even notice it.  

Why is this behavior not appreciated?  Apart from preventing accidental changes 
slipping into a file, turning off autowriteall would only cause me to type 
":w<enter>" incessantly.

Arguably, it's dissatisfying to have a plugin change a global setting; vimwiki 
would not be the first.

Original comment by stu.andrews on 31 Dec 2012 at 3:56

• Changed state: Accepted

[GoogleCodeExporter]

1. Someone can confirm this behavior as you asked, but since autowriteall is a 
global option (as stated by :h autowriteall) and it is easy to see that plugin 
code has no noautowriteall nor noaw, and as presence of "autowriteall< " in 
b:undo_ftplugin has no effect (as it resets the variable to is global value), I 
wonder how do you expect that autowriteall would apply only to wiki files.
2. That is probably because you enjoyed this option, thus there are great 
chances that it were already set autowriteall on your .vimrc.

One of the main reasons that I do not appreciate this behavior is exactly 
accidental changes, as you pointed out. And personally I prefer to use some 
mapping as <c-s> :update<cr> to write the file, along with :update command 
included in several mappings where it seems appropriated.

Apart from that, if it should be set at all times, it probably wouldn't be made 
as a Vim option. Also notice that this it is off by default, so many users may 
not be aware of this behavior.

If you feel that autowriteall should be enabled on wiki files, I believe it 
should be done only for this filetype 
(http://stevelosh.com/blog/2011/09/writing-vim-plugins/#localize-mappings-and-se
ttings). Maybe this could be achieved by setting some autocmds if the plugins 
detects that autowriteall is off.

Anyway, I'm glad that you share and maintain this great plugin!
It is not hard to open and comment out this options from plugin code; this was 
just an attempt of making an small improvement on it.

Happy New Year!

Original comment by marcmo...@gmail.com on 1 Jan 2013 at 2:56

[GoogleCodeExporter]

Thanks for these details, suggestions and the link ... I will refer this to the 
original author, Maxim.

The autocmd solution involves keeping track of the global autosaveall status, 
and reinstating that value whenever you leave a vimwiki file ... right?

Original comment by stu.andrews on 2 Jan 2013 at 3:06

[GoogleCodeExporter]

Right, probably it would localize the autowriteall to wiki buffers.

Original comment by marcmo...@gmail.com on 2 Jan 2013 at 10:34

[GoogleCodeExporter]

Original comment by habamax on 19 Mar 2013 at 3:48

• Changed state: FixedNeedMoreTest

[GoogleCodeExporter]

Maybe I am missing something, but this new version seems equivalent to 
commenting the line with "setlocal autowriteall" in the previous version.

In version 1331ddb92209 
(http://code.google.com/p/vimwiki/source/detail?r=1331ddb92209f55e91d9c6a62a754e
f5f306a366), without setting g:vimwiki_autowriteall it indeed gets the default 
value of '1', but all files (vimwiki and regular) remains with noautowriteall. 
Executing "let g:vimwiki_autowriteall=0" doesn't changed the behavior, and all 
the files remained with noautowriteall.

This differs from what is stated in the new documentation:

*g:vimwiki_autowriteall*

In vim |autowriteall| is a global setting. With g:vimwiki_autowriteall vimwiki
makes it local to its buffers.

Original comment by marcmo...@gmail.com on 21 Mar 2013 at 8:30

[GoogleCodeExporter]

1. in your vimrc make sure you don't have 'set hidden' and 'set autowriteall'
2. open vimwiki index
3. :split asdf.txt
4. make changes in asdf.txt
5. make changes in index.wiki

Now you have 2 windows with changed buffers
6. while in asdf.txt run :e qwer.txt --> it shouts error
7. switch to index.wiki window and follow any link --> index.wiki is saved and 
new link is opened.

It works for me that way...

Original comment by habamax on 22 Mar 2013 at 5:28

[GoogleCodeExporter]

I've followed your instructions, but on step 7 index.wiki also shouts an error.

Then I tried to test it on a fresh installation of gVim (Version 7.3 on 
Ms-Windows, downloaded from vim.org), with vimfiles directory (windows 
equivalent to .vim) containing only vimwiki plugin files and _vimrc (equivalent 
of .vimrc) containing only 

set nocompatible
filetype plugin on
syntax on

Following the steps you listed leads to same results that I got with my default 
setup, i.e, on step 7 index.wiki also shouts an error.

Please let me know if there are additional tests to perform.
And thanks for sharing this awesome plugin!

Original comment by marcmo...@gmail.com on 22 Mar 2013 at 12:07

[GoogleCodeExporter]

Hmm, it sometimes works, sometimes don't.

Original comment by habamax on 22 Mar 2013 at 5:04

• Changed state: Started

[GoogleCodeExporter]

Could you try it again?

Original comment by habamax on 22 Mar 2013 at 6:00

• Changed state: FixedNeedMoreTest

[GoogleCodeExporter]

Yes, it works now!

But I've made some tests on a clean installation and there is a situation where 
it fails, giving the following message:

Error detected while processing function 
vimwiki#base#follow_link..vimwiki#base#open_link..vimwiki#base#edit_file:
line   12:
E37: No write since last change (add ! to override)

But after the index is saved with `:w` it doesn't fails anymore.
And if steps 4 and 6 are skipped, i.e, no split and no changes on non-wiki 
file, everything works fine.

Original comment by marcmo...@gmail.com on 23 Mar 2013 at 2:23

[GoogleCodeExporter]

I have tested it for a while and I can see it doesn't 100% local to vimwiki 
files.

We need a better solution. 

Original comment by habamax on 14 Apr 2013 at 1:26