bug#20552: 24.4; cc

bug#20552: 24.4; cc

[gottlieb]

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))

bug#20552: 24.4; cc

[martin rudalics]

 > 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

bug#20552: 24.4; cc

[martin rudalics]

Please don't remove <20552@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

bug#20552: 24.4; cc

[gottlieb]

On Wed, May 13 2015, martin rudalics wrote:

> Please don't remove <20552@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

bug#20552: 24.4; cc

[gottlieb]

On Wed, May 13 2015, martin rudalics wrote:

> Please don't remove <20552@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

bug#20552: 24.4; cc

[martin rudalics]

 > 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

bug#20552: 24.4; cc

[gottlieb]

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

bug#20552: 24.4; cc

[gottlieb]

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

bug#20552: 24.4; cc

[martin rudalics]

 > 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

bug#20552: 24.4; cc

[martin rudalics]

 >> 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

bug#20552: 24.4; cc

[martin rudalics]

Bug closed.

Thanks, martin