prevent evil-change-whole-line from deleting the line + newline

[mattsawyer77]

What are you trying to achieve? It seems that, in normal mode, c c (evil-change-whole-line) used to clear the current line and place the cursor at the correct indentation column in most languages (can't say which?). I find that now this function deletes the current line and its newline, such that the line below is now moved up. I can't figure out if this is intended behavior, or something gone awry in my config -- though my elisp skills are mostly non-existent so I'm not sure how to troubleshoot.

What have you tried? Tenaciously searching around for similar issues or complaints has revealed nothing, which makes me wonder if I've caused this issue on my own. I've looked for functions, variables, etc. that seem to relate to evil-change behavior but haven't found anything.

simple repro:

1. create a new buffer
2. enable shell-script-mode
3. enter the following content:

   #!/bin/bash
   
   function hello() {
       echo "hello world"
   }
   

4. navigate to the line with the echo
5. from normal mode, press c c. now the buffer looks like this:

   #!/bin/bash
   
   function hello() {
   }
   

   and the cursor is right before the closing bracket -- but I'd expect there to be a blank line between the brackets and the cursor to be indented.

System information here is the info from my linux machine, though I'm seeing the same behavior on my Macbook which is running emacs 26.3.

emacs   version    26.1
        features   SOUND GPM DBUS GSETTINGS NOTIFY ACL GNUTLS LIBXML2 ZLIB GTK3 X11 THREADS LIBSYSTEMD
        build      Jun 04, 2018
        buildopts  (--without-xpm --without-jpeg --without-tiff --without-gif --without-png --without-rsvg --without-lcms2 --without-imagemagick --without-xft --without-libotf
--without-m17n-flt --without-toolkit-scroll-bars)
        windowsys  nil
        daemonp    server-running
doom    version    2.0.9
        build      HEAD -> develop 12094788d 2020-01-14 03:04:26 -0500
        dir        ~/dotfiles/doom/
system  type       gnu/linux
        config     x86_64-pc-linux-gnu
        shell      /usr/bin/zsh
        uname      Linux 5.4.8-arch1-1 #1 SMP PREEMPT Sat, 04 Jan 2020 23:46:18 +0000 x86_64
        path       (~/.zplugin/plugins/junegunn---fzf-bin ~/.zplugin/plugins/vim---vim/src ~/.cargo/bin node_modules/.bin ~/.nvm/versions/node/v10.8.0/bin ~/.cargo/bin ~/.tmuxifier/bin
~/.fzf/bin ~/.local/bin ~/.cabal/bin ~/gocode/bin ~/Library/Python/2.7/bin /usr/local/opt/curl/bin /usr/local/bin /usr/local/sbin /usr/bin /bin /usr/sbin /sbin
/usr/local/libexec/emacs/26.1/x86_64-pc-linux-gnu)
config  envfile    envvar-file
        elc-files  32
        modules    (:completion (company +auto) ivy :ui doom doom-dashboard workspaces hl-todo modeline treemacs (popup +all +defaults) unicode vc-gutter window-select :editor (evil
+everywhere) file-templates fold multiple-cursors rotate-text :emacs dired electric vc :tools eval (lookup +docsets) docker editorconfig :checkers syntax :tools magit rgb terraform lsp
:term term :lang data emacs-lisp go haskell javascript lua markdown nix (org +attach +babel +capture +export +present) purescript python racket rust sh web :config (default +bindings
+smartparens))
        packages   (yasnippet doom-modeline exec-path-from-shell prettier-js evil-leader evil-nerd-commenter hindent transpose-frame nginx-mode default-text-scale darktooth-theme
base16-theme hemisu-theme mustache-mode golden-ratio lsp-mode lsp-ui company-lsp company-go vmd-mode evil-terminal-cursor-changer highlight-indent-guides (ormolu :recipe (:host github
:repo "vyorkin/ormolu.el")) fzf dhall-mode manage-minor-mode toml-mode company-nginx lsp-haskell hlint-refactor)
        elpa       (n/a)

[hlissner]

I cannot reproduce this behavior. If it did behave this way it would certainly be a bug, however.

Two things jump out at me in your doom/info:

1. You're on 12094788d (roughly two weeks behind HEAD)
2. You have 32 elc files in your config; this could potentially mean stale byte-code. doom clean will clear them out

Try to update Doom, your packages and see if the issue goes away (with doom upgrade).

[hoyon]

I've had the same problem for a while now as well and it is pretty annoying. I've briefly looked into it in the past and couldn't find why it was happening. Deleting ~/.emacs.d/.local and reinstalling doom doesn't seem to fix the issue either.

My config is available here: https://github.com/hoyon/dotfiles/tree/master/doom-emacs/.doom.d in case I've done something crazy and my doom info is:

emacs   version    28.0.50
        features   XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GLIB NOTIFY INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ LIBOTF ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON PDUMPER LCMS2 GMP
        build      Jan 16, 2020
        buildopts  (--prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games --with-sound=alsa --with-modules --without-gconf --without-gsettings --enable-link-time-optimization --with-x-toolkit=gtk3 --without-xaw3d --without-m17n-flt --with-cairo --without-compress-install 'CFLAGS=-march=native -O2 -pipe -fstack-protector-strong -fno-plt -g -flto -fuse-linker-plugin -s -fuse-ld=gold' CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now)
        windowsys  x
        daemonp    server-running
doom    version    2.0.9
        build      HEAD -> develop, origin/develop c6518498b 2020-01-28 14:07:08 -0500
        dir        ~/.dotfiles/doom-emacs/.doom.d/
system  type       gnu/linux
        config     x86_64-pc-linux-gnu
        shell      /usr/bin/fish
        uname      Linux 5.4.15-arch1-1 #1 SMP PREEMPT Sun, 26 Jan 2020 09:48:50 +0000 x86_64
        path       (~/.cargo/bin/ ~/bin ~/.local/bin ~/.yarn/bin ~/.nimble/bin /usr/local/bin /usr/bin /bin /usr/local/sbin /usr/lib/jvm/default/bin /usr/bin/site_perl /usr/bin/vendor_perl /usr/bin/core_perl /usr/lib/smlnj/bin /usr/lib/emacs/28.0.50/x86_64-pc-linux-gnu/)
config  envfile    envvar-file
        elc-files  0
        modules    (:completion company ivy :ui doom doom-dashboard doom-quit hl-todo modeline nav-flash ophints (popup +all +defaults) treemacs vc-gutter vi-tilde-fringe window-select workspaces :editor (evil +everywhere) file-templates fold multiple-cursors rotate-text snippets :emacs dired electric ibuffer vc :term eshell :checkers syntax :tools (eval +overlay) (lookup +docsets) magit terraform :lang cc clojure data elixir elm emacs-lisp lua markdown (org +dragndrop +present) rest rust (sh +fish) web :config (default +bindings +smartparens))
        packages   (reason-mode geiser evil-terminal-cursor-changer nim-mode (ox-pandoc :disable t) (rtags :disable t :pin "92c5126e98"))
        elpa       (n/a)
        unpin      (n/a)

[mattsawyer77]

(@hoyon glad I'm not the only one) I pulled the latest develop branch, did git clean -xdf and rm -rf .local, then bin/doom install. That didn't help. Then I tried disabling/commenting packages and config that looked even remotely related. But I still see the behavior.

@hlissner any recommendations for debugging?

[mattsawyer77]

FWIW I went through the troubleshooting steps in the evil project, and found that c c works correctly in an emacs with only evil-mode installed.

[mattsawyer77]

found another data point: this problem doesn't occur in text-mode. Then after enabling prog-mode, the problem reappears.

[mattsawyer77]

Eureka: this seems to be caused by a bug in visual-line-mode: https://github.com/emacs-evil/evil/issues/1168

workaround until that's fixed: set evil-respect-visual-line-mode to nil.

[hlissner]

Understood. I'll keep this open until it is resolved upstream. (And will be defaulting evil-respect-visual-line-mode to nil soon)

[hlissner]

Since I can't reproduce the original issue (and evil-respect-visual-line-mode is just so darn nice), I have re-enabled it. Let me know if more issues arise.

[lunik1]

There is more discussion upstream at emacs-evil/evil#188 on the limitations of evil-respect-visual-line-mode.

[hlissner]

And, of course, the issues emerge again. Until they are addressed upstream they can be side-stepped by adding this to ~/.doom.d/init.el:

(setq evil-respect-visual-line-mode nil)

I'll contemplate making this Doom's default (again).

[benneti]

thank for pointing out that it has to go in init.el, tried it before ignoring that it needs to be set before evil is loaded. I guess that documenting it could be sufficient as only some modes are affected.

[Stefanomarton]

Kind of necro bumping but for anyone interest I found a filthy workaround using general.el package.

(use-package general
  :after dashboard
  :config
  (general-evil-setup t)
  (general-nmap "c" (general-key-dispatch 'evil-change
                      "c" 'my-evil-change-whole-line))
  (general-vmap "c" 'evil-change))

The end result is the same as expected behaviour but work nice with visual-line-mode

[jcf]

This slightly modified workaround is working for me. Thanks, @Stefanomarton!

(after! general
  (general-evil-setup t)
  (general-nmap "c" (general-key-dispatch 'evil-change
                      "c" #'evil-change-whole-line))
  (general-vmap "c" #'evil-change))

If I encounter other issues, I'll loop back.