Help debugging why evil-visual-char doesn't work

[RedPointyJackson]

Issue type

• Question

Environment

Emacs version: GNU Emacs 26.1 (build 1, x86_64-apple-darwin14.5.0, NS appkit-1348.17 Version 10.10.5 (Build 14F2511)) of 2018-05-31 Operating System: macOS Mojave Evil version: 1.2.14 Evil installation type: MELPA Graphical/Terminal: Graphical Tested in a make emacs session (see CONTRIBUTING.md): No

Reproduction steps

Start with an empty .emacs.d dir, and install evil. Then, evaluate

(add-hook 'term-load-hook (lambda ()
                            (setq-local transient-mark-mode nil)))

open eshell. Go to visual mode, it won't select any text.

The issue is not localized to eshell, it happens in other buffers too.

Expected behavior

You go into visual mode

Actual behavior

Nothing happens

Further notes

Trying to run M-x evil-visual-char doesn't work either. Strangely, evil-visual-block works. I tried toggling evil-mode off and on to no avail. The only way to 'recover' the expected behavior is to kill the buffer and reopen it. When this problem happens it's buffer-local, the other buffers can enter visual mode pressing 'v'.

The bug very difficult to reproduce, as it is not deterministic, except for the reproduction steps outlined. I tried limiting the number of extra packages installed in my emacs to pinpoint if any other extension may be interfering, but it didn't help.

Do you have any advice on how to debug the issue when it triggers? I tried debug-on-entry, but I don't find any clues on the output:

Debugger entered--entering a function:
* local-variable-p(evil-operator-state-local-map)
* evil-initialize-local-keymaps()
* evil-normalize-keymaps()
* evil-visual-state()
* evil-visual-make-region(nil nil inclusive t)
* (if (eq type 'exit) (evil-exit-visual-state) (setq type (or type evil-visual-char) evil-visual-selection 'char) (evil-visual-make-region mark point type message))
* (lambda (&optional mark point type message) "Characterwise selection." (interactive (list nil nil (if (and (evil-visual-state-p) (eq evil-visual-selection 'char)) 'exit evil-visual-char) t)) (if (eq type 'exit) (evil-exit-visual-state) (setq type (or type evil-visual-char) evil-visual-selection 'char) (evil-visual-make-region mark point type message)))(nil nil inclusive t)
* apply((lambda (&optional mark point type message) "Characterwise selection." (interactive (list nil nil (if (and (evil-visual-state-p) (eq evil-visual-selection 'char)) 'exit evil-visual-char) t)) (if (eq type 'exit) (evil-exit-visual-state) (setq type (or type evil-visual-char) evil-visual-selection 'char) (evil-visual-make-region mark point type message))) (nil nil inclusive t))
* evil-visual-char(nil nil inclusive t)
  funcall-interactively(evil-visual-char nil nil inclusive t)
  call-interactively(evil-visual-char nil nil)
  command-execute(evil-visual-char)

[VanLaser]

When it happens, you can try to see what the v key actually does at that moment, running C-h k v from the normal state. Maybe some package steals the binding?

[RedPointyJackson]

@VanLaser It's bound to the correct command:

v runs the command evil-visual-char (found in evil-motion-state-map), which is
an interactive Lisp function in ‘evil-states.el’.

It is bound to v.

(evil-visual-char &optional MARK POINT TYPE MESSAGE)

Characterwise selection.

[back]

[manveru]

I've also had this issue for months now. It's very hard to reproduce and easily fixed by getting rid of the affected buffer, which is why I never bothered tracking down the source of the issue.

But it would be awesome if it didn't happen :)

[manveru]

So, I managed to also fix this by calling evil-visual-state-exit-hook via M-:. My guess is that this is somehow related to the implementation of evil-define-state where sometimes the hook isn't being called, but I'm not familiar enough with the internals to say for sure how that happens.

[RedPointyJackson]

Just managed to get the problem in one buffer, the evil-visual-state-exit-hook trick didn't work for me.

[RedPointyJackson]

I found a way of constantly reproducing the bug, just evaluate

(add-hook 'term-load-hook (lambda ()
                            (setq-local transient-mark-mode nil)))

and open eshell. Visual won't work.

[joneshf]

I've run into this as well, from time to time. This latest time, evil-visual-char and evil-visual-line stopped working, but evil-visual-block continued to work. I dunno if that happens every time. Maybe that's useful information.

[joneshf]

I decided to try seeing if regex replace still worked. This what I did:

1. evil-visual-line on a line
2. evil-ex to start a regex
3. Execute the regex

evil-visual-char and evil-visual-line started working again without closing the buffer.

[joneshf]

Tried that again, it didn't fix it this time.

[toinfty]

I am using the evil-version (evil-git-0125af2be). This also happens to me occasionally, but I cannot find a way to reproduce...

[betaprior]

I see this breakage occasionally in Doom emacs, in evil-visual-line-mode. Manually evaluating (setq-local transient-mark-mode t) seems to fix it.

[jackkamm]

I see this breakage occasionally in Doom emacs, in evil-visual-line-mode. Manually evaluating (setq-local transient-mark-mode t) seems to fix it.

Thanks, this fixed the problem for me today!

Note, simply enabling/disabling transient-mark-mode globally did not fix it.

I have also been experiencing this problem for some time now. Usually it is fixed by killing and reopening the buffer, but sometimes not (it didn't today).

I am using my own custom Emacs config with evil (not doom or spacemacs).

[hraban]

I have the same problem, and I'd love to know how to debug it, too!

What consistently fixes it for me: getting help for the key. So when it's not working, I hit C-h k g j, it will in fact show the correct function, evil-next-visual-line (even though it wasn't working), and when I quit the help, suddenly g j works fine (it moves visual lines instead of logical ones).

How to debug this?

(fwiw, I have customized evil-respect-visual-line-mode t)

[vv111y]

I've run into this as well, from time to time. This latest time, evil-visual-char and evil-visual-line stopped working, but evil-visual-block continued to work. I dunno if that happens every time. Maybe that's useful information.

I have this as well in org-mode buffers which I use heavily. It seems to be random and intermittent; sometimes an org-mode buffer will get the problem after some period of time while evil continues to work normally in the other org-mode buffers.

Can confirm @betaprior hack works

[Sleepful]

It will be 3 years soon since this was opened 😭

The problem is very insidious, out of nowhere you are running a bunch of random commands because you thought you had highlighted the text but it didn't highlight and you are just pressing at your hotkeys, changing the text randomly, maybe sharing your screen and confusing all your spectators. "Hold on, I need to kill the buffer and reload it" you say, as you desperately jump around with your cursor.

A hack that fixes this automatically would be very welcome, hopefully I find some time to dig into it myself 😢

[tomdl89]

I think I fixed this. Merged to master. Lemme know if you observe otherwise.