Does b:undo_ftplugin actually work?

[Gary Johnson]

I was working on some code that set b:undo_ftplugin, but it didn't
have any effect when I set a new filetype. I copied
$VIMRUNTIME/ftplugin.vim to ~/.vim and instrumented the section that
is supposed to execute b:undo_ftplugin.

func! s:LoadFTPlugin()
echo "In s:LoadFTPlugin()" | sleep 2
echo "b:undo_ftplugin is" b:undo_ftplugin | sleep 2
if exists("b:undo_ftplugin")
echo "b:undo_ftplugin exists" | sleep 2
exe b:undo_ftplugin
unlet! b:undo_ftplugin b:did_ftplugin
endif

Whenever I open a new file for which Vim can detect the filetype, or
:edit some file, I always get the following errors.

Error detected while processing function <SNR>5_LoadFTPlugin:
line 2:
E121: Undefined variable: b:undo_ftplugin
E15: Invalid expression: b:undo_ftplugin | sleep 2

That is even after I execute

:echo b:undo_ftplugin

and verify that it is set correctly according to the new filetype.

It seems that b:undo_ftplugin does not exist in the environment in
which s:LoadFTPlugin() is executed. Does setting b:undo_ftplugin as
most current ftplugin scripts do actually do anything?

I am running Vim 7.3.646 on Linux.

Regards,
Gary

[ZyX]

пятница, 28 сентября 2012 г., 8:04:05 UTC+4 пользователь Gary Johnson написал:

> I was working on some code that set b:undo_ftplugin, but it didn't
> have any effect when I set a new filetype. I copied
> $VIMRUNTIME/ftplugin.vim to ~/.vim and instrumented the section that
> is supposed to execute b:undo_ftplugin.
>
> func! s:LoadFTPlugin()
> echo "In s:LoadFTPlugin()" | sleep 2
> echo "b:undo_ftplugin is" b:undo_ftplugin | sleep 2

You should’ve put this line after the next one (or, better, remove it as absense of the next message will indicate absence of b:undo_ftplugin definition). And use “:echom”, not “:echo | sleep”, then all messages will be seen when you do “:messages”

> if exists("b:undo_ftplugin")
> echo "b:undo_ftplugin exists" | sleep 2
> exe b:undo_ftplugin
> unlet! b:undo_ftplugin b:did_ftplugin
> endif
>
> Whenever I open a new file for which Vim can detect the filetype, or
> :edit some file, I always get the following errors.

b:undo_ftplugin is defined in filetype plugins. What else do you expect? When opening new file and doing :edit buffer scope is clean and filetype plugins are loaded by s:LoadFTPlugin function *after* you test for b:undo_ftplugin. You should have used “set filetype=new_filetype” on *existing* buffer to trigger desired behavior.

> Error detected while processing function <SNR>5_LoadFTPlugin:
> line 2:
> E121: Undefined variable: b:undo_ftplugin
> E15: Invalid expression: b:undo_ftplugin | sleep 2
>
> That is even after I execute
>
> :echo b:undo_ftplugin
>
> and verify that it is set correctly according to the new filetype.

Don’t use :edit. It wipes the buffer.

> It seems that b:undo_ftplugin does not exist in the environment in
> which s:LoadFTPlugin() is executed. Does setting b:undo_ftplugin as
> most current ftplugin scripts do actually do anything?

They do. Use “set filetype=new_filetype”.

[Gary Johnson]

Thanks for the reply, but I see that I didn't explain the problem
very well. Also, some of my experiments created new buffers instead
of replacing the contents of existing buffers with new filetypes, so
I wasn't replicating the actual problem conditions.

Let me try again.

The actual problem is that I would like to set 'indentexpr' for
buffers with no 'filetype' so that I get indenting behavior that I
think might be useful when just opening Vim and typing notes. To
that end I put the following in my ~/.vimrc.

au BufWinEnter * if &ft == "" || &ft == "text"
\ | setlocal indentexpr=indent(prevnonblank(v:lnum-1))
\ | setlocal indentkeys-=o
\ | let b:undo_ftplugin = "setl inde< indk<"
\ | endif

