I am thinking, based on some input from Danek, the best approach at
this point is to create an additional gvim package, that basically
just provides a gvim binary, and relies on the vim package for
everything else. (Basically the original plan)

(For know forgoing the additional language bindings until we get a
chance to test dynamic bindings. I will start research on that front
in the mean time.)

Thanks,
Brian

On Wed, Aug 13, 2008 at 1:35 PM, Brian Gupta <brian.gupta at gmail.com> wrote:
> I'm not really sure the emacs solution is the right technical solution
> for vim. By default when you build vim with gvim, pretty much
> everything is a symlink to the vim binary, and the vim binary uses $0
> to determine how it was called.
>
> In other words the current vim has the following interfaces:
>   /usr/bin/rview            Uncommitted          Symbolic link
> location (link to vim)
>   /usr/bin/rvim             Uncommitted          Symbolic link
> location (link to vim)
>   /usr/bin/vimdiff          Uncommitted          Symbolic link
> location (link to vim)
>   /usr/bin/vimtutor         Uncommitted          Symbolic link
> location (link to vim)
>
>   /usr/bin/vim              Uncommitted          Executable location
>   /usr/bin/xxd              Uncommitted          Executable location
>
>   /usr/share/vim/vim70      Uncommitted          Directory for bundled
>                                                  extensions
>   /usr/share/vim/vimfiles   Uncommitted          Directory for unbundled
>                                                  extensions
>
> In a "typical" install from source gvim would just be another symlink
> pointing at the vim binary that has graphics support compiled in.
>
> My feeling is that on an individual system people are going to want to
> install a binary with graphics support, or one without. (Whether it
> runs with graphics support is already addressed by how you call it,
> which seems a bit different than in the case of emacs. IE: there is no
> gemacs symlink to emacs)
>
> These issues also lead me to question whether linking gtk is
> appropriate. (vs. lowest common denominator X11). (I have ruled out
> linking to gnome itself, but that is on the table for discussion).
>
> Since I plan to list all interfaces as Uncommitted anyway, I don't
> know if a final resolution of alternate packages is required to submit
> this case, but it might be a good time to discuss.)
>
> -Brian
>
> On Wed, Aug 13, 2008 at 12:03 PM, Nicolas Williams
> <Nicolas.Williams at sun.com> wrote:
>> See PSARC/2008/494 GNU emacs, which uses a script for 'emacs' to choose
>> betwee X11 and non-X11 variants.
>>
>> Nico
>> --
>>
>
> --
> - Brian Gupta
>
> http://opensolaris.org/os/project/nycosug/
>
> http://www.genunix.org/wiki/index.php/OpenSolaris_New_User_FAQ
>



-- 
- Brian Gupta

http://opensolaris.org/os/project/nycosug/

http://www.genunix.org/wiki/index.php/OpenSolaris_New_User_FAQ

Reply via email to