add tag: problem with number as values(WAS: values is always the last added (even if the key is changed))

[skyper]

The new autocompletion produces strange or even nonsense key/value combinations, because the value is not adjusted to the key. Is always the last added one.

Please, use a valid, used combination as autocompleting.

r4115

[stoecker]

Please describe a lot better what your problem is. The change was to initialize add with the last key/value and it also does this here. values and keys aren't handled independently.

[skyper]

Replying to stoecker:

values and keys aren't handled independently.

That is the problem.

I tag for example addr:housenumber=23. Next I want to add a name=*. The value stays at 23 all the time. I get a combination offered which is not in presets nor in a data layer.

Please, delete the value if the key is changed or offer a used combination.

[stoecker]

This is the normal behaviour of the edit dialog. That's why the whole field is selected when entering edit, so the first key press deletes/overwrites the entry. You do not need to do any additional keypress to the way it was before.

[skyper]

Replying to stoecker:

This is the normal behaviour of the edit dialog. That's why the whole field is selected when entering edit, so the first key press deletes/overwrites the entry. You do not need to do any additional keypress to the way it was before.

But it leads to more often invalid combinations as before there where only used or valid (presets) combination offered.

Would be nice if the values would be treated independently, or if only previous used combinations would be shown, but this might not be possible (easy).

[stoecker]

This would mean the add and edit dialog would work differently which is not really a good thing. People using the add dialog and not the presets need to know what they are doing. If it is so easy to forget to enter a complete key/value pair, then these people should not use that dialog at all.

[skyper]

I found the misbehaviour I was annoyed about.

If value is a number it is not selected and therefor not deleted if a key is pressed.

[stoecker]

In [4132/josm]:

fix #6430 - fix autocompletion for numbers

[stoecker]

Ticket #6453 has been marked as a duplicate of this ticket.

[Zverikk]

This behaviour is very annoying and useless. When editing, I have always to stop and think, what is that value, how does it correspond to the tag I've just entered, is it selected so I can type safely etc. It is not selected when the caret is in the first text box, so it is not obvious. And it must be even more confusing for novices. I vote for removal of this feature, or making it optional with default state of disabled.

[stoecker]

This is the standard behaviour of the edit dialog for at least 3 years now and also it is the standard of all prefilled dialogs in other software. The only change to the past is that add is now handled as an edit as well. You don't need an single additional keypress or mouse-click to use the dialog and to think about what you enter should be required in any case.

The reason why the value is not cleared/changed/whatever when the key changes is also obvious - It must be possible to edit wrong key entries without destroying the value.

And there are also use cases, where same values are helpful (e.g. adding name and name:<lang> or adding a lot of nearly similar named objects).

I wont revert a feature if there are no real disadvantages, but only "I don't like this change".

[bilbo]

This is the standard behaviour of the edit dialog for at least 3 years now

No. This behavior was added recently in r4109 - before if you pressed "add key" you started with empty dialog.
Now last used values are prefilled. While it is often useful, sometimes (if you want to use different key) you end up with pre-filled value you don't want.

[stoecker]

No. This behavior was added recently

If you had not stripped the second sentence, then your quoting would have been correct and your answer thus maybe also.

[skyper]

Replying to stoecker:

In [4132/josm]:

fix #6430 - fix autocompletion for numbers

Not yet. Single digit numbers are not highlighted and the cursor is at the end.

r4135

[stoecker]

Autocomplete is such a tricky system, when I try to fix that single letter issue, then I probably again will bring up another bunch of errors more serious.

[skyper]

Replying to stoecker:

Autocomplete is such a tricky system, when I try to fix that single letter issue, then I probably again will bring up another bunch of errors more serious.

Then maybe exclude (single digit) number from history. I remember that number had also been a previous problem and the solution was to stop autocompletion for numbers.

Thanks

[stoecker]

In [4141/josm]:

fix #6430 - don't prefill single characters

[skyper]

Replying to stoecker:

In [4141/josm]:

fix #6430 - don't prefill single characters

It is back again. Probably r5479 or r5484 brought it back. Did not remember the reason for special treatment of single characters right away when reading the commit lines but here it is.