Loading ...
Sorry, an error occurred while loading the content.
 

Does b:undo_ftplugin actually work?

Expand Messages
  • 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
    Message 1 of 23 , Sep 27, 2012
      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

      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php
    • ZyX
      ... 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).
      Message 2 of 23 , Sep 27, 2012
        пятница, 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".

        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php
      • 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
        Message 3 of 23 , Sep 27, 2012
          On 2012-09-27, ZyX wrote:
          > пятница, 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".

          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

          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php
        • 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
          Message 4 of 23 , Sep 28, 2012
            Hi Gary!

            On Do, 27 Sep 2012, Gary Johnson wrote:

            > On 2012-09-27, ZyX wrote:
            > > пятница, 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".
            >
            > 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.

            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

            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php
          • ZyX
            ... According to the documentation, BufUnload event may be triggered when current and unloaded buffers are different. And, according to the same doc, you must
            Message 5 of 23 , Sep 28, 2012
              > " 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.

              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php
            • ZyX
              ... You can just set autoindent . This option is ignored in most cases when using other ways to define indentation. ... Yes, for some reason empty buffers
              Message 6 of 23 , Sep 28, 2012
                > 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.

                --
                You received this message from the "vim_dev" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php
              • 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
                Message 7 of 23 , Sep 28, 2012
                  On Thursday, September 27, 2012 11:04:05 PM UTC-5, Gary Johnson wrote:
                  > 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 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.

                  --
                  You received this message from the "vim_dev" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php
                • Christian Brabandt
                  Hi ZyX! ... It is not triggered when current and unloaded buffers are different, but when it triggers, current buffer and buffer being unloaded might be
                  Message 8 of 23 , Sep 28, 2012
                    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

                    --
                    You received this message from the "vim_dev" maillist.
                    Do not top-post! Type your reply below the text you are replying to.
                    For more information, visit http://www.vim.org/maillist.php
                  • Christian Brabandt
                    Hi ZyX! ... 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
                    Message 9 of 23 , Sep 28, 2012
                      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

                      --
                      You received this message from the "vim_dev" maillist.
                      Do not top-post! Type your reply below the text you are replying to.
                      For more information, visit http://www.vim.org/maillist.php
                    • ZyX
                      ... Is not that what I said? ... Actions done by filetype plugins are likely setting local options using setlocal. If you don’t move to another buffer you
                      Message 10 of 23 , Sep 28, 2012
                        > 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.

                        --
                        You received this message from the "vim_dev" maillist.
                        Do not top-post! Type your reply below the text you are replying to.
                        For more information, visit http://www.vim.org/maillist.php
                      • ZyX
                        ... No it is not. But you are wrong: vim -u NONE -c autocmd BufUnload * echom expand( ) bufnr( % ) -c vnew -c echom bufnr( % ) -c bw! 1 .
                        Message 11 of 23 , Sep 28, 2012
                          суббота, 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>")".

                          --
                          You received this message from the "vim_dev" maillist.
                          Do not top-post! Type your reply below the text you are replying to.
                          For more information, visit http://www.vim.org/maillist.php
                        • Christian Brabandt
                          Hi ZyX! ... No. ... No you are not. Just test it. It works correctly. ... Still holds. regards, Christian -- -- You received this message from the vim_dev
                          Message 12 of 23 , Sep 28, 2012
                            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
                            --

                            --
                            You received this message from the "vim_dev" maillist.
                            Do not top-post! Type your reply below the text you are replying to.
                            For more information, visit http://www.vim.org/maillist.php
                          • Christian Brabandt
                            Hi ZyX! ... You are changing buffers and wiping a buffer. I am not sure what you are trying to show here. ... Of course. I thought that is obvious. Mit
                            Message 13 of 23 , Sep 28, 2012
                              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

                              --
                              You received this message from the "vim_dev" maillist.
                              Do not top-post! Type your reply below the text you are replying to.
                              For more information, visit http://www.vim.org/maillist.php
                            • Christian Brabandt
                              ... 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
                              Message 14 of 23 , Sep 28, 2012
                                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

                                --
                                You received this message from the "vim_dev" maillist.
                                Do not top-post! Type your reply below the text you are replying to.
                                For more information, visit http://www.vim.org/maillist.php
                              • ZyX
                                ... 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
                                Message 15 of 23 , Sep 28, 2012
                                  суббота, 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.

                                  --
                                  You received this message from the "vim_dev" maillist.
                                  Do not top-post! Type your reply below the text you are replying to.
                                  For more information, visit http://www.vim.org/maillist.php
                                • ZyX
                                  ... First, this is not the issue. Second, b: is *current* buffer scope. Not scope of the buffer being unloaded. -- You received this message from the vim_dev
                                  Message 16 of 23 , Sep 28, 2012
                                    > 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.

                                    --
                                    You received this message from the "vim_dev" maillist.
                                    Do not top-post! Type your reply below the text you are replying to.
                                    For more information, visit http://www.vim.org/maillist.php
                                  • Christian Brabandt
                                    Hi ZyX! ... Because those options aren t freed correctly. See the patch, I submitted. ... I guess we are not going to agree here. So just one final remark from
                                    Message 17 of 23 , Sep 28, 2012
                                      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

                                      --
                                      You received this message from the "vim_dev" maillist.
                                      Do not top-post! Type your reply below the text you are replying to.
                                      For more information, visit http://www.vim.org/maillist.php
                                    • 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
                                      Message 18 of 23 , Sep 28, 2012
                                        суббота, 29 сентября 2012 г., 0:42:08 UTC+4 пользователь 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.

                                        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).

                                        --
                                        You received this message from the "vim_dev" maillist.
                                        Do not top-post! Type your reply below the text you are replying to.
                                        For more information, visit http://www.vim.org/maillist.php
                                      • Gary Johnson
                                        ... 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
                                        Message 19 of 23 , Sep 30, 2012
                                          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

                                          --
                                          You received this message from the "vim_dev" maillist.
                                          Do not top-post! Type your reply below the text you are replying to.
                                          For more information, visit http://www.vim.org/maillist.php
                                        • Gary Johnson
                                          ... 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
                                          Message 20 of 23 , Oct 1, 2012
                                            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

                                            --
                                            You received this message from the "vim_dev" maillist.
                                            Do not top-post! Type your reply below the text you are replying to.
                                            For more information, visit http://www.vim.org/maillist.php
                                          • Bram Moolenaar
                                            ... 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
                                            Message 21 of 23 , Nov 15, 2012
                                              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 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".
                                              > >
                                              > > 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.
                                              >
                                              > 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?

                                              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 -- Bram@... -- 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 ///

                                              --
                                              You received this message from the "vim_dev" maillist.
                                              Do not top-post! Type your reply below the text you are replying to.
                                              For more information, visit http://www.vim.org/maillist.php
                                            • Christian Brabandt
                                              Hi Bram! ... Unfortunately, that doesn t work. --git a/src/buffer.c b/src/buffer.c ... +++ b/src/buffer.c @@ -1703,6 +1703,7 @@ /* buf- b_nwindows = 0; why was
                                              Message 22 of 23 , Nov 16, 2012
                                                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

                                                --
                                                You received this message from the "vim_dev" maillist.
                                                Do not top-post! Type your reply below the text you are replying to.
                                                For more information, visit http://www.vim.org/maillist.php
                                              • Bram Moolenaar
                                                ... 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
                                                Message 23 of 23 , Nov 17, 2012
                                                  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.

                                                  /// Bram Moolenaar -- Bram@... -- 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 ///

                                                  --
                                                  You received this message from the "vim_dev" maillist.
                                                  Do not top-post! Type your reply below the text you are replying to.
                                                  For more information, visit http://www.vim.org/maillist.php
                                                Your message has been successfully submitted and would be delivered to recipients shortly.