QuickSearch eXtended

Samuel · Post by *Samuel » 2011-11-09, 19:25 UTC

sheppaul wrote:I've just tried replacement rules using "tcmatch.dic".
This is quiet a nice feature as it's possible to search files simultaneously in both english and korean.

However, I've found some weird action.
"Case sensitive" (of english chars) does not work with "tcmatch.dic".

Here is the "tcmatch.dic".

You mean an entry like:

Code: Select all

g	ㄱ

should also replace "G" to "ㄱ"?
Sorry I think I will not include this feature. Use 2 entries instead:

Code: Select all

g	ㄱ
G	ㄱ

Edit:
Let me explain this a little bit more:
Perhaps you mean that "g" does not match "G" anymore with the above first entry. If you search for "goal" and the file is named "Goal.txt" then this entry changes the search string to "ㄱoal" and the filename is untouched. This is all done before the matching even starts. So "ㄱoal" doesn't fit to "Goal.txt" anymore.

Perhaps I should not have included this feature. It will probably cause much trouble.

sheppaul · Post by *sheppaul » 2011-11-10, 05:02 UTC

should also replace "G" to "ㄱ"?

It depends. In such a case of Quick Search, it doesn't matter to replace "G" to "ㄱ". Because it's almost possible to search quickly korean only using lead consonants.

I've seen the dictionary for Japaness. As you may know, there are no such replacement rules that should distinguish between captial and small letters. In case of Korean, it's much easier than Japanese as Korean alphabet is made of phonetic letters just like English. However, I agree it could cause some trouble.

Sorry I think I will not include this feature. Use 2 entries instead:

I've tried this. It works but what about the replacement rules including more than one character?

for example, the following is one of replacement rules from japanese dictionary.

Code: Select all

tcho	っちょ

Logically, the number of cases is 16. You should fill 16 entries to handle unexpected cases in dictionary.

Let me explain this a little bit more:
Perhaps you mean that "g" does not match "G" anymore with the above first entry. If you search for "goal" and the file is named "Goal.txt" then this entry changes the search string to "ㄱoal" and the filename is untouched. This is all done before the matching even starts. So "ㄱoal" doesn't fit to "Goal.txt" anymore.

If "g" should be replaced by "ㄱ", what about "goal.txt"?
"ㄱoal" doesn't fit to "Goal.txt" but fits to "goal.txt".

My suggestion:
IMHO, it would be better to have an independant option of case sensitive for replacement rules, if it's not so difficult to implement.
However, I can live without it.

Samuel · Post by *Samuel » 2011-11-10, 14:05 UTC

sheppaul wrote:
Sorry I think I will not include this feature. Use 2 entries instead:
I've tried this. It works but what about the replacement rules including more than one character?

for example, the following is one of replacement rules from japanese dictionary.
Code: Select all
tcho	っちょ
Logically, the number of cases is 16. You should fill 16 entries to handle unexpected cases in dictionary.

I knew this would come up.

sheppaul wrote:
Let me explain this a little bit more:
Perhaps you mean that "g" does not match "G" anymore with the above first entry. If you search for "goal" and the file is named "Goal.txt" then this entry changes the search string to "ㄱoal" and the filename is untouched. This is all done before the matching even starts. So "ㄱoal" doesn't fit to "Goal.txt" anymore.
If "g" should be replaced by "ㄱ", what about "goal.txt"?
"ㄱoal" doesn't fit to "Goal.txt" but fits to "goal.txt".

"g" fits "goal.txt" because it would be changed to "ㄱoal.txt".

sheppaul wrote:My suggestion:
IMHO, it would be better to have an independant option of case sensitive for replacement rules, if it's not so difficult to implement.
However, I can live without it.

I don't think I will implement it, sry. You may implement it yourself, as the code is available.

Evds · Post by *Evds » 2011-12-05, 22:05 UTC

If i open the quickview panel (ctrl+q) and then open the search window (ctrl+s) and then move with the arrow keys to a pdf tc hangs. If i only open the quickview panel (and not the search window) i can move to the same pdf file with the arrows keys without a problem.

