This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 141181 - it should be possible to enable/disable CSS warnings
Summary: it should be possible to enable/disable CSS warnings
Status: VERIFIED FIXED
Alias: None
Product: web
Classification: Unclassified
Component: CSS Editor (show other bugs)
Version: 7.3
Hardware: Sun All
: P2 blocker with 2 votes (vote)
Assignee: Marek Fukala
URL:
Keywords:
: 235341 (view as bug list)
Depends on:
Blocks: 235151
  Show dependency tree
 
Reported: 2008-07-22 15:02 UTC by Jindrich Sedek
Modified: 2013-12-26 11:21 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jindrich Sedek 2008-07-22 15:02:10 UTC
the UI for enabling and disabling editor warnings is needed for CSS
Comment 1 Marek Fukala 2012-10-15 12:16:03 UTC
Each css error/warning should have a hint to suppress it for file/mime/project as in html
Comment 2 Marek Fukala 2013-09-02 09:22:48 UTC
*** Bug 235341 has been marked as a duplicate of this bug. ***
Comment 3 luiz_bonfa 2013-10-06 18:33:28 UTC
I consider this issue - not giving users a choice of detecting or ignoring parsing errors and marking them with error badges all over project tree - is a very serious  design flaw.
For me and my team this flaw makes it impossible to upgrade from 7.2 to 7.4 (although we need to upgrade for the different reasons - some new features). Please consider this as an urgent request from loyal NetBeans users.
Comment 4 Vladimir Riha 2013-10-08 10:54:33 UTC
After offline discussion with Marek marking as patch candidate.
Comment 5 luiz_bonfa 2013-10-11 01:40:04 UTC
@Vladimir Riha

Thank you for your understanding. I really appreciate it. I am looking forward for this patch to appear in 7.4 RC
Comment 6 Marek Fukala 2013-10-15 10:56:15 UTC
fixed in web-main#26b3e4610db9

it's not a flawless fix, but I believe it is acceptable for the patch.
Comment 7 Marek Fukala 2013-10-15 11:01:17 UTC
each css warning/error now have hint w/ fixes to suppress it for type, file or any of its parent folders. 

There's plenty of room for improvements especially for suppressing by the error type - the impl. is too simple to properly identify the particular error types and contexts.
Comment 8 luiz_bonfa 2013-10-16 16:40:03 UTC
@Marek Fukala

Thanks for the attention to this issue.  

The most obvious and straightforward cure for this would be to have a global preference  to show or not show error badges on all parent folders no matter what happens with individual files inside them all the way down the folder hierarchy.
 
Then if user prefers not "not to show error badges on folders" then he continues to work in old good 7.2. All third-party code errors will be hidden and won't distract the developer.   But all the errors of personal interest that is the errors related to his own files will be visible anyway by the badges on his own files. That is the way we worked for years and were pretty happy about it.

So creating ONE global switch can immediately bring a great relief. After that you guys can think about subtle differentiating by the error types etc. etc. etc. 

Just my two cents.
Comment 9 Marek Fukala 2013-10-17 08:19:25 UTC
(In reply to luiz_bonfa from comment #8)
> @Marek Fukala
> 
> Thanks for the attention to this issue.  
> 
> The most obvious and straightforward cure for this would be to have a global
> preference  to show or not show error badges on all parent folders no matter
> what happens with individual files inside them all the way down the folder
> hierarchy.
>  
> Then if user prefers not "not to show error badges on folders" then he
> continues to work in old good 7.2. All third-party code errors will be
> hidden and won't distract the developer.   But all the errors of personal
> interest that is the errors related to his own files will be visible anyway
> by the badges on his own files. That is the way we worked for years and were
> pretty happy about it.
> 
> So creating ONE global switch can immediately bring a great relief. After
> that you guys can think about subtle differentiating by the error types etc.
> etc. etc. 
> 
> Just my two cents.
So you think the implemented solution where one can disable the css error checks per folder is not enough? Too complicated? Each css error have now several hint fixes:

- suppress the "Unexpected ERROR token" CSS parsing error (not reliable as mentioned)
- suppress css parsing errors in myProject/public_html/lib/xxx/module.css
- suppress css parsing errors in myProject/public_html/lib/xxx/
- suppress css parsing errors in myProject/public_html/lib
- suppress css parsing errors in myProject/public_html
- suppress css parsing errors in myProject

so you can choose the context where the parsing errors are ignored.
Comment 10 luiz_bonfa 2013-10-17 20:54:20 UTC
@Marek Fukala

The question "is it not enough" is hard to answer without a context. I guess any piece of functionality should be considered in the scope of particular "use cases". 


In my view developers that use NetBeans can be roughly categorized in two groups (for the purpose of this particular discussion) :

1) Developers with relatively small projects where most of the code is written by them

