Re: Snap Packaging of NetBeans

[Emilian Bold]

This being an unofficial package made by you Laszlo, correct?

The '--dangerous' flag doesn't look reassuring.

--emi

‐‐‐ Original Message ‐‐‐

On 19 April 2018 11:13 PM, Laszlo Kishalmi  wrote:

> The (undecided) 9.0 release candidate is available as snap:
> 
> |wget
> 
> https://s3-us-west-2.amazonaws.com/lkishalmi-us-west-2-public/snaps/netbeans_9.0-rc_amd64.snap
> 
> sudo snap install netbeans_9.0-rc_amd64.snap --dangerous --classic|
> 
> On 02/20/2018 05:08 AM, Neil C Smith wrote:
> 
> > On Tue, 20 Feb 2018 at 12:47 constantin drabo drconstan...@hotmail.com
> > 
> > wrote:
> > 
> > > I think it will good . It will be an opportunity to bring back NetBeans to
> > > 
> > > Fedora Community after several years of mistrust .
> > 
> > +1 to providing the possibility of a Snap package, but I'm slightly
> > 
> > intrigued what this mistrust was about, and amused that Snap is a way to
> > 
> > address it!
> > 
> > There is the question of where Flatpak or AppImage sit with this?
> > 
> > Best wishes,
> > 
> > Neil



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

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

Re: HTML/Java API goes to Gradle

[Emilian Bold]

I can't help with the patch. Just 2 remarks:

* didn't notice HTML4J is Maven-based.
* I suppose the Platform does not depend on html4j-mavan-plugin so this new 
Gradle dependency doesn't matter.

--emi

‐‐‐ Original Message ‐‐‐

On 19 April 2018 9:58 PM, Jaroslav Tulach  wrote:

> Hello guys, hello Laszlo.
> 
> For a while I was considering to expand the reach of the HTML/Java class
> 
> post processing. So far we could do that from a command line and via a
> 
> Maven plugin. There is a pull request
> 
> https://github.com/apache/incubator-netbeans-html4j/pull/6 that tries to do
> 
> the same for Gradle. It works to some extent, but a review is needed. It is
> 
> my first real Gradle plugin... Especially the way it inserts itself between
> 
> compilation and packaging feels wild...
> 
> Thanks in advance for your advices at
> 
> https://github.com/apache/incubator-netbeans-html4j/pull/6
> 
> -jt
> 
> PS: The challenge was to build the plugin with Maven. It is not easy to
> 
> find proper Gradle JARs in Maven repositories. As such I decided to resort
> 
> to a bit of reflection in some situations.



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

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

Re: Tracking Issues, Versions

[cowwoc]

The way I've seen JIRA used in the past is:

Setting a "Fix Version" of 9.0 on an unresolved issue implies a desire 
to fix it in that release. When that issue is subsequently marked as 
resolved, the Fix Version indicates what version it was fixed in.


Gili

On 2018-04-22 12:53 AM, Laszlo Kishalmi wrote:

Dear all,

Some of you might noticed that I spent some time digging JIRA up and 
down during the last few days.


I try to identify those issues which we really need to solve before 
9.0 release. Right now it is hard to say. We are working with two 
version field at the moment: Affects version(s) and Fix Version(s).


1. Affects Versions: is quite straight forward: It is used to define
   the version where the issue is found. For me it is not necessary the
   version it shall be fixed.
2. Fix Versions: It can be set when an issue is resolved, marking the
   version where the fix for the issue would be delivered.
3. There is no clear field which would specify if an issue shall be in
   a specific release. Well, I know this is not really agile, but we
   are still kind of waterfall, having infrequent major releases.

To see my problem, check: NETBEANS-656 Help is Broken (Offline and 
On-line) 


Affect Versions: 9.0 (well, yes we do not deliver JavaHelp)

Fix Version: Though there is an improvement PR applied from Geertjan, 
I still can't say it is fixed in 9.0. I set it to Next, though the 
issue is still unresolved and I do not feel myself comfortable with 
that setting either.


