On Sunday, October 20, 2013 1:15:52 PM UTC-7, Bram Moolenaar wrote: > Michael Henry wrote: > > > > > I've been wondering about the use of CTRL-C regarding timers. > > > There has been a lot of discussion on ways to regain control in > > > the face of a runaway timer, which is of course an important > > > consideration. I've been wondering, however, about any negative > > > effects of accidental cancellation. If I understand correctly, when > > > a user presses CTRL-C while a timer happens to be running, that > > > timer will be canceled and not rescheduled. Can this happen > > > accidentally when the user is pressing CTRL-C for other reasons > > > (e.g., to abandon an ex-mode command he was typing)? Since > > > timers might be running at arbitrary times, how can a user be > > > sure it's safe to press CTRL-C without running the risk of canceling > > > a timer by mistake? Should it require multiple CTRL-C presses in > > > a row before aborting current and future timers, or is there some > > > other way to make sure the user won't accidentally cancel timers > > > that are operating properly? > > > > The problem with timers is that they repeat. I would think a first > > CTRL-C would "pause" a timer if it's clear that was the intention of > > hitting CTRL-C. As suggested, that the timer has been running for more > > than a certain time would work. Anything that's stuck must quit when > > CTRL-C is pressed. That's what it's for. > > > > But if the timer runs for a short time, but very often, it may still > > cause the user to hit CTRL-C to stop it. Perhaps we can detect that the > > user types CTRL-C twice in a row, then we know we need to cancel more > > than just the current operation. If there are multiple things that > > could be interrupted, a "what do you want to interrupt?" dialog could be > > used (although that's not really user friendly). > > > > I would prefer to have CTRL-C pause the timer instead of completely > > killing it. That gives a way to recover. E.g. if the timer uses a > > socket that is temporarily unavailable. Would require a "resume timer" > > command. > >
Bram, Thanks for taking time to look at our patch and give feedback. Besides pausing/resuming timers, are there any other blockers for merging this patch? Matt and I really want to get it merged, but there's been a recurring pattern where we address one thing only to have another brought up. If this is the last thing, we'll gladly add it. If it's not the last thing, please give us a complete list of blockers. Then we can determine if we want to continue addressing your issues or just maintain our own fork of Vim. Sincerely, Geoff Greer > > -- > > Did you ever stop to think... and forget to start again? > > -- Steven Wright > > > > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ > > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > > \\\ an exciting new programming language -- http://www.Zimbu.org /// > > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
