Bug 111619 - [Markers] Filters in Problems View: Provide separate marker limits per filter
Summary: [Markers] Filters in Problems View: Provide separate marker limits per filter
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: IDE (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 162505
Blocks:
  Show dependency tree
 
Reported: 2005-10-05 10:50 EDT by Markus Keller CLA
Modified: 2019-09-06 16:15 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2005-10-05 10:50:47 EDT
I20051004-0800

Could you move the marker limits option (view menu > Preferences) to the Filters
dialog as well? I'd like to set marker limits per filter, not globally.

Use case:
1) normal development:
    on any element, show only errors, limit: 100 errors
2) fixing nls/deprecation/etc. warnings:
    on any element in same project, show all severities, limit: none

In older builds I could switch this on one page. Now, I always have to open two
dialogs.
Comment 1 Tod Creasey CLA 2005-10-05 11:30:23 EDT
How do you reconcile 2 filters with different marker limits? The purpose of the
limits is to limit the markers shown for performance reasons so it does not
belong to a particular filter.
Comment 2 Markus Keller CLA 2005-10-05 11:52:06 EDT
> How do you reconcile 2 filters with different marker limits?
Take the largest number (or all, if the limit is disabled in one filter).
This is the same as if you have a filter "On any element" and one "On selected
element only" -> result is to take the larger set.

> The purpose of the limits is to limit the markers shown for performance
> reasons so it does not belong to a particular filter.
In my use case, it does: during normal development, I'm only interested in
global errors and it's nice that I can limit the Problems view's CPU
consumption. When I hunt for special kinds of warnings, I don't care about
performance - I want them all.
Comment 3 Tod Creasey CLA 2006-01-31 16:30:32 EST

*** This bug has been marked as a duplicate of 124883 ***
Comment 4 Markus Keller CLA 2006-02-23 12:53:27 EST
Sorry, but this is not a dup of bug 124883. The problem here is independent from grouping, and I still have to open two dialogs to switch between my two main usage patterns.
Comment 5 Tod Creasey CLA 2007-10-23 12:18:08 EDT
Marker limits are on the preference page of the new markers view.
Comment 6 Tod Creasey CLA 2007-10-29 11:49:54 EDT
Verified in I20071029-0100
Comment 7 Markus Keller CLA 2007-11-07 04:52:47 EST
Sorry, this is not fixed. The new preference is at odds with the trend to move view-specific preferences to the view (to avoid cluttering the Preferences dialog).

Moreover, I still have to open two configuration dialogs to change the filters and the limit.
Comment 8 Tod Creasey CLA 2007-11-07 08:29:27 EST
I'm going to mark this as FIXED so that I can track the bug you were reporting (which was a code error).

I have logged bug 209017 for you for this other issue.
Comment 9 Tod Creasey CLA 2007-12-10 14:12:02 EST
Verified in Version: 3.4.0 Build id: I20071210-0930
Comment 10 Markus Keller CLA 2010-11-22 07:01:03 EST
There's no reason for this enhancement request to be closed, since comment 0 has not been addressed at all.

Clarified subject to talk explicitly about separate marker limits *per filter*.
Comment 11 Hitesh CLA 2010-11-23 11:29:00 EST
Requires some rework.
Comment 12 Eclipse Webmaster CLA 2019-09-06 16:15:43 EDT
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.

If you have further information on the current state of the bug, please add it. 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.