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

Re: Does b:undo_ftplugin actually work?

Expand Messages
  • 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 1 of 23 , Sep 28, 2012
    • 0 Attachment
      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 2 of 23 , Sep 28, 2012
      • 0 Attachment
        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 3 of 23 , Sep 28, 2012
        • 0 Attachment
          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 4 of 23 , Sep 28, 2012
          • 0 Attachment
            > 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 5 of 23 , Sep 28, 2012
            • 0 Attachment
              суббота, 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 6 of 23 , Sep 28, 2012
              • 0 Attachment
                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 7 of 23 , Sep 28, 2012
                • 0 Attachment
                  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 8 of 23 , Sep 28, 2012
                  • 0 Attachment
                    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 9 of 23 , Sep 28, 2012
                    • 0 Attachment
                      суббота, 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 10 of 23 , Sep 28, 2012
                      • 0 Attachment
                        > 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 11 of 23 , Sep 28, 2012
                        • 0 Attachment
                          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 12 of 23 , Sep 28, 2012
                          • 0 Attachment
                            суббота, 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 13 of 23 , Sep 30, 2012
                            • 0 Attachment
                              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 14 of 23 , Oct 1, 2012
                              • 0 Attachment
                                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 15 of 23 , Nov 15, 2012
                                • 0 Attachment
                                  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 16 of 23 , Nov 16, 2012
                                  • 0 Attachment
                                    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 17 of 23 , Nov 17, 2012
                                    • 0 Attachment
                                      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.