In subword-mode, `w` navigation stops moving forward on the first line

[duianto]

Description

A specific order of upper and lowercase characters like: ACoupleOfCamelCaseWords, on a buffers first line causes the cursor to stop moving forward when w is pressed, while subword-mode is enabled.

Steps to reproduce

1. Start Emacs + Evil or Spacemacs
2. Open a new buffer C-f b, type: new, press RET
3. On the first line of the buffer type: ACoupleOfCamelCaseWords
4. Move the cursor to the first A
5. Enable subword mode M-x, type: subword-mode, press RET
6. Press w

Observed behavior

The cursor jumps to the e in Couple. Then nothing happens when w is pressed again.

Expected behavior

The cursor shouldn't stop moving forwards.

Notes

If one moves the cursor forward one character l then w continues moving forward. But if the cursor is anywhere before the e in ACouple then the cursor jumps to and stops at the e.

The same thing happens with: AAAAAaaaaaaaaaaaAaa. The order of upper and lowercase characters seems to be: Two or more uppercase characters at the start, then one or more lowercase characters followed by an uppercase character.

The cursor stops on the last lowercase character before the third uppercase character. It doesn't seem to matter how many lowercase a's there are, a quick test with 3360 a's caused the same thing to happen.

It only happens on the buffers first line, if the same word/characters are on any other line, then w keeps moving forward as expected.

Tested

This happens with just Emacs and the Evil package and in Spacemacs:

System Info :computer:

• OS: windows-nt
• Emacs: 25.1.1
• Spacemacs: 0.200.7
• Spacemacs branch: develop (rev. 3072e727)
• Graphic display: t
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers:

  (helm auto-completion emacs-lisp git)

• System configuration features: XPM JPEG TIFF GIF PNG RSVG SOUND DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS

[TheBB]

I'm afraid I can't reproduce this. It works with make emacs from the root of this repository, as well as my Spacemacs setup.

[duianto]

I just tested it with these versions: emacs-25.1-2-i686-w64-mingw32.zip (the latest version from gnu.org) emacs-25.1-i686-w64-mingw32.zip

and this one that i use on a daily basis with Spacemacs: emacs-w64-25.1-O2.7z (64-bit GNU Emacs for MS Windows with optimization.)

The issue occurs in all of them.

