Change the defaults for fork/no-fork

[valleydali]

I generally start Neovide by clicking on its Dock icon. The icon bounces and then there’s a visible stutter as the process forks, the parent exits, and the child replaces it.

But about half the time, the child appears as a second Dock icon. (I’m guessing there’s a race condition between the parent exiting and the child starting up.)

I can’t think why forking would be necessary when Neovide is launched from the Dock, and I believe it shouldn’t fork in this case.

So, either:

• Automatically don’t fork if the parent process is launchd.

or:

• Allow no-fork to be specified in the config file (or, just make --no-fork the default); and
• Add a --fork flag to be used in those cases where forking is really desired.

Launching from the Dock is unique in that there is no way to supply any flags, so one way or another the default needs to be appropriate for that scenario.

[fredizzimo]

I actually think we should remove the --fork/--no-fork completely and never fork, or at least make --no-fork the default. Almost no GUI applications fork when launched from a terminal on Linux, and it's probably the same on macOS.

There are already standard ways of running it in the background without forking like nohup command >/dev/null 2>&1 or on macOS nohup command </dev/null >/dev/null 2>&1 & to also detach stdin (which if I understand correctly, is not automatically done). And if we finalise the suspend support we started here #1971, to actually suspend when launched from a terminal, then you could map ctrl-z to suspend and return to the terminal.

Forking can also interfere with things like git merge tools, and while we don't pipe the stdin properly to Neovim currently, it becomes possible to implement if we don't fork.

On Windows the situation is more tricky, since there are no hybrid gui/console applications, but I think the current behaviour is good on that, it does not fork, but still allows the inputs and outputs to be redirected.

That said, if we want to keep the forking behaviour for just the terminal it would be easy by using this https://doc.rust-lang.org/std/io/trait.IsTerminal.html

Finally, I did have the impression that forking was actually necessary on macOS in all cases based on the PR that added it, #411

nevoide can now be run on macOS without spawning a new terminal, it will disown itself on the first run.

But actual issue, gives a different impression #402, so it's probably not necessary when launching from the dock. Also people there seem to agree that forking should be the default (including @Kethku), which is different from my opinion here, so more discussion is needed.

[valleydali]

FYI, yet another way to get the effect of forking when starting Neovide from the terminal is to use the open command, like so: open -a Neovide.

I can't think of a good reason why it would be necessary for Neovide to ever do the forking itself. To my knowledge, no other Mac apps do this. It would be totally fine with me if the forking behavior were removed altogether.

But that said, I don't have any objection to it being there for the benefit of those who want it, as long as it's not the default, or can be disabled in the config file.

Your idea of basing the choice on whether we're attached to a terminal is kind of the inverse of my idea of detecting whether we're launched from the Dock. I could live with this too.

[crupest]

Your advice is reasonable. I will be happier too if neovide plays better with Dock on macos.

It's not a simple problem. Different platforms have different situations. Even on the same platform there are different situations. It would be the best if we can handle every situation "correctly". But it's a long way. Like, it is very tricky that we detect whether launchd or other programs starts neovide.

At last, VSCode forks by default. And I vote for NO fork!😂

[agraven]

The absolute vast majority of linux gui applications do not fork by default. Most of them don't even have an option for it. I think having the option is nice, but I agree that it shouldn't be the default.

[9mm]

Def subbing to this as 99% of the time i launch neovide from terminal from the current project im working in.

When I click the icon in the dock though its really wild

What I can say is that MacVim does it perfectly as far as mac experience

• can be launched from terminal and it opens the proper icon on the dock
• icon doesnt "stutter" (im assuming that is it forking)
• can be launched from dock and it doesnt open a separate icon

[valleydali]

(OP here.) So #2189 claims to provide a "temporary solution" to this, but I don't see how.

Forking is still the default, but now it can be controlled with an environment variable. There was a time when this would have been a good solution, but those days are gone. It's no longer possible to do sudo launchctl setenv NEOVIDE_FORK 0 (at least not without disabling System Integrity Protection, which I'm not inclined to do).

I don't know of a way to set an environment variable for processes launched from the Dock. This needs to be a setting controlled from the config file, or else the default needs to change to not fork.

If I'm missing something, please enlighten me!

[9mm]

