search

xahlee / xah-fly-keys

the most efficient keybinding for emacs
http://xahlee.info/emacs/misc/xah-fly-keys.html
472 stars 80 forks source link

C-s remapping breaks ido #36

Open akater opened 6 years ago

akater commented 6 years ago

ido-next-match is bound to C-s which xah-fly-keys remaps to save-buffer. This breaks ido searches.

The issue is easy to fix. I defined xah-save-buffer-unless-ido function which checks if we're in minibuffer. I can submit a PR.

xahlee commented 6 years ago

Thanks. Not sure about this. My reasons are:

• it complicates the key. The C-s is meant for compatibility with de facto standard key for save. If we do this, now it has multiple meaning depending on which buffer cursor is at.

• C-s is a key combination. We try to avoid any key combination. I'd recommend up/down arrow for ido-next-match. (in other words, that's the philosophy am going with.)

akater commented 6 years ago

  1. Attempting to save-buffer while in minibuffer just ends in error. Hence, minibuffer is not meant to be saved at all. Which is why I don't see this as a problem, and I wouldn't propose this in case minibuffer was save-able.

  2. Up/down arrows would be totally inconvenient in terms of hands movement. It works with left/right arrows right now. The whole problem is, you can't ido-next-match without hands moving or going into command mode. C-f and C-b are occupied in ido too. How about C-n and C-p for ido-next-match and ido-prev-match, then? I don't really enjoy the idea to switch to command mode in minibuffer merely to choose among ido entries. OTOH, C-n and C-p could be used for something else in ido, or might be used in future.

akater commented 6 years ago

BTW, even with xah-fly-keys activated, I still use C-s to isearch-forward once the search query is entered. Is this wrong?

akater commented 6 years ago

Let's recap:

If we do this, now it has multiple meaning depending on which buffer cursor is at.

C-s already has multiple meanings. It still means “next” in isearch. There's 4000 packages out there, and some of them probably give their meanings to C-s as well. It just happens to have an established meaning in emacs.

The C-s is meant for compatibility with de facto standard key for save.

One cannot save minibuffer. I suggest only overloading it in minibuffer. At the moment, C-s in ido search triggers what is essentially an error message.

We try to avoid any key combination.

You do. ido doesn't. It's not about xah-fly-keys, it's about xah-fly-keys breaking something else, a built-in functionality. Ido is literally unusable with xah-fly-keys, for no good reason. (In fact, it breaks quite a lot but this one is easy to fix.) Note also, your package itself uses a key combination C-s for saving because it's “standard”. That's eating a cake while wishing to have it. More so, this standard is no less inefficient and arbitrary than Emacs defaults.

I'd recommend up/down arrow for ido-next-match.

Arrows are far from home row. Getting to them or, worse, switching between command mode and insert mode in ido buffer to manipulate candidates is exceedingly wasteful, given the alternative. Often, the correct candidate is one call of ido-next-match away. Often as well, one has to pick them again and again in deeper levels during one ido session. This particular case is extremely hostile to mode switching.

Please make a decision on this. I'd rather see this (fairly trivial) issue closed with ido still broken than in an undetermined state, as present. (I wouldn't consider binding arrow keys a solution, for reasons specified above.)

BTW, I think it would be better to remove -unless-ido prefix from the function name.

rschmidlin commented 6 years ago

Hello, my suggestion is to use TAB for next occurrence. I have bound it for usage with isearch-forward (b in command mode). I am quite happy with it and I think it balances well with the usage of DEL for navigating back: (define-key isearch-mode-map (kbd "TAB") 'isearch-repeat-forward) I'm sure you can do it for ido the same way. Best, Raul