unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* How about making `set-minibuffer-window' obsolete?
@ 2021-03-16 18:16 Alan Mackenzie
  2021-03-16 18:42 ` Eli Zaretskii
                   ` (5 more replies)
  0 siblings, 6 replies; 18+ messages in thread
From: Alan Mackenzie @ 2021-03-16 18:16 UTC (permalink / raw)
  To: emacs-devel

Hello, Emacs.

Does anybody have any objection to me making set-minibuffer-window
obsolete?

It's defined in src/minibuf.c, but not used by any C function, and it's
not used by any Lisp in Emacs itself - the nearest to a use is a
commented out occurrence in lisp/textmodes/ispell.el.

This function just sets the C variable minibuf_window.  This variable is
defined (by comment) to be the minibuffer window of the selected frame.
So setting it to a random mini-window will cause nasty problems.

Actually, I'd prefer just to remove the function entirely - but there's
always the chance it's being used by some external library.

So, any objections?

-- 
Alan Mackenzie (Nuremberg, Germany).



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: How about making `set-minibuffer-window' obsolete?
  2021-03-16 18:16 How about making `set-minibuffer-window' obsolete? Alan Mackenzie
@ 2021-03-16 18:42 ` Eli Zaretskii
  2021-03-16 20:50   ` Alan Mackenzie
  2021-03-16 19:42 ` [External] : " Drew Adams
                   ` (4 subsequent siblings)
  5 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2021-03-16 18:42 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

> Date: Tue, 16 Mar 2021 18:16:35 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> Does anybody have any objection to me making set-minibuffer-window
> obsolete?
> 
> It's defined in src/minibuf.c, but not used by any C function, and it's
> not used by any Lisp in Emacs itself - the nearest to a use is a
> commented out occurrence in lisp/textmodes/ispell.el.
> 
> This function just sets the C variable minibuf_window.  This variable is
> defined (by comment) to be the minibuffer window of the selected frame.
> So setting it to a random mini-window will cause nasty problems.
> 
> Actually, I'd prefer just to remove the function entirely - but there's
> always the chance it's being used by some external library.
> 
> So, any objections?

I'd object to obsoleting a command just because it can be dangerous
when used unwisely.  Emacs always gives you enough rope to hang
yourself, and trusts you that you won't.



^ permalink raw reply	[flat|nested] 18+ messages in thread

* RE: [External] : How about making `set-minibuffer-window' obsolete?
  2021-03-16 18:16 How about making `set-minibuffer-window' obsolete? Alan Mackenzie
  2021-03-16 18:42 ` Eli Zaretskii
