aerojump.nvim icon indicating copy to clipboard operation
aerojump.nvim copied to clipboard

Request: Have custom Aerojump mode to only match in the current screen

Open resolritter opened this issue 6 years ago • 3 comments

Description

aerojump.nvim (Default Mode) will prioritize matches forward regardless of if they are in the screen. This is an issue for me as I'll describe below.

Suggestion

I'd like to limit the amount of lines searched to only the current screen. I've tried to take a look at the source code to do this myself, but couldn't figure out how you're getting the constructor parameters for the Aerojump class.

Issues

Previously, I've considered making a strict backwards-matching version of the command (similar to how you have / for forward search and ? for backwards search). However, I found from my usage that most of the time I am able to narrow down backwards matches enough that I land on the right line without having to need a second command. i.e.

unique sentence backwards
<<-- CURSOR HERE
unique word forward

In the above case, I want to jump backwards. I could type unique and notice it's matching forward, but then I type sentence (which doesn't match forward) and I'm able to land in a previous line without having to think of setting up the direction from the start, which feels great.

The use case where this doesn't work well is when you have a match forward outside of the buffer's view. Here's a quick example of a buffer with a lot of "token" words I'd want to match

image

However, unknown to me, there's another "token" word outside of the buffer view forward. When I start AerojumpDefault, the screen will jump completely out of my starting position, which means I am not able to filter my "tokens[1-5]" visually anymore.

image

For my use case, I'd like to have a command which only filters in the current screen. Is that acceptable to you?

resolritter avatar Nov 09 '19 07:11 resolritter

Hi, this is the behavior that I wanted to have from the beginning due to the possibility of opening very large files. However it seemed to be fast enough at least for my needs even when opening large files. I can take a look at this over the weekend, you done want the cursor to jump 'off' the screen right?

ripxorip avatar Nov 22 '19 09:11 ripxorip

@ripxorip That is right. I only want to be able to jump to what I can see in the screen from the starting position. I think slicing the current view out of the buffer's lines is more efficient and can help to solve this issue too (i.e. line("w0") for the line at the top and line("w$") for the one at the bottom).

resolritter avatar Nov 22 '19 16:11 resolritter

Yeah, I will try to come up with something, I too can see the use case.

ripxorip avatar Nov 22 '19 17:11 ripxorip