@valleydali i simply put this in .zshrc, no disabling of system protection is required... no sudo required.

I believe the proper way is to use launchctl to set it permanently, but i chose to do it this way so it fits in my .dotfiles repo

# Neovide exports
# Instead of using launchd properly, just put them here so we don't forget
launchctl setenv NEOVIDE_FRAME "buttonless"
launchctl setenv NEOVIDE_VSYNC "0"
launchctl setenv NEOVIDE_FORK "0"

[valleydali]

Ah! So, without sudo it works, but only until the next reboot.

I did not know that, thanks!

[abhillman]

I wonder if this is also causing Neovide not to open a given document when it is opened with the Finder's contextual menu:

Perhaps not. It looks like #2191 resolves and that this issue is captured in #1682

[halostatue]

I actually think we should remove the --fork/--no-fork completely and never fork, or at least make --no-fork the default. Almost no GUI applications fork when launched from a terminal on Linux, and it's probably the same on macOS.

MacVim (when run as mvim or gvim) forks from the terminal and does not block the command-line, so I would consider switching from forking to non-forking a regression in an effort to replace MacVim. I do not know what it does from the dock or Finder, but it appears not to do incorrect things there.

One of the reasons that I end trying and never using emacs on macOS is it does not fork. I explicitly use a GUI version of vim because I want to be able to edit without blocking my terminal (I rarely use a vim terminal), especially since I typically open MacVim from the terminal and have it open in the previous window position on a different screen (rotated 90º, so tall).

I may be in the minority on this, but I would immediately uninstall Neovide if I have to switch from neovide files to nohup neovide files &. GUI programs should not block the terminal without a command-line option (e.g., use gvim --remote-wait as the command for git merge handling, etc.).

[AThePeanut4]

Now that I take a closer look, I can also see a very brief stutter when launching Neovide from the Dock. I have also had duplicate icons appear, but only occasionally, rather than half the time. Disabling forking (i.e. with launchctl setenv NEOVIDE_FORK 0) fixes both these issues for me as well.

However the reason I found this issue is because I've discovered another bug caused by immediately forking. For the last couple months, my Neovide window has always been opening unfocused and behind all other windows. At first I thought it was just some weird saved window position or something, so I ignored it, but it kept happening, even after a reboot. I only now had the idea to see if disabling forking would make a difference, and it indeed fixes the issue.

As for an actual fix, I think the best solution would be to keep forking when connected to a terminal, and stop forking everywhere else. Never forking would also be fine imo, as long as the --fork option remains, but realistically in most cases if you launch Neovide from the terminal you're going to want it to fork, so why not make that the default.

@valleydali I use custom LaunchAgents to run commands (e.g. launchctl setenv) at logon. Previously I also used shell config files (i.e. .zshrc, or in my case, config.fish), but anything there is only run after opening a terminal, rather than immediately on user logon.

So as a temporary fix for this issue, I have the following saved as ~/Library/LaunchAgents/com.Neovide.setenv-fork.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>setenv.NEOVIDE_FORK</string>
  <key>ProgramArguments</key>
  <array>
    <string>launchctl</string>
    <string>setenv</string>
    <string>NEOVIDE_FORK</string>
    <string>0</string>
  </array>
  <key>RunAtLoad</key>
  <true/>
</dict>
</plist>

[fredizzimo]

but realistically in most cases if you launch Neovide from the terminal you're going to want it to fork, so why not make that the default.

I don't agree with that, in most cases when I launch Neovide from the terminal, it's because I want to edit a single file and then resume with my terminal work. If I want to keep neovide open for longer, I don't want a terminal window, so I don't open it from the terminal.

Also, standard things like SUDO_EDITOR=neovide sudoedit /etc/locale.conf does not work, you would need SUDO_EDITOR="neovide --no-fork sudoedit /etc/locale.conf. And there's the same problem with using Neovide as a git merge tool. We don't currently correctly redirect the stddio from Neovim, but if we did, then that would not work either.

All of those are things terminal users are expecting to work.

[AThePeanut4]

but realistically in most cases if you launch Neovide from the terminal you're going to want it to fork, so why not make that the default.

