| Age | Commit message (Collapse) | Author |
|
|
|
Commenting this out instead of removing it for the moment while I add
test cases in case I need to keep debugging.
|
|
Turns out the backward increment/decrement didn't work in all cases. I
hadn't tested a multi-digit number in the second position from the left.
That didn't work with the old code. Adjust it and simplify it. Didn't
need to be so complicated. Now we set the start position to the $-[0] of
the previous match if the current match is to the right of point.
|
|
A new subrouting argument that defines by how much the number should be
incremented, or decremented if a negative step value is given.
Add a few new tests to verify the decrementing behaviour. The final test
where point is in the middle of the number fails.
|
|
|
|
|
|
Set up the proper condition to get the start index of the number just
before point.
|
|
|
|
Update the condition that increments the last number if the point is at
the end.
|
|
Doesn't work for middle numbers yet.
|
|
|
|
Still a bunch of old code to clean up, but this is a lot shorter than
what I had before, and I think it will be easier to extend it for
backwards searching.
|
|
This updated loop gets the start position of the appropriate number
nearest to point. It currently only works left to right, but seems like
it should be easy enough to extend to be right to left.
|
|
Not what I was thinking when I wrote that looping code.
|
|
Set `pos()` to enable us to increment a number in the middle of a
string.
|
|
Looking into a different algorithm for incrementing matches that's
easier to use in both forward and backward contexts.
Got a few ideas to get a match nearest to the cursor position. We could
then take that value and increment it, and replace the original
substring with the new incremented value.
|
|
|
|
|
|
Here, we really just want to exit the loop. There's no reason to change
`$point_position`.
|
|
Turns out this wasn't needed.
|
|
We were previously using values specific to the first and second numbers
in the line. Get middle-of-number point handling working for the third
number in the line, and hopefully the rest as well.
|
|
Test fails. Increments the second number instead of the third.
|
|
Remove work-in-progress, debug code, and things that didn't work out.
|
|
Previously, we correctly incremented the first number if point was in
the middle of that number, but we did not do so for subsequent numbers.
This change adds similar handling for all numbers in the line.
Got a little lost here trying different loops and changes. I kind of
hacked it without heavily planning the algorithm ahead of time.
The idea is that if the point position is beyond the right side of the
match, we cut off the part of the line from the start to the end of the
last match, then try matching again. This allows us to pull out the
number around point so that we can increment it with the evaluated regex
that follows the loop.
|
|
Previously, we only handled incrementing when point was in the middle of
the number if the number was the first on the line.
This is code from last week or so. Wasn't really analysing it. Don't
remember entirely. Currently, it loops infinitely on the fifth test.
|
|
Currently, the 'cursor within number' handling only works when the
cursor is inside the first number. It needs to work for any number in
the line.
|
|
|
|
* Needed the comparison to be `<`, otherwise the cursor becomes part of
the first number.
* The boolean operation was wrong: `$point_position` needs to be both
above the start of the match and below the end of the match to be
inside it.
|
|
Correctly increment a number when the cursor is, for example, at:
test 12 0
^
This causes the #5 test incrementing the second number to fail.
|
|
Add a failing test for incrementing a number when the cursor is at:
test 19 0
^
This currently results in:
test 110 0
which is incorrect.
|
|
This will increment the next number to the right of the given cursor
position.
|
|
Substrings and direction.
|
|
This allows us to more easily test the functionality and add new
behaviours.
|
|
Got it working! Thanks to the Fzf Bash code for showing me that you can
assign to `READLINE_LINE` and `READLINE_POINT`:
https://github.com/junegunn/fzf/blob/7191ebb615f5d6ebbf51d598d8ec853a65e2274d/shell/key-bindings.bash
|
|
Thinking I might be able to echo the whole line to the command line
instead of working out how to replace just the number that we've
incremented.
Discovered how to increment a number in a regex substitution from this
Stack Overflow answer by Mark Setchell
(https://stackoverflow.com/users/2836621/mark-setchell):
https://stackoverflow.com/questions/54367360/how-to-increment-the-last-number-in-a-string-bash/54367784#54367784
|
|
If we have access to the full command line and modify the number in it,
we can print the whole thing with the number incremented onto the
working command line.
Probably going to need some Perl to do the regex and incrementing.
|
|
A long time ago, I was trying to get this to work, but wasn't able to.
Commit the code from then.
Not really sure exactly what that was about now.
|
|
Want something similar to <C-a> and <C-x> in Vim. This function matches
and increments the number, but I'm currently stymied on how to insert
the number into the current line. There doesn't appear to be a way to do
that, except perhaps with the `shell-expand-line` function, and I don't
want to use that because I just want to insert the number, not expand
other parts of the shell line.
The other sticking point is how to read the value of the
`universal-argument`. There doesn't currently seem to be a way to do
that in a custom function.
I had a new idea for the number insertion problem, though. It's possible
I could replace the number, <C-c> the line, and reinsert a new copy with
the incremented/decremented number on the new shell line. That still
wouldn't resolve the `universal-argument` problem.
|