[jira] [Commented] (NETBEANS-646) Keyboard lag in 8.2 under macOS 10.13 High Sierra?

2018-06-22 Thread Laszlo Kishalmi (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520975#comment-16520975
 ] 

Laszlo Kishalmi commented on NETBEANS-646:
--

Does it still happen?

These are usual symptoms of an overloaded hardware/os/event queue.

Does a reboot fix this issue?

> Keyboard lag in 8.2 under macOS 10.13 High Sierra?
> --
>
> Key: NETBEANS-646
> URL: https://issues.apache.org/jira/browse/NETBEANS-646
> Project: NetBeans
>  Issue Type: Bug
> Environment: MacBook Pro, NB 8.2, JDK 1.8.?
>Reporter: Bob Alei
>Priority: Critical
>
> A student of mine is having big trouble with newly installed NB 8.2 on a 
> Macbook pro (?) running with JDK 1.8.?  In the source editor, he can type a 
> few characters then the cursor jumps around, very erratically. I think it's a 
> keyboard lag issue, if he waits a half second between keypresses, it seems to 
> be OK.  But it could be something else.  Are there any known configurations 
> that cause bizarre keyboard behavior?  Anything else that I could check?  All 
> other programs on his computer work fine.  TIA,
> Bob Alei
> PS.  MY apologies if this is the wrong forum for this kind of question.  
> Please advise if so.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-798) Netbeans crashes after closing snipping tools

2018-06-22 Thread Laszlo Kishalmi (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520964#comment-16520964
 ] 

Laszlo Kishalmi commented on NETBEANS-798:
--

Well, could you be more specific please? What OS do you use? What kind of 
snipping tools you experienced the problem with.

> Netbeans crashes after closing snipping tools
> -
>
> Key: NETBEANS-798
> URL: https://issues.apache.org/jira/browse/NETBEANS-798
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 8.2
>Reporter: Eduard Fekete
>Priority: Critical
> Attachments: b0.PNG
>
>
> I opened the dialog to create a new project because I wanted to take a 
> screenshot of it for a bug report, by using snipping tools. Ironically I 
> found another bug, after taking the screenshot and closing snipping tools, 
> NetBeans crashed. I was able to reproduce this many times.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-816) Netbeans inline JSX Variable

2018-06-22 Thread Laszlo Kishalmi (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Laszlo Kishalmi updated NETBEANS-816:
-
Component/s: javascript - Editor

> Netbeans inline JSX Variable
> 
>
> Key: NETBEANS-816
> URL: https://issues.apache.org/jira/browse/NETBEANS-816
> Project: NetBeans
>  Issue Type: Bug
>  Components: javascript - Editor
>Affects Versions: 8.2
>Reporter: Wagner Silva
>Priority: Critical
> Attachments: image-2018-05-18-15-28-30-210.png
>
>
> Netbeans is not being able to interpret a variable inside of a style tag in 
> JSX.
> React is very popular right now, and this kind of usage is very important.
>  
> !image-2018-05-18-15-28-30-210.png!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-798) Netbeans crashes after closing snipping tools

2018-06-22 Thread Laszlo Kishalmi (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Laszlo Kishalmi updated NETBEANS-798:
-
Component/s: javascript - Editor

> Netbeans crashes after closing snipping tools
> -
>
> Key: NETBEANS-798
> URL: https://issues.apache.org/jira/browse/NETBEANS-798
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 8.2
>Reporter: Eduard Fekete
>Priority: Critical
> Attachments: b0.PNG
>
>
> I opened the dialog to create a new project because I wanted to take a 
> screenshot of it for a bug report, by using snipping tools. Ironically I 
> found another bug, after taking the screenshot and closing snipping tools, 
> NetBeans crashed. I was able to reproduce this many times.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-798) Netbeans crashes after closing snipping tools

2018-06-22 Thread Laszlo Kishalmi (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Laszlo Kishalmi updated NETBEANS-798:
-
Component/s: (was: javascript - Editor)

> Netbeans crashes after closing snipping tools
> -
>
> Key: NETBEANS-798
> URL: https://issues.apache.org/jira/browse/NETBEANS-798
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 8.2
>Reporter: Eduard Fekete
>Priority: Critical
> Attachments: b0.PNG
>
>
> I opened the dialog to create a new project because I wanted to take a 
> screenshot of it for a bug report, by using snipping tools. Ironically I 
> found another bug, after taking the screenshot and closing snipping tools, 
> NetBeans crashed. I was able to reproduce this many times.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-798) Netbeans crashes after closing snipping tools

2018-06-22 Thread Laszlo Kishalmi (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Laszlo Kishalmi updated NETBEANS-798:
-
Affects Version/s: 8.2

> Netbeans crashes after closing snipping tools
> -
>
> Key: NETBEANS-798
> URL: https://issues.apache.org/jira/browse/NETBEANS-798
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 8.2
>Reporter: Eduard Fekete
>Priority: Critical
> Attachments: b0.PNG
>
>
> I opened the dialog to create a new project because I wanted to take a 
> screenshot of it for a bug report, by using snipping tools. Ironically I 
> found another bug, after taking the screenshot and closing snipping tools, 
> NetBeans crashed. I was able to reproduce this many times.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-816) Netbeans inline JSX Variable

2018-06-22 Thread Laszlo Kishalmi (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520963#comment-16520963
 ] 

Laszlo Kishalmi commented on NETBEANS-816:
--

Well, I guess it is filed against 8.2.  We've just got the second code drop 
which covers the Java EE, JS, etc.

> Netbeans inline JSX Variable
> 
>
> Key: NETBEANS-816
> URL: https://issues.apache.org/jira/browse/NETBEANS-816
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 8.2
>Reporter: Wagner Silva
>Priority: Critical
> Attachments: image-2018-05-18-15-28-30-210.png
>
>
> Netbeans is not being able to interpret a variable inside of a style tag in 
> JSX.
> React is very popular right now, and this kind of usage is very important.
>  
> !image-2018-05-18-15-28-30-210.png!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-816) Netbeans inline JSX Variable

2018-06-22 Thread Laszlo Kishalmi (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Laszlo Kishalmi updated NETBEANS-816:
-
Affects Version/s: 8.2

> Netbeans inline JSX Variable
> 
>
> Key: NETBEANS-816
> URL: https://issues.apache.org/jira/browse/NETBEANS-816
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 8.2
>Reporter: Wagner Silva
>Priority: Critical
> Attachments: image-2018-05-18-15-28-30-210.png
>
>
> Netbeans is not being able to interpret a variable inside of a style tag in 
> JSX.
> React is very popular right now, and this kind of usage is very important.
>  
> !image-2018-05-18-15-28-30-210.png!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-866) Platform "Resolve" button for libraries broken out of the box.

2018-06-22 Thread Laszlo Kishalmi (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520962#comment-16520962
 ] 

Laszlo Kishalmi commented on NETBEANS-866:
--

Hi [~pajansen], Have  Geertjan's hints resolved your problem?

We either have to mark this issue resolved, or demoted from critical in order 
to cut our final release.

> Platform "Resolve" button for libraries broken out of the box.
> --
>
> Key: NETBEANS-866
> URL: https://issues.apache.org/jira/browse/NETBEANS-866
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - JDK Problems
>Affects Versions: 8.2
>Reporter: Peter Jansen
>Priority: Critical
> Attachments: netbeans_issue_javafx.jpg
>
>
> I've just started trying to develop a GUI using the Netbeans Platform using 
> the NetBeans Platform for Beginners and JavaFX RCP for the Netbeans Platform 
> books recommended as part of the official documentation on the platform 
> website. 
> The very first examples in the book appear to break, as the Project 
> Properties > Libraries dialog throws the following error:
> "Module FX WebView Bootstrap in platform requests the token 
> javafx.application but there are no known providers." 
> The resolve button is red, but can't be clicked. 
> 1) Ignoring and attempting to add modules without being able to resolve their 
> dependencies means the program will throw and error and modules will be 
> disabled upon startup.
> 2) Deselecting the offending modules (FX Webview Bootstrap in platform, and 
> so on through other FX-depending modules, until the resolve button works 
> again) appears to allow the code to compile and dependencies to be 
> automatically resolved – but only a few pages in the book, adding the 'XML 
> Text Editor' and resolving the dependencies for this causes the program to 
> crash when running:
> java.lang.NoClassDefFoundError: Could not initialize class 
> org.netbeans.api.project.ProjectManager
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498)
> ...
> It seems that this is a major issue reported several years ago on other 
> venues with 8.x, and I've checked and also appears to be present on the 
> development and 9.0rc1 builds, but still hasn't been fixed?  This appears to 
> be a major issue in even beginning to write new software using the netbeans 
> platform?  My apologies if this is a simple error or oversight on my part.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-931) OutOfMemory after a night of stand-by

