On Mon, Mar 3, 2025 at 2:21 PM Daniel Colascione wrote: > Stefan Kangas writes: > > > Mattias Engdegård writes: > > > >> This change appeared on master in 3545988740. > >> > >> Is there really a consensus for this? Click-through does not appear > >> how (MacOS) applications work in general. While it seems useful for > >> switching between unobscured Emacs windows, it's a bit surprising > >> when clicking on a partially obscured Emacs in order to raise and > >> activate it. > >> > >> Is there a way to make the behaviour more conditional in this > >> respect? Or, at least, configurable. > > > > IIUC, this is how Emacs used to behave on macOS, so I originally treated > > this as just a bug fix. > > > > That said, I have no objection to making it optional, of course. > > > > I also don't have an opinion on what should be the default because: > > - the historical behavior of Emacs, and similarity to other platforms, > > seem to speak in favor of having this on by default > > - being consistent with macOS seems to speak in favor of having it off > > The situation seems a bit more nuanced than a choice of "on" or "off". > I think the concept is that you're supposed to enable click-through for > "utility" items (like toolbar buttons) and for document *selection*, but > require a second click for interaction with documents. > > You can see this behavior in Chrome. Start it up, go to a web page, > then give some other app focus. When Chrome is no longer focused, click > its page reload button. The page will reload immediately. Now switch > focus again, and this time click a link on the page. The click just > focuses and raises the Chrome window. You have to click a second time > to follow the link. > > It looks like Apple's put a lot of thought into the click-through model. > If we're going to follow the same pattern, we should use click-through > for toolbar buttons, mode-line stuff, and so on, but not for window > interaction. A non-focused click on an Emacs window should *select* the > window but not execute any special commands in that window, > e.g. following links, expanding headers, and so on. It probably > shouldn't move point either. > > Others have been tripped up by this too: > https://github.com/microsoft/vscode/issues/24634 > > We might be able to implement this model by letting the first click go > through only if it resolves to some command that has a new > ns-first-click-capable property or interactive spec or something. > > That's a lot of work, so I'd rather just have an on/off toggle right now > with a todo. I'd prefer to default the setting to on, since Emacs is > more convenient to use this way. > > > Please let your voices be heard, if you have a reasoned opinion here. > > > > Daniel, could you perhaps look into adding a defcustom for this? > > Sure. > To observe this behavior, I was supposed to click not in a text window but on some other UI control?