fix:! Don't fork by default

[fredizzimo]

What kind of change does this PR introduce?

Based on discussion here, we should change the defaults to not fork, so this is done here.

• Change the defaults for fork/no-fork #2147

Additionally, this prevents any attempts to fork when a terminal isn't attached, since that would have no effect.

Did this PR introduce a breaking change?

A breaking change includes anything that breaks backwards compatibility either at compile or run time.

• Yes, this changes the defaults, previously Neovide always forked.

[github-actions]

Test Results

  6 files  ±0    6 suites  ±0   21s ⏱️ +6s
110 tests ±0  110 ✅ ±0  0 💤 ±0  0 ❌ ±0 
644 runs  ±0  644 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 7a8c398. ± Comparison against base commit a5a9484.

[fredizzimo]

I'm going to merge this to get more feedback before the release.

[9mm]

is there an idiomatic way to handle this on OSX? maybe @halostatue knows? ie like what does macvim do so on the command line it forks?

[9mm]

One weird thing I notice is when I open neovim like this now:

/Users/zesty/.cargo/bin/neovide -- -c 'cd ~/Desktop'

It makes two tabs and rename one of the tabs.

Expected:

Actual:

[fredizzimo]

@9mm, I think the idiomatic way of doing it would be to provide multiple entry points in the homebrew scripts like macVim does:

• Change the defaults for fork/no-fork #2147 (comment)

[fredizzimo]

@9mm, I think it should be /Users/zesty/.cargo/bin/neovide -- -c ':cd ~/Desktop'

[9mm]

something definitely weird, this will take more time to look into

[9mm]

i did find their binary here as well: https://github.com/macvim-dev/macvim/blob/master/src/MacVim/mvim

[fredizzimo]

@falcucci, do you have any ideas? For me on Linux the cd command works correctly.

[halostatue]

This change will prevent me from using neovide unless and until neovide starts providing its own neovide script (the helper "binary" should not be provided by homebrew, but by neovide) that intelligently determines whether it should fork or not. A command-line neovide should behave like bbedit or gvim and not block the terminal command line unless a command-line option is provided.

[fredizzimo]

@halostatue, if you really want it to fork by default you can set the environment variable NEOVIDE_FORK=1.

As discussed in #2147, programs that fork are the exception, not the rule. Even pure GUI applications like kwrite or even Google Chrome don't fork by default. Some neovim GUIs and Visual Studio code are the only exceptions.

[fredizzimo]

And I don't want to maintain and tie any homebrew scripts to the release cycle of Neovide. They are totally independent and should be maintained elsewhere.

We could consider a separate repository for it, if someone volunteers to maintain it.

[halostatue]

@halostatue, if you really want it to fork by default you can set the environment variable NEOVIDE_FORK=1.