Can someone simulate this problem ?

TC8.0b11, QuickSearch, sLister 1.1.2

Samuel · Post by *Samuel » 2011-12-05, 22:12 UTC

a) Are you using QSx?
b) Could you post your tcmatch.ini?
c) What about uninstalling QSx?
d) Do you have (lister) plugins installed in TC? (please enumerate them)

Evds · Post by *Evds » 2011-12-06, 11:17 UTC

Hi Samuel,

I'm using QSx 2.0.1. I uninstalled all my lister plugins except sLister (viewer for pdf files).

Open quickview panel move with cursor keys over pdf files and they all show up in the quickview panel.
Open quickview panel and open QSx and when i move then with the cursor keys over a pdf file tc stalls.

tcmatch.ini:
[general]
simple_search_activate_char=
regex_search_activate_char=?
leven_search_activate_char=<
case_sensitive=0
allow_empty_result=0
preset_activate_char=>
simple_search_match_beginning_activate_char=^
and_separator_char=" "
or_separator_char=|
wdx_separator_char=/
negate_char=!
filter_files_and_folders=3
match_beginning=0
use_pinyin=0
srch_activate_char=*
[wdx]
debug_output=1
wdx_cache=1000
[gui]
override_search=1
invert_result=0
one_line_gui=1
show_presets=0

Samuel · Post by *Samuel » 2011-12-06, 11:36 UTC

e) Can you reproduce the bug when QSx is uninstalled? (or just rename "tcmatch.dll" to "tcmatch.bak" and restart TC)
f) Can you also try to uninstall sLister?
g) what search string do you use (just to make sure its not something weird)
h) Can you reproduce the bug when the additional user interface is disabled?

Evds · Post by *Evds » 2011-12-06, 17:31 UTC

e) renamed tcmatch.dll and tc still stalls
f) uninstalled sLister and the problem is no more present
g) is of no importants, you can leave the search field empty

Samuel · Post by *Samuel » 2011-12-06, 19:00 UTC

So it seems to be no bug of QSx or TCs QS but instead of sLister. Please ask the author of sLister if he can reproduce and fix it.

Evds · Post by *Evds » 2011-12-07, 21:48 UTC

thx for the help.

Samuel · Post by *Samuel » 2011-12-08, 05:50 UTC

Your welcome.

jo2h2 · Post by *jo2h2 » 2011-12-18, 00:41 UTC

Hello,

I really love your addon - today I tried the content plugin feature and I was wondering whether I could use

wdx_text_plugin1=Comment@%commander_path%\Plugins\wdx\Comments\CommentsWDX.wdx

instead of real physical path - I am using TC in a portable installation and on different systems with different folders and %commander_path% would be great - is this possible ?

Thanks a lot !

Samuel · Post by *Samuel » 2011-12-18, 13:10 UTC

Hi,

sorry I will not include variables like "%commander_path%".
However you may currently use relative paths like: "Plugins\wdx\Comments\CommentsWDX.wdx"

Greetings,
Samuel

Samuel · Post by *Samuel » 2012-02-09, 21:25 UTC

Update. Version 2.2.1 is available.

Code: Select all

Version 2.2.1
 - Added Spanish translation for the user interface - thank you Victor Emmanuel

seb- · Post by *seb- » 2012-03-12, 10:01 UTC

Hi Samuel,

thanks for this cool plugin.

I installed it because i'm in the search of something which i'd describe as "Search in Columns".

Is there any possibility to search in columns different form Filename-column?

especially searching in the comments column (if activated) would be a handy feature.

I know theres the possibility to filter with Ctrl+F12. But filtering for a searchstring in the file comment (or any other column provided by TC direclty or any Content Plugin) requires manually creating a filter...
This is a tedious work and actually it spams the list of filters... i might just search for a specific substring in Comments once and then never again...

Any chance getting such a feature with QuickSearch Extended?

thx again... seb

Total Commander

QuickSearch eXtended

QuickSearch and sLister crash

%commander_path% for wdx_text_plugin ?