vi edit mode: the dot `.` character should not be part of the same set of characters as letters for describing a word

[sim590]

Bug report form

• I have done a basic search of the issue tracker to find any existing issues that are similar.
• I have checked that my version is at least the latest stable release available via my installation method.

Describe the bug

In Vi edit mode, if the cursor of the user is aligned on the letter a in the following example:

a.b.c

Pressing e will bring the user's cursor to the end of the word. Since Nushell's knowledge of a word is wrong, it will move the cursor to the letter c as if the user pressed E rather than e.

I think it is because the implementation of the Vi mode's concept of a "word" is not correct regarding the dot character.

Also, an interesting thing is that if the user's cursor is on the letter c and he then presses b to go to the beginning of the previous word, then he'll end up on the previous dot (one character to the left of c), which is correct.

There seems to be inconsistencies.

How to reproduce

N/A

Expected behavior

When in VI mode, using w, e, ge or b should jump between words relative to the cursor.

According to the Vim documentation,

A word consists of a sequence of letters, digits and underscores, or a
sequence of other non-blank characters, separated with white space (spaces,
tabs, ). This can be changed with the 'iskeyword' option. An empty line
is also considered to be a word.

The relevant part of the definition here is "other non-blank characters".

For e.g.,

a b c

This is 3 words while

a.b.c

this is 5 words as the two dots each count as a word. However,

...

This is a single word consisting of 3 times the character ..

Regarding the example given earlier with a.b.c. Pressing initially e when the cursor of the user is on letter a should bring the user's cursor to the first character ..

Configuration

key	value
version	0.109.1
major	0
minor	109
patch	1
branch	makepkg
commit_hash	cde5f7b
build_os	linux-x86_64
build_target	x86_64-unknown-linux-gnu
rust_version	rustc 1.91.1 (ed61e7d7e 2025-11-07) (Arch Linux rust 1:1.91.1-2)
cargo_version	cargo 1.91.1 (ea2d97820 2025-10-10) (Arch Linux rust 1:1.91.1-2)
build_time	2025-12-03 07:57:38 +00:00
build_rust_channel	release
allocator	standard
features	default, network, plugin, rustls-tls, sqlite, trash-support
installed_plugins	port_extension 0.109.1, secret 0.4.0
experimental_options	example=false, reorder-cell-paths=true, pipefail=false, enforce-runtime-annotations=false

[sim590]

Another notable example is the following:

...

According to Vim's documentation, this is a single word. So, if the user's cursor is on the first dot, pressing e should move the user's cursor to the third dot. However, right now, it moves the cursor on the second dot. In other words, it thinks that there are 3 words here even though there's only one.

[fdncred]

This has to be a duplicate issue. I've several people complain about this and yet we don't have a lot of people creating PRs to fix it. We really need a label just for VIM things. This is also probably a reedline issue vs a nushell issue.

[sim590]

This has to be a duplicate issue.

Probably. I was not able to find an issue that talked about it though. I might not be using the same words to describe the issue.

[fdncred]

or maybe it's not in the nushell repo. I can't remember but it's definitely a reedline issue.