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

gvim script hangs twm in pseudocolor display

Expand Messages
  • Shing-Fat Fred Ma
    Hello, I m not sure if this problem is inherently vim s, solaris s, windows, twm, or vnc. I use TightVNC 1.2.2 to connect to twm running on solaris 8. I ve
    Message 1 of 2 , Nov 28, 2002
    • 0 Attachment
      Hello,

      I'm not sure if this problem is
      inherently vim's, solaris's, windows,
      twm, or vnc.

      I use TightVNC 1.2.2 to connect to twm
      running on solaris 8. I've got a twm
      menu item set to call a script
      ~/bin/gvim, which consists of the
      following lines:

      #!/bin/SomeShell
      /Directory/of/gvim/executable/gvim \
      -N \
      -u /home/Me/.vimrc \
      -U /home/Me/.gvimrc $*

      This script works fine from the command
      line. If I invoke it using twm menus,
      it hangs the twm window manager if the
      display is pseudocolor (it is a VNC
      desktop). Twm doesn't respond at all
      until I kill the gvim related processes.
      I don't have this problem if the desktop
      is true-color.

      I've tried with csh, tcsh, and bash in
      place of SomeShell above. Note that
      twm shells out with "sh -c", but I can
      pass "csh -c gvim" to the "sh -c"
      command. (It doesn't have to be csh,
      can be any other shell). Due to my path
      arrangement, gvim resolves to the 3-line
      script above, which in turn invokes the
      gvim binary executable.

      No processes are taking up any CPU when
      it hangs.

      I compared the command-line behaviours
      on pseudocolor and true color displays.
      The only difference is that the pseudo-
      color display generates the error

      Vim: (ec1) Cannot allocate colormap
      entry, some colors may be incorrect

      The colormap problem might be alleviated
      by shutting down other applications (and
      restarting them after gvim), but that's
      a pain. It's faster just to use the
      command line to start gvim to avoid the
      hanging. But I'd like to get it working
      with twm menus, without changing any of
      the colors that took so long to
      finalize.

      I thought vim might be hanging because
      it has no place to print its error
      message when invoked from twm. So I
      redirected stderr and stdout to
      /dev/null. No luck.

      Does anyone have any ideas on this?

      Fred
      --
      Fred Ma, fma@...
      Carleton University, Dept. of Electronics
      1125 Colonel By Drive, Ottawa, Ontario
      Canada, K1S 5B6
    • Shing-Fat Fred Ma
      ... Hi, Chris, I only get the problem with pseudocolor, not with truecolor. First thing I tried was to use depth 16 with pseudocolor. I believe that you re
      Message 2 of 2 , Nov 30, 2002
      • 0 Attachment
        > Subject:
        > Re: gvim hangs
        > From:
        > Chris McKenzie <cjmckenzie@...>
        > Date:
        > Fri, 29 Nov 2002 12:32:24 -0800 (PST)
        > To:
        > vnc-tight-list@...
        >
        >
        >It sounds like a color depth problem. Try using a -depth 16 option (if
        >your machines support them) and not using a -bgr233. Before you do this,
        >you may need to edit your X config script and add in support for a 16 bit
        >server (even if the server graphics card or monitor can't handle it) I
        >remember a few years ago, that unless this was specified then running at a
        >depth higher then 8 (the classic default) would cause some mighty strange
        >meessages. In order to alleviate the server from trying to go to some
        >silly color depth it cannot handle, put the DefaultDepth 8 (or 4 or 2) in
        >the "Display" (I think) part of the X configuration file (usually either
        >/usr/lib/X11/XF86Config, /etc/XF86config or /etc/X11/XF86Config or on
        >solaris, kdmconfig . . . the fancy ncurses way of doing things) Also make
        >sure there are no major version conflicts between the client/server vncs.
        >I know how backward compatibility is sought and promissed, but you know how
        >complex systems can go . . .
        >
        >Sincerely,
        > Christopher J. McKenzie
        >
        > cjm@...
        > mckenzie@...
        > H: +1 818.9917724
        > C: +1 818.4293772
        > 1815 Mesa Ridge Ave
        > Westlake Village, CA 9136
        >
        Hi, Chris,

        I only get the problem with pseudocolor, not
        with truecolor. First thing I tried was to
        use depth 16 with pseudocolor. I believe that
        you're right, some funking around is needed
        with the X config files. This is the results:

        30/11/02 17:37:50 Protocol version supported 3.3
        30/11/02 17:37:50 Listening for VNC connections on TCP port 5905
        Fatal server error:
        Couldn't add screen

        Unfortunately, I'm not system admin,
        so I can't write those files. Also, on
        Solaris 8, that specific file doesn't seem
        to exist, but we do have a directory /usr/X
        linked to /usr/openwin. I searched for a
        similarly name file in that subtree:

        $$> find . -follow -name 'X*[Cc]onfig*'
        ./share/man/man3/XConfigureEvent.3
        ./share/man/man3/XConfigureRequestEvent.3
        ./share/man/man3/XConfigureWindow.3
        ./share/man/man3/XReconfigureWMWindow.3
        ./share/man/man3/XtConfigureWidget.3
        ./share/include/X11/extensions/XKBconfig.h
        ./share/include/Xau/extensions/XKBconfig.h
        ./server/etc/XpConfig
        ./include/X11/extensions/XKBconfig.h
        ./include/Xau/extensions/XKBconfig.h
        ./man/man3/XConfigureEvent.3
        ./man/man3/XConfigureRequestEvent.3
        ./man/man3/XConfigureWindow.3
        ./man/man3/XReconfigureWMWindow.3
        ./man/man3/XtConfigureWidget.3

        The closest one is Xpconfig, which is a
        directory containing file README and
        subdirectory C/ (neither looks like it's it).

        As a workaround, I've followed the attatched
        suggestion from a newsgroup respondent.

        Thanks,

        Fred
        --
        Fred Ma, fma@...
        Carleton University, Dept. of Electronics
        1125 Colonel By Drive, Ottawa, Ontario
        Canada, K1S 5B6
        ===========================================

        Date: Fri, 29 Nov 2002 19:46:58 -0500
        From: Shing-Fat Fred Ma <fma@...>
        Newsgroups: comp.editors,comp.windows.x,comp.unix.solaris
        Subject: Re: gvim script hangs twm in pseudocolor display

        Kip Rugger wrote:

        >Shing-Fat Fred Ma <fma@...> wrote:
        >
        >
        >>Hello,
        >>
        >>I'm not sure if this problem is
        >>inherently vim's, solaris's, windows,
        >>twm, or vnc.
        >>
        >>I use TightVNC 1.2.2 to connect to twm
        >>running on solaris 8. I've got a twm
        >>menu item set to call a script
        >>~/bin/gvim, which consists of the
        >>following lines:
        >>
        >> #!/bin/SomeShell
        >> /Directory/of/gvim/executable/gvim \
        >> -N \
        >> -u /home/Me/.vimrc \
        >> -U /home/Me/.gvimrc $*
        >>
        >>This script works fine from the command
        >>line. If I invoke it using twm menus,
        >>it hangs the twm window manager if the
        >>display is pseudocolor (it is a VNC
        >>desktop). Twm doesn't respond at all
        >>until I kill the gvim related processes.
        >>I don't have this problem if the desktop
        >>is true-color.
        >>
        >>
        >[snip]
        >
        >Twm waits for the menu entry to complete, so I think you want something
        >more like
        >
        > #!/bin/SomeShell
        > /Directory/of/gvim/executable/gvim \
        > -N \
        > -u /home/Me/.vimrc \
        > -U /home/Me/.gvimrc "$@" &
        >
        >or tighten up your .twmrc file
        >
        > "Gvim" f.exec "/Directory//gvim -N -u ~/.vimrc -U ~/.gvimrc &"
        >

        Thanks, Kip. It worked. Though I'm
        baffled as to why. The gvim binary
        executable doesnt' cause the command
        line to hang until the editting session is
        done.

        Fred

        --
        Fred Ma, fma@...
        Carleton University, Dept. of Electronics
        1125 Colonel By Drive, Ottawa, Ontario
        Canada, K1S 5B6
      Your message has been successfully submitted and would be delivered to recipients shortly.