Invalid matching

[adamczykm]

There's something wrong with matching functions: instead of matching current word and then next, it matches first and then only a whitespace after another word.
I'm using config provided in the readme.

[hlissner]

I'll investigate, but in the meantime could you offer exact steps to reproduce the problem, including what function names you're trying to match and where the point is?

[adamczykm]

Sure. I'm using match-and-next function. In the code below > will mean beginning of matched region and < the end, and | will denote the current position.
Let's say we have the following text:

|import sth1
import sth2
import sth3

After using the function just once I got a valid result, which is:

>|import< sth1
import sth2
import sth3

But after using it 2 more times:

>|import< sth1
import> <sth2
import> <sth3

Weird.

[hlissner]

Very strange. What major mode does this occur in?

[adamczykm]

I'm using spacemacs. It occurs in all of the major modes.

[dp12]

Hmm, I'm getting exactly the same problem too (Spacemacs user as well). After pressing M-d four times on "Interrupt", it looks like:

[hlissner]

How frustrating! I can't reproduce it in vanilla emacs, so something in the spacemacs stack must be interfering. I'll install spacemacs over the weekend and see if I can figure it out.

[JJPandari]

@adamczykm @dp12 @hlissner I've just updated to the recent-released spacemacs 0.200.0, and found out this issue has magically disappeared. Cheers! 😆
edit: Wait, there's still a minor problem: if I want to match a word or symbol, either starting at normal-state or visual-state, everything works fine. However, if I want to match a region that's not a word or symbol, match-next and match-next-symbol says no more matches(but match-all correctly matches all ocurrences, so does it in prior versions of spacemacs when match-next malfunctions). But compared to before I updated spacemacs, evil-multiedit is working almost perfectly, so I can live with the current situation.

[hlissner]

I believe this is because evil-multiedit-scope defaults to visible, meaning it doesn't look past the visible buffer to find matches. match-all ignores this variable

I have changed its default to nil, which should fix the issue!

[JJPandari]

When I tried to match arbitrary regions, I had multiple matches on my screen, but match-next said "no more matches".
Also, I'm not sure if the change on default value you just made will cause confusion to heavy evil-multiedit users 🤔
Don't bother to fix it if the solution is not really obvious, the current situation seems good enough...

[hlissner]

It was effectively nil before I introduced evil-multiedit-scope in the first place, so it seemed better that it stay nil. However, I have a better solution in the pipeline (to have the cursor jump to each new match), which will make this new default make more sense.

[hlissner]

Bam, big update posted. This rewrite has turned out to be more reliable -- it may need some testing, but it should fix your problem. Let me know if it does!

[JJPandari]

Amazing! It's now working just perfectly.
Though I saw 2 errors when downloading and compiling from github:

1. "evil-multiedit.el:67:1:Error: Cannot open load file: no such file or directory, evil. Compiling no file at Tue Oct 11 15:46:22 2016"(so evil-multiedit.elc is not present)
2. "gnutls.c: 0 fatal error: The TLS connection was non-properly terminated."(I'm new to emacs and have no idea what this error means)

[hlissner]

Odd, these seem to be a package.el issue. Are you sure evil is installed? Perhaps try to uninstall evil-multiedit completely, then reinstall it?

[JJPandari]

Tried again on my home computer(was on work when I wrote last message), same errors ocurr. Reinstalled, still the same. Evil is installed.
I recompiled all elcs with a spacemacs function, evil-surround(requiring evil 1.2.12) compiles fine, evil-multiedit(requiring evil 1.2.8) still failed.

[dp12]

I also encountered syl20bnr/spacemacs#8885 in spacemacs when the c-c++ layer was enabled, which broke evil-multiedit and iedit.

Doing (setq ggtags-highlight-tag nil) fixed it.