I don't agree with that, in most cases when I launch Neovide from the terminal, it's because I want to edit a single file and then resume with my terminal work. If I want to keep neovide open for longer, I don't want a terminal window, so I don't open it from the terminal.

That's fair, I hadn't really thought about wanting to edit single files with Neovide. I just use nvim directly in the terminal for that - my EDITOR, etc is set to nvim and not neovide.

Also, standard things like SUDO_EDITOR=neovide sudoedit /etc/locale.conf does not work, you would need SUDO_EDITOR="neovide --no-fork sudoedit /etc/locale.conf. And there's the same problem with using Neovide as a git merge tool. We don't currently correctly redirect the stddio from Neovim, but if we did, then that would not work either.

All of those are things terminal users are expecting to work.

I don't think it's necessarily an expectation that it should just work with no arguments, especially for GUI programs. As an example, upstream Vim itself forks by default when you run gvim (or vim -g). You'd need to use the -f/--nofork argument to prevent the fork - i.e. EDITOR="gvim -f".

So yeah I don't really mind whether Neovide forks or not when in a terminal - I don't really ever launch it from a terminal. All I want is for it to stop forking when launched from the Dock on macOS, to fix the stuttering, duplicate icon and launching in the background issues.

[halostatue]

@AThePeanut4:

That's fair, I hadn't really thought about wanting to edit single files with Neovide. I just use nvim directly in the terminal for that - my EDITOR, etc is set to nvim and not neovide.

I generally start working with a specific file or a subset of files:

$ gvim (fd server src) # or
$ gvim lib/application.ex

I then use a fuzzy file picker to jump between files as I tend to work that. But I never launch MacVim from the dock or /Applications/MacVim.app, and I would never do so with neovide, either. Similarly, I will never use a GUI editor that blocks the console when launching or requires me to do something stupid like open -a neovide lib/application.ex. If neovide were both a console and GUI application, doing something different might make sense (both gvim and vim -g launch the GUI on both Windows and macOS; gvim --remote-wait and vim -g --remote-wait cause them to be blocking; I believe that a fork is still performed here, but it waits on the files).

@fredizzimo

Also, standard things like SUDO_EDITOR=neovide sudoedit /etc/locale.conf does not work, you would need SUDO_EDITOR="neovide --no-fork sudoedit /etc/locale.conf. And there's the same problem with using Neovide as a git merge tool. We don't currently correctly redirect the stddio from Neovim, but if we did, then that would not work either.

All of those are things terminal users are expecting to work.

Some terminal users, but I suspect not people who actually want neovide to be a good citizen on macOS. Blocking the console by default is the exact opposite of being a good citizen on macOS.

SUDO_EDITOR="gvim --remote-wait" sudoedit /etc/locale.conf would be the equivalent when using gvim. Want to use bbedit instead? SUDO_EDITOR="bbedit --wait" sudoedit /etc/locale.conf.

[AThePeanut4]

I've done some digging, and I think I now understand why GUI apps on macOS appear to "not block" the terminal when you use them.

To use BBEdit as an example: if you run /Applications/BBEdit.app/Contents/MacOS/BBEdit in the terminal, that is, if you run the actual program binary directly, it doesn't fork. It runs just like a "standard" Linux GUI program does.

But this isn't what you'd be doing to edit files using BBEdit from the terminal, you'd use the bbedit helper program, installed to /usr/local/bin when you install BBEdit's "Command Line Tools". This seems to basically just be a wrapper script that launches the main BBEdit app separately, remotely controls it to open whichever files you specify, and then optionally waits for you to finish editing them before exiting.

So there isn't actually any difference between macOS and Linux when it comes to whether GUI apps fork or not - neither of them do. It's just on macOS, the expectation is that the app will ship with some kind of command line helper script that launches the actual app in the background, forwards arguments to it, and then either exits immediately or waits for the app to finish/quit.

Problem is, for Neovide, the binary that is launched when you run the .app (/Applications/Neovide.app/Contents/MacOS/neovide) is identical to the one on your $PATH (~/.cargo/bin/neovide, /opt/homebrew/bin/neovide, or wherever else). So unless the "app" binary is made different to the "terminal" binary, or a command line helper script is somehow installed, the only way to behave "as expected" is to detect whether we're in a terminal and do something differently. In other words, fork by default when in a terminal, and don't fork anywhere else. I think it should also be fine to never fork on other platforms, since the expectation to "not block" is macOS-specific.

