readline-incdec/t, branch v0.0.1 Readline bindings to increment and decrement numbers on the command line 100-increment-decrement: Want to return real start position from incdec 2021-08-28T20:14:17+00:00 Teddy Wing 2021-08-28T20:14:17+00:00 9be99793b2d7eb4cc28db4cfc615325055d3853f In order to set up point moving only when point is on or after the start position of the changed number, I want the second return value from `incdec()` to always give me the correct start position. Currently, it returns 0 as the start position when backwards is on and point is before the first number. It should return the start position of the first number. 
In order to set up point moving only when point is on or after the start
position of the changed number, I want the second return value from
`incdec()` to always give me the correct start position.

Currently, it returns 0 as the start position when backwards is on and
point is before the first number. It should return the start position of
the first number.
incdec.pm: Return both line and start position 2021-08-28T17:42:31+00:00 Teddy Wing 2021-08-28T17:42:31+00:00 729cdbe8c41598aaa70c7c71d708953dd72a6866 I want access to the start position of the number being operated on. This will allow me to determine if point should be moved or not. Refactor everything to accept an array from `incdec()`. 
I want access to the start position of the number being operated on.
This will allow me to determine if point should be moved or not.
Refactor everything to accept an array from `incdec()`.
incdec.pm: Fix an issue where first number wasn't incremented backwards 2021-08-28T16:25:23+00:00 Teddy Wing 2021-08-28T16:08:30+00:00 88cc7f664a2c582c4fb08a4c3f927da7863ce9fc When `$start_position` was 0 going backwards, the `sed` test command line failed to increment the first number in the line. Can't figure out exactly what was wrong, but there seemed to be a problem with using the `\G` assertion for that test case. Decided to remove `\G` when `$start_position` position is 0 to work around the problem. Not sure if there's a more concise solution to this that wouldn't require me to have two separate subtitution lines. Also simplified the substitution regular expression. It turns out I didn't need the first capture group, and it was incorrect in matching /[^-\d]*/ because we really wanted /(?!-?\d+)/, not either or of the characters in the group. Completely removing it still allows everything to work. Don't remember if I added that when I was still using the substringing algorithm, but whatever happens, it's not necessary now. 
When `$start_position` was 0 going backwards, the `sed` test command
line failed to increment the first number in the line.

Can't figure out exactly what was wrong, but there seemed to be a
problem with using the `\G` assertion for that test case. Decided to
remove `\G` when `$start_position` position is 0 to work around the
problem. Not sure if there's a more concise solution to this that
wouldn't require me to have two separate subtitution lines.

Also simplified the substitution regular expression. It turns out I
didn't need the first capture group, and it was incorrect in matching
/[^-\d]*/ because we really wanted /(?!-?\d+)/, not either or of the
characters in the group. Completely removing it still allows everything
to work. Don't remember if I added that when I was still using the
substringing algorithm, but whatever happens, it's not necessary now.
100-increment-decrement: Add failing test for backward first number 2021-08-28T13:29:46+00:00 Teddy Wing 2021-08-28T13:29:46+00:00 924e467583354e6faa179518d90e1d4e7ca89743 When point is before the first number, that number should be incremented or decremented. This doesn't work correctly with more complex, real world commands. 
When point is before the first number, that number should be incremented
or decremented. This doesn't work correctly with more complex, real
world commands.
Add license (GNU GPLv3+) 2021-08-24T21:22:58+00:00 Teddy Wing 2021-08-24T21:22:58+00:00 ee898b113f54911e9e2719c3f6b73dcf42139a0e 






100-increment-decrement: Add new second number negative integer tests
2021-08-21T23:37:39+00:00

Teddy Wing

2021-08-21T23:36:02+00:00

6a2d1fc08c17b417a25156bdadcaf45d1929ea4f

The previous negative integer tests worked, but it turns out that when
the negative integer isn't the first one, there's a problem.





The previous negative integer tests worked, but it turns out that when
the negative integer isn't the first one, there's a problem.







100-increment-decrement: Add test to decrement a negative integer
2021-08-21T19:19:48+00:00

Teddy Wing

2021-08-21T19:19:48+00:00

b658b4b89b23ec4966642ad544dff43eca14045b












100-increment-decrement: Doesn't work for negative numbers
2021-08-21T18:56:54+00:00

Teddy Wing

2021-08-21T18:56:54+00:00

9ef2e03beda0e9084a8d871ab433ffdd2b0a70fc

Our pattern matcher doesn't increment or decrement negative numbers
because it doesn't look for a "-" prefix.





Our pattern matcher doesn't increment or decrement negative numbers
because it doesn't look for a "-" prefix.







100-increment-decrement: Add a few new test cases
2021-08-19T21:52:37+00:00

Teddy Wing

2021-08-19T21:52:37+00:00

045950b01cdbee910cab980d998edffe1b9c1ebd












incdec: Add increment step argument
2021-08-19T19:57:59+00:00

Teddy Wing

2021-08-19T19:57:59+00:00

016240388e39c58b2d0bba118e4c1a1a52011cee

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.





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.