Re: Indirect text properties

[Dmitry Gutov <dgutov@yandex.ru>]

Hi Alan,

On 17.11.2019 19:05, Alan Mackenzie wrote:

> This is an idea I had a couple of years ago, and has recently resurfaced
> in discussions with Dmitry (Subject: Several major modes).
> 
> The idea is that there could be several alternative sets of text
> properties with the same symbol simultaneously in a buffer, the Lisp
> code selecting which to use by binding a dynamic variable.  This would
> be most useful for the syntax-table text property.

Could char-property-alias-alist help?

> How would this work?  In textprop.c, the code would, on any access to a
> text property, check its symbol's property 'indirect-text-property, and
> if that is a non-nil symbol, access it's value (another symbol) and use
> that as the symbol for the text property instead.  It's easier to say in
> code, which would look something like:
> 
>      #define TEXP_PROP_END_NAME(sym) \
>          !NILP (itp = Fget (sym, Qindirect_text_property)) && SYMPOLP (itp) \
>          && !NILP (etp = find_symbol_value (itp)) && SYMBOLP (etp) \
>          ? etp : sym
> 
> .  To switch to a different set of, e.g., syntax-table text properties
> it would suffice to bind the lisp variable i-t-p to, say, the gensym
> syntax-table-13.  Of course low level caches, e.g. in syntax.c, would
> have to be kept synchronised, too.

It's a lot of work with likely some performance overhead even for the 
default case as well. It sounds like it could be a piece of the puzzle, 
but let's see if we get the full picture first.

Also, I think most (all?) of this proposal could be implemented in Lisp 
by just setting the 'syntax-table' on the overlays that cover different 
submode regions. With more overhead when setting but less overhead than 
accessing the values.

> So, what use would it be?  What I have proposed to Dmitry is having a
> distinct set of syntax-table properties for each major mode chunk of an
> MMM Mode ("multiple major mode") buffer.  Say syntax-table-13 would be
> the set for a CC Mode chunk.  Outside of that chunk, every character
> would be given a space syntax-table-13 text property.  This is the
> critical thing.
> 
> Thus all actions dependent upon syntax (and there are a LOT), could be
> performed by CC Mode in the chunk without the other chunks getting in
> the way.  It may not even be necessary to narrow to the chunk.

It doesn't seem like it covers all problematic cases. Maybe not even the 
majority:

- Would this win over "local" syntax-table properties as assigned by 
syntax-table? By the usual logic of how we implement property 
priorities, probably not. But it should, for this to work.
- Some code can just be looking for certain characters instead of syntax 
classes with re-search-backward, etc. It wouldn't be fooled either. So 
this would likely require some "are we still in the same major mode" 
predicate. At which point we might get by without the space-syntax-table 
swapping entirely.

So what are the exact scenarios that your aim is to fix with this?

/Cc Vitalie, he could have some ideas, maybe even tell us how Polymode 
maybe solves this problem already.