2018-06-22 Thread Laszlo Kishalmi (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520960#comment-16520960
 ] 

Laszlo Kishalmi commented on NETBEANS-931:
--

Could you compress the dump?

Also you can upload the compressed dump to Telegram [https://t.me/lkishalmi] or 
https://t.me/apache_netbeans

> OutOfMemory after a night of stand-by
> -
>
> Key: NETBEANS-931
> URL: https://issues.apache.org/jira/browse/NETBEANS-931
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 9.0
>Reporter: Luca Mambretti
>Priority: Critical
> Attachments: messages.log, uigestures.xml
>
>
> After a full day of work I left the system running (it had manifested the 
> errors described in NETBEANS-901).
>  
> The day after it was out of commission with OOM.
>  
> attached IDE logs and gestures, I also have the heap dump but it's 1.5 gigs 
> so I doubt I'll be able to attach it (sent it thru a WeTransfer link for now)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-979) With line wrap enabled, cursor at end of line is painted at beginning of next line instead

2018-06-22 Thread Eirik Bakke (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520920#comment-16520920
 ] 

Eirik Bakke commented on NETBEANS-979:
--

Doing a few more experiments with this, especially comparing to the behavior in 
other editors, I think the caret might actually be painted in the correct 
position--this should rather be regarded as a bug in the up/down/home/end 
actions.

> With line wrap enabled, cursor at end of line is painted at beginning of next 
> line instead
> --
>
> Key: NETBEANS-979
> URL: https://issues.apache.org/jira/browse/NETBEANS-979
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Painting  Printing
>Reporter: Eirik Bakke
>Priority: Major
> Fix For: 9.0
>
>
> In an editor with line wrap enabled, the cursor is shown at the wrong 
> physical location whenever it is supposed to be located at the end of a wrap 
> line. Instead of being painted at the end of the wrap line, it is painted at 
> the beginning of the following line. This causes the behavior of keyboard 
> shortcuts like "End" and "Up" to seem nonsensical to the user, although they 
> might well be behaving correctly wrt. the physical location of the cursor 
> (the character offset).
> To reproduce:
> 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
> set "Line Wrap" to "After words". Click OK.
> 2) Create a new plain text file and open it in the editor.
> 3) Type some gibberish into the editor on a single line that is long enough 
> to be broken into several break lines.
> 4) With the cursor before the first character of the first wrap line in the 
> paragraph, press the "End" key (Command+Right on MacBook keyboards). The 
> cursor appears to move one line down, which is unexpected. From looking at 
> this situation, the user would now assume that they could press the "Up" key 
> to move the cursor back to the previous break line, but this will not change 
> the cursor position (because the cursor is logically on the previous line).
> 5) Another unexpected example: Pressing Home anywhere in a paragraph will 
> move the cursor to the first character on the paragraph rather than at the 
> first character of the wrap line. (This might indicate that the problem is 
> more than just a paint bug, though.)
> Originally reported in BugZilla at 
> https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on 
> NetBeans 9.0 rc2.
> See also https://issues.apache.org/jira/browse/NETBEANS-980 .



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-979) With line wrap enabled, cursor at end of line is painted at beginning of next line instead

2018-06-22 Thread Eirik Bakke (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-979:
-
Description: 
In an editor with line wrap enabled, the cursor is shown at the wrong physical 
location whenever it is supposed to be located at the end of a wrap line. 
Instead of being painted at the end of the wrap line, it is painted at the 
beginning of the following line. This causes the behavior of keyboard shortcuts 
like "End" and "Up" to seem nonsensical to the user, although they might well 
be behaving correctly wrt. the physical location of the cursor (the character 
offset).

To reproduce:
1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
set "Line Wrap" to "After words". Click OK.
2) Create a new plain text file and open it in the editor.
3) Type some gibberish into the editor on a single line that is long enough to 
be broken into several break lines.
4) With the cursor before the first character of the first wrap line in the 
paragraph, press the "End" key (Command+Right on MacBook keyboards). The cursor 
appears to move one line down, which is unexpected. From looking at this 
situation, the user would now assume that they could press the "Up" key to move 
the cursor back to the previous break line, but this will not change the cursor 
position (because the cursor is logically on the previous line).
5) Another unexpected example: Pressing Home anywhere in a paragraph will move 
the cursor to the first character on the paragraph rather than at the first 
character of the wrap line. (This might indicate that the problem is more than 
just a paint bug, though.)

Originally reported in BugZilla at 
https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on 
NetBeans 9.0 rc2.

See also https://issues.apache.org/jira/browse/NETBEANS-980 .

  was:
In an editor with line wrap enabled, the cursor is shown at the wrong physical 
location whenever it is supposed to be located at the end of a wrap line. 
Instead of being painted at the end of the wrap line, it is painted at the 
beginning of the following line. This causes the behavior of keyboard shortcuts 
like "End" and "Up" to seem nonsensical to the user, although they might well 
be behaving correctly wrt. the physical location of the cursor (the character 
offset).

To reproduce:
1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
set "Line Wrap" to "After words". Click OK.
2) Create a new plain text file and open it in the editor.
3) Type some gibberish into the editor on a single line that is long enough to 
be broken into several break lines.
4) With the cursor before the first character of any wrap line in the paragraph 
except the last, press the "End" key (Command+Right on MacBook keyboards). The 
cursor appears to move one line down, which is unexpected. From looking at this 
situation, the user would now assume that they could press the "Up" key to move 
the cursor back to the previous break line, but this will not change the cursor 
position (because the cursor is logically on the previous line).
5) Another unexpected example: Pressing Home anywhere in a paragraph will move 
the cursor to the first character on the paragraph rather than at the first 
character of the wrap line. (This might indicate that the problem is more than 
just a paint bug, though.)

Originally reported in BugZilla at 
https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on 
NetBeans 9.0 rc2.

See also https://issues.apache.org/jira/browse/NETBEANS-980 .


> With line wrap enabled, cursor at end of line is painted at beginning of next 
> line instead
> --
>
> Key: NETBEANS-979
> URL: https://issues.apache.org/jira/browse/NETBEANS-979
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Painting  Printing
>Reporter: Eirik Bakke
>Priority: Major
> Fix For: 9.0
>
>
> In an editor with line wrap enabled, the cursor is shown at the wrong 
> physical location whenever it is supposed to be located at the end of a wrap 
> line. Instead of being painted at the end of the wrap line, it is painted at 
> the beginning of the following line. This causes the behavior of keyboard 
> shortcuts like "End" and "Up" to seem nonsensical to the user, although they 
> might well be behaving correctly wrt. the physical location of the cursor 
> (the character offset).
> To reproduce:
> 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
> set "Line Wrap" to "After words". Click OK.
> 2) Create a new plain text file and open it in the editor.
> 3) Type some gibberish into the editor on a single line that is long enough 
> to be broken into several break lines.
> 4) With the 

[jira] [Updated] (NETBEANS-979) With line wrap enabled, cursor at end of line is painted at beginning of next line instead

2018-06-22 Thread Eirik Bakke (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-979:
-
Description: 
In an editor with line wrap enabled, the cursor is shown at the wrong physical 
location whenever it is supposed to be located at the end of a wrap line. 
Instead of being painted at the end of the wrap line, it is painted at the 
beginning of the following line. This causes the behavior of keyboard shortcuts 
like "End" and "Up" to seem nonsensical to the user, although they might well 
be behaving correctly wrt. the physical location of the cursor (the character 
offset).

To reproduce:
1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
set "Line Wrap" to "After words". Click OK.
2) Create a new plain text file and open it in the editor.
3) Type some gibberish into the editor on a single line that is long enough to 
be broken into several break lines.
4) With the cursor before the first character of any wrap line in the paragraph 
except the last, press the "End" key (Command+Right on MacBook keyboards). The 
cursor appears to move one line down, which is unexpected. From looking at this 
situation, the user would now assume that they could press the "Up" key to move 
the cursor back to the previous break line, but this will not change the cursor 
position (because the cursor is logically on the previous line).
5) Another unexpected example: Pressing Home anywhere in a paragraph will move 
the cursor to the first character on the paragraph rather than at the first 
character of the wrap line. (This might indicate that the problem is more than 
just a paint bug, though.)

Originally reported in BugZilla at 
https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on 
NetBeans 9.0 rc2.

