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.

[Don-vip]

I see this ticket has a very long history and I don't know all the details. Can you describe more precisely what your problem is ? I have no problem right now with single-digit values.

[skyper]

Replying to Don-vip:

I see this ticket has a very long history and I don't know all the details. Can you describe more precisely what your problem is ? I have no problem right now with single-digit values.

I have exactly the same behaviour than before r4141.

The single digit is not selected when changing from key to value with TAB and this leads to that it is not deleted when you start typing but you start typing after it.

[Don-vip]

I don't have this problem:

Last Changed Rev: 5515

Identification: JOSM/1.5 (5515 fr)
Memory Usage: 38 MB / 247 MB (13 MB allocated, but free)
Java version: 1.7.0_07, Oracle Corporation, Java HotSpot(TM) Client VM
Operating system: Windows 7

What is your system info ? including the look-and-feel.

[skyper]

I can 100% reproduce with openjdk6 and 7 both icedteaed with fresh preference dir (metal look-and-feel) on debian wheezy with Gnome3:

1. add tag layer=1 to an object
2. select different object without layer-tag.
3. try to add tag with different key and tag
4. change key and switch to value field using "TAB"

Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2012-09-26 01:31:28
Last Changed Author: bastiK
Revision: 5518
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2012-09-25 20:25:37 +0200 (Tue, 25 Sep 2012)
Last Changed Rev: 5518

Identification: JOSM/1.5 (5518 de)
Memory Usage: 102 MB / 592 MB (11 MB allocated, but free)
Java version: 1.7.0_03, Oracle Corporation, OpenJDK 64-Bit Server VM
Operating system: Linux
Dataset consistency test: No problems found

java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.4) (6b24-1.11.4-3)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)

java version "1.7.0_03"
OpenJDK Runtime Environment (IcedTea7 2.1.2) (7u3-2.1.2-2)
OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode)

I also tried it with java6 (version 1.6.0_18) on a debian squeeze with LXDE and it is the same.

Gonna try it without icedtea and on i386 when I find the time.

[skyper]

Replying to skyper:

Gonna try it without icedtea and on i386 when I find the time.

Openjdk is directly build with IcedTea in Debian and Oracle is not included as openjdk-7 is considered as root version.

Is there anyone, who is facing the same problem ? Dirk did simply stop prefilling single digits 18 month ago and I wonder if it was only me who ever had and now has again this problem.

There are quite some common tags like layer=, level=, lanes=, *levels=, tracks= with single digit numbers as values.

[skyper]

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