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: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, 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 11:39:49 -0700 (PDT)

> > > > 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?  If you are unwilling to fix the
code, will you fix the doc?

Will you update the doc to say that `make-frame' does not (or might
not, or does not in the following cases...) respect this and that
parameter (whichever parameters it does not respect)?

Will you tell users in the doc that if they want (this or that part
of) the PARAMETERS argument to have any effect they will need to call
`set-frame-parameter' after `make-frame', to set those parameters as
they expected `make-frame' would have done?  IOW, PARAMETERS, or at
least some of it, might have no effect, so users had better find
some other way to set the frame parameters?

I find your reaction here to be dismissive and overreactive, so far.

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?

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?

It seems to me that a proper fix for the problem described in the
bug report that this "fix" was for is to do something specific for
the initial Emacs frame only - which is _anyway_ special-cased.  Take
some code from the existing `make-frame' and give it another name for
that special case, for example.

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?

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.

Previous Next

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