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

Re: new developer, longtime user

Expand Messages
  • 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 1 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 2 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 3 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 4 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.