welovecoding / editorconfig-netbeans

A NetBeans IDE plugin supporting the EditorConfig standard. ⛺
https://editorconfig.org/
MIT License
126 stars 22 forks source link

Netbeans UI appears to lock when trying to save a "properties" file #93

Open ZaLiTHkA opened 8 years ago

ZaLiTHkA commented 8 years ago

I was just testing a few things in the 0.0.9-beta build, and my NetBeans interface locks up each time I edit the contents of a .properties file and save it.

NetBeans itself doesn't crash and there's no suspicious looking CPU or memory spikes, but my mouse pointer shows a "working" icon and nothing responds to input. At this point the only option is to kill NetBeans through Task Manager and relaunch it.

NetBeans "Help > About" shows me:

Product Version: NetBeans IDE 8.0.2 (Build 201411181905)
Updates: NetBeans IDE is updated to version NetBeans 8.0.2 Patch 2
Java: 1.8.0_45; Java HotSpot(TM) Client VM 25.45-b02
Runtime: Java(TM) SE Runtime Environment 1.8.0_45-b15
System: Windows 8 version 6.2 running on x86; Cp1252; en_ZA (nb)

A couple environment variations I tried off the top of my head:

Can anyone else confirm this behaviour?

Note: I discovered this while trying to test #92 with 0.0.9-beta, so at first I was explicitly trying to save a file that didn't have any matching rules in my .editorconfig file.

joc-mer commented 8 years ago

I'm facing exactly the same issue with a standard .properties file.

Here are my nb "About" data :

Product Version: NetBeans IDE 8.1 (Build 201510222201) Java: 1.8.0_60; Java HotSpot(TM) 64-Bit Server VM 25.60-b23 Runtime: Java(TM) SE Runtime Environment 1.8.0_60-b27 System: Windows 7 version 6.1 running on amd64; Cp1252; fr_FR (nb)

After some debugging, it appears that StyledDocumentWriter.writeWithEditorKit is generating self triggering events through cookie.saveDocument();.

Even making the saving Runnable call async does not solves the problem.

Here is my .editorconfig file :

root = true

[*]

# Change these settings to your own preference
indent_style = tab
indent_size = tab

# We recommend you to keep these unchanged
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
trim_trailing_whitespace = false
ZaLiTHkA commented 8 years ago

I'm still battling with this issue in version 0.1.0, which is preventing me from getting our dev team to use this plugin..

Has anybody had a chance to look into this? Is it a complex issue to resolve?

In the meantime, is there any way to tell this plugin to ignore specific file extensions? I've tried removing the properties extension target from my .editorconfig rules, but the NB UI still gets stuck when I try save any of my bundled language resource files.

bennycode commented 8 years ago

@ZaLiTHkA, which files would you like to have ignored? You can add them here:

ZaLiTHkA commented 8 years ago

At the moment, it's related to this particular ticket; so quite simply any file with a properties extension.

For what it's worth, one of my projects has a series of language files in UTF-16 BOM encoding (don't ask, very long story), while all the others use UTF-8, but I see the same behaviour with both encoding options.

Thanks for the file link, I think it the meantime I'll fork this project and use a tweaked copy of it. :+1:

ZaLiTHkA commented 8 years ago

Just a quick note: I couldn't manage to get the plugin to ignore all .properties files. Ignore individual filenames seems simple enough, but we have a great number of them with different names.

Suppose I'll just have to wait for an official fix to this issue then. (:

bennycode commented 8 years ago

@ZaLiTHkA Would it help if we supply the functionality to ignore files by a regular expression?

Can you list some sample paths like:

myproject\directory\abc.properties
myproject\directory\subdirectory\xyz.properties

This would help me to understand your directory layout in order to write a proper regex for it.

ZaLiTHkA commented 8 years ago

Thanks, very kind. In my particular case I want to throw /(?:^.+?\.properties$)/gm at the "ignore" list... However, would it not make more sense to allow a list of "exclude" patterns to be provided by the user through the plugin settings?

A recursive search with this pattern shows 187 in my main projects folder, plus 31 in my sandbox. Scary filenames with no logic or structure between them, I promise you don't want to know more than, but these are the files that are accessible through NetBeans projects.