Difference between Emacs and Vim on handling _ as word boundary

[Qqwy]

In Vim, _ is considered a word character. Soo foo_bar_baz is one word.

In Emacs, _ is considered a separate word alltogether. So foo_bar_baz is five words.

Now, the Unicode standard agrees with what Vim does, and this is also the behaviour I am used to from many different contexts (browsers, command-line interfaces, ritch text editors etc): In many applications, using Ctrl+arrow keys lets you skip back and forth to the beginnings/ends of words quickly.

Because in the end, evil-mode is not entirely like vim, it adheres to emacs' rules of word boundary choice, which means that using the w and b commands in evil-mode will give different results than when using them in command-line vim.

Now I'm not sure what the proper approach might be here; There are ways to override how _ works in most modes (see this stackoverflow answer), but this might not be a silver bullet solution:

• What to do in hybrid mode?
• What if a user is used to the emacs-style underscores ?

Maybe the best thing we could do is to add a configuration option in the .spacemacs for this?

[Somelauw]

What Vim calls a word, Emacs calls a symbol.
Maybe w (and others) could have been bound to evil-next-symbol instead of evil-next-word.

However, I like the Emacs definition of a word better now.

[olymk2]

I have this in my config to change the behaviour.

(with-eval-after-load 'evil
(defalias #'forward-evil-word #'forward-evil-symbol))

[sdwolfz]

I had this setup as well @olymk2 but it felt weird, so I got used to navigating by W, f 《char》 and /《search words》 which proved to be better overall.

Not saying it's a solution fit for everyone but navigating only with w, e and b felt slow for me after a while, and now incorporating all these movements, I no longer mind it being different than vim. Actually I find the current behaviour better, especially when navigating emacs lisp code.

[Alexander-Miller]

In Emacs, _ is considered a separate word alltogether. So foo_bar_baz is five

Thats not the full truth. Whether a character is treated is part of a word or symbol is determined by a major mode's syntax table.

At any rate I dont think adding something like this to spacemacs is a good idea. Changing syntax definitions opens up a gaping abyss of subtle, difficult to track & debug bugs since everything that uses syntax tables - from autocompletion to syntax highlighting - would be affected by such a change.

[CeleritasCelery]

As @Alexander-Miller said, it would be unwise for Spacemacs to change this. However nothing is stopping your from updating the syntax table for your desired mode(s) so that _ is not considered a word boundary. Also note Spacemacs has the text-object o which grabs the entire symbol, underscore included.

[rudolfkral]

Does that mean that the issue is decided and closed, as it is advised to update the syntax table instead of changing anything in Spacemacs?

[duianto]

@rudolfkral I don't have final say for if it is decided, but as alexander said, it would effect other things, so we'll close this.