AutoIt v3.3.9.20 Beta

[jchd]

If you have to process text with uncommon newline ending (here I mean "uncommon in Windows world") then you're free to force whatever convention of your choice/need. Still making the regexp default coïncide with what is the OS default (or tradition if you prefer) used by 99.999% of Windows programs seems like a safe idea.

Also it's relatively frequent to see lone @LFs or @CRs mean a line break inside some multi-line field of a .CSV file, itself line-delimited by @CRLF. Making the latter a default would devastate the reading.

[DXRW4E]

Hi jchd, that I know very well, but we're talking about a default setting, Windows knows these line (run this inf file in system)

FileWrite(@DesktopDir & "\test.inf", @LF & @CR & '[Version]'& @LF & @CR & 'Signature="$Windows NT$"' & @LF & @CR & _
    '[DefaultInstall]' & @LF & @CR & 'AddReg = AddReg.Section' & @LF & @CR & _
    '[AddReg.Section]' & @LF & @CR & 'HKCR, "...Test", , ,"Test"')

in this case StringRegExp() No?, I do not think which is a good idea to tell all users always use the newline convention if you use RegExp in AutoIt?, I'm just saying what I think, I do not know hmmmmm

after that I do not understand who the point, when we can do it why not do it, does not lose anything in performance

Ciao.

Edited September 9, 2013 by DXRW4E

[jchd]

Please realize that your twisted example is precisely an instance of problematic source, since it will double or not, depending on the tool you use, the number of lines you seem to think it contains.

Contrary to what you pretend, I'm not "telling users to always use the newline convention if they use RegExp in AutoIt". This is only needed when/if you ever process very unusual files. I find it unfair that you put your own, biaised words in my mouth.

I'm not against changing the default convention (clearly, as I was just doing that!), but I'm waiting to see concrete advantages examples of (*ANYCRLF) massively outweight real-world drawbacks of (*CRLF) to be convinced.

[saudumm]

it seems some bug/regress in _ArrayDisplay() - unlike 3.3.8.1 in 3.3.9.20 you can't change window size by dragging it's borders...

The window is still resizable, but the mouse cursor doesn't change. This problem exists with all resizable AutoIt GUIs, so it seems related to the recent mouse cursor changes, not to _ArrayDisplay().

I filed a bug report for this.

Edited September 9, 2013 by saudumm

[DXRW4E]

the current setting says, if not @CRLF that is not NewLine, if a user has a Mac file or whatever in @CR only or @LF only, then that file is not valid file? (Windows and all other applications that run in Windows, do not say so, but say that is valid file ehhh ), and after need prevent everything manually?, in poor words is equal how to tell if a file is not ASCII then is invalid file, since the majority of the files are ASCII (or if a textdata .txt file saved in Mac or Linux that is not a valid .txt file in Windows?), I think instead which by default AutoIt will have to know everything that the Windows by default knows (example is in the post above),

as always I'm just saying what I think personally, nothing else, for more and still do not understand where is the problem that one thing should not be flexible hmmmmmmm, and is very simple it does not matter right or wrong or how you think or what I think, AutoIt (is forced) will need to know by default everything that Windows by default knows

Ciao.

Edited September 9, 2013 by DXRW4E

[Jon]

I guess that FileReadLine() will accept all three variants by default so maybe the default pcre option should mirror. Does anycrlf cause issues with standard crlf windows files?

[DXRW4E]

normally and logically No, will not have to be any kind of problem between (*CRLF) and (*ANYCRLF)

http://www.autoitscript.com/autoit3/pcrepattern.html

  (*CR)        carriage return
  (*LF)        linefeed
  (*CRLF)      carriage return, followed by linefeed
  (*ANYCRLF)   any of the three above
  (*ANY)       all Unicode newline sequences

 

Ciao.

Edited September 9, 2013 by DXRW4E

[jchd]

Shit, the answer vanished in space! I hate the web for that.

In short I was saying: why not. There are good arguments pro and contra which I'm not going to type again. Fucking web.

Also the question arises for R. Maybe we should make (*BSR_ANYCRLF) by default as well, since 0x85 is relatively common in ANSI files.

[DXRW4E]

 the answer vanished in space!

not true

Hi jchd, you're the guy who was very active there, and Thanks you very much (Seriously ) again for all the details about RegExp (or even in firefox favorite http://www.autoitscript.com/autoit3/mvps/jchd/PCRE%20documentation/pcrepattern.html I helped a lot to revise certain things more better), but I still believe that set for strength @CRLF only is a Very wrong choice, looking at the situation in general and for all the reasons written in all the posts above

Ciao.

Edited September 9, 2013 by DXRW4E

[jchd]

