exit-minibuffer does not work when window is split

[To1ne]

Steps to reproduce

1. Open any file, but has to have more lines than fit on a screen
2. Split the window with C-x 2 or C-x 3
3. Search for something that's not currently on screen
4. Press RET to exit searching

Expected behavior

Point in the current window should stay at the thing I've been searching.

Current behavior

Point jumps back to the position where point is on the other window.

[peteware]

I'm having same problem; super frustrating -- couldn't figure out why it happens sometimes and not others. Splitting the screen seems like the trigger. I rolled back to 1.1 which works

[gexplorer]

I've been experiencing this but I found something even funnier.
The search only works if the buffer you are searching is also opened in the last window.

Let's say we have the screen split in Left and Right and we have 2 buffers A and B:

Left	Right	Searching...
A	A	Left OK Right OK
A	B	Left Fails Right OK
B	B	Left OK Right OK
B	A	Left Fails Right OK

The same goes for any combination of horizontal and vertical splits. The search only works in the very last window or in any other window displaying the same buffer as the last window.

[tpeacock19]

I believe you can workaround this by ignoring the ctrlf--finalize function with (advice-add 'ctrlf--finalize :override #'ignore). I haven't had any issues since doing that.

[terlar]

Thank you for the work-around, this was really bothering me for quite some time!

[raxod502]

Huh, this is very odd. I don't think I've ever experienced this, which surprises me. I wonder if there is something in my configuration that happens to inhibit the problem by chance?

I'm also confused that rolling back to release 1.1 of CTRLF would fix the problem, since according to the changelog there weren't any changes related to point or window scroll positions. Apparently, there is something there though.

[egh]

FWIW I had this issue, #81 (comment) fixed it for me. But now I can't replicate the issue at all, so I'm not sure what happened.

[tpeacock19]

I think it could have to do with this expression in ctrlf--minibuffer-exit-hook

(setq ctrlf--final-window-start (window-start (minibuffer-selected-window)))

Since the function is added to the minibuffer-exit-hook I believe minibuffer-selected-window will always return nil since that hook is run after exiting the minibuffer.

[raxod502]

If I put a debug statement into that function, minibuffer-selected-window definitely returns non-nil, at least sometimes. Maybe it does not in this particular case and that is what is causing the issue?

[tpeacock19]

I can't really seem to find why issue occurs. When I use edebug it does return as nil; and I am certain that the (set-window-start nil ctrlf--final-window-start) expression is the culprit. Commenting that out and it seems to work correctly.

Do you not experience the issue at all?

fwiw I'm using this pgtk+native-comp emacs branch, version info below. But this had occurred in the standard native-comp branch as well.

GNU Emacs 28.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.17.4) of 2021-02-12

[raxod502]

Well, if you're using edebug, then your UI commands are actively screwing with the window state while the code is executing, so you should expect some different results.

Yes, for whatever reason I've never experienced this issue to my knowledge. I couldn't say why. I've had a perhaps similar problem #6 in the past, but I think it is unrelated to this.

My version info at present:

GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14) of 2020-03-26, modified by Debian.

(Although I've run Emacs 27 and 28 in the past with CTRLF, and haven't seen any difference in functionality.)

When you comment out the set-window-start invocation, is your scroll position maintained when you exit the search session? I added that piece of code because for some reason when I exited the minibuffer (with RET or C-g, I can't remember which) the window scroll position (though not the position of point) was moved unexpectedly. It's possible that this bug(?) was fixed in more recent versions of Emacs, and my hack now causes a problem.

[tpeacock19]

When you comment out the set-window-start invocation, is your scroll position maintained when you exit the search session?

When commented out it functions as expected for all actions, RET, C-g, ctrlf-cancel, etc.

It's possible that this bug(?) was fixed in more recent versions of Emacs, and my hack now causes a problem.

I imagine you are right and this is the case. I did a cursory search for commits since the middle of Jan that reference scroll or window positioning but couldn't find anything relevant.

[raxod502]

Well, I'm using Emacs 26.3 now, and things seem to work without that hack, so I'll remove it. For future reference, it was added in 03599db.

[To1ne]

I'm on gccemacs da4da88c76465e30ce974383b182f191553b470a from 2021-02-21 and the latest version of ctrlf also works fine for me. Gonna close this issue now. Thanks @raxod502!