When I start vim and execute

:echo b:undo_ftplugin

I see

setl inde< indk<

as expected. Further, ":ls" shows

1 %a "[No Name]" line 1

Now, if I open a C file, I expect to have 'indentexpr' empty, either
because the C file is opened in a new buffer or because the C file
was opened in the same buffer and the b:undo_ftplugin was executed.
However, after executing

:e foo.c
:set indentexpr?

I see

indentexpr=indent(prevnonblank(v:lnum-1))

and ":ls" shows

1 %a "foo.c" line 1

I did take your advice about using echom and instrumented
ftplugin.vim differently and verified that when it was executed by
the 'filetype' change to "c", b:undo_ftplugin did not exist.

If ":edit wipes the buffer" as you say, so that b:undo_ftplugin is
deleted, then shouldn't that wiping reset the values of any local
options?

I'm just looking for a way to reset those local options when I edit
a new file, b:undo_ftplugin seemed to be the way to do it, but it
doesn't seem to do anything useful.

Not using :edit is not a solution. For example, if I start vim
and use ":MRU" to open a recently-used C file, I wind up with
'indentexpr' set as above, which wrongly indents C.

Regards,
Gary

[Christian Brabandt]

Hi Gary!

Hi Gary,

Looks like the initial buffer isn't correctly freed.
Try this patch: which at least also gets rid of the buffer local
options, when loading another buffer:
diff --git a/src/buffer.c b/src/buffer.c
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -1702,6 +1702,12 @@
#endif
/* buf->b_nwindows = 0; why was this here? */
free_buffer_stuff(buf, FALSE); /* delete local variables et al. */
+ /* can't set TRUE in free_buffer_stuff(), this would destroy the wininfo stuff,
+ * so freeing the buffer options here afterwards manually */
+ free_buf_options(buf, TRUE);
+#ifdef FEAT_SPELL
+ ga_clear(&buf->b_s.b_langp);
+#endif
#ifdef FEAT_KEYMAP
/* need to reload lmaps and set b:keymap_name */
curbuf->b_kmap_state |= KEYMAP_INIT;

Although, this doesn't solve the problem, that the b:undo_ftplugin
option isn't executed on BufUnload event. Possibly we need a global
BufUnLoad event, that takes care of this, e.g. something like this:

" Make sure, the b:undo_ftplugin is also executed deleting the buffer
BufUnload * if exists("b:undo_ftplugin") | exe b:undo_ftplugin | endif

But I am not sure, where to put this script. Perhaps also put this into
ftplugin.vim?

regards,
Christian

[ZyX]

> " Make sure, the b:undo_ftplugin is also executed deleting the buffer
> BufUnload * if exists("b:undo_ftplugin") | exe b:undo_ftplugin | endif
>
> But I am not sure, where to put this script. Perhaps also put this into
> ftplugin.vim?

According to the documentation, BufUnload event may be triggered when current and unloaded buffers are different. And, according to the same doc, you must not change buffers on this event. Thus you must not put the above autocommand anywhere.

[ZyX]

> Thanks for the reply, but I see that I didn't explain the problem
> very well. Also, some of my experiments created new buffers instead
> of replacing the contents of existing buffers with new filetypes, so
> I wasn't replicating the actual problem conditions.
>
> Let me try again.
>
> The actual problem is that I would like to set 'indentexpr' for
> buffers with no 'filetype' so that I get indenting behavior that I
> think might be useful when just opening Vim and typing notes. To
> that end I put the following in my ~/.vimrc.
>
> au BufWinEnter * if &ft == "" || &ft == "text"
> \ | setlocal indentexpr=indent(prevnonblank(v:lnum-1))
> \ | setlocal indentkeys-=o
> \ | let b:undo_ftplugin = "setl inde< indk<"
> \ | endif

You can just set 'autoindent'. This option is ignored in most cases when using other ways to define indentation.

