Modify

Opened 7 years ago

Closed 3 years ago

#6430 closed defect (fixed)

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

Reported by: skyper Owned by: team
Priority: normal Milestone: 14.12
Component: Core Version: latest
Keywords: add key value number Cc: Don-vip, Hojoe

Description (last modified by 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

Attachments (3)

number_first.png (14.6 KB) - added by skyper 4 years ago.
1. screenshot
number_second.png (14.5 KB) - added by skyper 4 years ago.
2. screenshot
bug6430.patch (587 bytes) - added by Hojoe 3 years ago.
Selects all characters if the 'value' gets the focus.

Download all attachments as: .zip

Change History (43)

comment:1 Changed 7 years ago by stoecker

Owner: changed from team to skyper
Status: newneedinfo

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.

comment:2 in reply to:  1 Changed 7 years ago by skyper

Owner: changed from skyper to team
Status: needinfonew

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.

comment:3 Changed 7 years ago by stoecker

Resolution: wontfix
Status: newclosed

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.

comment:4 in reply to:  3 Changed 7 years ago by 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).

comment:5 Changed 7 years ago by 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.

comment:6 Changed 7 years ago by skyper

Keywords: number added
Resolution: wontfix
Status: closedreopened
Summary: add tag: values is always the last added (even if the key is changed)add tag: problem with number as values(WAS: values is always the last added (even if the key is changed))

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.

comment:7 Changed 7 years ago by stoecker

Resolution: fixed
Status: reopenedclosed

In [4132/josm]:

fix #6430 - fix autocompletion for numbers

comment:8 Changed 7 years ago by stoecker

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

comment:9 Changed 7 years ago by 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.

comment:10 Changed 7 years ago by 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".

comment:11 Changed 7 years ago by 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.

comment:12 Changed 7 years ago by 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.

comment:13 in reply to:  7 Changed 7 years ago by skyper

Resolution: fixed
Status: closedreopened

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

Last edited 7 years ago by skyper (previous) (diff)

comment:14 Changed 6 years ago by stoecker

Resolution: wontfix
Status: reopenedclosed

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.

comment:15 in reply to:  14 Changed 6 years ago by skyper

Resolution: wontfix
Status: closedreopened

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

comment:16 Changed 6 years ago by stoecker

Resolution: fixed
Status: reopenedclosed

In [4141/josm]:

fix #6430 - don't prefill single characters

comment:17 in reply to:  16 Changed 5 years ago by skyper

Cc: Don-vip added
Description: modified (diff)
Resolution: fixed
Status: closedreopened

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.

Last edited 5 years ago by skyper (previous) (diff)

comment:18 Changed 5 years ago by 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.

comment:19 in reply to:  18 Changed 5 years ago by 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.

comment:20 Changed 5 years ago by 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.

comment:21 Changed 5 years ago by 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.

comment:22 in reply to:  21 Changed 5 years ago by 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.

comment:23 Changed 5 years ago by skyper

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

comment:24 Changed 4 years ago by skyper

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

comment:25 Changed 4 years ago by skyper

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

comment:26 Changed 4 years ago by skyper

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

Changed 4 years ago by skyper

Attachment: number_first.png added
  1. screenshot

Changed 4 years ago by skyper

Attachment: number_second.png added
  1. screenshot

comment:27 Changed 4 years ago by 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
    1. screenshot
  5. press TAB
    2. screenshot

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
Last edited 4 years ago by skyper (previous) (diff)

comment:28 Changed 4 years ago by 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.

comment:29 Changed 4 years ago by 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.

Last edited 4 years ago by mdk (previous) (diff)

comment:30 Changed 4 years ago by 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

comment:31 Changed 3 years ago by 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 :)

comment:32 Changed 3 years ago by 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?

Changed 3 years ago by Hojoe

Attachment: bug6430.patch added

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

comment:33 Changed 3 years ago by Hojoe

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

comment:34 Changed 3 years ago by Hojoe

Cc: Hojoe added

comment:35 in reply to:  34 Changed 3 years ago by 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.

comment:36 Changed 3 years ago by mdk

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

comment:37 Changed 3 years ago by Don-vip

Milestone: 14.12

yep

comment:38 Changed 3 years ago by skyper

Ping

comment:39 Changed 3 years ago by 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.

comment:40 Changed 3 years ago by Don-vip

Resolution: fixed
Status: reopenedclosed

In 7883/josm:

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.