Received: (at 31031) by debbugs.gnu.org; 6 Apr 2018 13:19:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 06 09:19:25 2018
Received: from localhost ([127.0.0.1]:39951 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1f4RH3-0007hA-0r
for submit <at> debbugs.gnu.org; Fri, 06 Apr 2018 09:19:25 -0400
Received: from eggs.gnu.org ([208.118.235.92]:36451)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1f4RH1-0007gv-Hg
for 31031 <at> debbugs.gnu.org; Fri, 06 Apr 2018 09:19:23 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <eliz@HIDDEN>) id 1f4RGs-0005Ys-7e
for 31031 <at> debbugs.gnu.org; Fri, 06 Apr 2018 09:19:18 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level:
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD
autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48526)
by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
id 1f4RGs-0005Yo-3b; Fri, 06 Apr 2018 09:19:14 -0400
Received: from [176.228.60.248] (port=4933 helo=home-c4e4a596f7)
by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
(Exim 4.82) (envelope-from <eliz@HIDDEN>)
id 1f4RGq-0004Yn-SU; Fri, 06 Apr 2018 09:19:13 -0400
Date: Fri, 06 Apr 2018 16:19:10 +0300
Message-Id: <83d0zc1nht.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Robert Pluim <rpluim@HIDDEN>
In-reply-to: <873708pjl1.fsf@HIDDEN> (message from Robert Pluim on Fri, 06
Apr 2018 15:09:46 +0200)
Subject: Re: bug#31031: 27.0;
(elisp) `Position Parameters', floating-point values
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
<5AC3232D.1020107@HIDDEN> <874lksy9vy.fsf@HIDDEN>
<5AC35626.2070700@HIDDEN> <877epowjq9.fsf@HIDDEN>
<5AC48386.8040901@HIDDEN> <87sh8bw4xa.fsf@HIDDEN>
<87fu48pr1l.fsf@HIDDEN> <83in941oj9.fsf@HIDDEN>
<873708pjl1.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 31031
Cc: 31031 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)
> From: Robert Pluim <rpluim@HIDDEN>
> Cc: 31031 <at> debbugs.gnu.org
> Date: Fri, 06 Apr 2018 15:09:46 +0200
>
> > AFAIK, this depends on how the monitors are configured, and perhaps
> > also on the window manager. The "Multiple Terminals" node in ELisp
> > manual is what we felt we could document, and it does hint at what you
> > see, if you read the text carefully.
>
> I guess you mean this bit: "The third part, SCREENNUMBER, identifies a
> zero-based screen number (a separate monitor) that is part of a single
> monitor collection on that X server."
Also, this:
On some multi-monitor setups, a single X display outputs to more than
one physical monitor. You can use the functions
‘display-monitor-attributes-list’ and ‘frame-monitor-attributes’ to
obtain information about such setups.
And this:
‘geometry’
Position of the top-left corner of the monitor’s screen and
its size, in pixels, as ‘(X Y WIDTH HEIGHT)’. Note that, if
the monitor is not the primary monitor, some of the
coordinates might be negative.
> How about adding something like "Such a collection is often treated as
> one bigger virtual screen." ?
Sure, anything that might help understanding the issue without being
too definitive, provided that Martin is happy with the text.
Thanks.
bug-gnu-emacs@HIDDEN:bug#31031; Package emacs.
Full text available.Received: (at 31031) by debbugs.gnu.org; 6 Apr 2018 13:09:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 06 09:09:55 2018 Received: from localhost ([127.0.0.1]:39935 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1f4R7r-0007T4-DS for submit <at> debbugs.gnu.org; Fri, 06 Apr 2018 09:09:55 -0400 Received: from mail-wr0-f172.google.com ([209.85.128.172]:37450) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <rpluim@HIDDEN>) id 1f4R7p-0007Sr-ML for 31031 <at> debbugs.gnu.org; Fri, 06 Apr 2018 09:09:54 -0400 Received: by mail-wr0-f172.google.com with SMTP id l49so1730458wrl.4 for <31031 <at> debbugs.gnu.org>; Fri, 06 Apr 2018 06:09:53 -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; bh=9p5t6DEU6Z/yUDqm99Zbf98RHaYcD2lYJIKOB9Gi2hU=; b=NZAwwJqwhJhfJwGdVqjcJ1lbIY0G9iVkLmPXR6OOL1j0toumI1Vx9x/aKGx1Aq1ivJ 5M/QPs1+3RfT9uWoDJbaOnTtD4WUzRNGLEAhTipOnz84/dILqmwlnO3g1ppO0VgW4OdG lwuR2LedvQFXkqPdaem/8EzFXERaW5CVl0BchzchKaE7kfFA+1/qHv3R7howr1vw9bwF 3J1s5mpQiDRfUmzBpiGmXSh2xMymo60ruLl0rCjojX7C61Lw+F8doY7BlFUHfbghEz5G XMcYSOjF9x663J6eWl8L6w/60B8By6FK4YqClBFa9Qwphqd2rUPLgFiehxFGjQAxBI6p fKcw== 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; bh=9p5t6DEU6Z/yUDqm99Zbf98RHaYcD2lYJIKOB9Gi2hU=; b=avo0jfPVQmFBzlwhQfPOIWQxpzLfawLDNR45Lm3t5hfTKL6kXZoY+hzyrqPX2SRWFB blPYxXsXm+f4rOARIMxI3CGW8htEKlIulVvAc+7K/VluhrVfFPK4rIz/tg3KRqgCnwwT EqMFc5pYxKva75GiXeBmmeRXx8X6xVn2yxvt8HVZ1S++1NARQxFlkSoliZ/6d6A3LuUu QKY24nuJGSyzT2E5XKP8ge4P8ywYMeyDy+Kjv8ED2C5wUUxLQwjlVjJ7Bnd61h1mzl9d YAJ7u7z3rrwXd7gFf+GL+mPXMZyVT+QlUVlg8Bguxxuep13xpSc7IvDEgVSRAQEpZJyp yZUA== X-Gm-Message-State: AElRT7E2SeF2rLVVkZyTv/PKHJcCDnLZK/QUWS25vav1VoS+al8cfzeO 97MMkq/L63woiFwbnefnf6SWYvtv X-Google-Smtp-Source: AIpwx4+RfBH6pj+J+Sx/i2BGtPIcU6rZby0LilDAhH+G5Pa1CXro4RrpfHXunWdmiaC75p2vLBsFPQ== X-Received: by 10.223.181.149 with SMTP id c21mr20522392wre.233.1523020187385; Fri, 06 Apr 2018 06:09:47 -0700 (PDT) Received: from rpluim ([149.5.228.1]) by smtp.gmail.com with ESMTPSA id 14sm9660591wml.41.2018.04.06.06.09.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 06 Apr 2018 06:09:46 -0700 (PDT) From: Robert Pluim <rpluim@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default> <5AC3232D.1020107@HIDDEN> <874lksy9vy.fsf@HIDDEN> <5AC35626.2070700@HIDDEN> <877epowjq9.fsf@HIDDEN> <5AC48386.8040901@HIDDEN> <87sh8bw4xa.fsf@HIDDEN> <87fu48pr1l.fsf@HIDDEN> <83in941oj9.fsf@HIDDEN> X-Debbugs-No-Ack: yes Mail-Copies-To: never Gmane-Reply-To-List: yes Date: Fri, 06 Apr 2018 15:09:46 +0200 In-Reply-To: <83in941oj9.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 06 Apr 2018 15:56:42 +0300") Message-ID: <873708pjl1.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 31031 Cc: 31031 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Robert Pluim <rpluim@HIDDEN> >> Date: Fri, 06 Apr 2018 12:28:38 +0200 >> Cc: 31031 <at> debbugs.gnu.org >> >> I can't find anything in the elisp manual describing that the >> workareas of the two monitors are combined like this. > > AFAIK, this depends on how the monitors are configured, and perhaps > also on the window manager. The "Multiple Terminals" node in ELisp > manual is what we felt we could document, and it does hint at what you > see, if you read the text carefully. I guess you mean this bit: "The third part, SCREENNUMBER, identifies a zero-based screen number (a separate monitor) that is part of a single monitor collection on that X server." How about adding something like "Such a collection is often treated as one bigger virtual screen." ? Robert
bug-gnu-emacs@HIDDEN:bug#31031; Package emacs.
Full text available.Received: (at 31031) by debbugs.gnu.org; 6 Apr 2018 12:56:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 06 08:56:56 2018 Received: from localhost ([127.0.0.1]:39931 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1f4QvI-0007A6-7n for submit <at> debbugs.gnu.org; Fri, 06 Apr 2018 08:56:56 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49900) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1f4QvG-00079t-FK for 31031 <at> debbugs.gnu.org; Fri, 06 Apr 2018 08:56:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1f4Qv8-0000bV-BM for 31031 <at> debbugs.gnu.org; Fri, 06 Apr 2018 08:56:49 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48150) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1f4Qv8-0000bH-6h; Fri, 06 Apr 2018 08:56:46 -0400 Received: from [176.228.60.248] (port=4902 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1f4Qv7-0005vz-IA; Fri, 06 Apr 2018 08:56:45 -0400 Date: Fri, 06 Apr 2018 15:56:42 +0300 Message-Id: <83in941oj9.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Robert Pluim <rpluim@HIDDEN> In-reply-to: <87fu48pr1l.fsf@HIDDEN> (message from Robert Pluim on Fri, 06 Apr 2018 12:28:38 +0200) Subject: Re: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default> <5AC3232D.1020107@HIDDEN> <874lksy9vy.fsf@HIDDEN> <5AC35626.2070700@HIDDEN> <877epowjq9.fsf@HIDDEN> <5AC48386.8040901@HIDDEN> <87sh8bw4xa.fsf@HIDDEN> <87fu48pr1l.fsf@HIDDEN> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 31031 Cc: rudalics@HIDDEN, 31031 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Reply-To: Eli Zaretskii <eliz@HIDDEN> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -6.0 (------) > From: Robert Pluim <rpluim@HIDDEN> > Date: Fri, 06 Apr 2018 12:28:38 +0200 > Cc: 31031 <at> debbugs.gnu.org > > I can't find anything in the elisp manual describing that the > workareas of the two monitors are combined like this. AFAIK, this depends on how the monitors are configured, and perhaps also on the window manager. The "Multiple Terminals" node in ELisp manual is what we felt we could document, and it does hint at what you see, if you read the text carefully.
bug-gnu-emacs@HIDDEN:bug#31031; Package emacs.
Full text available.Received: (at 31031) by debbugs.gnu.org; 6 Apr 2018 10:28:50 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 06 06:28:50 2018 Received: from localhost ([127.0.0.1]:39884 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1f4Oby-0001rs-7J for submit <at> debbugs.gnu.org; Fri, 06 Apr 2018 06:28:50 -0400 Received: from mail-wr0-f180.google.com ([209.85.128.180]:42933) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <rpluim@HIDDEN>) id 1f4Obw-0001rf-6S for 31031 <at> debbugs.gnu.org; Fri, 06 Apr 2018 06:28:48 -0400 Received: by mail-wr0-f180.google.com with SMTP id s18so1203098wrg.9 for <31031 <at> debbugs.gnu.org>; Fri, 06 Apr 2018 03:28:48 -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=4zzIj/5rts1nYLkwYTFQPMM7XOWpYaFMJiPb5qalKiM=; b=M+CFKPtNBvAIR0aQiOQVentr1CjCB05VkNjjSgB++TSydyE7BB2eXhtHDv9EJ3fV61 t5QAyD5/myLBR3cFNphinkFb0R2Zg3/uC0FmO1R7m2xTXIKEwaATTBgtOS4cs84VuAWl Q1KV9qyYNc1D7WstGpsjkPsobWx1RZnpDvO0MV6goAxD90giSU2t/Pl8Dg4UcCNpAUPu CaWM3YS0WmjClIqL+iuU5SwVCyXoahukPuo8JXoZ7HLXNkAhs1XGzcP+n5yHKrCQP3gq 59nkvYeZvwPFr3lHNtS0U4Jhj7NidBLohSTRT5aYkeiYK5GX7kZn0ZRKFVKQyu4wIR2C AvkQ== 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=4zzIj/5rts1nYLkwYTFQPMM7XOWpYaFMJiPb5qalKiM=; b=GhcCh2M6CMGWVvQwW1MeqjFi6flj5uPBt+Zd/Z0bx6KIoRSTe85o6/MxfzL5Yr5d19 3DvbvhxXBZNFfWMTb/DrQwvlLVLbxjUq0SVc0HDUyrznmhBdd3hpkA/3LxPl68nvMnEN yC0RPaZ7TLT6IujIHT9ev9pAPcaXjbhm0aEJZjv2/W83g6/Hk6pg/PtEEtMVHUb/EkdI Gk1b8LBc6YBM4lodle6P9DYyw38jljT4iZOdUM4cZjNNIohaBkt+8FtbmUFD/wu/hkgk sBYV+djDCwq365zU7q2QHM/Y1gbXMnzLgXaHpIyA02PKA62mFukv5eDi70yn9//9WjB5 mn0g== X-Gm-Message-State: AElRT7GDBJ3eumkoGdyZ48BjTRINxQdwcYM6gZYS8rnANDnTCXyMEqgb G8KX0tsq3zLZfXFQRpGx4HrnUeKV X-Google-Smtp-Source: AIpwx49rJcD29SGaescmmHxOh7oFeBOesBWpZhN6Hjcgq9uAC3oDIrAJETLkBFd+FFZ2Jx5i2Hs67w== X-Received: by 10.223.219.16 with SMTP id s16mr20796364wri.123.1523010521981; Fri, 06 Apr 2018 03:28:41 -0700 (PDT) Received: from rpluim ([149.5.228.1]) by smtp.gmail.com with ESMTPSA id r75sm5919641wmf.34.2018.04.06.03.28.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 06 Apr 2018 03:28:41 -0700 (PDT) From: Robert Pluim <rpluim@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default> <5AC3232D.1020107@HIDDEN> <874lksy9vy.fsf@HIDDEN> <5AC35626.2070700@HIDDEN> <877epowjq9.fsf@HIDDEN> <5AC48386.8040901@HIDDEN> <87sh8bw4xa.fsf@HIDDEN> X-Debbugs-No-Ack: yes Mail-Copies-To: never Gmane-Reply-To-List: yes Date: Fri, 06 Apr 2018 12:28:38 +0200 In-Reply-To: <87sh8bw4xa.fsf@HIDDEN> (Robert Pluim's message of "Wed, 04 Apr 2018 14:07:45 +0200") Message-ID: <87fu48pr1l.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 31031 Cc: 31031 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) Robert Pluim <rpluim@HIDDEN> writes: >>> D'oh. Of course, top is the right parameter to use. With that the >>> frame switches monitor between top and bottom, so that would imply >>> that the same switching should happen for "left". I=CA=BCm undecided so= far >>> as to which I think is the "correct" behaviour. >> >> I'm not sure I understand. Do you mean that when you change the value >> of 'left' the frame always stays within the left monitor while when >> you change 'top' the frame moves from the upper to the lower monitor >> and back? That would be queer. > > I=CA=BCll have to retest this one, I may have missed a case. Two monitors, one above the other, frame on bottom one. (modify-frame-parameters nil '((top . 0.0))) =3D> frame moves to top monitor (modify-frame-parameters nil '((top . 1.0))) =3D> frame moves tobottom monitor Repeating those commands cycles between top and bottom monitor. (and they're not flush to the edges, but this is with GDK scaling going on, so I=CA=BCm not too surprised by that). Two monitors, one next to the other, frame on right one. (modify-frame-parameters nil '((left . 0.0))) =3D> frame moves to left monitor (modify-frame-parameters nil '((left . 1.0))) =3D> frame moves to right monitor and again this cycles between the monitors. So whatever I tested before, it wasn't this, and the behaviour is consistent between "left" and "top". I can't find anything in the elisp manual describing that the workareas of the two monitors are combined like this. Should such information go in (elisp)Multiple Terminals, or (emacs)Multiple Displays? Or both? Robert
bug-gnu-emacs@HIDDEN:bug#31031; Package emacs.
Full text available.
Received: (at 31031) by debbugs.gnu.org; 5 Apr 2018 14:21:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 05 10:21:15 2018
Received: from localhost ([127.0.0.1]:39545 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1f45lL-0003yb-9d
for submit <at> debbugs.gnu.org; Thu, 05 Apr 2018 10:21:15 -0400
Received: from mail-wm0-f44.google.com ([74.125.82.44]:39041)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rpluim@HIDDEN>) id 1f45lK-0003yO-3j
for 31031 <at> debbugs.gnu.org; Thu, 05 Apr 2018 10:21:14 -0400
Received: by mail-wm0-f44.google.com with SMTP id f125so7600665wme.4
for <31031 <at> debbugs.gnu.org>; Thu, 05 Apr 2018 07:21:14 -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=2f19jsbr3lhfxnm+ZPFfdI+2hrQDWlf8tZut+bAKXFw=;
b=iBUMF1rHRyJz12rn40gdu6xZOfn7BTS77cca/8pOMyZXf4tmd9TcuwwV5AySli3rew
2ZL8aGeo2BYmZmNo2gRlgWVBjhYq0MpjixcZ3l+zZdCINAGoCf5XKWFCekXyADx8ndwV
z5gEW90m64o0PPcX1UC0/CsAUDcCZJW5kCxnFbG/eg/kqowPbQfQ8oz4NETawZgmWuOH
5BICOUfxMa/i08FX0i7/icdBcduqZQkV7ROu1EVhJHw0q2BYkGzO3XUQFKYdJUeulsfX
bPHIrLQMzybGkQOPQ8dW5pFIVdH/OfcZer9RVoDPGUERxPTBLA26DywNrKjZ7srrAOaR
iZfA==
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=2f19jsbr3lhfxnm+ZPFfdI+2hrQDWlf8tZut+bAKXFw=;
b=pCzvQo+7sySONuLNwP6HCCgOebon/r6waQ9+YWtq0TdLIJc3YlXnp1YJIEAsjwOrJx
5vXgD94U9iKqq3XCNbxEkXbjWJyapYdEVGf06r7pRM+quVZ/rs7RHd/XM4/Hyj7cKXMY
pxaK8TvoeGQgtTt9ts3+JB29wmCgEV0B905Y6VEi904ffC0hNraf2033vMFbFcAA7M09
1naydvOdkiqo4BeCkU3Rk5FUZo/gpbT4g9YVqKEj9wsxsqCLf2TV8AFCZIU8AhSrj4wX
Qi9oeAPkBox80m0mv06+nsCgGY4tK8qrxdJ9Vyj8IM2qj17ULgBagtHToVsqW3RLoacR
BPiw==
X-Gm-Message-State: AElRT7GFuPlJh+jptXXiOi+IfHZVynq47D6nLvCpyPrtOatwTLzQg2aw
yukLEK4KW9c2eumcrMRlrDoK9VrQ
X-Google-Smtp-Source: AIpwx4+3akU9B+eaL446buUZXRQHIfMoA42B+xW/JMtMQvqLLA5Va+iJXE4GmoGBr5refmN4eqCPww==
X-Received: by 10.28.226.138 with SMTP id z132mr10010288wmg.101.1522938063194;
Thu, 05 Apr 2018 07:21:03 -0700 (PDT)
Received: from rpluim ([149.5.228.1])
by smtp.gmail.com with ESMTPSA id m83sm3579008wma.17.2018.04.05.07.21.01
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Thu, 05 Apr 2018 07:21:02 -0700 (PDT)
From: Robert Pluim <rpluim@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#31031: 27.0;
(elisp) `Position Parameters', floating-point values
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
<5AC3232D.1020107@HIDDEN> <874lksy9vy.fsf@HIDDEN>
<5AC35626.2070700@HIDDEN> <877epowjq9.fsf@HIDDEN>
<5AC48386.8040901@HIDDEN> <87sh8bw4xa.fsf@HIDDEN>
<5AC5C981.30700@HIDDEN>
X-Debbugs-No-Ack: yes
Mail-Copies-To: never
Gmane-Reply-To-List: yes
Date: Thu, 05 Apr 2018 16:21:01 +0200
In-Reply-To: <5AC5C981.30700@HIDDEN> (martin rudalics's message of "Thu, 05
Apr 2018 09:00:17 +0200")
Message-ID: <87k1tl68fm.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 31031
Cc: 31031 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
martin rudalics <rudalics@HIDDEN> writes:
>>> Why did you ask for 2400 and not for 2360? If the position value is
>>> too large the window manager might try to fit the frame onto the
>>> screen. OTOH "correcting" this to 2380 means there are 20 pixels (the
>>> full right external border) missing on the right if not I am missing
>>> something.
>>
>> I asked for 2400 because if I ask for 2360 the frame is not flush
>> right.
>
> Funny. There must be some strange calculations going on behind the
> scenes. Is there some consistency in the sense that your window
> manager never shows the full external border when you want to place it
> at some position on the left or top of the screen?
>
No, I haven't noticed any artifacts like that.
>> I think we=CA=BCre getting a -20 offset back from X somewhere when query=
ing
>> the frame size/position.
>
> And the -20 doesn't correspond to what you see on screen because the
> external border is not fully visible. Right?
>
What there is of the external border is fully visible, since the frame
is not flush right (except when I ask for 2400, that is).
>> If I look at this hunk in
>> x_real_pos_and_offsets:
>>
>> #ifdef USE_XCB
>> geom =3D xcb_get_geometry_reply (xcb_conn, geom_cookie, NULL);
>> if (geom)
>> {
>> real_x =3D geom->x;
>>
>> then real_x there is -20 when the frame is flush left. Should we be
>> using gdk/gtk calls to get the window geometry?
>
> By all means try to check whether these get you better results. But
> before that you might want to try disabling USE_XCB. I recall an
> earlier discussion where I strongly doubted the correctness of values
> returned by x_real_pos_and_offsets.
Some of them do seem bogus. disabling USE_XCB has no effect on the
values (I have a vague memory of Xlib using XCB behind the scenes now,
so that=CA=BCs not too surprising)
I=CA=BCll see if I can change the guts of x_real_pos_and_offsets to use
GDK directly, that might fix things.
Robert
bug-gnu-emacs@HIDDEN:bug#31031; Package emacs.
Full text available.
Received: (at 31031) by debbugs.gnu.org; 5 Apr 2018 07:00:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 05 03:00:36 2018
Received: from localhost ([127.0.0.1]:38871 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1f3ysu-0008NW-5g
for submit <at> debbugs.gnu.org; Thu, 05 Apr 2018 03:00:36 -0400
Received: from mout.gmx.net ([212.227.15.18]:37281)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1f3ysr-0008NG-Lw
for 31031 <at> debbugs.gnu.org; Thu, 05 Apr 2018 03:00:34 -0400
Received: from [192.168.1.100] ([212.95.5.100]) by mail.gmx.com (mrgmx003
[212.227.17.190]) with ESMTPSA (Nemesis) id 0MVMgI-1f1DDo3zVW-00YjTZ; Thu, 05
Apr 2018 09:00:27 +0200
Message-ID: <5AC5C981.30700@HIDDEN>
Date: Thu, 05 Apr 2018 09:00:17 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: Robert Pluim <rpluim@HIDDEN>
Subject: Re: bug#31031: 27.0; (elisp) `Position Parameters', floating-point
values
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default> <5AC3232D.1020107@HIDDEN>
<874lksy9vy.fsf@HIDDEN> <5AC35626.2070700@HIDDEN>
<877epowjq9.fsf@HIDDEN> <5AC48386.8040901@HIDDEN>
<87sh8bw4xa.fsf@HIDDEN>
In-Reply-To: <87sh8bw4xa.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:3c31+nHkWIgEVBu3DZZBQP1dpCJN985n6NVNlLozMsjIdWP+B/N
JRo9GmxS1SXRiSfbLKny12IAtSujYp78gLX7zk9XGnsJohp3McY2NWxpQ7WIrWVzQp/8+0s
KNydzJy3by3f8NiHad9mRBA9htQVBQhHc5bewuw8GlqqBJrTESCKCV4yCIMCOPfAidRkJOb
AXiTaskQewRRK0Zn9lmLA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:2ePNC0bDPXo=:ufwVDDMDBgb2vgBF1ruG9C
hUCspU1G6MpdeqX3T84xqLHIcuBlRE60kMJO+G4/vbWgKSU+/ZQDXFtL0Z0chc5ru5iLR0Kfc
ptlz/6OCHvkPXLuK8aWFUIbzV1QLNUTIxCJ3/fwjkNNBh6lCihoYDfi2IW5VBLUYpxq9u+hS6
arbmT3qKsio9cKE26qDbFd05Qn6JnbAloX8hY/fGurchWszK6Y+rFhcLhpcnoy3Z5ZC7nV0lF
0GNvO+b0YTMaxQrSLBLn2+tSHTeH8iTWwz9rwD9Uv7rEDFJ9ZZVoa6xHHKcjAykIL6eVxjSW/
uLaIALkM05C5lnE0EoyrTQmweHRgN9DB5yA+YjXSZQCewjCuTAmX57T63HNxbv7b94og4KTNY
pxgeBYFVw9IDF6ZH81SpNyChv/LBnl9h6KUOjvjAsP7hL3/0dWU9QjvmKTpHxg3xAK8LfAOhu
AHgrWSN55CwWpi8HKhQOg7rspyHQJAy/2O1ASv6uUVQdmbKL0CIn/RepA6pS3cck5L4ZDpJvg
eCHi8TgZ4awbVcAmiuW5MjB0QdcY68Hmto6SmqIWHX9U2FILMlvAkQcstYfIiS2kFskUNmAhU
wbXYLKSmfwdsA1Q0s2Fh2Nb4cDrg8i7krOsewTx8jyMjf+8QfhrIcQQNSGh3uTp8KtlgMFApr
/i4Yfys3GyvLkAKpBEgqaT7mFDbi/QKUtgWooW/1QB0V8EM27uE57pRgvxVfIfUFw19sllzbX
nkagkhxol55LSWU20T0uMp1DilLxLXNxWRyljoTfGw8XlAwL0LKQh5ZbFgHZhn3TF+gU0tTW6
08ldVrls46uW/39lmGx12AZncSM1yNJk+VZW8jfy+PFQlHuHWg=
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 31031
Cc: 31031 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)
>> Why did you ask for 2400 and not for 2360? If the position value is
>> too large the window manager might try to fit the frame onto the
>> screen. OTOH "correcting" this to 2380 means there are 20 pixels (th=
e
>> full right external border) missing on the right if not I am missing
>> something.
>
> I asked for 2400 because if I ask for 2360 the frame is not flush
> right.
Funny. There must be some strange calculations going on behind the
scenes. Is there some consistency in the sense that your window
manager never shows the full external border when you want to place it
at some position on the left or top of the screen?
> I think we=CA=BCre getting a -20 offset back from X somewhere when que=
rying
> the frame size/position.
And the -20 doesn't correspond to what you see on screen because the
external border is not fully visible. Right?
> If I look at this hunk in
> x_real_pos_and_offsets:
>
> #ifdef USE_XCB
> geom =3D xcb_get_geometry_reply (xcb_conn, geom_cookie, NULL);
> if (geom)
> {
> real_x =3D geom->x;
>
> then real_x there is -20 when the frame is flush left. Should we be
> using gdk/gtk calls to get the window geometry?
By all means try to check whether these get you better results. But
before that you might want to try disabling USE_XCB. I recall an
earlier discussion where I strongly doubted the correctness of values
returned by x_real_pos_and_offsets.
martin
bug-gnu-emacs@HIDDEN:bug#31031; Package emacs.
Full text available.
Received: (at 31031) by debbugs.gnu.org; 4 Apr 2018 12:07:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 04 08:07:55 2018
Received: from localhost ([127.0.0.1]:37758 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1f3hCl-0007X8-0x
for submit <at> debbugs.gnu.org; Wed, 04 Apr 2018 08:07:55 -0400
Received: from mail-wm0-f53.google.com ([74.125.82.53]:37323)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rpluim@HIDDEN>) id 1f3hCj-0007Ww-VJ
for 31031 <at> debbugs.gnu.org; Wed, 04 Apr 2018 08:07:54 -0400
Received: by mail-wm0-f53.google.com with SMTP id r131so41808752wmb.2
for <31031 <at> debbugs.gnu.org>; Wed, 04 Apr 2018 05:07:53 -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:message-id:mime-version:content-transfer-encoding;
bh=rUfaZXjVcobo9lScNESuGkfZTvNpuqTtGvrdZSFo5kE=;
b=Vc1mR7I+RwojgQ+PNLHuLQ+vZtArdurKMT11JOeNwfnsCQblfKawsacJd5JImujirl
4tDOq9RKbJhO2t/aaznDqF8W8n7wHY4RnLfZU0z+aV5YM5kmrxsyymCGm3tKqf+CVNvX
r0UdQVdDlXP6V2/IpJHRFMv7AqPfs/8HKpSZJs1GpxnnArVYyL9Zvn93BSx55n6Ijc/u
++NBpTmJnBPC+eQDqalUmtV/nJvZlK9/yDtZhYAw5tWmL8ToIn+9ljXTyujPU3l9MtYH
mqPrgNgX7Ob6m6zu4uMgPRclQ281W/dYd5+x0Mgr94lcG43X9sgokow2ojP0b1v6WrfR
kO8Q==
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:message-id:mime-version
:content-transfer-encoding;
bh=rUfaZXjVcobo9lScNESuGkfZTvNpuqTtGvrdZSFo5kE=;
b=FWUqYR0lty7+qVDZxJEhNVjSouL20yiVkhR67xzbRwV/iCRP/ve+VVuneK0iqtFpxq
i5L+nDbxkyfeqmzzqhmfDlDd+RXHMWTAL3KcxtzyvxnYooJqY6jWPYfnlCpljbwcsYxB
JYrTMTdr/oaxW2307pHljLPA5hslVlS/LnYXm8vWw4wLG4PjcFLttkJg6Egoi+0Ru6NX
wScWirfMpeAY8G1qKd4c09c8ixJFOvIL+sT6mo1QyjTI5zagpP0kO9TtgEs2JSgHM9H8
fECt7Dp65CgGnH0TTGBTX5iTjRlS1+4nUu3j34F9Pf6OEEmT0/nnRDcYDMrJHUBW9gq7
wGHA==
X-Gm-Message-State: ALQs6tA3f5dLMQQumLu2sOVSKZ9YoORSrEm7ic/4kiKGYRJkEuwZWXow
jOK4SNF8fjweCQXFx4hRl3vIUyC2UWA=
X-Google-Smtp-Source: AIpwx4/b7g/wqJZBu2ptTUexqLVzyEgiC7MM+jNLnRFiviRYikH+EBsYGB7CFLWVzUD7Ucf116rJkw==
X-Received: by 10.28.190.3 with SMTP id o3mr167715wmf.57.1522843667661;
Wed, 04 Apr 2018 05:07:47 -0700 (PDT)
Received: from rpluim (vav06-1-78-207-202-134.fbx.proxad.net. [78.207.202.134])
by smtp.gmail.com with ESMTPSA id t8sm3971802wmc.20.2018.04.04.05.07.46
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Wed, 04 Apr 2018 05:07:46 -0700 (PDT)
From: Robert Pluim <rpluim@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#31031: 27.0;
(elisp) `Position Parameters', floating-point values
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
<5AC3232D.1020107@HIDDEN> <874lksy9vy.fsf@HIDDEN>
<5AC35626.2070700@HIDDEN> <877epowjq9.fsf@HIDDEN>
<5AC48386.8040901@HIDDEN>
X-Debbugs-No-Ack: yes
Mail-Copies-To: never
Gmane-Reply-To-List: yes
Date: Wed, 04 Apr 2018 14:07:45 +0200
Message-ID: <87sh8bw4xa.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 31031
Cc: 31031 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
martin rudalics <rudalics@HIDDEN> writes:
>>> Can you try fixing that in some consistent manner? You can find the
>>> corresponding code in x_calc_absolute_position in xterm.c. BTW, does
>>> it work right when you use the "(- POS)" specification?
>>
>> (modify-frame-parameters nil '((user-position . t) (left . (- 0))))
>>
>> gives the same offset effect as
>>
>> (modify-frame-parameters nil '((user-position . t) (left . 1.0)))
>
> So we should try fixing (or documenting) the misbehavior of the (- n)
> notation first.
As noted elsewhere, I think this is a window manager issue. I=CA=BCd expect=
those
two calls to give the same effect, which is what I see.
>> D'oh. Of course, top is the right parameter to use. With that the
>> frame switches monitor between top and bottom, so that would imply
>> that the same switching should happen for "left". I=CA=BCm undecided so =
far
>> as to which I think is the "correct" behaviour.
>
> I'm not sure I understand. Do you mean that when you change the value
> of 'left' the frame always stays within the left monitor while when
> you change 'top' the frame moves from the upper to the lower monitor
> and back? That would be queer.
I=CA=BCll have to retest this one, I may have missed a case.
>>>> [1] Not completely to the right, but that=CA=BCs a different issue
>>>
>>> Probably a problem with calculating the decorations. Does
>>> (frame-geometry) return "reasonable" values for your frame?
>>
>> (display-monitor-attributes-list)
>> (((name . "XWAYLAND0") (geometry 0 540 3840 2160) (workarea 0 540 3840
>> 2094) (mm-size 350 190) (frames #<frame *unsent wide reply to martin
>> rudalics* 0x3d5ce80> #<frame *info* 0x89f6ff0> #<frame *scratch* 0x87=
f1a00>)
>> (source . "Gdk")))
>>
>> (modify-frame-parameters nil '((user-position . t) (left . 1.0)))
>>
>> (frame-geometry)
>> ((outer-position 2340 . 1730) (outer-size 1480 . 824)
>
> Hmm ... 2340 + 1480 gives 3820 which is obviously 20 pixels to the
> left of 3840. This clearly went wrong. Did we _ask_ for 2340 or
> 2360?
That I don=CA=BCt know, I=CA=BCll find out...
>> (external-border-size 20 . 20) (outer-border-width . 0)
>> (title-bar-size 0 . 70) (menu-bar-external . t) (menu-bar-size 0 . 0)
>> (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0
>> . 0) (internal-border-width . 0))
>>
>> (+ 2340 1480) =3D> 3820, + external-border-size? In any case, visually
>> the frame is not flush right.
>
> Do we anywhere add only one 'external-border-size' instead of two?
>
>> If I correct the visual aspect:
>>
>> (modify-frame-parameters nil '((left . (+ 2400))))
>>
>> (frame-geometry)
>> ((outer-position 2380 . 1586) (outer-size 1480 . 824)
>> (external-border-size 20 . 20) (outer-border-width . 0)
>> (title-bar-size 0 . 70) (menu-bar-external . t) (menu-bar-size 0 . 0)
>> (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0
>> . 0) (internal-border-width . 0))
>>
>> which to me says there=CA=BCs a (-20) error for the outer-position at
>> least.
>
> Why did you ask for 2400 and not for 2360? If the position value is
> too large the window manager might try to fit the frame onto the
> screen. OTOH "correcting" this to 2380 means there are 20 pixels (the
> full right external border) missing on the right if not I am missing
> something.
I asked for 2400 because if I ask for 2360 the frame is not flush
right.
> BTW is this on a high resolution display? Would/should we scale
> external borders on such a display too?
Yes, it=CA=BCs high resolution, but 20 pixels seems like more than can be
accounted for by scaling.
> martin
>
>> I=CA=BCll take a look at x_calc_absolute_position.
I think we=CA=BCre getting a -20 offset back from X somewhere when querying
the frame size/position. If I look at this hunk in
x_real_pos_and_offsets:
#ifdef USE_XCB
geom =3D xcb_get_geometry_reply (xcb_conn, geom_cookie, NULL);
if (geom)
{
real_x =3D geom->x;
then real_x there is -20 when the frame is flush left. Should we be
using gdk/gtk calls to get the window geometry?
Robert
bug-gnu-emacs@HIDDEN:bug#31031; Package emacs.
Full text available.Received: (at 31031) by debbugs.gnu.org; 4 Apr 2018 07:51:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 04 03:51:28 2018 Received: from localhost ([127.0.0.1]:37573 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1f3dCa-000812-A4 for submit <at> debbugs.gnu.org; Wed, 04 Apr 2018 03:51:28 -0400 Received: from mout.gmx.net ([212.227.17.21]:44381) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <rudalics@HIDDEN>) id 1f3dCX-00080m-F7 for 31031 <at> debbugs.gnu.org; Wed, 04 Apr 2018 03:51:25 -0400 Received: from [192.168.1.100] ([212.95.5.201]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M6SE3-1eKDDL0GJ1-00yTg4; Wed, 04 Apr 2018 09:51:16 +0200 Message-ID: <5AC483EA.8020603@HIDDEN> Date: Wed, 04 Apr 2018 09:51:06 +0200 From: martin rudalics <rudalics@HIDDEN> MIME-Version: 1.0 To: Drew Adams <drew.adams@HIDDEN>, 31031 <at> debbugs.gnu.org Subject: Re: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default> <5AC3232D.1020107@HIDDEN> <0f7742b2-9e8e-47ed-a6c0-195e1985b5e0@default> In-Reply-To: <0f7742b2-9e8e-47ed-a6c0-195e1985b5e0@default> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:R4YwqhFQqfR3Gn8q9/hJEpksl7Cxb+ju3wXY/7LdNzCBDiy9eG/ hlujxTUjpr61CRFW2Zu1t+n5kszHZLvPLXy4s3EYfUaqOjKDQTSQ8RzgrXA/MRbZFNomsu7 rZaxMf/eY+7UdV2J+Lk7Wh2dV9TiJUhVdTmLBLtluDDimC9eu8wXiJvbY9Ua2qsXHM0QZIm SJYZdwtBNH0VZngyGCgeA== X-UI-Out-Filterresults: notjunk:1;V01:K0:/slOcyRHXw8=:GdTu7KYH437cbzh/mJ0fet R3oM7XNjUEVb9OoNwoDVJLoyGU5KfISpoOauawgU+V4aHwYYuQoAgm67O/DUanfPRwnJzqzhC XyqiwuJaEF/ZnYW3eUo+ha2bcwgacqZoNjFkiLYQOXP5AE1sY+ZdHvKAuVNRWynOaDxWpPPKY cy8Hev0rxLgPVqRfY++qyzGpxK5W0SRVoBIS2RK1Q+5YaVZL1pKNO0HRgWLDw17jVgw49r63D 6pk/auR+xcsRYIFl8XoC0rI8kUi3FQwet0YWbFt7uQXHMhXgSV8bPLKt+DFGxap68oBuv/2iR JFc+s57HCX77toeLIqSuJgYblM6L/Di8ZIGXVl0BMrWvPpwIJdd72VUUM0KrpXeo+3C4r+Z6z ESRYCerCoCysTi00F0mHd2RlMbQbW7QuKWXM24JN7ZWmEECUY5YciszZo/BDqTFl9QA5Aaed6 FLFzssS2Xwu3qlK3ZeubYKsEh8Pzj4ruf6GTyZKrCqDq6h9ZMLcr/PeS7evugEhWJfxelYTrY JFDFhnqA2WS7IceqnDj516YvhMGO0hEt9+tEhns9VUAmcOr4pkpg8CHu9MNyDkEnm2um7nFaG ASI9W6rQVFfn/tQs12EBaeW28tXkY4GorhiET92O0UBGoMTkHa/u8cO4fvTg77Ie00zMzCGzq 8bSXxdod1uK9wAr8CmBKkg4DSLwdxaCEXTGsHwPiOJKsCzo7tnkX+r+1cG2C0XACvYfxy5s5a QPsXkiBmPhM6C0Zah3bmXqsz2LdRAWFIWUF6VjagJgxX11rwjAcnUuMbezVcDaS8gquoygy0x L9VDj5zjA55V5syL61Zl3O1xJSiqzN0EwsQQHQ9VTU1mDCj96ZqR6ggiaXcis08AZbAyu2B X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 31031 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.7 (/) > Yes. But I'm not sure why you mention that here. > What might I be missing? Because the desktop restore algorithm cannot restore the originally intended positioning, namely flushing the frame to the right whatever the size of the display is. > I have limited access to multiple monitors, myself. The > manual says that the monitor that dominates a frame is > "the monitor that contains the largest part of the window" > ((elisp) `Creating Frames'). And: > > A frame is =E2=80=9Cdominated=E2=80=9D by a physical monitor when e= ither the > largest area of the frame resides in that monitor, or (if the frame= > does not intersect any physical monitors) that monitor is the > closest to the frame. Every (non-tooltip) frame (whether visible > or not) in a graphical display is dominated by exactly one physical= > monitor at a time, though the frame can span multiple (or no) > physical monitors. -- (elisp) `Multiple Terminals' I read that text but since I have no experience with multiple monitors I have no idea of its practical implications. > With a single monitor it does indeed do what you say, and > what one would expect. When I tried with left and right > monitors I saw what I described (I don't have access to > multiple monitors today, but that is definitely what I > saw). Robert's experience seems to confirm yours. > I'm guessing now that `modify-frame-parameters' pays no > attention to the dominating monitor and expects its > position inputs to always use screen coordinates, i.e., > relative to all monitors combined, not relative to the > dominating monitor. Maybe. But then your problem should also show up when you try to position the left or top position of your frame by giving the offset of the left or top edge of the dominating monitor and that dominating monitor is not the left-/top-most one. Right? > If so then the doc about floating-point perhaps just needs > to be modified to not talk about "display" (which can be, > at least in some other places, the dominating monitor), > and instead talk about "screen" (which seems to always > refer to the space of all monitors taken together. Maybe, again. Is that display-screen dichotomy something we already document somewhere? If not we should fix the nomenclature first and I have no good idea how to do that (in Emacs sources you will still find places where the terms "frame" and "screen" are considered equivalents). So if there is some reasonable common understanding of this matter, we should specify what the terms "screen", "display", "monitor", "terminal" and "keyboard" stand for and how they relate to each other. > However, this part of the doc this report is about is > unclear in this regard: > > If you want to be sure the position you specify is not > ^^^^^^^^^^ > ignored, specify a non-=E2=80=98nil=E2=80=99 value for the =E2=80=98= user-position=E2=80=99 > parameter > > That suggests that here, at least, the parameter makes sure > that you get what you ask for. Ideally, yes. But all too often the window manager might want to correct that position to assure, for example, that a frame stays completely on-screen. > 1. Corrected wrt mention of "display", if it is in fact > the whole screen that is meant (e.g., in the case of > multiple monitors. I have to leave this part to someone who understands the implications of the use of multiple monitors. > 2. The text is pretty dense. This, in particular: > > A floating-point value ... specifies the > left edge=E2=80=99s offset via the =E2=80=9Cleft position ratio=E2= =80=9D of the > frame=E2=80=94the ratio of the left edge of its outer frame to th= e > width of the frame=E2=80=99s workarea (*note Multiple Terminals::= ) or > its parent=E2=80=99s native frame (*note Child Frames::) minus th= e > width of the outer frame. > > Maybe split that sentence into at least two sentences, but > probably three or four (or five). > > Maybe say "length of the left edge" instead of "left edge". These proposals are valuable. > What's the "outer frame" in the case of a non-child frame? The "outer frame" is described in section 29.3.1 Frame Layout. > Maybe say "screen area" instead of "frame's workarea"? The > latter is undefined, AFAIK, and can suggest the dominating > monitor and not the total screen area of all monitors. We want to position a frame within its workarea to avoid that the frame overlaps the windowing system's taskbar etc. > Maybe add "to" before "its parent's...", to make it more > clear that it's the ratio of the left-edge length to ___ > or ___ (minus...), not the ratio of the left-edge length > or ___ to ___ (minus...). But splitting the sentence up > into constituent pieces would help most. > > Maybe each term used should be defined here, rather than > sending readers elsewhere. If a reader has to go study > 4 other dense nodes to understand the terms used here in > a super-dense spec, then there are too many obstacles to > understanding. I understand your concerns but as you can see the "floating-point value" entry is already much larger than the remaining ones and since (if I understand Robert correctly) the "(- POS)" entry faces the same problems wrt multiple monitors, we have to sort out this more general problem anyway. In either case, reading the Frame Geometry section will remain a prerequsite for understanding some of the rest of the Frames chapter in the Elisp manual. martin
bug-gnu-emacs@HIDDEN:bug#31031; Package emacs.
Full text available.Received: (at 31031) by debbugs.gnu.org; 4 Apr 2018 07:49:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 04 03:49:44 2018 Received: from localhost ([127.0.0.1]:37565 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1f3dAu-0007y0-L7 for submit <at> debbugs.gnu.org; Wed, 04 Apr 2018 03:49:44 -0400 Received: from mout.gmx.net ([212.227.17.21]:54093) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <rudalics@HIDDEN>) id 1f3dAs-0007xm-9q for 31031 <at> debbugs.gnu.org; Wed, 04 Apr 2018 03:49:42 -0400 Received: from [192.168.1.100] ([212.95.5.201]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MZgdm-1enlHF3BLa-00LY9P; Wed, 04 Apr 2018 09:49:35 +0200 Message-ID: <5AC48386.8040901@HIDDEN> Date: Wed, 04 Apr 2018 09:49:26 +0200 From: martin rudalics <rudalics@HIDDEN> MIME-Version: 1.0 To: Robert Pluim <rpluim@HIDDEN> Subject: Re: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default> <5AC3232D.1020107@HIDDEN> <874lksy9vy.fsf@HIDDEN> <5AC35626.2070700@HIDDEN> <877epowjq9.fsf@HIDDEN> In-Reply-To: <877epowjq9.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:QhyhRFIYVscxZlWJL2ZNLMG6QQzvg91yYue5gLCBU/LkD60pXao QfnyCTOxctgPYLugWj9XP8lxIRxKked30u0Usq7FVb7F/fJ9cfguRXW+6Su/RIMGpYQvfcW WZe8cX664KbxV4rAafk09fbuMJ4zCkog7mvmhLqc48wjtoogEaOs2tu2qO6TXAD+tCADVkj KflhpgP/Z4YgY9CseZhcw== X-UI-Out-Filterresults: notjunk:1;V01:K0:FYawkw2HHDk=:DWuuRI0ZxAoznWXG6jeaur d5Ay4tQjldkNYtS8Ftd/SqVt0f73GcM0FopxItEt088K4UcPLAJsGzvRxfTXgZCTCzO/WnJ17 HoKWE+31y4BrgMNpoj1wnelPen483cFGYyc0tkTA4CTugC36G2a+ia50jBgW8UH/AMynFM3lO v+QelORXY2QV8klkAmfKeWp5qBhujMv8EeyohQDA73IHZFWiyFl5yCwFEW5/S2wrElXX7mmUM Ax7dVNDUB6/Zb35Xd340kjxbgEqrIl3AthwmjZfILpf+joSXfogdRFyEc2KJivYiOo8lD26sU vfvg6GJNi4VZBFadjGDJHPPLIArbm+aCZd3961NuWbPPYgUvstiqOl17UzFB+V7gifnf+JI2L 0bDJSarBiNzsemJ8aZ+v3+qWfpZJE8bJAGZj6prn2W8c3XcC7b6eyQ8gVYL8zL55QIbOzBrme 1EWNpVFAUfiH+q1i+oU8i9OEbCnp0kyEsCv6WR22yCb8jLbwYe2Uw6fmPdlZ7nHkUbdKJIkzk kl4WkKC5NVh2XoFdXYdMRhtbNwmJ5u74959Yn54DH1tFuElIZbbbN3yMzY5itLB3n9gTBdo4+ 50wVhL/Q/ouDsvQB6Ypnr0ZhwdYhPX1YcoaXq5rFTOxOoFHKJIvUQBnF8wIV6RdjF1Oq6DiFc JkbHojHRz1RAbcWwPGREpg9RoB47gxDx6MYxbkhHBEYC77zdIQ6ypdYbb/LamxUpioWN5NHVJ e7GrNpuz0RqGl+ajpJ0cXl728tMWrtL61U+xRjWcmJm3igadfApXggtKBD/MLg1YwweyFI7hF as1Nd0wXG9YkB4JSS7xyEVfM2fgdVKnwSBvkE6VyuRq28fOT3OHraJHzUHzLCEFBa6fb1YI X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 31031 Cc: 31031 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.7 (/) >> Can you try fixing that in some consistent manner? You can find the >> corresponding code in x_calc_absolute_position in xterm.c. BTW, does= >> it work right when you use the "(- POS)" specification? > > (modify-frame-parameters nil '((user-position . t) (left . (- 0)))) > > gives the same offset effect as > > (modify-frame-parameters nil '((user-position . t) (left . 1.0))) So we should try fixing (or documenting) the misbehavior of the (- n) notation first. > D'oh. Of course, top is the right parameter to use. With that the > frame switches monitor between top and bottom, so that would imply > that the same switching should happen for "left". I=CA=BCm undecided s= o far > as to which I think is the "correct" behaviour. I'm not sure I understand. Do you mean that when you change the value of 'left' the frame always stays within the left monitor while when you change 'top' the frame moves from the upper to the lower monitor and back? That would be queer. >>> [1] Not completely to the right, but that=CA=BCs a different issue >> >> Probably a problem with calculating the decorations. Does >> (frame-geometry) return "reasonable" values for your frame? > > (display-monitor-attributes-list) > (((name . "XWAYLAND0") (geometry 0 540 3840 2160) (workarea 0 540 3= 840 > 2094) (mm-size 350 190) (frames #<frame *unsent wide reply to marti= n > rudalics* 0x3d5ce80> #<frame *info* 0x89f6ff0> #<frame *scratch* 0x= 87f1a00>) > (source . "Gdk"))) > > (modify-frame-parameters nil '((user-position . t) (left . 1.0))) > > (frame-geometry) > ((outer-position 2340 . 1730) (outer-size 1480 . 824) Hmm ... 2340 + 1480 gives 3820 which is obviously 20 pixels to the left of 3840. This clearly went wrong. Did we _ask_ for 2340 or 2360? > (external-border-size 20 . 20) (outer-border-width . 0) > (title-bar-size 0 . 70) (menu-bar-external . t) (menu-bar-size 0 . = 0) > (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0 > . 0) (internal-border-width . 0)) > > (+ 2340 1480) =3D> 3820, + external-border-size? In any case, visually= > the frame is not flush right. Do we anywhere add only one 'external-border-size' instead of two? > If I correct the visual aspect: > > (modify-frame-parameters nil '((left . (+ 2400)))) > > (frame-geometry) > ((outer-position 2380 . 1586) (outer-size 1480 . 824) > (external-border-size 20 . 20) (outer-border-width . 0) > (title-bar-size 0 . 70) (menu-bar-external . t) (menu-bar-size 0 . = 0) > (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0 > . 0) (internal-border-width . 0)) > > which to me says there=CA=BCs a (-20) error for the outer-position at > least. Why did you ask for 2400 and not for 2360? If the position value is too large the window manager might try to fit the frame onto the screen. OTOH "correcting" this to 2380 means there are 20 pixels (the full right external border) missing on the right if not I am missing something. BTW is this on a high resolution display? Would/should we scale external borders on such a display too? martin > I=CA=BCll take a look at x_calc_absolute_position. Fine. Thanks, martin
bug-gnu-emacs@HIDDEN:bug#31031; Package emacs.
Full text available.
Received: (at 31031) by debbugs.gnu.org; 3 Apr 2018 15:08:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 03 11:08:51 2018
Received: from localhost ([127.0.0.1]:37229 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1f3NYI-0006kc-37
for submit <at> debbugs.gnu.org; Tue, 03 Apr 2018 11:08:51 -0400
Received: from userp2120.oracle.com ([156.151.31.85]:36338)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <drew.adams@HIDDEN>) id 1f3NYF-0006kO-V7
for 31031 <at> debbugs.gnu.org; Tue, 03 Apr 2018 11:08:48 -0400
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w33F49oG190105;
Tue, 3 Apr 2018 15:08:42 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
h=mime-version :
message-id : date : from : sender : to : subject : references :
in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26;
bh=is6fJfxwTVF3F2eg/tTiRDv2sw4+fgdfm/kaLmDbbuc=;
b=Q3XhFtcrSrOK8Wg5UirW0XqBbsYI76NKCHq4gAOFrj/D8Qni5f3L6R5KZqUfMcx9/zj+
MWpko0nQwzZH859iPRG3uTmAbXi6Ni9MSCaBxa6+/UNCUveHsIhFUIC9TM3vDCCPYW6z
JR0J/p1/jQ7g6yLbp5xIWuXiZovzZynf9QFybR0bJup+DrraIXMi6rUTS97Bqf3Ktk4l
uofddl9siJMVfEoGY7bg4QwoFxhCzHFPf6hS80g/RIGHnIPars1Kkk6HXQ2F+Qd6T9zE
gOVDh1MxSjUZdH6J+jpSJuelZJWx5/6J7R0h1YU5RjNOo1JpMMqsMKnKQ7VQdqrC1saq Aw==
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71])
by userp2120.oracle.com with ESMTP id 2h4bx8r0v6-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
Tue, 03 Apr 2018 15:08:42 +0000
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236])
by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w33F8eZn012547
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
Tue, 3 Apr 2018 15:08:41 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21])
by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w33F8ex9027129;
Tue, 3 Apr 2018 15:08:40 GMT
MIME-Version: 1.0
Message-ID: <0f7742b2-9e8e-47ed-a6c0-195e1985b5e0@default>
Date: Tue, 3 Apr 2018 08:08:38 -0700 (PDT)
From: Drew Adams <drew.adams@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>, 31031 <at> debbugs.gnu.org
Subject: RE: bug#31031: 27.0; (elisp) `Position Parameters', floating-point
values
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
<5AC3232D.1020107@HIDDEN>
In-Reply-To: <5AC3232D.1020107@HIDDEN>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL
16.0.4666.0 (x86)]
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8851
signatures=668697
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0
malwarescore=0
phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999
adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
engine=8.0.1-1711220000 definitions=main-1804030157
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 31031
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
> > Of course, the "out" is that it says, "In general, it is not a good id=
ea
> > to position a frame relative to the right or bottom edge of its
> > display." But the only case discussed in that context is an initial/n=
ew
> > frame.
>=20
> It also talks about how these positions are stored and restored, for
> example, when saving the desktop.
Yes. But I'm not sure why you mention that here.
What might I be missing?
> > And there is a similar caveat about using not using
> > floating-point with decorated frames. But again, it speaks only about
> > "when CREATING decorated frames.
>=20
> Because Emacs does not know the size of decorations _before_ a frame
> has been created.
Yes. The case I'm asking about is the case of an existing frame.
I don't expect any magic for the new-frame case. That part is
clear enough, I think.
> > The text talks about positioning flush to edges of the "display", whic=
h
> > I'm interpreting as the dominating monitor in the case of multiple
> > monitors. (Is that wrong?)
>=20
> 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 have limited access to multiple monitors, myself. The
manual says that the monitor that dominates a frame is
"the monitor that contains the largest part of the window"
((elisp) `Creating Frames'). And:
A frame is =E2=80=9Cdominated=E2=80=9D by a physical monitor when either =
the
largest area of the frame resides in that monitor, or (if the frame
does not intersect any physical monitors) that monitor is the
closest to the frame. Every (non-tooltip) frame (whether visible
or not) in a graphical display is dominated by exactly one physical
monitor at a time, though the frame can span multiple (or no)
physical monitors. -- (elisp) `Multiple Terminals'
> > 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)))
> > (modify-frame-parameters nil '((left . - 0.0)))
>=20
> The last specification is wrong - floating point values must be
> unsigned.
Ah yes. My bad. The doc does say 0.0 to 1.0.
=20
> > (modify-frame-parameters nil '((left . 1.0)))
>=20
> 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.
With a single monitor it does indeed do what you say, and
what one would expect. When I tried with left and right
monitors I saw what I described (I don't have access to
multiple monitors today, but that is definitely what I
saw).
I'm guessing now that `modify-frame-parameters' pays no
attention to the dominating monitor and expects its
position inputs to always use screen coordinates, i.e.,
relative to all monitors combined, not relative to the
dominating monitor.
If so then the doc about floating-point perhaps just needs
to be modified to not talk about "display" (which can be,
at least in some other places, the dominating monitor),
and instead talk about "screen" (which seems to always
refer to the space of all monitors taken together.
> > (And adding (user-position . t) changes nothing in this regard.)
>=20
> 'user-position' has no effect on Windows and can be silently ignored
> by window managers on GNU/Linux. Don't rely on it.
OK. And the doc has generally made that clear.
However, this part of the doc this report is about is
unclear in this regard:
If you want to be sure the position you specify is not
^^^^^^^^^^
ignored, specify a non-=E2=80=98nil=E2=80=99 value for the =E2=80=98user-=
position=E2=80=99
parameter
That suggests that here, at least, the parameter makes sure
that you get what you ask for.
> > What am I misunderstanding, here? Can this text please be made more
> > clear? It's not really clear how floating-point values are supposed t=
o
> > be used or what they are supposed to do. Dunno whether the behavior I=
'm
> > seeing is bugged or the doc is wrong or I'm misunderstanding it.
>=20
> Please state what you do not understand or can be improved in this
> text: [just a repeat of the existing doc]
See what I've said already. I think it does not do what is
described, for multiple monitors.=20
> In particular, it states that specifying floating point values is more
> suited for child frames than for normal frames although by design they
> should work for the latter too.
Yes, it says that. And yes, I am using "decorated" frames.
But "they should work for the latter too" suggests that,
well, they should work for the latter too.
Don't get me wrong. I appreciate the care with which you
wrote this doc (about floating-point values). I think
perhaps it can be improved in two ways:
1. Corrected wrt mention of "display", if it is in fact
the whole screen that is meant (e.g., in the case of
multiple monitors.
2. The text is pretty dense. This, in particular:
A floating-point value ... specifies the
left edge=E2=80=99s offset via the =E2=80=9Cleft position ratio=E2=80=
=9D of the
frame=E2=80=94the ratio of the left edge of its outer frame to the
width of the frame=E2=80=99s workarea (*note Multiple Terminals::) or
its parent=E2=80=99s native frame (*note Child Frames::) minus the
width of the outer frame.
Maybe split that sentence into at least two sentences, but
probably three or four (or five).
Maybe say "length of the left edge" instead of "left edge".
What's the "outer frame" in the case of a non-child frame?
Maybe say "screen area" instead of "frame's workarea"? The
latter is undefined, AFAIK, and can suggest the dominating
monitor and not the total screen area of all monitors.
Maybe add "to" before "its parent's...", to make it more
clear that it's the ratio of the left-edge length to ___
or ___ (minus...), not the ratio of the left-edge length
or ___ to ___ (minus...). But splitting the sentence up
into constituent pieces would help most.
Maybe each term used should be defined here, rather than
sending readers elsewhere. If a reader has to go study
4 other dense nodes to understand the terms used here in
a super-dense spec, then there are too many obstacles to
understanding.
If you try to state the same info in multiple, very simple
sentences, then I can try to make suggestions that might
make that text flow better. But without that starting
point of very simple statements I wouldn't really know
where to start. (And probably the simple sentences would
be fine as is, with no further suggestions needed.)
HTH, and thanks for your work on this. I'm hoping that
someone who has multiple monitors can chime in helpfully,
as well.
In sum, in priority, I'd suggest:
1. Possible code changes, to get the behavior consistent
and understandable.
2. Factual changes to the doc to reflect that corrected
behavior.
3. Simple sentences, defining terms (and possibly using
diagrams) as needed, so the spec here is at least a
bit more self-contained.
bug-gnu-emacs@HIDDEN:bug#31031; Package emacs.
Full text available.Received: (at 31031) by debbugs.gnu.org; 3 Apr 2018 12:35:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 03 08:35:52 2018 Received: from localhost ([127.0.0.1]:35985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1f3LAG-0000vi-FM for submit <at> debbugs.gnu.org; Tue, 03 Apr 2018 08:35:52 -0400 Received: from mail-wm0-f41.google.com ([74.125.82.41]:38706) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <rpluim@HIDDEN>) id 1f3LAE-0000vW-QM for 31031 <at> debbugs.gnu.org; Tue, 03 Apr 2018 08:35:51 -0400 Received: by mail-wm0-f41.google.com with SMTP id i3so11094579wmf.3 for <31031 <at> debbugs.gnu.org>; Tue, 03 Apr 2018 05:35:50 -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=WOpwq1cDAd2RdIWkZrWSwuba47OJCdsUKz5gcIbH/3M=; b=QoyTBfAv1dTiNuEdg9RFQjBO8UnBvUc18jBT5pb3czagYHDIDWEYC2ulricwlwEfWd 0z91mDgpoZtWi1B0ZuU/rQTbzPHzyhZbuSjzFjqplUn83lcD6Nt3BgM0lZKLwN3UGWgn tgYK5tFO9sD9rqiPtV7yDrYu5gGiXeXdC6rJoZRg8gEEjRJDoMH12BnOG/AEA7kv1xrA TM95EjfboW8YQ9FUxTH91fgKA5OP6k+xH7uWN0jDOdPqZcmr8hTnhBcKxdGNwNQI8KQz nDhYR1aAytBAB+2xzyIF2m/w1jr/qTc0V1YZYRgnLKd3n+WQkBYI2I2msSZNmhmJIcTg pbtg== 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=WOpwq1cDAd2RdIWkZrWSwuba47OJCdsUKz5gcIbH/3M=; b=aC31NAwTBqDjKj1s13XRvNix2alQkeXuWaPrtOt9PC9GXaE+Dth3Fv9wpf+9Xk3kjt QbXN9+kCZwSS6+xmkD/D3T1K0ZKT/y0vg6hD4TGxKC1EBsObPHmf+8s6cr6wfdbi0Cm/ 3/HkvktMmI9Gzw5EuRyejQ5z61JKshBWWwTHc1ExICx8p4DyvZMJa8WVAmdWVhb0IoS1 yjFZQqZofIS5nr2ZfJL+/gLYBiwTcZmYG9un9BYGGmy7yI1ImAjvWzKarOwsYrhIpAd8 t59j0ujJoSEEZqho4YDhihtFonmrskRkTBYUxIjmzdl7ZmMz6SC6anS0lXnswmo6Rmbz IqBw== X-Gm-Message-State: AElRT7EmurDzXT9b5bE1+lxszgCFb+7c161SPEe+NwE2RApb3x2XMB8i 6+AdzKB105+hNqKm50yBtTQqvbHUQEk= X-Google-Smtp-Source: AIpwx4/GKWU/OtIl0SyzUYnpNcyKbP/G+SCM6WfSPST4+/vY12sRLyU00zuhMOdpDaEzxblZnk7gqw== X-Received: by 10.80.148.49 with SMTP id p46mr16305323eda.311.1522758944384; Tue, 03 Apr 2018 05:35:44 -0700 (PDT) Received: from rpluim ([149.5.228.1]) by smtp.gmail.com with ESMTPSA id n3sm1807708edl.27.2018.04.03.05.35.43 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 03 Apr 2018 05:35:43 -0700 (PDT) From: Robert Pluim <rpluim@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default> <5AC3232D.1020107@HIDDEN> <874lksy9vy.fsf@HIDDEN> <5AC35626.2070700@HIDDEN> X-Debbugs-No-Ack: yes Mail-Copies-To: never Gmane-Reply-To-List: yes Date: Tue, 03 Apr 2018 14:35:42 +0200 In-Reply-To: <5AC35626.2070700@HIDDEN> (martin rudalics's message of "Tue, 03 Apr 2018 12:23:34 +0200") Message-ID: <877epowjq9.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 31031 Cc: 31031 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.0 (/) martin rudalics <rudalics@HIDDEN> writes: >>>> (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. > > Thanks for testing. I suppose that's the expected behavior. > >>>> (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. > > This sounds wrong. I suppose the frame should move to the right edge > of the rightmost monitor. I=CA=BCm undecided on this now. See below. >> 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. > > Can you try fixing that in some consistent manner? You can find the > corresponding code in x_calc_absolute_position in xterm.c. BTW, does > it work right when you use the "(- POS)" specification? (modify-frame-parameters nil '((user-position . t) (left . (- 0)))) gives the same offset effect as (modify-frame-parameters nil '((user-position . t) (left . 1.0))) >> 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. > > Did you try specifying the "top" parameter in that configuration? D'oh. Of course, top is the right parameter to use. With that the frame switches monitor between top and bottom, so that would imply that the same switching should happen for "left". I=CA=BCm undecided so far as to which I think is the "correct" behaviour. >> [1] Not completely to the right, but that=CA=BCs a different issue > > Probably a problem with calculating the decorations. Does > (frame-geometry) return "reasonable" values for your frame? (display-monitor-attributes-list) (((name . "XWAYLAND0") (geometry 0 540 3840 2160) (workarea 0 540 3840 2094) (mm-size 350 190) (frames #<frame *unsent wide reply to martin rudalics* 0x3d5ce80> #<frame *info* 0x89f6ff0> #<frame *scratch* 0x87f1a0= 0>) (source . "Gdk"))) (modify-frame-parameters nil '((user-position . t) (left . 1.0))) (frame-geometry) ((outer-position 2340 . 1730) (outer-size 1480 . 824) (external-border-size 20 . 20) (outer-border-width . 0) (title-bar-size 0 . 70) (menu-bar-external . t) (menu-bar-size 0 . 0) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0 . 0) (internal-border-width . 0)) (+ 2340 1480) =3D> 3820, + external-border-size? In any case, visually the frame is not flush right. If I correct the visual aspect: (modify-frame-parameters nil '((left . (+ 2400)))) (frame-geometry) ((outer-position 2380 . 1586) (outer-size 1480 . 824) (external-border-size 20 . 20) (outer-border-width . 0) (title-bar-size 0 . 70) (menu-bar-external . t) (menu-bar-size 0 . 0) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0 . 0) (internal-border-width . 0)) which to me says there=CA=BCs a (-20) error for the outer-position at least. I=CA=BCll take a look at x_calc_absolute_position. Robert
bug-gnu-emacs@HIDDEN:bug#31031; Package emacs.
Full text available.Received: (at 31031) by debbugs.gnu.org; 3 Apr 2018 10:23:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 03 06:23:59 2018 Received: from localhost ([127.0.0.1]:35866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1f3J6d-0002H8-Cq for submit <at> debbugs.gnu.org; Tue, 03 Apr 2018 06:23:59 -0400 Received: from mout.gmx.net ([212.227.17.21]:35859) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <rudalics@HIDDEN>) id 1f3J6c-0002Gs-2c for 31031 <at> debbugs.gnu.org; Tue, 03 Apr 2018 06:23:58 -0400 Received: from [192.168.1.100] ([213.162.73.239]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MBrCt-1fCPVJ1fIl-00AmN7; Tue, 03 Apr 2018 12:23:42 +0200 Message-ID: <5AC35626.2070700@HIDDEN> Date: Tue, 03 Apr 2018 12:23:34 +0200 From: martin rudalics <rudalics@HIDDEN> MIME-Version: 1.0 To: Robert Pluim <rpluim@HIDDEN> Subject: Re: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default> <5AC3232D.1020107@HIDDEN> <874lksy9vy.fsf@HIDDEN> In-Reply-To: <874lksy9vy.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:BTAwp5dpp2XtqFCcrA9ymvNoqzhL5zyshoR5yqwK0BcSicVeT9d xLcSgQwblbw0VQqLY1AmODAW++1Y8uAHPadbUE6yZU7r2b65Jk7witVKBWf9meoXNxDLFeX DrgPXIh97fJjTfLF5VNcEGSU2d43V4mnxUvNoiveFhwZ4yTHt1H++uaeTskm6jx95hShPog VuVgivqzVe+G/W8yIOqAw== X-UI-Out-Filterresults: notjunk:1;V01:K0:HSeiHSioqpA=:FR1CFLi+TD2UffCECklbAp R91pNQE7kvhekauzFZoVaCmqgnict6sqq12kodVwiZLr3ang5qxEcCaWGIRmwDaqho+y8lyoa qXVOFX/2M9Y2yDvZ6VH51GzGyYSiSq8J/473/l7ZQpBOnPmw0oPdBGrlhWK8eJwNEah3GoNGS hOp3VrypHf86BYnUGq6LvwHkChFXajNNVXK5MYb9yy/oSvb9Gxc5L+oN1LEzSY/TB5TBnZj7B XS97z+nUdZzm9YLg5jFKjRNvuC4cFVhtwVbpAotTOWYwB4kzUVVdSfWesGADPyHe79o5bXzBU 0BKXCUqcBu3xCsIcMyDtE2NvV0k2dIctu86fOPa8ATq+9xJvUHOFEbvrbgbmYjhyWyyfx11mX M9RylTLFwdS6duMg7YPXod/Ge1HIcpJJd+cTWl0JCThjteBfAytvE8WGQOpExdmmN0lGY26NV oAiskTym5WAFYKYFceL8l7VVT/ks8NZpIWAXqp8a0jxIyqHWzdQ3KMUkHT+p+0pbcQfH8snKF aKIId5aBMC/tYrPmXxX3aH60LgeZCee4bEzG0n2Er1e7yTJiFr44TjHhdDLmR4X2LwOB4um3M CpY2aaw/8oN2XNbRGqz3NHAcxpNHvS4glZChHjCkdYwRqfrJ8T4BRuQheJrB0RvzH0UfPiJio vblUu8k6hrIteQWqOnCPQzVU0GhM9Y3dM+r+g37ROCE5xc666n8j8Q1sJl2FwkhJSDtnZJzKX mPugD37Ksds1WiXNhOgUWx140UX4tMTVZ0Z5VySa4081+ir4IO17C8YJAtRbKJ4uQLCs+2JBH kYK3w5o8ZyNQxOebnvo5i0tBIbnZBriH1v4HNsqaDQgFXbm9Fm4PSRe6Sgscdks32jkqd15 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 31031 Cc: Drew Adams <drew.adams@HIDDEN>, 31031 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.7 (/) >>> (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 le= ft or > right. Thanks for testing. I suppose that's the expected behavior. >>> (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 relati= ve > positioning. This sounds wrong. I suppose the frame should move to the right edge of the rightmost monitor. > 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. Can you try fixing that in some consistent manner? You can find the corresponding code in x_calc_absolute_position in xterm.c. BTW, does it work right when you use the "(- POS)" specification? > 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. Did you try specifying the "top" parameter in that configuration? > [1] Not completely to the right, but that=CA=BCs a different issue Probably a problem with calculating the decorations. Does (frame-geometry) return "reasonable" values for your frame? martin
bug-gnu-emacs@HIDDEN:bug#31031; Package emacs.
Full text available.Received: (at 31031) by debbugs.gnu.org; 3 Apr 2018 08:25:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 03 04:25:30 2018 Received: from localhost ([127.0.0.1]:35757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1f3HFy-0007xF-A4 for submit <at> debbugs.gnu.org; Tue, 03 Apr 2018 04:25:30 -0400 Received: from mail-wm0-f43.google.com ([74.125.82.43]:37321) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <rpluim@HIDDEN>) id 1f3HFx-0007x5-1p for 31031 <at> debbugs.gnu.org; Tue, 03 Apr 2018 04:25:29 -0400 Received: by mail-wm0-f43.google.com with SMTP id r131so33057440wmb.2 for <31031 <at> 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) 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) From: Robert Pluim <rpluim@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default> <5AC3232D.1020107@HIDDEN> X-Debbugs-No-Ack: yes Mail-Copies-To: never Gmane-Reply-To-List: yes Date: Tue, 03 Apr 2018 10:25:21 +0200 In-Reply-To: <5AC3232D.1020107@HIDDEN> (martin rudalics's message of "Tue, 03 Apr 2018 08:46:05 +0200") Message-ID: <874lksy9vy.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 31031 Cc: Drew Adams <drew.adams@HIDDEN>, 31031 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.0 (/) martin rudalics <rudalics@HIDDEN> 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
bug-gnu-emacs@HIDDEN:bug#31031; Package emacs.
Full text available.
Received: (at 31031) by debbugs.gnu.org; 3 Apr 2018 06:46:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 03 02:46:28 2018
Received: from localhost ([127.0.0.1]:35707 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1f3Fi7-0005fb-Tc
for submit <at> debbugs.gnu.org; Tue, 03 Apr 2018 02:46:28 -0400
Received: from mout.gmx.net ([212.227.15.19]:55465)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1f3Fi3-0005fM-FS
for 31031 <at> debbugs.gnu.org; Tue, 03 Apr 2018 02:46:24 -0400
Received: from [192.168.1.100] ([212.95.5.238]) by mail.gmx.com (mrgmx003
[212.227.17.190]) with ESMTPSA (Nemesis) id 0M5LJv-1eJZ2R4Aed-00zZsJ; Tue, 03
Apr 2018 08:46:13 +0200
Message-ID: <5AC3232D.1020107@HIDDEN>
Date: Tue, 03 Apr 2018 08:46:05 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: Drew Adams <drew.adams@HIDDEN>, 31031 <at> debbugs.gnu.org
Subject: Re: bug#31031: 27.0; (elisp) `Position Parameters', floating-point
values
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
In-Reply-To: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:TVWzEikpnChSzveGO9KaG5+uScG5nDgzLBhz59MFQCnqkjMhgPj
6+0sEllrZSQ8pEd9ozrflFK3B+5mONUnKm3wk2lh8hBH10aNqbnoSS8hYTX2QwoYVgUMjSx
J7p+KOZvBEa/2qsmra8uAi1BbPR3LIJw1Sz+12YQp8Oorh6qJE5744dtweHlbqW0oO3EiSE
4UKsCarFngkxZHG41i3Eg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:ED3p5CJ8fwc=:AZERY3FMPeL8IkQu2sGY/a
q6eJyfNQNPC5TOed+rOrF7kxPq4t8zCTn4RUNLHuzPGd2RoCkNd53KNERM6KJ2KAQppAgflop
A7lx17uMGSGQCphg9MZ0Vozjbj96MlINbAzuYsrN4fndxdJSkFu8c3vDhFaQQEhMjbKurbQH8
/2XQ4LfrMD1OGBoenQfWHuh7E4sIBajJ2DPTb2573jhAVjlaDjgoitf02OlGUl3PtdnO5Sn0t
ZUSSMlimBfmlHi8J9rV4AxAFjw32qwqW+CET/KrdagiL9v/FLxQRBDuSj2HZ3HB3NpVvqldjU
1vuPSPlJp1pVyNI9eFgEJuv3P/4Fvilv2MCkijnUm+jyfg69pbpuRtCsKlk7J6czLderNBM0x
iib5+I0kkZGWAZdATD9+pCFC7GuAc4s43DPMtoFQ+M7Lp2z0aQYPi8EBsJndGZj0mMJHqU6na
9OxuYsf4yyV+Yr9Wp72ixxa6QielqKgawQZjUiK4L/Iw+CDxlyKQoDefqe1bNusR+jQMlzHlp
7EszIoGkGZT4zuB6arnLtMWmyer0haRYXysM3yLzxwjiG+o6zdzfnu5Eeo6RekVFESrW7UWHj
7F8Sq8ErwXL4KkdoCbWGaafpCgfVbl3DqeecSNBOW+HKO1kSKzSLo97HyPDEqqkc2NdkSFwJ8
pj4RwzsZbbQcBcK1WeJGgeNtNdz1zdF+dBpOKCj1JIQrS6zRH2Muzcjp76RH1STOB0GoQ1QpE
qhm5HK4Rb+6lgQP+AJkeqM/JMyIkt6Cdjj6/sMyCrUdWY2OXEySBNR80Lx6TSI2MrojlY4jXB
5xWhzktswxI03rEyiZBz6yDkX06/Rds+uet75XjwCaxP0Trnao=
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 31031
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)
> Of course, the "out" is that it says, "In general, it is not a good idea
> to position a frame relative to the right or bottom edge of its
> display." But the only case discussed in that context is an initial/new
> frame.
It also talks about how these positions are stored and restored, for
example, when saving the desktop.
> And there is a similar caveat about using not using
> floating-point with decorated frames. But again, it speaks only about
> "when CREATING decorated frames.
Because Emacs does not know the size of decorations _before_ a frame
has been created.
> 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.
> 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)))
> (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)))
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.
> (modify-frame-parameters nil '((left . - 1.0)))
See above.
> (And adding (user-position . t) changes nothing in this regard.)
'user-position' has no effect on Windows and can be silently ignored
by window managers on GNU/Linux. Don't rely on it.
> What am I misunderstanding, here? Can this text please be made more
> clear? It's not really clear how floating-point values are supposed to
> be used or what they are supposed to do. Dunno whether the behavior I'm
> seeing is bugged or the doc is wrong or I'm misunderstanding it.
Please state what you do not understand or can be improved in this
text:
A floating-point value in the range 0.0 to 1.0 specifies the
left edge's offset via the "left position ratio" of the
frame--the ratio of the left edge of its outer frame to the
width of the frame's workarea (*note Multiple Terminals::) or
its parent's native frame (*note Child Frames::) minus the
width of the outer frame. Thus, a left position ratio of 0.0
flushes a frame to the left, a ratio of 0.5 centers it and a
ratio of 1.0 flushes it to the right of its display or parent
frame. Similarly, the "top position ratio" of a frame is the
ratio of the frame's top position to the height of its
workarea or parent frame minus the height of the frame.
Emacs will try to keep the position ratios of a child frame
unaltered if that frame has a non-`nil' `keep-ratio' parameter
(*note Frame Interaction Parameters::) and its parent frame
is resized.
Since the outer size of a frame (*note Frame Geometry::) is
usually unavailable before a frame has been made visible, it
is generally not advisable to use floating-point values when
creating decorated frames. Floating-point values are more
suited for ensuring that an (undecorated) child frame is
positioned nicely within the area of its parent frame.
In particular, it states that specifying floating point values is more
suited for child frames than for normal frames although by design they
should work for the latter too.
Thanks, martin
bug-gnu-emacs@HIDDEN:bug#31031; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 2 Apr 2018 21:56:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 02 17:56:49 2018 Received: from localhost ([127.0.0.1]:35521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1f37RY-0006YK-Ug for submit <at> debbugs.gnu.org; Mon, 02 Apr 2018 17:56:49 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44879) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <drew.adams@HIDDEN>) id 1f37RW-0006Y7-VM for submit <at> debbugs.gnu.org; Mon, 02 Apr 2018 17:56:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <drew.adams@HIDDEN>) id 1f37RP-0008RI-Jj for submit <at> debbugs.gnu.org; Mon, 02 Apr 2018 17:56:40 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:54619) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <drew.adams@HIDDEN>) id 1f37RP-0008R9-GK for submit <at> debbugs.gnu.org; Mon, 02 Apr 2018 17:56:39 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <drew.adams@HIDDEN>) id 1f37RO-0007kA-5N for bug-gnu-emacs@HIDDEN; Mon, 02 Apr 2018 17:56:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <drew.adams@HIDDEN>) id 1f37RJ-0008L2-9t for bug-gnu-emacs@HIDDEN; Mon, 02 Apr 2018 17:56:38 -0400 Received: from aserp2130.oracle.com ([141.146.126.79]:43818) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <drew.adams@HIDDEN>) id 1f37RJ-0008KE-0A for bug-gnu-emacs@HIDDEN; Mon, 02 Apr 2018 17:56:33 -0400 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w32LtpvT111047 for <bug-gnu-emacs@HIDDEN>; Mon, 2 Apr 2018 21:56:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=eZlGI1sF8GyzbEUBCcl9r+Y45AvbDVF9Wr9g80AWEfM=; b=fGdaNzTnBWQk0TmDfFOY8/N89ZPWDbI731gjwRtgHB6Z4+JT8+5C/0zWSOAM2fF0vk5U LyoA1GaTKWf8A6VwCHEDWzGU/JVOixU/nwhXskm/J/k8M1ETYN4/afxIeFgyU7x5H2td NQG7ZVZllDNEf0wPeJVqUAaOzgW3Y3l96TtTWd/5I6hcmcNpgx+vGv6VDfEKcEeqBPo1 D4Ae3WZkggnzZzEYBzq+uIZy5zCH8GD91r/OJglAYABUNdaFqaNEXR4ED7nRor07KZ4h 6DMzmIXEy2RXTPYYrFMY/RdtOUw6r5dgWr+RjqcVw64TqasZB1s3iTFHgRMq5o8RkCPB Fw== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2130.oracle.com with ESMTP id 2h3vv3802q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <bug-gnu-emacs@HIDDEN>; Mon, 02 Apr 2018 21:56:31 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w32LuUtM018930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <bug-gnu-emacs@HIDDEN>; Mon, 2 Apr 2018 21:56:30 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w32LuTlY001157 for <bug-gnu-emacs@HIDDEN>; Mon, 2 Apr 2018 21:56:30 GMT MIME-Version: 1.0 Message-ID: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default> Date: Mon, 2 Apr 2018 14:56:28 -0700 (PDT) From: Drew Adams <drew.adams@HIDDEN> To: bug-gnu-emacs@HIDDEN Subject: 27.0; (elisp) `Position Parameters', floating-point values X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4666.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8851 signatures=668697 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804020229 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -4.0 (----) I'm afraid this reads a bit like gobbledygook, to me. And if I think I understand it, it doesn't seem to correspond to the behavior I see. Of course, the "out" is that it says, "In general, it is not a good idea to position a frame relative to the right or bottom edge of its display." But the only case discussed in that context is an initial/new frame. And there is a similar caveat about using not using floating-point with decorated frames. But again, it speaks only about "when CREATING decorated frames.=20 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?) 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))) (modify-frame-parameters nil '((left . - 0.0))) (modify-frame-parameters nil '((left . 1.0))) (modify-frame-parameters nil '((left . - 1.0))) (And adding (user-position . t) changes nothing in this regard.) What am I misunderstanding, here? Can this text please be made more clear? It's not really clear how floating-point values are supposed to be used or what they are supposed to do. Dunno whether the behavior I'm seeing is bugged or the doc is wrong or I'm misunderstanding it. In GNU Emacs 27.0.50 (build 3, x86_64-w64-mingw32) of 2018-03-21 Repository revision: e70d0c9e66d7a8609450b2889869d16aeb0363b5 Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --without-dbus --host=3Dx86_64-w64-mingw32 --without-compress-install -C 'CFLAGS=3D-O2 -static -g3''
Drew Adams <drew.adams@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#31031; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.