We can haggle on the Priority of the issue. It does not really affects 
me, but if we really would like to provide a decent IDE we might need 
to come up with a JavaHelp replacement. So critical would be fine for 
me either. Still this issue would not be delivered in NB 9.0.


I'd propose label those issues which we would really like to deliver 
in 9.0 with "NB9.0", though I'm open any other 
clarifications/suggestions etc. So let's discuss this!






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

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

Tracking Issues, Versions

[Laszlo Kishalmi]

Dear all,

Some of you might noticed that I spent some time digging JIRA up and 
down during the last few days.


I try to identify those issues which we really need to solve before 9.0 
release. Right now it is hard to say. We are working with two version 
field at the moment: Affects version(s) and Fix Version(s).


1. Affects Versions: is quite straight forward: It is used to define
   the version where the issue is found. For me it is not necessary the
   version it shall be fixed.
2. Fix Versions: It can be set when an issue is resolved, marking the
   version where the fix for the issue would be delivered.
3. There is no clear field which would specify if an issue shall be in
   a specific release. Well, I know this is not really agile, but we
   are still kind of waterfall, having infrequent major releases.

To see my problem, check: NETBEANS-656 Help is Broken (Offline and 
On-line) 


Affect Versions: 9.0 (well, yes we do not deliver JavaHelp)

Fix Version: Though there is an improvement PR applied from Geertjan, I 
still can't say it is fixed in 9.0. I set it to Next, though the issue 
is still unresolved and I do not feel myself comfortable with that 
setting either.


We can haggle on the Priority of the issue. It does not really affects 
me, but if we really would like to provide a decent IDE we might need to 
come up with a JavaHelp replacement. So critical would be fine for me 
either. Still this issue would not be delivered in NB 9.0.


I'd propose label those issues which we would really like to deliver in 
9.0 with "NB9.0", though I'm open any other clarifications/suggestions 
etc. So let's discuss this!

Re: IntelliJ IDEA vs Netbeans

[Rodolfo Fortes]

If it's to compare to IntelliJ it must be done with their community
version, that's free like NetBeans but lacks a lot of features.
To me, NetBeans is the best free IDE available to work with Java EE, I
tried Eclipse but I found its interface outdated and not straightforward as
NetBeans, I find it very easy to start a Java EE/Maven project with
NetBeans. A killer feature to me it's a plugin one, the Jeddict plugin! It
helped me a LOT! Sometimes when dealing with legacy systems I need just of
their database, Jeddict helps me to take it and reverse engineering to JPA
Entitys! I didn't find something so easy to work with as this plugin even
in the paid IntelliJ, I hope their developers continue to improve it.

On Sat, Apr 21, 2018 at 7:13 AM, John McDonnell 
wrote:

> @Gili/Laszlo
>
> Jiri already created a dashboard for NetBeans:
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12332455
>
> We also have a Kanban board for all issues (its a little slow loading):
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=216
>
> Regards
>
> John
>
> On 21 April 2018 at 08:35, Antonio  wrote:
>
> > Hi all,
> >
> > We may want to define a NetBeans wide "style guide" or "design
> guidelines"
> > that define:
> >
> > - A NetBeans-wide icon set (Emilian built a webpage for this).
> > - Padding/margins etc.
> > - Maybe an open source font (APLv2) we can use. IBM Plex
> > https://github.com/IBM/plex is SIL licensed (can we use that).
> > - A NetBeans-wide color theme.
> >
> > The "Java Look and Feel Design Guidelines" at
> > http://www.oracle.com/technetwork/java/index-136139.html is indeed
> > obsolete nowadays.
> >
> > Cheers,
> > Antonio
> >
> > On 20/04/18 17:21, Neil C Smith wrote:
> >
> >> On Fri, 20 Apr 2018 at 15:29 John Leon  wrote:
> >>
> >> - Add more padding/borders to the Darcula L as it feels crowded to
> >>> me
> >>>
> >>>
> >>> Funnily enough just been doing exactly that for Praxis LIVE (image at
> >> https://twitter.com/PraxisLIVE/status/984810937159995392 ), and making
> >> it a
> >> bit more responsive to --fontsize. Definitely be interested in helping
> out
> >> with this.
> >>
> >> Best wishes,
> >>
> >> Neil
> >>
> >>
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
>

Re: Netbeans encoding

[Victor Williams Stafusa da Silva]

I'm working right now on a legacy web project that uses a bunch of
System.out.println for logging and debugging. It was plagued by a lot of
encoding problems, and I fixed most of them by forcing everything to be
UTF-8. There is no sense in using the platform default encoding when the
text output is something to be embedded into HTML and juggling/converting
strings of different encodings around is what I considers a form of
torture. Also, reading text/config/html/java/whatever files written in
different encodings and having to guess what is the correct encoding on a
case-by-case basis just makes it a still worse torture.

Also, I done the translation of Checkstyle to Portuguese and the
translation files are encoded in UTF-8. When using them in my project,
Checkstyle prints localized messages of code-style violations, and those
became garbled in the netbeans console. Don't know if this is a Checkstyle
bug, but even if it is, having to do encoding checks and conversions just
to println a String for debugging purposes is a burden that no programmer
should deserve to have. Also, even if it is a Checkstyle bug and someone
gets to fix it, there would be probably more millions of tools out there
with the same bug.

Ok, Netbeans can't do anything to fix a bunch of tools that have encoding
problems. However this show that the hole here is much bigger: the simple
existence of the concept of a default platform encoding is the root cause
of all those problems. Even a simple System.out.println statement may
suffer from this problem because you don't know and can't know (and ideally
shouldn't need to know or care) if the String it is going to the console,
to a file, to a socket or to anywhere else. It only works safely when all
the produced strings born, live and die within the same machine, an
assumption that is and always was simply plain false and wrong. This is why
I strong support the idea of deprecating any methods that rely on the
default platform encoding. Netbeans could also do its part by not ever
relying on that.

Victor Williams Stafusa da Silva

2018-04-21 3:53 GMT-03:00 Tim Boudreau :

> No argument that the situation doesn't need a fix.
>
> But you didn't answer my question:  *What* are you running when the problem
> shows up?  Your own Java project?  If so, Ant, Maven or something else
> (i.e. build system where this is settable/detectable or not?)?  Or some
> application server or third party thing?
>
> What I'm trying to nail down is, what is the point of minimal intervention
> where this could either be detected or made settable.  External processes
> in Java have binary output;  the IDE decides what character set to impose
> over that.  That decision can be improved, but not without knowing what the
> stream is coming from there's no place to start.  Without knowing what it
> is you're looking at the output of when you see this problem, there's no
> progress to be made.
>
> I'm all for UTF-8 everywhere in theory, and on my own systems, but
> defaulting to that is likely to break things for at least as many people as
> it helps.  So, in the interest of solving it with a scalpel instead of a
> sledgehammer, could you give a little detail on where the problematic
> output is coming from and how it is generated?
>
> Thanks,
>
> -Tim
>
> On Fri, Apr 20, 2018 at 8:33 PM, Victor Williams Stafusa da Silva <
> victorwssi...@gmail.com> wrote:
>
> > In my case, I'm running in windows, with the dreaded and hated
> Windows-1252
> > default encoding.
> >
> > Using default OS encoding is really bad for portability and causes a lot
> of
> > encoding problems. See this JEP draft maybe for Java 11:
> > http://openjdk.java.net/jeps/8187041 - There are three proposed
> > alternatives: 1) Keep the status quo; 2) Deprecate all the methods that
> > uses the platform default encoding; 3) Force UTF-8 deing the default
> > regardless of anything.
> >
> > As a speaker of Portuguese, a language that is full of diacritics, I'm
> > already very sick of years and years of being haunted by encoding
> problems
> > in buggy software. But it could be much worse if my language was Chinese
> or
> > Japanese.
> >
> > Since option 1 is unacceptable and 3 is too drastic and dangerous due to
> > backwards-compatibility concerns, I think that this JEP, if it eventually
> > gets delivered, will go to option 2.
> >
> > Anyway, regardless of this JEP or its future, Netbeans should either get
> > the correct encoding in the console window or at least provide an easy
> and
> > accessible way to et the user define it.
> >
> > Victor Williams Stafusa da Silva
> >
> >
> > 2018-04-20 20:00 GMT-03:00 Tim Boudreau :
> >
> > > Your problem is most likely your operating system's default file
> encoding
> > > here (perhaps MacRoman?).  The IDE is assuming that process output is
> > > whatever your operating system's default encoding is, which is the
> right
> > > assumption, since that *is* what command-line 

