On 13/10/13 20:10, Nikolay Pavlov wrote:
On Oct 13, 2013 3:05 PM, "Nikolay Pavlov" <[email protected]
<mailto:[email protected]>> wrote:
>
>
> On Oct 13, 2013 2:57 PM, "Andre Sihera" <[email protected]
<mailto:[email protected]>> wrote:
> >
> > On 03/10/13 07:40, kans wrote:
> >>
> >>
> >> I believe we have addressed all major concerns- the last one
being the ex_timers command which shows all pending timers. If we
have missed something, or you have other concerns, please let us know.
As I wrote before, we'd really like to see this feature in Vim.
> >>
> >> -Matt
> >>
> >
> > Actually, I have a concern regarding these timers.
> >
> > Please confirm the method by which I can unconditionally disable
all timers, and all
> > attempts to thereafter create a timer, using a single command. For
example, a
> > command like "timers off" in my .vimrc could override any attempt
by any plug-in
> > to enable a timer and force ViM into a guaranteed timer-free state.
>
> You have no way to unconditionally disable mappings, statusline,
CursorHold events and so on; all these features can be harmful if used
not in proper way. If plugin developer wants to make intrusive plugin
he will make it. Thus such command makes exactly no sense. CursorHold
is what is currently used to emulate timers.
Forgot a thing: CursorHold may be disabled with eventignore. Though
nothing may prevent a plugin from resetting this option.
I'll take your "Thus such command makes exactly no sense" response as a
"No", shall I?
A plug-in developer may want to create an intrusive plug-in, in which
case there had
better be a way that normal users have to protect themselves against
such plug-ins,
irrespective of whether those plug-ins were created with malicious
intent or not.
Timers turn a finite-state system into a real-time system, and
guaranteeing the reliability
of any real-time system is impossible. Which is why, in every real-time
system, however
simple, there is always a get-out clause; and ViM should have one as
well for when things
go wrong. There is a lack of control on some commands now but that is no
excuse for not
building in appropriate controls into future commands to create a more
robust, reliable,
and predictable User experience.
When things inevitably do go wrong and become a hassle to diagnose
and/or fix, Users
may dump ViM in favour of other editors; editors that don't pretend to
be all-singing and
all-dancing for the benefit of a few at the expense of being a robust,
reliable, and
predictable tool for the many.
--
--
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
