Lister. There is the option to choose the encoding for search template?

[AntonyD]

As we know on the form "Find Files" we can set option for Encodings: 5 predefined types and one complex, based on plugins.
So WHY I can't use the same ability inside the Lister's 'Search' text form? Obviously that end user has logical proposals regarding
the fact that the text - which is searchable now - can be encoded in some ways, and the best thing here is to search it in a
parallel - by all Encodings. BUT! when I open via the Lister the founded file - I don't know initially - in which Encoding finally
my text was found.
And very often I have the case when text was copy-pasted as CP1251 inside the corresponding field on the form "Find Files",
but in the file the same text was coded as UTF-8. And now - when I will open in the Lister this file and with wrong Encoding
F7/Enter - will not give me proper result - Lister will not find my text for searching! Which obviously means that we MUST
have the same bunch of encoding options for choosing on the Lister's Search form which we have on the form "Find Files".
So, NOT only "whole words only", "Case sensitive", "Search hex string" and another 2 currently available options ARE matter
for that operation,

[Horst.Epp]

That would need an enhancement of the plugin interface.
At least for me, there is no file format which I view with pure Lister.
There are always plugins involved.

[Dalai]

Lister automatically searches for Unicode (UTF-16) text when it shows Unicode contents, i.e. Options > Unicode is selected. The same applies to UTF-8 and to ASCII (and ANSI obviously).

A file can contain mutiple pieces of text in different encodings. How is Lister supposed to show/mark the search results when you want to search for multiple encodings simultaneously?

Regards
Dalai

[AntonyD]

How is Lister supposed to show/mark the search results when you want to search for multiple encodings simultaneously?

I didn't understand the essence of the question. Total already does this itself. When we search using the "Find Files" form.
I simply ask to enter exactly the same options into the search form in the Lister window: Select encodings. And I MYSELF will now choose with my own hands in which form/encoding I need to find this required string now. And the search algorithms will work exactly the same as what ALREADY exists. In the “Find files” form, we get the required set of files with the desired search string inside their body when we mark these encodings.

[Dalai]

I didn't understand the essence of the question.

Let's assume you have a file with ANSI and UTF-8 text parts. Let's further assume that mutiple encodings can be selected in Lister's search window at the same time, just like in TC's Find Files. Let's also assume you enter a search phrase that can be found in both text encodings. Also consider the fact that Lister can show file contents in exactly one encoding at a time. Given these assumptions and facts, how is Lister supposed to show or mark the results when it can display a file in one encoding at a time? It just can't.

The encoding selection would need to be mutually exclusive, i.e. you can select either ASCII or ANSI or UTF-8 or Unicode (UTF-16) or Hex (though the last is not an encoding but the same thing applies), but not more than of them at the same time. The thing is, where would the improvement to the current implementation be then?

I hope it's clear now what I mean.

Total already does this itself. When we search using the "Find Files" form.

Yes, but it doesn't need to display any search phrases, i.e. where it found them, to the user. It just searches and adds them to the results list.

Regards
Dalai

[Fla$her]

And now - when I will open in the Lister this file and with wrong Encoding F7/Enter - will not give me proper result - Lister will not find my text for searching!

I am more concerned that there is a problem with F3 in the viewing area, which should automatically highlight the text specified earlier in the search dialog (Alt+F7). This applies primarily to the absence of the UTF-8/16 BOM signature, even when there is auto-detection for display and font.

[AntonyD]

The encoding selection would need to be mutually exclusive, i.e. you can select either ASCII or ANSI or UTF-8 or Unicode (UTF-16) or Hex (though the last is not an encoding but the same thing applies), but not more than of them at the same time. The thing is, where would the improvement to the current implementation be then?

It is in this "like-new" search window
Let's imagine that this encoding selection option is already there - on the form of 'Search' text action....
So now I just open this dialog, hold down the click-marker (yes - it’s not there yet, but let’s imagine that it is), which fixes the whole form ABOVE the lister window in modeless mode! That's very important! The search field ALREADY contains the required text for the search, because I opened the Lister immediately after the “Find Files” form - where all encodings were previously included and text for searching was inputted.
And now I press the Find button (or F3|F5). If nothing is found, then with just one easy movement I set another encoding (even if it is a mutually exclusive choice to begin with) and re-continue the search.
This concept MUCH simplifies the current state of affairs, when in fact I can also eventually find the text I need, using only the possibilities ALREADY available now. BUT now it is very multi-step'ed: You need to make a lot of extra clicks, there will be flickering of forms and different menus on the screen.

But in general, conceptually - I don’t quite understand - what is the difficulty in programming the selection of text that is in different encoding? After all, in any case, this is just a different set of selected characters that are present in the text. Yes, the text is readable in one encoding, but becomes completely unreadable in another. And highlighting a “strange” sequence of characters in the case when I was looking for a seemingly completely ordinary, humanly readable text - this seems strange. BUT! Only if we do not take into account that Lister yet knows how to show the contents of a file in different encodings! And if I initially opened a file in ANSI encoding in Lister, and the searched text was written there in UTF-8 encoding, then I could quite easily imagine the following work scenario in my head: in the text search field I typed this one UTF-8 encoded text, checked all the checkboxes of all encodings, ran a search, and it gave a non-zero result. And yes - I don’t know in which encoding the result was found, BUT! It’s just that now a special selection menu will appear on the screen with approximately the following text: “Your search pattern you are looking for was detected in the following encodings of this file <list of encodings>: Select which one you want to Reopen the file for you.” I just point at a line with UTF-8, the file itself is re-opened in this encoding! And the desired sequence of characters already stands out! If I click “Find Next” and the desired result is in the same encoding, then this new place in the text is simply highlighted.

[Fla$her]

there will be flickering of forms and menus on the screen.

If autodetect is used, it's sufficient to select the encoding in the menu if it's not detected automatically (OEM, no BOM). The problem remains in the quick view, where there is no menu.

[petermad]

The problem remains in the quick view, where there is no menu.

You can still press 6 for Unicode and 7 for UTF-8 in QuickView. You'll have to set focus to the Quick-view window first.

[Fla$her]

and 8 for UTF-8 in QuickView.

7. It's not easy to remember. ANSI —1, it's simple. But there is no OEM.