[Top][All Lists]

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

Re: Questions about text properties

From: Garreau\, Alexandre
Subject: Re: Questions about text properties
Date: Sun, 21 Oct 2018 15:35:25 +0200
User-agent: Gnus (5.13), GNU Emacs 25.1.1 (i686-pc-linux-gnu)

Le 21/10/2018 à 15h17, Eli Zaretskii a écrit :
>> From: "Garreau\, Alexandre" <address@hidden>
>> Date: Sun, 21 Oct 2018 05:21:40 +0200
>> – how about adding stuff to a *value* of property, be it a list, or
>>   anything that could inherit, such as an alist, a keymap, etc.? it
>>   seems there are no functions for that;
> Not sure I understand why you need something special: modifying a Lisp
> value, whether to add something or otherwise, is rather trivial, no?

It is.  But the same way, add text-properties using put*/set* functions
(put-text-property, set-text-properties) is rather trivial too, but
there are add-* functions (add-text-properties, add-face-text-property)
because that makes them more standard and because they’re convenient I
guess, and the fact you can use put*/set* functions instead of add*
functions doesn’t make the add* functions useless.

>> – why are properties rear-sticky by default rather than the opposite?
> Because the other alternative is rarely needed.  E.g., if you modify a
> string that has a face, you want the appended characters to inherit
> the same face.  By contrast, inserting before the string rarely needs
> such inheritance.

Ah ok, I didn’t feel like it’s the case, but maybe it is that my editing
is more chaotic than most others’ then.

>> – why is there only a mouse-face property, rather than a hover, click,
>>   pressed, active, focus, etc.
> The usual reason: low demand and/or low motivation to develop features
> that are in low demand.


> Another possible reason is that at least some
> of those (click and press -- what's the difference, btw?)

they were examples as not all interfaces name these the same. CSS use
“active”, which may be less familiar than click (used in js) or pressed,
which is used by I-don’t-recall-which other interface.

> you can have already, by using the 'keymap' property, and perhaps a
> few others.

But these don’t trigger a face or special properties that will keep
being true for a specified and definite amount of time.  A key is

>> – why can it only affects face rather than other properties so that to
>>   extend its behavior?
> By "it" you mean, mouse-face?  Because it's a face.

Erm, yes.  So why is it only a face and not a full plist, that might
also contain a face? potentially also forbidding properties that may
change the size of the text, too, as mouse-face already does for face

>> – sometimes most text properties can take a hook (that will be called
>>   lazily to compute a valid value), sometimes not (like for a display
>>   prop space);
> Not sure what this is about.  In general, only functions have hooks,
> not properties.  How about a couple of examples?

I should have been more precise as now I don’t recall precisely what
details did triggered in me this feeling after ending my reading.

Both help-echo and mouse-face can take a function, so its value will be
more dynamic than with a fixed constant value.  Why only them while other
properties could have them so to be more dynamic?

>> — is the recenter thing about overlays related to the fact buffers are
>>   implemented with a buffer gap, or is it just something similar to
>>   fasten stuff?
> It makes overlay access faster.

Ok so it’s a separate optimization ok.

reply via email to

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