Sv: Spatial groups refactored as a module

[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 <theophilusx@gmail.com>:

> 
> Shostek <szos@posteo.net> writes:
> 
>> 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.
>> 
> 
> 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