@ 2021-03-16 19:42 ` Drew Adams
  2021-03-16 23:04   ` Alan Mackenzie
  2021-03-16 23:00 ` Stefan Monnier
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 18+ messages in thread
From: Drew Adams @ 2021-03-16 19:42 UTC (permalink / raw)
  To: Alan Mackenzie, emacs-devel@gnu.org

> Does anybody have any objection to me making set-minibuffer-window
> obsolete?
> 
> It's defined in src/minibuf.c, but not used by any C function, and it's
> not used by any Lisp in Emacs itself - the nearest to a use is a
> commented out occurrence in lisp/textmodes/ispell.el.
> 
> This function just sets the C variable minibuf_window.  This variable is
> defined (by comment) to be the minibuffer window of the selected frame.
> So setting it to a random mini-window will cause nasty problems.
> 
> Actually, I'd prefer just to remove the function entirely - but there's
> always the chance it's being used by some external library.
> 
> So, any objections?

Thanks for asking.  Hope anyone who uses it gets a
chance to see the question and respond.  (How to know?)

I don't use it, so a priori no objection from me wrt
my code.

But is the _only_ reason to remove it that it's not
being used in the vanilla Emacs code?  If so, what's
the problem with keeping it?

If we keep it, maybe you'll want to add a comment
saying "setting it to a random mini-window will cause
nasty problems" or what you had in mind about that. 



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: How about making `set-minibuffer-window' obsolete?
  2021-03-16 18:42 ` Eli Zaretskii
@ 2021-03-16 20:50   ` Alan Mackenzie
  2021-03-17 12:57     ` Eli Zaretskii
  0 siblings, 1 reply; 18+ messages in thread
From: Alan Mackenzie @ 2021-03-16 20:50 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

Hello, Eli.

On Tue, Mar 16, 2021 at 20:42:32 +0200, Eli Zaretskii wrote:
> > Date: Tue, 16 Mar 2021 18:16:35 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > Does anybody have any objection to me making set-minibuffer-window
> > obsolete?

> > It's defined in src/minibuf.c, but not used by any C function, and it's
> > not used by any Lisp in Emacs itself - the nearest to a use is a
> > commented out occurrence in lisp/textmodes/ispell.el.

> > This function just sets the C variable minibuf_window.  This variable is
> > defined (by comment) to be the minibuffer window of the selected frame.
> > So setting it to a random mini-window will cause nasty problems.

> > Actually, I'd prefer just to remove the function entirely - but there's
> > always the chance it's being used by some external library.

> > So, any objections?

> I'd object to obsoleting a command just because it can be dangerous
> when used unwisely.

Every use of this command is unwise.  It cannot possibly do anything
useful.  It can only cause problems.

> Emacs always gives you enough rope to hang yourself, and trusts you
> that you won't.

Rope is generally useful stuff.  Changing the value of an internal C
variable in violation of its definition is never useful.

This command appears to have been useful in the distant past - it's last
use was commented out in 1998 in the following commit:

    commit f5136913a18bd7415c59dbf7bcaf3c316593c41d
    Author: Richard M. Stallman <rms@gnu.org>
    Date:   Thu Apr 30 06:43:48 1998 +0000

        Generalized region skipping added.
        Checks comments only in code.
	Added backward compatible support for customize.

Could I ask you, please, to reconsider?

-- 
Alan Mackenzie (Nuremberg, Germany).



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: How about making `set-minibuffer-window' obsolete?
  2021-03-16 18:16 How about making `set-minibuffer-window' obsolete? Alan Mackenzie
  2021-03-16 18:42 ` Eli Zaretskii
  2021-03-16 19:42 ` [External] : " Drew Adams
@ 2021-03-16 23:00 ` Stefan Monnier
  2021-03-16 23:24   ` Alan Mackenzie
  2021-03-17  3:31   ` Eli Zaretskii
  2021-03-16 23:17 ` Dmitry Gutov
                   ` (2 subsequent siblings)
  5 siblings, 2 replies; 18+ messages in thread
From: Stefan Monnier @ 2021-03-16 23:00 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

> This function just sets the C variable minibuf_window.

Reminds me: any hope we can get rid of this variable
(and just always use `XFRAME (selected_frame)->minibuffer_window)` instead?)


        Stefan




^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [External] : How about making `set-minibuffer-window' obsolete?
  2021-03-16 19:42 ` [External] : " Drew Adams
