[v1/v2] Additional special character built-in variables

[boiler]

Why only A_Space and A_Tab? For your consideration, I believe the following would be at least as useful:

• A_CR - carriage return (`r)
• A_LF - linefeed (`n)
• A_CRLF - carriage return & linefeed (`r`n)
• A_Quote - quotation mark (") - especially for v1, where escaping quotes can get hard to read
• A_Comma - comma (,) - especially for v1

[guest3456]

yesss

[Xtra]

Good suggestion.

[lexikos]

Why even A_Space or A_Tab?

If I had developed AutoHotkey from scratch, none of these variables would exist. I personally do not consider quoted strings so difficult to read that these "variables" are warranted.

For v1, there used to be some cases where the only way to include whitespace at the end of a parameter was to use the variable.

[boiler]

It’s not the biggest deal to me, but it seemed odd to include them only for those two characters and not others where it would be at least as useful, especially in the cases of `r and `n as compared to `t and A_Tab. Those were the cases that I thought were conspicuous by their absence and I would find plenty of occasions to use, unlike the existing ones.

Why even A_Space or A_Tab?

I might ask you the same…

If I had developed AutoHotkey from scratch, none of these variables would exist.

Then it’s interesting to see that they made into v2, which — while not a total blank slate — was/is basically your opportunity to do what you wanted with these. I’m guessing removing them was not worth the effort or high enough on the priority list, which is fair enough.

I personally do not consider quoted strings so difficult to read that these "variables" are warranted.

Not everyone is as astute and perceptive as yourself. There are many examples on the forum where users get confused by it, especially at the beginning/end of quoted strings where there will be three in a row for v1. Sure, languages shouldn’t necessarily be designed for ease of use by beginners (despite Chris’s original intention for AHK), and maybe some more careful attention is called for, but it could also make scripts more readable with a variable. And yes, I realize a user can define their own.

For v1, there used to be some cases where the only way to include whitespace at the end of a parameter was to use the variable.

I figured that was the reason for A_Space before there were expressions, but that doesn’t explain the existence of A_Tab if `t has always been around.

[guest3456]

quoted strings in v1 is a disaster using double quotes to escape a single quote. need A_Quote

[Qriist]

Why only A_Space and A_Tab? For your consideration, I believe the following would be at least as useful:

• A_CR - carriage return (`r)
• A_LF - linefeed (`n)
• A_CRLF - carriage return & linefeed (`r`n)
• A_Quote - quotation mark (") - especially for v1, where escaping quotes can get hard to read
• A_Comma - comma (,) - especially for v1

made a small library to incorporate that idea. Requires #include but shouldn't need anything else.

Code: Select all

a_defines(){
	global
	static A_dummy := a_defines()	;self-invokes when this function is #included

	A_CR := "`r"
	A_LF := "`n"
	A_CRLF := "`r`n"
	A_Quote := chr(34)
	A_Comma := ","
}

[lexikos]

I figured that was the reason for A_Space before there were expressions, but that doesn’t explain the existence of A_Tab if `t has always been around.

Yes, it does (at least, one explanation). The code below should show "ab" and then "cd", right?

Code: Select all

v = ab`tcd
Loop Parse, v, `t
	MsgBox %A_LoopField%

On v1.0.48.05, it shows "a", "b", (tab), "c", "d". To use tab at the start or end of a parameter, it was necessary to use a variable or expression.

[boiler]

It seems odd that it works with `n but not `t and the fix was to add a built-in variable rather than to change the parser to recognize it. I don’t know the first thing about programming a language, though.

[lexikos]

Of course it worked with `n; only spaces and tabs are trimmed around a parameter. For instance, there is a space after the comma, which is not included in the value. A literal newline character would terminate the command, while `n is always part of the value.

I don't claim that this is the reason Chris added these variables, but there were a lot of odd design choices in v1, IMO.

[iseahound]

I generally use Chr(34), but A_Quote would be a readability improvement

[lexikos]

jeeswg has submitted a pull request implementing A_Comma, A_DQ, A_SQ, A_CR, A_CRLF, A_LF for v1.

Does anyone have thoughts about A_Quote vs. A_DQ/A_SQ or alternatives? As it is, I don't care enough about this to make a choice, which makes it even less likely to get implemented.

[Helgef]

I would never use any of these in v2. I think q := "'", and similar, is much more convenient and readable. I have used this occasionally.

Does anyone have thoughts about A_Quote vs. A_DQ/A_SQ or alternatives?

As a non-english native speaker, I can contribute with the perspective that the word "qoute" is impossible to spell.

Cheers.

[TAC109]

I personally don’t see that these variables are easier to use than their literal equivalents, and wouldn’t use them myself.

[neogna2]

jeeswg has submitted a pull request implementing A_Comma, A_DQ, A_SQ, A_CR, A_CRLF, A_LF for v1.
Does anyone have thoughts about A_Quote vs. A_DQ/A_SQ or alternatives? As it is, I don't care enough about this to make a choice, which makes it even less likely to get implemented.

In v2 having both ' and " already improves readability a lot compared with "" situations in v1. But these A_ variables could be nice to have sometimes.
I dislike A_Quote because longer than A_DQ. (Also, agree with helgef on spelling.)
I prefer A_Q (not in jeeswg's PR) because shorter still. Double quote is the "primary style" of quotation mark in ordinary english so I think it would be ok to leave out the D character from the name.

For example in v2 I might use Run('notepad ' A_Q FilePath A_Q) instead of Run('notepad "' FilePath '"') but doubt I'd use Run('notepad ' A_Quote FilePath A_Quote)

Come to think of it, maybe the even shorter _ (underscore character): Run('notepad ' _ FilePath _) ?

[Helgef]

For example in v2 I might use Run('notepad ' A_Q FilePath A_Q) instead of Run('notepad "' FilePath '"')

Still, there might be better solutions, eg, run F'notepad "%FilePath%"'.

[boiler]

For v1, I don’t see why A_SQ is helpful since a literal single quote is not problematic. So I would prefer A_Quote.

[Xtra]

A_Quote for readability.

[neogna2]

Still, there might be better solutions, eg, run F'notepad "%FilePath%"'.

Why F?
The _ (underscore) idea keeps growing on me. Shortest yet noticeable. (Sidenote: surprising that _ seems uncommon as standalone syntax character in programming languages despite noticeable and easy to type. On a US keyboard AutoHotkey uses ~`!#%&*()-+={}[]|:;"'<>,.? and some combinations of them yet _ is vacant.)

[iseahound]

A_Q and A_QQ for single and double quotes respectively, since SQ / DQ doesn't offer much clarity.

A_Quote is elegant and readable, and would perhaps work with the proposal to simplify quotes around continuation sections. I remember @lexikos suggesting something like:

Code: Select all

variable := 
    ( Quote
        my variable
    )

My vote is for implementing both single and double quotes, which may not be possible with A_Quote. Implementing both will save headaches and arguments in the future, where users will invariably ask and complain why one and not the other