[fredizzimo]

That sounds like it's something that should be handled by the homebrew cask and not by the application itself.

[halostatue]

I've done some digging, and I think I now understand why GUI apps on macOS appear to "not block" the terminal when you use them.

To use BBEdit as an example: if you run /Applications/BBEdit.app/Contents/MacOS/BBEdit in the terminal, that is, if you run the actual program binary directly, it doesn't fork. It runs just like a "standard" Linux GUI program does.

…

Problem is, for Neovide, the binary that is launched when you run the .app (/Applications/Neovide.app/Contents/MacOS/neovide) is identical to the one on your $PATH (~/.cargo/bin/neovide, /opt/homebrew/bin/neovide, or wherever else). So unless the "app" binary is made different to the "terminal" binary, or a command line helper script is somehow installed, the only way to behave "as expected" is to detect whether we're in a terminal and do something differently. In other words, fork by default when in a terminal, and don't fork anywhere else. I think it should also be fine to never fork on other platforms, since the expectation to "not block" is macOS-specific.

However, forking is exactly what MacVim does. The mvim script does some dancing around to figure out what mode it should work in, but at line 37, we find:

# GUI mode, implies forking
case "$name" in m*|g*|rm*|rg*) gui=true ;; esac

At line 61, that gui=true pays off:

# Last step:  fire up vim.
# The program should fork by default when started in GUI mode, but it does
# not; we work around this when this script is invoked as "gvim" or "rgview"
# etc., but not when it is invoked as "vim -g".
if [ "$gui" ]; then
        # Note: this isn't perfect, because any error output goes to the
        # terminal instead of the console log.
        # But if you use open instead, you will need to fully qualify the
        # path names for any filenames you specify, which is hard.
        exec "$binary" -g $opts ${1:+"$@"}
else
        exec "$binary" $opts ${1:+"$@"}
fi

It may be that neovide needs to do the same thing on MacOS, but it very clearly requires forking. Again, MacVim is a little different because it is built simultaneously for terminal and GUI, and neovide is just a GUI, so it should always behave like mvim or gvim or bbedit does when run from the command-line, and that means providing a command-line flag for either not forking or waiting until edits are completed.

@fredizzimo: Homebrew can deliver packages that are built. Neovide builds a proper macOS .app and then wraps it in a .dmg. The responsibility does not lie with Homebrew, but with Neovide.

