Repository navigation
Add an option so that opening a file from macOS’s "external editor" mechanism does not bring macvim to foreground #1408
Description
Activity
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 --editorwith? I haven't used this option much. What kind of command are you invoking MacVim with when you hit a breakpoint?Reacted by Matthieu TalbotThanks for your swift answer!
I made a mistake, sorry. When launching an lldb session with
--editor,lldbwill usethe 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 InterestingFunctionthenrun), or any command that lists source code during the debugging session (like changing frame withupordown, 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?
- changed the title
[-]Add an option so that `mvim --remote-silent` does not bring macvim to foreground[/-][+]Add an option so that opening a file from macOS’s "external editor" mechanism does not bring macvim to foreground[/+]on Jun 20, 2023 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
--editorflag 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
opencommand in macOS (you can typeman openin terminal to see how it works). There is a-gcommand 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.Reacted by Matthieu TalbotIs 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 willopenat 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
--editorflag just configures lldb and tells it how to open a file?The flag only tells lldb to
openwhenever 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
opencommand in macOS (you can typeman openin terminal to see how it works). There is a-gcommand 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 --editordoes. 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 -gflag 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 theopen -gcommand 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.
Reacted by Matthieu Talbot
In macOS, I am setting the default editor for source code files to open with macvim be default so that macvim can be the editor when debugging on lldb with
lldb --editor. However, whenever a breakpoint is hit, or a frame changed, the focus automatically goes from lldb to macvim. I wish I could keep the focus on lldb instead.Describe the solution you'd like
Maybe there could be an option called
macvim_dont_bring_to_foreground, set to 0 by default, that enables the current behavior (bringing macvim to foreground when a remote command arrives), and can be set to 1 to disable the foreward bringing).Describe alternatives you've considered
I have considered using vim in the terminal instead, by the server part of +clientserver is disabled.Additional context
Add any other context or screenshots about the feature request here.
EDIT:
lldbdon’t use $EDITOR but the host’s external editor instead.