vimsh/vimsh.vim

   1 " file:     vimsh.vim
   2 " purpose:  support file for vimsh, when sourced starts a vimsh buffer
   3 "
   4 " author:   brian m sturk   bsturk@adelphia.net,
   5 "                           http://users.adelphia.net/~bsturk
   6 " created:  12/20/01
   7 " last_mod: 01/31/04
   8 " version:  see vimsh.py
   9 "
  10 " usage:    :so[urce] vimsh.vim
  11
  12 function! VimShRedraw()
  13     redraw
  14 endfunction
  15
  16 "  Use ':VimshNewBuf name' to open a new buffer '_name_'
  17 command! -nargs=1 VimShNewBuf python spawn_buf( "_<args>_" )
  18
  19 " Only load vimsh.py once (don't reset variables)
  20 if !exists("g:vimsh_loaded_python_file")
  21     pyfile <sfile>:p:h/vimsh.py
  22     let g:vimsh_loaded_python_file=1
  23 endif
  24
  25 VimShNewBuf vimsh
  26
  27 "function! VimShReadUpdate()
  28
  29     "  This function is a workaround until I can find
  30     "  a way to periodically check for more output
  31     "  for commands that continuously output until
  32     "  interrupted ( ping ) or slow ones ( ftp ).
  33     "  An ideal solution would be to have a function
  34     "  registered to be called when vim is 'idle'.
  35     "
  36     "  I've tried all kinds of solutions:
  37     "
  38     "       Threading
  39     "
  40     "  Most of the time I see this:
  41     "
  42     "   %$ Xlib: unexpected async reply (sequence 0x33d5)!
  43     "   Gdk-ERROR **: X connection to :0.0 broken (explicit kill or server shutdown).
  44     "
  45     "       Autocommands
  46     "
  47     "           CursorHold doesn't work
  48     "           And defining a User one causes a stack-overflow
  49     "           in the regex engine, plus it's still a different
  50     "           thread trying to write and it causes above behavior.
  51     "
  52     "       SIGALRM
  53     "
  54     "           Works, but alarm is only 'realized' when executing
  55     "           python code, so until the user does something, like
  56     "           execute a command, we never see the signal.
  57     "
  58     "
  59     "  So this works and stays until I can
  60     "  do one of the above and have it work or some
  61     "  idle processing can be done.  The python script current
  62     "  does create another thread to check for more data to
  63     "  read but it *DOES NOT* write to the buffer, this causes
  64     "  all sorts of problems.  What happens is, if the conditions
  65     "  are right to check and there's more data to read this
  66     "  function is invoked via that thread using the client/
  67     "  server ability of vim.  It's a total hack, but it does
  68     "  work.
  69     "
  70     "  Being able to use this hackjob workaround depends
  71     "  on a few things being present.
  72     "
  73     "  If I've read the docs right all that client/server stuff
  74     "  goes through the X server, so this will not work
  75     "  in pure console mode.  We also need to be compiled
  76     "  with client/server support...
  77
  78     "if has( "gui_running" ) && has( "clientserver" )
  79
  80     "python vim_shell.page_output( 0 )
  81     "
  82     " Unfortunately this doesn't work well enough either, I still get
  83     " the async errors mentioned above and other nasty side effects
  84     " happen.  So I guess for now, <F5> it is to see more output.
  85
  86 "endfunction