bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alan Mackenzie
Subject: bug#48409: Text runs away before user can copy it
Date: Sat, 15 May 2021 11:15:35 +0000

Hello, Eli.

On Sat, May 15, 2021 at 08:56:41 +0300, Eli Zaretskii wrote:
> > 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.

Thanks for clarifying that.  I'd misunderstood the comments, and got
those two functions' purposes mixed up.

So, your patch is then entirely correct, and what I'd put in yesterday
afternoon is not correct.  I'll get that fixed and committed now.

> > 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...

Sorry, bad wording on my part.  The fix was simple, and I was rejoicing
in that simplicity.

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]