I suspect that the flickering and duplicate dock issue reported initially has much more to do with Neovide having little proper macOS support‡ and nothing to do with the forking as originally reported. If I launch Neovide multiple times, I get multiple application icons in my application switcher (I have my dock hidden, but they are duplicated there, too). If I launch MacVim multiple times, it stays under one application icon and ⌘-` switches between the different vim "server" instances / windows. This is the correct behaviour on macOS, and what I look for personally. (I also think that Neovide should package a few more default key bindings into Neovide.app, so that ⌘-C/V/X work as expected by default on macOS.)

Some of these things, I could probably help with (generally the stuff that any idiot could do, like making sure that the system configuration loaded when Neovide launches includes macOS bindings), but other things…I cannot help with as I am not nor have never been a macOS application developer.

‡ Not slagging any of the developers. What works here is amazing, and it's more than I have knowledge to deal with. But as of right now, Neovide is the best neovim GUI…and worse than VS Code and the various Emacs GUIs when it comes to acting like a proper macOS citizen as a GUI editor. I personally find it nearly unusable:

• Command keymaps do not always appear to work (I have mapped ⌘-- and ⌘-+ to zoom levels as suggested on the wiki; they work ⅓ of the time; the ⌘-C/X/V combinations work a bit more often, but have been surprising. No issue yet, because I cannot reliably determine the cause of failure to meaningfully report it. I also still mostly use MacVim because of this and other usability issues (some of which has to do with missing plug-ins and a lack of time to normalize).
• neovide *.md opens each file in a tab, which I want to disable permanently, but no-tabs = true does not seem to work in ~/.config/neovide/config.toml. no-tabs = true in ~/.config/neovide/config.toml does not work #2348
• Neovide always opens in the background. neovide does not focus on launch from terminal (macOS, iTerm2) #2330

[9mm]

I suspect that the flickering and duplicate dock issue reported initially has much more to do with Neovide having little proper macOS support

It's been quite awhile since I looked at this, but I'm 99% certain the duplicate dock issue is related to forking or not.

I had to do some hacks basically to get it to work, but in ~/.zshrc I have this:

# Neovide exports
launchctl setenv NEOVIDE_FRAME "buttonless"
launchctl setenv NEOVIDE_VSYNC "0"
launchctl setenv NEOVIDE_FORK "0"

I know it can go inside the bundle, and also it can get set directly on startup, but I put them here so it's in my dotfiles and I dont forget

This 100% fixes the issue with launching the app from the dock. I forgot how I had it, but I believe I made an automator script wrapper.

Currently I dont even use the dock version because the ONLY thing I use the dock icon for (rather than launching from terminal) is when I have to deal with dozens of CSV's, and I want to drag them into the icon as its just easier when working with tons of files. Unfortunately dragging into the icon was another issue i looked at but it involves workign with multiple runtime loops which I just dont know. So for now, i dont even have a neovide dock icon, i just use macvim for that case. Its really painful, and i really wished that worked.

But, I do remember testing all this, and I remember it fixed the problem.

I then had a separate launcher script so I can just type n from terminal and it opens the gui to current folder

export NEOVIDE_FRAME=buttonless
export NEOVIDE_VSYNC=0
export NEOVIDE_FORK=1

export ENABLE_EDGE=1

if [ "$ENABLE_EDGE" = "1" ]; then
  neovide_bin="/Users/zesty/.cargo/bin/neovide"
else
  neovide_bin="/opt/homebrew/bin/neovide"
fi

... rest goes here

But you can see i just override forking there

This 100% removes the dock issues and bouncing, but it DOES open multiple instances of the app. I actually hated this at first, but have come to like it way way more, as its easier to maintain multiple "sessions". Im sure thats not the correct OSX behavior, which would try to put them as multiple windows, but still.

Either way, I agree Neovide doesn't behave like a normal mac app, I think the problem is that not many developers working on Neovide use OSX. I use it and can test things, but I don't do OS dev/rust so it makes it hard to contribute except for simple things.

[AThePeanut4]

However, forking is exactly what MacVim does. The mvim script does some dancing around to figure out what mode it should work in, but at line 37, we find:

I've never used MacVim, so I've just installed the MacVim cask to try it out. If you run /Applications/MacVim.app/Contents/MacOS/MacVim, which is the actual binary run when you run MacVim.app, it does not fork, and it "blocks" the terminal. It then launches a /Applications/MacVim.app/Contents/MacOS/Vim -g -f subprocess for every window, which also does not fork (due to the -f). The MacVim process I believe is responsible for the macOS "integration", i.e. the multiple windows in one Dock icon, the buttons in the menubar, etc.

If you run the mvim script, it launches a /Applications/MacVim.app/Contents/MacOS/Vim -g subprocess, which forks and then exits. This Vim process then launches a /Applications/MacVim.app/Contents/MacOS/MacVim -MMNoWindow yes subprocess, so that the macOS integration keeps working.

I suspect that the flickering and duplicate dock issue reported initially has much more to do with Neovide having little proper macOS support‡ and nothing to do with the forking as originally reported. If I launch Neovide multiple times, I get multiple application icons in my application switcher (I have my dock hidden, but they are duplicated there, too). If I launch MacVim multiple times, it stays under one application icon and ⌘-` switches between the different vim "server" instances / windows. This is the correct behaviour on macOS, and what I look for personally.

Well at least for me, disabling forking of the /Applications/Neovide.app/Contents/MacOS/neovide binary (with launchctl setenv NEOVIDE_FORK 0) fixes those two bugs, and #2324 as well. Since none of the actual binaries for other macOS apps (including MacVim and BBEdit) fork, I think it's fair to say the forking is the issue and not "improper macOS support".

As for the multiple application icons issue, this is basically #1586, and is also related to what is to me the biggest usability issue on macOS - you can't open multiple Neovide windows without going through the terminal (with either neovide if the binary is on your $PATH, or open -na Neovide if it isn't). I think there are three options here:

