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

Re: Does b:undo_ftplugin actually work?

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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.