Re: signal handling bogosities

[Richard Stallman <rms@gnu.org>]

    That signal results in `note_mouse_movement', and then
    `note_mouse_highlight' being called:

       #11 0x080b2345 in note_mouse_highlight (f=0x850aa18, x=184, y=260)
	   at /usr/local/src/emacs/src/xterm.c:7407
       #12 0x080b162e in note_mouse_movement (frame=0x850aa18, event=0xbffd1064)
	   at /usr/local/src/emacs/src/xterm.c:6893
       #13 0x080b5f05 in handle_one_xevent (dpyinfo=0x84f5490, eventp=0xbffd13ac, 
	   bufp_r=0xbffd1418, numcharsp=0xbffd141c, finish=0xbffd13a8)
	   at /usr/local/src/emacs/src/xterm.c:11291

    note_mouse_highlight then tries to figure out the proper mouse-face-id,
    which calls face realization, and if realize-face-filter-functions has
    a non-nil value, calls the lisp interpreter, and thus dies as seen.

I am surprised that the signal handler does face realization.  I would
have expected redisplay ought to do that job.  When the signal handler
runs, it should just look up the data that was computed by redisplay.

In the past, face realization did not evaluate any Lisp code, so
calling it from the signal handler was not a bug.  It may have been
bad design though.

    display the mouse face, and in other branches of the code the whole
    redisplay engine seems to be invoked, for exposure events (I don't know
    whether that can result in lisp code being called, but it seems as if it
    could -- given the complexity of redisplay, it's kind of hard to tell).

That seems bizarre too.  Can you please show me what you have learned
about this?

      How hard would be to
    restructure things to just queue this stuff for an event-loop outside
    the signal handler to handle?

That design has a serious drawback: the screen won't refresh while Emacs
is running.

The design idea used to be that the signal handler would update the
screen in a simple way based on tables that were computed in advance
by redisplay.  This avoided the problem we have now, and would
redisplay immediately even when Emacs is running.  Can we make it work
this way again?

Gerd wrote:

    Specifically for mouse-highlighting there may be a cheaper solution,
    though.  IIRC, I once talked with Stefan Monnier about generating
    mouse-highlight input events for mouse highlights instead of doing the
    display directly when handling the mouse movement event (analogous to
    help-echo, for example).

If we handle mouse highlighting by generating input events to do the
work at main program level, then the highlighting won't change when
you move the mouse while Emacs is running a Lisp program.  Is that
acceptable?

It is not as bad as failing to refresh the screen at all while
a Lisp program is running, but it is still somewhat undesirable.