AutoHotkey Community

this is a customized file for ahk_l saved with unicode's U+2028 lineseperator.
AHK_L does not detect it as newline (allthough AHK_L was used to create this file) and fails in execution as only one line is interpreted.

here's the creation script:


which should result in this script


the original file can be downloaded here:
http://www.autohotkey.net/~DerRaphael/t ... endian.ahk


as it seems for now that this U-2028 lineseperation and the U+2029 paragraph seperator will be upcoming standards to end that \r\n, \r, \n and \u0085 lineending story, imho ahk_l should be abled to support that natively. as for being prepared for future standards instead of hotfixing incorporations.

additionally if this ever gets fixed, ahk build in constants to easily send or create proper lineendings would be a nice to have, too ( see this wish )

greets
dR

_________________

All scripts, unless otherwise noted, are hereby released under CC-BY

I'm sure there are countless programs that support only `r`n and/or `n, and will continue to do so. In particular, I think programming languages traditionally support only ASCII in source files outside of literal strings. I don't see the benefit in adding handling for yet another line ending. How many text editors will output that when you press Enter?

the w3c has been asked to officially support unicode endings within xml standards. since it makes perfect sense for xml data, there are some fractions which use ahk (and will continue using ahk_l) to modify xml files. so since u state that u dont see a benefit for including two more handlers for lineendings u put the burden to create own solutions on anybody who will have to work with xml files using unicode lineendings as commands such as fileappend, or fileread wont support it and therefore have to be replaced by totally custom routines. tough decision.

_________________

All scripts, unless otherwise noted, are hereby released under CC-BY

I see. That could be a problem for file-reading loops. Loop, Parse may need to be used instead.

However, the examples you have given are bad ones. FileAppend and FileRead don't do anything with line endings except (optionally) translate between `n and `r`n. There's no need to do that with Unicode line endings.

What does supporting Unicode line endings in XML entail? I didn't think whitespace had all that much meaning.

you are correct

_________________
No matter what your oppinion Please join this discussion
Formal request to Polyethene