Is the "`n" option in FileAppend and FileRead confusing?

[lexikos]

I'm suggesting that `r should insert `r in front of each new line. As opposed to `n inserting `r in front of each new line.

I am aware. My point is that this isn't consistent with your argument about "UTF-8", which appears to be something like "specifying UTF-8 means to convert to UTF-8, therefore specifying `n should mean to convert to `n, but it means to convert to `r`n, and this is confusing". If `n should mean to convert to `n, then `r should mean to convert to `r.

That is exactly my point.

No, you are just twisting or misinterpreting my words.

You are biased toward strict logic.

"Strict" logic as opposed to... loose logic? That's just not logic. Arguing a point without logic is futile. You repeatedly bring this up as some kind of explanation, but all I'm getting is that there is little logic behind your opinions, so I will not understand or agree with them.

If the purpose of this topic is to drive development of the language or program, both of which are essentially constructs of logic, arguments must be backed by logic. But as I've been saying, I'm not convinced that this topic actually ever had a practical purpose.

I think you are missing my point: it has a lot to do with NOT thinking like a programmer.

I may be willfully missing or ignoring your point, because the only way I can understand "think like a non-programmer" is as "think irrationally". There is no structure which I can use to understand someone else's irrational thought process. It is pointless to discuss.

I hope you are not suggesting ..., because, you know, writing is the inverse of reading.

I think your logic is failing (or absent).

FileRead(path, "UTF-8 `n") reads from file, converts UTF-8 to UTF-16 and `r`n to `n.
FileAppend(text, path, "UTF-8 `n") writes to file, converts UTF-16 to UTF-8 and `n to `r`n.
Reading is inverted to become writing. Both conversions are inverted accordingly.

FileRead
`n results in `n or `r`n depending on whether you are reading or writing

FileAppend
`n results in `n or `r`n depending on whether you are reading or writing

FileOpen
`n results in `n or `r`n depending on whether you are reading or writing

Thus the results are consistent (not that the Options parameter ever claimed to be about the results).

[RaptorX]

I think you are missing my point: it has a lot to do with NOT thinking like a programmer.

I may be willfully missing or ignoring your point, because the only way I can understand "think like a non-programmer" is as "think irrationally". There is no structure which I can use to understand someone else's irrational thought process. It is pointless to discuss.

Alright, I will concede to that.
My point of view is that most people who use AutoHotkey do not have a background in programming and for that reason the way how they look at the language might not be exactly what your vision is.

Again. 99% of the time I agree with your decisions, I just try to point out how your decision making might be confusing to people like me and probably a big chunk of the current userbase.

Of course this poll is not a big indication of how most people see Autohotkey but it might shed light as to potential blind spots you might have.

I will stop wasting your time this one time
But you might find me in other topics arguing in favor of some "irrational" things that seem to make some sense to at least a part of the community.

(not that the Options parameter ever claimed to be about the results).

I think this is the main source of confusion. We either think this is the case implicitly or it is not well described in the documentation that this is what is going on.

I have always thought of those options as: "write the file and use UTF-8 encoding", or "read the file and use UTF-8 encoding"... by extension I would think: "Write the file using the `n EOL" and "Read the file using the `n EOL"

I do understand your arguments but that's what I think a lot people in this thread might be thinking. Food for thought.

Ill sign off from this thread now. Thanks for the discussion!.

[lexikos]

We either think this is the case implicitly or it is not well described in the documentation that this is what is going on.

What is going on, that you suggest the documentation does not well describe? A misconception which the authors of the documentation haven't observed or had reason to predict would occur? The documentation clearly states the parameter takes a list of options, and gives no reason to believe there is any theme or hidden meaning to the options. I don't know how the m1024 option of FileRead fits into your theory. I also don't think that pointing out a theoretical misconception about the general meaning of the Options parameter would improve upon the clarity already imparted by simply stating what the parameter does.

[V2User]

It's not possible to have a clean solution if backwards compatibility is taken into account. The current meaning of `n has three legs: CRLF → LF → CRLF which becomes confusing when only using FileRead CRLF → LF or FileAppend LF → CRLF. It's just better if `n means what it means.

In the situation of File Funcs, I think, `n means "an EOL conversion for AHK `n". If you replace the `n option with EOL, it might be easier to understand from the literal.

EOL is different in different systems. EOL is CrLf in Windows, while Lf in linux and Cr in ealy Mac OS. If you named the option with `r`n or `r, then you have to write three options for each of the three OS. Not only that, you have to change the Opt arguments in every FileAppend(), when you want to use your script from one OS to another OS.

But if the option is named EOL or `n by its meaning as I quoted above, the AHK script will work well on the three different OS at the same time. File Funcs in the script will be cross-platform, like Python. Codes of File Funcs will never need to change, when migrating among different systems. It preserves more potential possibilities and flexibility for the future.

[william_ahk]

In the situation of File Funcs, I think, `n means "an EOL conversion for AHK `n". If you replace the `n option with EOL, it might be easier to understand from the literal.

I agree with V2User. The reason why `n is confusing at first glance is because we use it as an actual line break character all the time. Using another symbol for the mode option will be easier to understand.

[iseahound]

git calls this autocrlf

[RaptorX]

In the situation of File Funcs, I think, `n means "an EOL conversion for AHK `n". If you replace the `n option with EOL, it might be easier to understand from the literal.

I agree with V2User. The reason why `n is confusing at first glance is because we use it as an actual line break character all the time. Using another symbol for the mode option will be easier to understand.

Yes I agree, I was suggesting `r instead but it has the same issue as `n

[lexikos]

The option started in FileOpen, which takes a string of character-based options. I think that `n was the obvious choice of option for the same reason that others claim to be confused by it.

[iseahound]

image.png (61.06 KiB) Viewed 3026 times

[RaptorX]

image.png

If autohotkey's option was named "autocrlf" instead of "`n", I wouldnt find it confusing, strangely enough

I think that `n was the obvious choice of option for the same reason that others claim to be confused by it.

For a man that loves precision, this statement seems ironic, as `n not always produce `n as one would expect.