Re: A vision for multiple major modes: some design notes

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 21 Apr 2016 09:59:02 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: acm@muc.de, emacs-devel@gnu.org
> 
> But just what does "the parts that affect redisplay" mean?
> If we mean parts that need to do something particular wrt
> redisplay, then yes, that makes sense.

I mean the part that is needed for redisplay to behave in each island
according to user expectations.  For example, imagine that a mode that
is relevant to a certain island chain sets up face-remapping-alist in
some particular way -- when redisplay does its job, it repeatedly
consults this variable when it needs to compute faces.  I'm saying
that the part of the changes for this feature that affects redisplay
will have to arrange for recalculation of the value of
face-remapping-alist when the display engine gets to examining the
portion of buffer text that belongs to this island chain.  Since the
position where the display engine processes is not visible to Lisp,
this arrangement will have to be in C.  And similarly with any other
variable whose value the display engine accesses from its C code, like
standard-display-table, for example.

> You mentioned earlier that redisplay needs to access
> buffer-local variables as it moves through the buffer.
> And you said that redisplay needs to get the right values
> of such variables.
> 
> But for some island-chain operations, e.g. some that I'm
> thinking of that do not care about the mode of a chain
> or whether it even has a mode, I don't see why redisplay
> would need to do anything special.

This could be so in some particular use cases, but it's not so in
general.  Modes do affect the way text is displayed.  Besides, Alan
says that "most" buffer-local variables will become island-chain
local.  If we believe him, then your use cases you mention above are
lucky exceptions rather than the rule.