bug#48409: Text runs away before user can copy it

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 14 May 2021 20:53:38 +0000
> Cc: juri@linkov.net, 48409@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Alan, is the below the right fix?  The problem is that no one is
> > setting up the minibuffer in inactive mode until after the first time
> > the minibuffer is activated.
> 
> > diff --git a/src/minibuf.c b/src/minibuf.c
> > index 428998a..9ec93a0 100644
> > --- a/src/minibuf.c
> > +++ b/src/minibuf.c
> > @@ -2297,6 +2297,8 @@ init_minibuf_once_for_pdumper (void)
> >    minibuf_prompt = Qnil;
> >    minibuf_save_list = Qnil;
> >    last_minibuf_string = Qnil;
> > +  Lisp_Object minibuf = get_minibuffer (0);
> > +  set_minibuffer_mode (minibuf, 0);
> >  }
> > 
> >  void
> 
> I'm not entirely sure.  I actually added a "get_minibuffer (0);" to
> init_minibuf_once in my commit earlier on today, so perhaps the
> "set_minibuffer_mode (minibuf, 0);" really belongs in that function.

init_minibuf_once isn't called after dumping, so that would not help.
We need to make sure the minibuffer is put in inactive mode when we
start Emacs.

> I'm not quite sure in my own mind what should go into init_minibuf_once
> and what into init_minibuf_once_for_pdumper.  I've taken as the
> criterion what the comment there says:
> 
>   /* We run this function on first initialization and whenever we
>      restore from a dump file.  pdumper doesn't try to preserve
>      frames, windows, and so on, so reset everything related here.  */
> 
> , and thus put the creation of  *Minibuf-0* into init_minibuf_once.

See above: this won't survive the dumping because the minibuffer's
mode isn't dumped.  And I see no reason to dump it; after all, it
only makes sense to dump things whose preparation is time-consuming.

> It would be good to have a relatively simple fix for something in
> minibuf.c, for once.  ;-)

And I thought I was fine providing a very simple fix.  Oh well...