* bug#20552: 24.4; cc @ 2015-05-11 20:10 gottlieb 2015-05-12 9:36 ` martin rudalics 0 siblings, 1 reply; 11+ messages in thread From: gottlieb @ 2015-05-11 20:10 UTC (permalink / raw) To: 20552 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)) ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#20552: 24.4; cc 2015-05-11 20:10 bug#20552: 24.4; cc gottlieb @ 2015-05-12 9:36 ` martin rudalics [not found] ` <87zj5aq8ol.fsf@nyu.edu> 0 siblings, 1 reply; 11+ messages in thread From: martin rudalics @ 2015-05-12 9:36 UTC (permalink / raw) To: gottlieb, 20552 > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <87zj5aq8ol.fsf@nyu.edu>]
* bug#20552: 24.4; cc [not found] ` <87zj5aq8ol.fsf@nyu.edu> @ 2015-05-13 7:37 ` martin rudalics 2015-05-13 13:33 ` gottlieb 0 siblings, 1 reply; 11+ messages in thread From: martin rudalics @ 2015-05-13 7:37 UTC (permalink / raw) To: gottlieb, 20552@debbugs.gnu.org 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#20552: 24.4; cc 2015-05-13 7:37 ` martin rudalics @ 2015-05-13 13:33 ` gottlieb 2015-05-13 13:40 ` gottlieb 2015-05-14 10:13 ` martin rudalics 0 siblings, 2 replies; 11+ messages in thread From: gottlieb @ 2015-05-13 13:33 UTC (permalink / raw) To: martin rudalics; +Cc: 20552@debbugs.gnu.org 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#20552: 24.4; cc 2015-05-13 13:33 ` gottlieb @ 2015-05-13 13:40 ` gottlieb 2015-05-14 10:13 ` martin rudalics 1 sibling, 0 replies; 11+ messages in thread From: gottlieb @ 2015-05-13 13:40 UTC (permalink / raw) To: martin rudalics; +Cc: 20552@debbugs.gnu.org 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#20552: 24.4; cc 2015-05-13 13:33 ` gottlieb 2015-05-13 13:40 ` gottlieb @ 2015-05-14 10:13 ` martin rudalics 2015-05-14 20:33 ` gottlieb 2015-05-14 20:58 ` gottlieb 1 sibling, 2 replies; 11+ messages in thread From: martin rudalics @ 2015-05-14 10:13 UTC (permalink / raw) To: gottlieb; +Cc: 20552@debbugs.gnu.org > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#20552: 24.4; cc 2015-05-14 10:13 ` martin rudalics @ 2015-05-14 20:33 ` gottlieb 2015-05-15 16:44 ` martin rudalics 2015-05-14 20:58 ` gottlieb 1 sibling, 1 reply; 11+ messages in thread From: gottlieb @ 2015-05-14 20:33 UTC (permalink / raw) To: martin rudalics; +Cc: 20552@debbugs.gnu.org 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#20552: 24.4; cc 2015-05-14 20:33 ` gottlieb @ 2015-05-15 16:44 ` martin rudalics [not found] ` <87twvdn4tm.fsf@nyu.edu> 0 siblings, 1 reply; 11+ messages in thread From: martin rudalics @ 2015-05-15 16:44 UTC (permalink / raw) To: gottlieb; +Cc: 20552@debbugs.gnu.org > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <87twvdn4tm.fsf@nyu.edu>]
* bug#20552: 24.4; cc [not found] ` <87twvdn4tm.fsf@nyu.edu> @ 2015-05-19 9:42 ` martin rudalics [not found] ` <87r3qcodz4.fsf@nyu.edu> 0 siblings, 1 reply; 11+ messages in thread From: martin rudalics @ 2015-05-19 9:42 UTC (permalink / raw) To: gottlieb, 20552@debbugs.gnu.org >> 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <87r3qcodz4.fsf@nyu.edu>]
* bug#20552: 24.4; cc [not found] ` <87r3qcodz4.fsf@nyu.edu> @ 2015-05-20 9:50 ` martin rudalics 0 siblings, 0 replies; 11+ messages in thread From: martin rudalics @ 2015-05-20 9:50 UTC (permalink / raw) To: gottlieb, 20552-done@debbugs.gnu.org Bug closed. Thanks, martin ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#20552: 24.4; cc 2015-05-14 10:13 ` martin rudalics 2015-05-14 20:33 ` gottlieb @ 2015-05-14 20:58 ` gottlieb 1 sibling, 0 replies; 11+ messages in thread From: gottlieb @ 2015-05-14 20:58 UTC (permalink / raw) To: martin rudalics; +Cc: 20552@debbugs.gnu.org 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2015-05-20 9:50 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-05-11 20:10 bug#20552: 24.4; cc gottlieb
2015-05-12 9:36 ` martin rudalics
[not found] ` <87zj5aq8ol.fsf@nyu.edu>
2015-05-13 7:37 ` martin rudalics
2015-05-13 13:33 ` gottlieb
2015-05-13 13:40 ` gottlieb
2015-05-14 10:13 ` martin rudalics
2015-05-14 20:33 ` gottlieb
2015-05-15 16:44 ` martin rudalics
[not found] ` <87twvdn4tm.fsf@nyu.edu>
2015-05-19 9:42 ` martin rudalics
[not found] ` <87r3qcodz4.fsf@nyu.edu>
2015-05-20 9:50 ` martin rudalics
2015-05-14 20:58 ` gottlieb
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).