Hi there,

Frequently I want to use the `:open-link` command, but the email has a dozen
links that all look vaguely similar, and I want to just search for the unique
bit (usually 'unsubscribe'), but the command palette matching seems to be
prefix-based, which isn't useful in this context.

I'm planning on adding this functionality, and wanted to double-check others
would find it useful, as well as ask a few other questions:

- Should this be only for `:open-link`, for all command arg completion, or
configurable?
- Do folks care about the algorithm?

For an unrelated (and unfortunately not OSS yet) project, I recently implemented
a simple (~10 line) command palette fuzzy match that feels pretty intuitive,
basically just scoring each option based on the proximity of characters in a
substring search.

Brandon

> Frequently I want to use the `:open-link` command, but the email has a 
> dozen
> links that all look vaguely similar, and I want to just search for the unique
> bit (usually 'unsubscribe'), but the command palette matching seems to be
> prefix-based, which isn't useful in this context.

For this I simply map C-l to use urlscan[0] instead of the default 
:open-link functionality. It is easy to decide which link to click based 
on where the link is assigned in the email. For me this has always been 
easier to track for emails with a ton of links that are all basically 
the same, just a few characters off to determine which link was clicked.

> - Should this be only for `:open-link`, for all command arg 
> completion, or configurable?

Quite a few of the commands now have arg auto-complete but I think it 
would be useful for any that may not yet have it and it makes sense.

Peter

[0]: https://github.com/firecat53/urlscan

Hi Brandon,

On Tue Sep 3, 2024 at 9:16 PM EDT, Brandon Sprague wrote:
> Frequently I want to use the `:open-link` command, but the email has a dozen
> links that all look vaguely similar, and I want to just search for the unique
> bit (usually 'unsubscribe'), but the command palette matching seems to be
> prefix-based, which isn't useful in this context.

Are you aware of the :unsubscribe command? Often it will find the
unsubscribe link in the headers and prevent the need to comb through the
URLs yourself.

I do think fuzzy search would be useful as well, probably for all commands and
with a configuration option enabling/disabling it.

Jason

On 04/09/2024, 17:07, Jason Cox wrote:
> I do think fuzzy search would be useful as well, probably for all commands and with a configuration option enabling/disabling it.

We do have [ui].fuzzy-complete in the config, doesn't that work for you? Admittely, the algorithm is quite rudimentary and could be improved, though...

Thanks for all the tips! Between `[ui].fuzzy-complete` and `:unsubscribe`, seems
like I should have everything I need for now.


On Wed Sep 4, 2024 at 8:12 AM PDT, inwit wrote:
> We do have [ui].fuzzy-complete in the config, doesn't that work for you?

Not sure how I missed this option, it's pretty much exactly what I want. So far,
the algorithm has been fine, but I'll try tweaking it if I find examples where I
think it works poorly.


On Wed Sep 4, 2024 at 5:29 AM PDT, Peter Sanchez wrote:
> For this I simply map C-l to use urlscan[0] instead of the default 
> :open-link functionality.

I hadn't come across urlscan before, thanks for the tip!


On Wed Sep 4, 2024 at 8:07 AM PDT, Jason Cox wrote:
> Are you aware of the :unsubscribe command?

I wasn't before, that'll definitely work for that particular use case.

Brandon