Re: Selecting tooltip frames considered harmful

[martin rudalics]

>> (1) Ignore the message in message3_nolog (the ideal solution but maybe
>>       too simplistic).
{...]
> I think we should do (1) and document it.

I'd tend to agree but I'm not sure whether the story will end here.

First of all I have to mention that the toy examples I presented will
hardly occur in practice.  Moreover, they could be easily fixed by
making 'visible-frame-list' not return a tooltip frame (and thus
always return a subset of the elements returned by 'frame-list') and
by having 'next-frame' and 'previous-frame' never return a tooltip
frame either.  This way the user should no longer be enabled to select
a tooltip frame from Elisp.

The problem did happen in practice here because I started implementing
a feature that allows mouse drags to cross frame boundaries.  This
means that when processing a MotionNotify event which is currently
handled as

        f = (x_mouse_grabbed (dpyinfo) ? dpyinfo->last_mouse_frame
             : x_window_to_frame (dpyinfo, event->xmotion.window));

I have to set f to the frame specified by the event window instead of
the last mouse frame.  If I now show a tooltip frame during mouse
tracking (as 'mouse-drag-and-drop-region' does by default), that event
frame happens to be a tooltip frame surprisingly often, in particular
with the Lucid build.

I resolved this problem by never choosing a tooltip frame in the
scenario above (and a few related ones) but always go to the initially
grabbed frame instead.  Still I wonder whether the problem with a
selected tooltip frame might arise in practice and whether we should
do something about it.

Unfortunately, when we allow selecting a tooltip frame (1) is not
sufficient since Emacs will crash immediately afterwards - xdisp.c has
message_with_string, vmessage, setup_echo_area_for_printing,
redisplay_internal, see

        internal_condition_case_1 (redisplay_window_1,
                                   FRAME_MINIBUF_WINDOW (sf), list_of_error,
                                   redisplay_window_error);

and

      Lisp_Object mini_window = FRAME_MINIBUF_WINDOW (sf);
      struct frame *mini_frame = XFRAME (WINDOW_FRAME (XWINDOW (mini_window)));

all silently assuming that the selected frame has a minibuffer window.
So the necessary changes are quite substantial.  And obviously the
abort in minibuffer.c I cited earlier

      /* I don't think that any frames may validly have a null minibuffer
         window anymore.  */
      if (NILP (sf->minibuffer_window))
        emacs_abort ();

is even more difficult to handle.

martin