Closed 62832 closed 1 year ago
This seems intentional. It highlights the matching string which in this case (st) covers the entire item.
Should be fairly easy to address though, e.g. by simply not drawing the highlights if the item has been marked for output.
diff --git a/patch/highlight.c b/patch/highlight.c
index b5947b5..664a8b6 100644
--- a/patch/highlight.c
+++ b/patch/highlight.c
@@ -15,6 +15,14 @@ drawhighlights(struct item *item, int x, int y, int maxw)
char *itemtext = item->text;
#endif // EMOJI_HIGHLIGHT_PATCH | TSV_PATCH
+ #if MULTI_SELECTION_PATCH
+ if (issel(item->id))
+ return;
+ #else
+ if (item->out)
+ return;
+ #endif // MULTI_SELECTION_PATCH
+
drw_setscheme(drw, scheme[item == sel ? SchemeSelHighlight : SchemeNormHighlight]);
strcpy(tokens, text);
for (token = strtok(tokens, " "); token; token = strtok(NULL, " ")) {
Applies for the fuzzyhighlight patch as well.
Having given it a bit more thought I don't see how the highlighted parts of the match adds any relevant information to the table when the item anyway has been selected for output. I'll consider including the above.
Pushed the above, let me know if you experience any issues.
No issues here. Thanks a ton!
I just noticed that when the highlight patch is applied and a search is being made, any entries added to a multi-selection only use the colours defined in
SchemeNorm
rather than the colours defined inSchemeOut
. This also seems to happen irrespectively of the multi-selection patch.An example of an entry normally added to a multi-selection, currently in orange
Whereas here,
st
is another selected entry but does not also show in orange during searching.What might a potential fix for this look like or involve?