[patch] mark text filter for TAB map

[bluap]

I've written a patch that I'd like to be considered for inclusion into the client.

 

The new function is a filter facility for the users mark text that get displayed on the TAB maps. When the TAB map is displayed, pressing CRTL+f activates the filter. Anything you now type is added to a filter string. Now, when the mark text strings are being displayed, they only get displayed if their text contains the current filter text. As you continue to type, the displayed marks are updated with each keypress. Pressing ESC or CTRL+f disables the filter and restores display of all marks. Backspace removes the last character added to the filter text. The current filter text is displayed below the "Cursor position" text on the left of the main map.

 

This patch requires only minor changes to the client:

A few additional lines in:

interface.c

mapwin.c

Minor additions to:

keys.c

keys.h

mapwin.h

translate.c

translate.h

 

I've testing the patch extensively on the test server but only use the Linux version of the client. I have no way to build or run the windows or MAC version but I don't expect they will be any complications. I have already picked up a #def from elsewhere that is used for BACKSPACE on MAC.

 

What do I need to do next?

[Entropy]

So it's some sort of find feature, right?

[bluap]

So it's some sort of find feature, right?

Yes, you're now going to tell me you can already do this I presume.

[Derin]

Do you have some kind of screenshot?

[bluap]

Do you have some kind of screenshot?

I do now

 

With the filter active and the letter "f" typed.

 

Then typing the rest of the word fruit.

[Entropy]

No, we don't have such an option in the client, at least not AFAIK.

Anyway, don't you think it would be a better idea to filter by the first letters of the word? To keep it consistent with the ctr+f feature in other applications.

[bluap]

No, we don't have such an option in the client, at least not AFAIK.

Anyway, don't you think it would be a better idea to filter by the first letters of the word? To keep it consistent with the ctr+f feature in other applications.

If I have understood you correctly, then sunflower would not match when you start by typing an "f". Well, that would be an easy change but I prefer it matching anywhere in the text. This way it behavours more like a filter (as intended). As you type more letters, it quickly resolves to what you're after. Also, this way, you can find mark text like "veg & fruit" not just "fruit". Another option would be to have a start anchor such as "^" so "^f" would match only text starting with "f", typing just "f" would match any mark text containing an "f".

[Entropy]

Let's see what others think.

[Derin]

I think filter by the first letter would be most logical, and I would prefer that setup.

[bkc56]

As a computer nerd I really like a true filter that handles regular expressions, but it might be easier for the typical user to understand if it matches from the start of the string (much like IE does URL matching as you type).

[bluap]

I think filter by the first letter would be most logical, and I would prefer that setup.

Thanks everyone for the feedback. However, I've just checked several editors and the Firefox browser and none of them only match words starting with the search string. They all behaviour as I have stated so I'm assuming I have misunderstood what's being said here. Or you have all misunderstood what I have explained. Either is likely as, although English is my first (and only language), I'm not too good at it.

 

In use, the way I have it currently coded works really well and is very intuitive - I think.

 

So let me try to check what you're saying. Paste the above first paragraph into your favourite text editor. Then search for the string "he". If I understand what you're preferring, the one and only match will be the start of the word "here", in the third sentence. That's not how the text editor I use works - it matches the end of the first "the". If you type another letter into the search string, making it "her", then sure enough only the word "here" matches.

 

At the end of the day, I'd really like to get this patch accepted. If I have to make it work in this (to me) odd way, so be it.

Edited October 16, 2006 by bluap

[Entropy]

You are right.

I was thinking of something else. Stuff like when you use an IDE and type the first few letters of a function, or like when you type the first few letters of an URL in a browser.

But anyway, let's wait for more people to suggest how they would like it to be.

[Aislinn]

That's not how the text editor I use works - it matches the end of the first "the". If you type another letter into the search string, making it "her", then sure enough only the word "here" matches.

If I understand your example correctly, both "the" and "here" would show up when you type "he", and then would progress to more precise matches the more you type.

I prefer this way, if I understand you correctly.

[Derin]

My only concern was that it will (at least for me I think) be faster if I, for example, type "r" I would get my markers for Red Snapdragons and Red Roses, and not also the markers for Tree Mushrooms, sunflowers, Wormwood etc. Or else it might get a bit cluttered.

 

I assume you get my point

[bluap]

