bug#63253: 29.0.90; with-delayed-message fails in combination with inhibit-message

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

> There seems to exist an interaction issue of `with-delayed-message' with
> `inhibit-message'.

Very much so, indeed.  The issue is fundamentally linked to
`set-message-function`:

`with-delayed-message` calls `message3` (via
`with_delayed_message_display`) from an "atimer", i.e. a thing that can
be run from `process_pending_signals`, `unblock_input`, `maybe_quit`, ...

AFAIK these are places where it's safe to run some C code, but not
places where it's safe to run arbitrary ELisp code.

So `set-message-function` is "dangerous" because it runs ELisp code from
`message3` => `message3_nolog` => `set_message`.

I think this is related to bug#58042.

Here the problem is that the regexp engine is stateful, so calling
a regexp function in the middle of another regexp match causes serious
problems.  When we need to run ELisp from a regexp match for
on-the-fly syntax-propertization (in `parse_sexp_propertize`), we're
careful to try and detect if the ELisp code may have modified the
current buffer and we re-set the `gl_state` with a call to
`SETUP_SYNTAX_TABLE`.

But when `with-delayed-message' performs a regexp operation from within
another regexp match, it doesn't re-set the `gl_state`, which then leads
to this "Error in syntax_table logic for to-the-end intervals" error.

I'm surprised we haven't yet seen the same problem when the ELisp code is
run via things like -[EmacsView layoutSublayersOfLayer:] which can be
called from `maybe_quit` and call `redisplay` which in turn can run
arbitrary ELisp code (via `mode-line-format`, jit-lock, you name it).


        Stefan