> When I start vim and execute
>
> :echo b:undo_ftplugin
>
> I see
>
> setl inde< indk<
>
> as expected. Further, ":ls" shows
>
> 1 %a "[No Name]" line 1
>
> Now, if I open a C file, I expect to have 'indentexpr' empty, either
> because the C file is opened in a new buffer or because the C file
> was opened in the same buffer and the b:undo_ftplugin was executed.
> However, after executing
>
> :e foo.c
> :set indentexpr?
>
> I see
>
> indentexpr=indent(prevnonblank(v:lnum-1))
>
> and ":ls" shows
>
> 1 %a "foo.c" line 1

Yes, for some reason empty buffers without edits are used to open a new file. You can get the same behavior after “:enew” then “edit bar.c”.

> I did take your advice about using echom and instrumented
> ftplugin.vim differently and verified that when it was executed by
> the 'filetype' change to "c", b:undo_ftplugin did not exist.
>
> If ":edit wipes the buffer" as you say, so that b:undo_ftplugin is
> deleted, then shouldn't that wiping reset the values of any local
> options?
>
> I'm just looking for a way to reset those local options when I edit
> a new file, b:undo_ftplugin seemed to be the way to do it, but it
> doesn't seem to do anything useful.
>
> Not using :edit is not a solution. For example, if I start vim
> and use ":MRU" to open a recently-used C file, I wind up with
> 'indentexpr' set as above, which wrongly indents C.

Unset 'indentoptions' on any filetype event, adding definition of needed autocommand somewhere at the beginning of the vimrc (as it is the first file sourced), definitely before “filetype plugin indent on” or similar command, it should not interfere with ftplugins then. Use 'autoindent' instead of your 'indentexpr', it is here just for that reason.

[Ben Fritz]

I wondered if using b:undo_indent worked any better, since arguably that is the correct method. But experimentation shows it doesn't work any better. I'm guessing from the patch later in the thread that the buffer-local variables are getting wiped out but not the buffer-local options.

[Christian Brabandt]

Hi ZyX!

On Fr, 28 Sep 2012, ZyX wrote:

>
> > " Make sure, the b:undo_ftplugin is also executed deleting the buffer
> > BufUnload * if exists("b:undo_ftplugin") | exe b:undo_ftplugin | endif
> >
> > But I am not sure, where to put this script. Perhaps also put this into
> > ftplugin.vim?

> According to the documentation, BufUnload event may be triggered when
> current and unloaded buffers are different. And, according to the same

It is not triggered when current and unloaded buffers are different, but
when it triggers, current buffer and buffer being unloaded might be
different. That is bufnr('%') can be different then "<afile>".

> doc, you must not change buffers on this event.

You should not move to another buffer and probably you shouldn't change
a buffer as well as this might cause problems. I don't see, how
resetting the actions being done by a filetype script might cause
problems in this case.

> Thus you must not put the above autocommand anywhere.

I disagree. The autocommand is there for a reason. Unsetting the effects
by a filetype plugin can be a reason to use this event.

regards,
Christian

[Christian Brabandt]

Hi ZyX!

On Fr, 28 Sep 2012, ZyX wrote:

> > When I start vim and execute
> >
> > :echo b:undo_ftplugin
> >
> > I see
> >
> > setl inde< indk<
> >
> > as expected. Further, ":ls" shows
> >
> > 1 %a "[No Name]" line 1
> >
> > Now, if I open a C file, I expect to have 'indentexpr' empty, either
> > because the C file is opened in a new buffer or because the C file
> > was opened in the same buffer and the b:undo_ftplugin was executed.
> > However, after executing
> >
> > :e foo.c :set indentexpr?
> >
> > I see
> >
> > indentexpr=indent(prevnonblank(v:lnum-1))
> >
> > and ":ls" shows
> >
> > 1 %a "foo.c" line 1
> Yes, for some reason empty buffers without edits are used to open a
> new file. You can get the same behavior after “:enew” then “edit
> bar.c”.

That just means it is a bug. It should have been reset by the time the
new buffer was loaded.

regards,
Christian
--
Bescheidenheit ist eine Eigenschaft, für die der Mensch bewundert
wird, falls die Leute je von ihm hören sollten.
-- Edgar Watson Howe

[ZyX]

