More useful matching

[michael-heerdegen]

Hi,

while using this fine tool for a while now, I miss a matching feature from the rest of helm. When entering multiple words, I would like to see all lines that contain all of these words - in any order. E.g., when giving "soup eel", I want to see the entry for "eel soup". This would make it possible to narrow down a long list of candidates by giving more keywords without having to know how the exact dictionary entry looks like.

Do you agree that could be useful?

@thierryvolpiatto Is this possible at all with the current implementation? I guess it's just the match plugin that I'm missing. Any chance to get it work here?

[thierryvolpiatto]

michael-heerdegen [email protected] writes:

Hi,

while using this fine tool for a while now, I miss a matching feature
from the rest of helm. When entering multiple words, I would like to
see all lines that contain all of these words - in any order. E.g.,
when giving "soup eel", I want to see the entry for "eel soup". This
would make it possible to narrow down a long list of candidates by
giving more keywords without having to know how the exact dictionary
entry looks like.

Do you agree that could be useful?

@thierryvolpiatto Is this possible at all with the current implementation? I guess it's just the match plugin that I'm missing. Any chance to get it work here?

Actually it is working as it is:

here a line from my dictionary:

jilt {v} /dʒɪlt/ (to jilt) plaquer, quitter, abandonner

I can get it by entering "aba jil"

---

Reply to this email directly or view it on GitHub:
#20

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[michael-heerdegen]

No, not here. I just upgraded helm and helm-dictionary, just to be sure, and used helm.sh. It's not working. Does it work for you with helm.sh? I just did a trivial M-x helm-dictionary.

[michael-heerdegen]

Just found out that it works when I redefine

(defun helm-dictionary-transformer (candidates)
  "Formats entries retrieved from the data base."
  candidates)

Why doesn't it work with the non-trivial transformer?

[michael-heerdegen]

Yes, it's the transformer:

(helm-dictionary-transformer
 '("Aalsuppe {f} [cook.] | Aalsuppen {pl} :: eel soup | eel soups"))

returns nil.

[michael-heerdegen]

The culprit is this part in `helm-dictionary-transformer':

if (or (string-match helm-pattern l1term)
       (string-match helm-pattern l2term))

[thierryvolpiatto]

michael-heerdegen [email protected] writes:

The culprit is this part in `helm-dictionary-transformer':

if (or (string-match helm-pattern l1term)
       (string-match helm-pattern l2term))

Hoops! yes indeed, I use my own version of `helm-dictionary-transformer' which
have this removed.

---

Reply to this email directly or view it on GitHub:
#20 (comment)

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[tmalsburg]

if (or (string-match helm-pattern l1term)
       (string-match helm-pattern l2term))

Hm, unfortunately this check is needed because a record (= line in the database) can contain several lexical entries. If we don't check, helm-dictionary will show results where neither the source nor the target term matches the search expression. Other dictionary apps using these data bases treat this issue in the same way, e.g., ding. So removing the above lines is not a good solution. Instead, we have to find a way to do the matching in the same way as helm does it. I don't understand helm well enough to see how this can be done, though. Thierry?

[thierryvolpiatto]

Titus von der Malsburg [email protected] writes:

if (or (string-match helm-pattern l1term)
       (string-match helm-pattern l2term))

Hm, unfortunately this check is needed because a record (= line in the
database) can contain several lexical entries. If we don't check,
helm-dictionary will show results where neither the source nor the
target term matches the search expression.

Sorry but I don't understand this, do you have concrete examples of these
use cases?

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[michael-heerdegen]

I see what Titus means. Several entries in the dictionary are often grouped in one line, the syntax is

a1 | a2 | a3 ... | an   :: b1 | b2 | b3 ... |bn

where ai corresponds to bi. The ai are somehow related, but different. That's why the transformer needs a nested loop. Titus creates an own candidate for each a, b pair, but wants to collect only those who are really matching the helm pattern. The other pairs should not be candidates, cause they are not really matches.

[tmalsburg]

Sure. Here's an entry from the German/English dictionary:

Abänderung {f}; Modifikation {f}; Modifizierung {f}; (teiweise) Änderung {f} (an etw.) | Abänderungen {pl}; Modifikationen {pl}; Modifizierungen {pl}; Änderungen {pl} | Ich habe am urspünglichen Entwurf ein paar Änderungen vorgenommen. :: modification (to sth.) | modifications | I've made one or two modifications to the original design.

The separator | is used to separate three sub-entries:

• Abänderung {f}; Modifikation {f}; Modifizierung {f}; (teiweise) Änderung {f} (an etw.)
• Abänderungen {pl}; Modifikationen {pl}; Modifizierungen {pl}; Änderungen {pl}
• Ich habe am urspünglichen Entwurf ein paar Änderungen vorgenommen.

When I search for "Entwurf" all three sub-entries are matched by helm because they occur on the same line in the data base. However, the search term "Entwurf" occurs only in the third sub-entry. The purpose of the additional check is to make sure, that we only get results for sub-entries that actually match the search term, i.e., the third sub-entry. When we remove this check, we may get countless of non-matching results. Some dictionaries make heavy use of sub-entries (e.g., the German/English dictionary), and there it really matters whether or not you have this additional check. Other dictionaries don't use sub-entries a lot and there it doesn't make a big difference.

[thierryvolpiatto]

Titus von der Malsburg [email protected] writes:

Sure. Here's an entry from the German/English dictionary:

Abänderung {f}; Modifikation {f}; Modifizierung {f}; (teiweise)

Änderung {f} (an etw.) | Abänderungen {pl}; Modifikationen {pl};
Modifizierungen {pl}; Änderungen {pl} | Ich habe am urspünglichen
Entwurf ein paar Änderungen vorgenommen. :: modification (to sth.) |
modifications | I've made one or two modifications to the original
design.

The separator | is used to separate three sub-entries:

• Abänderung {f}; Modifikation {f}; Modifizierung {f}; (teiweise) Änderung {f} (an etw.)
• Abänderungen {pl}; Modifikationen {pl}; Modifizierungen {pl}; Änderungen {pl}
• Ich habe am urspünglichen Entwurf ein paar Änderungen vorgenommen.

When I search for "Entwurf" all three sub-entries are matched by helm
because they occur on the same line in the data base. However, the
search term "Entwurf" occurs only in the third sub-entry. The purpose
of the additional check is to make sure, that we only get results for
sub-entries that actually match the search term, i.e., the third
sub-entry. When we remove this check, we may get countless of
non-matching results. Some dictionaries make heavy use of sub-entries
(e.g., the German/English dictionary), and there it really matters
whether or not you have this additional check. Other dictionaries
don't use sub-entries a lot and there it doesn't make a big
difference.

Did you try with the filtered-candidate-transformer ?

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[michael-heerdegen]

I guess in case of helm-match-plugin-mode' non-nil, we must test with any of thehelm-mp-default-match-functions', instead of `string-match'. Is there a smarter way?

[michael-heerdegen]

Did you try with the filtered-candidate-transformer ?

Sorry, I don't understand what that means.

[thierryvolpiatto]

michael-heerdegen [email protected] writes:

Did you try with the filtered-candidate-transformer ?

Sorry, I don't understand what that means.

Use filtered-candidate-transformer instead of candidate-transformer.

---

Reply to this email directly or view it on GitHub:
#20 (comment)

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[tmalsburg]

Thierry, to be honest, I don't know what filtered-candidate-transformer does. My impression was that it is typically used when we get candidates already filtered from a process, which is not the case here, or when a reference to the source is needed. I don't see how it helps us here.

[michael-heerdegen]

I tried to do what Thierry suggested. I used the original function, with the matching (if) part removed and one additional arg, as filtered-candidate-transformer'. But I saw false positve matches, just like withcandidate-transformer'.

[thierryvolpiatto]

Titus von der Malsburg [email protected] writes:

Sure. Here's an entry from the German/English dictionary:

Abänderung {f}; Modifikation {f}; Modifizierung {f}; (teiweise)

Änderung {f} (an etw.) | Abänderungen {pl}; Modifikationen {pl};
Modifizierungen {pl}; Änderungen {pl} | Ich habe am urspünglichen
Entwurf ein paar Änderungen vorgenommen. :: modification (to sth.) |
modifications | I've made one or two modifications to the original
design.

The separator | is used to separate three sub-entries:

• Abänderung {f}; Modifikation {f}; Modifizierung {f}; (teiweise) Änderung {f} (an etw.)
• Abänderungen {pl}; Modifikationen {pl}; Modifizierungen {pl}; Änderungen {pl}
• Ich habe am urspünglichen Entwurf ein paar Änderungen vorgenommen.

Ok I understand now, I have only one entry like this in the en-fr
dictionary.

When I search for "Entwurf" all three sub-entries are matched by helm
because they occur on the same line in the data base. However, the
search term "Entwurf" occurs only in the third sub-entry.

Yes but isn't it related to the whole line contents ?

The purpose of the additional check is to make sure, that we only get
results for sub-entries that actually match the search term, i.e., the
third sub-entry. When we remove this check, we may get countless of
non-matching results. Some dictionaries make heavy use of sub-entries
(e.g., the German/English dictionary), and there it really matters
whether or not you have this additional check. Other dictionaries
don't use sub-entries a lot and there it doesn't make a big
difference.

So probably you can implement your source differently with
candidates-in-buffer.

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[tmalsburg]

Upon thinking about this a bit more, I'm reluctant to change the current behaviour. I often search for things like "to hide" when I'm interested in the verb. If I just search "hide", I get countless of other entries that contain hide like "hideout", "hideaway", "hide glue", ... If we'd implement the search as Michael suggests, then I couldn't pull this trick any more. Searching for "to hide" would then also return entries such as "to save one's hide".

[michael-heerdegen]

You can still search for to\ hide to solve this problem. IMHO no reason be be inconsisitent with the rest of helm. As a user I wouldn't expect the behavior we currently have. Maybe you could introduce a user option?

[tmalsburg]

Hm, I didn't know about the possibility to escape the space. In that case, I'm ok with the change. No need for an user option. I will try to work on it but I'm a bit busy at the moment, so don't be surprised if it takes a while.

[michael-heerdegen]

Great! No need to hurry, this isn't urgent.

[michael-heerdegen]

Just a reminder, although I know this is bad behavior ...- I don't want this to be forgotten. Tell me if there is anthing I can do to help.

[tmalsburg]

It's not forgotten and I actually also want this feature.