Questions about text properties

Questions about text properties

[Garreau, Alexandre]

I was reading the text properties and overlays manual part and I’ve some
questions about them:
– why is everything using plists rather than alist? if I’m right plists
  are just like alist but more conveniently displayed as sexps (hence
  used for keyword arguments) and not overridable by appending: however
  having a lot of common text properties between part of text makes me
  wonder if sharing properties in memory wouldn’t have been relevant, it
  also would have made inheritance easier;
– 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;
— why does stuff everywhere (e.g. org-mode) appears to just bind RET,
  C-c C-c, mouse events, etc. to contextual do-everything functions,
  rather than only bind these on fontified parts of buffer, so not to
  have such meaningless hard to debug, read, and understand functions;
– why are properties rear-sticky by default rather than the opposite?
  why are stickiness properties biased toward this choice? that seems to
  reflect high confidence toward a such default;
– why is there only a mouse-face property, rather than a hover, click,
  pressed, active, focus, etc. (like in html/css) that would help
  distinguishing point, mouse, region, etc.? that feels rather limited;
– why can it only affects face rather than other properties so that to
  extend its behavior?
– 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);
— 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?

Re: Questions about text properties

[Daniele Nicolodi]

On 20/10/2018 21:21, Garreau, Alexandre wrote:
> — why does stuff everywhere (e.g. org-mode) appears to just bind RET,
>   C-c C-c, mouse events, etc. to contextual do-everything functions,
>   rather than only bind these on fontified parts of buffer, so not to
>   have such meaningless hard to debug, read, and understand functions;

Text properties are applied on fontification (font-lock-mode), and it
can be turned off. Those major modes of course need to work also in that
case. It should also be noted that fontification is the default only
since relatively recently (Emacs 23, maybe?).

Cheers,
Dan

Re: Questions about text properties

[Stefan Monnier]

>> — why does stuff everywhere (e.g. org-mode) appears to just bind RET,
>>   C-c C-c, mouse events, etc. to contextual do-everything functions,
>>   rather than only bind these on fontified parts of buffer, so not to
>>   have such meaningless hard to debug, read, and understand functions;
> Text properties are applied on fontification (font-lock-mode), and it
 ^
SOME

Far from all.


        Stefan

Re: Questions about text properties

[Eli Zaretskii]

> From: "Garreau\, Alexandre" <galex-713@galex-713.eu>
> 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?

> – 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.

> – 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?) you can have
already, by using the 'keymap' property, and perhaps a few others.

> – 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.

> – 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?

> — 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.

Re: Questions about text properties

[Garreau, Alexandre]

Le 21/10/2018 à 15h17, Eli Zaretskii a écrit :
>> From: "Garreau\, Alexandre" <galex-713@galex-713.eu>
>> 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.

Ok.

> 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
instantaneous.

>> – 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
attributes.

>> – 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.

Re: Questions about text properties

[Eli Zaretskii]

> From: "Garreau\, Alexandre" <galex-713@galex-713.eu>
> Cc: emacs-devel@gnu.org
> Date: Sun, 21 Oct 2018 15:35:25 +0200
> 
> Le 21/10/2018 à 15h17, Eli Zaretskii a écrit :
> >> From: "Garreau\, Alexandre" <galex-713@galex-713.eu>
> >> 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

No, they aren't: you could, for example, add-text-properties to a
substring of the characters that have the existing properties.  By
contrast, a value doesn't have this complication.

> 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.

They exist because they require non-trivial transformation of the
underlying data structures, which are not exposed to Lisp.

> > 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
> instantaneous.

A key can be bound to a function that can do anything, including
changing the face of the underlying characters.

> >> – 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

Because it needs a non-trivial support from the display engine.

> 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?

Each property has its own purpose, and they were designed mostly one
by one.