Right. Let me think about this a little and see if it makes sense to make a PR to upstream Vim instead (so all gvim implementation benefits). Just curious, what do you use lldb --editor with? I haven't used this option much. What kind of command are you invoking MacVim with when you hit a breakpoint?

Thanks for your swift answer!

I made a mistake, sorry. When launching an lldb session with --editor, lldb will use the host's "external editor" mechanism.. In my case, a long time ago, I used Finder to change the default editor of interesting source files .h, .c, .mm, .cpp, etc. to open by default with MacVim.

When lldb hits a breakpoint (b InterestingFunction then run), or any command that lists source code during the debugging session (like changing frame with up or down, lldb will automatically open the file at the correct line.

I have reworked the original ticket.

Is there an option, or a script I can run in macvim to dump system calls when this happens?

Is there a reason why you don't want the editor to come to the foreground? Why would you want to edit the file but not have it come to focus? I'm still not understanding what feature in lldb is actually opening MacVim. From what I can tell the --editor flag just configures lldb and tells it how to open a file? I don't think just setting a breakpoint will open a file right? Do you have some command or setting that causes it to open the editor?

As for how this works, I'm guessing it's just using the open command in macOS (you can type man open in terminal to see how it works). There is a -g command to prevent it from coming to the foreground but this isn't something MacVim has control over, as it's up to the caller how to invoke open, hence me being curious exactly what in lldb is causing it to want to open the editor.

Is there a reason why you don't want the editor to come to the foreground? Why would you want to edit the file but not have it come to focus? I don't think just setting a breakpoint will open a file right? Do you have some command or setting that causes it to open the editor?

When debugging using lldb --editor, whenever the editor display source code, for example when encountering a breakpoint, or inspecting another frame, lldb will open at file and line. Which means: if you are stepping a lot in a debugging session, or inspecting frames, focus on lldb is lost to macvim very frequently, opening files of no interest.

I'm still not understanding what feature in lldb is actually opening MacVim. From what I can tell the --editor flag just configures lldb and tells it how to open a file?

The flag only tells lldb to open whenever code is displayed, either when stopping because of a breakpoint, or when inspecting another frame.

As for how this works, I'm guessing it's just using the open command in macOS (you can type man open in terminal to see how it works). There is a -g command to prevent it from coming to the foreground but this isn't something MacVim has control over, as it's up to the caller how to invoke open, hence me being curious exactly what in lldb is causing it to want to open the editor.

As I try to describe the issue with further details, I realise that it may be intractable from macvim standpoint. lldb should not open each and every file and line it encounters, and a user command should really do that only for interesting places, which means that macvim is probably fine as-is.

Ok I think I might have been misunderstanding what lldb --editor does. Upon testing it myself, you are right, it does open each breakpoint with the editor, which seems… like a iffy feature for the reasons you said haha.

Upon testing, it does seem like lldb does use the open -g flag to make sure the editor should be opening the file in the background. What happens is that the first time MacVim opens a file, it does open it in the background. The second time it is opened though, it reuses the same opened window (which is fine) but somehow puts MacVim in the foreground. This does seem like a bug to me as MacVim isn't respecting the open -g command properly.

If you use Xcode for example, you will see that it won't steal focus.

I can take a look to see how to fix it.