Vi-normal mode f<char> doesn't work for period character

[aikow]

Platform: Manjaro

Window Manager: awesomewm

Terminal software: alacritty

Used with nushell

Problem

Trying to jump to the next or previous period character (.) does not work, even though jumping to all other characters is possible. With

open part_a.part_b.part_3.csv

typing f. in normal mode does absolutely nothing. I tested it with most other characters, and they all seem to work fine.

Also the word boundary definition for period seems to be very inconsistent as well, internally, and with vi and readline.

Given the above input navigating with w the jump forward word character puts the cursor into the following positions

open part_a.part_b.part_3.csv
^    ^                   ^^  ^

Readline stays consistent by jumping like this

open part_a.part_b.part_3.csv
^    ^     ^^     ^^    ^^

which is predictable. fish's vi mode has the different behavior again and jumps straight to each part like so

open part_a.part_b.part_3.csv
^    ^    ^ ^    ^ ^    ^ ^

Steps to reproduce

config.nu

let-env config = {
  edit_mode: vi
}

Solution

Adding a setting to allow users to configure their own word separators would be a nice feature.

[sholderbach]

The f. case is definetely a bug. It also seems to get stuck in the parser state machine. If somebody wants to pick that up, I think it is not too hard to solve. (Related issue that can be solved by lifting the dot into the full command parser instead of a special case, would be that the dot currently doesn't support multipliers)

For the word definition (if you consider particularly pressing maybe lift it to a different issue): In my research on different word definitions I came accross many inconsistencies like that (e.g. emacs evil mode disagreeing with vim. bash, zsh, fish all doing slightly different things also for the emacs bindings) As a result I for now settled on the Unicode Annex 29 word definitions (they consider snake_case a single word, if I recall basically UAX31 identifiers are vaild words) with a special case to jump over whitespace. In general we should strive to be relatively faithful to the precedent but there were a few annoyances we were able to solve with this definition (e.g. deleting separate special characters like the | without touching a preceding or following word that is not nice in some other line editors. #346)

[aikow]

My main complaint with the current word boundary definition is that numbers seem to count as a word boundary even if they are part of snake_case1word, which seems a bit unintuitive.

If you could point out the relevant files and methods, I could take a stab at trying to implement a fix for the state machine getting stuck.

[sholderbach]

Currently the . get's picked up by the overall key dispatch for vi mode: https://github.com/nushell/reedline/blob/117f13b005052acaa21e959755e56cb25a898ce1/src/edit_mode/vi/mod.rs#L58-L67

By the design of this match statement it should never flow further.

It could become a regular vi Command that doesn't require a motion.

Place to parse commands: https://github.com/nushell/reedline/blob/117f13b005052acaa21e959755e56cb25a898ce1/src/edit_mode/vi/command.rs#L5-L13

Here you would have to detect that it expects the ./RepeatLastAction command and emit the corresponding previous ones: https://github.com/nushell/reedline/blob/117f13b005052acaa21e959755e56cb25a898ce1/src/edit_mode/vi/mod.rs#L89-L103

[morzel85]

I'm on Nushell 0.67.0 and noticed the same problem with motions to letter b or w. For example fb doesn't move cursor from beginning of such string aaabbbccc to b (but fc would correctly move to letter c). Reedline must be getting confused with special meaning of word motions.

I've created separate issue for it because root cause is different: https://github.com/nushell/reedline/issues/473