Default processing-java behavior

[sophacles]

With Processing 2.0 providing the processing-java command there is a good request to make the vim-processing plugin support that by default. I agree with this suggestion, and think that it should be the case concurrent with the Processing 2.0 release (as of the opening of this ticket, 2.0 is still in beta)

Some thoughts on how to support processing-java in a wider sense, and options I see. I would like feedback from users and contributors:

• Keep the functionality as is: basically the change is just have g:use_processing_java=true as the default.
• Add functionality to check the shell environment for the processing_java executable, and if it is there, enable support.
• Tie the use of processing-java into the :Make support in Vim - this would allow users to just use the Make ex command. We would need to write some code to process the output of processing-java and add the result to the quickfix list, but then the ability to jump around to errors is added. This is functionality I personally really like in C and other languages I program in Vim

I don't see any of these as exclusive to the others, but some of them require more work than others, and I'm not sure if there are drawbacks to any of them I'm not seeing right now. The order I laid them out in, seems like a reasonable progression of work for this.

Thoughts everyone?

[vitorgalvao]

I agree with making it the default when Processing 2.0 goes out of beta. Another thing to consider would be to remove the applescript version altogether, in the future.

Regarding your three suggestions, I think the first one should be implemented, and then the focus should be the third one. The way I see it, the first option is que quick one, the third is the bigger (more useful and harder to implement) goal, and the second one is a kind of transitory one, not much different from the first.

Alternatively, maybe the second one should be implemented, instead of the first.

I believe the best option would be to eventually implement the third option, and in the meantime one of the first two (just not both, as they’re not that different in both work needed and result).

[vortura]

It sounds like a reasonable course of action. The ability to jump to errors in option 3 would be really nice.

The only thing that puts me off option two would be getting it working nicely on multiple platforms. Should be easy enough on unix-ish environments, but I'm not sure about Windows.

[crazymaster]

How about using vim-quickrun? https://github.com/thinca/vim-quickrun

[crazymaster]

Processing？それVimで書けるよ！！ - 僕の車輪の再発明

[XedMada]

The third option, integrating with the Make command, would seem most preferable. Even without a fully functional quickfix list, it would allow you to run your file and return to the buffer for editing. In the current implementation of running a shell command this doesn't seem possible and is very aggravating. It looks like integrating with vim-quickrun would help, but you don't want the bundle to be dependent on other bundles for core functionality.

[sophacles]

Hi all,

I was looking at my various github projects, and I noticed my comment on this thread apparently didn't go through. I have created a branch with the start of code using the Make command on this issue. I know it works on my mac, but not sure of other platforms. If anyone else wants to look at the branch issue_7_makeprg and comment please do!

[crazymaster]

I was looking at my various github projects, and I noticed my comment on this thread apparently didn't go through. I have created a branch with the start of code using the Make command on this issue. I know it works on my mac, but not sure of other platforms. If anyone else wants to look at the branch issue_7_makeprg and comment please do!

I confirmed it works on Ubuntu.

[sophacles]

Thanks for verifying that @crazymaster !

[crazymaster]

Also, I confirmed it works on Windows. :+1: to merge

[sophacles]

Thanks for that verification too!

[sophacles]

Merged the change for this into master as of 4fc6c7895ebc733d5b7eca43f6c2243be4490afd