From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#24085: 25.1.50; `make-frame' given `top' param creates frame with ~10x smaller `top' Date: Thu, 28 Jul 2016 17:40:39 +0300 Message-ID: <8337mtsu54.fsf@gnu.org> References: <<<<0bfd2e8d-9d9b-4737-a637-5175eaaf41c0@default> <57987CBA.2060405@gmx.at>>>> <<<<3657859c-03f1-4eca-9a78-a9be0dee6552@default>>>> <<<<83h9bbrqx5.fsf@gnu.org>>>> <<<06a3fb2a-b975-41cf-8aa3-c2cbe207057f@default>>> <<<838twnrngr.fsf@gnu.org>>> <<325b79e8-c40b-46f7-a89a-11f0888b0a68@default>> <<8360rqsy7i.fsf@gnu.org>> <6336b8b4-49c0-4ce6-9044-cf558f12c16e@default> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1469718838 14783 80.91.229.3 (28 Jul 2016 15:13:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Jul 2016 15:13:58 +0000 (UTC) Cc: 24085@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 28 17:13:47 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bSn0M-0003xz-Jr for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Jul 2016 17:13:46 +0200 Original-Received: from localhost ([::1]:53860 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSn0L-0008LN-8U for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Jul 2016 11:13:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42360) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSmVh-0002jL-Ea for bug-gnu-emacs@gnu.org; Thu, 28 Jul 2016 10:42:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bSmVe-0001al-70 for bug-gnu-emacs@gnu.org; Thu, 28 Jul 2016 10:42:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52076) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSmVe-0001af-3k for bug-gnu-emacs@gnu.org; Thu, 28 Jul 2016 10:42:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bSmVd-0002hD-Vg for bug-gnu-emacs@gnu.org; Thu, 28 Jul 2016 10:42:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Jul 2016 14:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24085 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24085-submit@debbugs.gnu.org id=B24085.146971686210286 (code B ref 24085); Thu, 28 Jul 2016 14:42:01 +0000 Original-Received: (at 24085) by debbugs.gnu.org; 28 Jul 2016 14:41:02 +0000 Original-Received: from localhost ([127.0.0.1]:49373 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bSmUg-0002fq-6z for submit@debbugs.gnu.org; Thu, 28 Jul 2016 10:41:02 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51207) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bSmUd-0002fE-Rj for 24085@debbugs.gnu.org; Thu, 28 Jul 2016 10:41:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bSmUS-0001Hw-Gz for 24085@debbugs.gnu.org; Thu, 28 Jul 2016 10:40:54 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45695) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSmUS-0001Hr-DL; Thu, 28 Jul 2016 10:40:48 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3988 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bSmUR-0004Cl-HF; Thu, 28 Jul 2016 10:40:47 -0400 In-reply-to: <6336b8b4-49c0-4ce6-9044-cf558f12c16e@default> (message from Drew Adams on Wed, 27 Jul 2016 13:55:33 -0700 (PDT)) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:121620 Archived-At: > Date: Wed, 27 Jul 2016 13:55:33 -0700 (PDT) > From: Drew Adams > Cc: rudalics@gmx.at, 24085@debbugs.gnu.org > > > 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. > > That's a mistake (misguided), I think. Why was that the solution > (or is the solution) to the problem reported, which was about the > initial frame? Because I think the issue exists not only for the initial frame. See the 10-year old discussion, it's all there. > Can we not fix Emacs so that its avoidance of such positions is for > the initial frame only? I don't think this would be a step in the right direction. Having a frame obscured by window-system or window-manager decorations is a bad screw that IMO we should try to avoid. > Why should the behavior of a general function such as `make-frame' > need to be sacrificed to fix that unique use case? The solution wasn't intended to affect only the initial frame. Once again, please read the past discussion, as the implementation you see now is not an accident, it was intended to do what you see. > And if there _were_ a good reason for `make-frame' to avoid such > positions in a general, default case (which I would disagree with, > FWIW), why would that be the case also for the non-default cases > where you pass an explicit PARAMETERS list to `make-frame'? Surely, > at least in that case the coder's intention should be respected. > And a fortiori if (user-position . t) is in PARAMETERS. I cannot > see any argument for _never_ being able to have `make-frame' respect > PARAMETERS. This could be an idea worth considering, although I'm not necessarily sure it's the best or even a right one. Patches and discussion are welcome. > I think (hope) you are saying that there is no good argument for > not respecting PARAMETERS, but because of the previous, low-level fix, > that's unfortunately where we are today. In that case, let's please > try to do better. If `set-frame-parameter' can in a sense "override" > or work around that low-level dictation of frame positioning, then > I imagine it should be possible for `make-frame' to do the same. The problem is not only technical, it's also a problem of our intent. Do we _want_ to let frames have their echo area obscured? If not, then the fact that set-frame-parameter allows that would be a bug that needs to be fixed. Also, what happens on other window-systems? Martin says most GNU/Linux window managers will behave the same as Emacs on Windows behaves now. > > You put in my mouth things I didn't say. > > I'm glad to hear that, and I apologize if I misunderstood you. > It must be said that you did not say much - hardly much to go on, > to decipher your meaning or intention. What I wrote was very clear, and didn't need any deciphering: reverting that change is out of the question. No more, no less. > Anyway, I take it now that you will seriously consider trying to > fix this problem for `make-frame'? Did I ever say I won't? Why would you even consider such a ridiculous (to say the least) possibility? > I'll say again that this is not something that annoys me in my own > use of Emacs, in general. It basically annoys no one, since the change was made 10 years ago, and we had no complaints. One more factor to consider while discussing this issue, I guess. > Since I have your attention, and if it doesn't take too much of > your time, could you or Martin perhaps please recommend a way of > getting the screen-relative pixel coordinates of a given buffer > position in a given window of a given Emacs frame? This is not the place to ask such question, so I will respond on emacs-devel. Please everybody, don't continue this sub-thread here.