Re: IntelliJ IDEA vs Netbeans

[John McDonnell]

@Gili/Laszlo

Jiri already created a dashboard for NetBeans:
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12332455

We also have a Kanban board for all issues (its a little slow loading):
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=216

Regards

John

On 21 April 2018 at 08:35, Antonio  wrote:

> Hi all,
>
> We may want to define a NetBeans wide "style guide" or "design guidelines"
> that define:
>
> - A NetBeans-wide icon set (Emilian built a webpage for this).
> - Padding/margins etc.
> - Maybe an open source font (APLv2) we can use. IBM Plex
> https://github.com/IBM/plex is SIL licensed (can we use that).
> - A NetBeans-wide color theme.
>
> The "Java Look and Feel Design Guidelines" at
> http://www.oracle.com/technetwork/java/index-136139.html is indeed
> obsolete nowadays.
>
> Cheers,
> Antonio
>
> On 20/04/18 17:21, Neil C Smith wrote:
>
>> On Fri, 20 Apr 2018 at 15:29 John Leon  wrote:
>>
>> - Add more padding/borders to the Darcula L as it feels crowded to
>>> me
>>>
>>>
>>> Funnily enough just been doing exactly that for Praxis LIVE (image at
>> https://twitter.com/PraxisLIVE/status/984810937159995392 ), and making
>> it a
>> bit more responsive to --fontsize. Definitely be interested in helping out
>> with this.
>>
>> Best wishes,
>>
>> Neil
>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: IntelliJ IDEA vs Netbeans

[Antonio]

Hi all,

We may want to define a NetBeans wide "style guide" or "design 
guidelines" that define:


- A NetBeans-wide icon set (Emilian built a webpage for this).
- Padding/margins etc.
- Maybe an open source font (APLv2) we can use. IBM Plex 
https://github.com/IBM/plex is SIL licensed (can we use that).

- A NetBeans-wide color theme.

The "Java Look and Feel Design Guidelines" at 
http://www.oracle.com/technetwork/java/index-136139.html is indeed 
obsolete nowadays.


Cheers,
Antonio

On 20/04/18 17:21, Neil C Smith wrote:

On Fri, 20 Apr 2018 at 15:29 John Leon  wrote:


- Add more padding/borders to the Darcula L as it feels crowded to me



Funnily enough just been doing exactly that for Praxis LIVE (image at
https://twitter.com/PraxisLIVE/status/984810937159995392 ), and making it a
bit more responsive to --fontsize. Definitely be interested in helping out
with this.

Best wishes,

Neil



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

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

Re: Netbeans encoding

[Tim Boudreau]

No argument that the situation doesn't need a fix.

But you didn't answer my question:  *What* are you running when the problem
shows up?  Your own Java project?  If so, Ant, Maven or something else
(i.e. build system where this is settable/detectable or not?)?  Or some
application server or third party thing?

What I'm trying to nail down is, what is the point of minimal intervention
where this could either be detected or made settable.  External processes
in Java have binary output;  the IDE decides what character set to impose
over that.  That decision can be improved, but not without knowing what the
stream is coming from there's no place to start.  Without knowing what it
is you're looking at the output of when you see this problem, there's no
progress to be made.

I'm all for UTF-8 everywhere in theory, and on my own systems, but
defaulting to that is likely to break things for at least as many people as
it helps.  So, in the interest of solving it with a scalpel instead of a
sledgehammer, could you give a little detail on where the problematic
output is coming from and how it is generated?

Thanks,

-Tim

On Fri, Apr 20, 2018 at 8:33 PM, Victor Williams Stafusa da Silva <
victorwssi...@gmail.com> wrote:

> In my case, I'm running in windows, with the dreaded and hated Windows-1252
> default encoding.
>
> Using default OS encoding is really bad for portability and causes a lot of
> encoding problems. See this JEP draft maybe for Java 11:
> http://openjdk.java.net/jeps/8187041 - There are three proposed
> alternatives: 1) Keep the status quo; 2) Deprecate all the methods that
> uses the platform default encoding; 3) Force UTF-8 deing the default
> regardless of anything.
>
> As a speaker of Portuguese, a language that is full of diacritics, I'm
> already very sick of years and years of being haunted by encoding problems
> in buggy software. But it could be much worse if my language was Chinese or
> Japanese.
>
> Since option 1 is unacceptable and 3 is too drastic and dangerous due to
> backwards-compatibility concerns, I think that this JEP, if it eventually
> gets delivered, will go to option 2.
>
> Anyway, regardless of this JEP or its future, Netbeans should either get
> the correct encoding in the console window or at least provide an easy and
> accessible way to et the user define it.
>
> Victor Williams Stafusa da Silva
>
>
> 2018-04-20 20:00 GMT-03:00 Tim Boudreau :
>
> > Your problem is most likely your operating system's default file encoding
> > here (perhaps MacRoman?).  The IDE is assuming that process output is
> > whatever your operating system's default encoding is, which is the right
> > assumption, since that *is* what command-line utilities will output.  It
> > happens that the process you're running is outputting UTF-8 *rather than*
> > the
> > OS's default encoding.
> >
> > Setting that as a default would be assuming that every operating system
> > uses UTF-8 regardless of what it does - it would be wrong a lot of the
> > time.  It just happens to solve the case that whatever you're running is
> > outputting UTF-8 in spite of what the operating system provides.
> >
> > That's not that uncommon, but the right solution is to *detect* that the
> > output is UTF-8 when the IDE runs whatever it is you're running.
> >
> > So... what are you running?  Is this project output?  If so, what kind of
> > project?  Or server output of some kind?  A correct fix would be to (if
> > possible), detect what that is and that it will output UTF-8, and have
> the
> > IDE open the output of that process with the right encoding.
> >
> > -Tim
> >
> > On Fri, Apr 20, 2018 at 6:18 PM, Victor Williams Stafusa da Silva <
> > victorwssi...@gmail.com> wrote:
> >
> > > I frequently had some long-standing problems with the console output
> > > encoding in Netbeans. Which always presented garbled non-ascii
> characters
> > > for me.
> > >
> > > After deciding that it was enough, I went to search for a solution and
> > did
> > > found a very simple one in StackOverflow. Just add
> > -J-Dfile.encoding=UTF-8
> > > into the netbeans_default_options line of netbeans.conf file and voilà,
> > it
> > > works!
> > >
> > > However, this make me think about it:
> > >
> > > 1. Is there a reason to not add it there by default?
> > >
> > > 2. If it can't be added there by default for some reason, can it at
> least
> > > be something more user-friendly and less arcane to be configured by the
> > > normal user?
> > >
> > > Victor Williams Stafusa da Silva
> > >
> >
> >
> >
> > --
> > http://timboudreau.com
> >
>



