RSyntaxTextArea replacement for JTextArea

[Frank Siebenlist]

At the last clojure meetup in SF, Clooj's author Arthur Edelstein pointed me to this RSyntaxTextArea swing component, which support syntax highlighting and more goodies.
http://fifesoft.com/rsyntaxtextarea/index.php

With a little determination and plenty of ignorance, I managed to jar-up V2.0.3 of RSyntaxTextArea and push it into clojars, and then by just replacing "JTextArea()" with "RSyntaxTextArea()", I ended up with a JTextArea compatible text-area that also support syntax highlighting.

Looks nice - i've pushed a development version of clj-ns-browser "1.3.0-SNAPSHOT" to clojars to play with. It will automatically turn-on syntax highlighting if you select to see the source-code for a var.

Thanks to Arthur for the pointer, and the cool work he's doing with Clooj!

Maybe we can incorporate RSyntaxTextArea as a fully supported seesaw component…

-FrankS.

[Dave Ray]

Done. At least in a very simple way:

https://github.com/daveray/seesaw/blob/develop/src/seesaw/rsyntax.clj#L53

You can continue to construct the RSyntaxTextArea in Java, but now you
can do (config! ta :syntax :clojure) or (config! ta :syntax :none).

Cheers,

Dave

[Frank Siebenlist]

Excellent - that was quick…

so it's:

(config! ta :syntax :clojure)

versus

(.setSyntaxEditingStyle ta org.fife.ui.rsyntaxtextarea.SyntaxConstants/SYNTAX_STYLE_CLOJURE)

guess the first syntax is slightly more "clojuresque" ;-)

The only part I'm worried about is the dependency on "my" jar'ed "org.fife.ui/rsyntaxtextarea" in clojars… not even sure if I managed to do the right thing with ant, mvn and just scp'ing the ~/.m2 jar&pom to clojars - it was truly based on trial&error. Maybe a "real" java expert can take that responsibility off my shoulder. We could even ask the maintainers to push their distribution into one of the repo-sites.

-FrankS.

[Frank Siebenlist]

It only seems to work if I require seesaw.rsyntax explicitly, which I understand as you have to register it with widget-option-provider.

This wasn't obvious as I don't create rsyntaxtextarea in the clojure code but in the java-generated file, so i don't call a (seesaw.rsyntax/text-area …)

I see you require a lot of other libs in seesaw.core - is that also to register those widgets?

Real Q: should seesaw.rsyntax be required in seesaw.core?

-FrankS.

[Meikel Brandmeyer]

Hi,

Am Dienstag, 8. Mai 2012 21:03:35 UTC+2 schrieb franks42:

Real Q: should seesaw.rsyntax be required in seesaw.core?

My recommendation: No if it requires external dependencies and the provided functionality is completely optional. eg.  swingx, forms, miglayout, etc. I think this falls in the same category.

Just 0.02€.

Kind regards
Meikel

[Dave Ray]

What Meikel said. I'd type more, but I have no Internet so I'm on my phone. 

 Dave 

[Jeff Rose]

With the imminent rise of seesaw ;-) this seems like a situation that
will continue to pop up more and more often. As we bring more
external libraries into the fold by adding support for binding, css
selection, etc., there could easily be tens or hundreds of libs with
seesaw support, so maybe it would be best to keep the core
abstractions in one library, and then the extension of these
abstractions to swing, JavaFX, rsyntax, and everything else, would go
in separate libraries. Maybe use a common suffix to communicate that
something is a seesaw library too? (e.g. swing-saw, javafx-saw,
rsyntax-saw...)

-Jeff

[Dave Ray]

I agree. I've talked to several people about breaking out useful parts
of Seesaw. Some which are nice standalone abstractions (selectors,
binding, etc), and others which can be considered extensions of Seesaw
(mig, rsyntax, jgoodies, etc). I've been thinking this might be a good
Seesaw 2.0 target since some breaking changes will probably be
inevitable.

So, I'm definitely thinking about it, but without a lot of action at
the moment. Instead of practicing "hammock driven development", I've
been practicing "paint every surface of your house driven development
lately." :)

Cheers,

Dave