> It is not triggered when current and unloaded buffers are different, but
> when it triggers, current buffer and buffer being unloaded might be
> different. That is bufnr('%') can be different then "<afile>".

Is not that what I said?

> You should not move to another buffer and probably you shouldn't change
> a buffer as well as this might cause problems. I don't see, how
> resetting the actions being done by a filetype script might cause
> problems in this case.

Actions done by filetype plugins are likely setting local options using setlocal. If you don’t move to another buffer you are setting local options *for a wrong buffer*. If you do you have other problems. Hence you must not use this autocommand.

> I disagree. The autocommand is there for a reason. Unsetting the effects
> by a filetype plugin can be a reason to use this event.

Explained above.

[ZyX]

суббота, 29 сентября 2012 г., 0:03:23 UTC+4 пользователь ZyX написал:

> > It is not triggered when current and unloaded buffers are different, but
> > when it triggers, current buffer and buffer being unloaded might be
> > different. That is bufnr('%') can be different then "<afile>".
>
> Is not that what I said?

No it is not. But you are wrong:

vim -u NONE -c 'autocmd BufUnload * echom expand("<abuf>") bufnr("%")' \
-c 'vnew' \
-c 'echom bufnr("%")' \
-c 'bw! 1'
. You will see
2
1 2
. Obviously, that means that current and unloaded buffers are different. You may replace first “echom” with “setlocal” and see that option is set for a wrong buffer. Your autocmd must not be used.

By the way, “bufnr('%')” is almost always different from «"<afile>"». First is buffer number, second is a plain string. Or a filename if you meant “expand("<afile>")”.

[Christian Brabandt]

Hi ZyX!

On Fr, 28 Sep 2012, ZyX wrote:

> > It is not triggered when current and unloaded buffers are different, but
> > when it triggers, current buffer and buffer being unloaded might be
> > different. That is bufnr('%') can be different then "<afile>".
>
> Is not that what I said?

No.

>
> > You should not move to another buffer and probably you shouldn't change
> > a buffer as well as this might cause problems. I don't see, how
> > resetting the actions being done by a filetype script might cause
> > problems in this case.
>

> Actions done by filetype plugins are likely setting local options
> using setlocal. If you don’t move to another buffer you are setting
> local options *for a wrong buffer*. If you do you have other problems.
> Hence you must not use this autocommand.

No you are not. Just test it. It works correctly.

> > I disagree. The autocommand is there for a reason. Unsetting the
> > effects by a filetype plugin can be a reason to use this event.

Still holds.

regards,
Christian
--

[Christian Brabandt]

Hi ZyX!

On Fr, 28 Sep 2012, ZyX wrote:

> vim -u NONE -c 'autocmd BufUnload * echom expand("<abuf>") bufnr("%")' \
> -c 'vnew' \
> -c 'echom bufnr("%")' \
> -c 'bw! 1'
> . You will see
> 2
> 1 2

> . Obviously, that means that current and unloaded buffers are
> different. You may replace first “echom” with “setlocal” and see that
> option is set for a wrong buffer. Your autocmd must not be used.

You are changing buffers and wiping a buffer. I am not sure what you are
trying to show here.

> By the way, “bufnr('%')” is almost always different from «"<afile>"».
> First is buffer number, second is a plain string. Or a filename if you
> meant “expand("<afile>")”.

Of course. I thought that is obvious.


Mit freundlichen Grüßen
Christian
--
Unsere Meinungen: Die Haut, in der wir gesehen werden wollen.
-- Friedrich Wilhelm Nietzsche

[Christian Brabandt]

On Fr, 28 Sep 2012, Christian Brabandt wrote:

> No you are not. Just test it. It works correctly.

Or to say it differently: by the time the BufUnload command is
triggered, the old buffer local variables have not been cleared yet, so
you can still access them.

regards,
Christian

[ZyX]

суббота, 29 сентября 2012 г., 0:15:33 UTC+4 пользователь Christian Brabandt написал:

> >You may replace first “echom” with “setlocal” and see that
> > option is set for a wrong buffer. Your autocmd must not be used.
>
> You are changing buffers and wiping a buffer. I am not sure what you are
> trying to show here.

