stumpwm-devel
[Top][All Lists]
Advanced

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

Re: [STUMP] group-format-map and window-format-map


From: Ben Spencer
Subject: Re: [STUMP] group-format-map and window-format-map
Date: Wed, 16 Mar 2011 18:23:21 +0000
User-agent: Mutt/1.5.20 (2009-06-14)

On Tue, Mar 15, 2011 at 09:37:56PM -0700, Matt Spear wrote:
> Having the windows be stuck with 0-based while groups can be 1-based
> is annoying (and there may be ppl like me that want more generic
> maps).  To accomidate this I added a *group-format-map* and a
> *window-format-map*, both of which can be accessed via %f in the
> *group-format*/*window-format*.  In both cases once the map is
> exceeded the actual window-number or group-number is used.

Hi Matt,

Great, this is a much-requested feature.  Some minor comments:

> (n (if (eq num 0) 10 num))

A group number never will be 0 in the current implementation so I
think this is unnecessary.

> (prin1-to-string n)
> (prin1-to-string num)

This explicit conversion to string is probably not needed.

> (defvar *group-number-map* "0123456789")

Should perhaps be "1234567890"?

> (#\f window-map-number)
> (#\f group-map-number)

Might be better just to replace the existing \#n modifier and ensure
that by default the functions behave equivalently to how window-number
and group-number do now (I think they will with the modification to
*group-number-map* suggested above).

Ultimately (this need not affect this patch) I'd like to see this
integrated further, eg using these mappings in the window and group
selection commands.  This would hopefully put us in a position to
change the group indexing to be zero-based like everything else,
without breaking existing behaviour.

Ben



reply via email to

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