PSPad UNICODE 4.5.0 (2133) beta English

Find-in-files seems a bit confusing to me now. Would it be possible to add a "search in all/any codepage" option? Presently, it seems to limit itself only to the selected codepage when in fact I expect text to be found in a file regardless of its codepage.

As always, thanks for your tireless and gracious efforts!

Best Regards,

xo boots

That's the german labeling of the 'Home' Key.

And i am not able to reproduce the described 'bug'...

boots wrote:

> Find-in-files seems a bit confusing to me now. Would it be
> possible to add a "search in all/any codepage" option?
> Presently, it seems to limit itself only to the selected
> codepage when in fact I expect text to be found in a file
> regardless of its codepage.

PSPad is able to detect a code page if a file contains the BOM. But PSPad can't detect non BOM code pages (ANSI, OEM, ...).

Imagine yourself, you are search accented string in OEM. You input it as ANSI/UNICODE.

Now you must translate file from OEM to ANSI/UNICODE to get matches or translate string from ANSI/Unicode to OEM. Second solution is more secure, because you didn't no file transformation.

I got this exception if you open an empty file, the WordWrap is On and you press HOME key

Search / Replace in Files... fails to list results and/or perform replace.
v 4.5.0.2133

Clear previous search results: checked
Search Scope: Selected Directory
File Masks: *.php

Result using v4.5.0.2132 and same settings lists results correctly.

I tried different combinations, but can't confirm the freezing bug: PSPad is working like a charm BTW I believe it's up to some settings in PSPad (eg. charset, file format, tool panel on/off, wordwrap on/off etc.) rather then to Windows version or graphic card.

> Imagine yourself, you are search accented string in OEM. You input it as
> ANSI/UNICODE.

> Now you must translate file from OEM to ANSI/UNICODE to get matches or
> translate string from ANSI/Unicode to OEM. Second solution is more secure,
> because you didn't no file transformation.

I agree that it is better to translate the search string, but is it not better to have the editor silently automate that instead of making me manually try each encoding type in turn? I can't tell whether a file has an encoding or a BOM without actually inspecting it. I agree it is more work for the editor to make the conversions and that it is perhaps less "safe" -- but I am willing to live with that. After all, I needn't choose "any/all" but can limit to a more specific codepage if need be.

One problem is that many files actually do not have BOM's and sometimes usng BOM's is not acceptable (because of limited support). Right now I have to check through each codepage to make sure I really find "ALL" files and this feels very different than old versions of PSPad.

Thanks for your reply.

I can also confirm problem with clips crashing the program.

Start with a text file. Change to html or html multihighlighter

Activate clip, add font or whatever and cpu goes to 100% and program stops responding.

Jody

PSPad uses this:
you enter string and choose some code page on file dialog

PSPad search file by file. If file contains a BOM, PSPad opens it correctly and handle it as UNICODE. If CP can't be detected, search string is converted into CP you specify in the dialog.

If you search open files, PSpad use it's CP.

I mean it's clear.