bug#62535: 29.0.60; Wrong left, top values stored in .emacs.desktop file

all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed

* bug#62535: 29.0.60; Wrong left, top values stored in .emacs.desktop file
@ 2023-03-29 20:45 Claudio Grondi
  2023-03-30  5:43 ` Eli Zaretskii
  0 siblings, 1 reply; 6+ messages in thread
From: Claudio Grondi @ 2023-03-29 20:45 UTC (permalink / raw)
  To: 62535

From: Claudio <claudio.grondi@freenet.de>
To: bug-gnu-emacs@gnu.org
Subject: 29.0.60; Wrong left, top values stored in .emacs.desktop file

check out

https://emacs.stackexchange.com/questions/76547/bug-in-emacs-29-0-60-or-is-there-a-way-to-prevent-moving-the-emacs-position-on-r/

for details.

--text follows this line--

In GNU Emacs 29.0.60 (build 2, x86_64-pc-linux-gnu, GTK+ Version
  3.24.33, cairo version 1.16.0) of 2023-03-20 built on OoO
Repository revision: b7f03333551b2214f4d151d25d319e62402167c1
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Linux Mint 21

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11
XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
   value of $LC_MONETARY: C.UTF-8
   value of $LC_NUMERIC: C.UTF-8
   value of $LC_TIME: C.UTF-8
   value of $LANG: C.UTF-8
   value of $XMODIFIERS: @im=none
   locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
   smooth-scrolling-mode: t
   delete-selection-mode: t
   save-place-mode: t
   desktop-save-mode: t
   cua-mode: t
   tooltip-mode: t
   global-eldoc-mode: t
   eldoc-mode: t
   show-paren-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   tab-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   column-number-mode: t
   line-number-mode: t
   indent-tabs-mode: t
   transient-mark-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t

Load-path shadows:
/home/neo/.emacs.d/elpa/svg-1.1/svg hides 
/usr/local/share/emacs/29.0.60/lisp/svg
/home/neo/.emacs.d/elpa/cl-lib-0.7.1/cl-lib hides 
/usr/local/share/emacs/29.0.60/lisp/emacs-lisp/cl-lib

Features:
(shadow sort mail-extr emacsbug message yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util text-property-search mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date tab-line view
enriched disp-table facemenu nlinum linum smooth-scrolling advice
finder-inf cl-extra help-mode icons moe-light-theme delsel saveplace
desktop frameset cua-base cus-load smooth-scrolling-autoloads
moe-theme-autoloads system-packages-autoloads rainbow-mode-autoloads
paredit-autoloads info orderless-autoloads mines-autoloads
luwak-autoloads tiny-autoloads which-key-autoloads
edit-indirect-autoloads shell-command+-autoloads dired-du-autoloads
svg-autoloads svg-lib-autoloads smooth-scroll-autoloads
treeview-autoloads ascii-art-to-unicode-autoloads smartparens-autoloads
wgrep-autoloads good-scroll-autoloads sublimity-autoloads
nlinum-autoloads minimap-autoloads relint-autoloads xr-autoloads package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache
json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs
cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process emacs)

Memory information:
((conses 16 195593 11754)
  (symbols 48 13898 0)
  (strings 32 60902 2865)
  (string-bytes 1 1541936)
  (vectors 16 21123)
  (vector-slots 8 291624 13179)
  (floats 8 162 280)
  (intervals 56 728 0)
  (buffers 984 13))






^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#62535: 29.0.60; Wrong left, top values stored in .emacs.desktop file
  2023-03-29 20:45 bug#62535: 29.0.60; Wrong left, top values stored in .emacs.desktop file Claudio Grondi
@ 2023-03-30  5:43 ` Eli Zaretskii
  2023-03-30  6:17   ` Eli Zaretskii
  0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2023-03-30  5:43 UTC (permalink / raw)
  To: Claudio Grondi; +Cc: 62535

> Date: Wed, 29 Mar 2023 22:45:20 +0200
> From: Claudio Grondi <claudio.grondi@freenet.de>
> 
> From: Claudio <claudio.grondi@freenet.de>
> To: bug-gnu-emacs@gnu.org
> Subject: 29.0.60; Wrong left, top values stored in .emacs.desktop file
> 
> check out
> 
> https://emacs.stackexchange.com/questions/76547/bug-in-emacs-29-0-60-or-is-there-a-way-to-prevent-moving-the-emacs-position-on-r/
> 
> for details.

I can only say that I'm using desktop with multiple frames for the
last decade, and the frames are always restored in the same positions.
So I think this has at least something to do with the WM you are
using, where Emacs can only ask to position its frames, but has no
100% control on where they are actually positioned.

IOW, much more information and details are needed to reproduce this
and investigate the reasons, and eventually the problem could have no
solution, as long as you use the same WM.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#62535: 29.0.60; Wrong left, top values stored in .emacs.desktop file
  2023-03-30  5:43 ` Eli Zaretskii
