non-instant status-cycling with TAB

[linuxcaffe]

currently, the tab-key is mapped to cycle the status of a task. The problem is, if a task cycles from pending to completed, it instantly disappears from the tasklist, making further cycling impossible.

My suggested "fix" for this tab cycling, would be to delay saving the actual status change while the task is still selected. Immediately after moving the cursor off the task, THEN the new task status is changed.

This way, a user could hit TAB and the symbol would change [ ] --> [X] --> [D] -->[ ] and so on, but the task stays on screen till the user leaves the row, and gives the user to cycle back to pending, if the change was unintended.

[blakesweeney]

This i s a good idea. I'm actually not sure why it disappears right away. At first I was thinking that it immediately recomputes the list but I'm actually not sure that's happening. I'll look into why this happens and see if we can do something about it.

[blakesweeney]

I'd actually like this for 1.0, but I'm not sure what's going on, so we'll see.

[linuxcaffe]

I might suggest disabling the tab key until non-instant works; I dissapeared a few tasks before I remembered what the tab key was supposed to do! (recovered)

[blakesweeney]

I've been playing around with this a bit and I don't think it's possible. As far as I can tell unite does not provide the ability to alter the display of candidates in a buffer without basically reloading all of them. This also likely means that sparkle isn't possible. I was hoping there was some sort of on_action hook but there is not. I'm going to have to close this unless I can find a way to do this.

[linuxcaffe]

One workaround Idea I had was to alter the behavior of the TAB key so that instead of directly cycling through status, pressing tab brings up prompt;

Status:completed

hit TAB again and the prompt is incremented to

Status:deleted

and TAB again to cycle around to PENDING.

This way, no changes take place until the prompt appears and user hits ENTER.

[blakesweeney]

On Sun, Sep 27, 2015 at 11:00:58AM -0700, David J Patrick wrote:

One workaround Idea I had was to alter the behavior of the TAB key so that instead of directly cycling through status, pressing tab brings up prompt;

Status:completed

hit TAB again and the prompt is incremented to

Status:deleted

and TAB again to cycle around to PENDING.

This way, no changes take place until the prompt appears and user hits ENTER.

Ok I can set that up. I like the current behavior of tab so I'll make it configurable.

[blakesweeney]

This is now implemented. Try it out. You can turn it off by setting prompt_on_toggle to 0.

[linuxcaffe]

Works great, right outta the gate, pressing TAB, I get a prompt

Status: completed

Great! then, hitting TAB again, thinking it should cycle to "Status: deleted" but instead,

Status: completed^I 

and further presses of TAB produce "^I^I^I^I.."

:map shows @unite#do_action('toggle'), and /config toggle_mappings look right. idonno...

[blakesweeney]

Right now you would have to delete the text and write deleted in. I might be able to do something with autocomplete. I don't know much about it, so I'll take a look.

[blakesweeney]

Ok I think I've got this working now. Try it out and let me know.

[blakesweeney]

As far as I can tell this is fixed, so I'm going to close this issue.