GNU bug report logs - #24085
25.1.50; `make-frame' given `top' param creates frame with ~10x smaller `top'

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: rudalics <at> gmx.at, 24085 <at> debbugs.gnu.org
Subject: bug#24085: 25.1.50; `make-frame' given `top' param creates frame with ~10x smaller `top'
Date: Wed, 27 Jul 2016 22:00:33 +0300

> Date: Wed, 27 Jul 2016 11:39:49 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: rudalics <at> gmx.at, 24085 <at> debbugs.gnu.org
> 
> > > > > Would someone please revert this, and let `make-frame' respect the
> > > > > frame parameters handed to it, in particular `top'?
> > > >
> > > > Not a chance, sorry.
> > >
> > > Huh? What's that all about?
> > 
> > Reverting the change will reintroduce the bug it fixed
> 
> Obviously, as I indicated in my earlier message, I meant that the
> bug that it fixed should be fixed properly, without treading on
> `make-frame'.  If on MS Windows you think the first Emacs frame
> should be positioned so that it does not overlap the task bar,
> then do that.  But do it without affecting what `make-frame' does.
> 
> > so doing that is out of the question.
> 
> What _is_ in the question, then?

Anything else.

> If you are unwilling to fix the code, will you fix the doc?

If that's the best we can do, yes.

> Just what bug did this change seek to fix?  Wasn't it only the default,
> initial behavior of Emacs for the initial frame?  If so, how is this
> general change to `make-frame' the right fix for that bug?

Please re-read the discussion, the answers are there.

> And how would it hurt for `make-frame' to at least respect an _explicit_
> frame alist argument, which is, after all, optional?  Why does it have
> such an argument, if it no longer respects it?

The code that bothers you is not in make-frame.

> But why take over the single, general-purpose frame-creation Lisp
> function we have, changing its behavior to ignore parts of optional
> arg PARAMETERS (on one platform, no less), just to accommodate the
> special case of the initial frame?

No one took over any Lisp function.  The code in question is deep in
the low-level support for creating frames on Windows.  What it does is
make sure a frame, any frame, is not displayed with its echo area's
view obstructed by the task bar.

> This makes no sense to me.  And I find it hard to believe that you
> would not consider fixing that bug properly and restoring `make-frame'
> to a general-purpose function that respects whatever optional frame
> parameters are specified.

You put in my mouth things I didn't say.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.