Support one-step request for a search term with multiple results

[za419]

The original intent of the one-step request feature was to supplement the existing functionality for request (first perform a search, then request the nth song) with the ability to request right away if a user knew exactly what they wanted (Cadence request only my railgun)

For this flow, the current behavior is perfectly suitable: If a search returns multiple results, the user is not requesting a single song, and so they are presented with the set of options and are instructed to select one.

However, this is slightly defective for a workflow where a user is familiar enough to know what the options will be (which is admittedly niche), or when a user isn't particular about the specifics of a song and is willing to obey Cadence's relevance sorting (Which is currently characterized as "How much text needs to change to make this match perfect"). For example, now that there are two versions of "only my railgun", it is difficult or impossible to one-step request the original version (which has a shorter name).

Therefore, provide a command syntax by which one can perform a true one-step request, with support to index into the results.

This can extend the existing request command even further, with some syntax like Cadence request only my railgun #1 and some complicated logic to separate a request for only my railgun #1 and "only my railgun, result 1". This can probably have it's parsing format controlled by config, reusing the mechanism in place for custom commands.

Alternatively, this could use a new command entirely: Cadence request-item only my railgun 1 - Since this can expect the last term to always be an index, it could simply grab that last group, attempt to parse it as an integer, and use that - With correct error generation and typechecking. This is probably preferable.

It would also be possible to implement both, and allow either. In this case, each syntax should be enabled/disabled by config - Even if the whole feature doesn't end up gated behind a feature flag.

This would merit incrementing a minor version.

[kenellorando]

If you're asking for my preference, I would prefer just appending the index number to the end of a request. Adding another command I feel adds unnecessary complexity.

But I have to play devils advocate and ask: are you expecting people to memorize songs' index numbers? Also, my problem with this is that a song's index is not an inherent property of the song itself. I see a lot of variables (such as any update to the library (adding another similarly named song), changing song metadata, or changing any logic of Cadence's populator) that could potentially put the songs in different order on results.

[za419]

@kenellorando

I agree that appending the index number to request is the most user-friendly thing to do... When it works. The problem is that if it isn't a separate command there needs to be some balance between 'easy to trigger' and 'doesn't trigger inadvertently' - how do we tell when a suffixed index number should be part of the search term? That's the logic behind #n syntax, but even that has failures - There is no prohibition on '#' appearing in a search term.

So perhaps the only advantage of the extra command option is that it is "impossible" to trigger inadvertently - Since the user explicitly asked for this behavior, we know that we should treat the last part as an index, not as a search term, so we know we won't mishandle the user's request.

[za419]

Devil's advocate: You have an entirely valid point.

I do not intend for this to be the primary method behind requests - Hence why I'm more okay using an arcane command form (request-item), and why I'm tempted to fail if the user tries to use this when OSR is fine - I find value in discouraging this form for normal usage.

The song's index is very much not an inherent property of the song. It can change trivially if:

• The database changes (songs added or removed)
• The songs change (the metadata for this or some other song changing and affecting ranking)
• The server's code changes (sort order is altered, or we change the special search forms in a way that affects this search)
• CadenceBot changes (I reserve the right to alter OSR's narrowing filters and change the results between versions)

So the index is a very fluid thing - I can probably expect the index to stay the same if I want to request the same song I requested ten minutes ago, but as the interval stretches to days or weeks stability is less certain. History shows that on the interval of years, the server will be rewritten and the library recreated, almost certainly breaking the index.

Thus, this feature is very bad for "I just thought of November Rain, I'm going to request that". It has two use-cases.

1. I'm very flexible on what song I want (I want to select the first result for "anime songs", and I'm going to accept the server's choice of ranking for what song it gives me, even though I've never even heard of 'Kono Yubi Tomare')
2. I've done this before, I know exactly what I'm going to get, and I'm power-user enough to know that stability is not a concern (I want to request the original 'only my railgun', and I'm doing it by saying Cadence request-item railgun 1, goddamit!) - This usually carries the implication of 'I know what's in the library and I understand how the server sorts results well enough that I know what's going to be returned', AKA 'I know Cadence well enough that I could script my usage'

2. is probably code for "My github username is @za419 or @kenellorando" here. Although it could also see use for more literally 'scripted' requests - For example, the election special I ran on November 3rd did include autorequests from CadenceBot, and it would probably have used this mechanism had it existed - That can be viewed as a point in favor of or against it of course (since autorequests should definitely not be a permanent feature)