emacs-devel
[Top][All Lists]
Advanced

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

Re: Generalizing prettify-symbols-mode


From: Stefan Monnier
Subject: Re: Generalizing prettify-symbols-mode
Date: Thu, 20 Aug 2015 10:15:08 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

> Is the below what you are suggesting?

Pretty much, yes.  See nitpicks below.

>     (prettify-symbols-compose-predicate): New variable with default
>     value #'prettify-symbols-default-compose-p.

You don't need to state its default value here.

>     (prettify-symbols--compose-symbol): Use
>     prettify-symbols-compose-predicate.

I like to say "Use it" after reordering the entries so that the "used"
thingy is the one mentioned in the previous entry.

> +(defvar-local prettify-symbols-compose-predicate 
> #'prettify-symbols-default-compose-p
> +  "A predicate deciding if the currently matched symbol is to be composed.
> +The predicate has no arguments and is called by font-lock in the
> +context where the regexp match data 0 points to an occurrence of
> +a symbol in `prettify-symbols-alist'.")

The fact that it uses font-lock should not be documented.  We may want
to change that in the future.

> +  (let ((start (match-beginning 0))
> +        (end (match-end 0))
> +        (match (match-string 0)))
> +    (if (funcall prettify-symbols-compose-predicate)

The predicate will probably need to extract the boundary positions and
the string as well, so I think we might as well pass start, end, and
match to prettify-symbols-compose-predicate.  That also means that
prettify-symbols-compose-predicate doesn't need the match-data any more,
which I think is a good side-effect (tho not an important one).  E.g. it
could be useful if we ever end up using a different search strategy
where we either don't use a regexp, or use regexp where the
matched string is not in "subgroup 0".


        Stefan



reply via email to

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