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

Re: current_compiler variable in...

Expand Messages
  • 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 1 of 5 , Jul 26 11:04 AM
    • 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 2 of 5 , Jul 30 4:40 AM
      • 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 3 of 5 , Jul 30 4:47 AM
        • 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 4 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.