@ 2021-03-16 23:04   ` Alan Mackenzie
  0 siblings, 0 replies; 18+ messages in thread
From: Alan Mackenzie @ 2021-03-16 23:04 UTC (permalink / raw)
  To: Drew Adams; +Cc: emacs-devel@gnu.org

Hello, Drew.

On Tue, Mar 16, 2021 at 19:42:11 +0000, Drew Adams wrote:
> > Does anybody have any objection to me making set-minibuffer-window
> > obsolete?

> > It's defined in src/minibuf.c, but not used by any C function, and it's
> > not used by any Lisp in Emacs itself - the nearest to a use is a
> > commented out occurrence in lisp/textmodes/ispell.el.

> > This function just sets the C variable minibuf_window.  This variable is
> > defined (by comment) to be the minibuffer window of the selected frame.
> > So setting it to a random mini-window will cause nasty problems.

> > Actually, I'd prefer just to remove the function entirely - but there's
> > always the chance it's being used by some external library.

> > So, any objections?

> Thanks for asking.  Hope anyone who uses it gets a
> chance to see the question and respond.  (How to know?)

I doubt there's anybody using it.  I don't think anybody's used it since
1998.

> I don't use it, so a priori no objection from me wrt
> my code.

> But is the _only_ reason to remove it that it's not
> being used in the vanilla Emacs code?  If so, what's
> the problem with keeping it?

It's an unnecessary function with no legitimate use which could be
damaging.

> If we keep it, maybe you'll want to add a comment
> saying "setting it to a random mini-window will cause
> nasty problems" or what you had in mind about that. 

That's an idea!

-- 
Alan Mackenzie (Nuremberg, Germany).



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: How about making `set-minibuffer-window' obsolete?
  2021-03-16 18:16 How about making `set-minibuffer-window' obsolete? Alan Mackenzie
                   ` (2 preceding siblings ...)
  2021-03-16 23:00 ` Stefan Monnier
@ 2021-03-16 23:17 ` Dmitry Gutov
  2021-03-16 23:28 ` Stefan Monnier
  2021-03-17  8:44 ` martin rudalics
  5 siblings, 0 replies; 18+ messages in thread
From: Dmitry Gutov @ 2021-03-16 23:17 UTC (permalink / raw)
  To: Alan Mackenzie, emacs-devel

On 16.03.2021 20:16, Alan Mackenzie wrote:
> Actually, I'd prefer just to remove the function entirely - but there's
> always the chance it's being used by some external library.

I've looked at the few 3rd party packages which deal with the 
minibuffer, and none of them use it.



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: How about making `set-minibuffer-window' obsolete?
  2021-03-16 23:00 ` Stefan Monnier
@ 2021-03-16 23:24   ` Alan Mackenzie
  2021-03-17  3:31   ` Eli Zaretskii
  1 sibling, 0 replies; 18+ messages in thread
From: Alan Mackenzie @ 2021-03-16 23:24 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

Hello, Stefan.

On Tue, Mar 16, 2021 at 19:00:53 -0400, Stefan Monnier wrote:
> > This function just sets the C variable minibuf_window.

> Reminds me: any hope we can get rid of this variable
> (and just always use `XFRAME (selected_frame)->minibuffer_window)` instead?)

I've been thinking about that quite a lot in my recent struggles with
src/minibuf.c.  minibuf_window doesn't seem to fulfil much of a purpose.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: How about making `set-minibuffer-window' obsolete?
  2021-03-16 18:16 How about making `set-minibuffer-window' obsolete? Alan Mackenzie
                   ` (3 preceding siblings ...)
  2021-03-16 23:17 ` Dmitry Gutov
@ 2021-03-16 23:28 ` Stefan Monnier
  2021-03-17  8:44 ` martin rudalics
  5 siblings, 0 replies; 18+ messages in thread
From: Stefan Monnier @ 2021-03-16 23:28 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

> This function just sets the C variable minibuf_window.  This variable is
> defined (by comment) to be the minibuffer window of the selected frame.
> So setting it to a random mini-window will cause nasty problems.

AFAICT it's not that bad in the sense that it may cause a temporary odd
behavior but will be undone next time you select another frame.

Still, it can't see what it can be used for.

I'd strongly recommend marking it obsolete, indeed.  This part of the
code is tricky enough without having to deal with such old code whose
intended behavior has been lost.


        Stefan




^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: How about making `set-minibuffer-window' obsolete?
  2021-03-16 23:00 ` Stefan Monnier
  2021-03-16 23:24   ` Alan Mackenzie
