Integrating the RSyntaxTextArea with Processing.py

joel_moniz

Hi everyone,

My name is Joel Moniz. I'd really love to apply to work with Processing this summer as part of GSoC 2015.

One of the ideas that I had in mind would be to incorporate the RSyntaxTextArea and Autocomplete library with the Python mode, which would together give syntax highlighting, code folding, syntax checking, auto-completion, documentation support, and parameter assistance. This would also serve as a proof of concept for checking the feasibility of updating the JEditTextArea with the RSyntaxTextArea in processing.

Are there any other features that would be nice to have in the processing.py development environment?

Looking forward to the community's feedback :)

Thanks,
Joel

shiffman

I am intrigued by this idea of using Python Mode as a trial run for RSyntaxTextArea. Is there a reason why you think this is preferable over testing RSyntaxTextArea in a stand-alone mode for Processing? Since Python Mode requires a great deal of work to update its compatibility with 3.0 / PDE X (which we hope to do as part of GSOC) my concern would be that it would be difficult to experiment with a new editor base at the same time.

joel_moniz

I was actually considering submitting 2 proposals, one which would involve either a new RSyntaxTextArea Mode (or possibly replacing the JEditTextArea with RSyntaxTextArea on my fork of processing and later possibly merging this with master, although I'm not very sure which would be better),and another having the RSyntaxTextArea integrated into the python mode. The pros that I had seen in each of these methods are as follows:

Separate RSyntaxTextArea Mode:

1. Much, much easier integration with the main repo
2. Bugs reported, features requested will directly pertain to the implementation of the RSyntaxTextArea Mode itself, and features added won't have to be ported later on

Integrating RSyntaxTextArea with Python Mode:

1. The 3.0 already has quite a few of these features (such as syntax checking and auto-completion), while the python mode doesn't
2. Better identification of bugs or new features required- the user base using the python mode is already quite strong, while a new mode from scratch would have to acquire the user base over a period of time

Would it be better if I submitted just one proposal, focusing more on the RSyntaxTextArea Mode (and perhaps doing things in reverse of what I had suggested, creating the RSyntaxTextArea Mode first, and then adding it into the Python Mode later on)? Or would it be better if I drafted both proposals?

A third idea that I had was to:

1. Iron out all the bugs in the Contributions Manager
2. Introduce JUnit Testing, starting with aiming for full coverage of everything related to the Contributions Manager as a warm up, and then moving on to other parts (such as, the Editor and so on).

With respect to the second part of this idea, what percent of coverage would be a good target to reach for? Could you please let me know how this idea sounds?

Thanks,
Joel

shiffman

Thanks for this very thorough explanation. My gut instinct here is to focus on the following:

• Separate RSyntaxTextArea Mode.
• Iron out all the bugs in the Contributions Manager

The plan for Python Mode is to update it to have all the same features as the current Processing 3 (Java) Mode. Both should ultimately be using the same text editor and the features should be mirrored. This work will be happening this summer so it doesn't make sense to try to build RSyntaxTextArea in at the same time.

JonathanFeinberg

Hello, everyone. Now that Python Mode for Processing 3 is a thing, what's the status of this idea? Is it still relevant?

shiffman

You can see more about what Joel accomplished over the summer in this report. (The report will soon be formatted more nicely on the foundation website.)

I can't speak to future plans as to whether RSyntaxArea will be incorporated into the PDE itself as the main editor in future versions of Processing. It's an open question that I think could be discussed again when the Processing 3 dust settles.