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

NyaoVim always starts with two open buffers #140

Open
unode opened this issue May 2, 2018 · 0 comments
Open

NyaoVim always starts with two open buffers #140

unode opened this issue May 2, 2018 · 0 comments

Comments

@unode
Copy link

unode commented May 2, 2018

When I start NyaoVim, even if I don't specify a file/folder, the first buffer to be opened is always the path <prefix>/lib/node_modules/nyaovim, where <prefix> is the location where I installed NyaoVim.

The problem is caused by the code:

if ('electron' === basename(remote.process.argv[0]).toLowerCase()) {

which only works if the binary is called electron. This is fragile and can break easily.

When running on NixOS by the time the code above runs the binary is actually .electron-wrapped, resulting in electron_argc = 1 which in turn causes <prefix>/lib/node_modules/nyaovim to be kept as 2nd argument.

On my system, since the folder where the binary lives is called electron I worked around the problem by using:

    if ('electron' === basename(remote.process.argv[0]).toLowerCase()) {
        electron_argc = 2;
    }
    else if ('electron' === basename(dirname(remote.process.argv[0])).toLowerCase()) {
        electron_argc = 2;
    }

however this is equally fragile...

As I understand, the goal here is to distinguish between the two execution modes, NyaoVim.app and electron. Can this be fixed by some other means instead of matching the name of the binary?

@unode unode changed the title NyaoVim always starts with two buffers open and <prefix>/lib/node_modules/nyaovim first NyaoVim always starts with two open buffers May 2, 2018
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

1 participant