Re: parsing comments in scripts
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: [EMAIL PROTECTED] Cognitive Applications Ltd | Phone: +44 (0)1273-821600 http://www.cogapp.com| Fax : +44 (0)1273-728866 ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution --- Frank D. Engel, Jr. [EMAIL PROTECTED] $ ln -s /usr/share/kjvbible /usr/manual $ true | cat
Re: parsing comments in scripts
on 15/12/04 2:19 pm, Frank D. Engel, Jr. wrote Not a particularly useful script, but notice the lack of blank lines between the handlers? Fair point - I guess that's a coding style that I've never run across, but it's certainly legal code. As for 'range comments', yeah, that's okay until you try to comment out a handler which already contains a 'range comment': That's why I suggested (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.) But fundamentally, my point is that having scripts compile with random junk in them is very 20th century, and we should no longer accept it. Everything else is just suggestions for how we can alleviate the, in any case not that great, loss of convenience for those who had got used to taking advantage of this to support a lazy way of commenting out a handler (a way which is already no longer safe, as has been observed). Ben Rubinstein | Email: [EMAIL PROTECTED] Cognitive Applications Ltd | Phone: +44 (0)1273-821600 http://www.cogapp.com| Fax : +44 (0)1273-728866 ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
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: [EMAIL PROTECTED] Cognitive Applications Ltd | Phone: +44 (0)1273-821600 http://www.cogapp.com| Fax : +44 (0)1273-728866 ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
Frank- Wednesday, December 15, 2004, 6:19:23 AM, you wrote: FDEJ Any attempt to implement this functionality will result in a 'best FDEJ guess' approach. Not necessarily. Most C compilers will have an option to allow nested comments. A simple IsInComment counter would allow this: start incrementing a counter at the first /*, decrement the counter at each */ and don't exit the comment processing until the count reaches zero. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On Dec 12, 2004, at 6:22 PM, J. Landman Gay wrote: I see the point people are making, but I'd sure miss the current behavior if it changed. The ability to comment out an entire handler by commenting the first line has been in xtalk for 18 years. I have become dependent on it. As Alex pointed out, it is really only an illusion for Transcript. It doesn't work. As for Hypertalk, my copy of Hypercard Script Language Guide: The HyperTalk Language says Statements always appear in handlers in a script. Any part of a statement following HyperTalk's double-hyphen comment character (--) is ignored by HyperCard. I read this as saying that the ability was not intended to be part of HyperCard. I am curious if others use the technique of commenting out a handler by commenting out the first line. Maybe there is a way to rescue this kind of thing in a clean way. Dar Yes I do use it occasionally, when I want to quickly disable a handler for debugging or somesuch purpose. If I want to disable a handler on a more long term basis I would comment the whole thing out. My habit is that I wouldn't actually save a stack with handlers commented out this way. As Jacqueline pointed out, this was a standard practise in Hypercard. And as you note Dar, in that environment there was really no problem with junk in the sense you mean because anything outside of a handler declaration was simply ignored, since there was no syntax at all that was valid outside a handler. On the slower machines of those days it was more efficient to disable a script by commenting one line than to comment the whole thing, which might also introduce enough characters to drive the script beyond the old length limit of 3 characters. I do wonder though how likely it is that you would comment : -- on whatever either accidentally or with any other purpose than disabling the handler ? Martin ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On 12/12/04 11:38 PM, Dar Scott [EMAIL PROTECTED] wrote: I am curious if others use the technique of commenting out a handler by commenting out the first line. Maybe there is a way to rescue this kind of thing in a clean way. Well, I know of at least one other person that does this, so it may have quite a following... perhaps commenting out the first line automatically comments out the whole handler? That is, when you close and reopen the script the handler is fully commented? Just a thought... Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On 12/13/04 10:15 AM, Dar Scott wrote: I would guess that HyperTalk did not have local, global or constant at the script level (outside of handlers), so there may not have been an issue. Exactly right, so the issue never arose. I do understand the problem you bring up. It may be that us old-timers have to evolve. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
If you found this to be so useful, why not submit a feature request? Maybe something like this would be in order: on handlerName is disabled or disabled handlerName or something like that. empty on handlerName ? On Dec 13, 2004, at 1:39 PM, J. Landman Gay wrote: On 12/13/04 10:15 AM, Dar Scott wrote: I would guess that HyperTalk did not have local, global or constant at the script level (outside of handlers), so there may not have been an issue. Exactly right, so the issue never arose. I do understand the problem you bring up. It may be that us old-timers have to evolve. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution --- Frank D. Engel, Jr. [EMAIL PROTECTED] $ 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 ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On 12/13/04 10:15 AM, Dar Scott [EMAIL PROTECTED] wrote: On Dec 13, 2004, at 7:12 AM, Ken Ray wrote: perhaps commenting out the first line automatically comments out the whole handler? That is, when you close and reopen the script the handler is fully commented? Like this? -- I wrote this -- on Christmas day -- when others were at play. local a on work local moss put a end work local b == -- I wrote this -- -- on Christmas day -- -- when others were at play. -- local a -- on work --local moss --put a -- end work local b No, like this: -- on work local moss put a end work == -- on work -- local moss -- put a -- end work The technique of commenting out the first line to disable the handler does not work in Transcript. You've said this a couple of times, but I have handlers where the first line is commented and the handler *is* disabled. Can you give an example of where this is not true? Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
At 13:43 13/12/2004 -0600, Ken Ray wrote: The technique of commenting out the first line to disable the handler does not work in Transcript. You've said this a couple of times, but I have handlers where the first line is commented and the handler *is* disabled. Can you give an example of where this is not true? There's an example (rather trivial one) in the Bugzilla entry (2468) A more serious one is on A local tLine end A on mouseUp B end mouseUp on B put original B string into tLine C put tLine cr after msg end B on C put the C version into tLine end C This prints out original B string to the message box. Comment out the first line of A, and it will now output the C version. The comment has disabled handler A, except for the local tLine statement, which has become script-local, and therefore changed the effect of the (implicit) declarations of tLine within B and C. So now the two handlers interfere with each other, when normally they wouldn't. -- Alex. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On 12/13/04 2:30 PM, [EMAIL PROTECTED] wrote: sez [EMAIL PROTECTED]: On 12/13/04 10:15 AM, Dar Scott wrote: I would guess that HyperTalk did not have local, global or constant at the script level (outside of handlers), so there may not have been an issue. Exactly right, so the issue never arose. I do understand the problem you bring up. It may be that us old-timers have to evolve. I think I see a possible solution. What if, whenever a user comments out the on HandlerName or function FcnName line of a handler, the engine automatically comments out the *entire* handler, down to and including the end [name of handler] line at the end? Obviously, *un*commenting the [functi]on HandlerName line should uncomment the entire handler. This way, not only can old-time HCers do what they've always done and get the same practical results, but it's a convenient shortcut for dyed-in-the-wool Rev'ers. Yes? No? Yup. We think alike; I just wrote something almost exactly the same in my last post. I think this would work very well. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On 12/13/04 1:11 PM, Frank D. Engel, Jr. wrote: If you found this to be so useful, why not submit a feature request? Maybe something like this would be in order: on handlerName is disabled or disabled handlerName or something like that. empty on handlerName ? That's more work. ;) The reason I use the top-comment disabling technique so much is because I often write two or three different versions of a handler, and then comment/uncomment them repeatedly until I decide which one I want to use. Sometimes this is for benchmarking, sometimes it is just because I'm experimenting with a different technique but I don't want to lose the original. It is very fast to click once and type a couple of hyphens. Dragging over the whole handler -- which can sometimes be very long -- and choosing a menu item is more work. Not that big a deal, but enough that I always choose the commenting method instead. But except for excessively long handlers, changing the text of the first line would probably be even more work, so would be less preferable than the drag-select-choose menuitem method. My ideal fix would be as Ken suggested: applying the script would automatically add comment characters to all the lines of the handler for me. Or perhaps we could simply choose comment from the menu, and it would automatically comment out all the lines of whatever handler the insertion point is currently in. That'd be okay with me too. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
sez [EMAIL PROTECTED]: On 12/13/04 10:15 AM, Dar Scott wrote: I would guess that HyperTalk did not have local, global or constant at the script level (outside of handlers), so there may not have been an issue. Exactly right, so the issue never arose. I do understand the problem you bring up. It may be that us old-timers have to evolve. I think I see a possible solution. What if, whenever a user comments out the on HandlerName or function FcnName line of a handler, the engine automatically comments out the *entire* handler, down to and including the end [name of handler] line at the end? Obviously, *un*commenting the [functi]on HandlerName line should uncomment the entire handler. This way, not only can old-time HCers do what they've always done and get the same practical results, but it's a convenient shortcut for dyed-in-the-wool Rev'ers. Yes? No? ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On 12/13/04 2:25 PM, Alex Tweedly [EMAIL PROTECTED] wrote: There's an example (rather trivial one) in the Bugzilla entry (2468) A more serious one is (snip) The comment has disabled handler A, except for the local tLine statement, which has become script-local, and therefore changed the effect of the (implicit) declarations of tLine within B and C. So now the two handlers interfere with each other, when normally they wouldn't. Thank you, Alex... I didn't realize that this would happen. Thanks for the clarification... Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
At 14:38 13/12/2004 -0700, Dar Scott wrote: On Dec 13, 2004, at 1:30 PM, [EMAIL PROTECTED] wrote: It may be that us old-timers have to evolve. I think I see a possible solution. The editor seems to know the limits of the handler (tab for formatting and handler oriented editing), so it should be able to comment out a handler. It does - in a fairly trivial way; --just do the current handler put word 2 of the selectedLine into tCurrentLine repeat with i = tCurrentLine down to 1 if word 1 of line i of fld script is among the items of on,setProp,getProp,function then exit repeat end repeat Maybe under the Script menu could be an item named Comment Handler. If a right click is added to the editor, then it could be there, too. I think it could. The problem would be in commenting it back in again. Of course, you could simply bail on that problem, and require the user to select the entire (commented) handler and select un-comment - but that requires the effort we said was undesirable (unacceptable) to comment it in the first place. 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. I think the failure modes here (at least, the ones I can think of) are fairly pathological; user comments out entire handler, then within that block partially removes a comment indicator such that the uncomment command selects the wrong start (or finish) line. -- Alex. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On Dec 13, 2004, at 7:12 AM, Ken Ray wrote: perhaps commenting out the first line automatically comments out the whole handler? That is, when you close and reopen the script the handler is fully commented? Like this? -- I wrote this -- on Christmas day -- when others were at play. local a on work local moss put a end work local b == -- I wrote this -- -- on Christmas day -- -- when others were at play. -- local a -- on work --local moss --put a -- end work local b A script local and a handler is lost by an inadvertent trigger in a comment. It currently works like this: This script with the first line commented... -- on work local moss put a end work ... is virtually compiled as though it like this... -- on work local moss -- put a -- end work ... inserting a script local variable. The technique of commenting out the first line to disable the handler does not work in Transcript. If this is fixed so '-- on xxx' patterns are recognized by the compiler, then the on Christmas day problem comes back. As a newbie, I was confused by some commands at the top of a script in an example stack. I thought maybe it was initialization. It turned out to be ignored by the compiler, left there for some reason by the script writer, perhaps long forgotten. Maybe it even had a commented out 'on' line, I don't remember. I would guess that HyperTalk did not have local, global or constant at the script level (outside of handlers), so there may not have been an issue. Dar Scott DSC ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On Dec 13, 2004, at 1:30 PM, [EMAIL PROTECTED] wrote: It may be that us old-timers have to evolve. I think I see a possible solution. The editor seems to know the limits of the handler (tab for formatting and handler oriented editing), so it should be able to comment out a handler. Maybe under the Script menu could be an item named Comment Handler. If a right click is added to the editor, then it could be there, too. Dar Dar Scott Consulting http://www.swcp.com/dsc/ Programming Services ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On Dec 13, 2004, at 1:36 PM, J. Landman Gay wrote: The reason I use the top-comment disabling technique so much is because I often write two or three different versions of a handler, and then comment/uncomment them repeatedly until I decide which one I want to use. This has the advantage in that if you want to use a few lines from the disabled one to include in another one, you don't have to uncomment the lines. My habit has been to select the entire handler and choose comment from the script menu; this has the problem that raided lines are commented. I suppose one could put a back tick in front of the name, but it would have to be done at the end, also. Dar Dar Scott Consulting http://www.swcp.com/dsc/ Programming Services ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On Dec 13, 2004, at 1:36 PM, J. Landman Gay wrote: Or perhaps we could simply choose comment from the menu, and it would automatically comment out all the lines of whatever handler the insertion point is currently in. Whoops. I didn't see that before I started harping on that idea. There is already a comment in the menu, so I was suggesting a separate menu item. It has the advantage of being able to comment out a handler from near the end, especially if only the tail of the handler is showing in the window at the time. Dar Dar Scott Consulting http://www.swcp.com/dsc/ Programming Services ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
Sun, 12 Dec 2004 22:38:41 -0700 Dar Scott wrote: I am curious if others use the technique of commenting out a handler by commenting out the first line. Maybe there is a way to rescue this kind of thing in a clean way. Dar I'm doing this for years and I guess I would have problems if this behavior would be changed. best Tariel ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
At 23:32 11/12/2004 -0700, Dar Scott wrote: On Dec 11, 2004, at 12:33 PM, Alex Tweedly wrote: I just think it should do what it says in the docs - make all the code between that line and the end myHandler be ignored / have no effect, equivalent to block-commenting the whole handler. I'm not comfortable with this. To do this, it would have to ignore everything from the commented out 'on' or 'function' line down to the 'end', including 'local', 'global' and 'constant' lines. To do this, it would have to know the line is a commented out 'on' or 'function'. To do this, it would have to look inside and parse the contents of comments. This violates the trust between the compiler and me. That which is in a comment belongs to me. And besides, what if I have a temporary first line commented out, or for some reason include on Christmas morning in some line of a comment. Yeah - it certainly has some difficulties. In some ways I don't care whether they change the docs or the app - I just don't like them disagreeing. It is straightforward to select the entire handler and select Comment from the script menu. An alternative might be to temporarily change the spelling of the name. That's what I've always done (since I didn't know about this feature), and what I intend to keep on doing - so I'll never (deliberately) use this feature, and hopefully I will never be affected by it. In this case, I don't think it's good enough to change the docs to reflect what the code does - because the current behaviour is a trap for the unwary. Often, I'll use the same (local) variable names within multiple handlers (e.g. tLine is a favourite of mine :-) If I were to use this feature, it would then change all those occurrences of tLine from handler-local to script-local - i.e. they are all the same variable - so hard-to-find bugs are all too possible. I'd prefer if they removed the feature entirely, or as you suggested used disabled or some such keyword rather than a comment, preceding the first line of the handler. -- Alex. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
Ken- Thanks for explaining the first line to me. Now I get it. I'm not in a panic anymore, but it's still bizarre. I'm sure someone thought it was a good idea at the time... more heavy medication, maybe? -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
Alex- Friday, December 10, 2004, 11:26:15 AM, you wrote: AT function StripComments theLine ATlocal theResult ATput token 1 to -1 of theLine into theResult AT if quote is in token -2 to -1 of theLine then put quote after theResult ATreturn theResult AT end StripComents Thanks for that. It pretty much does the job for me, although I have to handle C-style comments and line-continuation characters externally before the tokenizer has a chance to work. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On Dec 12, 2004, at 11:16 AM, Mark Wieder wrote: I would, too, now that Ken has set me straight on what the first line is. However, now that I understand what's involved in this, I'm rather apathetic to the whole thing since I don't intend to use this feature at all. I'm changing my bz comment to suggest removal. The feature is a by-product of the compiler ignoring top level lines that are not top level constructs or commands in Transcript. The problem is that local, global and constant in the handler that is disabled this way are pushed to the script level. Any attempt to fix that based on the comment syntax will have the compiler looking into comments. That means that though you do not intend to use this, you might accidently. Dar Dar Scott Consulting http://www.swcp.com/dsc/ Programming Services ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
Dar- Sunday, December 12, 2004, 10:39:19 AM, you wrote: DS The feature is a by-product of the compiler ignoring top level lines DS that are not top level constructs or commands in Transcript. Ah - so this feature is actually tied into your postings about junk in scripts? -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
Dar- Sunday, December 12, 2004, 2:04:10 PM, you wrote: DS And it also ties to recent discussion on parsing scripts. Should a DS preprocessor allow for uncommented junk at the top level, or should it DS assume a clean script? Well, for my own preprocessing purposes, anything not rigorously syntactically correct is an error. I suppose others may have differing needs. If nobody's said it yet, let me be the first to say that I think uncommented junk is still junk. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On Dec 12, 2004, at 5:19 AM, Alex Tweedly wrote: I'd prefer if they removed the feature entirely, or as you suggested used disabled or some such keyword rather than a comment, preceding the first line of the handler. My preference is to allow nothing at the top but but top level things, currently local, global, constant, on...end, function...end and comments. I'm ok with 'disabled' being at that top level if the handler is parsed or partially parsed. Currently, if I have a typo in funtion, then the script might compile without errors, but I'd be missing a function (and maybe a different one used) and have some constants and variables in script local that I didn't intend. Dar ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On 12/12/04 6:19 AM, Alex Tweedly wrote: Yeah - it certainly has some difficulties. In some ways I don't care whether they change the docs or the app - I just don't like them disagreeing. It is straightforward to select the entire handler and select Comment from the script menu. An alternative might be to temporarily change the spelling of the name. That's what I've always done (since I didn't know about this feature), and what I intend to keep on doing - so I'll never (deliberately) use this feature, and hopefully I will never be affected by it. I see the point people are making, but I'd sure miss the current behavior if it changed. The ability to comment out an entire handler by commenting the first line has been in xtalk for 18 years. I have become dependent on it. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On Dec 12, 2004, at 6:22 PM, J. Landman Gay wrote: I see the point people are making, but I'd sure miss the current behavior if it changed. The ability to comment out an entire handler by commenting the first line has been in xtalk for 18 years. I have become dependent on it. As Alex pointed out, it is really only an illusion for Transcript. It doesn't work. As for Hypertalk, my copy of Hypercard Script Language Guide: The HyperTalk Language says Statements always appear in handlers in a script. Any part of a statement following HyperTalk's double-hyphen comment character (--) is ignored by HyperCard. I read this as saying that the ability was not intended to be part of HyperCard. I am curious if others use the technique of commenting out a handler by commenting out the first line. Maybe there is a way to rescue this kind of thing in a clean way. Dar Dar Scott Consulting http://www.swcp.com/dsc/ Programming Services ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
Alex- Sunday, December 12, 2004, 4:19:27 AM, you wrote: AT I'd prefer if they removed the feature entirely, or as you suggested used AT disabled or some such keyword rather than a comment, preceding the first AT line of the handler. I would, too, now that Ken has set me straight on what the first line is. However, now that I understand what's involved in this, I'm rather apathetic to the whole thing since I don't intend to use this feature at all. I'm changing my bz comment to suggest removal. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On Dec 12, 2004, at 1:29 PM, Mark Wieder wrote: DS The feature is a by-product of the compiler ignoring top level lines DS that are not top level constructs or commands in Transcript. Ah - so this feature is actually tied into your postings about junk in scripts? Yes. And it also ties to recent discussion on parsing scripts. Should a preprocessor allow for uncommented junk at the top level, or should it assume a clean script? Dar Dar Scott Consulting http://www.swcp.com/dsc/ Programming Services ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
Alex- Saturday, December 11, 2004, 4:38:59 AM, you wrote: AT that says Tip: You can comment out an entire handler by commenting out its first line. Yikes! I really hope this isn't supposed to be true. I regularly put comments in the first line of my handlers as documentation. I'd hate to think that a 'fix' to some future version would break my code. The insertion of comments shouldn't have an effect on the execution of code. Comment added to bug #2468. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
At 10:18 11/12/2004 -0800, Mark Wieder wrote: Saturday, December 11, 2004, 4:38:59 AM, you wrote: AT that says Tip: You can comment out an entire handler by commenting out its first line. Yikes! I really hope this isn't supposed to be true. I regularly put comments in the first line of my handlers as documentation. I'd hate to think that a 'fix' to some future version would break my code. The insertion of comments shouldn't have an effect on the execution of code. Comment added to bug #2468. I'm not sure I see what you're worried about. Having a comment on the first line is OK, and will have no effect. A line like on myHandler pText-- deal with the new text is not going to be affected by this tip. But commenting *out* the line will have an effect on the execution of the code - just like commenting out any line of code would. If I take this fragment put 1 into a put 2 into b put 3 into c and comment out the second line to get put 1 into a -- put 2 into b put 3 into c then I've certainly affected the execution of that second line. So I don't see a bug problem with having -- on myHandler having some effect. I just think it should do what it says in the docs - make all the code between that line and the end myHandler be ignored / have no effect, equivalent to block-commenting the whole handler. (Currently it allows any local statements within the handler (probably also global statements though I haven't tested that) to take effect at the scope-level of the whole script. The same code without the handler line being commented out would have had those statements in the handler scope - so this can cause very nasty side-effects if the same variable names are used in other handlers in the same script. Another good reason to set explicitVariables to true !!) -- Alex. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On 12/11/04 12:18 PM, Mark Wieder [EMAIL PROTECTED] wrote: Alex- Saturday, December 11, 2004, 4:38:59 AM, you wrote: AT that says Tip: You can comment out an entire handler by commenting out its first line. Yikes! I really hope this isn't supposed to be true. I regularly put comments in the first line of my handlers as documentation. Don't worry, Mark... what it means is that this: --on mouseUp beep end mouseUp won't trigger, but either of these: on mouseUp -- beep now beep end mouseUp on mouseUp -- beep now beep end mouseUp will trigger just fine. Personally, I find just commenting the first line of a handler (like --on mouseUp) to be a bit sloppy IMHO and makes the script harder to read for me (I keep thinking there's some kind of mistake in the code which is why it isn't formatted properly; until I scroll up an see the commented on and then realize my mistake). But that's just my opinion... Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On Dec 11, 2004, at 12:33 PM, Alex Tweedly wrote: I just think it should do what it says in the docs - make all the code between that line and the end myHandler be ignored / have no effect, equivalent to block-commenting the whole handler. Maybe an alternative would be to allow the word 'disabled' in front of 'on' or 'function' to parse but not compile a handler. Dar Dar Scott Consulting http://www.swcp.com/dsc/ Programming Services ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On Dec 11, 2004, at 12:33 PM, Alex Tweedly wrote: I just think it should do what it says in the docs - make all the code between that line and the end myHandler be ignored / have no effect, equivalent to block-commenting the whole handler. I'm not comfortable with this. To do this, it would have to ignore everything from the commented out 'on' or 'function' line down to the 'end', including 'local', 'global' and 'constant' lines. To do this, it would have to know the line is a commented out 'on' or 'function'. To do this, it would have to look inside and parse the contents of comments. This violates the trust between the compiler and me. That which is in a comment belongs to me. And besides, what if I have a temporary first line commented out, or for some reason include on Christmas morning in some line of a comment. It is straightforward to select the entire handler and select Comment from the script menu. An alternative might be to temporarily change the spelling of the name. Dar ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
At 14:39 10/12/2004 -0700, Dar Scott wrote: Don't forget special parsing for this: format(... There's another special case to deal with; I just discovered the Tip in FAQ / How do I temporarily remove a portion of a script? that says Tip: You can comment out an entire handler by commenting out its first line. So does that mean that the rest of the handler IS a comment (and should be stripped out) or not ? Script colorizer doesn't think so - it colors the first line but not the rest. Script formatter does think so - it formats the rest of the handler flush left. Sadly, it turns out that the Tip is wrong - doing this does NOT comment out the rest of the handler; all it does is make it impossible to call the handler (this is not the same thing !!) Bugzilla 2468 has been entered. So I think you're free to deal with it almost any way you choose :-) - but you probably should deal with it explicitly. -- Alex. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
At 23:01 09/12/2004 -0800, Mark Wieder wrote: All- In the last few days I've started to realize how many ways comments and non-comments that look like comments can be embedded into lines of script code. In trying to get to what's actually code I've tried getting the offset of a -- string, which has complications if it is quoted. So I tried looking for quoted text and seeing if the comment was after quoted text - this also presents problems. We can have: #comment text --comment text more text -- still more text more text --comment text more text text -- text text more text text still more --comment (did I leave any out) text # comment and variants of that. I came across an interesting combination of tokens and words: tokens ignore comments, words don't make that distinction. However, the token delimiter isn't necessarily where I want it to be: put the tokens of put quote something quote --comment results in put something without the trailing quote. That's not quite what I see - I get just put something i.e. without either quote; that makes sense because once the line is tokenized, the quotes are unnecessary. But using tokens as counters and words to get the text works. Bizarre but true (AFAIKT). Sorry Mark, it won't work in all cases. In particular, any case where there are more tokens than words. put a+b into c has 6 tokens put a + b into c but only 4 words put a+b into c I don't have any suggestions, yet but it's an intriguing question, so I'll use it as an excuse to avoid gardening this afternoon :-) -- Alex. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
#comment text --comment text more text -- still more text more text --comment text more text text -- text text more text text still more --comment (did I leave any out) plenty :) although it may be that only MetaCard allows to use both quoting modes. from the above set text more text -- still more --comment same with hash text #comment text more text # still more text more text #comment text more text text # text text more text text still more #comment text more text # still more #comment mixed instances text more text # still more --comment text more text -- still more #comment I also use the following combinations to mark debugging code text text -- #comment text text #-- comment You could also consider other combo cases text more text --- still more #comment text more text -- still more -- still more #comment text more text -- # -- still more #comment text more text ### still more #comment In these cases it matters whether you first check for # or -- so you should really check both cases and see which has has lower offset. In general, I think you need to use the offset function for each line and check for either -- or # and count whether there is an even number of double-quotes before it (setting for example itemdelim to quote and get the item count). If count is odd, you are within literal and should continue. If count is even, then you hit a beginning of comment. I think this approach will work with all cases. Robert Brenstein ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
Robert Brenstein wrote: #comment text --comment text more text -- still more text more text --comment text more text text -- text text more text text still more --comment (did I leave any out) plenty :) although it may be that only MetaCard allows to use both quoting modes. Make that three: recently (v2.5?) they added support for multiline C-style comments: /* */ -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
RE: parsing comments in scripts
It may not be the fastest but its been quite reliable. This is the comment stripper for Transcriptolator. It removes the comments and THEN puts them back (optional...) It works line be line... hope it helps... cheers Xavier -- -- Comments Handlers -- a comment stripper rejoiner -- made to prevent comments translation -- left locally for local variable usage -- local commentdata on ClearLineComments put empty into commentdata[handler] put empty into commentdata[comment] put false into commentdata[has2ndcomment] put empty into commentdata[comment2] put true into commentdata[commentfinished] end ClearLineComments function StripComments aline local a,b local has2ndcomment,acomment2 ClearLineComments -- clean up aline repeat while char 1 of aline is delete char 1 of aline end repeat repeat while char -1 of aline is delete char -1 of aline end repeat put offset(/*,aline) into a put offset(*/,aline) into b if a 0 then if b 0 then put true into commentdata[commentfinished] get char a to b+1 of aline delete char a to b+1 of aline else put false into commentdata[commentfinished] get char a to -1 of aline delete char a to -1 of aline end if put it into acomment else if commentdata[commentfinished] is false then if b0 then -- middle of a comment put aline into acomment put empty into aline else -- end of comment if b0 then put char 1 to b+1 of aline into acomment if length(aline)b+1 then put char b+2 to -1 of aline into aline end if delete char 1 to b+1 of aline put true into commentdata[commentfinished] end if end if end if put offset(//,aline) into a if a 0 and offset(*/,aline) a then put true into commentdata[commentfinished] get char a to -1 of aline delete char a to -1 of aline put true into has2ndcomment -- finally if has2ndcomment is false then put it into acomment put false into has2ndcomment else put it into acomment2 put true into has2ndcomment end if -- this part is commented since this code was meant -- for not xtalk languages. untested... -- else ---- search for -- comments -- --put offset(--,aline) into a --if a 0 then -- get char a to -1 of aline -- delete char a to -1 of aline -- -- put true into has2ndcomment -- -- finally -- if has2ndcomment is false then --put it into acomment --put false into has2ndcomment -- else --put it into acomment2 --put true into has2ndcomment -- end if --end if end if repeat while char 1 of aline is delete char 1 of aline end repeat repeat while char -1 of aline is delete char -1 of aline end repeat put aline into commentdata[handler] repeat while char 1 of acomment is delete char 1 of acomment end repeat repeat while char -1 of acomment is delete char -1 of acomment end repeat put acomment into commentdata[comment] get has2ndcomment is true repeat while char 1 of acomment2 is delete char 1 of acomment2 end repeat repeat while char -1 of acomment2 is delete char -1 of acomment2 end repeat put it into commentdata[has2ndcomment] if it then put acomment2 into commentdata[comment2] return aline end StripComments function linewocomments -- return statement without comments return commentdata[handler] end linewocomments function LineComments get commentdata[has2ndcomment] if it then get commentdata[comment] commentdata[comment2] else get commentdata[comment] end if return it end LineComments function RestoreOrigComments local thisline,linecomment get commentdata[handler] into thisline put LineComments() into linecomment if linecomment is empty then return thisline else return thisline linecomment ClearLineComments end RestoreOrigComments ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
At 13:01 10/12/2004 +, Alex Tweedly wrote: At 23:01 09/12/2004 -0800, Mark Wieder wrote: I came across an interesting combination of tokens and words: tokens ignore comments, words don't make that distinction. However, the token delimiter isn't necessarily where I want it to be: put the tokens of put quote something quote --comment results in put something without the trailing quote. That's not quite what I see - I get just put something i.e. without either quote; that makes sense because once the line is tokenized, the quotes are unnecessary. Sorry - my error. I had already changed my script to investigate the case described later in my email (put a+b into c) So (naturally enough, with hindsight) using something like token N returns JUST the token itself, whereas token N to K returns the intervening delimiters, but not any trailing one. So we only need to restore any trailing quote, which is only needed if the final token started out being quoted, therefore function StripComments theLine local theResult put token 1 to -1 of theLine into theResult if quote is in token -2 to -1 of theLine then put quote after theResult return theResult end StripComents should do it OK. Seems to work for my simple testing so far - but there may be cases I haven't thought of yet. Unfortunately, it appears that token DOES include the C-style comment delimiters recently introduced, and they can be multi-line, so you'll need to do something more to deal with that. -- Alex. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
At 05:29 10/12/2004 -0800, Richard Gaskin wrote: Make that three: recently (v2.5?) they added support for multiline C-style comments: /* */ I love it when you get two, very different ways to create comments, and they can interact Any votes for how to interpret put asd /* comment -- this here */ def into msg Choices are 1. The /* starts a comment, so the -- is part of that comment, and the */ ends it; i.e. it is equivalent to put asd def into msg 2. The /* starts a comment, AND the -- starts a comment and everything after that is part of a comment - all the way to the end of the line. The script interpreter thinks version 1, while the script colorizer thinks something very close to 2. Sometimes it colors everything from the /* to the end of the line as a comment; other times it colors the /* and -- onwards (but not the word comment) -- Alex. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On Dec 10, 2004, at 1:28 PM, Mark Wieder wrote: RB In general, I think you need to use the offset function for each line RB and check for either -- or # and count whether there is an even RB number of double-quotes before it (setting for example itemdelim to RB quote and get the item count). If count is odd, you are within RB literal and should continue. If count is even, then you hit a RB beginning of comment. I think this approach will work with all cases. ... Yes - I was doing something complicated like that and hit on the tokens thing as a way to simplify and speed things up. Don't forget special parsing for this: format(... Dar DSC http://www.swcp.com/dsc/ Programming Services ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
Dar, thanks for the tip. Hugh On Dec 10, 2004, at 2:39 PM, Dar Scott wrote: On Dec 10, 2004, at 1:28 PM, Mark Wieder wrote: RB In general, I think you need to use the offset function for each line RB and check for either -- or # and count whether there is an even RB number of double-quotes before it (setting for example itemdelim to RB quote and get the item count). If count is odd, you are within RB literal and should continue. If count is even, then you hit a RB beginning of comment. I think this approach will work with all cases. ... Yes - I was doing something complicated like that and hit on the tokens thing as a way to simplify and speed things up. Don't forget special parsing for this: format(... Dar DSC http://www.swcp.com/dsc/ Programming Services ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
Alex- Friday, December 10, 2004, 5:01:53 AM, you wrote: (did I leave any out) AT text # comment AT and variants of that. ...yes, I was thinking of # and -- as interchangeable here. put the tokens of put quote something quote --comment AT That's not quite what I see - I get just AT put something AT i.e. without either quote; that makes sense because once the line is AT tokenized, the quotes are unnecessary. My bad typing - I left out the parens. Make that put the tokens of (put quote something quote --comment) AT Sorry Mark, it won't work in all cases. In particular, any case where there AT are more tokens than words. AT put a+b into c ... dang operator tokens... back to the drawing board... AT I don't have any suggestions, yet but it's an intriguing question, so AT I'll use it as an excuse to avoid gardening this afternoon :-) Well, winter itself (or December) should be a good excuse. Me, I was happy to get some greens in the ground before the rains started. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
Richard- Friday, December 10, 2004, 5:29:33 AM, you wrote: RG Make that three: recently (v2.5?) they added support for multiline RG C-style comments: /* */ Right. I forgot to mention those. I have to handle those separately, of course, because they can and usually do cover multiple lines. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
Robert- Friday, December 10, 2004, 5:22:49 AM, you wrote: RB In these cases it matters whether you first check for # or -- so you RB should really check both cases and see which has has lower offset. I don't think so. They're interchangeable at that level. RB In general, I think you need to use the offset function for each line RB and check for either -- or # and count whether there is an even RB number of double-quotes before it (setting for example itemdelim to RB quote and get the item count). If count is odd, you are within RB literal and should continue. If count is even, then you hit a RB beginning of comment. I think this approach will work with all cases. Yes - I was doing something complicated like that and hit on the tokens thing as a way to simplify and speed things up. I'll probably have to go back that way again. BTW - the item count thing won't work because you still don't know the order, especially in cases where there are multiple quotes and/or possible comment chars. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: parsing comments in scripts
On Dec 10, 2004, at 12:26 PM, Alex Tweedly wrote: Unfortunately, it appears that token DOES include the C-style comment delimiters recently introduced, and they can be multi-line, so you'll need to do something more to deal with that. I missed most of this. I'll just throw in this comment to consider in parsing: /* */ style comments form intra-command whitespace, not inter-command whitespace; they cannot take the place of a ; or a lf, even if they include a lf. Dar Dar Scott Consulting http://www.swcp.com/dsc/ Programming Services ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
