all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Tassilo Horn <tsdh@gnu.org>
To: Daniel Colascione <dancol@dancol.org>
Cc: Stefan Monnier <monnier@IRO.UMontreal.CA>,
	Artur Malabarba <bruce.connor.am@gmail.com>,
	emacs-devel <emacs-devel@gnu.org>
Subject: Re: [Emacs-diffs] master 51e7e46: Font-lock elisp macros/special forms dynamically
Date: Mon, 16 Mar 2015 10:36:23 +0100	[thread overview]
Message-ID: <878uexjnc8.fsf@gnu.org> (raw)
In-Reply-To: <87sid52x7y.fsf@gnu.org> (Tassilo Horn's message of "Mon, 16 Mar 2015 08:54:57 +0100")

[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]

Tassilo Horn <tsdh@gnu.org> writes:

>> Instead of doing it this way, why not make a font-lock matcher that
>> looks at *every* initial sexp atom, calls intern-soft on it, and
>> applies a face that depends on properties of the found symbol? This
>> way, we'd update fontification not only after load, but also after
>> eval-defun, and it'd be easy to make a `declare'-form that provided
>> for exceptions from the general rule.
>
> Also sounds good to me, and even simpler implementation-wise.  So I'm
> happy to implement it that way if nobody comes up with a reason why
> that's not the right way.

I've just tried that out in a local branch and it works good.  I went
with the opt-in variant for now (but I can change that) so that you
define macros which should be highlighted like so:

--8<---------------cut here---------------start------------->8---
(defmacro if-let (bindings then &rest else)
  (declare (indent 2)
	   (font-lock-keyword t) ;; <=================== HERE!
	   (debug ((&rest (symbolp form)) form body)))
  (when (and (<= (length bindings) 2)
             (not (listp (car bindings))))
    ;; Adjust the single binding case
    (setq bindings (list bindings)))
  `(let* ,(internal--build-bindings bindings)
     (if ,(car (internal--listify (car (last bindings))))
         ,then
       ,@else)))
--8<---------------cut here---------------end--------------->8---

IMHO, that's better than the regexp variant.  However, when a new macro
with `font-lock-keyword' declaration gets defined (or the value is
changed for some existing macro), we still need to flush existing elisp
buffers.  Else, the effect won't be visible there.

I'm not sure from where I should do that.  On a very fine-granular
basis, the function handling the `font-lock-keyword' declaration could
do that.  But that would mean many flushes when a file with many such
macros gets loaded.  Alternatively, an after-load-function could do
that, but that would miss changes manifested with C-c C-e.

Bye,
Tassilo

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 212 bytes --]

  reply	other threads:[~2015-03-16  9:36 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20150315082509.21193.18465@vcs.savannah.gnu.org>
     [not found] ` <E1YX3rB-0005WV-PA@vcs.savannah.gnu.org>
2015-03-15  9:12   ` [Emacs-diffs] master 51e7e46: Font-lock elisp macros/special forms dynamically Daniel Colascione
2015-03-15 15:11     ` Artur Malabarba
2015-03-15 17:20     ` Drew Adams
2015-03-15 19:15     ` Stefan Monnier
2015-03-16  1:35       ` Artur Malabarba
2015-03-16  3:07         ` Stefan Monnier
2015-03-16  7:07           ` Tassilo Horn
2015-03-16  7:10             ` Daniel Colascione
2015-03-16  7:54               ` Tassilo Horn
2015-03-16  9:36                 ` Tassilo Horn [this message]
2015-03-16 12:58               ` Stefan Monnier
2015-03-16 14:47                 ` Tassilo Horn
2015-03-16 17:31                   ` Stefan Monnier
2015-03-16 20:26                     ` Tassilo Horn
2015-03-16 20:39                       ` Daniel Colascione
2015-03-16 20:56                         ` Stefan Monnier
2015-03-17  9:36                           ` Tassilo Horn
2015-03-17 10:17                             ` Artur Malabarba
2015-03-17 16:34                             ` Stefan Monnier
2015-03-17 16:47                               ` Nicolas Richard
2015-03-18  7:17                               ` Tassilo Horn
2015-03-18  9:10                                 ` Artur Malabarba
2015-03-18  9:20                                   ` Dmitry Gutov
2015-03-18 13:13                                 ` Stefan Monnier
2015-03-18 16:12                                   ` Tassilo Horn
2015-03-18 16:44                                     ` Stefan Monnier
2015-03-16 12:56             ` Stefan Monnier
2015-03-16  7:41       ` Tassilo Horn
2015-03-16 12:59         ` Stefan Monnier
2015-03-16 14:23           ` Artur Malabarba
2015-03-15 15:09   ` Artur Malabarba
2015-03-16  6:40     ` [Emacs-diffs] " Tassilo Horn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878uexjnc8.fsf@gnu.org \
    --to=tsdh@gnu.org \
    --cc=bruce.connor.am@gmail.com \
    --cc=dancol@dancol.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.