GNU bug report logs - #20552
modify-frame-parameters left edge positioning

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20552 in the body.
You can then email your comments to 20552 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: gottlieb <at> nyu.edu
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4; cc
Date: Mon, 11 May 2015 16:10:03 -0400

I execute the following function in *scratch* on a fresh emacs -Q

  (modify-frame-parameters nil '( (width . 176) (left . -1300)))

My screen is 2560x1600.  Emacs version is 24.4.  System is gentoo/gnome.

The width does become 176.
However, left is not correct (it should be flush left but is nearly
centered).
The weird part is if I execute the same command again (a second C-j in
*scratch), the frame moves to the correct, flush left, position.

(Since my screen is 2560 wide (left . -1300) should have the right edge
a little left of center, instead it is very much right of center.)




In GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.9)
 of 2015-04-01 on newlap
Windowing system distributor `The X.Org Foundation', version 11.0.11604000
System Description:	Gentoo Base System release 2.2

Configured using:
 `configure --prefix=/usr --build=x86_64-pc-linux-gnu
 --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
 --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
 --localstatedir=/var/lib --disable-dependency-tracking
 --disable-silent-rules --libdir=/usr/lib64 --program-suffix=-emacs-24
 --infodir=/usr/share/info/emacs-24 --localstatedir=/var
 --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
 --with-gameuser=:gamestat --without-compress-install
 --with-file-notification=inotify --enable-acl --with-dbus
 --without-gnutls --with-gpm --without-hesiod --without-kerberos
 --without-kerberos5 --with-xml2 --without-selinux --without-wide-int
 --with-zlib --with-sound=alsa --with-x --without-ns --without-gconf
 --without-gsettings --with-toolkit-scroll-bars --with-gif --with-jpeg
 --with-png --with-rsvg --with-tiff --with-xpm --without-imagemagick
 --with-xft --without-libotf --without-m17n-flt --with-x-toolkit=gtk3
 GENTOO_PACKAGE=app-editors/emacs-24.4-r4 'CFLAGS=-march=native -O2
 -pipe' CPPFLAGS= 'LDFLAGS=-Wl,-O1 -Wl,--as-needed''

Important settings:
  value of $LANG: en_US.utf8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  eldoc-mode: t
  ido-everywhere: t
  nroff-electric-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p o r t - e v <tab> <backspace> m <tab> <r
eturn>

Recent messages:
Setting font to -unknown-DejaVu Sans Mono-medium-r-normal--14-*-*-*-m-*-iso8859-1
Source file `/home/gottlieb/.emacs.d/lisp/ajg-courses.el' newer than byte-compiled file
Setting printer to lj
Loading help-funs+...done
Source file `/home/gottlieb/.emacs.d/lisp/ajg-sgml.el' newer than byte-compiled file
Loading /home/gottlieb/.emacs.d/lisp/custom-file.el (source)...
Loading ido...done
Loading /home/gottlieb/.emacs.d/lisp/custom-file.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort flyspell ispell mail-extr gnus-msg emacsbug sendmail eldoc
tsdh-dark-theme ido cus-start cus-load ajg-sgml help-fns+ help-mode info
ehelp rolo ajg-dired dired-x dired ajg-gnus gnus-art mm-uu mml2015
epg-config mm-view mml-smime smime password-cache dig mailcap gnus-sum
nnoo gnus-group gnus-undo nnmail mail-source gnus-start gnus-spec
gnus-int gnus-range message format-spec rfc822 mml easymenu mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus gnus-ems
nnheader gnus-util mail-utils mm-util help-fns mail-prsvr wid-edit
ajg-printer nroff-mode ajg-nroff ajg-courses ajg-filling ajg-fonts
edmacro kmacro cl-loaddefs cl-lib site-gentoo tex-site auto-loads
time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment lisp-mode prog-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind inotify dynamic-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 158048 6897)
 (symbols 48 26684 0)
 (miscs 40 48 140)
 (strings 32 38648 7449)
 (string-bytes 1 1124873)
 (vectors 16 17283)
 (vector-slots 8 470924 3376)
 (floats 8 226 78)
 (intervals 56 275 0)
 (buffers 960 11)
 (heap 1024 23792 3565))

