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

Re: Vim syntax file should not require interpreter support to highlight :{interp}<

Expand Messages
  • Bram Moolenaar
    ... Clearly one can get upset when someone uses the word ridiculous this way. With the effect that the writer (Charles in this case) will object to any
    Message 1 of 12 , Aug 16, 2013
    • 0 Attachment
      Charles Campbell wrote:

      > ZyX wrote:
      > > I see that all g:vimsyn_embed flags say things like “embed …
      > > **(but only if vim supports it)**”. This is ridiculous:
      > Ah, I disagree -- not ridiculous at all. What's ridiculous is to assume
      > that one will be writing code for an interpreter embedded in vimscript
      > without being able to test it. Thus, one needs to have the interpreter
      > supported for it to make sense. The syntax/vim.vim script is quite long
      > already; making all interpreters' embedded highlighting work all the
      > time means everyone would have to put up with additional delays -- and
      > frankly, I don't think that most folks use all the interpreters.
      > That's not a problem for those with fast machines; not all have fast
      > machines.

      Clearly one can get upset when someone uses the word "ridiculous" this
      way. With the effect that the writer (Charles in this case) will object
      to any further argument, no matter how valid it is.

      I hope Charles has calmed down by the time he reads this.

      > > ou don’t have to have vim lua support to code in lua and have
      > > syntax highlighting; you specifically don’t have to have vim lua
      > > support to write or watch lua<<EOF sections; and it is completely
      > > possible for oneself to want to review {interp}<<EOF sections in
      > > foreign plugins before deciding whether he needs to obtain Vim with
      > > {interp} support or (my case) to watch correct highlighting of his
      > > own vimrc on machine without specific interpreter support.
      >
      > You can look at the embedded code already -- it just won't have the
      > embedded interpreter's highlighting if your vim won't support it. Sort
      > of a visual flag that it won't work with your vim.

      Well, if the code is inside an if has("perl") then it still gets
      highlighted as an error. E.g., if a script uses:

      if has("perl")
      perl << EOF
      VIM::Msg("pearls are nice for necklaces");
      VIM::Msg("rubys for rings");
      VIM::Msg("pythons for bags");
      VIM::Msg("tcls????");
      EOF
      elseif has("python")
      python << EOF
      class StrawberryIcecream:
      def __call__(self):
      print 'EAT ME'
      EOF
      endif

      Then we see large blocks of red, even though these lines will not be
      executed. I would at least not highlight this as an error.

      I don't really see a problem with highlighting the Perl/Python lines
      even when they can't be executed. It's a matter of removing a condition
      in the syntax file. I don't think it is slower than highlighting Vim
      code.

      What does slow down is loading all the syntaxes, even though the chance
      of the syntax commands actually being used is small. There already is a
      g:vimsyn_embed variable to disable some or all files.

      Perhaps we have a similar variable to force including the syntax. So
      the default would be to only highlight supported languages, and one can
      enable specific ones even though they are not supported.

      --
      % cat /usr/include/life.h
      void life(void);

      /// 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

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Nikolay Pavlov
      On Aug 16, 2013 7:02 AM, Charles E Campbell ... that one will be writing code for an interpreter embedded in vimscript without
      Message 2 of 12 , Aug 17, 2013
      • 0 Attachment


        On Aug 16, 2013 7:02 AM, "Charles E Campbell" <drchip@...> wrote:
        >
        > ZyX wrote:
        >>
        >> I see that all g:vimsyn_embed flags say things like “embed … **(but only if vim supports it)**”. This is ridiculous:
        >
        > Ah, I disagree -- not ridiculous at all.  What's ridiculous is to assume that one will be writing code for an interpreter embedded in vimscript without being able to test it.  Thus, one needs to have the interpreter supported for it to make sense.  The syntax/vim.vim script is quite long already; making all interpreters' embedded highlighting work all the time means everyone would have to put up with additional delays -- and frankly, I don't think that most folks use all the interpreters.   That's not a problem for those with fast machines; not all have fast machines.

        This word should be attached to the inability to force the highlighting. The case you describe here is targeted with different (computable) defaults I suggested later in the mail.

        >> ou don’t have to have vim lua support to code in lua and have syntax highlighting; you specifically don’t have to have vim lua support to write or watch lua<<EOF sections; and it is completely possible for oneself to want to review {interp}<<EOF sections in foreign plugins before deciding whether he needs to obtain Vim with {interp} support or (my case) to watch correct highlighting of his own vimrc on machine without specific interpreter support.
        >
        >
        > You can look at the embedded code already -- it just won't have the embedded interpreter's highlighting if your vim won't support it. Sort of a visual flag that it won't work with your vim.

        There are no such flags for all other disableable features except for :syn cchar (but not :syn conceal and :syn concealends) which is inconsistent.

        I should also say that highlighting cchar as an *error* without +conceal is a bug.

        >
        >
        > --
        > --
        > 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
        >
        > --- You received this message because you are subscribed to the Google Groups "vim_dev" group.
        > To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        > For more options, visit https://groups.google.com/groups/opt_out.

        --
        --
        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
         
        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Ingo Karkat
        ... I came to the same conclusion: While it is noble that the Vim syntax plugin notifies the user that the used script interpreter is not available in the
        Message 3 of 12 , Aug 20, 2013
        • 0 Attachment
          On 13-Aug-2013 18:46 +0200, ZyX wrote:

          > I see that all g:vimsyn_embed flags say things like “embed … **(but
          > only if vim supports it)**”. This is ridiculous: you don’t have to
          > have vim lua support to code in lua and have syntax highlighting; you
          > specifically don’t have to have vim lua support to write or watch
          > lua<<EOF sections; and it is completely possible for oneself to want
          > to review {interp}<<EOF sections in foreign plugins before deciding
          > whether he needs to obtain Vim with {interp} support or (my case) to
          > watch correct highlighting of his own vimrc on machine without
          > specific interpreter support.
          >
          > I thus see no reason for using `(g:vimsyn_embed =~ 'p' &&
          > has("perl"))` checks without any option to always highlight embedded
          > perl code. If the intention is to indicate that interpreter is not
          > supported then the only place where `has("perl")` should be present is
          > the section where `g:vimsyn_embed` default value is computed: those
          > (almost every vim user) who do not set `g:vimsyn_embed` will not
          > notice any change in behavior, those who care will always receive
          > correct highlighting.

          I came to the same conclusion: While it is noble that the Vim syntax
          plugin notifies the user that the used script interpreter is not
          available in the current editor, having huge blocks of red error
          highlighting is certainly overdoing it and counterproductive, because,
          as we all know, reality isn't either black or white, and situations like
          these do happen.

          When I encountered this "wall of red", I pragmatically patched my
          syntax/vim.vim (7.4a-03 ASTRO-ONLY) to only highlight the interpreter
          command itself, not the whole block, and as warning in place of error.
          The following patch is for Perl and Python (the two languages I'm
          concerned with) only, but I'd be trivial to extend to all languages.

          Charles, would you please consider including something like that? (Maybe
          conditionally with a config variable, if there are indeed purists that
          prefer the status quo, though none have spoken up so far in this thread.)

          -- regards, ingo

          --
          --
          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

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Peter Prohaska
          On Tue, Aug 20, 2013 at 9:29 PM, Ingo Karkat wrote: [...] ... Signed. ... Appreciated. Applied. Thanks. Testing with Python 2 and 3,
          Message 4 of 12 , Aug 20, 2013
          • 0 Attachment
            On Tue, Aug 20, 2013 at 9:29 PM, Ingo Karkat <swdev@...> wrote:
            [...]
            > I came to the same conclusion: While it is noble that the Vim syntax
            > plugin notifies the user that the used script interpreter is not
            > available in the current editor, having huge blocks of red error
            > highlighting is certainly overdoing it and counterproductive, because,
            > as we all know, reality isn't either black or white, and situations like
            > these do happen.

            Signed.

            > The following patch is for Perl and Python (the two languages I'm
            > concerned with) only, but I'd be trivial to extend to all languages.

            Appreciated. Applied. Thanks. Testing with Python 2 and 3, Perl absent.

            > Charles, would you please consider including something like that? (Maybe
            > conditionally with a config variable, if there are indeed purists that
            > prefer the status quo, though none have spoken up so far in this thread.)

            Only performance issues might turn me purist. I can hardly imagine
            an environment right now, where one of the two approaches fails significantly
            more than the other. I expect to be proven wrong and keep a copy of the
            patch nearby. my 2 ct.

            --peter.

            --
            --
            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

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • LCD 47
            ... [...] +1 for this. People routinely edit files that only make sense (and will only ever run) on remote servers. There are legitimate situations where
            Message 5 of 12 , Aug 20, 2013
            • 0 Attachment
              On 20 August 2013, Ingo Karkat <swdev@...> wrote:
              > On 13-Aug-2013 18:46 +0200, ZyX wrote:
              >
              > > I see that all g:vimsyn_embed flags say things like ?embed ? **(but
              > > only if vim supports it)**?. This is ridiculous: you don?t have to
              > > have vim lua support to code in lua and have syntax highlighting;
              > > you specifically don?t have to have vim lua support to write or
              > > watch lua<<EOF sections; and it is completely possible for oneself
              > > to want to review {interp}<<EOF sections in foreign plugins before
              > > deciding whether he needs to obtain Vim with {interp} support or
              > > (my case) to watch correct highlighting of his own vimrc on machine
              > > without specific interpreter support.
              > >
              > > I thus see no reason for using `(g:vimsyn_embed =~ 'p' &&
              > > has("perl"))` checks without any option to always highlight embedded
              > > perl code. If the intention is to indicate that interpreter is not
              > > supported then the only place where `has("perl")` should be present
              > > is the section where `g:vimsyn_embed` default value is computed:
              > > those (almost every vim user) who do not set `g:vimsyn_embed` will
              > > not notice any change in behavior, those who care will always
              > > receive correct highlighting.
              >
              > I came to the same conclusion: While it is noble that the Vim syntax
              > plugin notifies the user that the used script interpreter is not
              > available in the current editor, having huge blocks of red error
              > highlighting is certainly overdoing it and counterproductive, because,
              > as we all know, reality isn't either black or white, and situations
              > like these do happen.
              [...]

              +1 for this. People routinely edit files that only make sense (and
              will only ever run) on remote servers. There are legitimate situations
              where editing a file has nothing to do with actually running it.

              /lcd

              --
              --
              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

              ---
              You received this message because you are subscribed to the Google Groups "vim_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Charles Campbell
              ... Except, if its embedded in vimscript, then it is intended to be executed by vim. -- -- You received this message from the vim_dev maillist. Do not
              Message 6 of 12 , Aug 21, 2013
              • 0 Attachment
                LCD 47 wrote:
                > ..snip..
                > +1 for this. People routinely edit files that only make sense (and
                > will only ever run) on remote servers. There are legitimate situations
                > where editing a file has nothing to do with actually running it.
                >
                Except, if its embedded in vimscript, then it is intended to be executed
                by vim.

                --
                --
                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

                ---
                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • James McCoy
                On Aug 21, 2013 1:42 PM, Charles Campbell ... by vim. But not necessarily *this* Vim, which is the point. The syntax is valid
                Message 7 of 12 , Aug 21, 2013
                • 0 Attachment


                  On Aug 21, 2013 1:42 PM, "Charles Campbell" <Charles.E.Campbell@...> wrote:
                  >
                  > LCD 47 wrote:
                  >>
                  >> ..snip..
                  >>
                  >>      +1 for this.  People routinely edit files that only make sense (and
                  >> will only ever run) on remote servers.  There are legitimate situations
                  >> where editing a file has nothing to do with actually running it.
                  >>
                  > Except, if its embedded in vimscript, then it is intended to be executed by vim.

                  But not necessarily *this* Vim, which is the point. The syntax is valid regardless of whether this Vim has been built to execute the syntax.

                  --
                  --
                  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
                   
                  ---
                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • Charles Campbell
                  ... Which again means: the writer of the script has no intention of testing it at the current time. Bad idea. Nonetheless, I ve have posted a new version at
                  Message 8 of 12 , Aug 21, 2013
                  • 0 Attachment
                    James McCoy wrote:
                    >
                    >
                    > On Aug 21, 2013 1:42 PM, "Charles Campbell"
                    > <Charles.E.Campbell@... <mailto:Charles.E.Campbell@...>> wrote:
                    > >
                    > > LCD 47 wrote:
                    > >>
                    > >> ..snip..
                    > >>
                    > >> +1 for this. People routinely edit files that only make sense
                    > (and
                    > >> will only ever run) on remote servers. There are legitimate situations
                    > >> where editing a file has nothing to do with actually running it.
                    > >>
                    > > Except, if its embedded in vimscript, then it is intended to be
                    > executed by vim.
                    >
                    > But not necessarily *this* Vim, which is the point. The syntax is
                    > valid regardless of whether this Vim has been built to execute the syntax.
                    >
                    >
                    Which again means: the writer of the script has no intention of testing
                    it at the current time. Bad idea.

                    Nonetheless, I've have posted a new version at my website and given a
                    copy to Bram several days ago.

                    --
                    --
                    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

                    ---
                    You received this message because you are subscribed to the Google Groups "vim_dev" group.
                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                    For more options, visit https://groups.google.com/groups/opt_out.
                  • Peter Prohaska
                    On Wed, Aug 21, 2013 at 7:52 PM, Charles Campbell ... Which again is not if someone asks you for a quick review of the code. -- -- You received this message
                    Message 9 of 12 , Aug 22, 2013
                    • 0 Attachment
                      On Wed, Aug 21, 2013 at 7:52 PM, Charles Campbell
                      <Charles.E.Campbell@...> wrote:
                      > James McCoy wrote:
                      >
                      >>
                      >>
                      >> On Aug 21, 2013 1:42 PM, "Charles Campbell" <Charles.E.Campbell@...
                      >> <mailto:Charles.E.Campbell@...>> wrote:
                      >> >
                      >> > LCD 47 wrote:
                      >> >>
                      >> >> ..snip..
                      >> >>
                      >> >> +1 for this. People routinely edit files that only make sense
                      >> >> (and
                      >> >> will only ever run) on remote servers. There are legitimate situations
                      >> >> where editing a file has nothing to do with actually running it.
                      >> >>
                      >> > Except, if its embedded in vimscript, then it is intended to be executed
                      >> > by vim.
                      >>
                      >> But not necessarily *this* Vim, which is the point. The syntax is valid
                      >> regardless of whether this Vim has been built to execute the syntax.
                      >>
                      >>
                      > Which again means: the writer of the script has no intention of testing it
                      > at the current time. Bad idea.

                      Which again is not if someone asks you for a quick review of the code.

                      --
                      --
                      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

                      ---
                      You received this message because you are subscribed to the Google Groups "vim_dev" group.
                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                      For more options, visit https://groups.google.com/groups/opt_out.
                    Your message has been successfully submitted and would be delivered to recipients shortly.