AutoHotkey Community

It is currently May 27th, 2012, 1:21 pm

All times are UTC [ DST ]




Post new topic Reply to topic  [ 33 posts ]  Go to page 1, 2, 3  Next

Which line splitting behavior do you expect to use most often?
Spaces and tabs at the beginning of each line should be omitted by default.
Spaces and tabs at the beginning of each line should be retained (as literals) by default.
No preference
Other
You may select 1 option

View results
Author Message
PostPosted: May 6th, 2005, 3:37 am 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
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:
Code:
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 6th, 2005, 8:11 am 
Offline

Joined: January 31st, 2005, 9:50 am
Posts: 3910
Location: Bremen, Germany
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?

_________________
Ciao
toralf
Image


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 6th, 2005, 9:53 am 
Offline

Joined: March 28th, 2004, 3:53 pm
Posts: 1870
I voted 1st.

_________________
Image


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 6th, 2005, 12:03 pm 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
toralf wrote:
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.

Quote:
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 <PRE> section in HTML. Since HTML isn't indented as often as a script, the analogy isn't perfect. But anyone who's used the <PRE> section a lot can see how preserving indentation can be useful for some tasks (but perhaps these tasks wouldn't form a majority).


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 6th, 2005, 12:26 pm 
Offline

Joined: November 8th, 2004, 12:46 am
Posts: 1271
The <pre> 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.

_________________
"Anything worth doing is worth doing slowly." - Mae West
Image


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 6th, 2005, 7:35 pm 
Offline

Joined: January 31st, 2005, 9:50 am
Posts: 3910
Location: Bremen, Germany
Chris wrote:
toralf wrote:
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.

_________________
Ciao
toralf
Image


Report this post
Top
 Profile  
Reply with quote  
 Post subject: My Vote
PostPosted: May 7th, 2005, 3:05 am 
Offline

Joined: April 24th, 2005, 1:04 am
Posts: 97
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.

_________________
Wer keine Antworten hat muss nicht dumm sein,
dumm ist nur der welcher keine Fragen hat.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 7th, 2005, 1:01 pm 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
Rubberduck wrote:
...), "{space}:12" ,C:\My File.txt
would mean to write the lines, but before each line write 12-Spaces
toralf wrote:
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?

Rubberduck wrote:
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:
Code:
if x > 1
{
    FileAppend,
    (LTrim
        `t`tFirst line.
        `t`tSecond line.
    ), C:\My File.txt
}

Quote:
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.


Last edited by Chris on May 7th, 2005, 1:10 pm, edited 1 time in total.

Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 7th, 2005, 1:02 pm 
Offline

Joined: November 8th, 2004, 12:46 am
Posts: 1271
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:

Code:
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?

_________________
"Anything worth doing is worth doing slowly." - Mae West
Image


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 7th, 2005, 1:16 pm 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
Serenity wrote:
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 7th, 2005, 2:03 pm 
Offline

Joined: March 28th, 2004, 3:53 pm
Posts: 1870
Chris wrote:
Perhaps an option could be added to Input that makes all keys that don't produce a visible character become end keys.

great!

_________________
Image


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 7th, 2005, 2:53 pm 
Offline
User avatar

Joined: December 29th, 2004, 1:28 pm
Posts: 2545
I voted #2 :)


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 7th, 2005, 3:58 pm 
Offline

Joined: November 8th, 2004, 12:46 am
Posts: 1271
Chris wrote:
Serenity wrote:
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:

Code:
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%

_________________
"Anything worth doing is worth doing slowly." - Mae West
Image


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 7th, 2005, 8:59 pm 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
Serenity wrote:
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: May 10th, 2005, 7:19 pm 
Offline

Joined: February 27th, 2005, 5:51 pm
Posts: 139
Location: Heidelberg, Germany
Hi,

what are you thinking about a directive like this:
Code:
#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:
Code:
#LineContSeperator -


So a file append can look like this:
Code:
#LineContSeperator -

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


NiWi.


Report this post
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 33 posts ]  Go to page 1, 2, 3  Next

All times are UTC [ DST ]


Who is online

Users browsing this forum: Yahoo [Bot] and 3 guests


You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Group