Message #8 received at 20552 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: gottlieb <at> nyu.edu, 20552 <at> debbugs.gnu.org
Subject: Re: bug#20552: 24.4; cc
Date: Tue, 12 May 2015 11:36:34 +0200

> I execute the following function in *scratch* on a fresh emacs -Q
>
>    (modify-frame-parameters nil '( (width . 176) (left . -1300)))
>
> My screen is 2560x1600.  Emacs version is 24.4.  System is gentoo/gnome.
>
> The width does become 176.
> However, left is not correct (it should be flush left but is nearly
> centered).

Why do you think it should be "flush left"?  When you specify

(left . -1300)

Emacs will tell the window manager to position the right edge of the
frame 1300 pixels to the left of the right screen edge.  You will get a
"flush left" effect if and only if your screen is as wide as

(+ 1300 (* 176 (frame-char-width)))

plus the space needed for scrollbars and frame decorations.  Why don't
you use (left . 0)?

> The weird part is if I execute the same command again (a second C-j in
> *scratch), the frame moves to the correct, flush left, position.
>
> (Since my screen is 2560 wide (left . -1300) should have the right edge
> a little left of center, instead it is very much right of center.)

Maybe your window manager tries to keep the frame within the screen
boundaries.

martin

Message #13 received at 20552 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: gottlieb <at> nyu.edu, "20552 <at> debbugs.gnu.org" <20552 <at> debbugs.gnu.org>
Subject: Re: bug#20552: 24.4; cc
Date: Wed, 13 May 2015 09:37:03 +0200

Please don't remove <20552 <at> debbugs.gnu.org> from the list of recipients.

> I started with (left . 0).  That moves the frame close to the left edge
> but not quite flush left.  If I manually move the frame flush left and
> execute (modify-frame-parameters nil '( (width . 176) ( left . 0)))
> the frame moves *right* so that it is again about 1/8 inch away

Hmm... which window manager?  Would

(modify-frame-parameters nil '((user-position . t) (width . 176) (left . 0)))

change anything?

>>> The weird part is if I execute the same command again (a second C-j in
>>> *scratch), the frame moves to the correct, flush left, position.
>>>
>>> (Since my screen is 2560 wide (left . -1300) should have the right edge
>>> a little left of center, instead it is very much right of center.)
>>
>> Maybe your window manager tries to keep the frame within the screen
>> boundaries.
>
> The weird part is that
>
>    (modify-frame-parameters nil '( (width . 176) (left . -1300)))
>
> done once is not flush left but if done a second time to the same
> emacs -Q is flush left

My usual answer here is that eventually Jan will kick in and explain.

martin

Message #16 received at 20552 <at> debbugs.gnu.org (full text, mbox):

From: gottlieb <at> nyu.edu
To: martin rudalics <rudalics <at> gmx.at>
Cc: "20552 <at> debbugs.gnu.org" <20552 <at> debbugs.gnu.org>
Subject: Re: bug#20552: 24.4; cc
Date: Wed, 13 May 2015 09:33:56 -0400

On Wed, May 13 2015, martin rudalics wrote:

> Please don't remove <20552 <at> debbugs.gnu.org> from the list of recipients.
>
>> I started with (left . 0).  That moves the frame close to the left edge
>> but not quite flush left.  If I manually move the frame flush left and
>> execute (modify-frame-parameters nil '( (width . 176) ( left . 0)))
>> the frame moves *right* so that it is again about 1/8 inch away
>
> Hmm... which window manager?  Would
>
> (modify-frame-parameters nil '((user-position . t) (width . 176) (left . 0)))
>
> change anything?
>

Indeed!  As you wrote it there is no difference.  (left . 0) remains
about 1/8 inch right of flush left (even if executed twice).  BUT

(modify-frame-parameters nil '((user-position . t) (width . 176)
                               (left . -1300))

does become flush left on an initial emacs -Q whereas without the
user-position (which I will now read about) it required two executions
to become flush left.  Recall, previously the first execution left the frame
several inches right of flush left but a second execution made it flush
left.

I have modified my scripts to include (user-position . t) and eliminated
the embarrassing repeat execution.

>>>> The weird part is if I execute the same command again (a second C-j in
>>>> *scratch), the frame moves to the correct, flush left, position.
>>>>
>>>> (Since my screen is 2560 wide (left . -1300) should have the right edge
>>>> a little left of center, instead it is very much right of center.)
>>>
>>> Maybe your window manager tries to keep the frame within the screen
>>> boundaries.
>>
>> The weird part is that
>>
>>    (modify-frame-parameters nil '( (width . 176) (left . -1300)))
>>
>> done once is not flush left but if done a second time to the same
>> emacs -Q is flush left
>
> My usual answer here is that eventually Jan will kick in and explain.
>
> martin

Thanks you very much.
allan

Message #19 received at 20552 <at> debbugs.gnu.org (full text, mbox):

From: gottlieb <at> nyu.edu
To: martin rudalics <rudalics <at> gmx.at>
Cc: "20552 <at> debbugs.gnu.org" <20552 <at> debbugs.gnu.org>
Subject: Re: bug#20552: 24.4; cc
Date: Wed, 13 May 2015 09:40:06 -0400

On Wed, May 13 2015, martin rudalics wrote:

> Please don't remove <20552 <at> debbugs.gnu.org> from the list of recipients.

Sorry.

>> I started with (left . 0).  That moves the frame close to the left edge
>> but not quite flush left.  If I manually move the frame flush left and
>> execute (modify-frame-parameters nil '( (width . 176) ( left . 0)))
>> the frame moves *right* so that it is again about 1/8 inch away
>
> Hmm... which window manager?

mutter / gnome-shell

allan

Message #22 received at 20552 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: gottlieb <at> nyu.edu
Cc: "20552 <at> debbugs.gnu.org" <20552 <at> debbugs.gnu.org>
Subject: Re: bug#20552: 24.4; cc
Date: Thu, 14 May 2015 12:13:58 +0200

> As you wrote it there is no difference.  (left . 0) remains
> about 1/8 inch right of flush left (even if executed twice).  BUT
>
> (modify-frame-parameters nil '((user-position . t) (width . 176)
>                                 (left . -1300))
>
> does become flush left on an initial emacs -Q whereas without the
> user-position (which I will now read about) it required two executions
> to become flush left.  Recall, previously the first execution left the frame
> several inches right of flush left but a second execution made it flush
> left.

Still weird.  What happens with

(modify-frame-parameters nil '((user-position . t) (width . 176) (left . 1)))

Also, you could try playing with the `(+ POS)' and `(- POS)' position
specifications (see section 28.3.3.2 Position Parameters of the Elisp
manual).

martin

Message #25 received at 20552 <at> debbugs.gnu.org (full text, mbox):

From: gottlieb <at> nyu.edu
To: martin rudalics <rudalics <at> gmx.at>
Cc: "20552 <at> debbugs.gnu.org" <20552 <at> debbugs.gnu.org>
Subject: Re: bug#20552: 24.4; cc
Date: Thu, 14 May 2015 16:33:11 -0400

On Thu, May 14 2015, martin rudalics wrote:

>> As you wrote it there is no difference.  (left . 0) remains
>> about 1/8 inch right of flush left (even if executed twice).  BUT
>>
>> (modify-frame-parameters nil '((user-position . t) (width . 176)
>>                                 (left . -1300))
>>
>> does become flush left on an initial emacs -Q whereas without the
>> user-position (which I will now read about) it required two executions
>> to become flush left.  Recall, previously the first execution left the frame
>> several inches right of flush left but a second execution made it flush
>> left.
>
> Still weird.  What happens with
>
> (modify-frame-parameters nil '((user-position . t) (width . 176) (left . 1)))

I am not at the 2560x1600 screen.  But I tried (left . 1) anyway.  It is
still about 1/8 inch from flush-left.  I tried (on this 1680x1050
monitor) (left -1300) and tried (left . -500) both gave flush left.

Conclusions
1. (user-position . t) is needed to get flush left immediately.
   The manual is clear on this if you know to look at user-position.

2. (left . 0) is not quite flush left even with user-position.
   Same for (left . 1).  Perhaps the window manager is causing this.

3. (The weird part) without user-position (left -1300) is not close to
   flush left when executed once but is flush left if repeated.  Its as
   though the second time it carries the force of user-position despite
   user-position not having ever been specified on this fresh emacs -Q.

> Also, you could try playing with the `(+ POS)' and `(- POS)' position
> specifications (see section 28.3.3.2 Position Parameters of the Elisp
> manual).
>
> martin

I tried those before I knew about (i.e., you told me about)
user-position and I still could not get flush left.  I will try again
with (user-position . t).

Thanks again,
allan

Message #28 received at 20552 <at> debbugs.gnu.org (full text, mbox):

From: gottlieb <at> nyu.edu
To: martin rudalics <rudalics <at> gmx.at>
Cc: "20552 <at> debbugs.gnu.org" <20552 <at> debbugs.gnu.org>
Subject: Re: bug#20552: 24.4; cc
Date: Thu, 14 May 2015 16:58:52 -0400

On Thu, May 14 2015, martin rudalics wrote:

>> As you wrote it there is no difference.  (left . 0) remains
>> about 1/8 inch right of flush left (even if executed twice).  BUT
>>
>> (modify-frame-parameters nil '((user-position . t) (width . 176)
>>                                 (left . -1300))
>>
>> does become flush left on an initial emacs -Q whereas without the
>> user-position (which I will now read about) it required two executions
>> to become flush left.  Recall, previously the first execution left the frame
>> several inches right of flush left but a second execution made it flush
>> left.
>
> Still weird.  What happens with
>
> (modify-frame-parameters nil '((user-position . t) (width . 176) (left . 1)))
>
> Also, you could try playing with the `(+ POS)' and `(- POS)' position
> specifications (see section 28.3.3.2 Position Parameters of the Elisp
> manual).

I tried this with user-position and it is weird, I would say buggy.

(modify-frame-parameters nil '((user-position . t) (width . 176)
                               (left . (- 1300))))

did give flush left on a fresh emacs -Q but the result is bad.
The original scroll bar is still there so it looks like there are two
windows side by side in the frame (C-x 3) but there is only one window,
only one mode line, and C-x o is a no-op.

thanks,
allan

Message #31 received at 20552 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: gottlieb <at> nyu.edu
Cc: "20552 <at> debbugs.gnu.org" <20552 <at> debbugs.gnu.org>
Subject: Re: bug#20552: 24.4; cc
Date: Fri, 15 May 2015 18:44:59 +0200

> 2. (left . 0) is not quite flush left even with user-position.
>     Same for (left . 1).  Perhaps the window manager is causing this.

Does

(modify-frame-parameters nil '((user-position . t) (width . 176) (left . (+ -1))))

flush left?  If not, what is the largest value less than -1 to flush
left with the (+ POS) notation?

martin

Message #34 received at 20552 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: gottlieb <at> nyu.edu, "20552 <at> debbugs.gnu.org" <20552 <at> debbugs.gnu.org>
Subject: Re: bug#20552: 24.4; cc
Date: Tue, 19 May 2015 11:42:44 +0200

>> If not, what is the largest value less than -1 to flush left with the
>> (+ POS) notation?
>
> -4
>
>> martin
>
> (modify-frame-parameters nil
> 			 '((user-position . t)
> 			   (width . 176)
> 			   (left . (+ -4))))
>
> is flush left (on the 1680x1050 monitor)
>
> (modify-frame-parameters nil
> 			 '((user-position . t)
> 			   (width . 176)
> 			   (left . (+ -3))))
>
> is not quite flush left (on the same monitor).

Thanks.  I added an abbreviated version of this as example to the Elisp
manual.  Any objections to closing this bug?

martin

Message #39 received at 20552-done <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: gottlieb <at> nyu.edu, 
 "20552-done <at> debbugs.gnu.org" <20552-done <at> debbugs.gnu.org>
Subject: Re: bug#20552: 24.4; cc
Date: Wed, 20 May 2015 11:50:35 +0200

Bug closed.

Thanks, martin

Previous Next

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