cursorless icon indicating copy to clipboard operation
cursorless copied to clipboard

Add setting to modify row (line) number modulo

Open erhoppe opened this issue 3 years ago • 8 comments

When working on larger documents with many folded sections, I often encounter conflicts when attempting to select lines by row number. I would like to have a setting to be able to choose whether I want to select by the tens+ones or hundreds+tens+ones places or to use the absolute number. Perhaps just entering the modulo (e.g. default is 100, could make 1000 or leave blank for absolute) would work?

Another possible solution Andreas mentioned was to take the closest match in a conflict, which would be another nice setting to have generally.

erhoppe avatar Aug 06 '22 09:08 erhoppe

hundreds+tens+ones only is a bit tough since there is no number capture matching that in talon/knausj. We do have <number_small> that goes up to 99 and is what we use for modulo 100 row numbers and <number> that goes up to the trillions. It would be really easy for me to add absolute line numbers using the <number> capture. Would that suffice?

AndreasArvidsson avatar Aug 06 '22 10:08 AndreasArvidsson

Oh, I see. That is a difficulty. should be fine. It is too bad there's no <number_smallish>, though. Haha.

erhoppe avatar Aug 08 '22 20:08 erhoppe

It would be really easy for me to add absolute line numbers using the <number> capture. Would that suffice?

It would be useful too be able to use absolute line in cursorless now that it can be run inside of neovim. I've got terminals running that I often full screen on 2560x2880 monitors and even with a fairly big font, it's possible to cross over 100 rows. ATM it's not possible to reference a row by number if it happens to be a duplicate, and since there are no hats in neovim atm, it means you can't do anything on that line. @saidelike for awareness

I know this issue is only slightly related, but since @AndreasArvidsson you mentioned it would be trivial to do, I figured I just respond here rather than file a new issue. I can file any one if needed.

fidgetingbits avatar May 31 '24 05:05 fidgetingbits

It's not hard to add, but when I tested it it added more than one and a half second to the dfa compilation time which is beyond acceptable. Sorry to say this just isn't something that Talon can support at the moment. There are line number commands in community I suggest you use instead.

AndreasArvidsson avatar May 31 '24 07:05 AndreasArvidsson

Hrm brutal :| Line number commands from community doesn't really help though, as the point is to be able to issue cursorless commands on those rows.

What if we added (as suggested above) a new number capture in community that is say 1-1000? Then a separate higher resolution row command could target the last 3 digits, which would be more than enough to target rows with overlap?

fidgetingbits avatar May 31 '24 07:05 fidgetingbits

I don't really see which Cursorless actions are particularly beneficial when you can't actually see what you are targeting? Just navigate there using the community commands and then you can use Cursorless commands more efficiently?

A new number capture is an option but you still have the same problem. What if you have a file with more lines? Using modulo we can't reliably target lines outside of the viewport because we could not know which one you are talking about. We need absolute line numbers and for that we need a capture that could go to something like ten thousand, would probably be enough.

The problem is that I'm not sure even that has enough performance. In Cursorless we have rolled our own implementation of numbers small because the one in community was not performant enough.

Note that I am talking about absolute line numbers. Modular line numbers when you have more than a hundred lines I think it's a discussion we need to have separately. That capture might be able to work if we optimize it really thoroughly. The problem of course it is that it's still gonna increase compilation time and most people won't use it(or don't even have it in their older version of community) so it need to be hidden behind a tag.

AndreasArvidsson avatar May 31 '24 07:05 AndreasArvidsson

I don't really see which Cursorless actions are particularly beneficial when you can't actually see what you are targeting? Just navigate there using the community commands and then you can use Cursorless commands more efficiently?

There's lots. This has been my workflow for over 3 years with something other than cursorless that I had built, and the point of saidelike porting cursorless to neovim was to make it even more powerful. So for example, say I'm in the terminal at my $ prompt (so bottom of the window) and I'm building a command, and I want to some tokens from a line at > 100 rows away. Maybe I want 2nd paint and last paint, or a specific string, or the whole line. There are tons of possibilities that are very useful in practice.

I don't want to have to jump to the row, then issue cursorless commands and then go back to the original prompt line and paste them.

A new number capture is an option but you still have the same problem. What if you have a file with more lines? Using modulo we can't reliably target lines outside of the viewport because we could not know which one you are talking about. We need absolute line numbers and for that we need a capture that could go to something like ten thousand, would probably be enough.

That make sense.

The problem is that I'm not sure even that has enough performance. In Cursorless we have rolled our own implementation of numbers small because the one in community was not performant enough.

Note that I am talking about absolute line numbers. Modular line numbers when you have more than a hundred lines I think it's a discussion we need to have separately. That capture might be able to work if we optimize it really thoroughly. The problem of course it is that it's still gonna increase compilation time and most people won't use it(or don't even have it in their older version of community) so it need to be hidden behind a tag.

Right ya, I could easily get by with modular line no greater than 200. ATM my terminal with default width and full screen is 125 rows, if I zoom out to about the smallest I ever realistically go it's just over 150.

I can file a separate issue to discuss the modular line target if you want. Definitely don't need it to be absolute numbers. But anyway I agree, If it's noticeable performance impact since it's definitely an edge case most people wouldn't want, then everyone paying the compilation times is bad. Worst case I can limit my terminal window to < 100 rows until we get hats or something.

fidgetingbits avatar May 31 '24 08:05 fidgetingbits

I think we can probably track it in the same issue we just need to be very clear what we're actually talking about

I'm trying to capture my thoughts around the two different subjects here

  • [ ] A. Support absolute line numbers.
    This would be used when operating outside of the viewport. Since most of the Cursorless commands are not really that relevant when you can't see what you are targeting more exactly I feel that the community line commands probably would suffice for most people here?

  • [ ] B. Support module line numbers when your viewport is more than a hundred lines

    1. Change behavior to our existing modulo 100 implementation. Could just take the closest line to your current selection? Take the first line? Take multiple lines or use ordinals to decide?
    2. Add a larger number capture to support modulo 1000. We could always use this capture and support speaking two or three digits? We could add a new spoken form for this new modulo? If this number capsule lives in cursorless there isn't really a large problem, but if we need to support legacy community versions without it it becomes a bit more finicky.

I think the first thing we need to decide is if we want one or two? This would probably be beneficial to talk about in a Cursorless meetup?

AndreasArvidsson avatar May 31 '24 08:05 AndreasArvidsson