[patch] 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.

[skyper]

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

[skyper]

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

[skyper]

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

[skyper]

1. screenshot

[skyper]

2. screenshot

[skyper]

Short summary:

1. start with new/empty preferences
2. draw two objects
3. select first object and add a tag with on single digit number as value (e.g. layer=1)
4. select second object and open the add "Add Value" dialog
   
5. press TAB
   

Note the cursor at the end and that the value is not selected.

Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2014-05-03 01:32:45
Last Changed Author: bastiK
Revision: 7054
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2014-05-03 01:07:19 +0200 (Sat, 03 May 2014)
Last Changed Rev: 7054

Identification: JOSM/1.5 (7054 en) Linux Debian GNU/Linux 7.5 (wheezy)
Memory Usage: 172 MB / 881 MB (71 MB allocated, but free)
Java version: 1.7.0_25, Oracle Corporation, OpenJDK 64-Bit Server VM
Java package: openjdk-7-jre:amd64-7u25-2.3.10-1~deb7u1
VM arguments: [-Djosm.home=/tmp/.josm]
Program arguments: [--language=en]
Dataset consistency test: No problems found

[Don-vip]

OK reproduced on Windows too, it happens with Metal, Nimbus and CDE/Motif, but not with Windows and Windows classic look and feels.

[mdk]

I think that the problem should be solved in a little bit more general manner.
Here is a related problem I often have:

1st I want to add "landuse=grass" to one object. So I type "lan" <TAB> "gra" <ENTER>.

2nd I want to add "natural=water" to an other object. So I type "nat" <TAB> "wat" <ENTER>. But I get "natural=grasswat".
The problem in this case is, that there is also a "natural=grassland" in the presets. After entering "natural" as key, "grass" is the valid beginning of a "natural" value. So the cursor is placed after "grass" and the existing text is not selected. But this is absolute not what I expect to get. So in daily editing, I have always to check, that I don't enter garbage. And you can't even predict where problems will occur, because this will depend on the existing key/value pairs in the currently loaded data.

A solution would be: If the key changes, always select the whole value.

You can find several wrong tags which are probably introduced by this unexpected behaviour of JOSM.
For the above example with old value "grass" (landuse=grass, surface=grass, ...) and new key "natural" you find in TagInfo "natural=grasswo", where obviously somebody wants to add natural=wood.

Btw: I use Ubuntu.

[dieterdreist]

I also believe there is a bug here, I have isolated it to one-digit numbers (more digits and negative numbers work, ie. they get preselected and overwritten if you type other text).

So actually it is working for numbers > 9 (i.e. more than one digit) and for negative numbers but it is not working for numbers from 0 to 9 (not only in layer but also in addr:housenumber and other keys).

This was pulled over from ​http://josm.openstreetmap.de/ticket/9973 like suggested by skyper

[richlv]

this does not seem to be related to numbers but to the string length - one character will result in this problem.
my scenario :
alt+a, building:levels=1
alt+a addr:housenumber=12

...arrrgh, it should have been 2.

(try it with a single letter, behaviour is the same)

given the age of this ticket, should this problem be handled in a new one ?

i don't want to annoy the developers, but i face this problem after every few tags as i'm mapping, so i'm cursing almost constantly :)

[Hojoe]

As I understand, if the cursor goes to the 'value' field, then should all characters be selected. Why not select all characters manually, if the focus goes to the 'value' field?

[Hojoe]

Selects all characters if the 'value' gets the focus.

[skyper]

Replying to Hojoe:

@ Hojoe:
Commenting or changing the ticket is enough to get informeed about ticket changes/comments, e.g. additional CC-ing is not needed and makes more traffic.

[mdk]

Can we schedule this patch for 14.12? The current behaviour is very annoying!

[Don-vip]

yep

[skyper]

Ping

[mdk]

I think the current title is not correct. As comment:31 pointed out: it has noting to do with number as value, but with length of value.
Old value "1" or "a" -> on entering next value the cursor is placed at the end of the old string.
Old value "12" or "ab" -> on entering next value the old value is selected and replaced on next key press.

And as I wrote in comment:29 there is a similar problem with longer values when changing the key.

[Don-vip]

In 7883/josm:

fix #6430 - add tag: selection problem with single-char values on some LaFs (patch by Hojoe)