This is a plugin that highlights all occurrences of the current word in the current view. The current word is defined as the string of characters that contains the cursor position and starts and ends with a character from the word_separators setting. The plugin also delays the search by 0.5 seconds, so on large documents it will not do the search on every keypress, which really makes it feel much more responsive. There is a highlight_word_theme_selector setting which defaults to comment. This allows you to customize the color of the highlighted words independently of other theme settings. (I used this because I wanted the highlighted words to be similar to search results, but just a little darker, so the theme selector helps).

This is my first plugin, I found the basic idea from a similar current word plugin but added a few features.

I had a few questions too though if anyone has ideas: 1. It looks like there is no way to stop a timeout or tell it to repeat. I worked around this, but it might be a nice thing to have? 2. Are there any threading issues that need to be taken care of in the timeouts? I haven't done this, but what I would like to do is to store a reference to a view object in an event handler, and then access it later in the timeout. Is that possible? 3. I tried to setup my theme to highlight the current word with a green background. For whatever reason, when I set the background key in the theme for that selector to green, it did nothing. When I set the foreground selector to green, it made the background green and the text of the word pink. I would really like the text to be white for some more contrast, can that be done? How? Is there a reason the foreground setting is used for the background?

Heh, nice to see you too. I figured it was time to switch, I start working on a linux box in 1 week and e still sucks on linux.

O yea, that's the one I tried at first. It wasn't too bad, but I could see the cpu usage going up which I didn't really like. I hate any lag at all in my editor. Also, it uses regular expressions, I think \b, to detect word boundaries, which I didn't like because I couldn't customize it. The settings file has a word_separators setting built in, so I opted to use that. That was something that always bugged me about how I implemented it in e. Also, that one styled them as comments, which in my theme made it really hard to see.

Interesting. I didn't go that route because of speed. I had considered something similar, but I didn't know exactly how the regex search was implemented. In particular, for each character of the document, it might have had to compare it to each of separator characters, so it becomes an m*n problem, but with a dictionary it guarantees nearly constant lookup, so it's just n. I'll benchmark it just for fun anyway, in theory the regex should be slower, but idk if it actually is.

With regards to #2, there aren't any threading with callbacks run from set_timeout: they're all run on the main thread. FWIW, set_timeout is the only threadsafe function to call in the API, calling other functions in a thread other than the main one will throw an exception.

Currently, the background color is extracted from the theme, and the foreground color is automatically generated to be a contrasting one. I'll make a change in in the next build so that if the theme explicitly provides both a foreground and background color for the given scope, then they'll be used as is.

It's very curious, on a 2.5 mb file, the regex took about 1.5 seconds to do 5 passes, but the non-regex option took about .17 seconds for most words, but on a word like NULL that occurs multiple times it took up to a full second to do 5 passes.

You have no clue how awesome it is to have the developer actually respond to a forum post. (I'm from e ) Thanks for adding that functionality though.

ajpalkovic wrote:It's very curious, on a 2.5 mb file, the regex took about 1.5 seconds to do 5 passes, but the non-regex option took about .17 seconds for most words, but on a word like NULL that occurs multiple times it took up to a full second to do 5 passes.

Thanks for doing the benchmark.Even if it's expected, it's useful to know that RE is way slower than a straight text search.

Since the text search find every occurrence of NULL and filter them after, I first thought that your test file have a lot of word composed with NULL, but except nullity and nullify I didn't see any others.How many occurrence of NULL in your test file ?

Well, it was a sql file, so NULL occurred a few thousand times in it. The regex doesn't have to do any extra processing on each match, so its performance is fairly consistent regardless of the number of matches, but find_all has to check the character before and after, so when it matches a ton of things it slows down. Neverthless, I am going to rewrite it to be fast and instant soon.

Basically, instead of using a delay, I do something far smarter. It is silly to do a search for the current word on the entire document every time as you are only looking at the visible region. So now I contain the search to just be in the visible region of the view. As you scroll and modify the document the search is done instantly. Since it is only working on the visible screen it is quite fast (< .2 seconds for 1000 searches on my machine), but the downside is that the matches aren't visible in the minimap.

Also, if you multiselect the same word, it will still highlight that word in the file. Before it would highlight nothing on multiselect.