Do what I suggested with :setlocal. *It will set options for the buffer that **was not being unloaded***. ****Wrong**** buffer.

And, by the way, you are using b:undo_ftplugin from the *wrong* buffer as well. Because “b:” is *current* buffer scope and you must not touch buffer that is not being unloaded.

[ZyX]

> Or to say it differently: by the time the BufUnload command is
> triggered, the old buffer local variables have not been cleared yet, so
> you can still access them.

First, this is not the issue.
Second, b: is *current* buffer scope. Not scope of the buffer being unloaded.

[Christian Brabandt]

Hi ZyX!

On Fr, 28 Sep 2012, ZyX wrote:

> суббота, 29 сентября 2012 г., 0:15:33 UTC+4 пользователь Christian Brabandt написал:
> > >You may replace first “echom” with “setlocal” and see that
> > > option is set for a wrong buffer. Your autocmd must not be used.
> >
> > You are changing buffers and wiping a buffer. I am not sure what you are
> > trying to show here.
> Do what I suggested with :setlocal. *It will set options for the buffer that **was not being unloaded***. ****Wrong**** buffer.

Because those options aren't freed correctly. See the patch, I
submitted.

> And, by the way, you are using b:undo_ftplugin from the *wrong* buffer
> as well. Because “b:” is *current* buffer scope and you must not touch
> buffer that is not being unloaded.

I guess we are not going to agree here. So just one final remark from me
here, before I'll shut up.

Those buffer-local variables will be freed afterwards. We have not yet
fully unloaded the old buffer, therefore we can still undo the old
options.

regards,
Christian

[ZyX]

суббота, 29 сентября 2012 г., 0:42:08 UTC+4 пользователь ZyX написал:

To be more explicit: I do not want your autocommand to junk my ftplugin settings when I unload non-current buffer. And it happens every time I use bufkill plugin, which I use almost always (just in case you thought it is uncommon) to keep windows intact (apparently, not only me; and not only this plugin uses this technique for the same purpose). And it will junk ftplugin settings whenever the current buffer has b:undo_ftplugin (i.e. has settings to junk), not the unloaded one (this increases amount of casualties).

[Gary Johnson]

On 2012-09-28, ZyX wrote:
> > Thanks for the reply, but I see that I didn't explain the problem
> > very well. Also, some of my experiments created new buffers instead
> > of replacing the contents of existing buffers with new filetypes, so
> > I wasn't replicating the actual problem conditions.
> >
> > Let me try again.
> >
> > The actual problem is that I would like to set 'indentexpr' for
> > buffers with no 'filetype' so that I get indenting behavior that I
> > think might be useful when just opening Vim and typing notes. To
> > that end I put the following in my ~/.vimrc.
> >
> > au BufWinEnter * if &ft == "" || &ft == "text"
> > \ | setlocal indentexpr=indent(prevnonblank(v:lnum-1))
> > \ | setlocal indentkeys-=o
> > \ | let b:undo_ftplugin = "setl inde< indk<"
> > \ | endif
> You can just set 'autoindent'. This option is ignored in most
> cases when using other ways to define indentation.

I have 'autoindent' set all the time, but it doesn't always work as
I would like it to. For example,

I may have a set of lines like these,
each indented from the one above,
then I may add one ending in parentheses()
then paste one below it line this.

I would like to be able to type == to align that last line with the
one above it, but == instead aligns that last line with the first
line. The behavior has something to do with the parentheses.
Without the parentheses, == aligns the last line with the one above
it.

I thought that my 'indentexpr' would be a good way to fix this, and
it is except for my inability to unset it.

I found a solution to that problem later in this thread.

Regards,
Gary

[Gary Johnson]

On 2012-09-28, ZyX wrote:

> > I'm just looking for a way to reset those local options when I edit
> > a new file, b:undo_ftplugin seemed to be the way to do it, but it
> > doesn't seem to do anything useful.
> >
> > Not using :edit is not a solution. For example, if I start vim
> > and use ":MRU" to open a recently-used C file, I wind up with
> > 'indentexpr' set as above, which wrongly indents C.
> Unset 'indentoptions' on any filetype event, adding definition of
> needed autocommand somewhere at the beginning of the vimrc (as it
> is the first file sourced), definitely before “filetype plugin
> indent on” or similar command, it should not interfere with
> ftplugins then. Use 'autoindent' instead of your 'indentexpr', it
> is here just for that reason.

