Recent Posts

Pages: 1 [2] 3 4 ... 10
Fixed for the next build, or the first hotfix. 
SlickEdit 2018 v23 Beta Discussion / Re: B6: Syntax expansion & tabs
« Last post by patrick on October 18, 2018, 03:01:04 pm »
In a nice instance of serendipity, I made a fix for this from a related java report on the forums.  This will either be in the next build or the first hotfix.
SlickEdit 2018 v23 Beta Discussion / Re: B6: Syntax expansion & tabs
« Last post by jc44 on October 18, 2018, 02:54:58 pm »
There are still issues in RC2 (sorry). Once again if0 is before I type space and if1 is after.  This happened in RC1 too but I sort of hoped it was part of one of the bugs you were already fixing.  The problem is caused by the "#if VLC_VER_3"; the problem goes away if I replace it with a "#if 0".  The issue is actually quite annoying as it applies to all code in the source file after this point (code before is OK).
But even with locating the source dependencies in a Maven project, I'd still not be able to get the "Live Errors", which sounds like much work and could not be put into a point release? Live Errors in Maven probably needs to go into a future release?

So I'll probably end up using Java Project in the short term (until Live Errors in Maven is ever supported), manually setting up tag files for my Maven dependencies, and using my script hack to do debugging if I wanted to debug in SE (I'm using eclipse now for debugging, but would be nice to stay in SE). But in the real short term when I don't have time to hack up the Java Project I'll stick with the Maven project, not index the dependencies, not have Live Errors and use eclipse for debugging until I have time to work the other things out.
Yes. Support for extracting that and locating/locating the source jar files will have to go in the v23 point release.

A script works.  The only gotcha I see is that the parameters passed to the script get a "." where the qualified main class name would normally be.
My 23.0.0 config directory has many files from SE 22, vunxs22*.

Can I safely remove them?
For indexing the dependencies, for Maven the pom.xml says exactly which dependencies my application is using, so limiting indexing to just those jars would do the trick?

In my case I'm writing simple tools in Java, not some big application.

In the case of debugging a maven project when using it as a Java project in SE, I think I know a workaround where I would not need to perform an attach and could debug directly. In the Build->Java Options->JRE it allows to specify "JRE app name". Instead of "java", I could put my script there "myjava", and then "myjava" would repackage the command line options and run mvnDebug instead. Would that work?
It works with openjdk 11, and 10, I didn't check 9. 

@Marcel - agree that some incremental way of dealing with the huge number of jars would be needed.  Or a way for SlickEdit to ask on a tag not found if we should try to find the corresponding source jar on a background thread. 

The ability to pull down source jars was only recently added for our Gradle support, so right now it's only used to pull down the Kotlin and Scala standard library source.  That may expand a little for the point release.
If you are thinking about modularized applications, I doubt SE is ready for that.  It might work for unnamed module mode, I was able to compile but don't know yet if I can debug/run (too busy getting rid of old sun crypto apis).
My work place is using Gradle instead of Maven, but the problems are the same.  In the past I have made suggestions for SE to index the Gradle cache but have changed my mind about that. My cache has over 1000 jars with frequent updates, so indexing that is clearly not workable. I want SE to remain usable as an editor, not keep itself busy indexing 3rd-party libraries which I may never need to dive in. Maybe there is a smarter way to do late/as needed fine-grained indexing, for example when pulling up a 3rd-part class file.

For the heavy Java lifting, I am using Intellij.  It is friendly enough to download the matching sources jars for everything it needs from the Gradle cache.  The price to pay for this is a few minutes of loading time when opening a project. It doesn't do full indexing of the Gradle cache, I think all they do is build a package/class index.  it is enough to debug 3rd-party libraries at the source level and resolve imports.  If you need to clean up import lists, locate unused code, or need refactoring, IntelliJ is your friend.

SE can do certain things very well, but I don't expect it do be a replacement for a full-fledged specialized IDE. It cannot possibly replace VisualStudio or IntelliJ, they have two orders of magnitude more staff to support their products.

Taking a look at it.
Pages: 1 [2] 3 4 ... 10