I was referring to FileRead/FileAppend/StrGet/StrPut together. I think that EOL translation should be off by default, for both FileRead and FileAppend, partly for consistency, and that 'P0' or 'CP0' should be available to FileRead and FileAppend. I'm not bothered if one function uses 'P' and one function uses 'CP', but it's worth mentioning.
I find it difficult to conceive of why anybody would want EOL translation, if anyone would care to offer an answer. If more people don't use it than do use it, then that's an argument for having it off by default.
I've added support for UTF-16 BE to the Notepad replacement I'm creating, because Notepad has it. I don't know how common its usage is.
It is, however, completely redundant if you're not reading clipboard data.
I'm surprised by this, I don't use it for reading the clipboard contents, I use it for putting the contents of binary files into variables, *cnnn would allow grabbing the first few bytes only, for file type identification. It's a one-liner, and there's no advantage to using a File object instead.
Re. 'CP0'. It is possible I have made a mistake here, however:
Code: [Select all] [Download] GeSHi © Codebox Plus
FileRead, vText, % "*P0 " vPath ;this opened a UTF-8 file as UTF-8 rather than forcing ANSI
FileAppend, % vOutput "`r`n", % "*" vPath2, CP0 ;file was UTF-8, appended as UTF-8 rather than forcing ANSI
FileAppend, % vOutput "`r`n", % "*" vPath2, CP1252 ;file was UTF-8, appended as UTF-8 rather than forcing ANSI
Re. VarSetCapacity. Apologies, I've just read that bit again (and your additional comment), and I still don't know what you meant, otherwise I would have given a fuller comment at the time.
- Are you saying that TVITEM has a 'length' of 56/40 bytes. Personally I would never use the word 'length' for that, but maybe it's common in some circles. You could potentially have something like 'VarSetCapacityBytes', 'VarSetCapacityChars', but to change the meaning of VarSetCapacity would be very inconvenient, and I think 'capacity' implies 'bytes' rather than 'characters'.
- Does a UTF-16 string with 4 characters have a 'length' of 8 bytes and a 'capacity' of 4 characters, or a length of 4 characters, and a capacity of 8 bytes? With UTF-8, size in bytes becomes even more useful when talking about size/'length'/capacity.
Re. in/contains. If I want to do something in AHK, I use a function. Since in/contains were scheduled for removal, I've been using StrIn/StrContains functions, just fine. I, personally, don't see the need for the special syntax just for one function.
- Although Chris is right 99% of the time, and I do greatly appreciate his work as one of the two main contributors to AutoHotkey, other people do use AutoHotkey.
- Regarding expressiveness, StrContains(string, list), StrMatch/StrMatchList(string, list) are reasonably expressive.
Re. Control Choose(String). I would have said more about Control Choose/ChooseString, but nothing was said in the post about why the two should be combined, and so I'm still unsure for the rationale. If you combine the two, you need another parameter.
to get the 1st occurrence of an item?
to get the nth occurrence of an item?
to get the nth item?
- What if the item's string itself is blank? Hence, so that nothing can ever go wrong, keep them separate.
- If using the rationale of treating a number stored as text differently from a number stored as a number? There is a lot that could be said on that issue, I would say, avoid this at all costs, and thus, keep the functions separate.
- Also, I believe the AHK v2 approach is to avoid, where possible, using blank parameters.
- I had relevant concerns when I wrote these:
JEE_FirefoxFocusTabByName(hWnd, vTitle, vNum=1)
JEE_ChromeFocusTabByName(hWnd, vTitle, vNum=1)
Re. Click. I don't think that Click within Send is any better than Click by itself.
- So '2' has a different meaning without the comma. Is that click right twice, or click right at '2,5', is 'right 2' one parameter? If a command was ever confusing, then this is it. At least 'x2 y5' could be used.
- Furthermore this was the one difference I had with Coco, over converting AHK functions, he thought they should be regarded as separate parameters, I thought the whole thing should be regarded as one parameter.
- There are disadvantages to both approaches, hence, in my view, better just to have a normal 3-parameter function.
[EDIT:] In retrospect I think the main problem is the comma, remove the comma, and use x0 y0 instead, and everything looks pretty good. A space-separated list, all within one parameter. The only problem though, is how to specify the 2nd set of coordinates for MouseClickDrag, xx0 yy0, maybe (not great), xd0 yd0, for destination? You wouldn't even need a separate MouseClickDrag function.
Changes in the past have caused me untold difficulties, I'm not going to hide my views now, but I hope that I don't come across harsh, I'm a big supporter of AHK v1 and AHK v2.