1. The MacVim way, with a wrapper Neovide binary and the normal neovide binary. The Neovide main binary would then spawn separate neovide subprocesses for each window. If you run neovide from a terminal, it would fork (or not, if you specify the equivalent flag to -f), and then spawn a Neovide process if one doesn't exist yet.
2. The BBEdit way, with a main Neovide binary and a separate neovide terminal script. The main binary would be able to create multiple windows, thereby keeping all windows under the same application icon. The terminal script would just launch the main binary if needed, remotely send it arguments, and optionally wait before exiting.
3. The "browser" way (Chrome and Firefox do this, and probably other programs as well), with just one neovide binary. That binary can again create multiple windows, which keeps everything under one application icon. However, if you run neovide when a neovide process already exists, it would remotely instruct the existing process to create a new window using the given arguments and then exit. To be able to use Neovide as an EDITOR, we'd then need some kind of --wait option to wait for the window to be closed, even if it was opened in an existing process. A --new-instance option to force creating a new instance rather than using an existing one would also be useful. On macOS only, to not "block" the terminal as expected, the binary should also fork if run from a terminal, even if creating a new instance.

All three of these options are quite complicated though. 3 would apply to all platforms, so in that way it's sort of the "cleanest", but it would certainly be the most difficult to implement. 1 and 2 would be macOS-specific, and require less work, but would mean multiple binaries.

For my issue, all I'd need is a :NeovideNewWindow command that just forks off a new neovide process. I've just added this

vim.api.nvim_create_user_command("NeovideNewWindow", function()
    vim.system({ "open", "-na", "Neovide" })
end, {})

which works for my setup, but it won't work if you don't have Neovide.app installed.

(I also think that Neovide should package a few more default key bindings into Neovide.app, so that ⌘-C/V/X work as expected by default on macOS.)

Neovide is currently a rather barebones GUI in terms of system integration, on all platforms - and that isn't necessarily a bad thing. It just simply forwards all keypresses to Neovim, which I think is perfectly reasonable. And I don't think it needs to inject its own keybindings, on any platform - the user can configure those themselves, which they should be comfortable with, since they're using Neovim. A recommended/helpful keybindings page in the wiki would be nice though.

