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

Re: new developer, longtime user

Expand Messages
  • Benji Fisher
    ... Now that there is a version of OS X that seems to work (for me) I would like to see a GUI vim for it. (If only my poor old NeXT had lived to see this!)
    Message 1 of 6 , Oct 23, 2001
    • 0 Attachment
      Gregory Seidman wrote:
      >
      > Hey there. I'm trying to get ramped up on the vim codebase so I can achieve
      > the following goals:
      >
      > 1) a frontend for OpenStep/GNUstep/MacOS X, comparable to the Motif and GTK
      > frontends

      Now that there is a version of OS X that seems to work (for me) I would
      like to see a GUI vim for it. (If only my poor old NeXT had lived to see
      this!)

      > 2) supporting multiple frontends conveniently (this may be a build issue,
      > actually, but I'd like to be able to run 'gvim' under MacOS X and if
      > DISPLAY is defined it would use an X11 frontend and otherwise it would
      > use the Aqua frontend I want to build)

      I am not planning to run X on X (sorry) but I can see that this would be
      handy for those who do.

      > 3) support for what emacs calls multiple "frames" and what I would call
      > multiple windows except "windows" already means something else

      This has been suggested before. There are problems with it, starting
      with the problem of making it portable. The change in paradigm may be an even
      more serious problem. I do not think you will get much support with this, at
      least not from Bram.

      > 4) minor IPC features, mainly the option to deiconize and raise an
      > existing session when attempting to run vim on a file that is already
      > open in a running vim (this is more complicated than it sounds,
      > especially under X11)

      You can learn more than I know (if you have not already done so) by
      reading

      :help client-server

      > I don't know when I'll find the time to do all these things. I'd like to
      > know now, however, whether anyone is interested in these features and
      > whether any work has begun on any of them.

      I have almost never looked at vim's code, so I cannot offer much help,
      but I hope the comments are a little useful.

      > I hope it is acceptable to have sent this to both the main dev list and the
      > mac dev list, but since 1 and 2 are relevant to both it seemed appropriate.

      No problem for me: my mail filters are dumb enough that both copies went
      to the vim-dev folder, where they were put under the same thread.

      --Benji Fisher
    • Dany St-Amant
      ... Vim 6.0 under MacOS X can be compiled out-of-the-box from Terminal.app, with XonX (I only tried the Athena Widget), and with Carbon (need patch 6.0.018).
      Message 2 of 6 , Oct 23, 2001
      • 0 Attachment
        Le Mardi 23 octobre 2001, à 10:07 , Benji Fisher a écrit :

        > Gregory Seidman wrote:
        >>
        >> Hey there. I'm trying to get ramped up on the vim codebase so I can
        >> achieve
        >> the following goals:
        >>
        >> 1) a frontend for OpenStep/GNUstep/MacOS X, comparable to the Motif
        >> and GTK
        >> frontends
        >
        > Now that there is a version of OS X that seems to work (for me) I
        > would
        > like to see a GUI vim for it. (If only my poor old NeXT had lived to
        > see
        > this!)

        Vim 6.0 under MacOS X can be compiled out-of-the-box from Terminal.app,
        with XonX (I only tried the Athena Widget), and with Carbon (need patch
        6.0.018).
        [The X or Console version should still compile, it was so a few beta
        ago.]

        I do not believe it will be easy to provide a Cocoa interface, as it
        would probably
        require to create a Objective-C wrapper around Vim which would still
        allow us to
        scan the argument before entering that wrapper. Sounds scary to me.
        Maybe some
        NeXT guru could help solve that dilemma.

        The mains GUI thing missing from the Carbon version are:
        -the Toolbar: Which I didn't got time to look at, and consider as icing.
        -clean DialogBox: Which need to be really looked at.

        >> 2) supporting multiple frontends conveniently (this may be a build
        >> issue,
        >> actually, but I'd like to be able to run 'gvim' under MacOS X
        >> and if
        >> DISPLAY is defined it would use an X11 frontend and otherwise
        >> it would
        >> use the Aqua frontend I want to build)
        >
        > I am not planning to run X on X (sorry) but I can see that this
        > would be
        > handy for those who do.

        There's seem to even be a way to detect if an application is launch from
        the
        Finder.app or from Terminal.app. The Finder.app always use a -ppsn. So
        the
        auto selection could include the console version. Probably, to provide
        Carbon and Console mode will be the first step toward success.

        >> 3) support for what emacs calls multiple "frames" and what I would call
        >> multiple windows except "windows" already means something else
        >
        > This has been suggested before. There are problems with it,
        > starting
        > with the problem of making it portable. The change in paradigm may be
        > an even
        > more serious problem. I do not think you will get much support with
        > this, at
        > least not from Bram.

        There's a thread on vim-dev I didn't read yet which I think talk about
        this
        starting August 30th. 'mdi:- multiple document interface'

        >> 4) minor IPC features, mainly the option to deiconize and raise an
        >> existing session when attempting to run vim on a file that is
        >> already
        >> open in a running vim (this is more complicated than it sounds,
        >> especially under X11)
        >
        > You can learn more than I know (if you have not already done so) by
        > reading
        >
        > :help client-server

        The Carbon version support somewhat the Apple Event. So drag'n'drop file
        over Vim, or double-clicking a Vim file should raise Vim. But I didn't
        test yet
        for when Vim window is minimized into the Doc.

        >> I don't know when I'll find the time to do all these things. I'd like
        >> to
        >> know now, however, whether anyone is interested in these features and
        >> whether any work has begun on any of them.
        >
      • Eugene Lee
        ... [...] ... Actually, I would prefer a Cocoa port instead of a frontend. And if this could be done, a simple frontend to launch the Cocoa app would be
        Message 3 of 6 , Oct 23, 2001
        • 0 Attachment
          On Tue, Oct 23, 2001 at 10:56:12PM -0400, Dany St-Amant wrote:
          :
          : > Gregory Seidman wrote:
          : >>
          : >> Hey there. I'm trying to get ramped up on the vim codebase so I can
          : >> achieve the following goals:
          : >>
          : >> 1) a frontend for OpenStep/GNUstep/MacOS X, comparable to the Motif
          : >> and GTK frontends

          [...]

          : I do not believe it will be easy to provide a Cocoa interface, as it
          : would probably require to create a Objective-C wrapper around Vim
          : which would still allow us to scan the argument before entering that
          : wrapper. Sounds scary to me. Maybe some NeXT guru could help solve
          : that dilemma.

          Actually, I would prefer a Cocoa port instead of a frontend. And if
          this could be done, a simple frontend to launch the Cocoa app would be
          trivial I imagine.


          --
          Eugene Lee
          eugene@...
        • Bram Moolenaar
          ... Oh, you have my support for attempting to implement this, trying various alternatives and showing how it works. But I won t include anything unless I m
          Message 4 of 6 , Oct 24, 2001
          • 0 Attachment
            Benji Fisher wrote:

            > Gregory Seidman wrote:
            > > 3) support for what emacs calls multiple "frames" and what I would call
            > > multiple windows except "windows" already means something else
            >
            > This has been suggested before. There are problems with it, starting
            > with the problem of making it portable. The change in paradigm may be
            > an even more serious problem. I do not think you will get much
            > support with this, at least not from Bram.

            Oh, you have my support for attempting to implement this, trying various
            alternatives and showing how it works. But I won't include anything
            unless I'm convinced all major issues are taken care of (such as how to
            deal with typing ":" commands and what to do with their output. And can
            each frame be in a different mode?)

            --
            hundred-and-one symptoms of being an internet addict:
            246. You use up your free 100 hours in less than a week.

            /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
            ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
            \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
          • Zdenek Sekera
            ... That already should take care of a few of your weekends, Greg :-) But, no doubt, it would be a great feature. ... E.g. can t edit the same file in
            Message 5 of 6 , Oct 24, 2001
            • 0 Attachment
              Bram Moolenaar wrote:
              >
              > Benji Fisher wrote:
              >
              > > Gregory Seidman wrote:
              > > > 3) support for what emacs calls multiple "frames" and what I would call
              > > > multiple windows except "windows" already means something else
              > >
              > > This has been suggested before. There are problems with it, starting
              > > with the problem of making it portable. The change in paradigm may be
              > > an even more serious problem. I do not think you will get much
              > > support with this, at least not from Bram.
              >
              > Oh, you have my support for attempting to implement this, trying various
              > alternatives and showing how it works. But I won't include anything
              > unless I'm convinced all major issues are taken care of (such as how to
              > deal with typing ":" commands and what to do with their output. And can
              > each frame be in a different mode?)

              That already should take care of a few of your weekends, Greg :-)
              But, no doubt, it would be a great feature.

              Neil Bird wrote:

              > Maybe I'm being dense, but how would a multi-headed gvim
              > actually differ from merely running multiple gvims?

              E.g. can't edit the same file in different gvim's, can't share
              registers,
              marks, what have you....and surely more.

              ---Zdenek
            Your message has been successfully submitted and would be delivered to recipients shortly.