Invalid matching
adamczykm opened this issue · comments
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.
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?
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.
Very strange. What major mode does this occur in?
I'm using spacemacs. It occurs in all of the major modes.
Hmm, I'm getting exactly the same problem too (Spacemacs user as well). After pressing M-d four times on "Interrupt", it looks like:
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.
@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.
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!
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...
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.
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!
Amazing! It's now working just perfectly.
Though I saw 2 errors when downloading and compiling from github:
- "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.elcis not present) - "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)
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?
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.
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.