SOLVED - [11.02RC4 x64] Search (Alt+F7) - only 2 plugins to choose from

[tuska]

The following post is an extract from that post:
viewtopic.php?t=80379
[11.02RC4] Colour assignment only works partially

---

 
Search... Alt+F7
In the plug-in selection, only 2(!) plug-ins are available in TC 11.02RC4 x64.
In the plug-in selection, all plug-ins(!) are available in TC 11.02RC4 x86.

⸺⸺⸺⸺⸺⸺⸺⸺⸺⸺⸺⸺⸺⸺⸺⸺⸺
Performed a NEW INSTALLATION of TC 11.02RC4 '64-bit+32-bit combined'.
[x] Search in plugins
Only the plugins tc and emptywdx are still available in TC 11.02RC4 x64.
⸺⸺⸺⸺⸺⸺⸺⸺⸺⸺⸺⸺⸺⸺⸺⸺⸺

[ghisler(Author)]

That's because you damaged the file by saving it as UTF-8.

[tuska]

That's because you damaged the file by saving it as UTF-8.

Mmhh.
I have not changed the coding of the file "wincmd.ini" for over 20 years.
Only now, on your advice, have I changed the coding to "ANSI".

In TC 11.02RC4 x86 I have 52 plugins available on the "Plugins" tab and the same wincmd.ini is used.
I do not understand your statement.

[tuska]

I have now noticed the following:
My wincmd.ini from 7.10.2023 (backup) had coding "ANSI".

These files also had the coding "ANSI" at that time:
wincmd_Rename.ini
wincmd_Searches.ini
wincmd_Searches_Templates.ini

It is inexplicable to me how the file "wincmd.ini" was recoded to "UTF-8".
With the other three files, I can no longer determine the encoding at the time of the bug report,
because I have encoded all .ini files to "ANSI".

However, this caused the errors with the German umlauts, file attributes and missing plugins.

Conclusion:
After using the backup file "wincmd.ini" from 7.10.2023 everything works fine again.

I am very sorry for the inconvenience.
This is SOLVED.

[white]

Moderator message from: white » 2023-10-29, 15:09 UTC

Moved to English forum.

[algol]

deleted b/c of double-post created by forum-software instead of correctly editing the post.

[algol]

After using the backup file "wincmd.ini" from 7.10.2023 everything works fine again.

Is there a special reason as to why (in order to remedy the dysfunctional ini-file-situation) you went back to a saved backup (thereby possibly losing latest intentional changes) instead of simply re-encoding the latest version of your "wincmd.ini" as ANSI from the editor of your choice?

@ghisler (Author)
In the current Unicode-era with its capability to handle masses of special characters, not limited to but including German "Umlauts" as well, how difficult would it be to re-work TC in a manner that would allow it to also accept/cope with and correctly interpret UTF-8 encoded ini-files as the latter has become some sort of quasi-standard by now whereas the relevance of ANSI would seem to have diminished over time?

[petermad]

how difficult would it be to re-work TC in a manner that would allow it to also accept/cope with and correctly interpret UTF-8 encoded ini-files

Difficult becuse Windows does not support ini files in uft-8 format - see: https://ghisler.ch/board/viewtopic.php?p=353224#p353224

[algol]

Difficult becuse Windows does not support ini files in uft-8 format - see: https://ghisler.ch/board/viewtopic.php?p=353224#p353224

Bummer! You never stop learning! So one more thought perhaps? Since UTF-8 because of its scope obviously cannot be mapped in full onto ANSI - would it perhaps help solving such incompatibility-problems to internally convert various common encodings (like ANSI, UTF-8, ASCII) to the more comprehensive yet Windows-supported UTF-16-(intel byte order)-format first - and then internally keep using UTF-16-IBO from there? This procedure should allow to correctly interpret even UTF-8-encoded ini-files while at the same time enabling TC to cope with a wealth of more exotic symbols, such as advanced math-operators and smileys at the same time.

[ghisler(Author)]

No, just save the ini file as UTF-16 (LE, little endian, or Intel byte order). This is fully supported by ini file functions.

[tuska]

After using the backup file "wincmd.ini" from 7.10.2023 everything works fine again.

Is there a special reason as to why (in order to remedy the dysfunctional ini-file-situation) you went back to a saved backup
(thereby possibly losing latest intentional changes) instead of simply re-encoding the latest version of your "wincmd.ini"
as ANSI from the editor of your choice?

I did not think of this possibility (the excitement was probably too great and the joy about the problem solution).
I tried to solve the difference between 7.10.2023 and 29.10.2023 with a synchronisation between the two wincmd.ini
files. I think it's working fine again so far...

I used the "EncInfo" plugin for Total Commander to display the encoding: [=encinfo.Encoding].

No, just save the ini file as UTF-16 (LE, little endian, or Intel byte order).
This is fully supported by ini file functions.

These two codings are available.
1. UTF-16LE with Signature
2. UTF-16LE without Signature
Do you have to use a certain coding or does it not matter which coding of these two you use?

(I have now inserted Unicode characters into the file "wincmd.ini" for test purposes and
EmEditor Pro suggested UTF-16LE with Signature as the encoding.
I have therefore saved the wincmd.ini in this format).

[ghisler(Author)]

Yes, you need to always use UTF-16 with signature. Otherwise there is no easy way to check whether it's UTF-16LE or UTF-16BE.

[tuska]

Yes, you need to always use UTF-16 with signature.
Otherwise there is no easy way to check whether it's UTF-16LE or UTF-16BE.

Thank you very much for the clarification!

[algol]

Yes, you need to always use UTF-16 with signature.
Otherwise there is no easy way to check whether it's UTF-16LE or UTF-16BE.

Thank you very much for the clarification!

In order to complete this important clarification I might add that many advanced editors (like "UltraEdit" in my case) also call this "Unicode signature" by the technical term "BOM"="Byte Order Mark". So "UTF-16LE with BOM" is the way to go.

[tuska]

In order to complete this important clarification I might add that many advanced editors
(like "UltraEdit" in my case) also call this "Unicode signature" by the technical term "BOM"="Byte Order Mark".
So "UTF-16LE with BOM" is the way to go.

Thanks!
Notepad3 also has the encoding with designation: Unicode (UTF-16 LE BOM).

Whereas, on the other hand, PSPad has these designations:
Unicode UTF-16 little endian
Unicode UTF-16 big endian
which again leaves me as a user at a loss as to which coding to use here.