-- 
http://timboudreau.com

Re: IntelliJ IDEA vs Netbeans

[cowwoc]

Laszlo,

Thank you for taking the time to do this, but I don't see any screenshot 
attached to your email. Maybe the mailing list stripped it out?


Can someone help Laszlo share his dashboard publicly (permission fix)?

Gili

On 2018-04-20 7:14 PM, Laszlo Kishalmi wrote:

Dear all,


I've created a JIRA Dashboard to be able to see where are we now.

Actually JIRA is not that bad if you start to use it well. I'd share 
my dashboard if you find that useful, though I do not have the rights 
for it now, so I've attached a screenshot of that.


Just some short stats on the open issues: We have 571 issues already 
in the JIRA 526 of them are not assigned to anyone. Also we have 43 
open issues with PR-s.
The sad thing is that we have 4 blocker and 19 critical issues with no 
responsible persons.


If someone has no time to code, just trying to test/reproduce and 
clarify these issues would make a tremendous contribution to the project.


As of catching up with other IDEs. Good and detailed feature requests 
are welcome into the JIRA and on a mail thread as well.


On 04/20/2018 03:12 PM, Geertjan Wielenga wrote:
“25 days and nothing” — yes, that’s how it’s going to be for a while 
until

we are a real Apache project, whereas right now we’re in process moving
from Oracle to Apache. Though note you’re going to always be responsible
for making your own party — if you provide a PR or issue and no one
responds, create a new discussion thread here, i.e., new from 
scratch, to