I also had an older version: emacs-24.5-bin-i686-mingw32.zip but when i call: M-x (require 'evil) then it complains that: Debugger entered--Lisp error: (void-function cl-struct-define) when i try to enable evil-mode: M-x evil-mode then the modeline shows <N> but the keys i tested said that they were undefined: i, j, k, so i'm not sure if it also happens with this older version.

A quick test seems to indicated that the issue is in the evil-forward-beginning function. repeating: M-x (evil-forward-beginning 'evil-word 1) The cursor (indicated with []) jumps from: [A]AaaaaaaaaaaAaaAAaaaA to: AAaaaaaaaaa[a]AaaAAaaaA and stops.

evil-forward-beginning calls the command forward-thing, but when it's called directly: repeating: M-x (forward-thing 'evil-word 1) causes the cursor to stop where one would expect. from: [A]AaaaaaaaaaaAaaAAaaaA to: A[A]aaaaaaaaaaAaaAAaaaA AAaaaaaaaaaa[A]aaAAaaaA AAaaaaaaaaaaAaa[A]AaaaA AAaaaaaaaaaaAaaA[A]aaaA AAaaaaaaaaaaAaaAAaaa[A]

It's the same places where the w key stops, when that example is on any other line than the first.

[wasamasa]

Make sure you have the latest version of Evil installed. What make emacs basically does is running Emacs with Evil loaded from the Git repository, so to make sure it's an outdated bug, please confirm whether it still occurs for you in a more recent one.

[duianto]

It still happens with the latest version: evil-20170219.629

[TheBB]

That's a MELPA versioning scheme. Could you try make emacs please.

[duianto]

Oh sorry, where do i type that?

[TheBB]

In the terminal, in the root of a fresh clone of this repository:

git clone https://github.com/emacs-evil/evil
cd evil
make emacs

[ninrod]

cannot reproduce on emacs+evil. using Centos7. tested on Gui emacs and terminal emacs. latest evil from git HEAD.

[duianto]

Terminal is a linux/mac application, but I'm using windows 10.

However i found that there's bash on ubuntu on windows. I installed it, git, make and emacs. Then i cloned evil, navigated to the evil folder and ran: make emacs This is the output:

emacs -Q -L . -L lib -l goto-chg.el -l evil-tests.el \
--eval "(evil-mode 1)" \
--eval "(evil-tests-initialize '() '() t)" &

it stops with the cursor blinking under this message: emacs: standard input is not a tty

I've only searched for about an hour, but i haven't been able to find a a way to get past it.

[ninrod]

@duianto may I add the info that I'm also using windows, but I'm running emacs inside a docker container inside a vagrant box through virtualbox piping the interface through an X-server (cygwin x-server).

this error "not a tty" is ocurring because your terminal is not a properly configured terminal.

[duianto]

The tty issue might have been solved in the windows insider builds, but currently i'm only using the final releases. Some rumours are saying that the next release: Creators update, might arrive in march (earliest), or july (latest).

@ninrod you said that you're also using windows, could you test if this subword-mode w navigation issue also occur for you. Then we can see if it's just a windows issue.

[ninrod]

I use windows but really just to run virtualbox->vagrant->docker and then a centos image piped through cygwin x-server. I have no issue with subword-mode in this configuration. But it saying I use windows is really not true because this is really a unix configuration.

[duianto]

I tested this issue on another windows 10 computer with emacs 25.1 and evil-master.zip (the latest version as of yesterday 20170223), and the same thing happens, w stops jumping forward, on the first line.

I also tested it with two linux distributions, through virtualbox:

debian 8.7 jessie
gnu emacs 24.4.1 (x86_64-pc-linux-gnu, gtk+ version 3.14.5) of 2015-03-07 on trouble, modified by debian
evil-git-5d040cd

and

lubuntu 16.04 lts xenial
gnu emacs 24.5.1 (i686-pc-linux-gnu, gtk+ version 3.18.9) of 2016-04-17 on lgw01-36, modified by debian
evil-git-5d040cd

I cloned the evil package and ran make emacs from the evil folder like TheBB suggested. It asked if i wanted to run some tests, which i did, in both cases the result were: 181 passed, 0 failed, 181/181 total

However w doesn't stop on subwords in subword-mode, it jumps over subwords like this: camelCaseWords. But M-f and M-b does stop on subwords, so it seems like subword-mode is working.

This might not have anything to do with w not stopping on subwords for me in linux.

But I noticed that in Emacs 24, in both linux and windows, the M-f key binding calls subword-forward when subword-mode is enabled, but it calls forward-word when subword-mode is disabled.

In Emacs 25 (only tested on windows) M-f calls forward-word in both cases, it seems like subword-forward might have been integrated into forward-word.

[justbur]

I can reproduce the problem without using evil functions. With subword-mode on (bounds-of-thing-at-point 'word) in the word "Couple" returns nil. The problem seems to be that there is a problem with how forward-word works.

1. Start with (point is [ ])

   ACoupl[e]OfCamelCaseWords

2. (forward-word 1)

   ACouple[O]fCamelCaseWords

3. (forward-word -1)

   [A]CoupleOfCamelCaseWords

4. (forward-word 1)

   A[C]oupleOfCamelCaseWords

   So the sequence end of word, beginning of word, end of word lands you at a position that is before the starting position.

This only happens on the first line of the buffer for me. If you do the same test on line 3, 4 gets you

ACouple[O]fCamelCaseWords

and (bounds-of-thing-at-point 'word) returns a non-nil value.

This is on

GNU Emacs 25.1.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.22.4) of 2016-12-15

[wasamasa]

Ah, that explains why nobody could reproduce it from make emacs: It gives you a buffer with a few lines filled in, as opposed to an empty buffer where you insert a single line and have it fail.

Not sure whether this is completely unrelated to Evil as w calls evil-forward-word-begin calls evil-forward-beginning which has a workaround for a buffer without a trailing newline. Perhaps it's time for another workaround?

[TheBB]

I'll admit I didn't even notice that the original bug report does state that it needs to be the first line in the buffer.

[ninrod]

Ok, now I can reproduce, using the first line of the buffer.