Here is the current solution, which has been working fine so far
today. (I explained in a separate post how 'autoindent' does not
behave the same as this 'indentexpr'.)

au BufWinEnter * if &ft == "" || &ft == "text"
\ | setlocal indentexpr=indent(prevnonblank(v:lnum-1))
\ | setlocal indentkeys-=o

\ | let b:undo_indent = "setlocal indentexpr< indentkeys<"
\ | endif
au FileType * setlocal indentexpr< indentkeys<

Thanks for your help.

Regards,
Gary

[Bram Moolenaar]

Christian Brabandt wrote:

> On Do, 27 Sep 2012, Gary Johnson wrote:
>
> > On 2012-09-27, ZyX wrote:

> > > �������, 28 �������� 2012 �., 8:04:05 UTC+4 ������������ Gary Johnson �������:

I finally had time to look into this patch. It breaks the tests in a
nasty way. Thus this is not the right solution. Instead of freeing the
options they should be initialized to the global values.
Perhaps setting buf->b_p_initialized to FALSE works?

--
The technology involved in making anything invisible is so infinitely
complex that nine hundred and ninety-nine billion, nine hundred and
ninety-nine million, nine hundred and ninety-nine thousand, nine hundred
and ninety-nine times out of a trillion it is much simpler and more
effective just to take the thing away and do without it.
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Christian Brabandt]

Hi Bram!

On Do, 15 Nov 2012, Bram Moolenaar wrote:

> I finally had time to look into this patch. It breaks the tests in a
> nasty way. Thus this is not the right solution. Instead of freeing the
> options they should be initialized to the global values.
> Perhaps setting buf->b_p_initialized to FALSE works?

Unfortunately, that doesn't work.

--git a/src/buffer.c b/src/buffer.c
--- a/src/buffer.c
+++ b/src/buffer.c

@@ -1703,6 +1703,7 @@

/* buf->b_nwindows = 0; why was this here? */
free_buffer_stuff(buf, FALSE); /* delete local variables et al. */

buf->b_p_initialized = FALSE;
+ buf_copy_options(buf, BCO_ENTER);

#ifdef FEAT_KEYMAP
/* need to reload lmaps and set b:keymap_name */
curbuf->b_kmap_state |= KEYMAP_INIT;

This also seems to work.


regards,
Christian
--
Besser schweigen und als Narr scheinen, als sprechen und jeden Zweifel
beseitigen.
-- Abraham Lincoln

[Bram Moolenaar]

Christian Brabandt wrote:

> On Do, 15 Nov 2012, Bram Moolenaar wrote:
>
> > I finally had time to look into this patch. It breaks the tests in a
> > nasty way. Thus this is not the right solution. Instead of freeing the
> > options they should be initialized to the global values.
> > Perhaps setting buf->b_p_initialized to FALSE works?
>
> Unfortunately, that doesn't work.
>
> --git a/src/buffer.c b/src/buffer.c
> --- a/src/buffer.c
> +++ b/src/buffer.c
> @@ -1703,6 +1703,7 @@
> /* buf->b_nwindows = 0; why was this here? */
> free_buffer_stuff(buf, FALSE); /* delete local variables et al. */
> buf->b_p_initialized = FALSE;
> + buf_copy_options(buf, BCO_ENTER);
> #ifdef FEAT_KEYMAP
> /* need to reload lmaps and set b:keymap_name */
> curbuf->b_kmap_state |= KEYMAP_INIT;
>
> This also seems to work.

I'll try it out. Why BCO_ENTER and not BCO_ALWAYS, as it's used in the
"else" part?

--
If you put 7 of the most talented OSS developers in a room for a week
and asked them to fix a bug in a spreadsheet program, in 1 week
you'd have 2 new mail readers and a text-based web browser.