Facility to skip portions of script

[IanB]

Try this http://avisynth2.sourceforge.net/avisynth2572.zip

[Fizick]

Nested comments is interesting.
But why both nested and not nested?

[check]

The only concern I have with [* *] is that it's very unusual and will take me a while to get used to. If /* */ is included as well hopefully everyone will just use the latter instead

[IanB]

Originally Posted by Fizick

But why both nested and not nested?

So people can experiment, experience and comment on both philosophies.

Originally Posted by check

... concern I have with [* *] is that it's very unusual ...

I needed 2 distinct tokens to make both nested and first drop comments available together in the one version. The choice at this point is purely arbitary.

Now is the time to speak up. Make a proposition and argue your case.

[Leak]

Originally Posted by IanB

Now is the time to speak up. Make a proposition and argue your case.

Is there even any reason for non-nestable comments? If you don't want to nest comments you can just not do it...

But it's always a pain in the rear end to comment out bigger parts of code that happen to already have a block comment - like they're often used to document functions and the like, after all...

A vote for nested comments from me.

[Fizick]

Probably one nested will be enough (if it is not very hard for parser to process complex multi-level scripts).
I tried a new avisynth version a little.
Seems, it works fine.

Let's comment all!
IMO it is the greatest addition to avisynth language for recent years!
The previous was KillVideo of course (I can not appraise the mysterious OPT_UseWaveExtensible)

[gzarkadas]

I like having both alternatives. They are useful on different occasions. The interaction with strings must be thinked of more though IMHO. The following script:

[*
s = " [* "
*]
BlankClip().Subtitle("OK")

gives error "nestable block comment missing closing *]", which I believe it would suprised most people of Avisynth user base that are not inclined in programing.

Perhaps string contents should not be examined for starting or terminating comment characters, as they currently do not for single line # comments.

[IanB]

@gzarkadas,

Yes, sprung! The current code has been thrown together rather quickly to explore the concept. You will also find a comment closing inside a string trips up as well.

This is where we need to define some grammar rules with hierachy and how this most usefully will work.

[Fizick]

So, in this beta version we can not use comment symbols in string.
In this case we probably can replace comment block symbols to combination not-permitted in strings (and more long):
[""" for comment opening
"""] for comment closing

It is not perfect but more rarely occures.

[3ngel]

I am looking forward for a facility like /* */ of C++

Wow, now i remember i wanted to open this thread many time ago, but then i forgot

BTW, i would be very happy if avisynth would implement the C++ /* */ comments.
MANY times i've had the situation to comment out many lines, and i had to type # and type... and type... and type... and type...

Any news about this?
Sorry if i'm late or if it's already developed

OPS: I forgot an important, i think the /* */ is the best because some of avs users are programmers, and so it's good to the non programmers to just adapt them to the C++ language in some way eheheh

[esby]

Is // assigned to something currently in avisynth?

Could it be used as an alternative to # single line comments ?

esby

[Fizick]

IMO, adding // will broke compatibility without any real need.

here is my version to try:
http://avisynth.org.ru/tmp/avisynth258_comments.zip

[" "] nested block comments
/""" """/ not nested

this way we can use nested comments in complex string (with tripled doublequote) for Eval, subtitle, etc.

[stickboy]

Originally Posted by 3ngel

MANY times i've had the situation to comment out many lines, and i had to type # and type... and type... and type... and type...

You need a better text editor.

In TextPad, for example, I can select the lines, hit Ctrl+Q,B to enable block-selection mode, then go to Edit > Fill Block. And then to undo it, I could enable block-selection mode, highlight the # characters, and just hit delete.

Or as I mentioned a the very beginning of this thread, it's trivial to wrap the relevant lines in a function.

[stickboy]

Originally Posted by esby

Is // assigned to something currently in avisynth?

Could it be used as an alternative to # single line comments ?

I agree with Fizick. It doesn't offer new functionality and just restricts the grammar. Multiple ways to do things isn't always good.

[Didée]

Originally Posted by stickboy

In TextPad, for example, I can select the lines, hit Ctrl+Q,B to enable block-selection mode, then go to Edit > Fill Block.

Somewhat cumbersome for my taste, since you need to Ctrl+Q,B once more to quit block-selection mode again. I prefer Alt+draggin' (press down Alt before using the mouse button).

[IanB]

@Fizick, Ahhggggg! You just changed the strings, you didn't fix my code

Parse this

/"""
BlankClip()
SubTitle("""/ is the "divide" character""")
"""/

As I said

Originally Posted by IanB

This is where we need to define some grammar rules with hierachy and how this most usefully will work.

In C // seems to have the highest lexical priority followed by /* , i.e. // /* does not start a block comment. And nothing protects or masks a */ and the nearest C has to nestable comments is #if 0, #endif.

This model does not seem to be what people want. We struggle to express clearly how we want the grammar to work. Less coding more deep thinking needed here.

[smok3]

from a nonprogramer; i do like a # button in AVSedit 1.1.0.0

[gzarkadas]

Originally Posted by IanB

This is where we need to define some grammar rules with hierachy and how this most usefully will work.

The existing behavior is that everything inside a string is preserved, even a comment character (#); once a " or """ is found the tokenizer skips everything until a matching closing " or """ is found.

Thus, IMHO, the tokenizer when searching for a matching closing block comment should skip entirely string literals, with the existing rules (which allow inserting a "" string inside a """ string). Anything else would break the established from the current behavior user expectations.

[IanB]

@gzarkadas, How would you parse this

/* """ */

How is it different from this

# """

[Bidoche]

easy : "/*" *(. - "*/") "*/"