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

Re: Global cpo_save

Expand Messages
  • Tony Mechelynck
    ... The :let statement never remembers where its operand was set (unlike ... In this case, the above precautions are prudent, but only really necessary if
    Message 1 of 7 , Sep 2, 2008
      On 03/09/08 06:11, Bill McCarthy wrote:
      > Hello Vim Developers,
      >
      > I noticed a global variable that doesn't appear to be
      > intentionally set. The variable `cpo_save' undecorated and
      > outside a function is implicitly global.
      >
      > Unfortunately `verbose let' does not reveal where it is set.
      > I found three places - there could be more:
      >
      > vim72/ftplugin/hamster.vim
      > vim72/ftplugin/vim.vim
      > vim72/plugin/matchparen.vim
      >
      > The solution is to (1) prefix with `s:', (2) unlet, or (3)
      > do both.
      >

      The ":let" statement never remembers where its operand was set (unlike
      :set, :map, :autocmd, :hi, :function and :command).

      In this case, the above precautions are prudent, but only really
      necessary if those scripts can interrupt each other, which I don't think
      can happen in this case. I believe that in the first two cases above,
      prefixing with b: might also be a valid solution.

      Here's the typical use of that variable:

      let cpo_save = &cpo
      set cpo&vim
      ...
      the bulk of the script comes here
      ...
      let &cpo = cpo_save


      Best regards,
      Tony.
      --
      hundred-and-one symptoms of being an internet addict:
      159. You get excited whenever discussing your hard drive.

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Ben Schmidt
      ... Or if they can be sourced from another script whose variable they could clobber, which is definitely possible. Of course, you can argue that hypothetical
      Message 2 of 7 , Sep 3, 2008
        Tony Mechelynck wrote:
        > On 03/09/08 06:11, Bill McCarthy wrote:
        >> Hello Vim Developers,
        >>
        >> I noticed a global variable that doesn't appear to be
        >> intentionally set. The variable `cpo_save' undecorated and
        >> outside a function is implicitly global.
        >>
        >> Unfortunately `verbose let' does not reveal where it is set.
        >> I found three places - there could be more:
        >>
        >> vim72/ftplugin/hamster.vim
        >> vim72/ftplugin/vim.vim
        >> vim72/plugin/matchparen.vim
        >>
        >> The solution is to (1) prefix with `s:', (2) unlet, or (3)
        >> do both.
        >>
        >
        > The ":let" statement never remembers where its operand was set (unlike
        > :set, :map, :autocmd, :hi, :function and :command).
        >
        > In this case, the above precautions are prudent, but only really
        > necessary if those scripts can interrupt each other, which I don't think
        > can happen in this case.

        Or if they can be sourced from another script whose variable they could
        clobber, which is definitely possible. Of course, you can argue that
        hypothetical script is poorly written, but still...

        At any rate, I'm sure all will agree it should be fixed.

        Ben.



        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Tony Mechelynck
        ... Let/unlet could still clobber another variable (however, a variable which must be _kept_ over the opening of a file or over the sourcing of all global
        Message 3 of 7 , Sep 3, 2008
          On 03/09/08 11:50, Ben Schmidt wrote:
          > Tony Mechelynck wrote:
          >> On 03/09/08 06:11, Bill McCarthy wrote:
          >>> Hello Vim Developers,
          >>>
          >>> I noticed a global variable that doesn't appear to be
          >>> intentionally set. The variable `cpo_save' undecorated and
          >>> outside a function is implicitly global.
          >>>
          >>> Unfortunately `verbose let' does not reveal where it is set.
          >>> I found three places - there could be more:
          >>>
          >>> vim72/ftplugin/hamster.vim
          >>> vim72/ftplugin/vim.vim
          >>> vim72/plugin/matchparen.vim
          >>>
          >>> The solution is to (1) prefix with `s:', (2) unlet, or (3)
          >>> do both.
          >>>
          >> The ":let" statement never remembers where its operand was set (unlike
          >> :set, :map, :autocmd, :hi, :function and :command).
          >>
          >> In this case, the above precautions are prudent, but only really
          >> necessary if those scripts can interrupt each other, which I don't think
          >> can happen in this case.
          >
          > Or if they can be sourced from another script whose variable they could
          > clobber, which is definitely possible. Of course, you can argue that
          > hypothetical script is poorly written, but still...
          >
          > At any rate, I'm sure all will agree it should be fixed.
          >
          > Ben.

          Let/unlet could still clobber another variable (however, a variable
          which must be _kept_ over the opening of a file or over the sourcing of
          all global plugins shouldn't have such a suspicious name) -- unless, of
          course, a script variable were used.

          I'm saying it might be good to fix it but I would give it a low priority.


          Best regards,
          Tony.
          --
          The temperature of Heaven can be rather accurately computed. Our
          authority is Isaiah 30:26, "Moreover, the light of the Moon shall be as
          the light of the Sun and the light of the Sun shall be sevenfold, as
          the light of seven days." Thus Heaven receives from the Moon as much
          radiation as we do from the Sun, and in addition 7*7 (49) times as much
          as the Earth does from the Sun, or 50 times in all. The light we
          receive from the Moon is one 1/10,000 of the light we receive from the
          Sun, so we can ignore that ... The radiation falling on Heaven will
          heat it to the point where the heat lost by radiation is just equal to
          the heat received by radiation, i.e., Heaven loses 50 times as much
          heat as the Earth by radiation. Using the Stefan-Boltzmann law for
          radiation, (H/E)^4 = 50, where E is the absolute temperature of the
          earth (~300K), gives H as 798K (525C). The exact temperature of Hell
          cannot be computed ... [However] Revelations 21:8 says "But the
          fearful, and unbelieving ... shall have their part in the lake which
          burneth with fire and brimstone." A lake of molten brimstone means
          that its temperature must be at or below the boiling point, 444.6C. We
          have, then, that Heaven, at 525C is hotter than Hell at 445C.
          -- From "Applied Optics" vol. 11, A14, 1972

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Bram Moolenaar
          ... I ll fix vim.vim and matchparen.vim. Sorry I didn t notice this mistake before. I ll leave hamster.vim to David. -- How To Keep A Healthy Level Of
          Message 4 of 7 , Sep 3, 2008
            Bill McCarthy wrote:

            > Hello Vim Developers,
            >
            > I noticed a global variable that doesn't appear to be
            > intentionally set. The variable `cpo_save' undecorated and
            > outside a function is implicitly global.
            >
            > Unfortunately `verbose let' does not reveal where it is set.
            > I found three places - there could be more:
            >
            > vim72/ftplugin/hamster.vim
            > vim72/ftplugin/vim.vim
            > vim72/plugin/matchparen.vim
            >
            > The solution is to (1) prefix with `s:', (2) unlet, or (3)
            > do both.

            I'll fix vim.vim and matchparen.vim. Sorry I didn't notice this mistake
            before.

            I'll leave hamster.vim to David.

            --
            How To Keep A Healthy Level Of Insanity:
            15. Five days in advance, tell your friends you can't attend their
            party because you're not in the mood.

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ download, build and distribute -- http://www.A-A-P.org ///
            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_dev" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Bill McCarthy
            ... Thanks! Most scripts follow the same scheme, starting with let s:cpo_save = &cpo adjust cpo and end with let &cpo = s:cpo_save unlet s:cpo_save Besides
            Message 5 of 7 , Sep 3, 2008
              On Wed 3-Sep-08 3:12pm -0600, Bram Moolenaar wrote:
              > Bill McCarthy wrote:

              >> I noticed a global variable that doesn't appear to be
              >> intentionally set. The variable `cpo_save' undecorated and
              >> outside a function is implicitly global.
              >>
              >> Unfortunately `verbose let' does not reveal where it is set.
              >> I found three places - there could be more:
              >>
              >> vim72/ftplugin/hamster.vim
              >> vim72/ftplugin/vim.vim
              >> vim72/plugin/matchparen.vim
              >>
              >> The solution is to (1) prefix with `s:', (2) unlet, or (3)
              >> do both.

              > I'll fix vim.vim and matchparen.vim. Sorry I didn't notice this mistake
              > before.
              >
              > I'll leave hamster.vim to David.

              Thanks!

              Most scripts follow the same scheme, starting with

              let s:cpo_save = &cpo
              " adjust cpo

              and end with

              let &cpo = s:cpo_save
              unlet s:cpo_save

              Besides the 3 I mentioned, ftplugin/abaqus.vim fails to

              unlet s:cpo_save

              A very minor oversight.

              --
              Best regards,
              Bill



              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_dev" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Bill McCarthy
              ... Thanks for your and Ben s comments. Of course simply adding an unlet doesn t solve the problem. The problem is that a global is used. If you had a
              Message 6 of 7 , Sep 3, 2008
                On Tue 2-Sep-08 11:41pm -0600, Tony Mechelynck wrote:
                > On 03/09/08 06:11, Bill McCarthy wrote:

                >> I noticed a global variable that doesn't appear to be
                >> intentionally set. The variable `cpo_save' undecorated and
                >> outside a function is implicitly global.
                >>
                >> Unfortunately `verbose let' does not reveal where it is set.
                >> I found three places - there could be more:
                >>
                >> vim72/ftplugin/hamster.vim
                >> vim72/ftplugin/vim.vim
                >> vim72/plugin/matchparen.vim
                >>
                >> The solution is to (1) prefix with `s:', (2) unlet, or (3)
                >> do both.

                > In this case, the above precautions are prudent, but only really
                > necessary if those scripts can interrupt each other, which I don't think
                > can happen in this case. I believe that in the first two cases above,
                > prefixing with b: might also be a valid solution.

                Thanks for your and Ben's comments. Of course simply adding
                an "unlet" doesn't solve the problem. The problem is that a
                global is used. If you had a global that stored Captain
                Paul Olsen's SAV(E)ings - it gets wiped out. Globals should be
                used very sparingly and only when necessary.

                Yes, `b:' would be an adequate alternate - although IMHO
                `s:' is more natural. And please `unlet' - I know nobody is
                running a 64k machine anymore, but why waste space?

                --
                Best regards,
                Bill



                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_dev" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              Your message has been successfully submitted and would be delivered to recipients shortly.