On 5/24/06, Mun Johl <[EMAIL PROTECTED]> wrote:
Hi Eric, et al.,
Thanks for your reply.
I'm sorry for the delay in my response. I was not ignoring your reply;
rather I was trying to gather data to better answer your questions.
Please see my comments below.
On Wed, May 17, 2006 at 11:29 PM PDT, Eric Arnold wrote:
EA> It would be helpful to know more about whether any particular keys are
EA> problematic, and when you are having the trouble.
It "seems" kind of random; and because it's intermittent it's kind of
hard to isolate. Here's some new data though, I am now seeing the same
issue once in a while on my Solaris 8 system--that is, without even
running Exceed. I'm suspecting that something may be wrong with my gtk
installation or something. BTW, my GTK version is 1.2.10 .
In any case, I just saw this problem on one of my files. And it seems
to be more prevalent on the search line then when actually entering text
into the file. For example, on the search line I typed the alphabet and
here's what was echoed:
abdfgijkmoqsuvwyz
But when I inserted the alphabet into the body of the file, all
characters were present. Also, on the search line, if 'a' is not
entered as the first character, then it won't display either.
I asked the question because it sounds like the problem is either
1) something is not transmitting the key
2) something is eating the key
First of all, I'll assume that you've checked that your keyboard isn't wonky.
If the case is 2), the main culprits are usually mappings or
abbreviations which are grabbing the key for something.
If the "a" key is consistently not received except in the first
column, then you have something non-intermittent to play with.
Interestingly, I just noticed that I typically see this behavior when
the filetype is not set ("filetype="). I set the filetype=mail on the
problematic file, and the problem went away. I did not close and reopen
the file either. So I guess it's not an Exceed or GTK issue after all.
Possibly, if the problem is consistently fixed by changing the
filetype. It would be good to know what the filetype is when you are
having the problem. If it is a specific filetype, then you have a
clue. If it isn't specific, and all that's required is to switch from
any filetype to any filetype, then it's not as helpful. Though it
would indicate that something is amiss with
syntax/autocommands/mappings.
EA> Also, it isn't clear exactly how you are starting gvim, maybe because
EA> it's been a while since I've tried this. Are you starting the Win32
EA> version, and asking it to connect to the Sun X server via the Exceed X
EA> server? Or visa versa? I.e. remotely logging into one, and setting
EA> the DISPLAY to other.
In that scenario, I'd be logged in on my PC and start the Exceed X
server. Then, I'd open a terminal on my Sun box and export the terminal
to my PC. From that terminal I'd issue a vim -g command and export the
vim window to my PC.
Try starting an Xterm on the Sun, displayed to the pc, and running the
non-gui vim through the Xterm.
But--as mentioned above--I no longer believe Exceed or GTK are possible
suspects. Maybe I should be looking at my plugins or something. I'll
I still hold out the possibility that you have a flow control problem
somewhere in the stream. Since ^S / ^Q are flow control characters
for some schemes, and ^Q in Vim will eat characters (if exchanged with
^V with the mswin behavior), it is a suspect.
You could try mapping all of ^S/^Q/^V/^K to something like <ESC>, and
see if that helps. (^K is the compose command).
Also, if you are using a multibyte setup, you have to consider whether
th InputManager is a problem.
at least check the filetype every time I see this issue to see if I can
find a correlation.
One thing you should try if you haven't already is
gvim -u NONE -U NONE --noplugin
which should give you a clean process to play with (annoying clean,
actually...you probably want to set nocp at least).
--
Mun
EA> In any case, it's going to be helpful to know which binary type is
EA> running where and how.
EA>
EA> Are there any other applications running at the same time? Especially gtk?
EA>
EA> If it takes it as a multi-byte character, it also suggests that
EA> something might be adding some characters into the stream, i.e. the
EA> compose ^K or literal ^V or ^Q characters. Often, ^Q is part of a
EA> stream start/stop flow control sequence.
EA>
EA> If you can try any other gtk applications to see if they work, and a
EA> different X server than Exceed, it would help you narrow the problem
EA> down.
EA>
EA>
EA> On 5/17/06, Mun Johl <[EMAIL PROTECTED]> wrote:
EA> >Hi,
EA> >
EA> >This probably isn't a gvim issue, but I thought I'd ask the community for
EA> >input since other avenues have not yet yielded positive results.
EA> >
EA> >Here's the issue: I am using Hummingbird Exceed 2006 to log into my Sun
EA> >Sparc Solaris 8 system. From there, I am opening a gvim window which
EA> >was compiled using the gtk libraries. On the Solaris system, it works
EA> >fine. But when using gvim through exceed, I get an odd behavior: I
EA> >often have to enter each character twice in order for it to show up in
EA> >the window. And sometimes gvim will take that as a multi-bye character.
EA> >
EA> >I don't know if this is a gvim issue, Exceed issue, gtk issue, or what;
EA> >but since the application works fine on the Solaris system itself, I
EA> >thought blaming Exceed would be the logical choice. But I have not yet
EA> >been able to give Hummingbird sufficient data to track down the problem.
EA> >
EA> >Also note that if I compile gvim using Motif libraries instead of gtk,
EA> >then a gvim window opened through Exceed works correctly.
EA> >
EA> >Anyone ever see anything like this? Or have any ideas towards a
EA> >solution?
EA> >
EA> >Thanks in advance.
EA> >
EA> >Best regards,
EA> >
EA> >--
EA> >Mun
EA> >
