Modified consult-line-start-from-top behaviour

[craig981]

I run consult-line, and let's say the string I'm searching for is on the line that the point is currently on. There are many lines above and below which also match that string. I'm also using vertico.

With consult-line-start-from-top at nil the buffer does not scroll or move (this is good) because the match found on the current line is listed at the top of the candidate list in the minibuffer. However, the matches are out of line number order, split into two groups with all the matches after the current line listed first, followed by the matches above the current line after it, with the line numbers in a different colour. I can't fathom how this makes sense, or why it was done. It fries my brain. I'd expect to always see the matches in line number order.

With consult-line-start-from-top at t, the matches are in the correct line number order, however now the view of the buffer has jumped up to the first match, miles away from the line I started on. This is also undesirable.

It would be useful to have an option to keep the matches in line number order (like the t setting), but not jump away from the match that was on the line I started on (like the nil setting). This is what helm-occur does, and I find it a deal-breaker for replacing helm with consult-line.

Thanks

[minad]

This has been requested many times. Please search the issue tracker.