consult-focus-lines highlighting just like consult-keep-lines does it

[geza-herman]

This is a little cosmetic suggestion: when using consult-keep-lines, during preview, consult nicely highlights the matching part of the lines, while consult-focus-lines doesn't.

(I tried to fix it by passing 'highlight to consult--completion-filter-dispatch (instead of nil), but it doesn't work.)

[minad]

This is not a good idea since it will make consult-focus-lines much less efficient and the lines won't be editable anymore. consult-focus-lines puts an overlay over the hidden lines only (thus no highlighting) while consult-keep-lines puts an overlay over everything replaces the entire buffer content.

[geza-herman]

But why isn't efficiency/editability a problem for consult-keep-lines? I'd expect that these two functions behave exactly the same way until the user presses RET at the "Focus on lines"/"Keep lines" prompt. After the "RET", the former hides unmatching lines, the latter deletes them.

[minad]

The behavior is simply a consequence of the natural implementation. It makes sense to offer both commands since they do different things and serve different purposes, but they are not supposed to behave the same.

consult-keep-lines is worse in both ways, it is less efficient due to the large overlay replacing the buffer content and huge string concatenation (replacing the displayed text of the whole buffer!), and the previewed buffer is also not editable. consult-focus-lines in contrast is more efficient since it only hides non-matching buffer content, with the downside that the matching buffer content is not highlighted.

So what I want to say, the current implementation is as good as it gets for both commands (each with its own upsides and downsides), but introducing highlighting will make consult-focus-lines worse in multiple ways. This would not simply be a minor cosmetic change.

[geza-herman]

Yeah, by minor cosmetic change, I just meant what the user perceives. Code-wise, it might be a larger change.

Consult could have a backend function (for both focus/keep function), which can do the preview step. It could have a boolean argument how to behave (highlight or not). After this backend function returns, it'd leave the buffer in a "marked state". And then consult-keep-lines and consult-focus-line would do their job on the marked lines (delete or hide). So it'd be easy to select between the two behaviors, because it would be just an argument to the backend function. I suppose consult already has the necessary code, it's just that this hypothetical backend function is not factored out.

(this approach also has the benefit that the behavior could depend on the size of the buffer: if the buffer is small, we can do the highlighting. If it is large, then use the more efficient solution.)

I may try to implement this refactoring if it is not very hard to do (if you're open to this idea).

[minad]

Hmm, I don't think this can be done, without changing the design completely. The point of consult-focus-lines and consult-keep-lines is that you can also jump out of the minibuffer to the buffer during filtering and copy text or perform edits on the fly. This would break if preview would be treated as a separate step - right now preview is the same operation as the final operation. (What I wrote before regarding consult-keep-lines using an overlay was not correct.)

[minad]

So I think your idea would work if we replace the entire buffer with an overlay which simply previews the end result, without actually changing the backing buffer. Only in the end consult-keep-lines would actually delete the lines and consult-focus-lines would create the overlays to hide text. But I doubt that this would be better than what we have right now, where we don't have a separate intermediate preview step. The way things are right now is by design, since the buffer directly reflects the final result and as such the buffer can always be interacted with as usual, even when jumping out of the minibuffer.

[geza-herman]

Yes, that's one option. Another one is to apply overlays to the buffer: make the non-matching lines 'invisible, and add highlight overlays for the matching parts. This way the buffer is still editable. I'm not sure how difficult to implement this. One thing for sure, it's not trivial, because filtering is done on a string list, and then we'd need to figure out how to apply the result of the filter to the buffer. consult--focus-lines-state already does the "making 'invisible" part, but it doesn't do the "apply highlight to the matching" part. For each string of the result of the filter, it should find the corresponding line in the buffer, and then apply the highlight properties of the string from the filter to the line. It is not trivial, if a function doesn't exist already to do this job (just replacing the string with the corresponding line doesn't work perfectly, because we may lose the original highlights of the line of the buffer).

[minad]

...add highlight overlays for the matching parts. This way the buffer is still editable.

Yes, this is another possibility, but an expensive one since one has to find out all the matching parts and create many overlays. As you say, it is is non-trivial. The problem is that the completion machinery uses text properties. Each completion styles does its own thing, which makes it hard and inefficient to implement a generic mechanism. consult-line does this for the current matching previewed line, but it is not great. For consult-focus-lines one would also make sure to only add overlays in the visible region.