Jan Ploski

The parser is not perfect. It seeems to be tripping up on the $batchCnt++ / part specifically.. You could help it by adding parentheses, i.e. write ($batchCnt++) / instead.

I suppose this could be achieved by using a wrapper script for the Perl interpreter (the "Perl executable" in EPIC Preferences). The wrapper could check the command line arguments (specifically for -c), set the enviornment variable if compilation is detected, and then invoke the real Perl interpreter.

There is no option to avoid running BEGIN blocks. Running these blocks is generally essential for "syntax checking" (actually: reporting compilation errors) to be accurate. If you wish to avoid running certain parts of code in BEGIN block, perhaps you can work around by defining some environment variable (only at actual execution time of the script) and checking for it in inside of the (always executed) BEGIN block.

Thanks for the suggestion, but there is very little (almost no) development going on in this project. Also, I do not like "organizations" (but you are of course free to fork and join the organization then).

External content assistant

A prototype implementation is now included in testing 0.7.9. See description in User's Guide and https://github.com/jploski/epic-ide/blob/testing/org.epic.perleditor/src/org/epic/perleditor/editors/util/ExternalAutoComplete.java

External content assistant

Do you experience the "breakpoints ignored" issue in "Hello world" or in some more complex situation. The "breakpoint ignored" issue usually comes down to paths of files as expected by EPIC (and as set up for breakpoints when perl -d is launched) and the paths of files as reported by "perl -d" not matching (despite normalization attempts). How Perl reports appears seems to depend on how the modules are included (e.g. use/require with absolute/relative paths or using @INC with module names). You can...