Add location nicknames
JacobEvelyn opened this issue · comments
Commands and behavior should be pretty much the same as friend nicknames. Would be really useful, especially with multiword locations (New York City could be nicknamed as NYC) and "duplicate" nicknames (Portland, OR and Portland, ME).
@JacobEvelyn I'd like to work on this issue and raise a PR for this soon
Perfect, @v4vasanth ! Let me know how I can best assist you!
@v4vasanth anything I can do to help?
@v4vasanth are you still interested in this or should I assign it to someone else?
Hi i would like to work on this.
Additional to that i found a small missing documentation in the friends help remove. It only mentions (in the name description) the remove of nicknames. But when you simply call friends remove it also mentions tags. Should i put that in another PR or only make a separated commit?
Thanks, @RenCloud! I’ll assign this issue to you.
And I think having another PR to fix the documentation would work best for me.
Thank for picking these up, and please let me know if there’s anything I can do to help!
Okay, great.
I have started the implementation, but I have some open questions.
The first question is how to name the command. Currently I'm adding two new commands: friends add location_nickname and friends remove location_nickname, but I'm not sure if location_nickname fits to the other commands.
Additionally I have a question about the method highlight_location. For highlight_friends a 5-step algorithm is used to find the right friend. Based on the old code I currently map only direct matches ( e.g. a location New York City a.k.a. NYC will match New York City also with more spaces or NYC). I'm not sure if the algorithm is needed for the location, so I wanted to ask that.
While writing I thought about your request/idea with the duplicate. The current system does not allow duplicate names or locations, but it does for nicknames. (After that the matching might not be as correct, but it works.)
Therefore, it is currently not possible to add two locations with the name Portland. With nicknames you could distinguish between them, but then you would have to ask for the nickname while adding a new place that exists twice, and the place than would only matched by the nickname. Therefore I am not quite sure how you have imagined it.
Maybe I'm missing something at friends nicknames, but that's my understanding of it.
Hey @RenCloud! So glad to hear you've started working on this and thanks for the great questions!
The first question is how to name the command. Currently I'm adding two new commands:
friends add location_nicknameandfriends remove location_nickname, but I'm not sure iflocation_nicknamefits to the other commands.
This is a great question, and one I hadn't actually thought deeply about. In the past I've tended to use nested commands (such as multiple friends add subcommands) over one multiword command (such as friends add_nickname). The problem here is I think the most natural would be friends add friend nickname or friends add location nickname but then that leaves us with no way to just add friend or add location. I can think of a few options:
friends add location_nicknameas you've done.friends add nickname friendandfriends add nickname location- this reads kind of awkwardly
friends add alternate friend nameandfriends add alternate location name- this is a lot to type!
friends add aliasfor locations andfriends add nicknamefor people- perhaps a bit confusing but nice and simple
Of these I'm leaning toward either 1 or 4. What do you think?
Additionally I have a question about the method
highlight_location. I'm not sure if the algorithm is needed for the location, so I wanted to ask that.
Great question! While it's possible we'd want that someday, I think for now just matching only direct matches as you've done is perfect. The complex five-step algorithm is really just to handle the ambiguities of many people sharing the same name, which I think is infrequent enough for locations that we can ignore for now.
With nicknames you could distinguish between them, but then you would have to ask for the nickname while adding a new place that exists twice, and the place than would only matched by the nickname. Therefore I am not quite sure how you have imagined it.
Ha, honestly I don't remember what I was imagining here. I think the way you're approaching it is fine, and actually I would prefer to not have two locations with the same nickname either. With the Portland scenario I think nicknames would at least allow something like adding the Forest City as the nickname for Portland, ME and Stumptown for Portland, OR to make it easier to add activities in one or the other. Does that make sense?
I'm glad to help. friends is a nice tool.
Of these I'm leaning toward either 1 or 4. What do you think?
I also think that option 2 and 3 are not so great. Especially because they add another layer to the command, making it very long.
For the sake of simplicity I think the 4th option is better. It's not quite as descriptive, but it fits better with the other one. The combination of 2 words with underscore does not fit the simple call of the other commands.
Great question! While it's possible we'd want that someday, I think for now just matching only direct matches as you've done is perfect. The complex five-step algorithm is really just to handle the ambiguities of many people sharing the same name, which I think is infrequent enough for locations that we can ignore for now.
That was what I thought. Besides helping to find the right location, supporting nested locations is probably the better choice.
Ha, honestly I don't remember what I was imagining here. I think the way you're approaching it is fine, and actually I would prefer to not have two locations with the same nickname either. With the Portland scenario I think nicknames would at least allow something like adding
the Forest Cityas the nickname forPortland, MEandStumptownforPortland, ORto make it easier to add activities in one or the other. Does that make sense?
If I understood correctly that you are currently entering the two Portland's as Portlant, ME and Portlant, OR, then I had misinterpreted this at first. I thought you wanted to add two times Portland with nicknames either ME or OR.
But in this case, that doesn't account for the problem I had in mind.
actually I would prefer to not have two locations with the same nickname either.
I thought so too. But at the moment I have added it very similar to the 'friend nickname', and there it is possible. However, I will not allow it for place names then.
For the sake of simplicity I think the 4th option is better.
Cool, friends add alias it is!
Besides helping to find the right location, supporting nested locations is probably the better choice.
Completely agree! Looking forward to when #246 is done! 😄
If I understood correctly that you are currently entering the two
Portland's asPortland, MEandPortland, OR, then I had misinterpreted this at first.
Ah yes, I wasn't clear—sorry! I was imagining this as the locations were named Portland, ME and Portland, OR and then you could add clarifying aliases to either.
But at the moment I have added it very similar to the 'friend nickname', and there it is possible. However, I will not allow it for place names then.
Yeah it's definitely a bit confusing, but I think it's okay for friends to share the same nickname because of that five-step algorithm for deciding which friend is being referenced. (Just as I might have three friends named "Jacob," they might all also go by "Jake.") But for locations since we're just doing a strict match I think it'll be confusing to allow duplicates for now.
Thanks so much for working on this and let me know if you have any questions! ❤️
Thanks so much for all the hard work here, @RenCloud! I've just merged this and released it in v0.54. You can get it with friends update.
Congratulations on becoming an official contributor, and I'd love to have you contribute again in the future!