interesting new tag creation behavior. what chars are allowed? for example if i put ? or ^ in it, it doesn't register. also what about another #?

[yassinya]

It currently doesn’t accept characters other than letters, numbers and spaces.

I think allowing a second “#” could make working with them and detecting a bit trickier. What do you think? @ezl

I think we should support underscores ”_” as well, what other characters should we allow?

[ezl]

hmmm... my gut feel is that this indicates an implementaiton smell with the tags.

if i reclal correctly, we are doing some sort of lenght counting feature where we are essentially just noting the start/end of a tag in characters in the to do text string, then using that for formatting.

(A) my gut feel is that it needs to be treated as a separate type of item so we aren't "counting" position like that.

one of the problems with this is that we couldn't for example, easily do this operation: change the text of a tag -- for example if we go to tag settings, change the tag text, then it automatically updates all tags where that tag occurs. It's not a common operation, but to do this we would have to filter for all items that contain this tag, then do a text replacement operation + change the JSON with the tag location specified.

this seems like a smell

(B) however, right now, i don't want to stop our progress to consider alternate implementations. BUT, one if the issues is that the USER isn't aware of what tag characters are valid. I think it's a valid UX pattern to say we ONLY accept certain characters, but then I think we need to be explicit about it.

I propose we:

1. define the character set (alphanumeric characters, space, underscore)
2. define the valid "action" keys (enter for saving, up/down for navigation, ESC to exit tag creation mode)
3. explicitly CATCH all characters that are OUT of that character set, and if those keys are pressed, fire a notification ("Oops, are you trying to create a tag with a '^' in it? Tags can only contain the following characters: A-Z,a-z,0-9, space, _") then discard keypresses that are not accepted for tags.

[yassinya]

You’re absolutely right @ezl , current implementation has few drawbacks which I unfortunately didn’t consider when I was working on it

Your proposal sounds good to me, let’s do it this way until we find another solution.

Meanwhile, I’ll do some brainstorming and figure out another flexible approach that will allow us to do these operations and still keep displaying the tags inside the body

[ezl]

@yassinya great job implementing this fix so quickly