@ 2021-03-17  3:31   ` Eli Zaretskii
  2021-03-17  8:44     ` martin rudalics
  1 sibling, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2021-03-17  3:31 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: acm, emacs-devel

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 16 Mar 2021 19:00:53 -0400
> Cc: emacs-devel@gnu.org
> 
> > This function just sets the C variable minibuf_window.
> 
> Reminds me: any hope we can get rid of this variable
> (and just always use `XFRAME (selected_frame)->minibuffer_window)` instead?)

IME, using selected_frame has its perils.



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: How about making `set-minibuffer-window' obsolete?
  2021-03-16 18:16 How about making `set-minibuffer-window' obsolete? Alan Mackenzie
                   ` (4 preceding siblings ...)
  2021-03-16 23:28 ` Stefan Monnier
@ 2021-03-17  8:44 ` martin rudalics
  2021-03-17 13:17   ` Eli Zaretskii
  5 siblings, 1 reply; 18+ messages in thread
From: martin rudalics @ 2021-03-17  8:44 UTC (permalink / raw)
  To: Alan Mackenzie, emacs-devel

 > Does anybody have any objection to me making set-minibuffer-window
 > obsolete?
 >
 > It's defined in src/minibuf.c, but not used by any C function, and it's
 > not used by any Lisp in Emacs itself - the nearest to a use is a
 > commented out occurrence in lisp/textmodes/ispell.el.
 >
 > This function just sets the C variable minibuf_window.  This variable is
 > defined (by comment) to be the minibuffer window of the selected frame.
 > So setting it to a random mini-window will cause nasty problems.
 >
 > Actually, I'd prefer just to remove the function entirely - but there's
 > always the chance it's being used by some external library.
 >
 > So, any objections?

Rather `set-minibuffer-window' should take as argument a frame to set
the 'minibuffer-window' parameter of that frame.  This way it would
become the counterpart of `minibuffer-window' which takes as argument a
frame and returns that frame's minibuffer window.

The current semantics of `set-minibuffer-window' is of no practical use.
Lisp code should never deal with minibuf_window directly.  However,
every minibuffer interaction should be aware of the fact that any
frame's minibuffer window might change via fset_minibuffer_window under
its feet.

martin



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: How about making `set-minibuffer-window' obsolete?
  2021-03-17  3:31   ` Eli Zaretskii
@ 2021-03-17  8:44     ` martin rudalics
  0 siblings, 0 replies; 18+ messages in thread
From: martin rudalics @ 2021-03-17  8:44 UTC (permalink / raw)
  To: Eli Zaretskii, Stefan Monnier; +Cc: acm, emacs-devel

 >> Reminds me: any hope we can get rid of this variable
 >> (and just always use `XFRAME (selected_frame)->minibuffer_window)` instead?)
 >
 > IME, using selected_frame has its perils.

Indeed.

martin



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: How about making `set-minibuffer-window' obsolete?
  2021-03-16 20:50   ` Alan Mackenzie
@ 2021-03-17 12:57     ` Eli Zaretskii
  2021-03-18 11:46       ` Alan Mackenzie
  0 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2021-03-17 12:57 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

> Date: Tue, 16 Mar 2021 20:50:17 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > I'd object to obsoleting a command just because it can be dangerous
> > when used unwisely.
> 
> Every use of this command is unwise.  It cannot possibly do anything
> useful.  It can only cause problems.

I don't think I agree, not in this general form anyway.  The C code
assigns values to minibuf_window in several places; this function is
the Lisp counterpart of that.  If the C code can assign that variable,
why cannot Lisp code do the same if it needs to?  With the current
tendency to move stuff from C to Lisp, it is even less understandable
why would you think this function's use in unwise.  If you have
specific reasons for that, please describe them in more detail.

> Could I ask you, please, to reconsider?

I might -- if I see some specific reasoning.  I didn't see that yet.



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: How about making `set-minibuffer-window' obsolete?
  2021-03-17  8:44 ` martin rudalics
