Improve sorting order for tag edit dialogs

Auto suggestion of last or most used tag is really useful is a very good idea.

But what if someone needs alphabetical list of tags?

Modifying autocompletion list (if few letters are added) can cause problems - now there is some logic in first item of suggestion list too!

Maybe different colours to destinguish between "presets" and "only used in layer" tags is a nice enhancement.

Most of the features are implemented in tageditor plugin (with bugs, yes), including preset/used lists. Now we should decide what functionality we must have in core).

What should we show, when ....

1.Nothing entered, primary autocomplete ->

a) most used in layer

b) last added to other object

2.Nothing entered, list drops ->

a) alphabetical [as is]

b) most used on top

c) last used on top

d) b or c + rest items alphabetical with colors

3.Something entered, primary autocomplete ->

a) now - not alphabetical, something else!

b) most used on top, starting from entered letters

c) last used on top, starting from entered letters

4.Something entered, list drops ->

a) now alphabetical, starting from entered letters

b) most used starting from entered letters on top

c) last used starting from entered letters on top

d) b or c + rest items alphabetical with colors

First idea is 1c 2b 3a? 4a?
Skyper`s idea: 2a with colors or 2d.

Do you plan to filter the object types before filtering most used ?

Replying to skyper:

Do you plan to filter the object types before filtering most used ?

Er.. how can we filter object types? based on other tags of the object?

I have made a patch for 1b - last manualy added tag will be always initially selected in add tag dialog.

Please have a look at it.

I can add some extra fuctionality, but let us decide what exactly should be done)

last tag repeat

Please tell me is something is wrong with this patch. It has minimal but rather useful functionality.

I do not know how to implement 2,4 because
1) we should not breaking alphabetical autocomplete behaviour - write special comparator?
2) How to maintain last-used or most-used list without slowing JOSM once more.

We all have limited time only, so please be patient.

I like 1b. I think that having the value filled in could be useful too.

I think I would prefer if the completion list was sorted by usage count computed by the last N added tags, possible weighted. The order of the tags not used isn't very important to me. Again, having the value from the last usage of the tag filled in could be nice.

Since people have different edit patterns, the behavior of the completion should probably be somewhat customizable.

I want better/additional shortcuts for navigation the list too. (#6412)

Replying to stoecker:

We all have limited time only, so please be patient.

Of course there are much more important fixes (and activities).
If you could find time to write some short comments about the suggested patches it would be great!)
(like 'need some improvements' or 'patch is ok' or 'we will look at it next week')

In r4109 (rworked).

Of course there are much more important fixes (and activities).

No. Every supplied patch is high priority for us.

If you could find time to write some short comments about the suggested patches it would be great! (like 'need some improvements' or 'patch is ok' or 'we will look at it next week')

If we find errors and problems by simply having a look, you will be told usually very quickly. If there is no comment to patches this means mostly, that it is ok in principle, but needs to be tested (or it has been overlooked :-) After approx. a week with no reaction you may assume overlooking took place and ask again :-).

We are only two administration people and we both have little time (whereas bastiK does most tasks in the last months). So please be patient when reaction is not as fast as you want. Or write a lot more and good patches and thus get an SVN account.

---

Regarding the sorting order - Changes are possible, but alphabetical is usually the easiest to understand.

What about that:

• first alphabetical from presets
• second alphabetical everything else.

This should then be used for all autocomplete boxes everywhere.

Thank you for good explanation and patch rework. It became more understandable and simple because of automatic tagging exclusion (which is not really needed).

About list structure - we often need fast access to 2-5 last added different tags (like addr:street, building, highway etc.)
So I agree with you suggestion in such form:

• first alphabetical from presets
• second alphabetical last N used (even if they are in presets)

(or vice versa)

Or you mean this :

• first alphabetical from presets
• second alphabetical other from current dataset ?

Then what to do with current dataset objects from presets - should they be in first or second sublist?

If there are some letters typed, both sublists are filtered of course and last used starting from these letters is selected, if possible.

I will try to make next patch, better one)

Replying to akks:

Thank you for good explanation and patch rework. It became more understandable and simple because of automatic tagging exclusion (which is not really needed).

About list structure - we often need fast access to 2-5 last added different tags (like addr:street, building, highway etc.)
So I agree with you suggestion in such form:

• first alphabetical from presets
• second alphabetical last N used (even if they are in presets)

(or vice versa)

Or you mean this :

• first alphabetical from presets
• second alphabetical other from current dataset ?

Then what to do with current dataset objects from presets - should they be in first or second sublist?

If there are some letters typed, both sublists are filtered of course and last used starting from these letters is selected, if possible.

I will try to make next patch, better one)

What we have at the moment (see AutoCompletionItemPritority):

• if an item is used in the dataset, it is preferred
• otherwise if one item is used in the presets, it has higher precedence
• last is alphabetical order

This applies to the suggestion that comes up, when you start typing. The items in the Combobox drop down list are sorted alphabetically nevertheless. This is good if you like to skim the list to look for an entry you remember vaguely. In addition, it isn't necessary to filter the list when you type, because the entries with the given starting letter(s) come directly below the selected entry.

Personally, what me annoys most regarding autocompletion is addr:housename and addr:state. I never use these, but they keep popping up when any object in the downloaded area is tagged like this.

So I suggest to introduce a usage counter that keeps track, how often a certain key or key-value was added by the user. I think it is enough to keep this hash in memory and reset on each restart.

The usage counter would take highest precedence. If 2 items have been used equally (or not at all), the one that is found in the dataset (or in the preset) would be preferred. I don't think there is a reason to change the sorting order in the drop down list.

Thank you for explanation of current behaviour. I will try to introduce counters and incorporate them carefully into AutoCompletionItemPritority.

Or you have time to implement it yourself?

Replying to akks:

Thank you for explanation of current behaviour. I will try to introduce counters and incorporate them carefully into AutoCompletionItemPritority.

It would be silly to refuse that offer...

Or you have time to implement it yourself?

...even if I had time to do it myself. :)

Btw., you sometimes write a closing bracket, like this)

What does it mean, exactly?

About ")" - it is a silly social network/SMS/forum tradition popular in Russia. Meaning - like :), but somewhat more formal (or just less notable)

I will really try to understand and modify the behaviour of AutoCompletionItemPritority. Actually, I am teaching JAVA SE/EE (by accident) and need some real project experience.

In #6096, another improvement for the sorting was proposed.