Open linuxcaffe opened 10 years ago
You want C-A/C-X in command mode or in normal mode?
C-A/C-X in normal mode depends on the format of the column(limited). In command mode, I have to reimplement those increase/decrease functions(not so easy I think). Maybe you know which part of speeddating mainly does this(input : current date, format. output : increased/decreased date)?
I'm still learning what speeddating does and I expect it will take many moons befow I understand how . :)
In normal mode, date-field selected, hit C-A, combining "modify - increment - enter" would be amazing, even if it only had a limited action over a limited set of date.column formats. It would make tweaking dates, or times (?) super-easy. That said, there's a lot to consider, which sub-set of speeddating-like actions over which date column formats.. not so simple.
Command-mode, on the other hand, is a different kettle of fish, and while I was thinking of this mode when I filed the issue, I hadn't really thought it through, and I'm realizing how much I don't know about the current capabilities of the command-mode. I'm constantly stumbling across new things, like the blind man feeling an elephant's knee, guessing what it's shaped like :) If you think C-A could be used in command-mode, then it should be!
Well, normal mode is easy.
If a numeric prefix were added, like "5 C-A" to increment 5 days (?) that would seem almost perfect functionality, but would that be command-mode?
Yeah, please check the dev branch to see if that works for you. command-mode is hard to implement.
That works phenomenally well!! WOW numeric prefixs and all SWEET!
It works so well, quickly and almost silently, that I had changed several dates before I realized the list had auto-sorted the active task out from under the cursor. Would it be hard to make the cursor follow with the just-modified task? Otherwise, hitting C-A repeatedly is likely to modify several tasks at once, probably not intended.
It is not hard, but it will slow down the taskwarrior#list process with current structure.(better not)
If that slow-down is only incurred after C-A or C-X then I think the slow-down would be fine, a) because incrementing dates is probably not something you do constantly, and b) because you suddenly and silently modify + lose focus of the active task, it could be disorienting and error-prone, I think (after just blundering through it ;-)
like I say, if that's an edge-case slow-down we should go for it, for safety!
(re-reading your above statement) heck! it's not that dangerous! we'll just put a warning sticker on it and say "keep your eye on the ball" ;-)
Not easy if just for C-A/C-X operations. Currently it can't tell which operation makes it to refresh. I have to add some addtional arguments to many base functions(the arguments are barely used which makes me feel uncomfortable). And it makes the code look uglier I believe. So I don't want to do this. Why not just change the sort method to something like id/project before changing the date?
I was wrong, easy to do that and it is done. please check.
Yay! the cursor stays with that task like a cowboy on a bull! This is better behavior!
One thing I see now is that the C-A or C-X acts on the characters under the cursor, which makes sense, but I'm not sure how to move the character cursor from incrementing the year (default position) to increment per day, without using the mouse (with mouse works fine) maybe I need to better understand speeddating.
h,l move to the day field
Yup! That works great, thank you!
I get the feeling that this feature, increment/ decrement, is one that can keep evolving to other fields and other formats, but this part's fabulous!
On 25 November 2013 18:08, zc he notifications@github.com wrote:
h,l move to the day field
— Reply to this email directly or view it on GitHubhttps://github.com/farseer90718/vim-taskwarrior/issues/72#issuecomment-29252210 .
It only works on numbers.
It works really well where it's supposed to, but this new super-power is still a bit wild.
For example, after experimenting with a duration-type UDA; "duration", with the cursor over the numeric part of "2hr" (wishful thinking) with hopes of moving the digit, leaving the "hr" part unchanged.. the outcome is a tw prompt to confirm a large batch-deletion! oops! :)
In testing mode, and out of curiosity, I cycled the due.format to some non-standard format, cursor over some random part of it, and C-A just swiftly and silently deleted the date altogether!
I tried to increment/ decrement "phase" (a numeric-type UDA), from 1 to 2, without much luck.
Other than that, there aren't that many numbers to logically increment.
You mean you changed the code to test those field? My version only works on due/entry/end fields. It should do nothing for UDAs
Well, no, it means I was testing blindly, not entirely sure that the function was active for. :)
If anything, the behavior might be extended to the other date fields; wait and scheduled.
Extending to UDAs (date-type, duration-type and numeric) would be gravy, but is not that simple or that essential.
After hitting "m" with the cursor on a date field, the date is at the prompt, ready to edit. Being able to increment or decrement any part, using vim semantics Ctrl-A and Ctrl-X (and speeddating, if installed) then hit ENTER and bam!
high-speed procrastination!