See also https://issues.apache.org/jira/browse/NETBEANS-980 .

  was:
In an editor with line wrap enabled, the cursor is shown at the wrong physical 
location whenever it is supposed to be located at the end of a wrap line. 
Instead of being painted at the end of the wrap line, it is painted at the 
beginning of the following line. This causes the behavior of keyboard shortcuts 
like "End" and "Up" to seem nonsensical to the user, although they might well 
be behaving correctly wrt. the physical location of the cursor (the character 
offset).

To reproduce:
1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
set "Line Wrap" to "After words". Click OK.
2) Create a new plain text file and open it in the editor.
3) Type some gibberish into the editor on a single line that is long enough to 
be broken into several break lines.
4) With the cursor on the first break line, press the "End" key (Command+Right 
on MacBook keyboards). The cursor appears to move one line down, which is 
unexpected. From looking at this situation, the user would now assume that they 
could press the "Up" key to move the cursor back to the previous break line, 
but this will not change the cursor position (because the cursor is logically 
on the previous line).
5) Another unexpected example: Pressing End with cursor before the first 
character of any wrapped paragraph moves cursor down instead of to the end of 
the line.
6) Another unexpected example: Pressing Home anywhere in a paragraph will move 
the cursor to the first character on the paragraph rather than at the first 
character of the wrap line.

Originally reported in BugZilla at 
https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on 
NetBeans 9.0 rc2.


> With line wrap enabled, cursor at end of line is painted at beginning of next 
> line instead
> --
>
> Key: NETBEANS-979
> URL: https://issues.apache.org/jira/browse/NETBEANS-979
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Painting  Printing
>Reporter: Eirik Bakke
>Priority: Major
> Fix For: 9.0
>
>
> In an editor with line wrap enabled, the cursor is shown at the wrong 
> physical location whenever it is supposed to be located at the end of a wrap 
> line. Instead of being painted at the end of the wrap line, it is painted at 
> the beginning of the following line. This causes the behavior of keyboard 
> shortcuts like "End" and "Up" to seem nonsensical to the user, although they 
> might well be behaving correctly wrt. the physical location of the cursor 
> (the character offset).
> To reproduce:
> 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
> set "Line Wrap" to "After words". Click OK.
> 2) Create a new plain text file and open it in the editor.
> 3) Type some gibberish into the editor on a single line that is long enough 
> to be broken into several break lines.
> 4) With the cursor before the first 

[jira] [Assigned] (NETBEANS-965) does not load GlassFish

2018-06-22 Thread Kron22 (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kron22 reassigned NETBEANS-965:
---

Assignee: (was: Kron22)

> does not load GlassFish
> ---
>
> Key: NETBEANS-965
> URL: https://issues.apache.org/jira/browse/NETBEANS-965
> Project: NetBeans
>  Issue Type: Bug
>  Components: serverplugins - GlassFish
> Environment: OS: Manjaro 17.1.10 Hakoila
> Kernel: x86_64 Linux 4.14.48-2-MANJARO
> DE: Xfce4
> WM: Xfwm4
>Reporter: Kron22
>Priority: Major
> Attachments: error-glassfish.png
>
>
> does not load GlassFish server



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Created] (NETBEANS-981) the Java_ME_platform_SDK_8.3 platform is not defined

2018-06-22 Thread Kron22 (JIRA)
Kron22 created NETBEANS-981:
---

 Summary: the Java_ME_platform_SDK_8.3 platform is not defined
 Key: NETBEANS-981
 URL: https://issues.apache.org/jira/browse/NETBEANS-981
 Project: NetBeans
  Issue Type: Bug
  Components: platform - JDK Problems
Affects Versions: 8.2
Reporter: Kron22
 Attachments: platform.png

In Netbeans 8.2 I tried to add a Platform for Java ME SDK 8.3 without success 
the error message is Platform detection failed what goes wrong?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Assigned] (NETBEANS-965) does not load GlassFish

2018-06-22 Thread Kron22 (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kron22 reassigned NETBEANS-965:
---

Assignee: Kron22

> does not load GlassFish
> ---
>
> Key: NETBEANS-965
> URL: https://issues.apache.org/jira/browse/NETBEANS-965
> Project: NetBeans
>  Issue Type: Bug
>  Components: serverplugins - GlassFish
> Environment: OS: Manjaro 17.1.10 Hakoila
> Kernel: x86_64 Linux 4.14.48-2-MANJARO
> DE: Xfce4
> WM: Xfwm4
>Reporter: Kron22
>Assignee: Kron22
>Priority: Major
> Attachments: error-glassfish.png
>
>
> does not load GlassFish server



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Created] (NETBEANS-980) Cannot arrow up/down to shorter word-wrapped line in editor

2018-06-22 Thread Eirik Bakke (JIRA)
Eirik Bakke created NETBEANS-980:


 Summary: Cannot arrow up/down to shorter word-wrapped line in 
editor
 Key: NETBEANS-980
 URL: https://issues.apache.org/jira/browse/NETBEANS-980
 Project: NetBeans
  Issue Type: Bug
  Components: editor - Other, editor - Painting  Printing
Affects Versions: 9.0
Reporter: Eirik Bakke


If line wrap is enabled, and the text caret is located in a wrapped paragraph, 
the up/down arrow keys cannot be used to move the caret up/down to another wrap 
line if the target wrap line is shorter than the current caret position. Either 
nothing happens, or the caret may skip the shorter wrap lines and step multiple 
wrap lines up/down.

To reproduce:
1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
set "Line Wrap" to "After words". Click OK.
2) Create a new plain text file and paste in the paragraph "SHORTWORD 
LONGWORD SHORTWORD LUUUNGWORD".
3) Resize the editor window so that the paragraph gets split into three wrap 
lines (one word on each wrap line--i.e. make the editor a little wider than the 
long word).
4) Position the cursor right after "...ONG"
5) Press the "Up" arrow. Nothing happens (expected would be to the caret to 
move up to the end of the previous wrap line).
6) Press the "Down" arrow. This moves the caret _two_ wrap lines down instead 
of to the end of the next wrap line.

Tested in NetBeans 9.0 rc2.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-979) With line wrap enabled, cursor at end of line is painted at beginning of next line instead

2018-06-22 Thread Eirik Bakke (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-979:
-
Description: 
In an editor with line wrap enabled, the cursor is shown at the wrong physical 
location whenever it is supposed to be located at the end of a wrap line. 
Instead of being painted at the end of the wrap line, it is painted at the 
beginning of the following line. This causes the behavior of keyboard shortcuts 
like "End" and "Up" to seem nonsensical to the user, although they might well 
be behaving correctly wrt. the physical location of the cursor (the character 
offset).

To reproduce:
1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
set "Line Wrap" to "After words". Click OK.
2) Create a new plain text file and open it in the editor.
3) Type some gibberish into the editor on a single line that is long enough to 
be broken into several break lines.
4) With the cursor on the first break line, press the "End" key (Command+Right 
on MacBook keyboards). The cursor appears to move one line down, which is 
unexpected. From looking at this situation, the user would now assume that they 
could press the "Up" key to move the cursor back to the previous break line, 
but this will not change the cursor position (because the cursor is logically 
on the previous line).
5) Another unexpected example: Pressing End with cursor before the first 
character of any wrapped paragraph moves cursor down instead of to the end of 
the line.
6) Another unexpected example: Pressing Home anywhere in a paragraph will move 
the cursor to the first character on the paragraph rather than at the first 
character of the wrap line.

Originally reported in BugZilla at 
https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on 
NetBeans 9.0 rc2.

  was:
In an editor with line wrap enabled, the cursor is shown at the wrong physical 
location whenever it is supposed to be located at the end of a wrap line. 
Instead of being painted at the end of the wrap line, it is painted at the 
beginning of the following line. This causes the behavior of keyboard shortcuts 
like "End" and "Up" to seem nonsensical to the user, although they might well 
be behaving correctly wrt. the physical location of the cursor (the character 
offset).

To reproduce:
1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
set "Line Wrap" to "After words". Click OK.
2) Create a new plain text file and open it in the editor.
3) Type some gibberish into the editor on a single line that is long enough to 
be broken into several break lines.
4) With the cursor on the first break line, press the "End" key (Command+Right 
on MacBook keyboards). The cursor appears to move one line down, which is 
unexpected. From looking at this situation, the user would now assume that they 
could press the "Up" key to move the cursor back to the previous break line, 
but this will not change the cursor position (because the cursor is logically 
on the previous line).

Originally reported in BugZilla at 
https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on 
NetBeans 9.0 rc2.


