> 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

... 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 2 of 12
, Aug 21 10:42 AM

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

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 3 of 12
, Aug 21 10:48 AM

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 4 of 12
, Aug 21 10:52 AM

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

> 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