cursor jumps to end of tag entry box after using tag completion / inserted tags eaten
Talk Bug Collectors
Join LibraryThing to post.
1ianreads
I wanted to bring up two related issues with tag entry that have been bugging me for a long while. I looked and searched and didn't see them discussed previously/recently.
The bugs are present when using a tag entry field: confirmed on the catalogue, edit your book, and add books.
What I'm trying to do: since tags on LibraryThing have a set order, I often want to add or edit a tag in the middle of some other tags. In this example, I'm trying to change the tag "some" to "some more". I position the cursor after some and type a little so the autocomplete selector shows up. I then select "some more".
What happens: the "some more" tag is inserted and the cursor jumps to the end of the tag entry field.
What I expect to happen: the tag is inserted and cursor is kept after the inserted tag, so I can manually or automatically insert another tag.
See this animated gif (externally hosted):
This ends the first "bug".
As I carefully sidestepped in the bug description above, the (current) "right" way to insert a tag is to put your cursor before a tag, type ", " (comma space), put the cursor two spaces back and start typing the wanted tag. But I've come to consider that a workaround for the following bug (but I get that some might disagree):
What I'm trying to do: insert a tag into a tag entry field. I position the cursor after a comma, but before the space that is followed by an existing tag. I type a space and start writing a tag. The autocomplete box shows up and I select the wanted tag.
What happens: the selected tag is inserted and the tag that was supposed to be following it, gets "eaten".
What might be reasonable to expect: since only the part before the cursor is being used as the input for the autocomplete function, when the selected tag is inserted, it should come with a delimiter (comma), so the tag next to it doesn't get eaten.
See here (externally hosted animated gif):
The bugs are present when using a tag entry field: confirmed on the catalogue, edit your book, and add books.
What I'm trying to do: since tags on LibraryThing have a set order, I often want to add or edit a tag in the middle of some other tags. In this example, I'm trying to change the tag "some" to "some more". I position the cursor after some and type a little so the autocomplete selector shows up. I then select "some more".
What happens: the "some more" tag is inserted and the cursor jumps to the end of the tag entry field.
What I expect to happen: the tag is inserted and cursor is kept after the inserted tag, so I can manually or automatically insert another tag.
See this animated gif (externally hosted):
This ends the first "bug".
As I carefully sidestepped in the bug description above, the (current) "right" way to insert a tag is to put your cursor before a tag, type ", " (comma space), put the cursor two spaces back and start typing the wanted tag. But I've come to consider that a workaround for the following bug (but I get that some might disagree):
What I'm trying to do: insert a tag into a tag entry field. I position the cursor after a comma, but before the space that is followed by an existing tag. I type a space and start writing a tag. The autocomplete box shows up and I select the wanted tag.
What happens: the selected tag is inserted and the tag that was supposed to be following it, gets "eaten".
What might be reasonable to expect: since only the part before the cursor is being used as the input for the autocomplete function, when the selected tag is inserted, it should come with a delimiter (comma), so the tag next to it doesn't get eaten.
See here (externally hosted animated gif):
2norabelle414
Regarding the second bug,
Because there is no comma between the first part of the tag you are inserting (e.g. "shor") and the next tag (e.g. "random"), the autocompleter doesn't have any way to know that those are intended to be two separate tags. Instead of your workaround of adding a space and a comma and backing up two characters, you can start a new tag before the comma of the previous tag, adding another comma and space, so that the comma stays between "shor" and "random" the whole time.
here, are, some more|, random, tags
here, are, some more,|, random, tags
here, are, some more, |, random, tags
here, are, some more, s|, random, tags
here, are, some more, sh|, random, tags
here, are, some more, sho|, random, tags
here, are, some more, shor|, random, tags
Because there is no comma between the first part of the tag you are inserting (e.g. "shor") and the next tag (e.g. "random"), the autocompleter doesn't have any way to know that those are intended to be two separate tags. Instead of your workaround of adding a space and a comma and backing up two characters, you can start a new tag before the comma of the previous tag, adding another comma and space, so that the comma stays between "shor" and "random" the whole time.
here, are, some more|, random, tags
here, are, some more,|, random, tags
here, are, some more, |, random, tags
here, are, some more, s|, random, tags
here, are, some more, sh|, random, tags
here, are, some more, sho|, random, tags
here, are, some more, shor|, random, tags
3SandraArdnas
I think both of those are by design, rather than a bug. Yes, inserting a tag by auto-complete in the middle is somewhat clunky, which I suspect is why afterwards the cursor jumps to the end (by design). Not sure what you mean by 'tags on LibraryThing have a set order'. AFAIK, the only thing that matters as far as LT functionality is concerned is the first one if you want to sort by tags. I enter mine in a certain order because it is meaningful to me, but apart from the first one LT doesn't care one way or the other to the best of my knowledge.
4kristilabrie
I don't think these are bugs, but I'll double check.
5ianreads
>4 kristilabrie: I knew calling these bugs might've been a little controversial; and I agree... But they are fixable, IMO.
>2 norabelle414: Actually, the autocompleter does have all the necessary information to potentially implement this. The logic would go something like this. Take the text before the cursor as input to the completion algorithm (as it currently does) and suggest a tag. Then, when a tag is selected, check if the text following the cursor corresponds to a current tag of the book (pre-edit). If so, insert/keep the existing tag following the new tag.
>3 SandraArdnas: With "a set order" I mean that, while almost all tag implementations out there jumble tags together in a proverbial bag, LibraryThing also keeps the tags as a string that can be sorted and which keeps some formatting. So you can order tags any way you want, and it even remembers how many (zero to n) spaces you've used to separate them. I like these features, but they're really rare compared to other software/websites.
>2 norabelle414: Actually, the autocompleter does have all the necessary information to potentially implement this. The logic would go something like this. Take the text before the cursor as input to the completion algorithm (as it currently does) and suggest a tag. Then, when a tag is selected, check if the text following the cursor corresponds to a current tag of the book (pre-edit). If so, insert/keep the existing tag following the new tag.
>3 SandraArdnas: With "a set order" I mean that, while almost all tag implementations out there jumble tags together in a proverbial bag, LibraryThing also keeps the tags as a string that can be sorted and which keeps some formatting. So you can order tags any way you want, and it even remembers how many (zero to n) spaces you've used to separate them. I like these features, but they're really rare compared to other software/websites.
6kristilabrie
Yeah, closing this as not a bug but please feel free to request this in the RSI Group!
