Issue #174 resolved

Updating of highlighted search

created an issue

I find the highlights for my searches with evil-search don't update as I'd expect. Examples:

• Search on a term that appears throughout file. Hold {{{j}}}. Search terms will scroll in and out of view without becoming highlighted.

• Search for foo: {{{/foo}}}. Put point over "f", {{{x}}} to delete it. oo remains highlighted. Moving around with {{{j}}}, {{{k}}} doesn't update the highlighting.

• Similarly, inserting text before "foo" creates incorrect highlighting. {{{i}}}, type "baz", now "bazfoo" is highlighted.

• In Vim, if I search and replace (with {{{:1,$s/old/new/g}}}), then undo, the "old" string is highlighted. Evil doesn't do that. In Vim I liked this for verifying complex search and replace operations.

• Similarly, in Vim, a search and replace would use the new search term for further {{{n}}}, {{{N}}}. So {{{:1,$s/old/new/g}}}, then {{{n}}} would go to instances of "old".

Comments (7)

  1. Frank Fischer repo owner
    • changed status to open

    I assume you use evil's own interactive search module and not Emacs isearch, is that correct?

    I try to answer each of your points:

    1. scrolling the window should update the highlight (and in my tests it does, starting with make emacs). If this does not happen, please try to give a way to reproduce it
    2. that's right, changing highlighted text does not change the highlight. This can probably be solved using some overlay tricks. But as in the previous issue the highlight should be updated when the buffer is scrolled (in fact, scrolling causes an update of the highlights in the current visible area of the buffer via some timer)
    3. the same as 2.
    4. evil uses different independent patterns for search and replace. Probably I've been a little bit confused with vim's doc and certain flags for the :s command like r and so on, that seem to distinguish between that last "search-pattern" and the last "substitute-pattern" - maybe this needs a rework (perhaps a substitute should update both, the last search pattern and the last substitute pattern and a search should update only the last search pattern). But note that currently "undo" would probably not update the highlighting, currently only scrolling the window does this. Maybe buffer modifications should do the same (restart the highlighting I mean, perhaps with a reasonable large/small timer - usually I'm not a friend of doing expensive stuff after each single buffer modification, and updating the highlight is relatively expensive because it requires searching for the pattern in the buffer again; although in the case of buffer modification a better locality of the updating may be possible, but certainly not trivial to implement).
    5. see 4.
  2. epich reporter

    Yes, I used evil-search.

    Since you mentioned it updates highlights on a timer I thought that might explain issue 1. I found evil-ex-hl-idle-update sets the timer and I changed the hardcoded update delay from 0.1 to 0.01. Issue 1 no longer occurs with that change. Perhaps it comes down to the desktop environment's setting for repeating a key which is held down? Is the right approach to make the timer delay a defcustom?

    Thanks for your thoughtful answers on the other points.

  3. Frank Fischer repo owner

    using defcustom is ok, using setq is another option, use whatever you prefer.

    To your question: I don't know for sure, but I think you're right. Currently the timer is restarted when the window is scrolled, so if the scrolling is faster then the timeout, nothing will happen. Perhaps a different approach is appropriate. I'm quite sure that the updating could be done more accurately especially in the case of scrolling when the buffer content does not change. So, another item on the TODO-list ;)

  4. Log in to comment