t9md / atom-vim-mode-plus

vim-mode improved

MIT License

1.4k stars 111 forks source link

Find `f`/`F`/`t`/`T` and replace `r` are broken when Soft Wrap Hanging Indent is set #869

Closed intrepidcoder closed 7 years ago

intrepidcoder commented 7 years ago

When Soft Wrap Hanging Indent is set for the plain text language, the find motions (f/F/t/T) and the replace command (r) are broken. This behavior is observed for all language types, not only plain text.

Demo

vim-mode-plus-bug

Minimal config.cson to reproduce

".plain.text":
  editor:
    softWrap: true
    softWrapHangingIndent: 4

Removing softWrapHangingIndent: 4, fixes the problem.

Output of atom --version:

Atom    : 1.19.7
Electron: 1.6.9
Chrome  : 56.0.2924.87
Node    : 7.4.0

vim-mode-plus version 1.3.3
My OS is Debian linux (Linux localhost 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64 GNU/Linux)
I reproduced this on a clean install of atom with VMP as the only installed package.

t9md commented 7 years ago

Broken how? Cannot get it from GIF. Need short explanation sentence.

intrepidcoder commented 7 years ago

Here is an explanation of the actual behavior:

The f command moves the cursor one character right (acting like l), and F moves it one character left (acting like h) without waiting to accept the second character to search for. The t and T commands do absolutely nothing.
The r command deletes the current character, but instead of waiting to accept another character to replace the current one, it replaces the current character with a newline. For example, pressing r when the cursor is on 3 in the line 123456 would result in the text
```
12
456
```
with the cursor on the 4.

t9md commented 7 years ago

I tried, but could not reproduce.

I set softWrapHangingIndent to 4. And tried with and without softwrapped text. But I still can use r and f without any issue.

When you can repro issue, the line your cursor is on is wrapped?

I'm macOS user btw.

intrepidcoder commented 7 years ago

When you tried, did you set softWrapHangingIndent in the global editor settings? Because that does not cause the issue for me; it only happens when softWrapHangingIndent is set specifically for the plain text language. Can you trying using the exact config.cson file I included?

".plain.text":
  editor:
    softWrap: true
    softWrapHangingIndent: 4

It does not matter whether the line the cursor is on is wrapped or not.

I was able to reproduce the issue on both Debian Linux and Windows, but I don't have access to a Mac.

t9md commented 7 years ago

Thanks! I could repro. Setting softWrap and softWrapHangingIndent in .plain.text grammar affects all behavior of f and r in other grammar. This is because mini-input editor's grammar used in f and r input is text.plain.null-grammar.

I think I can fix this easily will check from now.

t9md commented 7 years ago

editor.onDidChange fired with empty text without any keytype(initial focus) if “softWrap and softWrapHangingIndent > 0”.

Disabling softrwap on mini-editor did not help to solve this issue.

Not sure this behavior is bug or not.

I can avoid this unwanted event triggering by using different event(editor.buffer.onDidChangeText).

t9md commented 7 years ago

Will release as v1.4.0 maybe this week.