My notes for Java Mode Tamed : see https://stackoverflow.com/questions/tagged/cc-mode : see https://stackoverflow.com/questions/tagged/emacs+java : see https://emacs.stackexchange.com/questions/tagged/cc-mode : see https://emacs.stackexchange.com/questions/tagged/java !!+ Keyword (or whatever they call it) `yield` for switch expressions is going unfaced. : see https://openjdk.org/jeps/361 ?+ Can I simply tell the underlying Java Mode about it? !!+ Function variable declarations go unfaced. / E.g. the declaration of `b` in `beans.forEach( b -> count(b) )` \ + Report the regression. \ : see @ `^*\+ Repair fontification of text blocks\.$` @ ~/work/Java/Emacs/notes.brec \ ' Repair of misfaced type references. \\ pending OS upgrade !!+ Annotated variable declarations go unfaced. : e.g. `command` @ `Descriptor` @ non-fractal ~/work/Breccia/parser/plain/SimpleCommandPoint.java \ + Run a pre-release branch to deal with upcoming Emacs changes, viz. those appearing \ in the pre-release versions, before they hit users on the next release. \ : privately see email:2022-2-12 \ : cf. https://www.gnu.org/savannah-checkouts/gnu/emacs/emacs.html#Releases \ - Else JMT Mode is apt to break on their release, and lie broken till I happen to upgrade. \ ?+ Where can I promptly learn of new pre-releases and releases? Is there a schedule? + Make my label declarations bold. / Like a block statement keyword, as always it marks a block. + Allow distinct faces for label declaration and reference. + Start to ask for changes to CC Mode that would obviate the need of advice and monkey patches. ∵ ‘If you are writing code for release, for others to use, try to avoid including advice in it. If the function you want to advise has no hook to do the job, please talk with the Emacs developers about adding a suitable hook.’ : see https://www.gnu.org/software/emacs/manual/html_node/elisp/Advising-Named-Functions.html + Deal correctly with upper case package names. / For instance in `import Breccia.XML.translator.BrecciaXCursor`. : see ~/code/WP3/wayic/Web/imager/bin/waycast-web-image : see `Package name occuring elsewhere$` @ ~/work/Java/Emacs/jmt-mode.el method | let the user declare each during initialization / Package names `Breccia` and `Breccia.Web` for instance. | for each package segment matched, search backward to get its full name - Slower, perhaps. - Applying this method if chosen, yet acknowledging the other in a comment. | recode using an anchored highlighter - Harder to code, disrupts the present code. ━━━━━━━━━━━━━━━━━━ `assert` keyword ────────────────── - Apropos Java Mode’s omission of Java’s `assert` keyword. - JMT Mode’s workaround: - JMT Mode fontifies the keyword itself. - Also it corrects misfaced method calls, the only instance seen being one in which a method is called from within an `assert` statement. - Maybe this misfacing too would be corrected if the keyword were properly faced in the first instance. / Both bits of code refer to these notes. - Further, these repairs of underlying Java Mode variables were tested:   (let* ((pattern c-simple-stmt-key)   (pattern-beg "\\(\\(?:"))   (if (not (string-prefix-p (concat pattern-beg "break\\|") pattern))   (jmt-message "(jmt-mode): Patch failed to apply, `c-simple-stmt-key`")   (setq pattern (substring pattern (length pattern-beg))   pattern (concat pattern-beg "assert\\|" pattern))   (jmt-set-for-buffer 'c-simple-stmt-key pattern)))   (let* ((pattern c-regular-keywords-regexp)   (pattern-beg "\\(\\(?:"))   (if (not (string-prefix-p (concat pattern-beg "@interface\\|") pattern))   (jmt-message "(jmt-mode): Patch failed to apply, `c-regular-keywords-regexp`")   (setq pattern (substring pattern (length pattern-beg))   pattern (concat pattern-beg "assert\\|" pattern))   (jmt-set-for-buffer 'c-regular-keywords-regexp pattern))) - Tested as part of in-buffer initialization. - But the repair to `c-regular-keywords-regexp` comes too late to affect the value which Java Mode uses to initialize *c-lang-const* `c-basic-matchers-before`, which in turn appears in `font-lock-keywords`. - Neither of these seems feasible to repair after the fact. - The resulting `font-lock-keywords` contains unfamiliar forms, which might be inaccessible to me. - And `c-basic-matchers-before` is entirely inaccessible, my attempts to access it via `c-lang-const` resulting in inexplicable errors. - Maybe putting that code into one of CC Mode’s early-run hooks would work. / But now I have spent too much time working around what could more easily be redressed by a bug report to CC Mode. ━━━━━━ Bugs ────── ! ‘c-invalidate-sws-region-after: Args out of range: 1, 1631’ - Seen while pasting then editing a multi-line `/* … */` comment. / 2021-4 ! ‘Args out of range’ error in `c-remove-stale-state-cache-backwards`. / see `/usr/share/emacs/29.3/lisp/progmodes/cc-engine.el` /   c-remove-stale-state-cache-backwards: Args out of range: 1, 2935Error during redisplay: (jit-lock-function 2789) signaled (args-out-of-range 1 2935)   Error during redisplay: (jit-lock-function 1912) signaled (args-out-of-range 1 2935) - Seen while editing within the brace delimiters of a Java conditional, 2020-11-6. : see ~/work/Breccia/Web/imager/ImageMould.java - Directly after the changes of revisions 200c0eb0 and 8ff45cd6. - Inspections of those changes and the changed code reveal no apparent fault. - Function `c-remove-stale-state-cache-backwards` has a single caller in `c-parse-state-1`. / see `/usr/share/emacs/29.3/lisp/progmodes/cc-engine.el` - Much later, a similar error while cutting (killing) a field declaration complete with an API description, near the end of the buffer. : see ~/work/Breccia/parser/plain/BrecciaCursor.java         /** The leading characters of the next head, up to the first non-space character (20), inclusive.   * It is null at parse state `DocumentEnd`.   *   *

