Bug 252314 - Emacs window resizes whenever a buffer is closed (openSUSE 11.3)
Summary: Emacs window resizes whenever a buffer is closed (openSUSE 11.3)
Status: REOPENED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: OpenSUSE Linux
: NOR normal with 1 vote (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-25 10:03 UTC by Jorge Adriano
Modified: 2020-09-07 18:45 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
emacs rule (189 bytes, text/plain)
2013-02-18 19:08 UTC, Thomas Lübking
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jorge Adriano 2010-09-25 10:03:39 UTC
Version:           unspecified (using KDE 4.5.1) 
OS:                Linux

In openSUSE 11.3, under KDE (using kwin), whenever I close an emacs buffer, the window shrinks! The bottom edge goes up quite a bit. This is really annoying since my window keeps getting tiny as I work.

I am using upstream release (KDE SC 4.5) for openSUSE 11.3. Not Factory. 

I can confirm  does not happen in openbox for instance. 
It also does not happen in openSUSE 11.2 using the equivalent repository though.

Reproducible: Always

Steps to Reproduce:
close emacs buffer

Actual Results:  
lower edge goes up 
window shrinks

Expected Results:  
window to stay the same size

OS: Linux (i686) release 2.6.34.7-0.3-desktop
Compiler: gcc
openSUSE 11.3
upstream release (KDE SC 4.5)
Comment 1 Thomas Lübking 2010-09-25 14:22:42 UTC
sounds related to bug #158974
Comment 2 Jorge Adriano 2010-10-06 10:09:26 UTC
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.
Comment 3 Thomas Lübking 2010-10-06 20:18:06 UTC
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
Comment 4 Jorge Adriano 2010-10-09 23:28:18 UTC
Important Note:

This happens when editing LaTeX files! Moving from latex-mode to text-mode and it suddenly works fine.
Comment 5 Thomas Lübking 2010-11-16 17:48:04 UTC
http://svn.reviewboard.kde.org/r/5871/
Comment 6 Thomas Lübking 2010-12-20 19:19:15 UTC
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
Comment 7 Jorge Adriano 2010-12-20 19:32:04 UTC
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
Comment 8 Thomas Lübking 2010-12-20 19:35:47 UTC
> Will this be present in KDE 4.6 RC1?
Yes. (tagged tomorrow ;-)
Comment 9 Jorge Adriano 2010-12-20 19:38:06 UTC
(In reply to comment #8)
> > Will this be present in KDE 4.6 RC1?
> Yes. (tagged tomorrow ;-)

Great!
Comment 10 Jorge Adriano 2010-12-23 12:35:22 UTC
(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.
Comment 11 Thomas Lübking 2010-12-23 14:09:56 UTC
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.
Comment 12 Jorge Adriano 2010-12-23 14:17:32 UTC
a) not really, any access to the command input area triggers this
b) nope
Comment 13 Jorge Adriano 2010-12-23 14:19:25 UTC
b) should I?
Comment 14 Thomas Lübking 2010-12-23 15:22:19 UTC
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
Comment 15 Jorge Adriano 2010-12-23 15:33:47 UTC
Ah got it. I had to downgrade meanwhile. I'll give that a shot later.
Comment 16 auxsvr 2011-02-04 16:24:48 UTC
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.
Comment 17 Thomas Lübking 2011-02-06 18:00:06 UTC
(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.
Comment 18 Jorge Adriano 2011-02-06 18:11:02 UTC
(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
Comment 19 auxsvr 2011-02-06 18:32:46 UTC
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.
Comment 20 Thomas Lübking 2011-02-06 19:05:52 UTC
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)
Comment 21 Jorge Adriano 2011-02-09 19:31:03 UTC
(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.
Comment 22 Thomas Lübking 2011-03-08 21:53:21 UTC
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
Comment 23 Jorge Adriano 2011-06-08 09:45:02 UTC
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...
Comment 24 Thomas Lübking 2011-06-08 16:24:12 UTC
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...)
Comment 25 Jorge Adriano 2011-06-12 13:01:38 UTC
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.
Comment 26 Thomas Lübking 2011-06-12 20:37:51 UTC
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*
Comment 27 Jorge Adriano 2011-06-12 20:50:40 UTC
> 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.
Comment 28 Thomas Lübking 2011-06-12 22:14:41 UTC
> 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)
Comment 29 Jorge Adriano 2011-06-12 22:38:07 UTC
> 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.
Comment 30 Jorge Adriano 2011-06-12 22:55:42 UTC
(...) i.e. before there was always a bit of space between _emacs_ and
the bottom panel, now there is no gap.
Comment 31 Thomas Lübking 2011-06-12 23:15:59 UTC
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)?
Comment 32 Jorge Adriano 2011-06-12 23:44:35 UTC
> 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?
Comment 33 auxsvr 2011-06-12 23:57:37 UTC
Try this link for fast access to the patches:
https://build.opensuse.org/package/files?package=emacs&project=openSUSE%3A11.4
Comment 34 Thomas Lübking 2011-06-13 16:44:47 UTC
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)
Comment 35 Jorge Adriano 2011-06-14 13:08:20 UTC
> Could you make a video?
> (I /do/ believe you ;-) - but it might hint something)

Sure, there you go:
http://jorgeadriano.packagecloud.com/vidcap.mpeg
Comment 36 nb 2012-03-28 13:39:36 UTC
I still can observe this on openSuse 12.1 with KDE 4.7.2. 
Please fix it, this is very annoying.
Comment 37 Thomas Lübking 2012-03-28 14:01:05 UTC
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.
Comment 38 nb 2012-03-28 15:29:03 UTC
oh, thank you, with your advice it works good.
but this solution is not trivial at all...
Comment 39 Jorge Adriano 2012-03-28 16:00:38 UTC
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.
Comment 40 Jorge Adriano 2012-03-28 17:47:51 UTC
Emacs bug report
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11113
Comment 41 Tristan Miller 2013-02-18 16:41:34 UTC
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.
Comment 42 Thomas Lübking 2013-02-18 19:08:15 UTC
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)
Comment 43 Tristan Miller 2013-02-19 11:44:50 UTC
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.
Comment 44 Thomas Lübking 2013-03-28 19:31:35 UTC
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
Comment 45 Tristan Miller 2020-08-24 13:59:01 UTC
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.
Comment 46 Tristan Miller 2020-08-24 14:07:40 UTC
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!
Comment 47 Tristan Miller 2020-09-07 18:45:54 UTC
On further testing, I can confirm that the workaround from Comment 37 still works.  Still, it would be nice if this weren't necessary.