• Command keymaps do not always appear to work (I have mapped ⌘-- and ⌘-+ to zoom levels as suggested on the wiki; they work ⅓ of the time; the ⌘-C/X/V combinations work a bit more often, but have been surprising. No issue yet, because I cannot reliably determine the cause of failure to meaningfully report it. I also still mostly use MacVim because of this and other usability issues (some of which has to do with missing plug-ins and a lack of time to normalize).

I've had

vim.keymap.set("v", "<D-c>", '"+y')
vim.keymap.set({ "n", "v" }, "<D-v>", '"+P')
vim.keymap.set({ "c", "i" }, "<D-v>", "<C-R>+")

vim.keymap.set("n", "<D-s>", "<Cmd>update<CR>")

in my config file for ages, and I don't remember them ever not working. I also just added

vim.g.neovide_scale_factor = 1.0
local change_scale_factor = function(delta)
  vim.g.neovide_scale_factor = vim.g.neovide_scale_factor * delta
end
vim.keymap.set("n", "<D-+>", function()
  change_scale_factor(1.25)
end)
vim.keymap.set("n", "<D-->", function()
  change_scale_factor(1/1.25)
end)

to test, and they also seems to work fine at least for me. I think there's probably something else going on that's causing your bindings to not work.

I'm in a similar position to @9mm - I'd love to contribute fixes for this kind of issue, but I know basically nothing about OS development and I'm still (slowly) trying to learn Rust so I can only really help with testing.

This 100% removes the dock issues and bouncing, but it DOES open multiple instances of the app. I actually hated this at first, but have come to like it way way more, as its easier to maintain multiple "sessions". Im sure thats not the correct OSX behavior, which would try to put them as multiple windows, but still.

I can entirely understand this. The way the Dock groups all windows of an app behind a right-click is for me one of the most annoying parts of using a mac. I really wish there was an option to either show all windows on hover (i.e. like Windows) or just show a separate icon for each. AltTab really is the single thing keeping me from going insane when I have to constantly switch between multiple windows.

[9mm]

@AThePeanut4 I always used Hyperdock for the longest time:

https://bahoom.com/hyperdock

Sadly I think it stopped working some time ago but I don't remember. You might try installing it and see if it works. I have also heard of alternatives if it doesnt work:

https://www.macenhance.com/dockmate.html

Basically instead of alt tab, the thing that keeps me sane is 3 finger swipe UP on trackpad. I actually find this is much faster than hyperdock even which is why I dont use it much anymore.

This trick wouldnt work though if you are not working on a laptop, but I find this is actually supreme as I can even have a dozen windows open and quickly find the one i want

[fredizzimo]

I'm not a Mac user, so I might be wrong but to add to the above,

The dmg we provide is a Gui app, neovide.app, we don't provide a neovide command to be used from the shell, that's done by Homebrew Cask

If you launch neovide.app the standard way NEOVIDE_FORK=0 open neovide.app it does detach from the terminal (fork as we call it here, but it's not really forking). With NEOVIDE_FORK=1 open neovide.app it actually forks and launches neovide twice, which is wrong, and you get the same problems as with the gui.

As mentioned, the neovide command is provided by homebrew, with the binary stanza, here https://github.com/Homebrew/homebrew-cask/blob/9b00cc305f9c06b69c61314984fba1dfb4248361/Casks/n/neovide.rb#L13. And that is not maintained by the Neovide team.

The macVim cask on the other hand provides several binaries https://github.com/Homebrew/homebrew-cask/blob/9b00cc305f9c06b69c61314984fba1dfb4248361/Casks/n/neovide.rb#L13. And they all target the same mvim script that was linked above. which selects the forking behaviour based on the binary used.

In the case of macVim, that script is maintained by the team, but it does not need to and in our case I don't think it should, but I don't think we would refuse if someone made a PR and offers to maintain it. If not, it can be embedded in the cask using the preflight stanza

What we definitely should not do is to embed complex logic like that in the binary itself.

[AThePeanut4]

@9mm I searched around once and I remember finding Hyperdock, but yeah it hasn't been updated in 7 years. Also both Hyperdock and Dockmate are paid software, and yeah I know that's the Apple way, but I'd prefer something FOSS :) (like AltTab)

I do use the 3 finger up swipe fairly often, if I need to find one specific window - but it's too tedious if I have to constantly do it. But yeah between that and AltTab I'm efficient enough, I just had to take the opportunity to rant a bit xD

[fredizzimo]

There's also this https://github.com/alex35mil/NeoHub, by @alex35mil specially made for Neovide, that you might want to look at. I'm not a mac user, so I don't know how well it works, but I have heard good things about it.

[fredizzimo]

@halostatue, can you create an issue for the key press issue with a log attached? There's a chance we can figure out the cause with that. But without any report's there's no hope of fixing it.

[halostatue]

@halostatue, can you create an issue for the key press issue with a log attached? There's a chance we can figure out the cause with that. But without any report's there's no hope of fixing it.

It will take a bit of time (elapsed) to do so, because I need to try to isolate whether there are circumstances that cause it to happen so that I can reproduce it. It is really annoying when it happens, but when I relaunch neovide…it sometimes works. I’m swamped with paying work right now, so I’m not doing a lot of playing with Neovide right now.

With respect to providing a launcher program / script for macOS, I believe that neovide should provide them like MacVim does. It should not have an "install helpers"; the homebrew cask takes care of symlinking those into /opt/homebrew/bin from the cask for MacVim, and I believe there are instructions to do so when you manually install the app from a DMG or zip file.

I want to reiterate something, because I realize my tone may have come across as very negative. I tried Neovide last year and uninstalled it almost immediately. The improvements overall in the last year are impressive, and I applaud that. There's a long way to go, and it does require more work for better macOS integration that I am currently unable to provide (time, expertise, etc.) except as bug reports.

I think there are things that could be learned from MacVim even though they are entirely different beasts. There is consideration of having a MacNeovim in the future, but I personally suspect that collaboration would be better between these two projects than competition (see macvim-dev/macvim#1472 and macvim-dev/macvim#47; the 2023 comments are more interesting).

[fredizzimo]

The defaults will be changed by #2512

[fredizzimo]

And this was merged:

• fix:! Don't fork by default #2512