Fix mouse cursor stuck if new window created after colgrow right window

[blogdron]

In the forum user kaldeon show me a bug https://www.linux.org.ru/forum/talks/17709316?cid=18077919

• video with bug http://0x0.st/Kb4J.30am.mp4 created by user kaldeon

Im read source code and found problem. If for new window coladd no have place in colomn, for previos bottom window do colgrow for make more space. Problem, after colgrow called winmousebut and one more times override mouse position to growed window before save mouse position savemouse for call restoremouse in future and if we close new window, mouse cursor dont jump back to previos window, and stay on last colomn growed window. Just no need every time change mouse pose value, to autogrow window. Moreover in this

plan9port/src/cmd/acme/cols.c

Lines 506 to 509 in bafcddd

	if(abs(p.x-op.x)<5 && abs(p.y-op.y)<5){
	colgrow(c, w, but);
	winmousebut(w);
	return;

This is what is done, which confirms that call winmousebut inside colgrow is a bug

• video without bug https://0x0.st/Kc-c.ogv created by me

---

Im not user plan9port and acme, and use acme first time, I've double-checked many times to see if this change changes behavior anywhere, but as far as I could examine the code, and as far as I could test it all in the editor, there are no regressions.

---

P.S. Sorry for my English, I wrote half of it myself and just translated some of the text into English :D

[spektrokalter]

I've tested it locally and identified an inconsistency.

While I agree that winmousebut shouldn't be triggered every time colgrow is called, simply removing it from there breaks some cases where it should be called. Specifically:

• If +Errors is obscured, running echo hello should not only make the body visible but also move the mouse to that window.
• If an empty window is obscured and we write anything to its body via /mnt/acme/123/body, the mouse should move to that window.
• Similarly, writing "show" to an obscured window's "ctl" should also trigger the mouse movement.

To address these issues, I've added a call to winmousebut in textshow, like this:

	if(t->w!=nil && t->fr.maxlines==0) {
		colgrow(t->col, t->w, 1);
		winmousebut(t->w);
	}

Please, review the change and, if you agree, push it.

[blogdron]

Yes thanks @spektrokalter , current fix have regressions. Now we have 2 ways remove regressions

• 1 - Directly add winmousebut in all places after colgrow except for the case that provokes the cursor stuck bug
• 2 - Add winmousebut calls only to places where you actually need to move the cursor

First way simple and garanty fix bug + save previous behaviors.
The second way requires a precise and deep understanding of the editor's behavior.

I'll do the first one a little later (or maybe other make in first) :)

[blogdron]

Im read code again the new bug case from @spektrokalter is not regression, this similar bug, winresize also override mouse pose before savemouse and mouse cursor stuck. One way or another, the call needs to be removed call winmousebut from colgrow and return winmousebut after call colgrow where it is clearly needed, but at least not where it causes problems. After this need save mouse pose for correct back jump before all posible call moveto.

I'll try to work on this and add commits, but the solution here is complex and depends on intersecting particular cases.
I just need to approach the problem from a different angle. =)

[blogdron]

Last commit fix similar bug

• with bug http://0x0.st/KcMO.37am.mp4
• without bug https://0x0.st/Kc2g.ogv

There are a lot of special cases and things connected with each other by implicit logic in the code. Please check them before using the fixes. I could only allocate a little time for all this.

The main problem with window getting stuck is that in some places the mouse position data changes before it is saved for subsequent restoration, a pointer to the window is used as just an additional condition, and in some places the saved pointer is simply erased without taking into account that to return the mouse pointer it is checked, the window is alive, the pointer to it too, the mouse position is saved, but the buffer variable is simply erased, in some places this needs to be done, for example, after closing all the windows, there is simply nowhere for the cursor to jump back, but this is not always necessary. Sometimes one logic and one behavior simply conflict with other logic and behavior.

I just wrote down my thoughts and observations, I really hope that the current fixes did not introduce problems. Since these are also special cases of trying to return the cursor back as the user expects.

People write that the cursor getting stuck is annoying, and it happens all the time and is very annoying, so I tried to fix it.

Maybe no need accept this changes. But maybe it will be useful to simply study the problem and possibly solve it in a more comprehensive way.

[spektrokalter]

@blogdron Thanks a lot of your patience and effort.

@0intro @rsc Hello! We'd appreciate your time to review this request. Apologies if I tagged a wrong person, I'm not familiar with the review process. For convenience, here's a short summary.

Initially, we addressed the issue of the mouse not retuning after deleting a new window, which was caused by other windows shrinking. It's a very annoying inconsistency, given Acme's heavy reliance on cursor automation. It clearly breaks user's expecations. The fix had a problem but it was resolved (I've tested it locally).

@blogdron has also addressed a related problem where the mouse doesn't return after deleting an existing window whose dimension changes attract the mouse. While fixing this issue for "+Errors" windows is straightforward (even intended, it seems), other cases (e.g. writing "show" to "ctl") are far more complex. These cases seem to be incompatible with the simple jump-return mechanics of the mouse, requiring a significant rewrite. This could disrupt other people's familiarity with the existing codebase, so we're unsure if it's the right approach.

Nonetheless, the major problem is solved.

Here's a one-minute silent demo of everything stated in this post:

screenrecording2025-09-16at12.53.06am.mp4

Again, thank you for your time and consideration.

[spektrokalter]

@blogdron There's another small regression (I hope). Previously, when a user changed a font, the mouse would stay in place, but now it jumps. Here's a quick video demonstrating the issue:

screenrecording2025-09-17at2.45.25pm.mp4

It seems like fontx shouldn't call winmousebut. Previously, colgrow didn't call it due to but being -1.

[blogdron]

@spektrokalter regression by this #730 (comment) fixed.

• https://0x0.st/Kcdo.ogv