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

32335Re: Output/Input is not to/from a terminal

Expand Messages
  • Walter Briscoe
    May 1, 2003
      In message <20030501023953.GP30778@...> of Wed, 30 Apr 2003
      22:39:53 in , Andrew Pimlott <vim-dev@...> writes
      >On Wed, Apr 30, 2003 at 02:11:59PM +0100, Walter Briscoe wrote:
      >> :help todo contains
      >> 7 Allow using Vim in a pipe: "ls | vim -u xxx.vim - | yyy". Only needs
      >> implementing ":w" to stdout in the buffer that was read from stdin.
      >I had no idea this was a todo, and I didn't look at your
      >implementation, but I've done this. I use a wrapper script to map
      >some file descriptors, and a vim script to write the stdin buffer
      >when it's unloaded. It's a quick hack, but do you see any problem
      >with it is principle?
      >I made :bunload, not :w, write the buffer to stdout, since my
      >intuition is that you're only "happy" with the buffer when you close
      >it. Plus, I :w habitually, and wouldn't want this to write to
      >stdout. What would happen if you :w twice?
      This work is in a narrower context than vim itself which interested me.
      It looks good to me. It was interesting to see getopt (singular name)
      deal with long option names. I think IEEE Std 1003.1-2001 does not have
      getopt in that context. It has getopts (plural name) without the ability
      to handle long option names.
      Walter Briscoe
    • Show all 6 messages in this topic