emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Complex SPEC for variables/customization like font-lock-keywords/org


From: Stefan Monnier
Subject: Re: Complex SPEC for variables/customization like font-lock-keywords/org-capture-templates/etc
Date: Fri, 24 Nov 2023 23:03:14 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

> Or font-lock-keywords... Last time I were seriously developing new
> keywords, I had to do it by trial-and-error and even examine
> font-lock sources.
[...]
> I do not know a good solution to the above, and thus would like to
> discuss this problem.
>
> Some possible ideas:
>
> 1. Provide some universal mechanism for type-validation of variables.
>    Something similar to :type spec in defcustom, but for Elisp
>    variables. This will at least catch invalid values.

IME, the problem usually stems from a confusion between code and data:
`font-lock-keywords` should hold code (i.e. something like a function)
rather than nested-lists-with-special-structure.
We could then provide some kind of macro to make it easier to define
these functions.

That's what I tried to do with `syntax-propertize-rules`, which is
otherwise very similar to the previous `font-lock-syntactic-keywords`.
That's also what I did with `bindat-type`.

This has the advantage that the macro can make various sanity checks
(and hence detect some of the possible errors), and that we can (to
some extent) Edebug the result.

I intended to try and provide a similar replacement facility for
`font-lock-keywords`, but haven't gotten to it.

> 3. Enhance eldoc to show a tip about variable value structure, similar
>    to what is done for function arguments.

It doesn't really work for `bindat-type`, but the use of macros should
make it easier because the code tells us reliably  that this is a Bindat
type whereas nothing in the declaration of (defvar
my-font-lock-keywords-1 <FOO>) that the <FOO> nested lists are meant to
be font-lock keywords (unless we use heuristics based on var names,
which quickly become ugly and brittle).


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]