Loading ...
Sorry, an error occurred while loading the content.

InputManager wip

Expand Messages
  • Nico Weber
    Hi, attached is a patch that lets MacVim write to protected directories (for example /Library/InputManagers). The first two commits add a class called
    Message 1 of 3 , Feb 1, 2008
    View Source
    • 0 Attachment
      Hi,

      attached is a patch that lets MacVim write to protected directories
      (for example /Library/InputManagers).

      The first two commits add a class called `AuthorizedShellCommand` that
      can execute arbitrary shell commands and shows the standard
      authorization dialog before doing so (think "graphical sudo"). The
      third commit is only an example for how this class is used -- this
      commit shouldn't be applied to the official tree.

      With this class, we could literally execute the steps Bruno outlined
      (put the inputmanager somewhere in the macvim bundle, preferrably with
      the defaults preset to org.vim.MacVim, `cp -pR` it to /Library/
      InputManagers, `chmod -R root:admin` it, done). A "Install \"Edit in
      in MacVim\" Input Manager" button in the prefs would be a good first
      place to put this I think.

      Likewise, we could install the `mvim` script to `/usr/local/bin` (with
      a similar button). Are there comments on how the mvim script should
      behave? Since we would install it from withing MacVim, MacVim could
      basically just put

      exec <path to myself>/Contents/MacOS/Vim -g

      in the mvim file. Would there be any problems with this? Other
      suggestions?

      Nico


      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • björn
      ... I would not encourage fixed paths like this since an app bundle is supposed to be able to be moved around (of course, if you move the app bundle to some
      Message 2 of 3 , Feb 1, 2008
      View Source
      • 0 Attachment
        On 01/02/2008, Nico Weber <nicolasweber@...> wrote:
        > Hi,
        >
        > attached is a patch that lets MacVim write to protected directories
        > (for example /Library/InputManagers).
        >
        > The first two commits add a class called `AuthorizedShellCommand` that
        > can execute arbitrary shell commands and shows the standard
        > authorization dialog before doing so (think "graphical sudo"). The
        > third commit is only an example for how this class is used -- this
        > commit shouldn't be applied to the official tree.
        >
        > With this class, we could literally execute the steps Bruno outlined
        > (put the inputmanager somewhere in the macvim bundle, preferrably with
        > the defaults preset to org.vim.MacVim, `cp -pR` it to /Library/
        > InputManagers, `chmod -R root:admin` it, done). A "Install \"Edit in
        > in MacVim\" Input Manager" button in the prefs would be a good first
        > place to put this I think.
        >
        > Likewise, we could install the `mvim` script to `/usr/local/bin` (with
        > a similar button). Are there comments on how the mvim script should
        > behave? Since we would install it from withing MacVim, MacVim could
        > basically just put
        >
        > exec <path to myself>/Contents/MacOS/Vim -g
        >
        > in the mvim file. Would there be any problems with this? Other
        > suggestions?

        I would not encourage fixed paths like this since an app bundle is
        supposed to be able to be moved around (of course, if you move the app
        bundle to some exotic location then mvim fails anyway, but...).
        However, an item that "installs mvim" sounds fine to me.

        >
        > Nico
        >
        >
        > ps: The patches are numbered starting at 0003 because git is stronger
        > than me.
        > pps: Bjorn, any comments on the sparkle patch?

        Both patches look great...I will try to merge them this weekend.

        Thanks,
        Björn

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • björn
        ... I have no objections to that idea...the current mvim script does look overly complicated to me so I think your idea would make it look a bit neater.
        Message 3 of 3 , Feb 4, 2008
        View Source
        • 0 Attachment
          On 01/02/2008, Nico Weber <nicolasweber@...> wrote:
          >
          > > I would not encourage fixed paths like this since an app bundle is
          > > supposed to be able to be moved around (of course, if you move the app
          > > bundle to some exotic location then mvim fails anyway, but...).
          > > However, an item that "installs mvim" sounds fine to me.
          >
          > Only the mvim script would stop working if MacVim.app is moved, and
          > there's not much we can do about that anyways. The mvim script could
          > check if the Vim executable exists, and write a "can't find app, do
          > prefs->install mvim script in MacVim again" error message.

          I have no objections to that idea...the current mvim script does look
          overly "complicated" to me so I think your idea would make it look a
          bit neater. Would you mind sending me a patch with these ideas?

          I haven't gotten around to applying your patch for executing
          privileged commands yet...hopefully I'll get around to it this week.

          /Björn

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        Your message has been successfully submitted and would be delivered to recipients shortly.