Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"evil-search-forward" freezes emacs sometime in org-mode #3623

Closed
StreakyCobra opened this issue Nov 1, 2015 · 9 comments
Closed

"evil-search-forward" freezes emacs sometime in org-mode #3623

StreakyCobra opened this issue Nov 1, 2015 · 9 comments
Labels
Bug :-( Org stale marked as a stale issue/pr (usually by a bot)

Comments

@StreakyCobra
Copy link
Contributor

To reproduce:

  1. Open the *scratch* buffer: SPC b s

  2. Paste this line in it:

    [[path/is/problematic][link]] is problematic
    
  3. Change the buffer to org-mode: SPC : org-mode RET

  4. Search for is/ or path

Notice:

  • Doing the same but staying in fundamental-mode doesn't have this behaviour.
  • It appears when all the matches are only inside links' path.
  • If we search with evil-search-forward in fundamental-mode, then switch to org-mode, doing evil-search-next doesn't freeze.

So for now the rule seems to be: «Using evil-search-forward or evil-search-backward in org-mode for an expression which is only inside links' path, freeze emacs.».

It's probably an upstream bug, but as I'm not used to standard emacs enough to test it without spacemacs, I can't exclude it's a spacemacs bug. Maybe someone can try?

Bug reproduced on both master and develop fresh installs (vim mode at least), emacs 24.5.1.

@manfredlotz
Copy link

Some weeks ago I had opened issue #3338 which reported a freeze when searching for the word 'link' in the README.org buffer. Funny thing was that the freeze happened when opening the file via 'SPC f e h'. If later I repoen the file via 'SPC f e h' there is no freeze.

Don't know if this is the same thing.

@manfredlotz
Copy link

In issue #3338 I added an append because I found that emacs antialiasing might be the problem of the freezes.

@manfredlotz
Copy link

Would be interesting which font is defined in .spacemacs of StreakyCobra. In my situation (#3338) changing the font, and no freeze in the described situation (SPC feh and searching for link in README.org)

@manfredlotz
Copy link

Clarifying: As StreakyCobra said the problem shows up with 'emacs -nw' it has nothing to do with issue #3338.

@Alexander-Shukaev
Copy link

Profiler trace shows the following:

                   - isearch-search                             23604  91%
                    - isearch-filter-visible                    14667  56%
                       isearch-range-invisible                  12937  50%
                    + isearch-search-string                      8009  30%

If only I knew where to start debugging this...

@Alexander-Shukaev
Copy link

I think I've found a solution. Just want to note one thing. I'm not a spacemacs user and I also have completely reimplemented the evil-search module based on isearch as the original contained numerous subtle bugs. In fact, I have a large custom layer on top of evil which hooks certain parts of it, extends, replaces, or removes them completely. In future, I plan to fork and deprecate Evil entirely and release a new package to the public when I have more spare time (the idea is actually to produce a more generic and bug-free version of Evil). Anyway, since some of the code of this rewritten evil-search module is still in common, I also have these freezing issues. They were annoying me for quite some time now, so I decided to nail it. It looks like if you say

(setq-default search-invisible t)

the problem should be gone, at least it does for me. Give it a shot.

@Alexander-Shukaev
Copy link

emacs-evil/evil#843

@TheBB
Copy link
Contributor

TheBB commented Dec 19, 2019

Should hopefully be fixed when MELPA next packages Evil.

@Alexander-Shukaev It would be great if you could share your search improvements. :-)

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

@github-actions github-actions bot added the stale marked as a stale issue/pr (usually by a bot) label Dec 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug :-( Org stale marked as a stale issue/pr (usually by a bot)
Projects
None yet
Development

No branches or pull requests

4 participants