It was a test on x32 only. x64 will follow soon.Samuel wrote:I worked on a new version that should improve the experience with the Korean language:
QuickSearch eXtended Korean (x32) beta 1
Please install the regular version first and overwrite the "tcmatch.dll" with the packed file. You need "use_pinyin=1" in your "tcmatch.ini" to make it work.
(I plan to release the merged final [including x64 / readme and stuff] in around 2 weeks.)
QuickSearch eXtended
Moderators: Hacker, petermad, Stefan2, white
- Samuel
- Power Member
- Posts: 1930
- Joined: 2003-08-29, 15:44 UTC
- Location: Germany, Brandenburg an der Havel
- Contact:
To quote myself:
- Samuel
- Power Member
- Posts: 1930
- Joined: 2003-08-29, 15:44 UTC
- Location: Germany, Brandenburg an der Havel
- Contact:
Update. Version 2.2.0 is available.
Code: Select all
Version 2.2.0
- Added support for Korean lead syllable search
- Added support for dictionaries (tcmatch.dic) - see help file for details
- Added example dictionary for Japanese
- Added Korean readme - thank you sheppaul
Now it should.sheppaul wrote:64bit version of QSx is not working with Korean.
- Samuel
- Power Member
- Posts: 1930
- Joined: 2003-08-29, 15:44 UTC
- Location: Germany, Brandenburg an der Havel
- Contact:
2infimum
Can your try the included Japanese dictionary? Does it help?
Helpfile description of the new dictionary replacements:
Can your try the included Japanese dictionary? Does it help?
Helpfile description of the new dictionary replacements:
Perhaps the keys and values, where the key is longer than one character should just be removed.helpfile wrote:Replacement rules
Beside the char replacement rules available in the user interface, it is possible to replace words with help of a dictionary. If there is a file named "tcmatch.dic" (Format: UTF16-LE) then it will be parsed for valid entries. A valid entry in that file is a line that contains a key and a value divided by a tab stop character. The file is not allowed to contain the same key twice.
When the search is in progress, every occurrence of any key in the filename or in the filter string is replaced by the according value. When more than one replacement is possible, replacing long keys has higher priority.
Disadvantages:
- Changes in the file "tcmatch.dic" will be activated after a restart of Total Commander.
- Already replaced parts of the string are not considered for further replacements, because this could lead to infinite loops.
- Any key that consists of more than one character will not be found when searching for the leading part of the key. For example the key is "kya" and the value is "きゃ". If the file is named "kya.txt" and the search string is "ky" so far, then the file "kya.txt" will not be found. The new filename would be "きゃ.txt", but the new search string is not yet "きゃ” but still "ky".
Suggestions are appreciated.
It works. Thanks.
Is this:
If the first quote is referring to something else, could you elaborate a little bit more?
Is this:
referring to this?Samuel wrote:Perhaps the keys and values, where the key is longer than one character should just be removed.
I take it that the "normal" incremental search is not compatible with tcmatch. If that's the case, so be it.- Any key that consists of more than one character will not be found when searching for the leading part of the key. For example the key is "kya" and the value is "きゃ". If the file is named "kya.txt" and the search string is "ky" so far, then the file "kya.txt" will not be found. The new filename would be "きゃ.txt", but the new search string is not yet "きゃ” but still "ky".
If the first quote is referring to something else, could you elaborate a little bit more?
- Samuel
- Power Member
- Posts: 1930
- Joined: 2003-08-29, 15:44 UTC
- Location: Germany, Brandenburg an der Havel
- Contact:
Yes.infimum wrote:It works. Thanks.
Is this:referring to this?Samuel wrote:Perhaps the keys and values, where the key is longer than one character should just be removed.- Any key that consists of more than one character will not be found when searching for the leading part of the key. For example the key is "kya" and the value is "きゃ". If the file is named "kya.txt" and the search string is "ky" so far, then the file "kya.txt" will not be found. The new filename would be "きゃ.txt", but the new search string is not yet "きゃ” but still "ky".
The problem is:infimum wrote:I take it that the "normal" incremental search is not compatible with tcmatch. If that's the case, so be it.
I currently replace all occurrences at the same time.
To avoid this behavior I would need to replace only some of the occurrences, but I don't know which. (trying every combination would be very time consuming under certain conditions)
- Samuel
- Power Member
- Posts: 1930
- Joined: 2003-08-29, 15:44 UTC
- Location: Germany, Brandenburg an der Havel
- Contact:
Yes I forgot to change this in one place. In the next version this will not be needed anymore.sheppaul wrote:PinYin option must be enabled for Korean search?
Lead syllable search does not work with pinyin disabled.
It's not restricted to the lead consonant: "ㄱ" will match "각", but also "가" will do. I think I will leave it for now.sheppaul wrote:IMHO, Initial (or lead) Consonant search would be more suitable explanation for the option.
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".
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".