My only concern was that it will (at least for me I think) be faster if I, for example, type "r" I would get my markers for Red Snapdragons and Red Roses, and not also the markers for Tree Mushrooms, sunflowers, Wormwood etc. Or else it might get a bit cluttered.

That is how it works currently. However, next typing "e" would leave you with just Red Snapdragons, Red Roses and Tree Mushrooms. Next typing "d" would leave you just Red Snapdragons and Red Roses. etc.

 

The big advantage to my mind is that this way, "Fruit and red roses" will still get matched with a filter of say "red r". Even the initial "r" search helps see what you're looking for. Just cutting down the clutter on some of my maps would allow me to see what I need even if many unrequired marks are still visible.

 

I assume you get my point

Indeed I do

 

This debate is rather fun, its great to see how different people view such a simple function.

 

If I understand your example correctly, both "the" and "here" would show up when you type "he", and then would progress to more precise matches the more you type.

I prefer this way, if I understand you correctly.

That's exactly how it works.

[Placid]

I like it the way Bluap has currently developed it. Aferall, it's not as though typing one or more letters is stupidly time consuming, is it?

[trollson]

Matching on substrings is a reasonable implementation. Is the comparison case insensitive? Would it be more useful that way?

 

Locking matches to the beginning of strings could be added later using a prefix character (cf. regex "^red", or infer from capitals "Red"). Of course, any such syntax would need to be kept very simple.

 

Keep the string search implementation flexible enough to be reused elsewhere in the client later (for example, search back in the chat log).

[kl4Uz]

I like it the way Bluap has currently developed it. Aferall, it's not as though typing one or more letters is stupidly time consuming, is it?

 

I agree. I'm really looking forward to this feature.

[Mar(c)]

I don't know if it's easy to put an

[ ] anywhere in text

check box under it?

But then, an

[ ] only exact matches

check box would be nice too!

 

In the current set-up I agree with bluap: keep it filtering matches anywhere in the text.

[Derin]

ok ok, I have put my "bluap goggles" on and thus I agree with the way you have developed it bluap

[bluap]

Matching on substrings is a reasonable implementation. Is the comparison case insensitive? Would it be more useful that way?

Yes it's case insensitive, its the catch all way and I didn't think this type of function would benefit from a case sensitive match - it would just be confusing when things didn't match.

 

Locking matches to the beginning of strings could be added later using a prefix character (cf. regex "^red", or infer from capitals "Red"). Of course, any such syntax would need to be kept very simple.

Yes, exactly as I was considering. I have also considered "fruit|veg" to match marks containing either "fruit" or "veg" substrings. Along with "fruit&veg" for the "and" case. Also matching the end of the string with "$". The only thing stopping me pursuing this is the added user complexity. What if you want to search for "$$", you would need to delimit.

 

Keep the string search implementation flexible enough to be reused elsewhere in the client later (for example, search back in the chat log).

The actual code change is very small though I had to impliment my own case insensive code which could be reused.

 

I quite like to sound of working on a search function for the chat log. May be if this patch gets accepted...

[bluap]

ok ok, I have put my "bluap goggles" on and thus I agree with the way you have developed it bluap

Now you make me feel like I've beaten you into submission Anyway, we have a consenus.

 

I've not contributed a patch before but I have read the pinned message so I guess I just sumbit it to berlios and hope for the best. Thanks to everyone for the lively debate and support

 

(Patch #1567 submitted to berlios)

Edited October 17, 2006 by bluap

[Entropy]

ok ok, I have put my "bluap goggles" on and thus I agree with the way you have developed it bluap

Now you make me feel like I've beaten you into submission Anyway, we have a consenus.

 

I've not contributed a patch before but I have read the pinned message so I guess I just sumbit it to berlios and hope for the best. Thanks to everyone for the lively debate and support

 

(Patch #1567 submitted to berlios)

Great

 

I will tell some client developer to take a look at it, and if it is stable and clean code, it will be accepted (I don't handle the client programming lately).

[crusadingknight]

Only thing I can spot is that string_contains_substr (which is a lot like get_string_occurance) probably doesn't belong in mapwin.c, but rather in asc.c, or another utility source file.

Edited October 17, 2006 by crusadingknight

[bluap]

Only thing I can spot is that string_contains_substr (which is a lot like get_string_occurance) probably doesn't belong in mapwin.c, but rather in asc.c, or another utility source file.

I did wonder if there was a general function kind of module. If you want I'll move it. I can check the other function in case I can use that.