allow for portable installation of Vim

[Konfekt]

If gvim is run as a portable application, say installed by scoop, for users without admin rights to access the HKCM branch of the registry, then the vim executable cannot be found. This commit lets Vimer find Vim in %PATH$ and by the environment variable %EDITOR%.

[Konfekt]

@susam : This should work now; it's just a fall back to %PATH% in case Vim was not installed as an admin, say by Scoop

[Konfekt]

@susam This also contains a commit to call gVim without remote arguments on first run to detach it from the cmd window ... with a refined check for whether the command was meant to let Vim open a file

[Konfekt]

@susam Is there anything left to do?

[susam]

Hi @Konfekt, Thank you for sending the pull request. It is unlikely I am going to merge this into my fork for reasons I have explained below. You are however very welcome to maintain these changes in your fork. My reasons for not merging are as follows:

• The scope of this PR seems to be too large that goes well beyond portability. For example, there are a lot of whitespace related changes which I have no intention of including in my fork. I prefer a certain way of indenting my code and I do not wish to change that.
• The script supports setting VIM_CMD to set arbitrary Vim paths for users who do not have admin rights on their system. This is the primary reason.
• There are two scripts in this project vimer for Unix/Linux and vimer.cmd for Windows. I have tried to maintain feature parity between the two scripts. Updating only vimer.cmd is going to break this feature parity between the two scripts. Now vimer.cmd is going to have an additional feature that vimer won't. This is the secondary reason but an important one nevertheless.

Sorry about not merging this! I am sure your new additions are very useful to you and it could potentially be useful to other users too but before merging it into my fork, I'll have to decide whether I am ready to incur the additional maintenance overhead associated with the new code and the additional work to maintain feature parity with vimer (the Unix/Linux script). My answer unfortunately happens to be negative in this case. Sorry!

[Konfekt]

Thank you!

The scope of this PR seems to be too large that goes well beyond portability. For example, there are a lot of whitespace related changes which I have no intention of including in my fork. I prefer a certain way of indenting my code and I do not wish to change that.

I am sorry, there must be a setting that ignores white space changes when using git diff. These were unintentional and don't reflect any personal preference of mine that I want to coerce. I reverted them in the latest commit.

The script supports setting VIM_CMD to set arbitrary Vim paths for users who do not have admin rights on their system. This is the primary reason.

This is also removed. Or did you refer to a check that ensures that the user must have admin rights to run Vim?

There are two scripts in this project vimer for Unix/Linux and vimer.cmd for Windows. I have tried to maintain feature parity between the two scripts. Updating only vimer.cmd is going to break this feature parity between the two scripts. Now vimer.cmd is going to have an additional feature that vimer won't. This is the secondary reason but an important one nevertheless.

I am not quite sure which feature you refer to that I'd happily port to the Unix version, though

[susam]

Thank you!

The scope of this PR seems to be too large that goes well beyond portability. For example, there are a lot of whitespace related changes which I have no intention of including in my fork. I prefer a certain way of indenting my code and I do not wish to change that.

I am sorry, there must be a setting that ignores white space changes when using git diff. These were unintentional and don't reflect any personal preference of mine that I want to coerce. I reverted them in the latest commit.

Thank you!

The script supports setting VIM_CMD to set arbitrary Vim paths for users who do not have admin rights on their system. This is the primary reason.

This is also removed. Or did you refer to a check that ensures that the user must have admin rights to run Vim?

I am referring to https://github.com/susam/vimer/blob/master/vimer.cmd#L42. The script tries to locate Vim on its own when the VIM_CMD environment variable is not set. However, if the VIM_CMD environment variable is set, then the script uses the path in this environment variable to launch Vim.

Information about this available in the vimer help too which can be printed as follows:

C:\>vimer -h
Usage: %NAME% [-t] [-s] [-e|-d] [-n] [-w] [-h] [-v] [-|FILE...]

This is a wrapper script to open files in existing GVim. If an
existing instance of GVim is running, the files are opened in it,
otherwise, a new GVim instance is launched. If no FILE is
specified, a new GVim instance is launched.

If this script cannot find GVim, set the VIM_CMD environment
variable with the command to execute GVim as its value.

...

