Re: Java-1.5 font-lock support?
Until we see the full semantic support, This simple patch improves the coloring of generic declarations: diff -p font-lock.el.~1~ font-lock.el *** font-lock.el.~1~Fri Aug 30 05:35:14 2002 --- font-lock.elSun May 8 12:19:19 2005 *** See also `java-font-lock-extra-types'.) *** 2941,2947 ;; ;; Fontify random types immediately followed by an item or items. `(eval . ! (list (concat ( ,java-type-names \\)\\ \\([ \t]*\\[[ \t]*\\]\\)* \\([ \t]*\\sw\\)) ;; Fontify each declaration item. --- 2941,2947 ;; ;; Fontify random types immediately followed by an item or items. `(eval . ! (list (concat ( ,java-type-names \\(?:\\(?:.*\\) \\|) \\) \\([ \t]*\\[[ \t]*\\]\\)* \\([ \t]*\\sw\\)) ;; Fontify each declaration item.
Re: Compiler window deletion - UI question/suggestion
Your fix will help; it enables one to unset jde-compile-enable-kill-buffer to avoid the killing of the window. However; what I want (and i suspect other's do as well), is to kill the buffer, but: Leave the window in place! That way, when i have two edit windows, and compile in one window, the compile results will show briefly in the second window, and then (when all goes well) that second window will revert to the previously visible buffer! That way you do it, compile will either: a) leave the compile output showing where the second edit window was b) close the second edit window. Neither of which is my expectation/intent. If everyone else only expects one window per frame, and really wants to close the second/temporary compile output window, then maybe we should make creative use of save-window-excursion, to restore the configuration? (defun jde-compile-kill-buffer (buf) (kill-buffer buf))
Java-1.5 font-lock support?
Is there a version of Java font-lock that supports Java-1.5? To so something reasonable with Generics and varargs (Object... args) and other 1.5-isms?
JDE-2.5.3 SemanticDB: too much of a good thing?
I just upgraded to NT Emacs 21.3.1 (i386-mingw-nt5.1.2600) and JDEE 2.3.5 Plenty of new features, but i'll need to read a bunch to learn to appreciate them. My current concern is with semantic and its continuous background parsing. Which would not be so bad, but contrary to the documentation, it does not 'break' when there is keyboard input. on the contrary the kbd/gui freezes (1-20 secs)while semantic does its thing. And it does it (parsing/freezing)more or less continously/asynchronously while i'm editing... painful. In *Messages* are comments like: Wrote c:/Data/Programs/java/util/Arg.javaUpdate Tag Table: Invoke [2 times]Building Arglist.java Semantic directory index imenu [2 times]Building Arglist.java.~2~ Semantic directory index imenu [2 times]Building NArglist.java Semantic directory index imenu [2 times]Building Reflect.java Semantic directory index imenu [2 times]Mark set Sometimes theseries of "Building ... index imenu[]" repeats every minute or so Note: Each lineappears [2 times], is it really parsing twice? or just sending the message twice? Note: Even non-modified buffers (like the read-only Arglist.java.~2~) are being rescanned repeatedly... Is this normal/expected? or am I badly configured? Where to I look to improve this? [this didn't seem to be a problem in my previous JDEE 1.x.x installation] The semantic docs talk about how to enable only partial features, but i don't do any of that, i assume it is all setup by jde-mode;can itune/modify without breaking everything? My underlying grump is that i'm an old-dog, all i really want is the syntax coloring, compile/run/debug key bindings and for Meta-. to work; All the semantic analysis does not seem to link into M-. so what is the point of that CPU hog? And how do i get things like Arglist.java.~2~ *out* of the semantic db/cache/parsing? I have always loved the responsiveness of Emacs, but this background semantic parsing is ruining the experience.
