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

current_compiler variable in...

Expand Messages
  • Douglas L . Potts
    Hi all, Just noticed that in all of the built-in compiler files that we use setlocal for all of the compiler settings, but the current_compiler variable is
    Message 1 of 5 , Jul 26, 2002
    • 0 Attachment
      Hi all,

      Just noticed that in all of the 'built-in' compiler files that we use
      setlocal for all of the compiler settings, but the current_compiler
      variable is used as an overall check of what compiler file we have
      loaded.

      Shouldn't we be using b:current_compiler if it is all set locally?

      Just a thought,
      -Doug

      --
      *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
      Douglas L. Potts
      "The three Rs of Microsoft support: Retry, Reboot, Reinstall."
      -Ralf Hildebrandt <R.Hildebrandt@...>
      GPG Fingerprint: 768A EEF8 197A 4C9A 5EF7 DA5B 464C 97DF DCD5 68C2
      *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
    • Bram Moolenaar
      ... That would indeed be better, since makeprg and errorformat should also be local to the buffer. The question is how to change this and still be
      Message 2 of 5 , Jul 26, 2002
      • 0 Attachment
        Douglas Potts wrote:

        > Just noticed that in all of the 'built-in' compiler files that we use
        > setlocal for all of the compiler settings, but the current_compiler
        > variable is used as an overall check of what compiler file we have
        > loaded.
        >
        > Shouldn't we be using b:current_compiler if it is all set locally?

        That would indeed be better, since 'makeprg' and 'errorformat' should
        also be local to the buffer.

        The question is how to change this and still be backwards compatible.
        Someone may use "current_compiler" to stop the standard plugin from
        being used. I suppose a user-specific compiler plugin would set
        "current_compiler" to disable the standard one. Thus the plugin should
        check both "current_compiler" and "b:current_compiler", and only do its
        work when neither is defined. And probably set both variables as well.

        --
        Everybody lies, but it doesn't matter since nobody listens.
        -- Lieberman's Law

        /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
        /// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
        \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
        \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
      • Douglas L . Potts
        ... This sounds like it would work the way one would expect. Did you already have something worked up, or should I come up with a patch? -Doug --
        Message 3 of 5 , Jul 30, 2002
        • 0 Attachment
          On Fri, Jul 26, 2002 at 08:04:57PM +0200 Bram Moolenaar wrote:
          >
          > Douglas Potts wrote:
          >
          > > Just noticed that in all of the 'built-in' compiler files that we use
          > > setlocal for all of the compiler settings, but the current_compiler
          > > variable is used as an overall check of what compiler file we have
          > > loaded.
          > >
          > > Shouldn't we be using b:current_compiler if it is all set locally?
          >
          > That would indeed be better, since 'makeprg' and 'errorformat' should
          > also be local to the buffer.
          >
          > The question is how to change this and still be backwards compatible.
          > Someone may use "current_compiler" to stop the standard plugin from
          > being used. I suppose a user-specific compiler plugin would set
          > "current_compiler" to disable the standard one. Thus the plugin should
          > check both "current_compiler" and "b:current_compiler", and only do its
          > work when neither is defined. And probably set both variables as well.

          This sounds like it would work the way one would expect. Did you
          already have something worked up, or should I come up with a patch?

          -Doug

          --
          *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
          Douglas L. Potts
          "Writing is easy. It's all a matter of staring at a blank piece of paper
          until your forehead bleeds" -Douglas Adams
          GPG Fingerprint: 768A EEF8 197A 4C9A 5EF7 DA5B 464C 97DF DCD5 68C2
          *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
        • Bram Moolenaar
          ... You could make a suggestion. Since all the existing plugins need to be changed, It s easier for me to do that myself on the versions I have now. In other
          Message 4 of 5 , Jul 30, 2002
          • 0 Attachment
            Douglas Potts wrote:

            > > > Just noticed that in all of the 'built-in' compiler files that we use
            > > > setlocal for all of the compiler settings, but the current_compiler
            > > > variable is used as an overall check of what compiler file we have
            > > > loaded.
            > > >
            > > > Shouldn't we be using b:current_compiler if it is all set locally?
            > >
            > > That would indeed be better, since 'makeprg' and 'errorformat' should
            > > also be local to the buffer.
            > >
            > > The question is how to change this and still be backwards compatible.
            > > Someone may use "current_compiler" to stop the standard plugin from
            > > being used. I suppose a user-specific compiler plugin would set
            > > "current_compiler" to disable the standard one. Thus the plugin should
            > > check both "current_compiler" and "b:current_compiler", and only do its
            > > work when neither is defined. And probably set both variables as well.
            >
            > This sounds like it would work the way one would expect. Did you
            > already have something worked up, or should I come up with a patch?

            You could make a suggestion. Since all the existing plugins need to be
            changed, It's easier for me to do that myself on the versions I have
            now. In other words: rather a script than a patch.

            --
            hundred-and-one symptoms of being an internet addict:
            67. Your hard drive crashes. You haven't logged in for two hours. You start
            to twitch. You pick up the phone and manually dial your ISP's access
            number. You try to hum to communicate with the modem. You succeed.

            /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
            /// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
            \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
            \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
          • Douglas L . Potts
            ... Well, assuming I understand you correctly, here is a bash script to go through and modify the existing compiler files. -Doug --
            Message 5 of 5 , Aug 2, 2002
            • 0 Attachment
              On Tue, Jul 30, 2002 at 01:47:27PM +0200 Bram Moolenaar wrote:
              >
              > Douglas Potts wrote:
              >
              > > > > Just noticed that in all of the 'built-in' compiler files that we use
              > > > > setlocal for all of the compiler settings, but the current_compiler
              > > > > variable is used as an overall check of what compiler file we have
              > > > > loaded.
              > > > >
              > > > > Shouldn't we be using b:current_compiler if it is all set locally?
              > > >
              > > > That would indeed be better, since 'makeprg' and 'errorformat' should
              > > > also be local to the buffer.
              > > >
              > > > The question is how to change this and still be backwards compatible.
              > > > Someone may use "current_compiler" to stop the standard plugin from
              > > > being used. I suppose a user-specific compiler plugin would set
              > > > "current_compiler" to disable the standard one. Thus the plugin should
              > > > check both "current_compiler" and "b:current_compiler", and only do its
              > > > work when neither is defined. And probably set both variables as well.
              > >
              > > This sounds like it would work the way one would expect. Did you
              > > already have something worked up, or should I come up with a patch?
              >
              > You could make a suggestion. Since all the existing plugins need to be
              > changed, It's easier for me to do that myself on the versions I have
              > now. In other words: rather a script than a patch.

              Well, assuming I understand you correctly, here is a bash script to go
              through and modify the existing compiler files.

              -Doug

              --
              *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
              Douglas L. Potts
              "But you can't expect to wield supreme executive power just 'cause some
              watery tart threw a sword at you!"
              -Dennis, "Monty Python and the Holy Grail"
              GPG Fingerprint: 768A EEF8 197A 4C9A 5EF7 DA5B 464C 97DF DCD5 68C2
              *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
            Your message has been successfully submitted and would be delivered to recipients shortly.