So when I wrote this script for myself and published it on GitHub, I did consider that not everyone is going to have the Vim path registered in their system registry (or equivalently in one of the PATH paths on Unix/Linux). For such users, the VIM_CMD environment variable is supposed to serve as a way of telling vimer where the Vim executable is.

There are two scripts in this project vimer for Unix/Linux and vimer.cmd for Windows. I have tried to maintain feature parity between the two scripts. Updating only vimer.cmd is going to break this feature parity between the two scripts. Now vimer.cmd is going to have an additional feature that vimer won't. This is the secondary reason but an important one nevertheless.

I am not quite sure which feature you refer to that I'd happily port to the Unix version, though

I mean the new feature of detecting the EDITOR environment variable in Windows. Although this project of mine is a relatively obscure project, I have taken a lot of care testing the script across various operating systems and shells. I do not have the time now or in the foreseeable future to test substantial code changes to Vimer. This is what I meant by additional maintenance overhead.

Having said that, since you seem to be actively working on this enhancement, why not maintain it in your own fork and have potential users use your fork. I can link to your fork in my README if that would help.

[Konfekt]

Yes, I can maintain a competing fork, just to understand where the problem is:

So when I wrote this script for myself and published it on GitHub, I did consider that not everyone is going to have the Vim path registered in their system registry (or equivalently in one of the PATH paths on Unix/Linux). For such users, the VIM_CMD environment variable is supposed to serve as a way of telling vimer where the Vim executable is.

Looking at the code, my fork would try, before falling back to VIM_CMD, to look for gVim in $PATH, and then $EDITOR.

Would you accept looking for gVim in $PATH? As I understood

I mean the new feature of detecting the EDITOR environment variable in Windows. Although this project of mine is a relatively obscure project, I have taken a lot of care testing the script across various operating systems and shells. I do not have the time at this or in the foreseeable future to test substantial code changes to Vimer. This is what I meant by additional maintenance overhead.

the issue lies in a missing fallback to $EDITOR in the unix script?

My fork would then offer reading this environment variable as well on both platforms?

[Konfekt]

Regarding $PATH and feature parity, I am a bit confused as

#  vimer (lines 69-79)
find_vim()
{
    echo $EDITORS | tr : '\n' | while read -r v
    do
        if "$v" --version > /dev/null 2>&1
        then
            printf "%s" "$v"
            break
        fi
    done
}

seems to look for vim in $PATH ...

[Konfekt]

Okay, the unix shell script now also falls back to $EDITOR.

So my fork would differ in finding Vim by

• falling back to $PATH in Windows as well
• falling back to $EDITOR in Windows and Unix

Is that it?

[susam]

Okay, the unix shell script now also falls back to $EDITOR.

So my fork would differ in finding Vim by

* falling back to `$PATH` in Windows as well

* falling back to `$EDITOR` in Windows and Unix

Is that it?

Yes.

If VIM_CMD is unspecified in the Unix environment, then the script tries invoking gvim or mvim directly (thus implicitly defaulting to the first such command found in $PATH).

You are right about one thing in the previous comment that this behaviour is not uniform across both scripts, so after all, 100% feature parity does not exist right now, contrary to what I presumed.

Regardless, if you are going to maintain your better-maintained fork, you can of course resolve these differences at your own discretion.

Yes, it does look like your fork would offer two additional features: Falling back to %PATH% on Windows and falling back to $EDITOR/%EDITOR% on Unix/Windows.

[Konfekt]

Cool, so be it. Feel free to link to my fork, maybe using this description. I will add it to the Readme.

[Konfekt]

Well, I also removed the context menu entries on Windows (and Unix) as I was under the impression by the HKCR reg key that they require an administered machine?

[Konfekt]

Maybe there is another difference, as the Shell script, but not the batch script, opens Vim if no instance exists, whereas in this pull request Vim is opened on Microsoft Windows as well? I tried to compile the complete list in https://github.com/konfekt/vimer/#related

[Konfekt]

Good afternoon, maybe you could point out where it falls short?

[susam]

Sorry, I have not had a lot of time to stay up to date with this conversation, so thank you for bumping this thread up.

I have now added a link to your fork in this project's README at https://github.com/susam/vimer#current-development-status.

[Konfekt]

Thank you, I would not mind closing this pull request and conversation, but feel free to reopen.