Beware of it swapping with `head` as reading progresses.

  */   private StringBuilder headSuccessor = new StringBuilder( /*initial capacity*/400 ); / 2020-12-12, when debug-on-error happened to be enabled. Package `app-editors/emacs-26.3-r1:26`.   Debugger entered--Lisp error: (args-out-of-range 965 1403)   c-state-balance-parens-backwards(1208 1208 1403)   c-remove-stale-state-cache-backwards(1208)   c-parse-state-1()   c-parse-state()   c-syntactic-skip-backward("^;{}" 440 t)   c-fl-decl-start(1439)   c-change-expand-fl-region(1077 1077 331)   #f(compiled-function (fn) #)(c-change-expand-fl-region)   mapc(#f(compiled-function (fn) #) (c-depropertize-new-text c-parse-quotes-after-change c-restore-<>-properties c-change-expand-fl-region))   c-after-change(1077 1077 331)   delete-and-extract-region(1077 1408)   #f(compiled-function (beg end delete) #)(1077 1408 delete)   apply(#f(compiled-function (beg end delete) #) (1077 1408 delete))   #f(compiled-function (funs global args) #)(nil nil (1077 1408 delete))   buffer-substring--filter(1077 1408 delete)   filter-buffer-substring(1077 1408 delete)   #f(compiled-function (method) #)(delete)   kill-region(1077 1408 region)   funcall-interactively(kill-region 1077 1408 region)   call-interactively(kill-region nil nil)   command-execute(kill-region) - Apparently the error comes from the top function calling `(narrow-to-region (point-min) top)`, which is `(narrow-to-region 965 1403)`. - From `(point-min)` I do indeed get 965, and clearly `top` is 1403. - From `(point-max)` I get 1318, so indeed 1403 is out of range. ∵ Function the call by `c-remove-stale-state-cache-backwards` to `(c-state-balance-parens-backwards here- here+ pos)` is in error. ∵ It passes `pos` for `top`, which is greater than `point-max`. \ - Function `c-remove-stale-state-cache-backwards` says it ‘must only be called \ only when (> `c-state-cache-good-pos' HERE)’. \ - Okay, indeed (> 1403 1208). + Is it the fault of JMT Mode? - I am unable to get a reproducible case from a copy of that file. : viz. ~/work/Breccia/parser/plain/BrecciaCursor.java + Live with this bug until the next Emacs upgrade. / Present package `app-editors/emacs-26.3-r1:26`. | no + Report it. + Annotate by referring to the report. | yes + Patch an attempted recovery, calling one of `c-invalidate-state-cache` and `c-invalidate-state-cache-1` to clear away the whole cache. / ∵ The cache is likely left inconsistent. + Find the safest place in the stack to put the error handler. ! `scan-error "Unbalanced parentheses"` /   Error during redisplay: (jit-lock-function 1207) signaled (scan-error "Unbalanced parentheses" 693 12819) [2 times] - Seen while editing near the top of: : see ~/work/Makeshift/Bootstrap.java / 2020-11-7 + Live with this bug until the next Emacs upgrade. : join ━━━━━━━━━ CC Mode ───────── - The package that implements Java Mode. diff >+ (d=/usr/share/emacs; e=lisp/progmodes; f=cc-engine.el; diff --unified $d/26.3/$e/$f $d/27.1/$e/$f) instructions : see https://www.gnu.org/software/emacs/manual/html_node/ccmode/index.html : see https://www.gnu.org/software/emacs/manual/html_mono/ccmode.html source code : see http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/progmodes : `cc-*.el` : see https://github.com/emacs-mirror/emacs/tree/master/lisp/progmodes : `cc-*.el` ━━━━━━━━━━━━━ Text blocks ───────────── + Repair fontification of text blocks. : see https://emacs.stackexchange.com/questions/63680/java-15-text-blocks-in-cc-mode - This is a regression in the underlying Java Mode from Emacs 26.3 to 27.1. | report upstream + Report the regression. | syntax-propertize : see `^*Context sensitive syntax$` @ http://www.modernemacs.com/post/major-mode-part-1/ / Outline:   (defun jmt-syntax-propertize (start end)   "Apply syntax properties to the region denoted by START and END.   JMT Mode assigns this function to ‘syntax-propertize-function’."   ())     (defun jmt-syntax-propertize-extend-region (start end)   "Give an extended region if START and END are too narrow for propertizing.   JMT Mode hooks this function into   ‘syntax-propertize-extend-region-functions’."   ()) | syntax-propertize-rules | By fixing the regression in CC-Mode. - Somehow it prevents what would work by default. / A triple delimited string should be fontified *by default* as three separate strings; switching to `perl-mode` confirms this. - But it messes *extensively* with syntax properties, including string delimiters, making the fault difficult to trace in the code. - And a diff shows many changes in that mess from 26.3 to 27.1.