emacs-devel
[Top][All Lists]
Advanced

[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).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]