sounds related to bug #158974

Still present in KDE 4.5.2

Also the window is resized whenever we run a command or change buffer. This makes working with emacs nearly impossible for many tasks.

Trying to set the application to always be maximized does not work (it's resized anyway and still thinks it's maximized). Fixing its geometry keeps it the same size but then you cannot see the bottom part where you input commands for some reason. 

Something is very wrong here.

while emacs ("i'm an OS + WM in a text editor") unsets it's maximization state here*, the resize does not happen on buffer closing.

The strict geometry only applies to maximized windows (whether this is sensible i don't know. i geuss it should at least be mentioned in the dialog, though...)
Since emacs thinks it has to play WM and unset the maximization state as well as internally recalculates and resets its size, this fails. (commenting lines 1502 & 1504 in geometry.cpp + forcing obey geometry (UNchecked) and forcing to ignore resize requests (UNchecked) will allow you to set specific sizes for emacs, still it tries to unmaximize itself unless brought into "proper" dimensions...)

I think eg. openbox goes for a longer fight with emacs (resizing this window is incredibly slow and that cannot be due to the clients content)

*GNU Emacs 23.2.1 (i686-pc-linux-gnu, GTK+ Version 2.20.1) of 2010-05-08 on pidsley.hoetzel.info

Important Note:

This happens when editing LaTeX files! Moving from latex-mode to text-mode and it suddenly works fine.

http://svn.reviewboard.kde.org/r/5871/

SVN commit 1208120 by luebking:

adjust strict geometry policies
http://svn.reviewboard.kde.org/r/5871/
BUG: 158974
CCBUG: 252314

@Jorge:
please see the request description and check whether this allows you to fix your bug
in case, don't forget to close it ;-)


 M  +6 -7      geometry.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1208120

Hi Thomas,

> @Jorge:
> please see the request description and check whether this allows you to fix
> your bug
> in case, don't forget to close it ;-)

The 3rd item in the description of the patch seems to describe the current issue, so hopefully it does fix it :) Will this be present in KDE 4.6 RC1? If so I could test it when released and then close the report. 

Thank you!

> 
> 
>  M  +6 -7      geometry.cpp  
> 
> 
> WebSVN link: http://websvn.kde.org/?view=rev&revision=1208120

> Will this be present in KDE 4.6 RC1?
Yes. (tagged tomorrow ;-)

(In reply to comment #8)
> > Will this be present in KDE 4.6 RC1?
> Yes. (tagged tomorrow ;-)

Great!

(In reply to comment #8)
> > Will this be present in KDE 4.6 RC1?
> Yes. (tagged tomorrow ;-)

Using RC1. It does fix the problem! :)

It is not perfect. 
- when accessing the command input region on the bottom emacs (e.g. opening a file) the bottom of the window goes up a tiny bit, but then comes down. It does look weird and gets a bit annoying as you're entering lots of commands to see the window go up and down. 

- maximization leaves quite some space between the bottom of emacs and the taskbar. It doesn't look maximized at all. 

- maximization button on window, is not on maximized state after being pressed (it should show restore, but keeps showing maximize)

So yeap this can be closed, but it does need a bit more work :S
Should I make a new report? 

Thanks again!
J.A.

there's another bug on maximizing emacs/gvim which should have caught by this fix as well: bug #158974 (and i could actually test that - on gvim though)

a) is this still related to emacs' latex mode?
b) did you enforce to disobey emacs geometry?
(kcmshell4 kwinrules, new rule, detect emacs, "workarounds", check "strictly obey geometry", set it to "force", do NOT check the related checkbox.

a) not really, any access to the command input area triggers this
b) nope

b) should I?

yes, like pointed in comment "c" in the review request
otherwise kwin repects emacs size increment values what leads to
a) it cannot be maximized (because the available screenarea likely won't be a multiple of 9x19)
b) emacs invalid self resize being "fixed" by kwin to match the increment request

Ah got it. I had to downgrade meanwhile. I'll give that a shot later.