@ 2021-03-17 13:17   ` Eli Zaretskii
  2021-03-17 15:36     ` martin rudalics
  0 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2021-03-17 13:17 UTC (permalink / raw)
  To: martin rudalics; +Cc: acm, emacs-devel

> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 17 Mar 2021 09:44:37 +0100
> 
> Rather `set-minibuffer-window' should take as argument a frame to set
> the 'minibuffer-window' parameter of that frame.  This way it would
> become the counterpart of `minibuffer-window' which takes as argument a
> frame and returns that frame's minibuffer window.

I'm okay with extending this function that way (assuming the
additional parameter is made &optional).

> The current semantics of `set-minibuffer-window' is of no practical use.

Why not? how is it different from the C code doing the same?

> Lisp code should never deal with minibuf_window directly.

This seems to contradict what you propose above, doesn't it?  Or what
am I missing?

> However, every minibuffer interaction should be aware of the fact
> that any frame's minibuffer window might change via
> fset_minibuffer_window under its feet.

Yes, using these facilities is not for the faint at heart.  But that
doesn't mean it can never be useful, IMO.



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: How about making `set-minibuffer-window' obsolete?
  2021-03-17 13:17   ` Eli Zaretskii
@ 2021-03-17 15:36     ` martin rudalics
  2021-03-17 15:45       ` Eli Zaretskii
  0 siblings, 1 reply; 18+ messages in thread
From: martin rudalics @ 2021-03-17 15:36 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: acm, emacs-devel

 >> Rather `set-minibuffer-window' should take as argument a frame to set
 >> the 'minibuffer-window' parameter of that frame.  This way it would
 >> become the counterpart of `minibuffer-window' which takes as argument a
 >> frame and returns that frame's minibuffer window.
 >
 > I'm okay with extending this function that way (assuming the
 > additional parameter is made &optional).

Setting the minibuffer window of some frame is completely different from
fiddling with minibuf_window directly.  IMO none of the variables like
selected_frame, selected_window or minibuf_window must be set by Lisp
code.

 >> The current semantics of `set-minibuffer-window' is of no practical use.
 >
 > Why not? how is it different from the C code doing the same?

The C code has to do it in a very controlled way, just like setting
selected_window or selected_frame.  Think of how redisplay struggles to
keep the window it selects for redisplay selected after Lisp code
interventions.

 >> Lisp code should never deal with minibuf_window directly.
 >
 > This seems to contradict what you propose above, doesn't it?  Or what
 > am I missing?

The function would set the frame's minibuffer window (aka
f->minibuffer_window) just like setting the 'minibuffer-window' frame
parameter does.  minibuf_window would remain unaffected.

 >> However, every minibuffer interaction should be aware of the fact
 >> that any frame's minibuffer window might change via
 >> fset_minibuffer_window under its feet.
 >
 > Yes, using these facilities is not for the faint at heart.  But that
 > doesn't mean it can never be useful, IMO.

It's already hard enough to handle setting a particular frame's
minibuffer window.  But handling setting minibuf_window from Elisp is
much harder.

martin



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: How about making `set-minibuffer-window' obsolete?
  2021-03-17 15:36     ` martin rudalics
@ 2021-03-17 15:45       ` Eli Zaretskii
  0 siblings, 0 replies; 18+ messages in thread
From: Eli Zaretskii @ 2021-03-17 15:45 UTC (permalink / raw)
  To: martin rudalics; +Cc: acm, emacs-devel

> Cc: acm@muc.de, emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 17 Mar 2021 16:36:39 +0100
> 
>  >> The current semantics of `set-minibuffer-window' is of no practical use.
>  >
>  > Why not? how is it different from the C code doing the same?
> 
> The C code has to do it in a very controlled way, just like setting
> selected_window or selected_frame.

Then let's document that this function should only be used with care,
and move on.



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: How about making `set-minibuffer-window' obsolete?
  2021-03-17 12:57     ` Eli Zaretskii
