stumpwm-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [STUMP] [PATCH] command-mode-hook


From: Ben Spencer
Subject: Re: [STUMP] [PATCH] command-mode-hook
Date: Thu, 10 Mar 2011 19:45:40 +0000
User-agent: Mutt/1.5.20 (2009-06-14)

Hi Matt,

On Wed, Mar 09, 2011 at 10:11:06PM -0800, Matt Spear wrote:
> Have a *command-mode-start-hook* and a *command-mode-end-hook*.

Cool.  I guess these should be exported.


> (move the defvar *root-map* to primitives)

Might fit better in kmap.lisp, where *top-map* is defined.


> Also changed the grab/ungrab pointer to use a counter so that things
> work right when not making the pointer grabbed during command-mode.

Nice.  You don't need the progns in grab-pointer and ungrab-pointer
though, function bodies have an implicit progn.


> I made the (message "Exited") not appear when in command-mode as the
> command-mode-end-hook may want to do a message (in my case it is
> distracting as the pointer changes shape).  If desired
> command-mode-end-hook can do it.

So as it stands there are no enter and exit messages (and thus no
feedback at all) for command mode by default?

On reflection, maybe we should prepopulate the hooks with message
functions after all.  If so, they should be named, exported functions,
eg command-mode-start-message and command-mode-end-message.  This
would enable the user to selectively remove parts of the default hook.

Anyone else have opinions on this approach?


> +  (let ((in-top-map (eq *top-map* *root-map*)))
> +    (when (pop-top-map)
> +      (if in-top-map

Minor: this variable name doesn't really seem to fit.  in-command-mode
perhaps?  Alternatively maybe pop-top-map could be changed to return
the map it's just popped, avoiding the need for a variable altogether.


Ben



reply via email to

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