Proposal: remap s to evil-avy-goto-char-timer by default?

[dalanicolai]

This might be nitpicking, but personally I prefer to 'suggest' better alternatives to users/to make Spacemacs more awesome.
Basically you can find the motivation/argument here.
So we can keep it mapped to substitute if prefixed with a number.

I read about evil-snipe and that is how I eventually found this motivation. I think for me personally, evil-avy-goto-char-timer is more useful than vim-seek. Also, I think vim-seek does not offer much more than just a normal buffer search (with two characters), it just saves you from pressing RET. Furthermore, evil-avy-goto-char-timer enables you to quickly jump to any location in any visual buffer.

On the other hand I do find SPC j j a bit too clumsy for such useful functionality.

Anyway, as this 'breaks' with default vim (only for s without prefix), I am first 'polling' here. Of course, we would document the difference and the motivation.

For users interested, it would look something like this:

(with-eval-after-load 'evil-commands
  (evil-define-operator spacemacs/evil-jump-or-substitute (beg end type register arg)
    "Change a character."
    :motion evil-forward-char
    (interactive "<R><x>\nP")
    (if arg
        (evil-change beg end type register)
      (evil-avy-goto-char-timer))))

(setq avy-timeout-seconds 0.3)

(evil-global-set-key 'normal "s" 'evil-avy-goto-char-timer)

[BenedictHW]

I have come to the same conclusion after using evil snipe.

1. I find that avy-goto-word-or-subword-1 with (setq avy-style 'words) to be faster
   (and less keystrokes) even than evil-avy-goto-char-timer. What is the general
   consensus between the two?

2. It turns out the S key is already overloaded. Spacemacs documentation under
   heading "Differences between Vim, Evil and Spacemacs". Its worth
   noting too that evil-surround-region is by default assigned to s and not S.
   So the precedent of breaking the default vim layout is already set by the s
   and , key. What my current config shows is

  (evil-define-key 'visual evil-surround-mode-map "s" 'avy-goto-word-or-subword-1)
  (evil-define-key 'visual evil-surround-mode-map "S" 'evil-surround-region)

But I would like to hear feedback from those who
use evil-surround a lot. Are those users convinced also that they use avy-goto
more than evil-surround? Or conversely would you rather avy replace evil-surround-region?

3. A secondary effect of using evil-snipe is that the valuable home row ; key
   is freed up (see `evil-snipe-override-evil-repeat-keys). It's possible syl20bnr feels the same, as per the recent commit here:
   b8621b7
   shows we may have the same kind of redundancy between

SPC m and ,
SPC p and ;
SPC j and s

merged into develop branch soon.

4. More considerations

Evil snipe should be moved out of its own optional layer and into the default
spacemacs-editing layer if this change goes through.

Say you record a macro to delete the first occurrence of x and y in a line. One
possible downside of the evil-snipe behavior is that f will now instead find
the 2nd occurrence of x. Niche, I know, but there are bound to be some downsides of
evil-snipes' new behavior.

Interested in hearing your thoughts,

Best,

[dalanicolai]

Thanks for the very useful comments!

I think evil-avy-goto-word-or-subword-1 only requires fewer keystrokes because it can only jump to the beginning of (sub)words. Using, evil-avy-goto-char-timer, one can jump exactly to any location, including spelling mistakes in the middle of some word. Also, evil-avy-goto-char-timer enables the option of providing a multiple char pattern, so that you can often type two or three letters to jump without having to wait for the labels.

Indeed, I've read this section about 'differences between vim, evil and Spacemacs' but I did not think of it in this context, so this is a very useful reminder/argument. Personally, I do use surround quite frequently, but I really would not mind to map it on S for consistency (i.e. having avy-goto on s).

Also, the comment about this proposal fixing the 'break' that the new role of ; introduces is very relevant. So although f will still be useful for jumping a single time, avy-goto could be a prefect replacement for the case of requiring to f-jump multiple times.

I do not understand your point in 4 because it seems it is about evil-snipe, not about avy-goto.
Although the comment about the use in macro's is still relevant, I think using a normal search / instead is already a perfect/better alternative for that use case.

[BenedictHW]

Lol we can't be the only ones who felt the need to rebind SPC j j, so cheers
for the idea. Just for the record, the above mentioned redundancy does save me countless
(? may need keyfreq to confirm) keystrokes, so I am very much in favour.

Regarding avy-timer vs avy-goto-word, I prefer (1) over (2), but its not a
hill I'm willing to die on. For the use case of jumping to the middle, I like to
combine avy-goto-word with f/t. I find it to be a similar number of
keystrokes with a bit less mental load and more flexibility thanks to f/t. I
agree either are preferable to the status quo.

Evil-surround on S would be less work/breakage than finding a new binding for it. I
only found out now about g S through C-h b though.

About point 4, yeah no that's my bad, it's not strictly related. If
syl20bnr will subsume ; repeat functionality for project scope, I'm assuming
he uses repeated f=/=t. So maybe he will then make evil-snipe part of a
default layer? And if that's the case, then the evil=snipe README already
binds s/S to evil-snipe-s/S. Don't want to assume too much lol. He might not
rely on all the behavior evil-snipe pulls in, or even use said package.

Yeah a normal / search is a better alternative. It's just that I bound
helm-swoop to replace the regular search on / :D . This frees up ? as well!
But I'm going to stop myself here. The original macro point is not
too relevant.

And I forgot to point this out, but I do like your suggestion of adding prefixes
to s/S to retain substitute behaviour.

I've spilled too much ink over this already, but your proposal gets two thumbs up from me! And
thanks for your contributions to Spacemacs. Not like me, I'm all talk and no
code lol.

Cheers,