Autocompleting entities corrupts the text you're typing when the match is not at the start

wjt commented

2015-04-20 17:35:52 +00:00

Suppose you have the following entities:

Tomas Bug
Yanis Testerson

Now try to add Yanis Testerson to a time range:

Open the editor, set an in and out point
Click + to tag an entity of the relevant type.
Type T. Two completions are offered in the menu, with the letter you have typed highlighted in each name: Tomas Bug and Yanis Testerson. The first one is filled into the entry field as a placeholder. So far, so good.
Type e. The menu is updated to remove Tomas Bug and move Yanis Testerson to the top, which is correct. But the entry field now reads: Yenis Testerson – the first letter we typed has been replaced by the first letter of the suggestion, even though the match was not anchored at the start.
Type the third letter, s. Now the entry reads Yes, and there are no matches.

This doesn't seem to happen when the match is anchored at the start of the first suggested entity's name.

Suppose you have the following entities: * Tomas Bug * Yanis Testerson Now try to add *Yanis Testerson* to a time range: 1. Open the editor, set an in and out point 2. Click **+** to tag an entity of the relevant type. 3. Type **T**. Two completions are offered in the menu, with the letter you have typed highlighted in each name: ***T**omas Bug* and *Yanis **T**esterson*. The first one is filled into the entry field as a placeholder. So far, so good. 4. Type **e**. The menu is updated to remove *Tomas Bug* and move *Yanis **Te**sterson* to the top, which is correct. But the entry field now reads: **Ye**nis Testerson – the first letter we typed has been replaced by the first letter of the suggestion, even though the match was not anchored at the start. 5. Type the third letter, **s**. Now the entry reads **Yes**, and there are no matches. This doesn't seem to happen when the match is anchored at the start of the first suggested entity's name.

wjt added this to the 14.04 milestone 2015-04-20 17:35:52 +00:00

rlx was assigned by wjt

2015-04-20 17:35:52 +00:00

wjt added the

normal

defect

labels 2015-04-20 17:35:52 +00:00

wjt commented

2015-04-20 17:48:35 +00:00

Author

Actually, this description is not quite accurate: “Yanis Testerson” is actually named “Yenis Testerson”. The difference is that when the two-character input “Te” is corrupted to “Ye”, it does actually match the first two characters of “Yenis Testerson”.

rlx commented

2015-04-20 18:26:47 +00:00

Owner

Autocomplete should probably be limited to leading matches.

wjt commented

2015-04-22 11:45:04 +00:00

Author

I think non-leading matches are useful: anecdotally, surnames are more unique than forenames, and people expect to be able to type the surname.

Is alternativeNames consulted when auto-completing? Many of these actors do actually have unique, confusingly-named "tags" mostly derived from their surname or their common nickname. If I populated these into Pandora, and they were shown and offered as completions in the entity sidebar, then only allowing leading matches might be okay.

I think non-leading matches are useful: anecdotally, surnames are more unique than forenames, and people expect to be able to type the surname. Is [alternativeNames](https://wiki.0x2620.org/browser/pandora/pandora/entity/models.py#L38) consulted when auto-completing? Many of these actors do actually have unique, confusingly-named "tags" mostly derived from their surname or their common nickname. If I populated these into Pandora, and they were shown and offered as completions in the entity sidebar, then only allowing leading matches might be okay.

rlx commented

2015-04-22 11:48:47 +00:00

Owner

Also see: #1023

wjt commented

2016-03-02 16:39:56 +00:00

Author

Attachment 0001-Autocomplete-only-replace-input-when-a-prefix-matche.patch (1714 bytes) added

**Attachment** 0001-Autocomplete-only-replace-input-when-a-prefix-matche.patch (1714 bytes) added

0001-Autocomplete-only-replace-input-when-a-prefix-matche.patch

1.7 KiB

wjt commented

2016-03-02 16:43:35 +00:00

Author

I haven't tried to address #1023 at all; here's a fix for input getting mangled by the best match being a non-leading one.

Using String.toLowerCase() to match the prefix fixes the common case where you want "joh" to be recognised as a prefix of "John Smith". I'm sure one could contrive a situation where this could still mangle your input ("ß" vs "ss", maybe?) but I think it's probably fine in practice.

I haven't tried to address #1023 at all; here's a fix for input getting mangled by the best match being a non-leading one. Using String.toLowerCase() to match the prefix fixes the common case where you want "joh" to be recognised as a prefix of "John Smith". I'm sure one could contrive a situation where this could still mangle your input ("ß" vs "ss", maybe?) but I think it's probably fine in practice.

wjt added the

oxjs

label 2016-03-02 17:10:18 +00:00

Will Thompson commented

2016-03-05 09:45:46 +00:00

Owner

In 3637b70/oxjs:

#!CommitTicketReference repository="oxjs" revision="3637b7024442b4e28e4116c958bf16196d068b1f"
Autocomplete: only replace input when a prefix matches (fixes #2753)

Previously, if the top match for "Smi" was "John Smith", the contents of
the field would be changed to "Smi[n Smith]" (where square brackets
indicate selection). On top of this, if you then type the fourth letter
("n"), the input becomes "Smin", which is not what you typed.

This preserves the "happy path" for replacing the field contents if
there is a prefix match, but without making the field unusable if
there's an infix match.

In [3637b70/oxjs](https://code.0x2620.org/0x2620/pandora/commit/3637b7024442b4e28e4116c958bf16196d068b1f): ``` #!CommitTicketReference repository="oxjs" revision="3637b7024442b4e28e4116c958bf16196d068b1f" Autocomplete: only replace input when a prefix matches (fixes #2753) Previously, if the top match for "Smi" was "John Smith", the contents of the field would be changed to "Smi[n Smith]" (where square brackets indicate selection). On top of this, if you then type the fourth letter ("n"), the input becomes "Smin", which is not what you typed. This preserves the "happy path" for replacing the field contents if there is a prefix match, but without making the field unusable if there's an infix match. ```

0x2620 added the

fixed

label 2016-03-05 09:45:46 +00:00

0x2620 closed this issue

2016-03-05 09:45:46 +00:00

Autocompleting entities corrupts the text you're typing when the match is not at the start #2753