Strings with backslashes in Lister

[browny]

The subject is handling of escape sequences, enumerated in the help file: \\, \t, \n.

It feels that the current behaviour is more of a bug than a feature, because:
1. Counterintuitive: literal seach is expected, not escaped one.
When a string is selected and Ctrl+F pressed, the selection is copied and used as a search pattern - and even this same selection would never be found if it contained one of the magic sequences. This is baffling. Next, there is also inconvenience to scan the string, find offending sequences and add backslashes - particularly because backslashes are quite common in Windows, so this will happen sooner or later.
2. Inconsistent: c:\bin will find c:\bin, but c:\tin will fail on c:\tin. Consistent, as in regular expression, is to have double backslashes in search string - c:\\bin.
3. Creates a lot of confusion - my bug report has been appended to the help topic which already referred to a bunch of similar issues in different parts of the forum. And there are other topics related to the subject, not glued to the mentioned help topic.

Two alternatives might be considered.
Preferably, solution would be to make search literal by default, and add - similar to Akelpad - checkbox Esc sequences (\[0020], \\, \t, \n).
Or, a simpler way would be to add a checkbox forbidding escape sequences; and it might be ON by default.

[Sir_SiLvA]

May feel buggy for you but it has been like this forever and should not be changed now just because you "feel" something

[white]

This indeed is a feature that has fooled a lot of users. Not only when using search in Lister, but also when searching for files containing a certain text. I agree that an explicit option should be created for this, like suggested by a number of people.

[Dalai]

I support an option that enables literal search. But considering how long the search has worked this way, I guess it should be disabled by default. There could be an additional option in wincmd.ini that enables the literal search by default. I think that would satisfy long-time users who are used to the old way as well as (new) users who know it differently from other programs or have different expectations.

[white]

I support an option that enables literal search. But considering how long the search has worked this way, I guess it should be disabled by default.
... I think that would satisfy long-time users who are used to the old way...

How do you know what old users prefer? Old users never had the choice between literal search and extended search. Probably \n is used the most when the user actually wants to do an extended search. What do you think old users would prefer? Being able to type \n without having to click an option? Or being able to do a literal search without having to click an option or having to double backslashes?

[Dalai]

The suggestion is about Lister's search, but there's much more to it than it might seem at first glance.

Lister's search can be more or less integrated into TC's search as the search terms are transferred to Lister's search when opening a file from TC's Find Files window. And if Lister's search is changed, the regular search has to change with it - otherwise it would become inconsistent or a complete mess.

Long-time users could have saved searches that would no longer work as expected when suddenly a literal search is performed instead. This can mislead users when search terms are not found when they were previously (or vice versa). I'll try to give an example. If someone has "\n" as part of a text search in a saved search, e.g. to find some text before and after a linebreak, a literal search wouldn't yield any results unless the file contains that text.

What I'm trying to say is that one has to be very careful when changing defaults, especially ones that change documented decade-old behavior. That's why I proposed a second setting that directly influences whether or not a literal search is performed by default.

[white]

Long-time users could have saved searches that would no longer work as expected when suddenly a literal search is performed instead. This can mislead users when search terms are not found when they were previously (or vice versa). I'll try to give an example. If someone has "\n" as part of a text search in a saved search, e.g. to find some text before and after a linebreak, a literal search wouldn't yield any results unless the file contains that text.

I am fully aware of the relevance of saved searches, but in my opinion that is an implementation issue. A new default search method should not affect currently saved searches. If it does, it's simply implemented badly.

[browny]

May feel buggy for you but it has been like this forever and should not be changed now just because you "feel" something

These wise words deserve to be moved to another topic (request moderators assistance ). Doing like forever, we still would be dwelling in cave and hunting for food with stones and sticks.

[browny]

From top of my head, there were no common program with non-literal search be default; grep is abnormal by definition.

I support an option that enables literal search. But considering how long the search has worked this way, I guess it should be disabled by default. There could be an additional option in wincmd.ini that enables the literal search by default.

This means, a new user should first figure out how to enable literal searches with hidden option.
Also, having two settings for essencially one options is a great way to mess things up.
It should be an explicit option in GUI, not a hidden toggle in .ini file.
For old-timer who already managed to figure out the peculiarities of the current implementation, it would be simple to tick a checkbox.

[Dalai]

This means, a new user should first figure out how to enable literal searches with hidden option.

You misunderstood. With the first option I was referring to a checkbox in both Lister's search and Find Files. With the second option I meant an INI setting that controls whether or not this checkbox is enabled by default, and possibly save the checkbox state at the same time.

[xxxdo1]

General search disables escape characters, regular expression enables escape characters.
This is what most people are used to.

[browny]

You misunderstood.

Maybe. Option upon option and more in .ini file to control a part of the option... the word mess was already mentioned.
Versus simple and clear: literal search by default, escaped if user ticks it.

General search disables escape characters, regular expression enables escape characters.

Regular expression have too many characters to be screened and are tough to read, so simplified escape sequences are handy in certain cases.

[xxxdo1]

Adding too many checkbox options is not a good idea.
Regular expressions contain escape characters, and the two do not conflict.
In my usage, I use regular expressions when I need to escape characters, and for general searches I consider it disabled.

[petermad]

2xxxdo1

An how do you find line breaks with regexp - $ only finds the line end in the first line. .$ find most line breaks but not in empty lines.

[xxxdo1]

2petermad
I was wrong, I used boost regular expression, it supports escape characters, it can use \n to find line breaks.