[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Making the command loop mode-dependent [was: position on changing defaul
From: |
Alan Mackenzie |
Subject: |
Making the command loop mode-dependent [was: position on changing defaults?] |
Date: |
Sun, 9 Mar 2008 08:38:23 +0000 |
User-agent: |
Mutt/1.5.9i |
Morning, Kim!
On Sat, Mar 08, 2008 at 09:56:01PM +0100, Kim F. Storm wrote:
> Stefan Monnier <address@hidden> writes:
> >> BTW, why is using a pre- or post- command hook so bad?
> > These tend to be brittle (e.g. when entering/exiting minibuffer
> > prompts or recursive edits) and difficult to debug. I think the need
> > for pre/post command-hook is often a sign of a missing functionality
> > elsewhere.
> It seems I could get by with the following hooks:
> pre-command-shifted-key-hook
> Called before executing command if transient-mark-mode
> is enabled and current command is invoked by a shifted key.
> pre-command-mark-active-hook
> Called before executing command if transient-mark-mode
> is enabled and mark is active.
> post-command-mark-active-hook
> Called after executing command if transient-mark-mode
> is enabled and mark is active. Called before checking
> value of deactivate-mark!
Where are these hooks going to be called from? The command loop?
I think this needs a _LOT_ of thinking about.
Up to now, the command loop has been @dfn{vi-modeless} (i.e. doesn't
have things like vi's "insert-mode" and "command-mode"). This is a
fundamental assumption which (I think) has always been implicit up till
now.
If the command loop starts calling hooks IF certain user-level conditions
hold, it will cease to be vi-modeless. Things will surely break.
Somehow, sometime, this is going to cause a LOT of pain in the far
future, since it will constrain our options. In the medium future,
possibly, some modes might have to start testing the values of these
hooks to behave properly.
[Stefan:]
> > These [pre- and post-command-hooks] tend to be brittle (e.g. when
> > entering/exiting minibuffer prompts or recursive edits) and difficult
> > to debug.
I can't see that pre-command-shifted-key-hook and friends would be any
less brittle.
[ .... ]
> --
> Kim F. Storm <address@hidden> http://www.cua.dk
--
Alan Mackenzie (Nuremberg, Germany).
- Re: position on changing defaults?, (continued)
- Re: position on changing defaults?, Richard Stallman, 2008/03/11
- Re: position on changing defaults?, Kim F. Storm, 2008/03/08
- Re: position on changing defaults?, Stefan Monnier, 2008/03/08
- Re: position on changing defaults?, Kim F. Storm, 2008/03/08
- Re: position on changing defaults?, Miles Bader, 2008/03/08
- Re: position on changing defaults?, Stefan Monnier, 2008/03/08
- Re: position on changing defaults?, Richard Stallman, 2008/03/09
- Re: position on changing defaults?, Chong Yidong, 2008/03/10
- Re: position on changing defaults?, Kim F. Storm, 2008/03/11
- Re: position on changing defaults?, Kim F. Storm, 2008/03/08
- Making the command loop mode-dependent [was: position on changing defaults?],
Alan Mackenzie <=
- Re: position on changing defaults?, Richard Stallman, 2008/03/06
- Re: position on changing defaults?, Kim F. Storm, 2008/03/07
- Re: position on changing defaults?, Richard Stallman, 2008/03/08
- Re: position on changing defaults?, Miles Bader, 2008/03/08
- Re: position on changing defaults?, Kim F. Storm, 2008/03/09
- Re: position on changing defaults?, Miles Bader, 2008/03/09
- Re: position on changing defaults?, Stefan Monnier, 2008/03/09
- Re: position on changing defaults?, Kim F. Storm, 2008/03/09
- Re: position on changing defaults?, Miles Bader, 2008/03/09
- Re: position on changing defaults?, Johan Bockgård, 2008/03/09