Any access to the mini-buffer in auctex mode still triggers this in 4.6.0, regardless of the "strictly obey geometry" setting. I've found that only disabling the tool-bar with (tool-bar-mode -1) in .emacs makes this stop.

(In reply to comment #16)
> Any access to the mini-buffer in auctex mode still triggers this in 4.6.0,
triggers "what" - "unmaximizability" or the "judder"

to test this i'll need a step-by-step instruction how to enter "auctex" mode, find the "mini-buffer" and "access" it - preferably w/o installing a full blown TeX environment.

(In reply to comment #17)
> (In reply to comment #16)
> > Any access to the mini-buffer in auctex mode still triggers this in 4.6.0,
> triggers "what" - "unmaximizability" or the "judder"
> 
> to test this i'll need a step-by-step instruction how to enter "auctex" mode,
> find the "mini-buffer" and "access" it - preferably w/o installing a full blown
> TeX environment.

You don't need a TeX environment at all. Just emacs and the auctex mode. 
In opensuse auctex is provided by: emacs-auctex-11.86-15.21.noarch

Auctex should be active by default whenever you edit a .tex file. 

To access the minibuffer you can use for instance
ctrl+c  ctrl+s
  or
ctrl+c  ctrl+e

If I maximize only the height of the window, not the width, entering the
mini-buffer makes the window height shorter by approximately one line. The
"strictly obey geometry" setting fixes this only for the fully maximized
window. 

To enter auctex, you need to open a *.tex file. One can access the mini-buffer
with Alt-X, and exit it with Ctrl-G.

By the way, what is the purpose of the checkbox on the right of the workarounds
tab?

Thanks.

auctex -> texlive => 320MB... =\

Overriding to "strictly obey geometry" does only allow you to enter the maximized mode otherwise the client would require to be sized in n*a:m*b | a,b != 1 - what inherently prevents arbitrary "maximized" sizes.
Also in unmaximized mode it will prevent the window to "judder", ie. emacs resizes itself, kwin fixes that size according to emacs increment values (a,b), emacs re-resizes to what it believes is right...

Vertical maximization is not "really" maximization - it would however be possible to treat it the same (ie. if maximized in any direction, the window looses the permission to change the size at all), but we should wait for the results on this bug #265568

nB.: The client (emacs) is broken - it should not attempt to "refix" its size at all, because it is NOT a window manager, but instead expect that the WM will handle the clients properties right (or attempts to know better for user requests)

(In reply to comment #20)
> auctex -> texlive => 320MB... =\

I think you can safely ignore them. Of course some auctex commands on emacs won't work, but for testing purposes it's fine. If you check the rpm contents, it's just a bunch of .el for emacs and documentation.

Git commit 44795854aa522c323e5fa1d9600bb63cb5aac02d by Thomas L��bking.
Committed on 08/03/2011 at 21:33.
Pushed by luebking into branch 'master'.

Unlink maximization state from actual geometry

Since clients with restricted geometry now cannot cover the entire screen by default it was necessary to unlink the state from the actual geometry to re-provide the "restore" feature.
The patch also extends the protection of the maximized state to unilateral maximizations (emacs issue)

BUG: 265568
BUG: 252314
CCBUG: 252255
review request https://git.reviewboard.kde.org/r/100606/

M  +0    -1    kwin/client.cpp     
M  +0    -1    kwin/client.h     
M  +13   -44   kwin/geometry.cpp     

http://commits.kde.org/kde-workspace/44795854aa522c323e5fa1d9600bb63cb5aac02d

There is a regression in KDE 4.7 Beta 1. Again emacs resizes itself whenever I access the minibuffer (thus making it impossible for me to work in KDE). Please don't let this into 4.7.0...

Can you please elaborate on this?

- maximization state
- geometry rule

I've installed auctex, but ctrl+c ctrl+s or ctrl+c, ctrl+e don't much but inserting random lines (usually /end - i assume ctrl+c is copy a line?)

However while being vertically maximized, emacs should not be able to vertically resize at all (but it can explicitly drop out of maximization and that's no more "fixable" but by adding a "ignore all client requests" rule...)

Sorry for the delay. I think the spam filter is eating my bugs.kde.org emails. 
(In reply to comment #24)
> Can you please elaborate on this?


> - maximization state

Ahh very good point. Now it only happens when the window is maximised. 

To test it, 
- open a .tex file 
- access the mini-buffer: alt+x 
- get out of the mini-buffer: ctrl+g

The window will resize vertically (bottom part up), but the state is kept as maximised. So if you continue accessing the mini-buffer it keeps resizing.

If the window is not maximised, the resize won't happen. 


> - geometry rule

If you mean the advances kwin options for the application, I have none set. 

> I've installed auctex, but ctrl+c ctrl+s or ctrl+c, ctrl+e don't much but
> inserting random lines (usually /end - i assume ctrl+c is copy a line?)

Mini-buffer access is typically done with alt+x, which allows you to input a command. Another way, and how I usually bump into this bug, is ctrl+c ctrl+c, which with auctex is used to compile your latex document. 


> However while being vertically maximized, emacs should not be able to
> vertically resize at all (but it can explicitly drop out of maximization and
> that's no more "fixable" but by adding a "ignore all client requests" rule...)

The window state is maximised (judging for the buttons) even after resize.

Hope this helps.

Ahh, the "mini buffer" is the command interpreter (like pressing ":" in vim)

However, this does not happen at all here and actually can (in theory) not happen, since configure requests (attempts from the window to resize itself) are (directionwise) completely ignored while the window is maximized (ie. a vertically maximized window can resize itself horizontally _only_) - so as long as the window says "i'm maximized" it cannot resize itself.

What however /does/ happen is that without a rule a window with a baseincrement (minimal resize value) > (1,1) will /not/ cover the entire screen area while it's maximized.

Do you compile from sources? (so you could inject some debug output)

About your mail:
your account usually/often/always spams "i'm away" messages when i post to this bug. No idea whether this is related to your issue. *shrug*

> Ahh, the "mini buffer" is the command interpreter (like pressing ":" in vim)

Yes.

> However, this does not happen at all here and actually can (in theory) not
> happen, since configure requests (attempts from the window to resize itself)
> are (directionwise) completely ignored while the window is maximized (ie. a
> vertically maximized window can resize itself horizontally _only_) - so as long
> as the window says "i'm maximized" it cannot resize itself.
> 
> What however /does/ happen is that without a rule a window with a baseincrement
> (minimal resize value) > (1,1) will /not/ cover the entire screen area while
> it's maximized.
> 
> Do you compile from sources? (so you could inject some debug output)

Not really. I'm using openSUSE's RPM's (unstable for 11.3). 

> About your mail:
> your account usually/often/always spams "i'm away" messages when i post to this
> bug. No idea whether this is related to your issue. *shrug*

Sorry about that, and thanks for letting me know. I don't/can't set the notifications myself (sys admin does that)... I knew it was on, but expected it to have a sane default, e.g. not to send more than once to the same recipient. I'll ask for that to be fixed or removed completely. 

Is there a way for me to change the email associated with my account? I could just open another account, but I'd like to keep the history.

> Is there a way for me to change the email associated with my account? I could
> just open another account, but I'd like to keep the history.

Scroll up, left side: "My Account" is the last item ;-)

Can you try a rule on emacs that enforces the (at least) vertical maximization state?
What if you disobey strict geometry honoration? (The window should then cover the entire screen when maximized)

> Scroll up, left side: "My Account" is the last item ;-)

Ah thanks! how did I miss that...


> Can you try a rule on emacs that enforces the (at least) vertical maximization
> state?

Used "maximise vertically - force - yes"
No effect. 

> What if you disobey strict geometry honoration? (The window should then cover
> the entire screen when maximized)

Used "obey geometry restrictions - force - no"
Worked like a charm. The resizing was gone. Plus emacs actually maximises better - i.e. before there was always a bit of space between the without and the bottom panel, now there is no gap.

(...) i.e. before there was always a bit of space between _emacs_ and
the bottom panel, now there is no gap.

As mentioned ;-)
Without the setting emacs cannot "really" maximize because it cannot cover an arbitrary region of the screen because it asks to grow in non minimal steps.

This is expected and ok, but that should not impact whether the client can resize itself or not. (and does not here) *shrug*

Is there a way to inspect the sources of OpenSuSE (with pot. patches)?

> Is there a way to inspect the sources of OpenSuSE (with pot. patches)?

Well sources should be here, I guess...
http://download.opensuse.org/repositories/KDE:/Unstable:/SC/openSUSE_11.3/src/

But I have no idea what the pot.(In reply to comment #31)
> As mentioned ;-)
> Without the setting emacs cannot "really" maximize because it cannot cover an
> arbitrary region of the screen because it asks to grow in non minimal steps.

Right.

> This is expected and ok, but that should not impact whether the client can
> resize itself or not. (and does not here) *shrug*
> 
> Is there a way to inspect the sources of OpenSuSE (with pot. patches)?

Well Source RPMs should be here:

(KDE Unstable)  
http://download.opensuse.org/repositories/KDE:/Unstable:/SC/openSUSE_11.3/src/

(Editors)
http://download.opensuse.org/repositories/editors/openSUSE_11.3/src/

Would that do?

Try this link for fast access to the patches:
https://build.opensuse.org/package/files?package=emacs&project=openSUSE%3A11.4

Thanks, I've checked the kwin patches from the srpm and they don't cover this at all.
I doubt they're added a patch to emacs to unmaximize, resize and remaximize either (but i don't speak lisp) - so this is pretty weird.

Given it anyway used to work in 4.6.3 with the supporting rule only, I guess there's not /that/ much need to determine what's wrong with (emacs...) client self-resizing (on your side, it frankly doesn't happen here at all - sorry)

I'll ask to add some debug messages for the release.
Could you make a video?
(I /do/ believe you ;-) - but it might hint something)

> Could you make a video?
> (I /do/ believe you ;-) - but it might hint something)

Sure, there you go:
http://jorgeadriano.packagecloud.com/vidcap.mpeg

I still can observe this on openSuse 12.1 with KDE 4.7.2. 
Please fix it, this is very annoying.

Did you add a rule to disobey geometry restrictions for that window?
Otherwise emacs will attempt to fix it's aspect ratio and kwin will fix it back.

oh, thank you, with your advice it works good.
but this solution is not trivial at all...

I just reported it to Emacs. As it stands most people will either dump Emacs or KDE, rather than figuring our the advanced settings. 

Thomas, I cc'ed you the bug report, as I thought you may be interested in it. Plus all the technicalities really go over my head. Hope you don't mind.

Emacs bug report
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11113

As with others, I can reproduce the problem with recent-ish versions of KDE and emacs (KDE 4.9.5 and emacs-24.2-15.8.2 on openSUSE 12.2).  Please reopen this report.

Created attachment 77410 [details]
emacs rule

import the attached rule from the "kcmshell4 kwin" dialog.
If it fixes your issue (and you confirm that) we could add it as a default rule for 4.11 (i18n issues will prevent it from 4.10)

There is no module kwin for kcmshell4; I take it you meant kwinrules.  Anyway, importing that rule file worked (as did manually configuring kwin to disobey geometry restrictions as you suggested in Comment 37).

I note that your file has "wmclass=Emacs" whereas after importing the file, or after turning off geometry restrictions manually, kwinrulesrc has "wmclass=emacs".  Thought I'd mention this in case case sensitivity is an issue when directly writing to the rc file.

Git commit 65d333625ffacf39f3178011decc918affe1719b by Thomas Lübking.
Committed on 24/03/2013 at 19:13.
Pushed by luebking into branch 'master'.

turn "ignore geometry" forcerule into a setrule

and btw. replace legacy "ignoreposition" by "ignoregeometry"

this will allow to use "apply initially" as "force" used to act
(ignore position on placement) and "force" to prevent clients
from reconfiguring themselves (to not break a tabgroup or to just
not be annoying)
Related: bug 311720
REVIEW: 109691
FIXED-IN: 4.11

M  +3    -0    kwin/geometry.cpp
M  +5    -5    kwin/kcmkwin/kwinrules/ruleswidget.cpp
M  +1    -1    kwin/kcmkwin/kwinrules/ruleswidget.h
M  +21   -6    kwin/kcmkwin/kwinrules/ruleswidgetbase.ui
M  +1    -1    kwin/manage.cpp
M  +8    -19   kwin/rules.cpp
M  +4    -6    kwin/rules.h

http://commits.kde.org/kde-workspace/65d333625ffacf39f3178011decc918affe1719b

I think we may have hit a regression, as I can now reproduce this problem.  I am using the following on openSUSE Tumbleweed:

Emacs 27.1
KDE Plasma 5.19.4
KDE Frameworks 5.73.0
Qt 5.15.0

An easy way to reproduce the behaviour is to open any file with Emacs, press Ctrl+S to invoke the search function, type in some text to search for, and then hit Enter.  The Emacs window will then shrink vertically.

Some further details: I was not using any Special Window Settings or Special Application Settings to force vertical maximization.  (Such settings had not been necessary after this bug was fixed previously.)  But if I go ahead and add a Special Application Settings entry to always force vertical maximization, then the Emacs window shrinks anyway whenever I complete a search with Ctrl+S.  What's worse, it's no longer possible to adjust the vertical size of the window by dragging the window edge, and the maximize button is missing from the window title bar.  And even worse than that, there doesn't seem to be any way of removing the Special Applications Setting entry, since if I revisit the Special Applications Setting dialog, the entry is no longer listed at all!

On further testing, I can confirm that the workaround from Comment 37 still works.  Still, it would be nice if this weren't necessary.

Problem is still reproducible with openSUSE 15.4 with Emacs 28.2 and Plasma 5.24.4.  (And the workaround from Comment 37 still works.)

Even if this is reproducable in Plasma 6, this is an application bug, so I'm closing this now. If you can still reproduce the issue, please reopen the bug report for Emacs and have it be fixed in the application

I reopened the report on the Emacs bug tracker at <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11113>.  The developers there have examined this KDE bug report and consulted the Window Manager Specification at <https://www.freedesktop.org/wiki/Specifications/wm-spec/>, and in their determination, this is definitely a problem with KWin and not Emacs.  In their view, the problem is due to KWin's failure to properly observe geometry hints and enforce window management properties specified by the client. One of the comments on the Emacs bug is worth quoting at length here:

> […] 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.

These arguments seem well-supported and persuasive to me, so I am reopening this bug, which I am able to reproduce with the following setup:

Emacs 29.3
KDE Plasma 5.27.9
KDE Frameworks 5.103.0
Qt 5.15.8

I understand from <https://community.kde.org/Schedules/Plasma_5> that Plasma 5.27 is still under long-term support, and indeed is still shipped by many distributions, so it would be nice if a fix could be applied.

I have not (yet) been able to reproduce the issue with Plasma 6, but I have not tested extensively.

It's really weird to make nonsensical resize requests, requiring that the window manager ignores them for correct behavior... Either way though, Plasma 6.1 has the resize increments checks removed, so if that's the cause of the issue, it should be fixed: https://invent.kde.org/plasma/kwin/-/commit/2491fb1b2b02db5352bc02050298e7522d4dfaa5

Good to hear that there's a fix for Plasma 6.  Do I understand correctly, then, that there are no plans to apply a similar fix to the still-supported Plasma 5?  If so, then for the benefit of any affected users who are subscribed to or stumble across this bug report, a workaround that works for me is to add

    (setq frame-resize-pixelwise t)

early in the Emacs initialization files.

That depends mostly on if there will be another 5.27 release; right now it doesn't look like it

I'm afraid the problem is still reproducible for me with KWin 6.1.1.

The issue is still present in KWin 6.2.3. The workaround of putting `(setq frame-resize-pixelwise t)` in Emacs `init.el` helps.