@ 2023-03-30  6:17   ` Eli Zaretskii
       [not found]     ` <5ab7293c-e690-4121-bc3f-e77007eddf66@freenet.de>
  0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2023-03-30  6:17 UTC (permalink / raw)
  To: claudio.grondi; +Cc: 62535

> Cc: 62535@debbugs.gnu.org
> Date: Thu, 30 Mar 2023 08:43:05 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > https://emacs.stackexchange.com/questions/76547/bug-in-emacs-29-0-60-or-is-there-a-way-to-prevent-moving-the-emacs-position-on-r/
> > 
> > for details.
> 
> I can only say that I'm using desktop with multiple frames for the
> last decade, and the frames are always restored in the same positions.
> So I think this has at least something to do with the WM you are
> using, where Emacs can only ask to position its frames, but has no
> 100% control on where they are actually positioned.
> 
> IOW, much more information and details are needed to reproduce this
> and investigate the reasons, and eventually the problem could have no
> solution, as long as you use the same WM.

Btw, if you could test this in Emacs 28 or Emacs 27 and see if we have
some regression in Emacs 29, that would give us some lead to look for
the cause of the regression.





^ permalink raw reply	[flat|nested] 6+ messages in thread

[parent not found: <5ab7293c-e690-4121-bc3f-e77007eddf66@freenet.de>]

* bug#62535: 29.0.60; Wrong left, top values stored in .emacs.desktop file
       [not found]     ` <5ab7293c-e690-4121-bc3f-e77007eddf66@freenet.de>
@ 2023-03-30 10:42       ` Eli Zaretskii
  2023-03-30 18:11         ` Claudio Grondi
  0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2023-03-30 10:42 UTC (permalink / raw)
  To: Claudio Grondi; +Cc: 62535

[Please use Reply All to reply, so that the bug tracker is CC'ed.]

> Date: Thu, 30 Mar 2023 12:26:47 +0200
> From: Claudio Grondi <claudio.grondi@freenet.de>
> 
> 
> Have tested it with:
> 
> GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, 
> cairo version 1.16.0)
> 
> GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, 
> cairo version 1.16.0)
> 
> getting the same behavior.
> 
> 
> Why do you think it has something to do with WM?

Because it never happens to me here, and what other factor can explain
this?

> (you mean GNOME Window Manager? What is WM?

Yes, the Window Manager.

> The position of Emacs on the screen changes from restart to restart in 
> the .emacs.desktop file. Reading the position from the .desktop file 
> should give the value of the own position and if not changed is should 
> stay the same, doesn't it? Does Emacs 'ask the system' on exit for the 
> own position and update the .desktop file with it?

Positioning of frames is a function of the WM.  Emacs asks the WM to
position its frames, but the actual positioning is not up to us, at
least not with all the WMs out there.

> You mean if I run it on another version of Linux Mint Cinnamon it could 
> change? I'm using 21, but have still also 18.4 available.

It's worth trying.

Perhaps also try a build with another toolkit (like Lucid, not GTK),
it could also matter.  Although I thought this was supposed to be
solved in Emacs 29.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#62535: 29.0.60; Wrong left, top values stored in .emacs.desktop file
  2023-03-30 10:42       ` Eli Zaretskii
@ 2023-03-30 18:11         ` Claudio Grondi
  2023-03-30 18:15           ` Eli Zaretskii
  0 siblings, 1 reply; 6+ messages in thread
From: Claudio Grondi @ 2023-03-30 18:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 62535

Installed Emacs 27.1 lucid version. It hasn't shown the described 
problem and I have had the impression that the graphics comes up faster.

