Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Line continuation: A method to divide up long lines.


  • Please log in to reply
25 replies to this topic
  • Guests
  • Last active:
  • Joined: --

Even if it has to be the beginning of the line, it's still not very unique...the Text could contain a closing paren on it's own line, say if you were using an ahk script to generate an ahk script.

If you still think so, I could use clarification.


Hehe... didja read my post, directly before yours? I had some answers there too.


Anyway, I just had another idea. How about something like this:

Fileappend, (qwerty), somefunkyname.vbs

(qwerty `n
  ...vbs script code...
)

Using that, the "(qwerty `n" line would act more like a label, and it could be anywhere in the script. It could also be conditional, using if commands, and it would allow on-the-fly transformation of the script and it's routines. I think this is quite flexible, I'm not sure about the implementation of it. Also, you could make it like this:

Fileappend, (), somefunkyname.vbs
(`n
 ...vbs script code...
)

In which case it would have to be directly below it, just in case one didn't want to deal with labeling, placement, and all that cal.

With everything above, I also still think the "(" and the ")" should still be configurable via a processing directive "#" at the start.

  • Guests
  • Last active:
  • Joined: --

the Text could contain a closing paren on it's own line, say if you were using an ahk script to generate an ahk script.


You mean specifying a parenthese-enclosed multi-line inside a command, that, itself, generates a multi-line?

...what? huh? "parenthese-enclosed multi-line inside a command"? Did you mean the below?...

Even if it has to be the beginning of the line, it's still not very unique...the Text could contain a closing paren on it's own line, say if you were using an ahk script to generate an ahk script.

If you still think so, I could use clarification.


GuiCode.ahk...

Gui, Add, ListBox,, Item1|Item2|Item3
(
     |Item4|Item5|Item6
     |Item7|Item8|Item9
)

CreateGuiCode.ahk...

FileAppend,
(
Gui, Add, ListBox,, Item1|Item2|Item3
(
     |Item4|Item5|Item6
     |Item7|Item8|Item9
)
)
, GuiCode.ahk
Run, GuiCode.ahk
Sleep, 750
FileDelete, GuiCode.ahk
...this is using an ahk script to write an ahk script. I might've messed up your paren syntax, but that's not the point...I'm not sure how I'm supposed to deal with the paren'd param being before the end of the params, so I did the paren'd param, then continued the params.

before you say "that will break scripts that do use begin as the text to display" simply look for an end tag & if you don't find one, don't give an error, just revert to the old way & display the word begin

That seems like a good system, but I wanted something easy to implement and small in code size. It would be easy if AHK were purely interpreted, and that's probably what you were assuming.

...how is it done if it's not a runtime step thru (I didn't read Performance yet, but I'm going to, if the answer is there you can disregard this question)? Could you do some preloading & some step thru? Why does code size increase by stepping thru? In the preloader you could give yourself runtime hints, so the runtime don't have to backtrack, like if the preloader sees a << then never finds the end, have the preloader make some note of it for the runtime, perhaps by rewriting it to be escaped `<< Why is there a preloader & a runtime, isn't going thru the file twice worse for performance?

Hehe... didja read my post, directly before yours? I had some answers there too.

...that Guest was not me. Guest if you meant the stuff in a different language, then no, no one read it, it's not in english.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

Hehe... didja read my post, directly before yours? I had some answers there too.

Yes I saw it. Thanks.

How about something like this:
Fileappend, (qwerty), somefunkyname.vbs
(qwerty `n
...vbs script code...
)

That's an interesting variation.

Using that, the "(qwerty `n" line would act more like a label, and it could be anywhere in the script. It could also be conditional, using if commands, and it would allow on-the-fly transformation of the script and it's routines.

Probably getting too complicated. After all, 90% of the value of this whole proposal is just to have a line continuation mechanism, which does not add any new functionality. All it does is make scripts more readable and easier to write.

Also, you could make it like this:
Code:
Fileappend, (), somefunkyname.vbs
(`n
...vbs script code...
)

Seems quite usable.

With everything above, I also still think the "(" and the ")" should still be configurable via a processing directive "#" at the start.

It adds complexity because the user could choose characters that are legal in variable names. Still, if the paren approach adopted, maybe it can be allowed "at own risk" if it doesn't add to much overhead.

CreateGuiCode.ahk...

I see what you mean now, thanks for clarifying it. Of course, it would be extremely rare that someone would want to have a script build another script with telescoping continuation sections like that, and it could be worked around simply by not using line-continuation in one of the scripts. Still, it's another disadvantage that gives more weight to the alternate parameter-based approach.

Why does code size increase by stepping thru?

At this stage, it's hard to say for sure that it would.

Why is there a preloader & a runtime, isn't going thru the file twice worse for performance?

It reads the file only once. When reading, each line is pre-parsed and transformed into a command number and a series of memory addresses corresponding to the variables and parameters involved in the line. Once all the lines are in memory in this compressed form, the script begins executing. If the script's flow of control ever repeats a section more than once (such as a Loop or hotkey subroutine), performance savings begin to accrue. For a loop with 1000 iterations, the performance of having to "interpret" the lines inside the body only once (upon loading the file) rather 1000 times can be very large depending on the nature of the commands inside.

Thanks to everyone for all these ideas. I think the parameter-based idea has considerable advantages over the simple merge-these-lines-with-the-above-line idea. So if it's not too much more complex (both for usability and code complexity), it should probably be done that way.

Feel free to post more replies if you have the time and interest. For example, I still would like to see it support modes such as the following:
1) each linebreak becomes `n, `r`n, a space, or nothing at all (i.e. straight concatenate)
2) whether leading whitespace should be ignored in each line of continuation text.

  • Guests
  • Last active:
  • Joined: --

With everything above, I also still think the "(" and the ")" should still be configurable via a processing directive "#" at the start.

It adds complexity because the user could choose characters that are legal in variable names. Still, if the paren approach adopted, maybe it can be allowed "at own risk" if it doesn't add to much overhead.

...if someone wants to cause problems by picking dumb chars, let em, just have it spew errors at them or you could define safe chars & let em pick any subset of those. My comment is only about being able to use directives to configure things, I still don't generally like the paren idea.

Thanks to everyone for all these ideas. I think the parameter-based idea has considerable advantages over the simple merge-these-lines-with-the-above-line idea. So if it's not too much more complex (both for usability and code complexity), it should probably be done that way.

...do you mean my begin/end param method or his () or (qwerty) method?

Feel free to post more replies if you have the time and interest. For example, I still would like to see it support modes such as the following:
1) each linebreak becomes `n, `r`n, a space, or nothing at all (i.e. straight concatenate)
2) whether leading whitespace should be ignored in each line of continuation text.

...both of my ideas support a flags param, the << method (that don't seem like it's going to happen) supported <<% to have it parse vars, it could be expanded to <<`n to do line breaks or <<%`n to do both. Basically it's just a flags section, that can be expanded to have any flags to do anything. Ditto for my begin/end method, one syntax has the flags before the word begin...%begin...the other has it after...begin%. This flags section is supposed to be the same expandable section as the other one...begin`n...begin%`n

Flags
%__________Parse for vars
`n or `r`n___lMake line breaks be `n or `r`n
s__________llMake line breaks be a space
S__________-Strip line breaks
W__________Strip leading whitespace
...maybe even...
[chars]______lMake line breaks be chars

Examples
begin_______lNo number or flags, preserve all
begin123____lAny number, no flags, preserve all
begin1%____-Any number, % flag, parse for vars
begins______lNo number, s flag, change line breaks to spaces
begin1s_____lAny number, s flag, change line breaks to spaces
beginS______lNo number, S flag, strip line breaks
begin[123]___No number, [chars] flag, change line breaks to chars, in this case 123...default with no flags, my idea is supposed to preserve everything, because mine isn't a line continuation method, it's an "include arbitrary text here" method, that text being included without any changes.

I was just thinking of how my begin/end would deal with an ahk script writing an ahk script, that had begin/end tags in it & it would be fine, because the number don't have to be in order, you can use any number, so if the script you're including uses end1 thru end9 just use end12345 & it's unique. You can also use just plain begin/end throughout your script, because the number only comes into play when nesting, so you wouldn't need to think of an unused number each time you do a begin/end.

Going back to the subject of being able to use directives to control things, if you do the begin/end method, you should include the #BeginFormat/#EndFormat directives, then people can use other words besides begin/end & pick where they want the number & flag params. If someone picks a dumb format here, let it be their problem, don't sacrifice configurability for the few who would be dumb with it.

jonny
  • Members
  • 2951 posts
  • Last active: Feb 24 2008 04:22 AM
  • Joined: 13 Nov 2004

...if someone wants to cause problems by picking dumb chars, let em, just have it spew errors at them


There's this new thing called program development, it's all the rage. It's where we actually try to fix errors. Sound fun? :D

I was just thinking of how my begin/end would deal with an ahk script writing an ahk script, that had begin/end tags in it & it would be fine,


A string like "(" or ")" wouldn't have trouble with that either. Imagine this scenario:

FileAppend, (), funkymultiline.ahk
(`n
blarg i am code!
FileAppend, (), somefunkyname.vbs
(
blarg i am more code!
)
)

In this case, the extra "(" would tell the script to negate the next ")" it found. That wouldn't be too hard to implement, at least I don't think so.

If someone picks a dumb format here, let it be their problem, don't sacrifice configurability for the few who would be dumb with it.


I respect your opinion (and the right to say it), but are you listening to yourself? Isn't it a bit stupid to only appeal to people who can use something very well? How would we ever learn? Don't get me wrong, I'm all for configurability, but if we start letting BIG problems like ambiguity and complexity slide, this excellent program will go downhill. Fast. Avalanche-style.

And btw, don't get me wrong guest, you're suggesting some great ideas, I just disagree with you on some key points here. For instance, I like the #BeginFormat and #EndFormat, (The range of available characters would be quite limited, however) but I personally would still be more comfortable with a default of "(" and ")".

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

If someone picks a dumb format here, let it be their problem, don't sacrifice configurability for the few who would be dumb with it.

I respect your opinion (and the right to say it), but are you listening to yourself? Isn't it a bit stupid to only appeal to people who can use something very well?

In this particular case, I think Guest is probably right. Flexibility seems more important than protecting users against simple mistakes in this case.

I suspect Guest has more experience in these types of issues than I do. Therefore, I value his/her advice, as well as yours and the others'. My original plan wasn't nearly as good as what you all have come up with.

...do you mean my begin/end param method or his () or (qwerty) method?

I meant both, because they're both different than what I originally had in mind.

it could be expanded to <<`n to do line breaks or <<%`n to do both.

That's good.

And thanks for your description of begin/end options and usage.

In the following example I'll use the << method since it seems to be more self-documenting. Also, I think for simplicity it might be best to restrict it to one expanded parameter per line, since the need for two or more seem extremely rare.
FileAppend, Some arbitrary text.`n<<`nEnd`n, Filename.txt
     First line of text.
     Second line of text.
End
Consider the first parameter in the top line (since the second parameter is ordinary). It contains ordinary text up until the << flag. When the loading-routine sees the flag, it initially assumes it's a parameter extension and not literal text.

It sees the `n after the << and will use linefeed for every line-break. Then it sees the word "End" and will use that as the marker (the `n after the word End is a literal/ordinary linefeed that will be written to the file).

So now it scans ahead in the file looking for the end-marker (if not found, it goes back and considers the <
Literal accents might also be an issue. If accents are all treated as literal, chars such as `r and `n would not be possible in the text (but this is probably not much of a concern for most usages, so can probably be left as-is).

One of the big questions that remains for me is what the default behavior should be, among the following options:
Linebreaks become `n vs. `r`n vs. space vs. nothing.
Percent signs and accents are treated literally vs. as variables.
Leading and trailing whitespace omitted vs. included (omitted seems best).

Also, if there is a mode that includes leading whitespace, filtering out the indentation might become a problem. Perhaps it's best in that mode to assume that all leading whitespace is literal.

  • Guests
  • Last active:
  • Joined: --
Is there a solution to this thread?

I though it was a good idea, and I thought the discussion was going down the right path.

TIA!

jonny
  • Members
  • 2951 posts
  • Last active: Feb 24 2008 04:22 AM
  • Joined: 13 Nov 2004
Dynamic variables would probably cover this, and I understand those are a relatively high priority right now. It's not quite the same, but would fill some of the same needs.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Line continuation and wildcards are both a high priority. As for dynamic variables, if you mean the ability to execute command(s) dynamically -- such as ones read in from an INI file or the registry -- that will probably be longer in coming.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
The means of dividing up a long line into short ones has finally been added. However, it's not as elaborate as some of you had proposed. This is because upon further reflection, these more complex methods -- though flexible and useful -- didn't seem to have enough benefit to justify the added code size and complexity. However, this doesn't rule out the possiblity of doing something like them in the future.

For details, see line continuation.

tank
  • Administrators
  • 4345 posts
  • AutoHotkey Foundation
  • Last active: May 02 2019 09:16 PM
  • Joined: 21 Dec 2007
In the end i love php over all others but it has some Caveats
even tho Chris has chosen to implement a line continuation strategy that is very different from anything we see in vb or php or even javascript or java for that matter. we have to remember one thing
This is a New scripting language that is not just another spiffy duplication of others. it is geared for new scriptors and hobbiests.any programmer can do almost anything in ahk without ahk. but lets face it it took us all a bit of effort to learn the language and then we ended up able to pick the others up because they all basically do the same crap a different way.
AHK gives non programers a way to control windows and programs in easy to understand methods. it does it in very different ways from other languages and has some truly inventive shortcuts to others.
I have to say if i had only the most basic programming experience and i were learning line continuation for the first time i would find this implementation the most intuitive. i might even find options in php << ....
mline
or vb
"multi " _
& "line 2"

a bit bizarre and go on long rants about it
I would like to express my sincere admiration for Chris's ability to go past his experience to the eyes of the non programmer in implementing new ideas
Never lose.
WIN or LEARN.