GNU bug report logs - #43265
28.0.50; Inconsistent fontifying in elisp-mode

Previous Next

Full log

View this message in rfc822 format

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43265 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode
Date: Fri, 22 Jan 2021 17:11:22 -0300

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Mauro Aranda <maurooaranda <at> gmail.com> writes:
>
>> To reproduce:
>>
>> emacs -Q
>> In the scratch buffer type:
>>
>> (condition-case nil
>>     (fail-badly)
>>   (error (when foo t)))
>>
>> I don't see WHEN with font-lock-keyword-face.  However:
>>
>> (condition-case nil
>>     (fail-badly)
>>   (error (if foo t)))
>>
>> IF has font-lock-keyword-face.
>
> This is the bit that determines whether to give something a keyword-face:
>
> (defun lisp--el-match-keyword (limit)
>   ;; FIXME: Move to elisp-mode.el.
>   (catch 'found
>     (while (re-search-forward
>             (eval-when-compile
>               (concat "(\\(" lisp-mode-symbol-regexp "\\)\\_>"))
>             limit t)
>       (let ((sym (intern-soft (match-string 1))))
> 	(when (or (special-form-p sym)
> 		  (and (macrop sym)
>                        (not (get sym 'no-font-lock-keyword))
>                        (not (lisp--el-non-funcall-position-p
>                              (match-beginning 0)))))
> 	  (throw 'found t))))))
>
> All special forms get it (`if' is a special form), but macros (like
> `when') only gets it if we're in a funcall position:
>
> (defun lisp--el-non-funcall-position-p (pos)
>   "Heuristically determine whether POS is an evaluated position."
>
> [...]
>
>                   (and (eq parent 'condition-case)
>                        (progn
>                          (forward-sexp 2)
>                          (< (point) pos))))))))))
>
>
> And this doesn't count any of the error clauses as being in a funcall
> position, so no macros in those get a keyword-face.  
>
> I think.  I've added Stefan M to the CCs.
>
> If that's the correct analysis, then fixing this shouldn't be too hard,
> I think?  Just add some extra code in the `condition-case' bit to catch
> this case?

Thanks for taking a look at this report, I hope it's easy to fix.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.