@ 2021-03-18 11:46       ` Alan Mackenzie
  2021-03-18 12:01         ` Eli Zaretskii
  0 siblings, 1 reply; 18+ messages in thread
From: Alan Mackenzie @ 2021-03-18 11:46 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

Hello, Eli.

On Wed, Mar 17, 2021 at 14:57:19 +0200, Eli Zaretskii wrote:
> > Date: Tue, 16 Mar 2021 20:50:17 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > I'd object to obsoleting a command just because it can be dangerous
> > > when used unwisely.

> > Every use of this command is unwise.  It cannot possibly do anything
> > useful.  It can only cause problems.

> I don't think I agree, not in this general form anyway.  The C code
> assigns values to minibuf_window in several places; this function is
> the Lisp counterpart of that.  If the C code can assign that variable,
> why cannot Lisp code do the same if it needs to?

The C code does it only under very carefully controlled circumstances
(such as when iconising a frame).

> With the current tendency to move stuff from C to Lisp, it is even
> less understandable why would you think this function's use in unwise.
> If you have specific reasons for that, please describe them in more
> detail.

> > Could I ask you, please, to reconsider?

> I might -- if I see some specific reasoning.  I didn't see that yet.

OK.  set-minibuffer-window, as it stands, has no function.  Maybe as an
alternative to obsoleting it, we could give it functionality - the
function could move an open minibuffer from one frame to another frame,
for example.  But I'm not sure what the use case is.  All the
minibuffer-follows-selected-frame stuff is done internally in minibuf.c.

-- 
Alan Mackenzie (Nuremberg, Germany).



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: How about making `set-minibuffer-window' obsolete?
  2021-03-18 11:46       ` Alan Mackenzie
@ 2021-03-18 12:01         ` Eli Zaretskii
  0 siblings, 0 replies; 18+ messages in thread
From: Eli Zaretskii @ 2021-03-18 12:01 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

> Date: Thu, 18 Mar 2021 11:46:57 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > I don't think I agree, not in this general form anyway.  The C code
> > assigns values to minibuf_window in several places; this function is
> > the Lisp counterpart of that.  If the C code can assign that variable,
> > why cannot Lisp code do the same if it needs to?
> 
> The C code does it only under very carefully controlled circumstances
> (such as when iconising a frame).

If that's the real problem, then let's document that this function can
be dangerous and should only be used with extreme care.

> > > Could I ask you, please, to reconsider?
> 
> > I might -- if I see some specific reasoning.  I didn't see that yet.
> 
> OK.  set-minibuffer-window, as it stands, has no function.  Maybe as an
> alternative to obsoleting it, we could give it functionality - the
> function could move an open minibuffer from one frame to another frame,
> for example.  But I'm not sure what the use case is.  All the
> minibuffer-follows-selected-frame stuff is done internally in minibuf.c.

Martin suggested adding functionality, and I'm okay with doing that.



^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2021-03-18 12:01 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-03-16 18:16 How about making `set-minibuffer-window' obsolete? Alan Mackenzie
2021-03-16 18:42 ` Eli Zaretskii
2021-03-16 20:50   ` Alan Mackenzie
2021-03-17 12:57     ` Eli Zaretskii
2021-03-18 11:46       ` Alan Mackenzie
2021-03-18 12:01         ` Eli Zaretskii
2021-03-16 19:42 ` [External] : " Drew Adams
2021-03-16 23:04   ` Alan Mackenzie
2021-03-16 23:00 ` Stefan Monnier
2021-03-16 23:24   ` Alan Mackenzie
2021-03-17  3:31   ` Eli Zaretskii
2021-03-17  8:44     ` martin rudalics
2021-03-16 23:17 ` Dmitry Gutov
2021-03-16 23:28 ` Stefan Monnier
2021-03-17  8:44 ` martin rudalics
2021-03-17 13:17   ` Eli Zaretskii
2021-03-17 15:36     ` martin rudalics
2021-03-17 15:45       ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).