Community
Participate
Working Groups
When too many tabs are opened, some are not directly displayed. A button with a double arrow (">>") above a number indicating the number of tabs displays to the right of the tab strip. When clicking this button, a yellow drop-down is displayed listing all tabs in that tab group. This drop-down offers a filter text field at the top which allows to search in the list by typing part of the tab name. Unfortunately, if the name fragment typed is not right at the beginning of the searched tab, the tab is not shown (it is filtered out). For example, if I search fragment "synchro", the list is reduced to: >synchro.php >synchro_suppression_adna.php >Synchronizer.php ...but the following tabs will not show: >MasasSynchronizer.php >NaadAdnaSynchronizer.php It may make sense to list results in which the fragment is not at the beginning after others, but I consider not showing them as a bug, as similar filters generally have no such constraint, and there is no indication to that effect. For example, searching for "language" in Preferences will not filter out the "Dynamic Languages" panel.
Search fields are a delicate topic. They tend to have all slightly different behaviors (which is sometimes useful and sometimes just inconsistent). Sometimes someone wishes a different behavior and when change the next complains the search has to much matches now... The most similar request to your request is bug 511375. However although the summary matches your request I will not yet close this one as duplicate because the other bug is actually discussing case insensitive CamelCase matches (makes more sense than it seems). IMO bug 511375 combined with this one is an example who different wishes can potential collide. The other bug plans that "npe" match the upper letters from "NullPointerException". You wish that "npe" match anything which contains this substring anywhere in the name. If both are implemented both parties may complain about unexpected matches. Just for completeness and the rare case you don't already know. The "Show List" search field supports wildcards. So searching "*synchro" would match all of your example files. Maybe this is already good enough for you. We have a similar situation with Quick switch editor and bug 543191 and bug 497938. Or also similar bug 550779. This is just my general opinion on those search related bugs and I wanted to add my knowledge about related bugs. It should not decide the handling of your request. I personally would prefer substring over bug 511375 and even Patrik seemed to prefer the current behavior in the end of bug 511375.
Ah, thank you very much Paul. I'm fixing this ticket's Summary correspondingly. Yes, knowing about the issue and about "*" is already a pretty good workaround. Technically, ticket #511375 is invalid as search already supports substring matching. It just doesn't support all substrings (without an asterisk). But in any case I see no conflict between it and this request. I for one have nothing against the other change being implemented too. But I agree this is very related with ticket #550779. I would argue that prefilling the search field with "*" would make the workaround a lot more discoverable and largely reduce this issue's impact. But I very much consider that as a hack.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Fixing this ticket's status (see ticket #565491)