discuss it.

Gj

On Saturday, April 21, 2018, Christian Bourque 


wrote:


I have to agree with Gili...


Sometimes it feels that nobody cares... I created a ticket a month ago
about an improvement in the NetBeans Git integration and decided to 
code it

myself.


Then I submitted a PR and eventually the reviewing process started. 
But the
reviewer has had many objections to my request (which is perfectly 
fine). I

told him that the Eclipse JGit library was OSGi based and that it had
external dependencies that were triggered during the bootstrapping of
NetBeans. I even contacted the Eclipse team to tell them that one of 
their

OSGi dependencies wasn't even used in their JGit library, the lead
developer realized that it was a mistake and he fixed it!


After that, I sent more questions and comments to the reviewer to
understand how I could resolve the remaining issues in an acceptable 
way,
but to no avail. The reviewer just stopped answering my questions! 
Now it's
been 25 days and nothing... So, I put a lot of time into this for 
what at

the end?


I don't think that this is how you're going to attract new 
developers to

contribute to this project...


Christian



On Fri, Apr 20, 2018 at 1:36 PM, cowwoc  
wrote:



I did. Multiple times.

One of the issues I brought up was the copy/paste bug I linked to 
below.

When I brought it up in the mailing list in the past I got no replies.

That issue (and its linked counterparts) are very annoying (for 
obvious
reasons). I suspect no one else is experiencing this problem 
because it

seems too major to ignore.

Gili


On 2018-04-20 1:21 PM, Geertjan Wielenga wrote:


Rather than filing hundreds of issues, I recommend you pick one, just

one,

and open a discussion thread around that. Once people have seen and
discussed your issue on the mailing list, probably one of those will
volunteer to tix it.

Gj

On Friday, April 20, 2018, cowwoc  wrote:

This is precisely the kind of fixes I'm talking about. I 
understand that

IntelliJ has many features that Netbeans does not, but I'm primarily
focused on improving the *core* development functionality (this is
because
it impacts all other project types). We've got many of the pieces in
place,
but UI problems make that functionality annoying/slow to use.
Specifically
on the point of 4k monitors, I keep on saying that it is 
impossible to

copy/paste correctly: https://issues.apache.org/

jira/browse/NETBEANS-235

(see linked issues as well)

I have already filed thousands of issues before (literally), but 
those

got
flushed down the drain when we migrated to Apache. I've already 
filed

some
issues in Apache JIRA but for now there hasn't been much movement
(committers are understandably working on their own issues before

looking

at other people's issues). Nothing personal against you guys but I

don't

have the time/energy to re-file all those bug reports. Family

emergencies
are keeping me super busy nowadays and frankly I don't see the 
point of

doing all this work until I see some movement on the issues that I
already
filed.

Gili

On 2018-04-20 10:20 AM, John Leon wrote:

I have been compiling a list myself of things I wanted to improve 
with

NetBeans as a relatively new user. I'll share them here, but I will

also
keep an eye out for the Wiki page that Wade is going to make and 
try

to

contribute there. Here are some of the examples I had in my list:

  - The