> With line wrap enabled, cursor at end of line is painted at beginning of next 
> line instead
> --
>
> Key: NETBEANS-979
> URL: https://issues.apache.org/jira/browse/NETBEANS-979
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Painting  Printing
>Reporter: Eirik Bakke
>Priority: Major
> Fix For: 9.0
>
>
> In an editor with line wrap enabled, the cursor is shown at the wrong 
> physical location whenever it is supposed to be located at the end of a wrap 
> line. Instead of being painted at the end of the wrap line, it is painted at 
> the beginning of the following line. This causes the behavior of keyboard 
> shortcuts like "End" and "Up" to seem nonsensical to the user, although they 
> might well be behaving correctly wrt. the physical location of the cursor 
> (the character offset).
> To reproduce:
> 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
> set "Line Wrap" to "After words". Click OK.
> 2) Create a new plain text file and open it in the editor.
> 3) Type some gibberish into the editor on a single line that is long enough 
> to be broken into several break lines.
> 4) With the cursor on the first break line, press the "End" key 
> (Command+Right on MacBook keyboards). The cursor appears to move one line 
> down, which is unexpected. From looking at this situation, the user would now 
> assume that they could press the "Up" key to move the cursor back to the 
> previous break line, but this will not change the cursor position (because 
> the cursor is logically on the previous 

[jira] [Created] (NETBEANS-979) With line wrap enabled, cursor at end of line is painted at beginning of next line instead

2018-06-22 Thread Eirik Bakke (JIRA)
Eirik Bakke created NETBEANS-979:


 Summary: With line wrap enabled, cursor at end of line is painted 
at beginning of next line instead
 Key: NETBEANS-979
 URL: https://issues.apache.org/jira/browse/NETBEANS-979
 Project: NetBeans
  Issue Type: Bug
  Components: editor - Painting  Printing
Reporter: Eirik Bakke
 Fix For: 9.0


In an editor with line wrap enabled, the cursor is shown at the wrong physical 
location whenever it is supposed to be located at the end of a wrap line. 
Instead of being painted at the end of the wrap line, it is painted at the 
beginning of the following line. This causes the behavior of keyboard shortcuts 
like "End" and "Up" to seem nonsensical to the user, although they might well 
be behaving correctly wrt. the physical location of the cursor (the character 
offset).

To reproduce:
1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
set "Line Wrap" to "After words". Click OK.
2) Create a new plain text file and open it in the editor.
3) Type some gibberish into the editor on a single line that is long enough to 
be broken into several break lines.
4) With the cursor on the first break line, press the "End" key (Command+Right 
on MacBook keyboards). The cursor appears to move one line down, which is 
unexpected. From looking at this situation, the user would now assume that they 
could press the "Up" key to move the cursor back to the previous break line, 
but this will not change the cursor position (because the cursor is logically 
on the previous line).

Originally reported in BugZilla at 
https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on 
NetBeans 9.0 rc2.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Created] (NETBEANS-978) Visual cursor position not updated when editor resized under line wrap

2018-06-22 Thread Eirik Bakke (JIRA)
Eirik Bakke created NETBEANS-978:


 Summary: Visual cursor position not updated when editor resized 
under line wrap
 Key: NETBEANS-978
 URL: https://issues.apache.org/jira/browse/NETBEANS-978
 Project: NetBeans
  Issue Type: Bug
  Components: editor - Painting  Printing
Affects Versions: 9.0
Reporter: Eirik Bakke


If line wrap is enabled, and the editor window is resized, the text is 
re-wrapped correctly to the new width of the editor. However, the cursor ends 
up in weird places, still blinking.

To reproduce:
1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
set "Line Wrap" to "After words". Click OK.
2) Create a new plain text file and open it in the editor. Type a couple of 
long lines (with some spaces in them)--they will correctly be broken when the 
line reaches the end of the editor window.
3) Now resize the editor window in the horizontal direction, back and forth a 
couple of times. Observe that while the text is re-broken to the new width, the 
cursor tends to end up in non-sensical places (it may seem as if its position 
is only updated if it needs to end up on a new physical line, but not if it 
needs to end up in a different column position). However, as soon as a 
character is typed or an arrow key is pressed, the cursor re-appears in the 
correct place.

Originally reported in BugZilla at 
https://netbeans.org/bugzilla/show_bug.cgi?id=241953 . Still reproducible on 
NetBeans 9.0 rc2.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Resolved] (NETBEANS-971) Can't open tools/options

2018-06-22 Thread Laszlo Kishalmi (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Laszlo Kishalmi resolved NETBEANS-971.
--
Resolution: Information Provided

Well, NetBeans 8.2 goes well with Java 8.

NetBeans 9.0 is in a quite good shape we are cooking the RC-s now. Though it 
hasonly Java SE support.

> Can't open tools/options
> 
>
> Key: NETBEANS-971
> URL: https://issues.apache.org/jira/browse/NETBEANS-971
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Actions/Menu/Toolbar
>Affects Versions: 8.2
> Environment: Product Version: NetBeans IDE 8.2 (Build 201609300101)
> Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2
> Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10
> Runtime: Java(TM) SE Runtime Environment 10.0.1+10
> System: Windows 10 version 10.0 running on amd64; Cp1252; en_GB (nb)
> User directory: C:\Users\bob\AppData\Roaming\NetBeans\8.2
> Cache directory: C:\Users\bob\AppData\Local\NetBeans\Cache\8.2
>Reporter: Bob Findlay
>Priority: Blocker
> Attachments: netbeans.log
>
>
> If I select tools config I get no window appear.  On another computer I've 
> installed the same version of netbeans and it works fine.
> I didn't have an api.properties so I tried creating one in 
> C:\Users\bob\AppData\Roaming\NetBeans\8.2\config\Preferences\org\netbeans\modules\options
> containing 
>  
> OptionsHeight = 500
> OptionsWidth = 871
> OptionsX = 100
> OptionsY = 117
>  
> but it didn't help
> log file attached



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-977) Improve text layout in word wrap mode

2018-06-22 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated NETBEANS-977:

Labels: pull-request-available  (was: )

> Improve text layout in word wrap mode
> -
>
> Key: NETBEANS-977
> URL: https://issues.apache.org/jira/browse/NETBEANS-977
> Project: NetBeans
>  Issue Type: Improvement
>  Components: editor - Formatting  Indentation, editor - Painting 
>  Printing
>Affects Versions: 9.0
>Reporter: Eirik Bakke
>Priority: Minor
>  Labels: pull-request-available
> Attachments: wrappingdiff.png
>
>
> The NetBeans editor's word wrap feature, which can be enabled via 
> Preferences->Editor->Formatting->Line Wrap->After Words, currently has a few 
> quirks that makes wrapped text hard to read. I have prepared a patch which 
> makes the following improvements, as illustrated in the attached before/after 
> screenshot:
> 1) In HighlightsViewUtils.breakView, use a proper java.text.BreakIterator to 
> split text instead of the previous hand-coded text wrapping logic (this was 
> in fact suggested as a TODO in the previous code). This, in particular, 
> avoids putting spaces and punctuation at the beginning of a wrap line, making 
> the NetBeans editor work more like other editors. This fixes the BugZilla bug 
> [242113|https://netbeans.org/bugzilla/show_bug.cgi?id=242113].
> 2) Handle words that are longer than the preferred maximum width properly. 
> The long word still won't be broken, but at least the rest of the paragraph 
> will--previously the entire rest of the paragraph would remain unbroken in 
> this case.
> 3) Allow whitespace at the end of a wrap line to extend beyond the preferred 
> viewport width (like in jEdit and other editors, including the in-browser 
> editor I'm typing this JIRA issue description in). This usually saves one 
> character of horizontal space for regular text paragraphs.
> 4) Don't display a "line continuation character" to indicate that a line has 
> been wrapped. It clutters the display, takes up an extra character of 
> horizontal space, and does not work well with rule (3) above. Besides, in the 
> NetBeans code editor, the equivalent information is already communicated to 
> the user by the line numbering to the left. This fixes the BugZilla bug 
> [213829|https://netbeans.org/bugzilla/show_bug.cgi?id=213829].
> Besides improving the word wrap feature for use in the NetBeans editor, this 
> patch also makes NetBeans' EditorKit more useful for standalone use in a 
> JEditorPane, e.g. in NetBeans Platform applications. For instance, my own 
> platform application uses NetBeans' EditorKit to provide editing of text 
> paragraphs and spreadsheet formulas in a spreadsheet-like table widget, where 
> horizontal space is at a premium.
> Note that word wrapping boundary computation logic exists in two different 
> places in the editor.lib2 module: in 
> o.n.modules.editor.lib2.view.HighlightViewUtils.breakView , and in 
> o.n.modules.editor.lib2.view.WrapInfoUpdater.getWordInfo. The logic changed 
> in this patch is that of HighlightViewUtils.breakView. The 
> WrapInfoUpdater.getWordInfo routine seems to be a fall-back path that is only 
> used for View implementations that do not use HighlightViewUtils.breakView, 
> or when the latter fails. I was never able to make 
> WrapInfoUpdater.getWordInfo return non-null during a real editor session, 
> having tried word wrapping in Java source files, including with collapsed 
> methods (which I know involves a special kind of View), and selected text (to 
> try to trigger the old BugZilla bugs 
> [183219|https://netbeans.org/bugzilla/show_bug.cgi?id=183219] and 
> [189554|https://netbeans.org/bugzilla/show_bug.cgi?id=189554], which were 
> mentioned in the commits around the related code in WrapInfoUpdater). To 
> avoid breaking things, I have _not_ changed the logic in 
> WrapInfoUpdater.getWordInfo. Miloslav Metelka might be able to tell whether 
> the latter is really "dead code" or not.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-977) Improve text layout in word wrap mode

2018-06-22 Thread Eirik Bakke (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-977:
-
Description: 
The NetBeans editor's word wrap feature, which can be enabled via 
Preferences->Editor->Formatting->Line Wrap->After Words, currently has a few 
quirks that makes wrapped text hard to read. I have prepared a patch which 
makes the following improvements, as illustrated in the attached before/after 
screenshot:

1) In HighlightsViewUtils.breakView, use a proper java.text.BreakIterator to 
split text instead of the previous hand-coded text wrapping logic (this was in 
fact suggested as a TODO in the previous code). This, in particular, avoids 
putting spaces and punctuation at the beginning of a wrap line, making the 
NetBeans editor work more like other editors. This fixes the BugZilla bug 
[242113|https://netbeans.org/bugzilla/show_bug.cgi?id=242113].
2) Handle words that are longer than the preferred maximum width properly. The 
long word still won't be broken, but at least the rest of the paragraph 
will--previously the entire rest of the paragraph would remain unbroken in this 
case.
3) Allow whitespace at the end of a wrap line to extend beyond the preferred 
viewport width (like in jEdit and other editors, including the in-browser 
editor I'm typing this JIRA issue description in). This usually saves one 
character of horizontal space for regular text paragraphs.
4) Don't display a "line continuation character" to indicate that a line has 
been wrapped. It clutters the display, takes up an extra character of 
horizontal space, and does not work well with rule (3) above. Besides, in the 
NetBeans code editor, the equivalent information is already communicated to the 
user by the line numbering to the left. This fixes the BugZilla bug 
[213829|https://netbeans.org/bugzilla/show_bug.cgi?id=213829].

Besides improving the word wrap feature for use in the NetBeans editor, this 
patch also makes NetBeans' EditorKit more useful for standalone use in a 
JEditorPane, e.g. in NetBeans Platform applications. For instance, my own 
platform application uses NetBeans' EditorKit to provide editing of text 
paragraphs and spreadsheet formulas in a spreadsheet-like table widget, where 
horizontal space is at a premium.

Note that word wrapping boundary computation logic exists in two different 
places in the editor.lib2 module: in 
o.n.modules.editor.lib2.view.HighlightViewUtils.breakView , and in 
o.n.modules.editor.lib2.view.WrapInfoUpdater.getWordInfo. The logic changed in 
this patch is that of HighlightViewUtils.breakView. The 
WrapInfoUpdater.getWordInfo routine seems to be a fall-back path that is only 
used for View implementations that do not use HighlightViewUtils.breakView, or 
when the latter fails. I was never able to make WrapInfoUpdater.getWordInfo 
return non-null during a real editor session, having tried word wrapping in 
Java source files, including with collapsed methods (which I know involves a 
special kind of View), and selected text (to try to trigger the old BugZilla 
bugs [183219|https://netbeans.org/bugzilla/show_bug.cgi?id=183219] and 
[189554|https://netbeans.org/bugzilla/show_bug.cgi?id=189554], which were 
mentioned in the commits around the related code in WrapInfoUpdater). To avoid 
breaking things, I have _not_ changed the logic in WrapInfoUpdater.getWordInfo. 
Miloslav Metelka might be able to tell whether the latter is really "dead code" 
or not.

  was:
The NetBeans editor's word wrap feature, which can be enabled via 
Preferences->Editor->Formatting->Line Wrap->After Words, currently has a few 
quirks that makes wrapped text hard to read. I have prepared a patch which 
makes the following improvements, as illustrated in the attached before/after 
screenshot:

1) In HighlightsViewUtils.breakView, use a proper java.text.BreakIterator to 
split text instead of the previous hand-coded text wrapping logic (this was in 
fact suggested as a TODO in the previous code). This, in particular, avoids 
putting spaces and punctuation at the beginning of a wrap line, making the 
NetBeans editor work more like other editors. This fixes the BugZilla bug 
[242113|https://netbeans.org/bugzilla/show_bug.cgi?id=242113].
2) Handle words that are longer than the preferred maximum width properly. The 
long word still won't be broken, but at least the rest of the paragraph 
will--previously the entire rest of the paragraph would remain unbroken in this 
case.
3) Allow whitespace at the end of a wrap line to extend beyond the preferred 
viewport width (like in jEdit and other editors, including the in-browser 
editor I'm typing this JIRA issue description in). This usually saves one 
character of horizontal space for regular text paragraphs.
4) Don't display a "line continuation character" to indicate that a line has 
been wrapped. It clutters the display, takes up an extra character of 

[jira] [Updated] (NETBEANS-977) Improve text layout in word wrap mode

2018-06-22 Thread Eirik Bakke (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-977:
-
Description: 
The NetBeans editor's word wrap feature, which can be enabled via 
Preferences->Editor->Formatting->Line Wrap->After Words, currently has a few 
quirks that makes wrapped text hard to read. I have prepared a patch which 
makes the following improvements, as illustrated in the attached before/after 
screenshot:

1) In HighlightsViewUtils.breakView, use a proper java.text.BreakIterator to 
split text instead of the previous hand-coded text wrapping logic (this was in 
fact suggested as a TODO in the previous code). This, in particular, avoids 
putting spaces and punctuation at the beginning of a wrap line, making the 
NetBeans editor work more like other editors. This fixes the BugZilla bug 
[242113|https://netbeans.org/bugzilla/show_bug.cgi?id=242113].
2) Handle words that are longer than the preferred maximum width properly. The 
long word still won't be broken, but at least the rest of the paragraph 
will--previously the entire rest of the paragraph would remain unbroken in this 
case.
3) Allow whitespace at the end of a wrap line to extend beyond the preferred 
viewport width (like in jEdit and other editors, including the in-browser 
editor I'm typing this JIRA issue description in). This usually saves one 
character of horizontal space for regular text paragraphs.
4) Don't display a "line continuation character" to indicate that a line has 
been wrapped. It clutters the display, takes up an extra character of 
horizontal space, and does not work well with rule (3) above. Besides, in the 
NetBeans code editor, the equivalent information is already communicated to the 
user by the line numbering to the left. This fixes the BugZilla bug 
[213829|https://netbeans.org/bugzilla/show_bug.cgi?id=213829].

Besides improving the word wrap feature for use in the NetBeans editor, this 
patch also makes NetBeans' EditorKit more useful for standalone use in a 
JEditorPane, e.g. in NetBeans Platform applications. For instance, my own 
platform application uses NetBeans' EditorKit to provide editing of text 
paragraphs and spreadsheet formulas in a spreadsheet-like table widget, where 
horizontal space is at a premium.

Note that word wrapping boundary computation logic exists in two different 
places in the editor.lib2 module: in 
o.n.modules.editor.lib2.view.HighlightViewUtils.breakView , and in 
o.n.modules.editor.lib2.view.WrapInfoUpdater.getWordInfo. The logic changed in 
this patch is that of HighlightViewUtils.breakView. The 
WrapInfoUpdater.getWordInfo routine seems to be a fall-back path that is only 
used for View implementations that do not use HighlightViewUtils.breakView, or 
when the latter fails. I was never able to make WrapInfoUpdater.getWordInfo 
return non-null , having tried word wrapping in Java source files, including 
with collapsed methods (which I know involves a special kind of View), and 
selected text (to try to trigger the old BugZilla bugs 
[183219|https://netbeans.org/bugzilla/show_bug.cgi?id=183219] and 
[189554|https://netbeans.org/bugzilla/show_bug.cgi?id=189554], which were 
mentioned in the commits around the related code in WrapInfoUpdater). To avoid 
breaking things, I have _not_ changed the logic in WrapInfoUpdater.getWordInfo. 
Miloslav Metelka might be able to tell whether the latter is really "dead code" 
or not.

  was:
The NetBeans editor's word wrap feature, which can be enabled via 
Preferences->Editor->Formatting->Line Wrap->After Words, currently has a few 
quirks that makes wrapped text hard to read. I have prepared a patch which 
makes the following improvements, as illustrated in the attached before/after 
screenshot:

1) In HighlightsViewUtils.breakView, use a proper java.text.BreakIterator to 
split text instead of the previous hand-coded text wrapping logic (this was in 
fact suggested as a TODO in the previous code). This, in particular, avoids 
putting spaces and punctuation at the beginning of a wrap line, making the 
NetBeans editor work more like other editors. This fixes the BugZilla bug 
[242113|https://netbeans.org/bugzilla/show_bug.cgi?id=242113].
2) Handle words that are longer than the preferred maximum width properly. The 
long word still won't be broken, but at least the rest of the paragraph 
will--previously the entire rest of the paragraph would remain unbroken in this 
case.
3) Allow whitespace at the end of a wrap line to extend beyond the preferred 
viewport width (like in jEdit and other editors, including the in-browser 
editor I'm typing this JIRA issue description in). This usually saves one 
character of horizontal space for regular text paragraphs.
4) Don't display a "line continuation character" to indicate that a line has 
been wrapped. It clutters the display, takes up an extra character of 
horizontal space, and does not 

[jira] [Updated] (NETBEANS-977) Improve text layout in word wrap mode

2018-06-22 Thread Eirik Bakke (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-977:
-
Description: 
The NetBeans editor's word wrap feature, which can be enabled via 
Preferences->Editor->Formatting->Line Wrap->After Words, currently has a few 
quirks that makes wrapped text hard to read. I have prepared a patch which 
makes the following improvements, as illustrated in the attached before/after 
screenshot:

1) In HighlightsViewUtils.breakView, use a proper java.text.BreakIterator to 
split text instead of the previous hand-coded text wrapping logic (this was in 
fact suggested as a TODO in the previous code). This, in particular, avoids 
putting spaces and punctuation at the beginning of a wrap line, making the 
NetBeans editor work more like other editors. This fixes the BugZilla bug 
[242113|https://netbeans.org/bugzilla/show_bug.cgi?id=242113].
2) Handle words that are longer than the preferred maximum width properly. The 
long word still won't be broken, but at least the rest of the paragraph 
will--previously the entire rest of the paragraph would remain unbroken in this 
case.
3) Allow whitespace at the end of a wrap line to extend beyond the preferred 
viewport width (like in jEdit and other editors, including the in-browser 
editor I'm typing this JIRA issue description in). This usually saves one 
character of horizontal space for regular text paragraphs.
4) Don't display a "line continuation character" to indicate that a line has 
been wrapped. It clutters the display, takes up an extra character of 
horizontal space, and does not work well with rule (3) above. Besides, in the 
NetBeans code editor, the equivalent information is already communicated to the 
user by the line numbering to the left. This fixes the BugZilla bug 
[213829|https://netbeans.org/bugzilla/show_bug.cgi?id=213829].

Besides improving the word wrap feature for use in the NetBeans editor, this 
patch also makes NetBeans' EditorKit more useful for standalone use in a 
JEditorPane, e.g. in NetBeans Platform applications. For instance, my own 
platform application uses NetBeans' EditorKit to provide editing of text 
paragraphs and spreadsheet formulas in a spreadsheet-like table widget, where 
horizontal space is at a premium.

  was:
The NetBeans editor's word wrap feature, which can be enabled via 
Preferences->Editor->Formatting->Line Wrap->After Words, currently has a few 
quirks that makes wrapped text hard to read. I have prepared a patch which 
makes the following improvements, as illustrated in the attached before/after 
screenshot:

1) In HighlightsViewUtils.breakView, use a proper java.text.BreakIterator to 
split text instead of the previous hand-coded text wrapping logic (this was in 
fact suggested as a TODO in the previous code). This, in particular, avoids 
putting spaces and punctuation at the beginning of a wrap line, making the 
NetBeans editor work more like other editors. This fixes the BugZilla bug 
[242113|https://netbeans.org/bugzilla/show_bug.cgi?id=242113].
2) Handle words that are longer than the preferred maximum width properly. The 
long word still won't be broken, but at least the rest of the paragraph 
will--previously the entire rest of the paragraph would remain unbroken in this 
case.
3) Allow whitespace at the end of a wrap line to extend beyond the preferred 
viewport width (like in jEdit and other editors, including the in-browser 
editor I'm typing this JIRA issue description in). This usually saves one 
character of horizontal space for regular text paragraphs.
4) Don't display a "line continuation character" to indicate that a line has 
been wrapped. It clutters the display, takes up an extra character of 
horizontal space, and does not work well with rule (3) above. This fixes the 
BugZilla bug [213829|https://netbeans.org/bugzilla/show_bug.cgi?id=213829].

Besides improving the word wrap feature for use in the NetBeans editor, this 
patch also makes NetBeans' EditorKit more useful for standalone use in a 
JEditorPane, e.g. in NetBeans Platform applications. For instance, my own 
platform application uses NetBeans' EditorKit to provide editing of text 
paragraphs and spreadsheet formulas in a spreadsheet-like table widget, where 
horizontal space is at a premium.


> Improve text layout in word wrap mode
> -
>
> Key: NETBEANS-977
> URL: https://issues.apache.org/jira/browse/NETBEANS-977
> Project: NetBeans
>  Issue Type: Improvement
>  Components: editor - Formatting  Indentation, editor - Painting 
>  Printing
>Affects Versions: 9.0
>Reporter: Eirik Bakke
>Priority: Minor
> Attachments: wrappingdiff.png
>
>
> The NetBeans editor's word wrap feature, which can be enabled via 
> Preferences->Editor->Formatting->Line Wrap->After Words, currently 

[jira] [Created] (NETBEANS-977) Improve text layout in word wrap mode

2018-06-22 Thread Eirik Bakke (JIRA)
Eirik Bakke created NETBEANS-977:


 Summary: Improve text layout in word wrap mode
 Key: NETBEANS-977
 URL: https://issues.apache.org/jira/browse/NETBEANS-977
 Project: NetBeans
  Issue Type: Improvement
  Components: editor - Formatting  Indentation, editor - Painting 
 Printing
Affects Versions: 9.0
Reporter: Eirik Bakke
 Attachments: wrappingdiff.png

The NetBeans editor's word wrap feature, which can be enabled via 
Preferences->Editor->Formatting->Line Wrap->After Words, currently has a few 
quirks that makes wrapped text hard to read. I have prepared a patch which 
makes the following improvements, as illustrated in the attached before/after 
screenshot:

1) In HighlightsViewUtils.breakView, use a proper java.text.BreakIterator to 
split text instead of the previous hand-coded text wrapping logic (this was in 
fact suggested as a TODO in the previous code). This, in particular, avoids 
putting spaces and punctuation at the beginning of a wrap line, making the 
NetBeans editor work more like other editors. This fixes the BugZilla bug 
[242113|https://netbeans.org/bugzilla/show_bug.cgi?id=242113].
2) Handle words that are longer than the preferred maximum width properly. The 
long word still won't be broken, but at least the rest of the paragraph 
will--previously the entire rest of the paragraph would remain unbroken in this 
case.
3) Allow whitespace at the end of a wrap line to extend beyond the preferred 
viewport width (like in jEdit and other editors, including the in-browser 
editor I'm typing this JIRA issue description in). This usually saves one 
character of horizontal space for regular text paragraphs.
4) Don't display a "line continuation character" to indicate that a line has 
been wrapped. It clutters the display, takes up an extra character of 
horizontal space, and does not work well with rule (3) above. This fixes the 
BugZilla bug [213829|https://netbeans.org/bugzilla/show_bug.cgi?id=213829].

Besides improving the word wrap feature for use in the NetBeans editor, this 
patch also makes NetBeans' EditorKit more useful for standalone use in a 
JEditorPane, e.g. in NetBeans Platform applications. For instance, my own 
platform application uses NetBeans' EditorKit to provide editing of text 
paragraphs and spreadsheet formulas in a spreadsheet-like table widget, where 
horizontal space is at a premium.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-971) Can't open tools/options

2018-06-22 Thread Bob Findlay (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520322#comment-16520322
 ] 

Bob Findlay commented on NETBEANS-971:
--

yes, netbeans 9 doesn't have a problem.

what version of JDK should I use if I don't want to use the beta of 9, but 8.2?

> Can't open tools/options
> 
>
> Key: NETBEANS-971
> URL: https://issues.apache.org/jira/browse/NETBEANS-971
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Actions/Menu/Toolbar
>Affects Versions: 8.2
> Environment: Product Version: NetBeans IDE 8.2 (Build 201609300101)
> Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2
> Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10
> Runtime: Java(TM) SE Runtime Environment 10.0.1+10
> System: Windows 10 version 10.0 running on amd64; Cp1252; en_GB (nb)
> User directory: C:\Users\bob\AppData\Roaming\NetBeans\8.2
> Cache directory: C:\Users\bob\AppData\Local\NetBeans\Cache\8.2
>Reporter: Bob Findlay
>Priority: Blocker
> Attachments: netbeans.log
>
>
> If I select tools config I get no window appear.  On another computer I've 
> installed the same version of netbeans and it works fine.
> I didn't have an api.properties so I tried creating one in 
> C:\Users\bob\AppData\Roaming\NetBeans\8.2\config\Preferences\org\netbeans\modules\options
> containing 
>  
> OptionsHeight = 500
> OptionsWidth = 871
> OptionsX = 100
> OptionsY = 117
>  
> but it didn't help
> log file attached



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-975) Template Wizard does not create files on config FS

2018-06-22 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated NETBEANS-975:

Labels: pull-request-available  (was: )

> Template Wizard does not create files on config FS
> --
>
> Key: NETBEANS-975
> URL: https://issues.apache.org/jira/browse/NETBEANS-975
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Data Systems
>Reporter: Svatopluk Dedic
>Assignee: Svatopluk Dedic
>Priority: Major
>  Labels: pull-request-available
>
> I wanted to use the
> {noformat}
> o.o.loaders.TemplateWizard{noformat}
> to create some files on config FS. I have vound that when the Wizard 
> completes, the resulting FileObject is placed correctly, but comes from the 
> underlying physical filesystem. Then checks like the following fail:
>  
> {code:java}
> wizard.setTargetFolder(DataFolder.findFolder(FileUtil.getConfigFile("scripts"));
> Set result = wizard.instantiate();
> FileObject fo = result.iterator().next().getPrimaryFile();
> FileObject cfRoot = FileUtil.getConfigRoot(); 
> if (FileUtil.isParentOf(cfRoot, fo)) {
>   // never reached
> }
> {code}
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-811) Screen doesn't scroll on shortcut key after change from Chinese input method back to English

2018-06-22 Thread Paul Chu (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Chu updated NETBEANS-811:
--
Summary: Screen doesn't scroll on shortcut key after change from Chinese 
input method back to English  (was: Screen does scroll on shortcut key after 
change from Chinese input method back to English)

> Screen doesn't scroll on shortcut key after change from Chinese input method 
> back to English
> 
>
> Key: NETBEANS-811
> URL: https://issues.apache.org/jira/browse/NETBEANS-811
> Project: NetBeans
>  Issue Type: Bug
>Reporter: Paul Chu
>Priority: Major
>
> Product Version = NetBeans IDE 8.2 (Build 201609300101)
>  Operating System = Linux version 4.13.0-41-generic running on amd64
>  Java; VM; Vendor = 1.8.0_171
>  Runtime = Java HotSpot(TM) 64-Bit Server VM 25.171-b11
> STEPS:
>  * Change to Chinese input method and type something.
>  * Change back to English input method
>  * Key End, Ctrl-Home not work, screen will not scroll to cursor position.
> ACTUAL:
>  nothing happens
> EXPECTED:
>  Screen scroll to cursor position



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Created] (NETBEANS-976) Template wizard does not work well for virtual folders on config fs

2018-06-22 Thread Svatopluk Dedic (JIRA)
Svatopluk Dedic created NETBEANS-976:


 Summary: Template wizard does not work well for virtual folders on 
config fs
 Key: NETBEANS-976
 URL: https://issues.apache.org/jira/browse/NETBEANS-976
 Project: NetBeans
  Issue Type: Bug
  Components: platform - Data Systems
Reporter: Svatopluk Dedic


Suppose the wizard is configured with a folder in config fs:

 
{code:java}
wizard.setTargetFolder(DataFolder.findFolder(FileUtil.getConfigFile("scripts"));
 
{code}
and that the "scripts" folder is empty and present only in the XML layers of 
some module.

The Wizard is unable to create files in such on config FS; it converts 
FileObject to File quite early and if the target folder is not yet materialized 
on disk, the Wizard behaves as if no target folder was specified.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Created] (NETBEANS-975) Template Wizard does not create files on config FS

2018-06-22 Thread Svatopluk Dedic (JIRA)
Svatopluk Dedic created NETBEANS-975:


 Summary: Template Wizard does not create files on config FS
 Key: NETBEANS-975
 URL: https://issues.apache.org/jira/browse/NETBEANS-975
 Project: NetBeans
  Issue Type: Bug
  Components: platform - Data Systems
Reporter: Svatopluk Dedic
Assignee: Svatopluk Dedic


I wanted to use the
{noformat}
o.o.loaders.TemplateWizard{noformat}
to create some files on config FS. I have vound that when the Wizard completes, 
the resulting FileObject is placed correctly, but comes from the underlying 
physical filesystem. Then checks like the following fail:

 
{code:java}
wizard.setTargetFolder(DataFolder.findFolder(FileUtil.getConfigFile("scripts"));
Set result = wizard.instantiate();
FileObject fo = result.iterator().next().getPrimaryFile();
FileObject cfRoot = FileUtil.getConfigRoot(); 
if (FileUtil.isParentOf(cfRoot, fo)) {
  // never reached
}
{code}
 

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-860) Proposed new hint "Convert Lambda to Use 'var' Parameter Types" for Lambda expression

2018-06-22 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated NETBEANS-860:

Labels: JDK11-VarInLambda pull-request-available  (was: JDK11-VarInLambda)

> Proposed new hint "Convert Lambda to Use 'var' Parameter Types"  for Lambda 
> expression
> --
>
> Key: NETBEANS-860
> URL: https://issues.apache.org/jira/browse/NETBEANS-860
> Project: NetBeans
>  Issue Type: Improvement
>Reporter: ARUNAVA SINHA
>Assignee: vikas kumar prabhakar
>Priority: Minor
>  Labels: JDK11-VarInLambda, pull-request-available
>
> Hint "Convert Lambda to Use 'var' Parameter Types" should be enable for below 
> expressions. 
> IntBinaryOperator cal c=  (int x, int y) -> x + y;
>  IntBinaryOperator cal c=  (x, y) -> x + y;
> Proposed fix : 
> IntBinaryOperator calc = (var x, var y) -> x + y;



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Assigned] (NETBEANS-691) Cannot undo conversion of constructor to factory when refactoring in calling class.

