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

Vim on Mac: What's NeXT? ;)

Expand Messages
  • Dany St-Amant
    Hi, It s probably time for a quick survey as I don t seem to work on what people want. What should be the priority work done in Vim for Mac? (You can also
    Message 1 of 5 , Nov 6, 2001
    • 0 Attachment
      Hi,

      It's probably time for a quick survey as I don't seem to work on what
      people want.
      What should be the priority work done in Vim for Mac?
      (You can also answer as: who what to do what?)

      -Dialog boxes?
      (currently in progress)
      -Drop to shell?
      (Huh? this currently work on my development stream can't believe it)
      -pre-MacOS X bug: filename weirdness?
      -Terminal/Carbon combo version?
      -Find/Replace/Font Selection dialogs?
      - --remote from Terminal.app for Carbon?
      -Toolbar?
      (Seem easy as 123 in Cocoa, but in Carbon, yikes)
      -Cocoa version?
      (who come first main.c or gui_carbon.m? Any NeXT expert around?)
      -Terminal/Motif/Carbon combo version?
      (could ask the main stream for a Motif/GTK version first)

      Other main concern?

      Dany
    • gmark@svs.com
      ... Yeah, we ve been meaning to complain about that! :-) ... I don t understand that comment, but having VIM be able to drop to the shell (preferably the
      Message 2 of 5 , Nov 6, 2001
      • 0 Attachment
        On Tuesday, November 6, 2001, at 09:01 PM, Dany St-Amant wrote:

        > Hi,
        >
        > It's probably time for a quick survey as I don't seem to work on what
        > people want.
        > What should be the priority work done in Vim for Mac?

        Yeah, we've been meaning to complain about that! :-)
        > (You can also answer as: who what to do what?)
        >
        > -Dialog boxes?
        > (currently in progress)
        > -Drop to shell?
        > (Huh? this currently work on my development stream can't believe it)
        I don't understand that comment, but having VIM be able to drop to
        the shell (preferably the user-specified shell (ksh, bash, csh,
        whatever's
        running) would be excellent. Being able to actually run a shell command
        on a text buffer or file would be even better, doing it from VIM in a GUI
        environment would likely attract a LOT of attention, since it would give
        IMMEDIATE shell access from a GUI editor!

        Everything else pales after the shell stuff. It'd be a BIG draw for
        OSX users everywhere.

        G. Mark Stewart

        > -pre-MacOS X bug: filename weirdness?
        > -Terminal/Carbon combo version?
        > -Find/Replace/Font Selection dialogs?
        > - --remote from Terminal.app for Carbon?
        > -Toolbar?
        > (Seem easy as 123 in Cocoa, but in Carbon, yikes)
        > -Cocoa version?
        > (who come first main.c or gui_carbon.m? Any NeXT expert around?)
        > -Terminal/Motif/Carbon combo version?
        > (could ask the main stream for a Motif/GTK version first)
        >
        > Other main concern?
        >
        > Dany
        >
        >
      • Gregory Seidman
        Dany St-Amant sez: } Hi, } } It s probably time for a quick survey as I don t seem to work on what } people want. } What should be the priority work done in
        Message 3 of 5 , Nov 6, 2001
        • 0 Attachment
          Dany St-Amant sez:
          } Hi,
          }
          } It's probably time for a quick survey as I don't seem to work on what
          } people want.
          } What should be the priority work done in Vim for Mac?
          } (You can also answer as: who what to do what?)
          }
          } -Dialog boxes?
          } (currently in progress)

          Not vastly important to me.

          } -Drop to shell?
          } (Huh? this currently work on my development stream can't believe it)

          Er, this should work flawlessly in MacOS X. It is *high* priority.

          } -pre-MacOS X bug: filename weirdness?

          I don't know what that means. Colon as a separator or something?

          } -Terminal/Carbon combo version?

          What I'd really love is one binary capable of one of the OS X GUIs (Cocoa
          or Carbon), one of the X11 GUIs (Athena, Motif, or GTK), and the terminal
          non-GUI. It would make me happy to be able to ssh in and have the terminal
          frontend, run it from Terminal.app and have it pop up (having forked!) as a
          .app with a doc icon and all, and run it from an xterm and have it pop up
          on my X display. Determining which to do can be handled by checking certain
          environment variables (DISPLAY, and something else for the Terminal.app)
          and whether it was given a -psn commandline flag.

          Nonetheless, I consider it low priority, since several separate binaries
          can coexist nicely and use the same .vim files, and I can write a script to
          distinguish when to use which.

          } -Find/Replace/Font Selection dialogs?

          Font selection is desirable, but I don't care about dialogs for
          find/replace... :s is sufficient for that. And as long as there is some
          hacky way to change the font (e.g. mess with some file within the Vim.app
          directory tree), I don't need to change the font on the fly.

          } - --remote from Terminal.app for Carbon?

          Oh, yes please! Call it medium priority.

          } -Toolbar?
          } (Seem easy as 123 in Cocoa, but in Carbon, yikes)

          I don't care for the toolbar, myself.

          } -Cocoa version?
          } (who come first main.c or gui_carbon.m? Any NeXT expert around?)

          I consider this fairly high priority. I would really like to have things
          set up so that the Cocoa version is source-compatible with GNUstep.

          } -Terminal/Motif/Carbon combo version?
          } (could ask the main stream for a Motif/GTK version first)

          Oops, I talked about this above. A cool feature, but low priority.

          } Other main concern?

          I tend to use vim in several separate sessions. I do so because there is no
          support for multiple heads (what emacs calls frames and what every GUI
          toolkit calls windows) in a single session. Under MacOS X I would be likely
          to run Vim from Terminal.app multiple times, filling the dock with multiple
          Vim icons. I'd prefer to open another head with a file. First, though, we
          have to handle multiple heads in all the other frontends so there is a
          reasonable and consistent interface. I consider this the highest priority
          for vim development, on MacOS X or otherwise.

          } Dany
          --Greg
        • Dany St-Amant
          Le Mercredi 7 novembre 2001, à 12:32 , gmark@svs.com a écrit : [...[ ... My comment was live feedback ;). I did a quick :!sh and strangely, I got a shell. As
          Message 4 of 5 , Nov 7, 2001
          • 0 Attachment
            Le Mercredi 7 novembre 2001, à 12:32 , gmark@... a écrit :

            [...[
            >> -Drop to shell?
            >> (Huh? this currently work on my development stream can't believe it)
            > I don't understand that comment, but having VIM be able to drop to
            > the shell (preferably the user-specified shell (ksh, bash, csh,
            > whatever's
            > running) would be excellent. Being able to actually run a shell command
            > on a text buffer or file would be even better, doing it from VIM in a
            > GUI
            > environment would likely attract a LOT of attention, since it would give
            > IMMEDIATE shell access from a GUI editor!

            My comment was live feedback ;). I did a quick :!sh and strangely, I got
            a shell.
            As I didn't do any change (at least can't remember) in that area since
            the
            "Patch for shell.." I shipped on the 31st of October. This should be
            working since then.
            I didn't try the binary that Benji put on is iDisk,
            http://homepage.mac.com/fisherbb/
            (but I think he included that patch and compiled it with -DMACOS_X_UNIX
            (even though the patch is not a official vim patch as I did't got time
            to look
            at the type ahead possible bug.

            > Everything else pales after the shell stuff. It'd be a BIG draw for
            > OSX users everywhere.
            >
            > G. Mark Stewart
            >
            Dany
          • Florent Pillet
            ... About this, one of my friends developed a terminal emulator for Mac OS X which uses OpenGL in 2D mode to display the text. It is __much__ faster than the
            Message 5 of 5 , Nov 7, 2001
            • 0 Attachment
              on 7/11/01 4:01, Dany St-Amant at dany.stamant@... wrote:

              > -Terminal/Carbon combo version?

              About this, one of my friends developed a terminal emulator for Mac OS X
              which uses OpenGL in 2D mode to display the text. It is __much__ faster than
              the basic terminal rendering speed, because it goes direct to the
              acceleration hardware. A weird use for OpenGL, but definitely interesting
              for those who spend the whole work day in VIM (I do, on several platforms).

              --
              Florent Pillet, Code Segment Florent.Pillet@...
              PGP Key: D13C 6DD7 D0E2 7891 4AF9 0111 9514 4753 02F1 4D6D

              PowerGlot, the premier localization tool for Mac OS software
              -> PowerGlot Software http://www.powerglot.com/
              Sync Buddy for Mac & PalmOS. FindHack, SymbolHack for PalmOS
              -> ...and other tools... http://perso.wanadoo.fr/fpillet/
              BrainForest, outlines & action items for Palm, Mac & Windows
              -> http://www.aportis.com/
            Your message has been successfully submitted and would be delivered to recipients shortly.