3

I search for questions through questions/tagged using the OR operator. Here's a screen-shot that shows the problem:

alt text

My "Interesting tags" selections are not visible but match the query as visible in the upper right.

  • First visible question has three tags that I have selected as interesting tags, no highlight.
  • Second visible question has two interesting tags, no highlight.
  • Thirst visible question has one interesting tag, highlighted.

At least here, it is doing the exact opposite of what it should do. It is otherwise very inconsistent, I have other questions on that page with one tag match that do not get highlighted like the [c] one did. Another example is [windows] [winapi] [visual-studio-2010] [graphics] [coordinates], matches on the first 3 tags, gets highlighted.

I assume it has something to do with the OR operator, if it is easier to fix by just highlighting them all then please don't hesitate to fix it that way.

Improve this question
2
  • See this related question, under the assumption you have function-pointers as an Interesting Tag (but not as part of your search query).
    – Tim Stone
    Commented Dec 19, 2010 at 9:04
  • No, [function-pointers] is not an interesting tag selection for me. Focusing on the question that matches three but without highlight might be more productive.
    – Uphill Luge
    Commented Dec 19, 2010 at 9:07

2 Answers 2

Reset to default
6

The lack of highlighting is to be expected given that you're essentially browsing by tag (though multiple ones), and this recent change removed Interesting Tag highlighting on tag pages, for questions where the only Interesting Tags present are the ones which the tag page is for. Since you've stated that you've included all of your Interesting Tags in the query, none of the questions should be highlighted, since there are no non-queried Interesting Tags to use for highlighting.

So, the bug is really in the fact that you see any highlighting, and it comes from a fairly innocent mistake in the appyPrefs() function which handles the question highlighting. This function iterates over your list of Interesting Tags to build a selector string to use in finding questions to highlight. It then takes the array of tags used to make up that "tag page" (which accidentally also contains the "or"s in this case, but that's not a huge issue) and removes them from the selector string so that they aren't highlighted per the feature change.

When it goes to remove the queried tags, it uses the following replace:

selector = selector.replace("div.t-" + tag, "");

In general this isn't an issue, but in the case of the C tag, things go a bit awry. You have several tags which begin with the letter C, and one of them must appear earlier on in the selector string that the actual div.t-c entry. Since this isn't a global replace, one of the tag entries is cut off from the front (for example, a selector string of div.t-cçç, div.t-c becomes çç, div.t-c, where "ç" is the stand-in for "+" in the class names) instead of the actual C tag selector.

In the example, this effectively removes C++ from being highlighted, but since the C selector is still there questions tagged C will be inadvertently highlighted anyway. The replace should be more discriminatory about what it matches so that all of the correct tags will be removed from the selector string, which in this particular case would result in none of the questions being highlighted.

Improve this answer
4

This will be fixed in our next deploy.

Props to Tim Stone for spotting my mistake.

Improve this answer
6
  • It is still wrong, but a different way. The [c] tag highlighting is gone but it still doesn't highlight a question that has multiple tag matches with my interesting tags settings. For example, [c#][.net][c++][winforms][scrollbar] doesn't highlight. Four matches. What I tried to focus on in my comment to Tim's comment. The scheme makes very little sense to me in general, one tag match is as good as multiple, it's rare to get more interesting with multiple tag matches. If you want to fix it by just suppressing it then please don't hesitate.
    – Uphill Luge
    Commented Dec 20, 2010 at 22:08
  • @HansPassant You tried to bring focus to the fact that the questions with two and three matches weren't highlighted, which I already explained is [status-bydesign] in the described scenario. I linked to the explanation of this change in my answer, and to a question which asks about the change in my comment.
    – Tim Stone
    Commented Dec 20, 2010 at 22:37
  • @Tim: I tried to bring focus to it being random, as mentioned in the title. It is, still is. Yet another example: [visual-studio][visual-c++][assembly][microsoft] is highlighted right now, two matches. [c#][.net][impersonation][advapi32] is not highlighted, two matches. Hard to see how that's by design. I appreciate your input but you're not helping.
    – Uphill Luge
    Commented Dec 21, 2010 at 13:47
  • @HansPassant ~ We've got a whole community of developers to review cases, he presented the logic from the source, the developer of the source said "yeah, that was the bug and I fixed it" and you're telling Tim he's wrong? Really? You think so? Because I think his description shows that your edge cases are accounted for. Can you present an edge case that his doesn't cover? Then you might have found another bug in addition to the fixed one.
    – jcolebrand
    Commented Dec 21, 2010 at 14:47
  • @drach - how many of them run OR queries? I'm not making this up, what would be the point?
    – Uphill Luge
    Commented Dec 21, 2010 at 14:56
  • @HansPassant ~ I'm pretty sure that was the point to what Tim demonstrated and the reason the fix was necessary and not built-in.
    – jcolebrand
    Commented Dec 21, 2010 at 18:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .