parsing comments in scripts

[Frank D. Engel, Jr.]

Yeah, I considered that contiguous-comment thing too for a time, but 
there is another issue here:

Consider this code:

--Hi, I am a comment!
on mouseUp
   unhilite me
end mouseUp
on mouseDown
   hilite me
end mouseDown

Not a particularly useful script, but notice the lack of blank lines 
between the handlers?  Now run the comment-script thing on the first 
handler:

----Hi, I am a comment!
--on mouseUp
--  unhilite me
--end mouseUp
on mouseDown
   hilite me
end mouseDown

And now, with the first one commented out, on the second as well:

------Hi, I am a comment!
----on mouseUp
----  unhilite me
----end mouseUp
--on mouseDown
--  hilite me
--end mouseDown


Do we begin to see the problem here?  From this stage, how do you 
uncomment the *first* handler (mouseUp)?


As for 'range comments', yeah, that's okay until you try to comment out 
a handler which already contains a 'range comment':

on mouseUp
   /* read this please */
   hide me
end mouseUp


/* on mouseUp
   /* read this please */
   hide me
end mouseUp */


I suspect what would happen here is for Rev to interpret the comment as 
beginning at /* on mouseUp and ending with please */, then
complaining about 'hide me'... not being in a handler, 'end mouseUp' 
which would end a handler which never started, and the extra
*/, which would terminate a comment which never got started.

Any attempt to implement this functionality will result in a 'best 
guess' approach.

You can decrease the likelihood of a problem by using unlikely 
character sequences to delimit the start and end of the handler, then 
watching for those when uncommenting the handler:

on mouseUp
   hide me
end mouseUp

becomes:

--$START_COMMENTED_HANDLER!!!!
--on mouseUp
--  hide me
--end mouseUp
--$TERMINATE_COMMENTED_HANDLER!!!!

Now the reversal function has something definite to look for.

On Dec 15, 2004, at 5:11 AM, Ben Rubinstein wrote:

> Alex Tweedly wrote:
>> If you want the editor to have an "uncomment the entire handler" 
>> command,
>> then it's going to need to look into comments, to see whether or not
>> removing the leading comment indicator would leave a line which could 
>> then
>> be a start / finish of a handler. Doesn't seem too bad to me - but I 
>> know
>> there were concerns about the interpreter (now the editor) looking at
>> comments and guessing about their meaning.
>
> Two possible solutions here (I didn't say either were pretty):
>
> * 'Comment Handler' finds the start and end of the handler that the
> insertion point lies in; and extends this range of lines to 
> incorporate any
> contiguous comment lines.  It then adds "-- " to the start of every 
> line in
> this range.  Hence:
>
>     -- a comment about foo
>     --
>     on foo x
>        -- put x into it
>        get x
>     end foo
>
> becomes
>
>     -- -- a comment about this
>     -- --
>     -- on foo x
>     --    -- put x into it
>     --    get x
>     -- end foo
>
> 'Uncomment Handler' then takes the contiguous range of commented lines 
> round
> the insertion point, and removes the initial "-- " from each one - thus
> restoring previous comments as they were.
>
>
> * we've got range comments now, /* */.  So 'Comment Handler' could 
> work like
> this:
>
>     -- a comment about foo
>     --
>     /* on foo x
>        -- put x into it
>        get x
>     end foo */
>
> Then 'Uncomment Handler' searches up and down from the insertion point 
> for
> some pretty easily recognised patterns: "/* on <label>" or "/* function
> <label>" up, and "end <label> */" down.  If these don't match, or it 
> finds
> strange variants out of order, then it does the best it can or gives 
> up and
> leaves the user to figure it out.  (I don't know whether /* */ comments
> nest; if not then Comment Handler should disable internal occurences, 
> eg
> changing to "/--*" and "*--/", and Uncomment Handler reverse this.)
>
> Whatever, I do think the concept that 'junk' should be acceptable 
> outside a
> handler is a dangerous hangover, and should be abandoned.  I used to 
> take
> advantage of this in HyperCard too (I stored data in scripts, since 
> they
> were effectively the only properties available for all objects) but 
> switched
> with relief to using custom properties in MC/Rev.  Since there's now a 
> real
> issue (the fact that some statements from inside a 'commented' handler 
> can
> take effect outside the handler) and we have range comments anyway, the
> worst that we're asking people to do, even if no additional 
> conveniences are
> provided in the script editor, is find the bottom of their handler to 
> add
> the close comment there.
>
> How about we just request a simpler Script Editor enhancement - jump 
> to end
> of current handler?
>
>   Ben Rubinstein               |  Email: benr_mc at cogapp.com
>   Cognitive Applications Ltd   |  Phone: +44 (0)1273-821600
>   http://www.cogapp.com        |  Fax  : +44 (0)1273-728866
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
-----------------------------------------------------------
Frank D. Engel, Jr.  <fde101 at fjrhome.net>

$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten 
Son, that whosoever believeth in him should not perish, but have 
everlasting life.
$



___________________________________________________________
$0 Web Hosting with up to 120MB web space, 1000 MB Transfer
10 Personalized POP and Web E-mail Accounts, and much more.
Signup at www.doteasy.com