bug#58518: 29.0.50; [PATCH] Turning off compilation-minor-mode removes fontification of other modes

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

> But since it's so unusual, I wonder whether there's any reason we don't
> use this more in general.  Are there performance impacts, for instance?
> (I don't think so, since it's a buffer-local variable.)  But I've added
> Stefan and Eli to the CCs; perhaps they have comments.

I can't remember anyone measuring the performance impact, but it does
come at a cost since every time we call `lookup_char_property` it takes
significantly more work.

This is called at every text-property (or overlay) boundary in things
like `next-single-property-change` and similar operations used by the
redisplay.

The "more work" is the `assq` itself whose time is proportional to the
length of this alist, plus a `plist-get` per alias listed, whenever
the `assq` finds a match (i.e. whenever we're looking for a property
which has aliases).

FWIW, in the past I suggested maybe we should introduce a notion of
"property planes".  So `compilation` could use one property plane,
`font-lock` could use another and they could just blindly remove all the
properties in their plane without affecting others.

The idea is similar to using the approach suggested by "miha", except
that the intention is to implement the hard work of merging the planes
in the code that adds/removes properties rather than in the code which
looks it up (and it would probably only apply to text properties, not to
overlays).
The idea of doing it when adding/removing properties is:
- Should keep the important lookup path used during redisplay fast.
- Should make it possible to run ELisp while merging, thus allowing
  "smart" merging (e.g. concatenating faces, or composing keymaps)
  rather than only choosing the value with highest priority and ignoring
  all the others.

BTW, another option is to use overlays rather than
text-properties :-)


        Stefan