Vote on the default behavior for line splitting/continuation

The ability to split a long line into a series of smaller ones was recently added. The part of it that's most uncertain is whether to omit leading spaces and tabs from the beginning of each line. The answer to this probably depends solely on how it will be used most often, which is difficult to predict.

I'd envisioned that the continuation section should support copy & paste from other files, and thus would seldom be indented. It might make scripts a little ugly looking, but has the advantage of preserving "what you see is what you get", while also avoiding the need to indent every line (I know some editors have the ability to mass-indent, but perhaps that isn't something the typical user is in the habit of doing).

So could the real issue here be how often users would want to indent the continuation section to make it look nice? Perhaps this depends on how long the typical continuation section will be. Really long ones would clearly be more tedious to keep indented; but short ones consisting of only a few lines would clearly look better indented.

A couple of examples:

if x > 1
{
    FileAppend,
    (
        An continuation section with only a few lines
        would usually look better indented (though the
        indentation would not be an actual/literal part
        of the text).
    ), C:\My File.txt
}

::hotstring::
(
    This is the replacement text. An argument
could be made that it's more intuitive for hotstrings
to be "what you see is what you get".
    Note: The default continuation behavior for
hotstrings could be different than that of other
continuations.
)

Your votes and comments will be appreciated.

I go with Rajat, LTrim should be default.

I'm not sure if this is a good idea (or useful at all):
LTrim could be extended with a number. Default is LTrim0 (or LTrim), even if not meantioned. With a number greater than 0 each line will get filled up with "number"s of spaces at the beginning, independent of the indentation in the code.

BTW: Do the parentheses have to be the first character in their line?

I voted 1st.

LTrim could be extended with a number. Default is LTrim0 (or LTrim), even if not mentioned. With a number greater than 0 each line will get filled up with "number"s of spaces at the beginning, independent of the indentation in the code.

It's an interesting idea and if you or anyone can think of a real-world use for it, that would help justify it.

Do the parentheses have to be the first character in their line?

Yes (but there can be spaces and tabs to their left).

By the way, I remembered another piece of info that might help other voters: the intent of line continuation is something like the

 section in HTML.  Since HTML isn't indented as often as a script, the analogy isn't perfect.  But anyone who's used the 
 section a lot can see how preserving indentation can be useful for some tasks (but perhaps these tasks wouldn't form a majority).
					
					

					
				

The

 tag analogy is useful to me. As much as I want scripts to look nice, I prefer the idea of WYSIWYG as it keep things simple. Maybe a character could be used with the brackets to indicate the indentation is to be ignored? I like the idea of hotstrings being WYSIWYG by default with the option of ignoring indentation elsewhere in scripts.
					
					

					
				

LTrim could be extended with a number. Default is LTrim0 (or LTrim), even if not mentioned. With a number greater than 0 each line will get filled up with "number"s of spaces at the beginning, independent of the indentation in the code.

It's an interesting idea and if you or anyone can think of a real-world use for it, that would help justify it.

2 examples:
1) The script is used to write another script with specific indentation.
2) The script writes a formated file, but the indentation of the script is different then the format that needs to be used in the file.

I voted for Number 1.
There must be another way to write formated text
to an file other than to be preformat it within the script.
There may be to much error-possiblities.

Also, what is with writing text contained in variables, lists, arrays ?
Maybe there is the possibility to use something like
format-Strings, that format the output that is written in
a predefined way:

FileAppend,
(
An continuation section with only a few lines
would usually look better indented (though the
indentation would not be an actual/literal part
of the text).
), "{space}:12" ,C:\My File.txt

would mean to write the lines, but before each line write 12-Spaces

I also think of something like a format-String
Here an example (pseudo-code, because I am a AHK-newbie):

DummyArray = 2.4.1987|9.3.04
loop, 2
{
Fileappend, DummyArray%A_index%`n , "00d2.00d2.2000d4", My File.txt
}

would result in:
02.04.1987
09.03.2004

It only is an idea, and the above example was only
created to show what I think of.
Sorry if this is bullshit, but if I see a problem I think on an solution.

...), "{space}:12" ,C:\My File.txt
would mean to write the lines, but before each line write 12-Spaces

2 examples:
1) The script is used to write another script with specific indentation.
2) The script writes a formated file, but the indentation of the script is different then the format that needs to be used in the file.

Thanks. Perhaps a new feature should be added that adds a prefix to each line. For example, the option Prefix`t`t`t would insert three tabs in front of each line. Does this fall short of your idea in any way?

There must be another way to write formated text to an file other than to be preformat it within the script.

You could manually specify your own indentation as in this example:

if x > 1 
{
    FileAppend,
    (LTrim
        `t`tFirst line.
        `t`tSecond line.
    ), C:\My File.txt
}

I also think of something like a format-String
Here an example (pseudo-code, because I am a AHK-newbie):
Fileappend, DummyArray%A_index%`n , "00d2.00d2.2000d4", My File.txt

It's a good idea to offer some kind of number formatting beyond SetFormat. Perhaps someone could write a function to do it; if there is enough demand, it could become a built in function someday.

I voted 2. Long match lists are hard to read on the forums and in editors, and I think the priority is to make scripts easier to read/edit/write:

Loop
{
  Input Key, L1 V, 
(
{ScrollLock}{CapsLock}{NumLock}{TAB}{Esc}{BS}{Enter}{PrintScreen}{Pause}
{LControl}{RControl}{LAlt}{RAlt}{LShift}{RShift}{LWin}{RWin}
{F1}{F2}{F3}{F4}{F5}{F6}{F7}{F8}{F9}{F10}{F11}{F12}
{Left}{Right}{Up}{Down}{Home}{End}{PgUp}{PgDn}{Del}{Ins}
), cnt++
}

On a different note, perhaps for the above example there could be an %A_Key% variable to avoid typing out all of the keys with this Input command?

perhaps for the above example there could be an %A_Key% variable to avoid typing out all of the keys with this Input command?

That sounds interesting. Perhaps an option could be added to Input that makes all keys that don't produce a visible character become end keys.

Perhaps an option could be added to Input that makes all keys that don't produce a visible character become end keys.

great!

I voted #2

perhaps for the above example there could be an %A_Key% variable to avoid typing out all of the keys with this Input command?

That sounds interesting. Perhaps an option could be added to Input that makes all keys that don't produce a visible character become end keys.

This would be useful I think. I was thinking something more on the lines of any key being the end key:

Input, key, L1 V * ; asterix for the any key "wildcard"
  msgbox, you pressed %key%

; or

Input, key, L1 V, %any_key%
  msgbox, you pressed %key%

I was thinking something more on the lines of any key being the end key.

Thanks. I assume you mean any key at all, not just ones that fail to produce a visible character when pressed. Although there doesn't seem to be much benefit to this (since specifying L1 seems like it would have the same effect), it might be more convenient and intuitive to have the option anyway.

Hi,

what are you thinking about a directive like this:

#LineContinuation LTrim

Another problem might be if you like to indent manually and you have something like LTrim. For this a special character would be nice which also can be defined using a directive:

#LineContSeperator -

So a file append can look like this:

#LineContSeperator -

FileAppend,
(
   -This is my first try.
   -All of this is left bounded, but
   -   this line isn't...
), myoutfile.txt

NiWi.