Spatial groups refactored as a module

[Russell Adams]

I've cleaned up the code into a module following the instructions on
the wiki. It's posted here:

https://osdn.net/users/rladams/pf/StumpWMSpatial/

I'm open to this migrating to contrib, modules, or elsewhere in the
project.

Installation instructions are on the main page (README).

==================================================================
Russell Adams Russel...@AdamsInfoServ.com
Principal Consultant Mobile: 281-846-8329

PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/
Fingerprint: 1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3

[Roland Everaert]

Excellent.

Thanks,

Roland Everaert
---
Use the F.O.S.S., Luke

Envoyé avec la messagerie sécurisée ProtonMail.

------- Original Message -------

[Russell Adams]

On Tue, Mar 08, 2022 at 06:20:40PM +0100, Russell Adams wrote:
>
> https://osdn.net/users/rladams/pf/StumpWMSpatial/

Updated to 0.0.2:

- Created function spatial-groups:install-default-keybinds to install
Control key based default keybinds. These may conflict with some
GUI applications. Use the function as a template to create your
own.

- Updated README to show optional requirement to create keybinds.

------------------------------------------------------------------
Russell Adams RLA...@AdamsInfoServ.com

[Shostek]

it may be cleaner to define *spatial-groups-[top|root]-map* variables and add the new top map to the default top maps when the module is loaded instead of defining keys directly in the *top-map* variable. Its how group types handle their group specific bindings and would give a canonical place to put bindings related to spatial groups. Default bindings could perhaps be placed in the *spatial-bindings-root-map*, such that they don't interfere with application bindings. Just a thought.

Cheers
Sz

[Tim Cross]

I was thinking along similar lines, but then I realised that with most
of the bindings, you want them to be directly on the *top-map* i.e. you
want to be able to move around with 1 key stroke.

I think the recent changes are probably on the right track i.e. have a
function which you can call to have the 'default' bindings if you want
them and document what you need to bind for those who need something
different.

In my case, I've used the super key and the vi 'hjkl' and 'HJKL' for the
most common movement keys and super + Up/Down/Left/Right for the rest. I
also use super instead of C-t as my *root-map* prefix. This greatly
minimises impact with other applications.

Tim

[Shostek]

Sorry, I don't think I expressed what I meant well. I agree that a function setting up default bindings should be present, but think it could be cleaner if the bindings were enabled by default in a root map hanging from a new top map specifically for spatial groups. Then the function to install the default bindings at the top map level would install them to this new top map, and all user bindings could be defined there as well.

Cheers,
Sz

13. mar. 2022 22:07:48 Tim Cross <theop...@gmail.com>:

[Tim Cross]

Shostek <sz...@posteo.net> writes:

> Sorry, I don't think I expressed what I meant well. I agree that a function
> setting up default bindings should be present, but think it could be cleaner if
> the bindings were enabled by default in a root map hanging from a new top map
> specifically for spatial groups. Then the function to install the default
> bindings at the top map level would install them to this new top map, and all
> user bindings could be defined there as well.
>

I think I understood, but perhaps I'm confused by your use of *top-map*
and *root-map*. My understanding is that *top-map* is the highest
keymap. By default, the only key bound in this map is C-t, which is
bound to the *root-map*. To get to any key bindings defined in the root
map, you have to first enter C-t. If you use set-prefix-key, the
*root-map* is bound to the new prefix key in the *top-map*.

If you were to put the bindings in their own keymap, you also need to
have a prefix key to bind that keymap, so as a minimum, two key
presses to execute any of the actions (assuming it is bound to the
*top-map*, 3 if bound to the *root-map*).

For moving around windows/groups/frames, I think you want as few key
presses as possible i.e. you want it bound directly in the *top-map*,
but things bound in this map must not conflict with 'normal' bindings
for applications, which is why I find super (windows key) to be a good
prefix. I only use Linux and the super key is rarely used by
applications on Linux.

Using a function which directly binds the movement functions to the
*top-map* allows movement to be triggered with one key press. Yes, it is
perhaps less 'clean' than having a new keymap which you could bind to a
prefix of your choice, but avoids the problem of movement now requiring
more key presses.

Of course, if you don't mind having to use two key presses to move
around windows/groups/frames, using a keymap is clean and it would make
it possible to define a function to allow the user to select/change the
*top-map* prefix, but I suspect most people will prefer single key press
movement.

[Shostek]

