From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Pluim Newsgroups: gmane.emacs.bugs Subject: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values Date: Tue, 03 Apr 2018 10:25:21 +0200 Message-ID: <874lksy9vy.fsf@gmail.com> References: <5AC3232D.1020107@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1522743855 4356 195.159.176.226 (3 Apr 2018 08:24:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 3 Apr 2018 08:24:15 +0000 (UTC) Cc: 31031@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 03 10:24:11 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3HEg-00011J-IC for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Apr 2018 10:24:10 +0200 Original-Received: from localhost ([::1]:42586 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3HGk-0007kU-0o for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Apr 2018 04:26:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60248) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3HGY-0007hD-24 for bug-gnu-emacs@gnu.org; Tue, 03 Apr 2018 04:26:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f3HGU-0005fv-2D for bug-gnu-emacs@gnu.org; Tue, 03 Apr 2018 04:26:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56093) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f3HGT-0005fc-Td for bug-gnu-emacs@gnu.org; Tue, 03 Apr 2018 04:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f3HGT-0007y0-Kx for bug-gnu-emacs@gnu.org; Tue, 03 Apr 2018 04:26:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Apr 2018 08:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31031 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31031-submit@debbugs.gnu.org id=B31031.152274393030586 (code B ref 31031); Tue, 03 Apr 2018 08:26:01 +0000 Original-Received: (at 31031) by debbugs.gnu.org; 3 Apr 2018 08:25:30 +0000 Original-Received: from localhost ([127.0.0.1]:35757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3HFy-0007xF-A4 for submit@debbugs.gnu.org; Tue, 03 Apr 2018 04:25:30 -0400 Original-Received: from mail-wm0-f43.google.com ([74.125.82.43]:37321) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3HFx-0007x5-1p for 31031@debbugs.gnu.org; Tue, 03 Apr 2018 04:25:29 -0400 Original-Received: by mail-wm0-f43.google.com with SMTP id r131so33057440wmb.2 for <31031@debbugs.gnu.org>; Tue, 03 Apr 2018 01:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:mail-copies-to:gmane-reply-to-list :date:in-reply-to:message-id:mime-version:content-transfer-encoding; bh=quwZ0Xfj0nbxYvrlZVHqfDqJJA/Ibv55fjzBeVDKhig=; b=nZfzUFrzIPXRBd9YShP/vLThV7HnfhIOb2W+44VZAPBuZUkHpbH5wj2pd8JbCTrQuz c1kwK03d+t47Q0zNQeJ9JbgNFR+JShIwg3bOo/xU2sCjwewUqpbyUtp4mpHFajKYlYgL IRfAJHhZE7oqvaVL5SYjsr2MaiB6dcln5lhqhhV2c+hWdMjPEkoIDWxu/FkknpweuxD4 ikPsbDsHBZpLawcf/RCBOTyzLe5yXQ11oyHLSVzY+cPx5NC3zoUuDsB4+XPiDVRr3KZZ Yk7Fub4HZ/UdbGKJU/V/z0j6KpxIl/pp8BiFZFjBChGXFCLooslyHRsALIuMZVQc99W2 jZuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:mail-copies-to :gmane-reply-to-list:date:in-reply-to:message-id:mime-version :content-transfer-encoding; bh=quwZ0Xfj0nbxYvrlZVHqfDqJJA/Ibv55fjzBeVDKhig=; b=WnKt9LCFonaVLo8CdWLFPELCH6vv0ox18AzFiZ+eGtDlL59+X9qpbzea25y+j/2dcp e0lORn03yluZxcPFyF36awkzUd95tdJYW0dzynn3u54U/voU45AW2j4c37Gx1p7qhNuL AOryJTD8oFE4BDxMbHRdhJ8zEEXkUYhkRC31Wg33KOTPdJZwrLIb/rKBo1eyzAqxVllH NoGrmiPCJfHnGoRSep8P5hWcxSuZEsN+L9PFJHzq/el0ORoVb7R4GXSRCL2rd4/a9rYm RbUFCbHYwGEp8C94KPl6F3TJP5VjzqPCcpS4iM6KtTfNMnOVz4OtQZcs8B8eOLif26Hr UDuw== X-Gm-Message-State: AElRT7FcolQJCrlZ6Enty4uBiHl3eN4vKGH0NfdiQwOu09avI66HYsqG l1F/xm4mFGTzp1OOiL5iW186TiVk X-Google-Smtp-Source: AIpwx4+lzgNYdcCKiNUlvHFEURrxRrQg2i+a+hCnvnfg5b7iUi0ZqDW45BZ9ijND9RaURDSQ4rzZNA== X-Received: by 10.80.179.74 with SMTP id r10mr15063931edd.228.1522743922801; Tue, 03 Apr 2018 01:25:22 -0700 (PDT) Original-Received: from rpluim ([149.5.228.1]) by smtp.gmail.com with ESMTPSA id l25sm1396147edb.49.2018.04.03.01.25.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 03 Apr 2018 01:25:21 -0700 (PDT) Mail-Copies-To: never Gmane-Reply-To-List: yes In-Reply-To: <5AC3232D.1020107@gmx.at> (martin rudalics's message of "Tue, 03 Apr 2018 08:46:05 +0200") 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:144832 Archived-At: martin rudalics writes: >> The text talks about positioning flush to edges of the "display", which >> I'm interpreting as the dominating monitor in the case of multiple >> monitors. (Is that wrong?) > > I can't tell because I don't use multiple monitors and don't know what > a dominating monitor is. Anyone who does - please compare behavior > and manual with what she experiences in practical work and try to fix > any errors she sees. > I see something similar using GTK on GNU/Linux, see below. >> What I see is that the dominating monitor seems to have no effect, so I >> wonder what "display" means here. >> >> And in fact using any of the following on an existing frame dominated by >> the left monitor or the right monitor sends the frame to the _same_ >> location: its left edge flush with the left edge of the right monitor: >> >> (modify-frame-parameters nil '((left . 0.0))) I see the same: the frame always ends up flush left on the leftmost monitor, regardless of whether it=CA=BCs initially displayed on the left or right. >> (modify-frame-parameters nil '((left . - 0.0))) > > The last specification is wrong - floating point values must be > unsigned. > >> (modify-frame-parameters nil '((left . 1.0))) This flushes almost [1] to the right when the frame is already positioned on the rightmost monitor. When the frame is positioned on the leftmost monitor, it ends up on the right edge of the left monitor. Which monitor is primary doesn=CA=BCt matter, only the relative positioning. > On my single monitor display, evaluating the last form flushes the > frame to the right of the display. If it doesn't on yours, then > please try on a single monitor display first and then describe the > observed misbehavior on your multiple monitor display. Maybe we can > improve it, maybe we have to add a caveat to the manual. I certainly find the current behaviour inconsistent: either the repositioning should happen only within the workarea of each monitor, or it should happen within the sum of the two workareas. What we have now behaves differently depending on whether you flush left or flush right. Note that if I specify to my window manager that one of the monitors is above the other rather than to the right, then the frame repositioning always occurs within the confines of the monitor displaying the frame. Footnotes: [1] Not completely to the right, but that=CA=BCs a different issue