the Prototype version should be updated as well. Both implementations should be kept in sync feature-wise

@stof hey man, I've just updated the code with your recommendations! :)

I tried your jquery file and on many case I had <em> parts appearing randomly in the text. especially when I erased part of my search. You may want to strip <em>s at the beginning of the function and add them back when you do the highlighting.

@p-j hey, man! I'm not being able to reproduce your problem. Could you provide an example?

@eliasdorneles, I whas not able to repro with your script only. Sorry for the false alarm.
I'm actually unable to repro in the exact same condition where yesterday I was 100% of the time.. I don't get it...

@stof hey, man! Is there something else that is missing for this to go upstream?

Just thought I should mention that I've been using this branch for a while now and it works really well. I, personally, haven't noticed anything wrong with it. It would be nice to have this in the core repository although I would imagine it would have to be behind a flag for backwards compatibility.

This version is working great!
I think in some cases chosen is not usable without fuzzy search.
Please add it to the master branch!

I can't say when or if this would be merged, but can you please at least a.) rebase against master, and b.) squash this into one (or a few) logical commit(s) to remove a lot of the leftover dev-cycle cruft in the commits? Things like 5e809cb and d806b34 and d6f3a81 should be squashed out of the history.

Directions here if you're unfamiliar.

@tjschuck thank you for the directions -- I'm not familiar with rebase yet, I'll give a try.

@tjschuck well, I was able to squash it into one commit only -- that should make the revision a bit easier.
I'm not sure if I'm the right person to merge them into the current master, as there has been a lot of new commits in the recent months and I haven't had time to keep up.

@eliasdorneles If you rebase against master, you should then be up to date with what's happened there. Looking at https://github.com/eliasdorneles/chosen/commits/master, it appears that you're still quite a bit behind.

Well, I meant to say that it was not that simple to rebase because the upstream code had several conflicting changes that were made after my initial pull request, and I had't been able to keep up.
So, today I redid the work against the current code base and cleaned up the code a little bit, I believe now it is easier to review it. :)

Can someone please take a second look at this patch?
Or otherwise, le me know if there is a way I could package it so people can use it as an extension of vanilla Chosen?
Thanks, guys!

I think the highlighting logic is flawed if you are searching for foo foobar as highlighting foo will find places already highlighted for foobar.
And I think it gets even worse when searching for r</e foobar (and as the search string comes from the user, there is no guarantee about what you get).

@stof thanks for the review, man -- I'll try to fix these.
I'm not sure about the problem with the search for r</e foobar, because that string only gets replaced if it matches with the option label. Considering this, do you think it is a problem still?

@stof hey, man! I've added a new commit fixing the stuff you pointed out.

Also, I've tested the behavior of the highlighting with the search queries you mentioned and they seemed to work fine.
I've added to my local tests an option like this:

<option value="foobar">r&lt;/mark&gt; foo foobar</option>

What I found was:

1. Searching for </mark> does not causes an issue because get_search_text() returns the search text already escaped. :)
2. Searching for foobar foo ends up highlighting foo inside foobar indeed, but the nested <mark> tags do not affect the behavior.

If you really think it's worthwhile, I can try coming up with some algorithm to avoid the nested highlighting but as it doesn't affect the behavior, I hesitate to add more code to this with potentially more bugs -- it is simpler as it is.

I tried implementing fuzzy search using a single regex, which works but then its not possible to highlight the matches.
Anyway, I do think we're going to need unit tests for this functionality. Maybe you can use the tests in my branch as a start: https://github.com/koenpunt/chosen/commits/jasmine-tests

@koenpunt Before adding specs, it would be easier to merge the PR adding the runner first so that they can be used

bump - what's up with this? Over a year old, lots of people want fuzzy search done right - will it appear in chosen master do you think, folks?

I don't yet know if fuzzy filtering will ever get added to Chosen or not, but it seems #2599 is a more up-to-date version and I'm going to close this. Thanks @eliasdorneles and very sorry it took me THREE YEARS to do anything with this.