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

Global cpo_save

Expand Messages
  • Bill McCarthy
    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
    Message 1 of 7 , Sep 2, 2008
    • 0 Attachment
      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.

      --
      Best regards,
      Bill


      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • 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 2 of 7 , Sep 2, 2008
      • 0 Attachment
        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 3 of 7 , Sep 3, 2008
        • 0 Attachment
          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 4 of 7 , Sep 3, 2008
          • 0 Attachment
            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 5 of 7 , Sep 3, 2008
            • 0 Attachment
              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 6 of 7 , Sep 3, 2008
              • 0 Attachment
                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 7 of 7 , Sep 3, 2008
                • 0 Attachment
                  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.