I don’t particularly care whether Neovide forks by default or not. I do care that, if there is a neovide command (like mvim on the command-line, it should not block the command-line unless I ask it to do so. If I do /Application/Neovide.app/Contents/Neovide, do whatever.

And I don't want to maintain and tie any homebrew scripts to the release cycle of Neovide. They are totally independent and should be maintained elsewhere.

I don't think you should, either. But that is different than what I have said. The fact that Homebrew provides a script is a distraction. If Neovide can be run with just neovide on Windows and Linux, then Neovide should offer a helper script or binary that provides an installable/linkable command-line (like the mvim script for MacVim) that does the right thing. This, by the way, is what VS Code does with its code command (the script that Homebrew links is in Visual Studio Code.app/Contents/Resources/app/bin/code).

If such a script were part of upstream (that is, neovide itself), I would consider look at making and maintaining a MacPorts port for Neovide (I am trying to reduce my Homebrew install to a few casks and fonts). But I’m not going to create and maintain such a script myself, and I’ll just not use Neovide if your answer is ultimately that such a launcher script is outside of neovide's responsibility, because we disagree on that.

[fredizzimo]

The Neovide command is not provided by us, we only provide Neovide.dmg. The neovide executable is provided through homebrew, and this formula https://github.com/Homebrew/homebrew-core/blob/451533c52463b62ba5c56c1c761bc704337f7ef1/Formula/n/neovide.rb. I have no idea who maintains it.

[halostatue]

The Neovide command is not provided by us, we only provide Neovide.dmg. The neovide executable is provided through homebrew, and this formula https://github.com/Homebrew/homebrew-core/blob/451533c52463b62ba5c56c1c761bc704337f7ef1/Formula/n/neovide.rb. I have no idea who maintains it.

And that is what I am saying is where Neovide is not delivering a whole experience. The neovide command — which is provided by the way that Windows and Linux work — should also be provided for macOS (even if it would, like the bbedit command or code command, require an additional step unless installed by something like Homebrew). The launch script should be part of the Neovide app bundle, and not someone else's responsibility.

Visual Studio Code provides their launch script in the .app bundle (which Homebrew symlinks into /opt/homebrew/bin). BBEdit provides their launch binary in the .app bundle (for which they provide a menu option to symlink it into /usr/local/bin).

The fact that the neovide team does not provide a workable macOS launch script and has allowed Homebrew maintainers to create a substandard launch script that does not provide a quality experience is immaterial to most people who will install Neovide via Homebrew. You’ll get the bug reports and you have an opportunity to improve that experience by providing a launch script in your .app bundle (and this is your actual deliverable on macOS; the .dmg is no different in this perspective than a .zip file).

As I said, I have too many commitments to other things to want to bother creating and maintaining such a script. But if Neovide does create such a script (and there are good examples from MacVim and VS Code that can be adapted) and include it in your bundle, I’ll take on the much lighter-weight commitment of making a MacPorts port for neovide.

I don’t want Neovide through Homebrew. I want to be able to install Neovide either by downloading the .dmg/.zip/whatever and getting the .app`, and then opting to install the helper binary/script — or an option through MacPorts that gives me an equivalent‡ experience. Unless Neovide provides a launch script, it is not providing a viable alternative to MacVim.

‡ MacPorts prefers source builds over downloading compiled binaries.

[Kethku]

Please try to remember that "the neovide team" is effectively 2 or 3 people at any given time who donate what time they can to the project for free.

[9mm]

Please try to remember that "the neovide team" is effectively 2 or 3 people at any given time who donate what time they can to the project for free.

Yes agree, that was painful to read. Enough with all the italicized words my man.

So @fredizzimo I don't quite understand the "solution", or tbh if there is even a problem. I agree that homebrew shouldn't really have anything to do with the release cycle.

Are you saying a potential solution is to have a binary handle launching, similar to macvim? The one I linked above was the only one I found. I also looked inside their MacVim.app and found a file called automator stub, but I couldn't figure out what's generating it. I thought that might also be some launcher script.

Whatever the answer is, I've just been writing my own script anyway to launch neovide, but it would be cool if it were a part of neovide itself.

[9mm]

@fredizzimo i see the issue now why my script stopped working. I dont understand this, and I know this isnt a bash supprt help issue, but...

can you think of some reason why my NEOVIDE_FORK=1 stopped working after the fork commit? That's why the duplicate tab was opening... and then i see its because its no longer forking.

A simplified version of my script:

#!/bin/bash

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

neovide_bin="/Users/zesty/.cargo/bin/neovide"

exec $neovide_bin -- -c ':cd ~/Desktop' > /dev/null 2>&1

Will actually not fork, yet this will, if ran straight from command line:

NEOVIDE_FORK=1 /Users/zesty/.cargo/bin/neovide -- -c ':cd ~/Desktop'

[fredizzimo]

@9mm, I don't really know what's being asked for either. But here's my attempt to explain, how I think it should work.

There can be several entrypoints in homebrew, and they can launch scripts and add command line arguments and so on.

For example, mvim declares the following executables:
https://github.com/Homebrew/homebrew-core/blob/1f3d566233384a23bb46a72e93369d5d8026b75c/Formula/m/macvim.rb#L81-L82

Then the script matches against the executable name to disable or enable forking depending on which executable you launch. Additionally, the script adds some parameters to some of the other modes
https://github.com/macvim-dev/macvim/blob/e10ad1f5085cf2f0ae45b05cc4a92f77025629af/src/MacVim/mvim#L37-L38

This means that if you launch it through vim you get no forking, while mvim or gvim forks for example.

Since both the homebrew formulae and the script need to be in sync, it only makes sense to include it there.

For usage outside of homebrew, which I consider advanced use cases, then the user can create the required scripts themselves. Or define NEOVIDE_FORK=1 if they want to always fork. This can be as simple as a shell alias, and you don't even need the --fork parameter if you don't want, the support for detaching is built in in macOS.

• https://www.jviotti.com/2022/11/28/launching-macos-applications-from-the-command-line.html
• https://osxdaily.com/2007/02/01/how-to-launch-gui-applications-from-the-terminal/

[fredizzimo]

@9mm, I will check if there's some bug with the environment variable parsing or something

[9mm]

Sorry I hit enter too soon, but went back and edited. It seems it works if its on the same line of the command, but not if its in a bash script with export. I feel like I am just making a dumb mistake. i do know it used to work though

[fredizzimo]

@9mm, I see it's this condition in the code:

    // Never fork unless a tty is attached
    if !settings.fork || !utils::is_tty() {
        return;
    }

And because your script uses redirection > /dev/null 2>&1, it does not detect that a TTY is attached

[9mm]

Ahh... I see. Ok Ill try to figure out a better way to do it. Thank you!

[fredizzimo]

I think you can remove the /dev/null redirection, it should not print anything when it's forking anyway

[halostatue]

My request is simple: stop relying on Homebrew to provide a macOS launcher script.

The Homebrew script is not correct. Whether you like it or not, when people install neovide they expect that you are responsible for the installed programs.

Neovide should be providing this launcher script like VS Code and MacVim do.