- 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
[v1/v2] Additional special character built-in variables
[v1/v2] Additional special character built-in variables
Why only A_Space and A_Tab? For your consideration, I believe the following would be at least as useful:
Re: [v1/v2] Additional special character built-in variables
Good suggestion.
Re: [v1/v2] Additional special character built-in variables
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.
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.
Re: [v1/v2] Additional special character built-in variables
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.
I might ask you the same…
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.
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.
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.
Re: [v1/v2] Additional special character built-in variables
quoted strings in v1 is a disaster using double quotes to escape a single quote. need A_Quote
Re: [v1/v2] Additional special character built-in variables
made a small library to incorporate that idea. Requires #include but shouldn't need anything else.boiler wrote: ↑06 Aug 2022, 07:51Why 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
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 := ","
}
Re: [v1/v2] Additional special character built-in variables
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%
Re: [v1/v2] Additional special character built-in variables
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.
Re: [v1/v2] Additional special character built-in variables
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.
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.
Re: [v1/v2] Additional special character built-in variables
I generally use Chr(34), but A_Quote would be a readability improvement
Re: [v1/v2] Additional special character built-in variables
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.
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.
Re: [v1/v2] Additional special character built-in variables
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.
Cheers.
As a non-english native speaker, I can contribute with the perspective that the word "qoute" is impossible to spell.Does anyone have thoughts about A_Quote vs. A_DQ/A_SQ or alternatives?
Cheers.
Re: [v1/v2] Additional special character built-in variables
I personally don’t see that these variables are easier to use than their literal equivalents, and wouldn’t use them myself.
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
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.lexikos wrote: ↑10 Sep 2022, 04:10jeeswg 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.
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 _) ?
Last edited by neogna2 on 10 Sep 2022, 10:45, edited 1 time in total.
Re: [v1/v2] Additional special character built-in variables
Still, there might be better solutions, eg, run F'notepad "%FilePath%"'.neogna2 wrote:For example in v2 I might use Run('notepad ' A_Q FilePath A_Q) instead of Run('notepad "' FilePath '"')
Re: [v1/v2] Additional special character built-in variables
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.
Re: [v1/v2] Additional special character built-in variables
A_Quote for readability.
Re: [v1/v2] Additional special character built-in variables
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.)
Re: [v1/v2] Additional special character built-in variables
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:
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
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
)