Inspector: render Java items using java-mode syntax coloring

[vemv]

Fixes #3546

Demo:

Cheers - V

[vemv]

Headers now are rendered as comments - else it's all too homogeneous.

[rrudakov]

Starting from emacs-29, build-in java-ts-mode is also available. Maybe this could be customizable, to let users pick the desired mode?

[vemv]

Good eye!

It seems most desirable to simply pick java-ts-mode if available, improving performance I guess (or in any case having color consistency, in case there's a discrepancy between both modes. Assuming that the user uses java-ts-mode regularly).

Would you be able to try this diff locally and confirm that it works well with java-ts-mode?

[rrudakov]

Good eye!

It seems most desirable to simply pick java-ts-mode if available, improving performance I guess (or in any case having color consistency, in case there's a discrepancy between both modes. Assuming that the user uses java-ts-mode regularly).

Would you be able to try this diff locally and confirm that it works well with java-ts-mode?

Sure, I can try it out tomorrow. The only concern I have is that emacs can be built without the tree-sitter support or the grammar can be missing, I guess java-ts-mode won't work properly in this case.

[vemv]

Is that condition detectable?

[rrudakov]

@vemv, yes, it's possible:

(require 'treesit)
(treesit-available-p)                   ;check if Emacs is built with tree-sitter library
(treesit-language-available-p 'java)    ;Make sure Emacs can find the language grammar you want to use

[bbatsov]

Given the simple nature of this highlighting in the inspector, it seems to me that using java-mode unconditionally will be perfectly fine.

I'd suggest a defcustom to enable/disable this, and perhaps a second one about the preferred java-mode to use, if someone feels strongly that using java-ts-mode will result in any meaningful improvements.

[bbatsov]

I think we had a similar function in cider-util.el already that you can reuse (it takes the mode to use as its param).

[vemv]

Indeed! I got to also kill a similar defun in cider-docstring.el.

[vemv]

@rrudakov although your suggestion was a fair call, it seems best addressed later, and also backed by a specific problem statement (not that I don't like the idea, but we'd like to see some performance or presentational difference first).

My main reasoning is that we now have 5 cider-font-lock-as 'java-mode calls, so it would be a broader refactoring than initially thought.

[rrudakov]

vemv ***@***.***> writes:

@rrudakov although your suggestion was a fair call, it seems best addressed later, and also backed by a specific problem statement (not that I don't like the idea, but we'd like to see some performance or presentational difference first). My main reasoning is that we now have 5 `cider-font-lock-as 'java-mode` calls, so it would be a broader refactoring than initially thought.

Sure, sounds fair. Thanks for considering this anyway. -- Best regards, Roman