Then I have compiled Emacs 29.0.60 with lucid instead of gtk and was not 
able to reproduce the bug either.

I think I will stay with the lucid version.
I have been biased towards gtk because of python tkinter gui toolkit I 
have been already familiar with.

The drift left and up ... seem to happen during the initialization 
process of Emacs.
I am not 100% sure, but I have had the impression that there was an 
extremely short period of time where the window was at the right place 
and then moved a bit. Finally on exit Emacs saves then the changed 
position. In other words the problem appears to be repositioning the 
window while processing the .desktop and/or the other the initialization 
files.

If you can't reproduce this behavior from the .emacs.desktop file ... 
the reason for it will remain maybe a strange mystery (until it pops up 
again in another context in future Emacs versions).

On 3/30/23 12:42, Eli Zaretskii wrote:
> [Please use Reply All to reply, so that the bug tracker is CC'ed.]
>
>> Date: Thu, 30 Mar 2023 12:26:47 +0200
>> From: Claudio Grondi <claudio.grondi@freenet.de>
>>
>>
>> Have tested it with:
>>
>> GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30,
>> cairo version 1.16.0)
>>
>> GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33,
>> cairo version 1.16.0)
>>
>> getting the same behavior.
>>
>>
>> Why do you think it has something to do with WM?
> Because it never happens to me here, and what other factor can explain
> this?
>
>> (you mean GNOME Window Manager? What is WM?
> Yes, the Window Manager.
>
>> The position of Emacs on the screen changes from restart to restart in
>> the .emacs.desktop file. Reading the position from the .desktop file
>> should give the value of the own position and if not changed is should
>> stay the same, doesn't it? Does Emacs 'ask the system' on exit for the
>> own position and update the .desktop file with it?
> Positioning of frames is a function of the WM.  Emacs asks the WM to
> position its frames, but the actual positioning is not up to us, at
> least not with all the WMs out there.
>
>> You mean if I run it on another version of Linux Mint Cinnamon it could
>> change? I'm using 21, but have still also 18.4 available.
> It's worth trying.
>
> Perhaps also try a build with another toolkit (like Lucid, not GTK),
> it could also matter.  Although I thought this was supposed to be
> solved in Emacs 29.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#62535: 29.0.60; Wrong left, top values stored in .emacs.desktop file
  2023-03-30 18:11         ` Claudio Grondi
@ 2023-03-30 18:15           ` Eli Zaretskii
  0 siblings, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2023-03-30 18:15 UTC (permalink / raw)
  To: Claudio Grondi; +Cc: 62535

> Date: Thu, 30 Mar 2023 20:11:12 +0200
> Cc: 62535@debbugs.gnu.org
> From: Claudio Grondi <claudio.grondi@freenet.de>
> 
> 
> Installed Emacs 27.1 lucid version. It hasn't shown the described 
> problem and I have had the impression that the graphics comes up faster.
> 
> Then I have compiled Emacs 29.0.60 with lucid instead of gtk and was not 
> able to reproduce the bug either.
> 
> I think I will stay with the lucid version.
> I have been biased towards gtk because of python tkinter gui toolkit I 
> have been already familiar with.
> 
> The drift left and up ... seem to happen during the initialization 
> process of Emacs.
> I am not 100% sure, but I have had the impression that there was an 
> extremely short period of time where the window was at the right place 
> and then moved a bit. Finally on exit Emacs saves then the changed 
> position. In other words the problem appears to be repositioning the 
> window while processing the .desktop and/or the other the initialization 
> files.
> 
> If you can't reproduce this behavior from the .emacs.desktop file ... 
> the reason for it will remain maybe a strange mystery (until it pops up 
> again in another context in future Emacs versions).

Thanks.  Let's wait for someone else to chime in, if they have some
relevant info or comments.





^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2023-03-30 18:15 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-03-29 20:45 bug#62535: 29.0.60; Wrong left, top values stored in .emacs.desktop file Claudio Grondi
2023-03-30  5:43 ` Eli Zaretskii
2023-03-30  6:17   ` Eli Zaretskii
     [not found]     ` <5ab7293c-e690-4121-bc3f-e77007eddf66@freenet.de>
2023-03-30 10:42       ` Eli Zaretskii
2023-03-30 18:11         ` Claudio Grondi
2023-03-30 18:15           ` Eli Zaretskii

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.