2) Developers with  big projects where most of the code is writthen by third-parties (libraries, frameworks, platforms etc)

For group 1 it is easy to go through a couple of dozen folders/files and suppress error badges where they are not needed

For group 2 it is a significant effort and time to traverse hundreds and hundreds folders/files (mostly not their own) and suppress error badges where they are not needed.

That is why I suggested that this global switch that will allow the following: 

Developers of group 1 will turn it ON (show error badges) and then specifically suppress folders/files in a few areas of the project that they are not interested in and do not need any error detection

Developers of group 2 will turn it OFF (do not show error badges) and will find themselves in a  environment of version 7.2 and earlier. Then (if necessary) they specifically enable error badges only for a few areas/locations in the project that they own and/or are interested in.

This solution will cover both use cases. Of course there will be projects somewhere in between and  then developers will decide themselves which course of actions is more suitable for them. 

And your design and implementation will be flexible and will give them the choice to work in a most convenient and efficient way.
Comment 11 Marek Fukala 2013-10-18 07:47:29 UTC
> For group 2 it is a significant effort and time to traverse hundreds and
> hundreds folders/files (mostly not their own) and suppress error badges
> where they are not needed.
> 
I understand your point. 

However I'm curious how the libraries sources are organized in such environment. Are the user's sources in the same project as the libraries? Are they in separated projects? What kind of projects are these?

Typically in html project you copy all the css/js libraries into the project's sources so suppressing the css errors would be one click operation.

I can add a global switch "Show error badges for CSS errors", but first I'd like the understand why the current solution doesn't work for you.

Also note that when the css errors are suppressed not only the error badge is disabled. The editor won't show any error neither and there won't be issues in the Action Items list.
Comment 12 luiz_bonfa 2013-10-23 01:01:37 UTC
@Marek Fukala

The typical project I am talking about represents a single web application that contains Joomla CMS Core Code + some particular Joomla Template Code + T3 Framework code that is based on  Bootstrap and uses  LESS pre-processor.

Typical project is about 40 MB and consists of about 5000 files and about  1000 folders.

If based on these source files we create PHP project in NetBeans 7.2.1 there will be no error badges on the folders. 

If we create the project in NetBeans  7.4 based on the same source file it will have error badges on .css, .less and .php files and on all hierarchy of containing folders.


I can provide a sample typical project if it is necessary to look at the project structure and content in details so that some reasonable way to deal with the error detection could be found
Comment 13 bht 2013-10-26 05:03:35 UTC
Please excuse my ignorance - I cannot find in 7.4 (Build 201310111528) how to disable the error badges.

I see in Menu|Tools_Options|Editor|Hints|Language: HTML

there is a check box tree node "CSS" with nodes "Missing CSS Class", "Missing CSS Class in partials" and "No id rule found".

None of these options seem to fit the description, and none of them has "Show as" configured as error.

So I must be looking in the wrong place. If I disable CSS on the top level, then I still see the CSS error "Unexpected token COLON found"

Where can I find the new features?

Thanks
Comment 14 malm 2013-10-27 11:27:22 UTC
(In reply to bht from comment #13)
> Please excuse my ignorance - I cannot find in 7.4 (Build 201310111528) how
> to disable the error badges.
If I understand the BugZilla fields for this entry correctly it has been fixed for NetBeans 8.0 and is under consideration for NetBeans 7.4 Patch 1. Therefore this fix is not included in the NetBeans 7.4 release.
Comment 15 Vladimir Riha 2013-11-04 08:39:22 UTC
Verified in trunk. Filtering out all CSS errors in (all projects/single project/folders in path to css file) is one click action


Product Version: NetBeans IDE Dev (Build 201311040001)
Java: 1.7.0_45; Java HotSpot(TM) Client VM 24.45-b08
Runtime: Java(TM) SE Runtime Environment 1.7.0_45-b18
System: Linux version 3.2.0-48-generic-pae running on i386; UTF-8; en_US (nb)
Comment 16 Petr Jiricka 2013-11-13 10:01:16 UTC
Marku, would you agree with putting this in the patch? Ondro, would you please be able to put it in the patch for Marek? Thanks.
Comment 17 Ondrej Brejla 2013-11-13 11:59:53 UTC
It's marked as a patch candidate for a month, so I'll transplant it.
Comment 18 Ondrej Brejla 2013-11-13 12:02:43 UTC
Transplanted to release74 branch. Please verify, thanks.
Comment 19 Vladimir Riha 2013-11-15 10:02:25 UTC
verified in patch

Product Version: NetBeans IDE 7.4 (Build 201311142201)
Java: 1.7.0_45; Java HotSpot(TM) Client VM 24.45-b08
Runtime: Java(TM) SE Runtime Environment 1.7.0_45-b18
System: Linux version 3.2.0-48-generic-pae running on i386; UTF-8; en_US (nb)