Ah, sorry what I'm referring to is the (perhaps poorly documented) way top maps are handled. There is one general *top-map*, but there is also a *group-top-map*, *float-group-top-map*, etc., which define top level keybindings for various groups. By default they all just contain their respective root map bound to the prefix key, but if you for example wanted some keybindings active in only floating groups you could define them in the floating groups top/root maps. These maps are returned by the function #'top-maps if I recall correctly (I don't have my pc in front of me). I was suggesting that such a setup could be used with the spatial groups to have a canonical place for bindings related to the spatial groups.

Cheers,
Sz

13. mar. 2022 22:51:58 Tim Cross <theop...@gmail.com>:

[Tim Cross]

Shostek <sz...@posteo.net> writes:

> Ah, sorry what I'm referring to is the (perhaps poorly documented) way top maps
> are handled. There is one general *top-map*, but there is also a
> *group-top-map*, *float-group-top-map*, etc., which define top level keybindings
> for various groups. By default they all just contain their respective root map
> bound to the prefix key, but if you for example wanted some keybindings active
> in only floating groups you could define them in the floating groups top/root
> maps. These maps are returned by the function #'top-maps if I recall correctly
> (I don't have my pc in front of me). I was suggesting that such a setup could be
> used with the spatial groups to have a canonical place for bindings related to
> the spatial groups.
>

Thanks for explaining. I understand what you mean now.

[Shostek]

No problem, sorry I wasn't more clear to begin with.

14. mar. 2022 00:38:29 Tim Cross <theop...@gmail.com>:

[sam kleinman]

On Tuesday, March 08 2022, 18:20:40, Russell Adams wrote:

> I've cleaned up the code into a module following the
> instructions on
> the wiki. It's posted here:
>
> https://osdn.net/users/rladams/pf/StumpWMSpatial/
>
> I'm open to this migrating to contrib, modules, or elsewhere in
> the
> project.

This is pretty great!

I'd definitely love to see this in stumpwm-contrib or somewhere
otherwise quicklisp-able?

--
sam kleinman
s...@tychoish.com
https://tychoish.com/

[Russell Adams]

On Sat, Apr 30, 2022 at 08:55:49PM -0400, sam kleinman wrote:
>
> On Tuesday, March 08 2022, 18:20:40, Russell Adams wrote:
>
> > I've cleaned up the code into a module following the
> > instructions on
> > the wiki. It's posted here:
> >
> > https://osdn.net/users/rladams/pf/StumpWMSpatial/
> >
> > I'm open to this migrating to contrib, modules, or elsewhere in
> > the
> > project.
>
> This is pretty great!
>
> I'd definitely love to see this in stumpwm-contrib or somewhere
> otherwise quicklisp-able?

I'm not sure how to get it into contrib, but I'm open to moving it
anywhere.

Honestly the idea is a simple one, it's just explaining it that's
hard. I just wanted to contribute something that helped me daily.


------------------------------------------------------------------
Russell Adams RLA...@AdamsInfoServ.com
https://www.adamsinfoserv.com/

[sam kleinman]

On Sunday, May 01 2022, 03:07:29, Russell Adams wrote:
> I'm not sure how to get it into contrib, but I'm open to moving
> it
> anywhere.

Just do a pull request to this repo:

https://github.com/stumpwm/stumpwm-contrib

>
> Honestly the idea is a simple one, it's just explaining it
> that's
> hard. I just wanted to contribute something that helped me
> daily.

StumpWM itself is pretty simple in a lot of ways, so this is sort
of the thing that makes it good and consistent with the
idiom. Writing good documentation is often the hardest part of
software.

Cheers,
sam

[Russell Adams]

On Sun, May 01, 2022 at 08:52:34PM -0400, sam kleinman wrote:
> Just do a pull request to this repo:
>
> https://github.com/stumpwm/stumpwm-contrib

Well, I had to make an account. :P

I made a clone, merged spatial, updated Readme and checked the coding
standards. Ideally it'll be an easy addition.

> > Honestly the idea is a simple one, it's just explaining it that's
> > hard. I just wanted to contribute something that helped me daily.
>
> StumpWM itself is pretty simple in a lot of ways, so this is sort
> of the thing that makes it good and consistent with the
> idiom. Writing good documentation is often the hardest part of
> software.

That's part of the problem. I had to make a video for anyone to
understand the idea. I don't mind putting the code on Github, but I'm
not sure where to host the video in the long run.

Thanks.