Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an option so that opening a file from macOS’s "external editor" mechanism does not bring macvim to foreground #1408

Open
MartyLake opened this issue Jun 19, 2023 · 5 comments
Milestone

Comments

@MartyLake
Copy link

MartyLake commented Jun 19, 2023

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: lldb don’t use $EDITOR but the host’s external editor instead.

@ychin
Copy link
Member

ychin commented Jun 19, 2023

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?

@MartyLake
Copy link
Author

MartyLake commented Jun 20, 2023

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?

@MartyLake MartyLake 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 Jun 20, 2023
@ychin
Copy link
Member

ychin commented 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 --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.

@MartyLake
Copy link
Author

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.

@ychin
Copy link
Member

ychin commented Jun 22, 2023

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.

@ychin ychin added this to the Release 177 milestone Jun 22, 2023
@ychin ychin modified the milestones: Release 177, Release 178 Jul 9, 2023
@ychin ychin modified the milestones: Release 178, Release 179 Sep 9, 2023
@ychin ychin modified the milestones: Release 179, Release 180 Dec 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants