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 -- b...@moolenaar.net -- 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
