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

new developer, longtime user

Expand Messages
  • Gregory Seidman
    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
    Message 1 of 6 , Oct 23, 2001
    • 0 Attachment
      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

      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)

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

      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)

      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 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.

      --Greg
    • 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 2 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 3 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 4 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 5 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 6 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.