Improve Autocompletion

[GerdP]

When tagging guidepost I often have to enter several tag keys like
direction_north=*, direction_north:route=*, and direction_north:symbol, followed by similar tags for other directions. Sometimes I only need direction=*
Autocompletion too often suggests the longest match, e.g. when I start typing dir it may suggest key direction_northwest:symbol instead of only direction.
I typically have to either type a lot more characters or I use the cursor to get to wanted position. Both are time consuming.
Is there an option to tell JOSM that it should use the shortest match instead? So, e.g. suggest
direction when typing dir, and then, after typing "_n" it should suggest direction_north.
I think I have the same problem with tag keys like bicycle:left:surface, bicycle:left:traffic_sign etc.

If there is no such option: Wouldn't it be better to do this by default?

I think the same is true for tag values, e.g. the value for direction_northwest:symbol can be
train_station;none;train_station. Now, when I tag a differnt guidepost and enter the value for tag direction_northwest:symbol JOSM might suggest train_station;none;train_station instead of only train_station when I start typing "t" assuming that there is a tag direction_northwest:symbol=train_station in the data or in the presets.

Addition 1: Some tags like survey:date or check_date or start_date contain dates or years. It would be good if JOSM would sort those so that the oldest date comes last in the list of known values instead of sorting the values alphabetically (-> oldest date comes first). This is also a good idea for all tags with prefixes like check_date: and maybe also with suffixes like :date.
Addition 2: The autocompletion text field for the upload comment should also use the most recent matching entry instead of the first in a list which seems to be sorted alphabetically. This is a problem when JOSM decides to empty the field because of preference upload.comment.max-age which is set to 14400 seconds (4 hours) by default.
I've quite often not noticed this problem and uploaded with the wrong comment.

[stoecker]

I think it's taking the first suggestion in the list and the longer ones with _ are probably before the shorter ones. Solution to this would be to change sorting or allow different sorting methods.

• alphabetical
• personal use count
• use count in database
• somehow weighted (i.e. is in presets, usage, ...)

[GerdP]

I'll have a closer look at the current implementation. Another approach is to change the way how Ctrl+Cursor left/right moves to the next position. It would help to stop at the special characters like ":" and "_".

[GerdP]

The problem here is that JOSM prefers to present a matching key/value that was recently used. This works very well in most cases but for these long keys with many similar characters in the prefix it doesn't work well. Maybe it helps to ignore recent inputs with e.g. 10 or more characters. I am experimenting now with this change:

src/org/openstreetmap/josm/gui/tagging/ac/AutoCompletionManager.java

@@ -230 +230 @@
     protected Collection<String> getUserInputKeys() {
         List<String> keys = USER_INPUT_TAG_CACHE.stream()
                 .filter(tag -> !tag.defaultKey)
+                .filter(tag -> tag.key.length() < 10)
                 .map(tag -> tag.key)
                 .collect(Collectors.toList());
         Collections.reverse(keys);

If it helps I would use a user preference instead of the hard coded limit 10.

[GerdP]

No, not much better, and sometimes more confusing. Too simple :(
Maybe guideposts simply need a special plugin. OTOH we have the same problem with tags like sidewalk:left:bicycle=yes.

[GerdP]

Allow to exclude value auto-completion for certain keys specifed in a preference

[GerdP]

With 24516-no-automplete-for-keys.patch it is possible to define a filter for tag keys for which the auto-completion of tag values should never be done. This was suggested in this discussion ​https://community.openstreetmap.org/t/die-josm-autovervollstandigung-ist-sub-optimal/136717
The code is based on the changes introduced for #12554.
Edit stop-autocomplete values filter is a bit clumsy, please suggest a better text for the menu entry.

[stoecker]

"Edit autocomplete filter"?

[GerdP]

I still want to implement something that allows to improve the auto-completion of tag keys, so the text should make clear that one edits a tag key filter which is used to swich off the autocompletion of the value for those keys matching the filter.

[stoecker]

However you name it, people will misunderstand. Explain details in the dialog afterwards, not in the menu item.

[GerdP]

Yes, I'd like to do that, but the dialog afterwards is the standard search dialog.

[stoecker]

Add an variant with optional description parameter?

[GerdP]

Maybe. I'll have a closer look tomorrow.

[StephaneP]

What about a shortcut to "validate" sub key?

Let's say we have direction, direction_north, direction_south, direction_north:route, direction_north:symbol in the autocompletion list.
When you are typing dir the autocompletion choose the first value without "separator" (_,:). Then if you press a to-be-defined shortcut it "validates" the direction value and move you cursor to the key end. Next you can press _n to continue the autocompletion process, validate direction_north, press the key :r to get direction_north:route.
It's quite similar to a smarter ctrl+ right arrow shortcut.

[GerdP]

Replying to StephaneP:

It's quite similar to a smarter ctrl+ right arrow shortcut.

Yes. Up to now I found no place to configure the places where ctrl+right arrow or other keys like ctrl+backspace might be configured to stop also at "_" or maybe further characters, so using a special key sounds like a good alternative.

[GerdP]

Reg. the menu entries:

• I think the existing entry "Edit ignore list" should be changed to "Edit ignore filter" or maybe even "Edit ignore-tags filter"
• The search dialog should be called with a Filter argument so that its title is Filter instead of Search
• The new menu entry could then be "Edit stop-autocomplete filter" or "Edit tag key filter to stop autocompletion of values"

Instead of defining a filter with the rather complex search dialog we may also just maintain an exclude list containing the plain keys.
This would allow a dynamic mena entry which could be either "Disable value autocompletion for {0}" or "Enable value autocompletion for {0}" with {0} being the tag key. Or are two menu entries with Enable.../Disable... better where only one is enabled?
We would loose the ability to use regular expressions and other special options but many of them simply don't work since the filter is applied to a fake OSM object.

[GerdP]

Hack: if CTRL+< is pressed in autocompletion field suggest the next matching entry in alphabetical order

[GerdP]

24516-ac-to-shortest-wip.patch implements the "validate" action, but I'd prefer to make the shortcut configurable. No good idea yet. Maybe implement an action with the shortcut which actually does nothing but allows to configure the shortcut and then check if the keyevent matches that of the action?

[GerdP]

The last patch doesn't handle the problem with the underscore _. I'll try a different approach which might even be simpler: If the unpatched code suggests a too long string, action "validate" could simply cut before the first occurence of e.g. [_:;,].