integration with spacemacs

[gcentauri]

I'm a happy user of xah-fly-keys, it has helped me avoid serious RSI over the past year of professional work.

Recently, I have been trying to adopt Spacemacs rather than my traditonal .emacs configuration and there are some places where xfk could use a little help.

For example, spacemacs seems to control the cursor so the standard xfk behavior of switching from box to bar doesn't work. there is also inconsistent switching of keymaps when entering different modes (which i know is more of a emacs issue than a xfk issue) - for example, when using magit mode before spacemacs, many of the xfk commands still worked as expected (navigation and such). in spacemacs, magit commands seem to have precedence which is okay, but can be problematic for certain things. when switching to a magit sub-command buffer, suddenly xfk has precedence and i have to swich out of command mode in order to finish up a command.

i am happy to start digging in and seeing what can be done, but i wanted to raise this issue to see if you had any guidance on integrating with something as large as spacemacs. i think it would be awesome if someday xfk was just as important of an input mode as evil

[xahlee]

thank you!

about spacemacs, i never actually tried it, but have heard of lots good things about it.

about spacemacs + magit + xah-fly-keys (i have abbrev so xfk expands), i don't have info to give you.

with gnu emacs + magit + xah-fly-keys... it has issues overriding xah-fly-keys. but i haven't really investigated. I just switch to insert mode and make do.

some of the issue really can't be solved without serious hacking, which is not desirable.

e.g. emacs can have keybinding in text properties, so that key behavior depends on cursor position. I'm quite sure that's how part of magit works. e.g. when cursor is on a file, press s to add.

but other than this, also that emacs don't really have a good keybinding priority. So minor modes could override each other. I don't think there's a none tech policy about this neither.

so, am fraid you'll have to explore. But if you find something, post the issue, , i'll look into. (usually that's how i get to start to do things)

[gcentauri]

I opened a pull request into the spacemacs project to offer xah-fly-keys as a layer. https://github.com/syl20bnr/spacemacs/pull/11701

I added some extra config for the cursor color to identify modes (something by default clobbers the block/bar switch), set the default layout to "qwerty" (spacemacs and evil assume qwerty for the most part), and turned the control key off by default. I also added a hook to switch to insert mode when in magit buffers and popups, seems to work great so far. I'd like to do a decent job of representing your choices about presenting the keymap though, so I thought I'd post here if you had any input on how to integrate with Spacemacs.

I've also been taking bits of your documentation, but giving credit to you for your great work! Just hoping to help, let me know if you have any opinions.

[xahlee]

that's fantastic! thank you very much. In this week, let me look at spacemacs, and see if i can help in anything.

[gcentauri]

This issue could potentially be closed if you don't have a use for it @xahlee

I am currently maintaining a layer for spacemacs here https://github.com/gcentauri/xah-fly-keys-layer

I'm still working on integrating it with some of the major features of Spacemacs, particularly with Helm/Ivy completion helpers. How do you feel about adding some of that to xah-fly-keys itself? I noticed that the execute-extended-command function has a condition to see if helm-M-x is bound. There's a few places like that where xah-fly-keys could check for alternate functions (like isearch) provided by popular packages like helm. On the other hand, perhaps they could just be variables that a user can set (e.g. (setq xah-fly-keys-search-function 'helm-swoop) ) or something like that.