bug#11113: 23.3; Access to the mini-buffer in auctex mode triggers window resize in KDE (Kwin)

bug#11113: 23.3; Access to the mini-buffer in auctex mode triggers window resize in KDE (Kwin)

[Jorge Adriano Branco Aires]

Problem:
Emacs+Auctex doesn't work properly in KDE (or more precisely kwin).
Any access to the mini-buffer in auctex mode triggers window resize,
making it smaller.

Current work around:
There is a known workaround right now, which is to set kwin to disobey
geometry restrictions for emacs, in its advanced settings. But of
course most users will have no idea what to do when affected by this
strange behaviour.

Related:
KDE bug report (set to RESOLVED FIXED of KDE's end).
https://bugs.kde.org/show_bug.cgi?id=252314

J.A.

-------------

In GNU Emacs 23.3.1 (x86_64-suse-linux-gnu, GTK+ Version 2.24.7)
 of 2011-10-30 on build17
Windowing system distributor `The X.Org Foundation', version 11.0.11004000
configured using `configure  '--with-pop' '--without-hesiod'
'--with-kerberos' '--with-kerberos5' '--with-xim'
'--enable-autodepend' '--prefix=/usr' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--datadir=/usr/share'
'--localstatedir=/var' '--sharedstatedir=/var/lib'
'--libexecdir=/usr/lib' '--with-x' '--with-sound' '--with-sync-input'
'--with-xpm' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png'
'--with-rsvg' '--with-dbus' '--without-gpm' '--with-x-toolkit=gtk'
'--x-includes=/usr/include' '--x-libraries=/usr/lib64:/usr/share/X11'
'--with-xft' '--with-libotf' '--with-m17n-flt'
'--build=x86_64-suse-linux' 'build_alias=x86_64-suse-linux'
'CFLAGS=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2
-fstack-protector -funwind-tables -fasynchronous-unwind-tables -g
-D_GNU_SOURCE -std=gnu89 -pipe -Wno-pointer-sign -Wno-unused-variable
-Wno-unused-label -Wno-unprototyped-calls -fno-optimize-sibling-calls
-DSYSTEM_PURESIZE_EXTRA=55000 	 -DSITELOAD_PURESIZE_EXTRA=10000 '
'LDFLAGS=-Wl,-O2 -Wl,--hash-size=65521''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  show-paren-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-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 <tab> r <tab> <return>

Recent messages:
Loading /home/jadrian/.cabal/share/Agda-2.3.0.1/emacs-mode/agda2.el
(source)...done
Loading /usr/share/emacs/site-lisp/haskellmode-emacs/haskell-site-file.el
(source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
/usr/share/emacs/site-lisp/ruby-mode hides
/usr/share/emacs/23.3/lisp/progmodes/ruby-mode

Features:
(shadow sort mail-extr message idna byte-opt sendmail ecomplete rfc822
mml mml-sec password-cache mm-decode mm-bodies mm-encode mailcap
mail-parse rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader
gnus-util netrc time-date mm-util mail-prsvr gmm-utils wid-edit
mailheader canlock sha1 hex-util hashcash mail-utils warnings emacsbug
help-mode view font-latex bytecomp byte-compile tex regexp-opt advice
help-fns advice-preload easymenu scala-mode-auto agda2 xfonts rmailgen
paren mouse-sel thingatpt preview-latex tex-site auto-loads ispell lpr
disp-table tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win
x-dnd font-setting tool-bar dnd fontset image fringe lisp-mode register
page menu-bar rfn-eshadow timer select scroll-bar mldrag 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 loaddefs button
minibuffer faces cus-face files text-properties overlay md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind system-font-setting
font-render-setting gtk x-toolkit x multi-tty emacs)

bug#11113: 23.3; Access to the mini-buffer in auctex mode triggers window resize in KDE (Kwin)

[Stefan Kangas]

Jorge Adriano Branco Aires <jorge.adriano@gmail.com> writes:

> Problem:
> Emacs+Auctex doesn't work properly in KDE (or more precisely kwin).
> Any access to the mini-buffer in auctex mode triggers window resize,
> making it smaller.
>
> Current work around:
> There is a known workaround right now, which is to set kwin to disobey
> geometry restrictions for emacs, in its advanced settings. But of
> course most users will have no idea what to do when affected by this
> strange behaviour.
>
> Related:
> KDE bug report (set to RESOLVED FIXED of KDE's end).
> https://bugs.kde.org/show_bug.cgi?id=252314

If I understand you correctly, this is a bug in KDE which has since
been fixed?

If this is a bug in Emacs, is this still an issue on a modern versions
of Emacs?

Best regards,
Stefan Kangas

bug#11113: 23.3; Access to the mini-buffer in auctex mode triggers window resize in KDE (Kwin)

[Stefan Kangas]

Stefan Kangas <stefan@marxist.se> writes:

> Jorge Adriano Branco Aires <jorge.adriano@gmail.com> writes:
>
>> Problem:
>> Emacs+Auctex doesn't work properly in KDE (or more precisely kwin).
>> Any access to the mini-buffer in auctex mode triggers window resize,
>> making it smaller.
>>
>> Current work around:
>> There is a known workaround right now, which is to set kwin to disobey
>> geometry restrictions for emacs, in its advanced settings. But of
>> course most users will have no idea what to do when affected by this
>> strange behaviour.
>>
>> Related:
>> KDE bug report (set to RESOLVED FIXED of KDE's end).
>> https://bugs.kde.org/show_bug.cgi?id=252314
>
> If I understand you correctly, this is a bug in KDE which has since
> been fixed?
>
> If this is a bug in Emacs, is this still an issue on a modern versions
> of Emacs?

More information was requested, but none was given within 4 weeks, so
I'm closing this bug.  If this is still an issue, please reply to this
email (use "Reply to all" in your email client) and we can reopen the
bug report.

Best regards,
Stefan Kangas

bug#11113: [Tristan Miller] Re: bug#11113: 23.3; Access to the mini-buffer in auctex mode triggers window resize in KDE (Kwin)

[Stefan Kangas]

-------------------- Start of forwarded message --------------------
Date: Fri, 7 Jun 2024 12:34:41 -0500
Subject: Re: bug#11113: 23.3; Access to the mini-buffer in auctex mode
 triggers window resize in KDE (Kwin)
To: Stefan Kangas <stefan@marxist.se>,
 Jorge Adriano Branco Aires <jorge.adriano@gmail.com>
Cc: 11113-done@debbugs.gnu.org, thomas.luebking@gmail.com
From: Tristan Miller <tristan@logological.org>

Greetings.

On 2019-12-01 01:51, Stefan Kangas wrote:
> More information was requested, but none was given within 4 weeks, so
> I'm closing this bug.  If this is still an issue, please reply to this
> email (use "Reply to all" in your email client) and we can reopen the
> bug report.

This issue is still reproducible for me on an openSUSE Leap 15.5 system
running the following:

Emacs 29.3
KDE Plasma 5.27.9
KDE Frameworks 5.103.0
Qt 5.15.8

As noted upthread, the problem was previously reported as a kwin bug on
the KDE issue tracker at <https://bugs.kde.org/show_bug.cgi?id=252314>.
A fix to kwin was applied in 2011, nearly immediately followed by a
regression, followed by another fix in 2013, followed by another
regression in 2020.  I have been able to reproduce the problem
consistently since 2020.  Today the KDE developers have decided that the
bug is a problem with Emacs, not kwin, and have closed their bug report.

Could an Emacs developer please have a look at the KDE bug report and
determine whether there's anything in Emacs itself that can or should be
fixed?  I can provide further information if necessary and/or help test
a fix.

Regards,
Tristan

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                   Tristan Miller
Free Software developer, ferret herder, logologist
              https://logological.org/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-------------------- End of forwarded message --------------------

bug#11113: [Tristan Miller] Re: bug#11113: 23.3; Access to the mini-buffer in auctex mode triggers window resize in KDE (Kwin)

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas <stefankangas@gmail.com> writes:

> As noted upthread, the problem was previously reported as a kwin bug on
> the KDE issue tracker at <https://bugs.kde.org/show_bug.cgi?id=252314>.
> A fix to kwin was applied in 2011, nearly immediately followed by a
> regression, followed by another fix in 2013, followed by another
> regression in 2020.  I have been able to reproduce the problem
> consistently since 2020.  Today the KDE developers have decided that the
> bug is a problem with Emacs, not kwin, and have closed their bug report.
>
> Could an Emacs developer please have a look at the KDE bug report and
> determine whether there's anything in Emacs itself that can or should be
> fixed?  I can provide further information if necessary and/or help test
> a fix.

A window manager's creatively interpreting (read: failing to observe)
geometry hints specified by a client is deficient behavior on the window
manager's part, so the least they could have done should have been
declining to play "shift the blame."  As enforcing window management
properties otherwise than the client requested was a KWin bug then, so
it is now, whether they admit it or not, and until they leave their high
pedestal Emacs users might easily circumvent it by configuring
`frame-resize-pixelwise' to t.

bug#11113: [Tristan Miller] Re: bug#11113: 23.3; Access to the mini-buffer in auctex mode triggers window resize in KDE (Kwin)

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu <luangruo@yahoo.com> writes:

> A window manager's creatively interpreting (read: failing to observe)
> geometry hints specified by a client is deficient behavior on the window
> manager's part, so the least they could have done should have been
> declining to play "shift the blame."  As enforcing window management
> properties otherwise than the client requested was a KWin bug then, so
> it is now, whether they admit it or not, and until they leave their high
> pedestal Emacs users might easily circumvent it by configuring
> `frame-resize-pixelwise' to t.

BTW, it might interest them to know that the wm-spec defines
maximization in quite express terms:

  Maximization is a very old feature of window managers. There was even
  a ZoomedState in early ICCCM drafts.  Maximizing a window should give
  it as much of the screen area as possible (this may not be the full
     --------------------------------------
  screen area, but only a smaller 'workarea', since the window manager
  may have reserved certain areas for other windows).  A window manager
  is expected to remember the geometry of a maximized window and restore
  it upon de-maximization.  Modern window managers typically allow
  separate horizontal and vertical maximization.

Emphasis mine.  By any reasonable interpretation, the window manager
should disregard resize increments in resizing maximized windows, and
indeed as far as I'm aware, KWin's design choices have been emulated by
no other conforming window manager.

bug#11113: 23.3; Access to the mini-buffer in auctex mode triggers window resize in KDE (Kwin)

[Stefan Kangas]

[Fixed the subject here to not include Tristan's name.  It was added by
me on accident; sorry.]

Po Lu <luangruo@yahoo.com> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> A window manager's creatively interpreting (read: failing to observe)
>> geometry hints specified by a client is deficient behavior on the window
>> manager's part, so the least they could have done should have been
>> declining to play "shift the blame."  As enforcing window management
>> properties otherwise than the client requested was a KWin bug then, so
>> it is now, whether they admit it or not, and until they leave their high
>> pedestal Emacs users might easily circumvent it by configuring
>> `frame-resize-pixelwise' to t.
>
> BTW, it might interest them to know that the wm-spec defines
> maximization in quite express terms:
>
>   Maximization is a very old feature of window managers. There was even
>   a ZoomedState in early ICCCM drafts.  Maximizing a window should give
>   it as much of the screen area as possible (this may not be the full
>      --------------------------------------
>   screen area, but only a smaller 'workarea', since the window manager
>   may have reserved certain areas for other windows).  A window manager
>   is expected to remember the geometry of a maximized window and restore
>   it upon de-maximization.  Modern window managers typically allow
>   separate horizontal and vertical maximization.
>
> Emphasis mine.  By any reasonable interpretation, the window manager
> should disregard resize increments in resizing maximized windows, and
> indeed as far as I'm aware, KWin's design choices have been emulated by
> no other conforming window manager.

Thanks, could someone please contact them about this?

Does this affect all KDE users?  If so, that sounds like a pretty nasty
bug.  Is there any feasible workaround that we could do on our end?

bug#11113: 23.3; Access to the mini-buffer in auctex mode triggers window resize in KDE (Kwin)

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas <stefankangas@gmail.com> writes:

> Does this affect all KDE users?

They're the only judges of that.

> If so, that sounds like a pretty nasty bug.  Is there any feasible
> workaround that we could do on our end?

No, but KDE users might easily apply:

  (setq frame-resize-pixelwise t)

in their early initialization files.

bug#11113: 23.3; Access to the mini-buffer in auctex mode triggers window resize in KDE (Kwin)

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Does this affect all KDE users?
>
> They're the only judges of that.

Sorry, I don't think I understand what you mean here.

>> If so, that sounds like a pretty nasty bug.  Is there any feasible
>> workaround that we could do on our end?
>
> No, but KDE users might easily apply:
>
>   (setq frame-resize-pixelwise t)
>
> in their early initialization files.

Assuming that this does affect all KDE users, is there any way to detect
that KDE is running and then do that for them?

bug#11113: 23.3; Access to the mini-buffer in auctex mode triggers window resize in KDE (Kwin)

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas <stefankangas@gmail.com> writes:

> Sorry, I don't think I understand what you mean here.

I meant to say that the severity of the problem is to be judged only by
KDE users, not me.

> Assuming that this does affect all KDE users, is there any way to detect
> that KDE is running and then do that for them?

If there were, still I would be very averse to implementing such a
questionable workaround in Emacs.

bug#11113: 23.3; Access to the mini-buffer in auctex mode triggers window resize in KDE (Kwin)

[Tristan Miller via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Greetings.

On 2024-06-08 08:46, Po Lu wrote:
> A window manager's creatively interpreting (read: failing to observe)
> geometry hints specified by a client is deficient behavior on the window
> manager's part, so the least they could have done should have been
> declining to play "shift the blame."  As enforcing window management
> properties otherwise than the client requested was a KWin bug then, so
> it is now, whether they admit it or not, and until they leave their high
> pedestal Emacs users might easily circumvent it by configuring
> `frame-resize-pixelwise' to t.

Well, let's not be so hasty to attribute to arrogance what might more 
easily be explained by ignorance or negligence.  I'll pass on the 
information you provided about the specification to the KDE bug report 
and maybe they will reconsider the matter.  In the meantime, I can 
report that:

1) The suggested workaround of (setq frame-resize-pixelwise t) works for me.

2) So far I haven't been able to reproduce the problem with KDE Plasma 
6, though I haven't tested exhaustively.  (I had reported the problem 
for Plasma 5.27, which according to 
<https://community.kde.org/Schedules/Plasma_5> is still supported, and 
is still the version many GNU/Linux distributions are shipping.)

Regards,
Tristan

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                   Tristan Miller
Free Software developer, ferret herder, logologist
              https://logological.org/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-