It may be very wrong from your point of view for your routine use cases. I'd rather say it's marginally wrong for people having to routinely process "foreign" files. But since these are essentially power-users, I'd say it's only sugar for not having to force another convention.

The question for R remains open and if (*ANYCRLF) is retained, then (*BSR_ANYCRLF) would be a more consistent choice: current (*BSR_UNICODE) default will take 0x85 (ellipsis in many ANSI codepages) as a line break (also Vertical Tab, but this control char is rare).

I'll now leave it to Jon to decide what's best. (*ANYCRLF) will work on essentially all files whatever OS or program produced them, but may confuse users in situations where separate CR or LF don't mean a new line (or record). (*CRLF) will work unsurprisingly for all Windows files but may require rare users processing rare foreign text to use another convention.

Time to close eyes!

[jpm]

 http://www.autoitscript.com/autoit3/mvps/jchd/PCRE%20documentation/pcrepattern.html

this link does not point to the current beta pcre support.

Your previous http://www.autoitscript.com/autoit3/pcrepattern.html is the correct one for the current beta

not sure jchd hav really edited an old version

[jchd]

Should be 8.33, I'll check later today.

[Jon]

 

I'll now leave it to Jon to decide what's best. (*ANYCRLF) will work on essentially all files whatever OS or program produced them, but may confuse users in situations where separate CR or LF don't mean a new line (or record). (*CRLF) will work unsurprisingly for all Windows files but may require rare users processing rare foreign text to use another convention.

Time to close eyes!

 

I'm going to go for *ANYCRLF as default. Shoot me!

(Edit: I Love how until this was brought up, the old default of LF was fine...haha)

[BigDod]

[jchd]

Not as fine as you think it was.I remember having to circumvent things a couple of times. There must ce also tracks in the answers posted here and there. But yes I was unsuspecting that such a brilliant personality as you would have left such a wide hole in the perfect AutoIt galaxy.

Oops, going to be shot down!

I'll fix the doc accordingly. What's your opinion regarding R and (*BSR_ANYCRLF) vs. the current default (*BSR_UNICODE)?

[DXRW4E]

this link does not point to the current beta pcre support.

Your previous http://www.autoitscript.com/autoit3/pcrepattern.html is the correct one for the current beta

not sure jchd hav really edited an old version

Hi jpm, Thank you

@OffTopic

RegExp never ends to learn it ehhh, the http://www.autoitscript.com/autoit3/mvps/jchd/PCRE%20documentation/pcrepattern.html has been updated before the official page http://www.autoitscript.com/autoit3/pcrepattern.html and even also brings in pages like http://www.autoitscript.com/autoit3/mvps/jchd/PCRE%20documentation/index.html

certainly today I always refer only to the official page http://www.autoitscript.com/autoit3/pcrepattern.html (that even saved in HTML and in PDF the old and the new page, since long ago that page went offline for months ehhhh, However now almost everything of pcrepattern.html is already in AutoIt.chm ) but long ago http://www.autoitscript.com/autoit3/mvps/jchd/PCRE%20documentation/pcrepattern.html has been really helpful to understand some more good stuff

Ciao.

Edited September 10, 2013 by DXRW4E

[jpm]

In fact there must be 2 pages one for the release and one for the beta.

I think Jon update the http://www.autoitscript.com/autoit3/pcrepattern.html and now this one point to the beta based on 8.33

not sure the one of jchd is referring to the release with is based on pcre 8.12

[jchd]

I copied 8.33 to my space some time ago, right after the beta went alive again and Jon compiled it with UCP support. I would also recommend to append the PCRE version to the doc name in the repository, so that successive releases and beta can refer to their exact reference doc.

[mLipok]

Nope. All I've done so far is to change the error message to show what file has an error. So it would be worth trying again to see what it says.

 

I'll check today or tomorrow and will put the relevant information in that thread.

 

I spoke badly, I mean, that previous thread, not this one.

Please see the continuation of that previous thread:

[kylomas]

jchd,

I don't know if this is a problem, expected behaviour or my ineptitude with regexp.

When I run the following code under 3.3.8.1 I get an output file without line #1 as expected, however, the EOL chars are changed to CR (as reported by Notepad++).  When I run the same code under 3.3.9.20 I get NO EOL chars.

local $str = _
'line 1' & @crlf & _
'line 2' & @crlf & _
'line 3' & @crlf & _
'line 4' & @crlf & _
'line 5' & @crlf

$str = stringregexpreplace($str,'(?:.*\R)?(.*)','\1')

local $f2 = @scriptdir & '\test2.txt'

filedelete($f2)

filewrite($f2,$str)

ShellExecute($f2)

kylomas