C-k should be C-k in helm for hybrid mode.

[choppsv1]

Currently

       (run-hook-with-args 'spacemacs--hjkl-completion-navigation-functions
                          (member dotspacemacs-editing-style '(vim hybrid)))

remaps C-k in helm minibuffer to a cute vim inspired C-j/C-k for C-n/C-p functionality. This is fine for vim choice I suppoes; however, in hyrbrid mode one expects emacs editing keys to work when in "insert" situations such as helm minibuffer.

So: we should remove hyrbid from the list of modes in the above code.

[bmag]

I have to disagree. As a Hybrid user, I find C-k and C-j very comfortable for movement, though YMMV.

Helm, as well as other minibuffer interactions (e.g. Ido and Ivy), aren't strictly "insert" situations. It is very common to select a candidate from a list (e.g. find-file, switch-buffer), and in these cases moving between candidates is more useful than deleting the input (original C-k). I know of C-n and C-p, but I find C-k and C-j easier to reach.

Another concern is consistency. We use C-j and C-k for navigation in several other places, like company popup and repls. Although, these also have C-n/C-p or M-n/M-p bindings for the same commands, so maybe we can live without them...

[nixmaniack]

I fully agree with @bmag on this.

[choppsv1]

Bar notifications@github.com writes:

I have to disagree. As a Hybrid user, I find C-k and C-j very comfortable for movement, though YMMV.

Helm, as well as other minibuffer interactions (e.g. Ido and Ivy), aren't strictly "insert" situations. It is very common to select a candidate from a list (e.g. find-file, switch-buffer), and in these cases moving between candidates is more useful than deleting the input (original C-k). I know of C-n and C-p, but I find C-k and C-j easier to reach.

Another concern is consistency. We use C-j and C-k for navigation in several other places, like company popup and repls. Although, these also have C-n/C-p or M-n/M-p bindings for the same commands, so maybe we can live without them...

Ok well here's my argument. If this fails I at least want a way to
override the behavior...

As a hyrbid user, if C-a, C-e, C-f, and C-b do the emacs things, then I
expect C-k to as well in the same context. I think I have a leg to stand
on here since those are the most basic emacs editing keys, if the first
4 are there, I have an expectation (reasonable I think) that I'm now in
the "hybrid/emacs" editing mode and I shouldn't get tricky vim-like
stuff overriding basic emacs editing keys. :)

FWIW I use C-n/C-p/M-n/M-p in these situations and expect them to work for
the same reason as above (i.e., I'm in an "emacs/hybrid" situation).

Thanks,
Chris.

[bmag]

@choppsv1 that's a good argument, especially from an Emacs style point of view. But hybrid style is a merge between Emacs and Vim styles, so we also have to take the Vim side into account.

Hybrid is supposed to act as Vim, except for insert state where it should act as Emacs. However, the minibuffer isn't exactly insert state. I think we are arguing here about how much Emacsy or Vimmy the sort-of-like-insert interactions should be. We're talking specifically about the Helm and the minibuffer now, but we can also use the same arguments for popups and repls. Your expectation ("hybrid/emacs") is reasonable, but the other way around is also reasonable ("hybrid/vim").

Honestly, I don't think either one of us is more correct than the other. Looks like a personal preference to me, where the current Spacemacs behaviour just happens to match my preference.

It would be nice to have a consistent way to enable/disable vim-like keys in sort-of-but-not-exactly-insert-like interactions. Though it won't exist until somebody implements it, of course.

related issue: #5211

[sooheon]

I have felt the same pain points as @choppsv1 many times, so I must speak out in his favour.

Actually another place I encounter this is in company completion. C-j C-k have very standardised meaning for editing in emacs, creating a new line and killing are certainly among the most common actions. For that to suddenly behave completely differently based on whether 0.2 seconds have passed and the completion menu popped up, strikes me a pretty bad ux, and I've changed it to reflect my tastes in my config.

I think the spirit of vim we should embrace for hybrid mode is to use the strengths of modality to the fullest. There's nothing "vimmy" about C-hjkl, as they are already a bastardization of the modal philosophy. hjkl keys are not special, and the entire point of them was that you need not press the C- prefix. As long as you are going with chorded movements within insert mode, you should go with the existing standards of the emacsy way (as in vim-rsi). Especially when they shadow extremely useful conventions.

I should add that hybrid style is specifically a merge of the two styles so that emacs conventions remain untouched while editing, and vim conventions can coexist with chorded keys while navigating. Just adding C-hjkl is not a good way to mix the two, in my opinion.They are chorded navigation while inserting, specifically a case where emacs conventions should be untouched.

[justbur]

I vote to remove or change C-jk for hybrid. I am used to them now, but can get used to something else. One of the reasons I like hybrid is that I can consistently use readline bindings when I'm inserting text. C-jk throws that off. That being said I really like hjkl for navigating directories. Here's another proposal

Move C-hjkl to M-hjkl which gives the same flavor with a different modifier. There is less conflict and it should be easier to apply these more consistently across modes. What do you think?

[justbur]

By the way, emacs screws up C-np for history commands anyway.

[AlejandroCatalina]

I agree with @justbur on the M-hjkl thing. 👍

[syl20bnr]

If we draw a segment with Vim and Emacs at the extremes and hybrid somewhere on this segment we end up with a lot of possible hybrid flavours leaning toward more Vim or more Emacs behaviour.

My stance on hybrid is this:

Hybrid is Vim style with Emacs bindings in insert state

It looks to me that in Helm buffers we are in insert state so the Emacs bindings should prevail.

Now we can add options to hybrid style if this is reasonable to implement and does not break dynamic switching of style.

[justbur]

It looks to me that in Helm buffers we are in insert state so the Emacs bindings should prevail.

Does that mean M-np for selecting candidates (or whatever helm uses I can't remember)?

[syl20bnr]

I don't know the Helm bindings but I guess in hybrid state the default helm key bindings should be available, except if enough users agree on a tweak for them (both hybrid and Emacs style).

[nixmaniack]

I got used to C-jk because of spacemacs but surely I can retrain for other binding(or default C-np). But as pointed in #5211 remapping C-jk in insert states would certainly make terrible UX.

So looking at helm input line as hybrid insert state, it makes sense to remove C-jk but it would be nice to move them under another modifier(as justbur mentioned M-jk sounds reasonable; M-hl might be conflicting if someone is used to downcase-word or mark-paragraph)

[bmag]

I'm ok with moving away from C-jk as well.

[justbur]

I think we should keep hjkl in some form for hybrid users. These are from normal mode, and a set of key bindings that they have said that they want (o/w they could pick emacs style). I don't see any big problem from having them on M-hjkl (they could always use the default bindings and if it's a huge problem for someone they can switch to emacs or rebind the key they miss). Defaults will never satisfy everyone.

Much more important than that is that the bindings are consistent across spacemacs for these users. Use the defaults is not a good answer if the defaults are inconsistent between helm, ivy, company, etc.

[choppsv1]

On Feb 25, 2016, at 1:17 PM, Justin Burkett notifications@github.com wrote:
Much more important than that is that the bindings are consistent across spacemacs for these users. Use the defaults is not a good answer if the defaults are inconsistent between helm, ivy, company, etc

So assuming we are going to stop remapping C-jk ...

I've been thinking about this suggestion of using another mapping, and I wonder if we shouldn't use 2 modifiers e.g., C-M-[hjkl] by default to provide a high probability of not clashing with anything else (except maybe org mode which probably uses every combination possible :) That way we could blanket use them everywhere as you say and be consistent. It's useful that you can press the modifiers with one hand and the direction keys with the other so using 2 modifiers isn't much more burdensome than 1.

Additionally it would be nice to allow the user to change the default modifier combo to whatever modifiers they want (i.e., put the setting in the spacemacs/layers defun).

Chris.

[sooheon]

Re: @justbur

I think we should keep hjkl in some form for hybrid users. These are from normal mode, and a set of key bindings that they have said that they want (o/w they could pick emacs style).

Another interpretation is that hybrid mode users have opted in for modal editing, and don't think that there is anything special about the hjkl keys. After all, if you're going to be pressing a modifier anyway, you can avoid the shadowing and potential conflicts all together and just use C-npfb

Much more important than that is that the bindings are consistent across spacemacs for these users. Use the defaults is not a good answer if the defaults are inconsistent between helm, ivy, company, etc.

But emacs is very consistent in this regard, and C-npfb works for all three of these packages mentioned. There is no pressing need for new chorded navigation keys on Foo-hjkl, and I think the desire for this is trying to take the wrong thing from vim (the keys themselves, not the modal philosophy).

I think an option that achieves better modality is leaving the M-foo C-foo space untouched in insert mode, and using something like the ivy-transient-state. I found that it was highly intuitive to use readline bindings while completing in "insert" state, and also have a "normal" state to do hjklduGg etc. navigation, as well as other commands, with single keypresses. The most important thing is that readline habits are not shadowed, and modality can also be achieved. Here we can be as unified as we'd like across spacemacs, because transient states are something we've added, and are meant to be modal, so there is no problem of shadowing.

In other words, rather than adding hjkl keys to insert mode (which even vim doesn't have), it is better to add the normal mode.

[choppsv1]

@sooheon

If there's a way to add ESC to these minibuffer "apps" which would switch to normal (modal) mode, I'm hugely in favor of adding this capability. This then yields straight-forward vi compatibility not to mention a lot of extra editing functionality. I'd be in favor of adding this everywhere possible, even for standard emacs commands like find-file

[sooheon]

@choppsv1 Try adding the spacemacs-ivy package, and after spc f f, press C-o (which I believe in default evil is the key for evil-execute-in-normal-state). We already have the technology! :)

The reason normal state is not on ESC is because these minibuffers really should go away with one ESC press.

[justbur]

@sooheon they're not entirely consistent though by default. Helm's tab is very different from ivy's and company's. Company uses M-np for candidate selection while Ivy and helm use C-np. I don't think company uses C-j. I'm sure there are others but these little inconsistencies can get annoying in my opinion even if you learn them eventually

[sooheon]

@justbur Tab being different I think is a different discussion, (after all apps have different functionality) but I stand corrected on the C-np for company, you're correct.

I still don't think that is too inconsistent--C-np moves point in the buffer, and M-np moves selection, exactly analogous to defaults in say, eshell (this is why going by memory I saw no inconsistency--because it's idiomatic in emacs-land). In fact, company putting movement on M-np is a good example of deliberately not interfering with readline bindings when editing.

In any case, your point still stands, that there will be inconsistencies. The question is, should the inconsistencies be in the realm of accepted variability which emacs package devs chose for their own ecosystem (difference between C-np or M-np, for example, which when you get down to it, still have sensible logic), or should they be overriding expected default behaviour (C-jk) sporadically? My vote is firmly in the former.

e: I actually remember having a similar conversation about this before: #1372 (comment)

At that time I deferred to popular decision, and simply adjusted my personal settings--still, this issue coming up again shows that it may need rethinking.

[syl20bnr]

I'm not for a solution that introduces potential new clashes, here is what we can do:

• in hybrid style, the insert state is the same as emacs state, any places where we consider the point to be in insert state must follow this rule consistently, this is the case for the minibuffer, hence for completion front-ends.
• we add style variables following the same pattern as layer variables, that is '(hybrid :variables hybrid-style-enable-hjkl-navigation t)
• we need a framework to handle these variables and still allow dynamic switching of editing style

So we don't introduce potential new clashes we just reuse the work done for the Vim users. Remember the analogy of a segment where Vim and Emacs are at the extremes, by default we place Hybrid near Emacs and introduce variables to move the Hybrid point toward the Vim point.

[nixmaniack]

@choppsv1 This can be closed I think as we have the tooling in place to get the desired behaviour in hybrid mode now. Or Fixed in develop label.

[duianto]

We'll close this, since the hybrid-style-enable-hjkl-navigation variable is available on the master branch.