* bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode @ 2020-09-07 20:05 Mauro Aranda 2021-01-22 19:32 ` Lars Ingebrigtsen 2021-01-26 0:19 ` Lars Ingebrigtsen 0 siblings, 2 replies; 22+ messages in thread From: Mauro Aranda @ 2020-09-07 20:05 UTC (permalink / raw) To: 43265 [-- Attachment #1: Type: text/plain, Size: 3340 bytes --] 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. In GNU Emacs 28.0.50 (build 181, x86_64-pc-linux-gnu, cairo version 1.15.10) of 2020-09-07 built on tbb-desktop Repository revision: 0ebe2678002ffb82a25311c56cbc4b8ba3bd5fa1 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12008000 System Description: Ubuntu 18.04.5 LTS Configured using: 'configure --with-x-toolkit=no' Configured features: XPM JPEG TIFF GIF PNG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY GNUTLS LIBXML2 FREETYPE HARFBUZZ ZLIB OLDXMENU X11 XDBE XIM MODULES THREADS PDUMPER Important settings: value of $LC_MONETARY: es_AR.UTF-8 value of $LC_NUMERIC: es_AR.UTF-8 value of $LC_TIME: es_AR.UTF-8 value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr mule-util info emacsbug message rmc puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json map text-property-search seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date subr-x pcase misearch multi-isearch vc-git diff-mode easy-mmode bug-reference pp wid-edit descr-text help-fns radix-tree cl-print debug backtrace help-mode easymenu find-func cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo x multi-tty make-network-process emacs) Memory information: ((conses 16 133020 8093) (symbols 48 8406 1) (strings 32 28861 5704) (string-bytes 1 864362) (vectors 16 14411) (vector-slots 8 187982 17929) (floats 8 37 39) (intervals 56 17238 0) (buffers 992 17)) [-- Attachment #2: Type: text/html, Size: 3718 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2020-09-07 20:05 bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode Mauro Aranda @ 2021-01-22 19:32 ` Lars Ingebrigtsen 2021-01-22 20:11 ` Mauro Aranda 2021-01-22 22:32 ` Stefan Monnier 2021-01-26 0:19 ` Lars Ingebrigtsen 1 sibling, 2 replies; 22+ messages in thread From: Lars Ingebrigtsen @ 2021-01-22 19:32 UTC (permalink / raw) To: Mauro Aranda; +Cc: 43265, Stefan Monnier Mauro Aranda <maurooaranda@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? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2021-01-22 19:32 ` Lars Ingebrigtsen @ 2021-01-22 20:11 ` Mauro Aranda 2021-01-22 22:32 ` Stefan Monnier 1 sibling, 0 replies; 22+ messages in thread From: Mauro Aranda @ 2021-01-22 20:11 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 43265, monnier Lars Ingebrigtsen <larsi@gnus.org> writes: > Mauro Aranda <maurooaranda@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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2021-01-22 19:32 ` Lars Ingebrigtsen 2021-01-22 20:11 ` Mauro Aranda @ 2021-01-22 22:32 ` Stefan Monnier 2021-01-23 18:42 ` Lars Ingebrigtsen 1 sibling, 1 reply; 22+ messages in thread From: Stefan Monnier @ 2021-01-22 22:32 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 43265, Mauro Aranda > All special forms get it (`if' is a special form), but macros (like > `when') only gets it if we're in a funcall position: Not sure why that is. Seems like an accident. > (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. Sounds like a bug. Note that in (condition-case nil (foo) (error (when a (when b c)))) the second `when` gets the keyword face, as it should. BTW I suspect that part of the reason for this bug is because of the need to avoid using the keyword face on the `when` of: (condition-case nil (foo) ((when error) ...)) Adding corresponding tests for these things would be great. Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2021-01-22 22:32 ` Stefan Monnier @ 2021-01-23 18:42 ` Lars Ingebrigtsen 2021-01-23 19:54 ` Stefan Monnier 0 siblings, 1 reply; 22+ messages in thread From: Lars Ingebrigtsen @ 2021-01-23 18:42 UTC (permalink / raw) To: Stefan Monnier; +Cc: 43265, Mauro Aranda [-- Attachment #1: Type: text/plain, Size: 399 bytes --] Stefan Monnier <monnier@iro.umontreal.ca> writes: >> All special forms get it (`if' is a special form), but macros (like >> `when') only gets it if we're in a funcall position: > > Not sure why that is. Seems like an accident. The special form bit, or the macro bit? :-) Since special forms are always font-locked as keywords when appearing as the first element in a list, you get stuff like: [-- Attachment #2: Type: image/png, Size: 6013 bytes --] [-- Attachment #3: Type: text/plain, Size: 702 bytes --] So if would perhaps make sense to also do the `funcall-position-p' for special forms? > Sounds like a bug. Note that in > > (condition-case nil > (foo) > (error (when a (when b c)))) > > the second `when` gets the keyword face, as it should. Because then `condition-case' isn't the parent, presumably. > BTW I suspect that part of the reason for this bug is because of the > need to avoid using the keyword face on the `when` of: > > (condition-case nil > (foo) > ((when error) ...)) > > Adding corresponding tests for these things would be great. Indeed. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2021-01-23 18:42 ` Lars Ingebrigtsen @ 2021-01-23 19:54 ` Stefan Monnier 2021-01-24 19:58 ` Lars Ingebrigtsen 0 siblings, 1 reply; 22+ messages in thread From: Stefan Monnier @ 2021-01-23 19:54 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 43265, Mauro Aranda >>> All special forms get it (`if' is a special form), but macros (like >>> `when') only gets it if we're in a funcall position: >> Not sure why that is. Seems like an accident. > The special form bit, or the macro bit? :-) The fact that the two are treated differently. Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2021-01-23 19:54 ` Stefan Monnier @ 2021-01-24 19:58 ` Lars Ingebrigtsen 2021-01-24 19:59 ` Lars Ingebrigtsen ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Lars Ingebrigtsen @ 2021-01-24 19:58 UTC (permalink / raw) To: Stefan Monnier; +Cc: 43265, Mauro Aranda, Tassilo Horn Stefan Monnier <monnier@iro.umontreal.ca> writes: >>>> All special forms get it (`if' is a special form), but macros (like >>>> `when') only gets it if we're in a funcall position: >>> Not sure why that is. Seems like an accident. >> The special form bit, or the macro bit? :-) > > The fact that the two are treated differently. The handling of the macros is "more correct". Should we just remove the special-casing of special forms? It apparently was introduced by: commit 9fdc166ee0ca212f7d5bf1cd9e1177932b0cd9aa Author: Tassilo Horn <tsdh@gnu.org> AuthorDate: Mon Mar 16 10:25:14 2015 +0100 Before this, special forms and macros were handled in the same way, but the commit message doesn't really explain why this was changed. (Tassilo added to the CCs.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2021-01-24 19:58 ` Lars Ingebrigtsen @ 2021-01-24 19:59 ` Lars Ingebrigtsen 2021-01-24 20:09 ` Eli Zaretskii 2021-01-24 21:25 ` Stefan Monnier 2 siblings, 0 replies; 22+ messages in thread From: Lars Ingebrigtsen @ 2021-01-24 19:59 UTC (permalink / raw) To: Stefan Monnier; +Cc: 43265, Mauro Aranda, Tassilo Horn (Oh, and I added some tests for the font locking here, including three failing ones that illustrates the issues under discussion.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2021-01-24 19:58 ` Lars Ingebrigtsen 2021-01-24 19:59 ` Lars Ingebrigtsen @ 2021-01-24 20:09 ` Eli Zaretskii 2021-01-24 20:16 ` Lars Ingebrigtsen 2021-01-24 21:25 ` Stefan Monnier 2 siblings, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2021-01-24 20:09 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: maurooaranda, 43265, monnier, tsdh > From: Lars Ingebrigtsen <larsi@gnus.org> > Date: Sun, 24 Jan 2021 20:58:22 +0100 > Cc: 43265@debbugs.gnu.org, Mauro Aranda <maurooaranda@gmail.com>, > Tassilo Horn <tsdh@gnu.org> > > It apparently was introduced by: > > commit 9fdc166ee0ca212f7d5bf1cd9e1177932b0cd9aa > Author: Tassilo Horn <tsdh@gnu.org> > AuthorDate: Mon Mar 16 10:25:14 2015 +0100 > > Before this, special forms and macros were handled in the same way, but > the commit message doesn't really explain why this was changed. https://lists.gnu.org/archive/html/emacs-devel/2015-03/msg00327.html etc. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2021-01-24 20:09 ` Eli Zaretskii @ 2021-01-24 20:16 ` Lars Ingebrigtsen 2021-01-24 21:58 ` bug#43265: [External] : " Drew Adams 0 siblings, 1 reply; 22+ messages in thread From: Lars Ingebrigtsen @ 2021-01-24 20:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: maurooaranda, 43265, monnier, tsdh Eli Zaretskii <eliz@gnu.org> writes: >> Before this, special forms and macros were handled in the same way, but >> the commit message doesn't really explain why this was changed. > > https://lists.gnu.org/archive/html/emacs-devel/2015-03/msg00327.html Skimming that thread, I can't see any explanation for why we don't check that special forms are in a function position, while we do that for macros? I.e., (setq a '(if a b)) is currently fontified incorrectly, while (setq a '(when a b)) is fontified correctly. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: [External] : bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2021-01-24 20:16 ` Lars Ingebrigtsen @ 2021-01-24 21:58 ` Drew Adams 2021-01-25 6:30 ` Tassilo Horn 0 siblings, 1 reply; 22+ messages in thread From: Drew Adams @ 2021-01-24 21:58 UTC (permalink / raw) To: Lars Ingebrigtsen, Eli Zaretskii Cc: 43265@debbugs.gnu.org, maurooaranda@gmail.com, monnier@iro.umontreal.ca, tsdh@gnu.org Oh boy - font-lock bikeshedding! > Skimming that thread, I can't see any explanation for why we don't check > that special forms are in a function position, while we do that for > macros? I.e., > > (setq a '(if a b)) is currently fontified incorrectly, while > (setq a '(when a b)) is fontified correctly. Really? Are you sure one is correct and the other not, and that you have it the right way round? (setq a '(setq b d)) (setq a '(if a b)) (setq a '(when a b)) (setq a '(and a b)) Nowadays, all of those `setq's, the `if', and the `and' are highlighted; poor-boy `when' isn't. :-( ___ But is it really "correct" to fontify _any_ of the names in those quoted sexps as if they were being used with their active meanings - as code? In that context they're just data - list elements. It was Emacs 25 that started highlighting all of those `setq's, and `and'. Up through Emacs 24, `setq' and `and' weren't highlighted anywhere - and both `if' and `when' were highlighted (everywhere). Emacs 25 made `when' a special case (unhighlighted), and it made `setq' and `and' unspecial (highlighted). That new behavior is no more "correct" than what it replaced. If any highlightings could be considered more correct than others, I'd think a more correct one would _at least_ not highlight function/macro/special-form names when used as elements of a list (i.e. quoted) or as plain-quoted atoms. Consider: (defun foo (x y) 42) ; or (defmacro foo (x y) 42) (setq a '(foo a b)) (setq a '(if a b)) `foo' in the quoted list isn't highlighted; `if' is. Why? In sum: 1. We're not very consistent (before or since Emacs 25). 2. The behavior's changed over time: sometimes to add highlighting (`setq', `and'), sometimes to remove it (`when'). Why? Maybe (or maybe not) there were some good reasons. In any case, for a _user_ things are not so clear. 3. IMO, it could make sense to not highlight such names when they're not syntactically seen as being _used_ as function/macro/special-form, but are instead seen as data (e.g. quoted). (When the use isn't obvious, pick a direction to err on, and be relatively consistent about it.) Now the question becomes, What constitutes "use" as a function/macro/special-form? Plain-quoting doesn't, IMO; but what about #'? How many angels fit on the head of a pin? (Depends on the angels and the pin.) ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: [External] : bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2021-01-24 21:58 ` bug#43265: [External] : " Drew Adams @ 2021-01-25 6:30 ` Tassilo Horn 2021-01-25 6:39 ` Lars Ingebrigtsen 2021-01-25 16:01 ` Drew Adams 0 siblings, 2 replies; 22+ messages in thread From: Tassilo Horn @ 2021-01-25 6:30 UTC (permalink / raw) To: Drew Adams Cc: maurooaranda@gmail.com, Lars Ingebrigtsen, 43265@debbugs.gnu.org, monnier@iro.umontreal.ca >> Skimming that thread, I can't see any explanation for why we don't >> check that special forms are in a function position, while we do that >> for macros? I.e., Me neither, and as Stefan said, that's a change in that behavior has not been intended by my patch. It's intention was to highlight all macros (except those declared with no-font-lock-keyword), no matter when they are loaded. E.g., when a new macro gets defined, it should also be highlighted. >> (setq a '(if a b)) is currently fontified incorrectly, while >> (setq a '(when a b)) is fontified correctly. > > Really? Are you sure one is correct and the other not, > and that you have it the right way round? > > (setq a '(setq b d)) > (setq a '(if a b)) > (setq a '(when a b)) > (setq a '(and a b)) > > Nowadays, all of those `setq's, the `if', and the `and' > are highlighted; poor-boy `when' isn't. :-( All but `when' are special forms, so Lars is right that the distinction is between special forms vs. macros. > But is it really "correct" to fontify _any_ of the names > in those quoted sexps as if they were being used with > their active meanings - as code? In that context they're > just data - list elements. Yeah, the special forms should probably not be highlighted here. Bye, Tassilo ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: [External] : bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2021-01-25 6:30 ` Tassilo Horn @ 2021-01-25 6:39 ` Lars Ingebrigtsen 2021-01-25 6:46 ` Tassilo Horn 2021-01-25 16:01 ` Drew Adams 1 sibling, 1 reply; 22+ messages in thread From: Lars Ingebrigtsen @ 2021-01-25 6:39 UTC (permalink / raw) To: Tassilo Horn Cc: 43265@debbugs.gnu.org, maurooaranda@gmail.com, monnier@iro.umontreal.ca Tassilo Horn <tsdh@gnu.org> writes: > Me neither, and as Stefan said, that's a change in that behavior has not > been intended by my patch. Ah; thanks for confirming. I'll change it so that special forms and macros are handled the same way, then. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: [External] : bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2021-01-25 6:39 ` Lars Ingebrigtsen @ 2021-01-25 6:46 ` Tassilo Horn 2021-01-25 13:59 ` Stefan Monnier 2021-01-25 16:09 ` Drew Adams 0 siblings, 2 replies; 22+ messages in thread From: Tassilo Horn @ 2021-01-25 6:46 UTC (permalink / raw) To: Lars Ingebrigtsen Cc: 43265@debbugs.gnu.org, maurooaranda@gmail.com, monnier@iro.umontreal.ca > Tassilo Horn <tsdh@gnu.org> writes: > >> Me neither, and as Stefan said, that's a change in that behavior has >> not been intended by my patch. > > Ah; thanks for confirming. I'll change it so that special forms and > macros are handled the same way, then. Feel free to do so. But I can also make an argument for the current behavior: special forms are under our control and there aren't many, so if they happen to be in a quoted form, it's likely that's actually code eventually being run. In contrast, the number of macros is theoretically unbounded and naming is not restricted, so we can't say anything about usage patterns of macro-named things in quoted lists. Bye, Tassilo ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: [External] : bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2021-01-25 6:46 ` Tassilo Horn @ 2021-01-25 13:59 ` Stefan Monnier 2021-01-25 23:34 ` Lars Ingebrigtsen 2021-01-25 16:09 ` Drew Adams 1 sibling, 1 reply; 22+ messages in thread From: Stefan Monnier @ 2021-01-25 13:59 UTC (permalink / raw) To: Tassilo Horn Cc: Lars Ingebrigtsen, 43265@debbugs.gnu.org, maurooaranda@gmail.com > Feel free to do so. But I can also make an argument for the current > behavior: special forms are under our control and there aren't many, so > if they happen to be in a quoted form, it's likely that's actually code > eventually being run. I don't see why that should be more likely for special forms than for macros. For many of them, which is which is largely an arbitrary choice. Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: [External] : bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2021-01-25 13:59 ` Stefan Monnier @ 2021-01-25 23:34 ` Lars Ingebrigtsen 0 siblings, 0 replies; 22+ messages in thread From: Lars Ingebrigtsen @ 2021-01-25 23:34 UTC (permalink / raw) To: Stefan Monnier Cc: 43265@debbugs.gnu.org, maurooaranda@gmail.com, Tassilo Horn Stefan Monnier <monnier@iro.umontreal.ca> writes: > I don't see why that should be more likely for special forms than for > macros. For many of them, which is which is largely an > arbitrary choice. The only reason I see to handle special forms specially here is for reasons of efficiency. That is, we now do a lot more work for special forms than we used to do, and special forms are a lot more common in Emacs Lisp code than macros, so perhaps the performance regression isn't worth it. Emacs doesn't feel more sluggish to me than before making the change, though, so I think the change was the right thing to do. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: [External] : bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2021-01-25 6:46 ` Tassilo Horn 2021-01-25 13:59 ` Stefan Monnier @ 2021-01-25 16:09 ` Drew Adams 2021-01-25 16:14 ` Drew Adams 1 sibling, 1 reply; 22+ messages in thread From: Drew Adams @ 2021-01-25 16:09 UTC (permalink / raw) To: Tassilo Horn, Lars Ingebrigtsen Cc: 43265@debbugs.gnu.org, maurooaranda@gmail.com, monnier@iro.umontreal.ca > >> Me neither, and as Stefan said, that's a change in that behavior has > >> not been intended by my patch. > > > > Ah; thanks for confirming. I'll change it so that special forms and > > macros are handled the same way, then. > > Feel free to do so. Agreed. > But I can also make an argument for the current > behavior: special forms are under our control and there aren't many, so > if they happen to be in a quoted form, it's likely that's actually code > eventually being run. In contrast, the number of macros is > theoretically unbounded and naming is not restricted, so we can't say > anything about usage patterns of macro-named things in quoted lists. Highlighting macro names (when used as macros, but not when just elements in a quoted list etc.) is helpful, IMO. For the reason you gave (macros are defined with Lisp, and can be user-defined), my preference is for a separate kind of highlighting for their names - separate from special-form names and function names. Now, if people get excited about too much angry fruit salad, the default face used for macro names could just inherit from that for special form names. (But I'm against such "invisible" face defaulting, in general.) ___ IMO, the priorities, in terms of importance (help for users) are these. (They might not be the priorities for implementation, e.g. if #1 is thought to be hard to do or problematic.) 1. Stop highlighting names of functions, macros and special forms when they are not being used as such. Don't highlight them when they are just symbols in data (e.g. quote lists). 2. Other than #1, highlight function, macro, and special-form names, each with a different face. (Or use the same face for special forms and macros - but that's not my preference.) ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: [External] : bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2021-01-25 16:09 ` Drew Adams @ 2021-01-25 16:14 ` Drew Adams 0 siblings, 0 replies; 22+ messages in thread From: Drew Adams @ 2021-01-25 16:14 UTC (permalink / raw) To: Drew Adams, Tassilo Horn, Lars Ingebrigtsen Cc: 43265@debbugs.gnu.org, maurooaranda@gmail.com, monnier@iro.umontreal.ca BTW: Would it be useful to take a poll about the most useful behavior, or otherwise discuss on emacs-devel what behavior to have? I realize that this question is relatively minor (~bike-shedding), but maybe users have strong opinions or good ideas about it. Just a question. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: [External] : bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2021-01-25 6:30 ` Tassilo Horn 2021-01-25 6:39 ` Lars Ingebrigtsen @ 2021-01-25 16:01 ` Drew Adams 1 sibling, 0 replies; 22+ messages in thread From: Drew Adams @ 2021-01-25 16:01 UTC (permalink / raw) To: Tassilo Horn Cc: maurooaranda@gmail.com, Lars Ingebrigtsen, 43265@debbugs.gnu.org, monnier@iro.umontreal.ca > >> (setq a '(if a b)) is currently fontified incorrectly, while > >> (setq a '(when a b)) is fontified correctly. > > > > Really? Are you sure one is correct and the other not, > > and that you have it the right way round? > > > > (setq a '(setq b d)) > > (setq a '(if a b)) > > (setq a '(when a b)) > > (setq a '(and a b)) > > > > Nowadays, all of those `setq's, the `if', and the `and' > > are highlighted; poor-boy `when' isn't. :-( > > All but `when' are special forms, so Lars is right that the distinction > is between special forms vs. macros. That may be the distinction now, but the behavior has changed over time. The real question about that distinction should be whether it's helpful/useful for users? Typically for Lisp whether a special form is implemented at a lower-than-Lisp level or as a macro or in some other way is only an implementation detail. What's most helpful, for a user, in terms of font-lock? I'm guessing that the aim behind this distinguishing special forms from macros by highlighting is really aimed at distinguishing user-defined macros from predefined macros. To me, as one user, highlighting predefined macros the same as special forms makes sense. But so does highlighting all macros differently from functions and special forms. To me, it's not so helpful to not highlight macros at all. > > But is it really "correct" to fontify _any_ of the names > > in those quoted sexps as if they were being used with > > their active meanings - as code? In that context they're > > just data - list elements. > > Yeah, the special forms should probably not be highlighted here. That was my main point, yes. To do that correctly in the general case is maybe hard (when is something "used" as a function/macro/special-form?). But a first approximation should be pretty easy and helpful. Users can be helped by not highlighting such things when quoted (e.g. in quoted lists). Highlighting them in such contexts is misleading. That's the main highlighting change I'd like to see made. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2021-01-24 19:58 ` Lars Ingebrigtsen 2021-01-24 19:59 ` Lars Ingebrigtsen 2021-01-24 20:09 ` Eli Zaretskii @ 2021-01-24 21:25 ` Stefan Monnier 2 siblings, 0 replies; 22+ messages in thread From: Stefan Monnier @ 2021-01-24 21:25 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 43265, Mauro Aranda, Tassilo Horn > The handling of the macros is "more correct". Should we just remove the > special-casing of special forms? > > It apparently was introduced by: > > commit 9fdc166ee0ca212f7d5bf1cd9e1177932b0cd9aa Looks like an accident: none of that change explains the difference in treatment. Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2020-09-07 20:05 bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode Mauro Aranda 2021-01-22 19:32 ` Lars Ingebrigtsen @ 2021-01-26 0:19 ` Lars Ingebrigtsen 2021-01-26 0:27 ` Mauro Aranda 1 sibling, 1 reply; 22+ messages in thread From: Lars Ingebrigtsen @ 2021-01-26 0:19 UTC (permalink / raw) To: Mauro Aranda; +Cc: 43265 Mauro Aranda <maurooaranda@gmail.com> writes: > (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. I forgot to mention in this bug report (since we started talking about other things here) that this bit has been fixed. So I'm closing this bug report. Opening a new one about `edebug-form-spec' when doing highlights may be appropriate, if that's something that somebody wants to work on. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode 2021-01-26 0:19 ` Lars Ingebrigtsen @ 2021-01-26 0:27 ` Mauro Aranda 0 siblings, 0 replies; 22+ messages in thread From: Mauro Aranda @ 2021-01-26 0:27 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 43265 Lars Ingebrigtsen <larsi@gnus.org> writes: > Mauro Aranda <maurooaranda@gmail.com> writes: > >> (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. > > I forgot to mention in this bug report (since we started talking about > other things here) that this bit has been fixed. > Thanks! ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2021-01-26 0:27 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-09-07 20:05 bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode Mauro Aranda 2021-01-22 19:32 ` Lars Ingebrigtsen 2021-01-22 20:11 ` Mauro Aranda 2021-01-22 22:32 ` Stefan Monnier 2021-01-23 18:42 ` Lars Ingebrigtsen 2021-01-23 19:54 ` Stefan Monnier 2021-01-24 19:58 ` Lars Ingebrigtsen 2021-01-24 19:59 ` Lars Ingebrigtsen 2021-01-24 20:09 ` Eli Zaretskii 2021-01-24 20:16 ` Lars Ingebrigtsen 2021-01-24 21:58 ` bug#43265: [External] : " Drew Adams 2021-01-25 6:30 ` Tassilo Horn 2021-01-25 6:39 ` Lars Ingebrigtsen 2021-01-25 6:46 ` Tassilo Horn 2021-01-25 13:59 ` Stefan Monnier 2021-01-25 23:34 ` Lars Ingebrigtsen 2021-01-25 16:09 ` Drew Adams 2021-01-25 16:14 ` Drew Adams 2021-01-25 16:01 ` Drew Adams 2021-01-24 21:25 ` Stefan Monnier 2021-01-26 0:19 ` Lars Ingebrigtsen 2021-01-26 0:27 ` Mauro Aranda
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.