2018-06-22 Thread ARUNAVA SINHA (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ARUNAVA SINHA reassigned NETBEANS-691:
--

Assignee: ARUNAVA SINHA

> Cannot undo conversion of constructor to factory when refactoring in calling 
> class. 
> 
>
> Key: NETBEANS-691
> URL: https://issues.apache.org/jira/browse/NETBEANS-691
> Project: NetBeans
>  Issue Type: Bug
>  Components: java - Refactoring
>Affects Versions: 9.0
>Reporter: Manikantan Narender Nath
>Assignee: ARUNAVA SINHA
>Priority: Major
>
> Test Spec: 
> [http://netbeans-vm.apache.org/synergy/client/app/#/specification/351]
> Test Suite: 
> [http://netbeans-vm.apache.org/synergy/client/app/#/suite/2034/v/1]
> Test Case: 
> http://netbeans-vm.apache.org/synergy/client/app/#/case/5158/suite/2034/v/1
> Environment
> *Product Version:* Apache NetBeans IDE Dev (Build 
> incubator-netbeans-linux-408-on-20180417)
> *Java:* 10; Java HotSpot(TM) 64-Bit Server VM 10+46
> *Runtime:* Java(TM) SE Runtime Environment 10+46
> *System:* Mac OS X version 10.12.6 running on x86_64; UTF-8; en_IN (nb)
>  
>  
> Steps to reproduce
>  # OPen Project Java refactoring (attached to test spec)
>  # Open replace_constructor.ClassB
>  # Place caret on constructor call on  line ClassA ca2 = new Clas|sA(10, 5) 
> (| is caret position)
>  # From menu choose Refactor|Replace Constructor With Factory
>  # Provide name for factory
>  # Click Refactor
>  # Click undo-redo-undo
> Expected results
>    Able to run step 7   Undo/Redo button is enabled and clickable
> Actual Result
>    Cannot run Step 7 as  Undo button is disabled.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Assigned] (NETBEANS-813) Debugging Java web application - unable to view variable value

2018-06-22 Thread ARUNAVA SINHA (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ARUNAVA SINHA reassigned NETBEANS-813:
--

Assignee: ARUNAVA SINHA

> Debugging Java web application - unable to view variable value
> --
>
> Key: NETBEANS-813
> URL: https://issues.apache.org/jira/browse/NETBEANS-813
> Project: NetBeans
>  Issue Type: Bug
>  Components: debugger - Java
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build 
> incubator-netbeans-release-299-on-20180512)
> Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10
> Runtime: Java(TM) SE Runtime Environment 10.0.1+10
> System: Windows 7 version 6.1 running on amd64; Cp1250; cs_CZ (nb)
>Reporter: Vít Suchánek
>Assignee: ARUNAVA SINHA
>Priority: Major
> Attachments: NB90_opening_variable_value.png
>
>
> Could not open a value of a variable. Resulted in following error:
> java.lang.AssertionError: Debugger lock taken in AWT Event Queue!
> at 
> org.netbeans.modules.debugger.jpda.JPDADebuggerImpl$DebuggerReentrantReadWriteLock$DebuggerReadLock.lock(JPDADebuggerImpl.java:2675)
> at 
> org.netbeans.modules.debugger.jpda.models.JPDAThreadImpl$ThreadReentrantReadWriteLock$ThreadWriteLock.lock(JPDAThreadImpl.java:2555)
> at 
> org.netbeans.modules.debugger.jpda.JPDADebuggerImpl.invokeMethod(JPDADebuggerImpl.java:1066)
> at 
> org.netbeans.modules.debugger.jpda.JPDADebuggerImpl.invokeMethod(JPDADebuggerImpl.java:1008)
> at 
> org.netbeans.modules.debugger.jpda.models.AbstractObjectVariable.getToStringValue(AbstractObjectVariable.java:496)
> at 
> org.netbeans.modules.debugger.jpda.models.AbstractObjectVariable.getToStringValue(AbstractObjectVariable.java:460)
> at 
> org.netbeans.modules.debugger.jpda.models.AbstractObjectVariable.getToStringValue(AbstractObjectVariable.java:424)
> at 
> org.netbeans.modules.debugger.jpda.ui.models.VariablesFormatterFilter.getValueAt(VariablesFormatterFilter.java:498)
> at 
> org.netbeans.modules.debugger.jpda.ui.models.VariablesFormatterFilter.getValueAt(VariablesFormatterFilter.java:425)
> at 
> org.netbeans.modules.debugger.jpda.ui.models.VariablesTreeModelFilter.getValueAt(VariablesTreeModelFilter.java:532)
> at 
> org.netbeans.spi.viewmodel.Models$CompoundTableModel.getValueAt(Models.java:1439)
> at 
> org.netbeans.modules.debugger.jpda.ui.models.PendingActionsFilter.getValueAt(PendingActionsFilter.java:108)
> at 
> org.netbeans.spi.viewmodel.Models$CompoundTableModel.getValueAt(Models.java:1439)
> at 
> org.netbeans.spi.viewmodel.Models$CompoundTableModel.getValueAt(Models.java:1441)
> at 
> org.netbeans.spi.viewmodel.Models$CompoundTableModel.getValueAt(Models.java:1441)
> at 
> org.netbeans.spi.viewmodel.Models$CompoundModel.getValueAt(Models.java:4566)
> at 
> org.netbeans.modules.viewmodel.TreeModelNode$MyProperty.updateShortDescription(TreeModelNode.java:2102)
> at 
> org.netbeans.modules.viewmodel.TreeModelNode$MyProperty.getShortDescription(TreeModelNode.java:2084)
> at 
> org.openide.explorer.propertysheet.CustomEditorAction.actionPerformed(CustomEditorAction.java:287)
> at 
> org.openide.explorer.propertysheet.PropertyPanel$CustomEditorProxyAction.actionPerformed(PropertyPanel.java:1183)
> at 
> org.openide.explorer.view.OutlineView$OutlineViewOutline.editCellAt(OutlineView.java:2103)
> at 
> java.desktop/javax.swing.plaf.basic.BasicTableUI$Handler.adjustSelection(BasicTableUI.java:1127)
> at 
> java.desktop/javax.swing.plaf.basic.BasicTableUI$Handler.mousePressed(BasicTableUI.java:1057)
> at 
> java.desktop/java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:288)
> at 
> java.desktop/java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:287)
> at 
> java.desktop/java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:287)
> at 
> java.desktop/java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:287)
> at java.desktop/java.awt.Component.processMouseEvent(Component.java:6586)
> at 
> java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3342)
> at org.netbeans.swing.outline.Outline.processMouseEvent(Outline.java:1014)
> at java.desktop/java.awt.Component.processEvent(Component.java:6354)
> at java.desktop/java.awt.Container.processEvent(Container.java:2261)
> at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4966)
> at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2319)
> at java.desktop/java.awt.Component.dispatchEvent(Component.java:4798)
> at 
> java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4914)
> at 
> 

[jira] [Commented] (NETBEANS-971) Can't open tools/options

2018-06-22 Thread ARUNAVA SINHA (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520099#comment-16520099
 ] 

ARUNAVA SINHA commented on NETBEANS-971:


It seems you are trying to run JDK-10 in NetBeans-8.2

Please try running JDK-10 in NetBeans-9

One can download it from below link .

[https://netbeans.apache.org/download/nb90/nb90-beta.html]

I ran NetBeans-9 with Open JDK10, tools–>options windows came up properly

 

 

> Can't open tools/options
> 
>
> Key: NETBEANS-971
> URL: https://issues.apache.org/jira/browse/NETBEANS-971
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Actions/Menu/Toolbar
>Affects Versions: 8.2
> Environment: Product Version: NetBeans IDE 8.2 (Build 201609300101)
> Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2
> Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10
> Runtime: Java(TM) SE Runtime Environment 10.0.1+10
> System: Windows 10 version 10.0 running on amd64; Cp1252; en_GB (nb)
> User directory: C:\Users\bob\AppData\Roaming\NetBeans\8.2
> Cache directory: C:\Users\bob\AppData\Local\NetBeans\Cache\8.2
>Reporter: Bob Findlay
>Priority: Blocker
> Attachments: netbeans.log
>
>
> If I select tools config I get no window appear.  On another computer I've 
> installed the same version of netbeans and it works fine.
> I didn't have an api.properties so I tried creating one in 
> C:\Users\bob\AppData\Roaming\NetBeans\8.2\config\Preferences\org\netbeans\modules\options
> containing 
>  
> OptionsHeight = 500
> OptionsWidth = 871
> OptionsX = 100
> OptionsY = 117
>  
> but it didn't help
> log file attached



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-971) Can't open tools/options

2018-06-22 Thread Bob Findlay (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520047#comment-16520047
 ] 

Bob Findlay commented on NETBEANS-971:
--

I haven't installed any plugins.  The first thing I did after installation was 
to try to go into options.

> Can't open tools/options
> 
>
> Key: NETBEANS-971
> URL: https://issues.apache.org/jira/browse/NETBEANS-971
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Actions/Menu/Toolbar
>Affects Versions: 8.2
> Environment: Product Version: NetBeans IDE 8.2 (Build 201609300101)
> Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2
> Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10
> Runtime: Java(TM) SE Runtime Environment 10.0.1+10
> System: Windows 10 version 10.0 running on amd64; Cp1252; en_GB (nb)
> User directory: C:\Users\bob\AppData\Roaming\NetBeans\8.2
> Cache directory: C:\Users\bob\AppData\Local\NetBeans\Cache\8.2
>Reporter: Bob Findlay
>Priority: Blocker
> Attachments: netbeans.log
>
>
> If I select tools config I get no window appear.  On another computer I've 
> installed the same version of netbeans and it works fine.
> I didn't have an api.properties so I tried creating one in 
> C:\Users\bob\AppData\Roaming\NetBeans\8.2\config\Preferences\org\netbeans\modules\options
> containing 
>  
> OptionsHeight = 500
> OptionsWidth = 871
> OptionsX = 100
> OptionsY = 117
>  
> but it didn't help
> log file attached



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists