Flymake/Flycheck about malabar-mode

[m0smith]

Same as buzztaiki#11

[m0smith]

Flycheck requires an external command. This one seems to work:

emacsclient -e "(malabar-compile-files 
                 (list \"c:/Users/Smith/projects/tester/src/main/java/LabChar.java\") nil)"

[m0smith]

emacsclient -e "(malabar-compile-buffer "App.java" t) " works even better

[m0smith]

Info on extending flycheck http://flycheck.github.io/Extending.html

[m0smith]

I decided to shell out to javac directly. If flycheck/flycheck#169 is ever completed, I will look at calling the compiler using Groovy instead.

[m0smith]

Added malabar-flycheck. To enable, load that file.

[rob5n]

So if I understand correctly, you are hoping for flycheck to be able to call a function that requests the running malabar JVM to do a compile, similar to the existing way malabar compiles a file (using Compile.groovy). But at the moment flycheck has to run a program in a new process for each check it makes, so you cannot do that directly.

You are going to have flymake run a shell calling javac. Won't that be very slow? Couldn't you have it run something light that communicates with the existing malabar groovy JVM to do a compile?

(In any case I'm grateful for you adding this feature)

[m0smith]

You understand correctly.

I had planned to use emacsclient to call the running emacs but the further I got down that path, the more problems I encountered. I was going to have to do some things to capture the output and redirect it for instance.

I did some experiments with javac and at least on my boxes the performance was more than adequate. I have been using it for a day or so and it has not caused any problems or slowdowns. To be honest I was pleasantly surprised with how well it behaved.

I will continue to monitor flycheck/flycheck#169. When it is completed I will look at then calling Compile.groovy instead.

You are welcome. It is nice to be appreciated.

[rob5n]

I'm trying this out, but it's not working quite as expected.

When I make an edit in a buffer, like type a char or delete one, I don't get any syntax error highlighting and the following message is printed to the minibuffer (briefly) and Messages buffer:
Blocking call to accept-process-output with quit inhibited

When I save the buffer it does do the error highlighting and I don't get the above error.

I can confirm that javac does get run while editing the buffer; I can see the time on the class file in target/flycheck/... change. (BTW, the compile on my box is very quick, just as you found it to be).

I installed flycheck from elpa a few days ago (20140121.147). I'm using Emacs 24.3. Are you experiencing this problem?

Perhaps on a related matter, when I use the latest source from git for the malabar lisp, I get the following error in messages buffer when starting:
Loading semantic/wisent/javat-wy.elc...done Loading semantic/wisent/javat-wy.elc...done Loading semantic/wisent/javat-wy.elc...done ... {{dozens of times}}
But when I use the malabar lisp package from ELPA I don't have this problem.

[m0smith]

I had noticed the "Blocking call ... " but wasn't sure what it meant. I will look into it.

I just pushed a new version of malabar-mode to ELPA. Try it out and see if you still get the Loading semantic/wisent/javat-wy.elc...done That is not something I have ever noticed.

Be sure and delete the ~/malabar_mode/classpath as part of the install so you get the latest code.

[m0smith]

The Blocking call message is an emacs "bug" as far as I can tell. It happens when you call an external program (like javac) from a timer, as flycheck would do.

Related to the Blocking call issue

• http://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00360.html
• https://bugs.launchpad.net/vm/+bug/1068805
• auto-complete/auto-complete#179
• http://list-archives.org/2013/06/21/emacs-devel-gnu-org/blocking-call-to-accept-process-output-with-quit-inhibited/f/2033507556

quit is inhibited when running timers, process-filters and other
such asynchronous events.
So comint doesn't need to inhibit-quit itself for such a warning to show
up, if its code is executed from a process-filter.

Try to figure out how/when a process-filter (or timer...) can end up
running the while + accept-process-output loop, and then think about
whether that really should happen, and if so make sure the
process-filter (or timer...) uses with-local-quit before running
that loop.

[m0smith]

I opened an issue with flycheck on the Blocking call to accept-process-output with quit inhibited!! [12 times] I'll open a new issue if we can find a resolution with flycheck