I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed

Mun Johl
Hi,

This probably isn't a gvim issue, but I thought I'd ask the community for
input since other avenues have not yet yielded positive results.

Here's the issue: I am using Hummingbird Exceed 2006 to log into my Sun
Sparc Solaris 8 system.  From there, I am opening a gvim window which
was compiled using the gtk libraries.  On the Solaris system, it works
fine.  But when using gvim through exceed, I get an odd behavior: I
often have to enter each character twice in order for it to show up in
the window.  And sometimes gvim will take that as a multi-bye character.

I don't know if this is a gvim issue, Exceed issue, gtk issue, or what;
but since the application works fine on the Solaris system itself, I
thought blaming Exceed would be the logical choice.  But I have not yet
been able to give Hummingbird sufficient data to track down the problem.

Also note that if I compile gvim using Motif libraries instead of gtk,
then a gvim window opened through Exceed works correctly.

Anyone ever see anything like this?  Or have any ideas towards a
solution?

Thanks in advance.

Best regards,

--
Mun
Reply | Threaded
Open this post in threaded view
|

Re: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed

Eric Arnold-3
It would be helpful to know more about whether any particular keys are
problematic, and when you are having the trouble.

Also, it isn't clear exactly how you are starting gvim, maybe because
it's been a while since I've tried this.  Are you starting the Win32
version, and asking it to connect to the Sun X server via the Exceed X
server?  Or visa versa?  I.e. remotely logging into one, and setting
the DISPLAY to other.

In any case, it's going to be helpful to know which binary type is
running where and how.

Are there any other applications running at the same time?  Especially gtk?

If it takes it as a multi-byte character, it also suggests that
something might be adding some characters into the stream, i.e. the
compose ^K or literal ^V or ^Q characters.  Often, ^Q is part of a
stream start/stop flow control sequence.

If you can try any other gtk applications to see if they work, and a
different X server than Exceed, it would help you narrow the problem
down.


On 5/17/06, Mun Johl <[hidden email]> wrote:

> Hi,
>
> This probably isn't a gvim issue, but I thought I'd ask the community for
> input since other avenues have not yet yielded positive results.
>
> Here's the issue: I am using Hummingbird Exceed 2006 to log into my Sun
> Sparc Solaris 8 system.  From there, I am opening a gvim window which
> was compiled using the gtk libraries.  On the Solaris system, it works
> fine.  But when using gvim through exceed, I get an odd behavior: I
> often have to enter each character twice in order for it to show up in
> the window.  And sometimes gvim will take that as a multi-bye character.
>
> I don't know if this is a gvim issue, Exceed issue, gtk issue, or what;
> but since the application works fine on the Solaris system itself, I
> thought blaming Exceed would be the logical choice.  But I have not yet
> been able to give Hummingbird sufficient data to track down the problem.
>
> Also note that if I compile gvim using Motif libraries instead of gtk,
> then a gvim window opened through Exceed works correctly.
>
> Anyone ever see anything like this?  Or have any ideas towards a
> solution?
>
> Thanks in advance.
>
> Best regards,
>
> --
> Mun
>
Reply | Threaded
Open this post in threaded view
|

Re: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed

Mun Johl
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.

....

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.

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.

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
at least check the filetype every time I see this issue to see if I can
find a correlation.

--
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 <[hidden email]> 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> >
Reply | Threaded
Open this post in threaded view
|

Re: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed

Eric Arnold-3
On 5/24/06, Mun Johl <[hidden email]> 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 <[hidden email]> 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> >
>
Reply | Threaded
Open this post in threaded view
|

Re: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed

Mun Johl
Hi Eric,

Please see my comments below.

On Wed, May 24, 2006 at 04:03 PM PDT, Eric Arnold wrote:

... Text Deleted ...

EA> >here's what was echoed:
EA> >
EA> >abdfgijkmoqsuvwyz
EA> >
EA> >But when I inserted the alphabet into the body of the file, all
EA> >characters were present.  Also, on the search line, if 'a' is not
EA> >entered as the first character, then it won't display either.
EA>
EA>
EA> I asked the question because it sounds like the problem is either
EA> 1) something is not transmitting the key
EA> 2) something is eating the key
EA>
EA> First of all, I'll assume that you've checked that your keyboard isn't
EA> wonky.

Correct; keyboard is not wonky.

EA> If the case is 2), the main culprits are usually mappings or
EA> abbreviations which are grabbing the key for something.
EA>
EA> If the "a" key is consistently not received except in the first
EA> column, then you have something non-intermittent to play with.

I'm seeing behavior that is kind of all over the place when I compile
with gtk.  For example, some chars don't show up when typed as part of
the search text; but they do show up if I type them as part of a command
entry string.

EA> >Interestingly, I just noticed that I typically see this behavior when
EA> >the filetype is not set ("filetype=").  I set the filetype=mail on the
EA> >problematic file, and the problem went away.  I did not close and reopen
EA> >the file either.  So I guess it's not an Exceed or GTK issue after all.
EA>
EA> Possibly, if the problem is consistently fixed by changing the
EA> filetype.

Sadly, new data shows that the changing the filetype to mail does not
always work after all.  At this time, I have no data correlating the
issue to a specific filetype.

EA> >In that scenario, I'd be logged in on my PC and start the Exceed X
EA> >server.  Then, I'd open a terminal on my Sun box and export the terminal
EA> >to my PC.  From that terminal I'd issue a vim -g command and export the
EA> >vim window to my PC.
EA>
EA> Try starting an Xterm on the Sun, displayed to the pc, and running the
EA> non-gui vim through the Xterm.

I'm currently trying to get my system updated to GTK-2, to see if that
helps.  Once I get the running, and if I still see the issue, I'll try
your suggestion.

EA> >But--as mentioned above--I no longer believe Exceed or GTK are possible
EA> >suspects.  Maybe I should be looking at my plugins or something.  I'll
EA>
EA> I still hold out the possibility that you have a flow control problem
EA> somewhere in the stream.  Since ^S / ^Q are flow control characters
EA> for some schemes, and ^Q in Vim will eat characters (if exchanged with
EA> ^V with the mswin behavior), it is a suspect.

But then I would of expected the same issue when compiled with Motif.

EA> One thing you should try if you haven't already is
EA>
EA> gvim -u NONE -U NONE --noplugin
EA>
EA> which should give you a clean process to play with (annoying clean,
EA> actually...you probably want to set nocp at least).

Another good idea; I haven't tried this yet simply because I almost
can't use vim without all of my customizations.  But I'll keep it in
mind after the GTK-2 effort.

Regards,

--
Mun
Reply | Threaded
Open this post in threaded view
|

laststatus=2 anomaly (was: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed)

Mun Johl
In reply to this post by Mun Johl
Hi,

After taking a couple of helpful hints from Eric, and doing a bunch of
experiments, I have isolated some odd behavior to 'laststatus'.

As a reminder, this issue only shows up when I compile vim7 using GTK-1;
it does not occur when I compile with Motif or GTK-2.  My system is a
Sun workstation running Solaris 8 and I use gcc 3.3.2 for compilation.

The problem is that when I compile vim7 using GTK-1, certain characters
need to be typed twice on the _search_ line.  Note that it only appears
as if the search line is affected.  Text entry and command entry don't
appear to be affected.

If I set laststatus to 0 or 1, the problem goes away.  If I set it to 2
again, the problem re-appears.

This doesn't always occur either; some files edit just fine.  So there
is some other dependency as well it seems--but I haven't discovered that
yet.  But, when it does occur, changing laststatus to 0 or 1 always
corrects the issue.

Here's a sample of what I get when I type each letter in the English
alphabet twice in a row (e.g.: aabbccddeeff...):

abbcdeffgghijjkklmmnopqqrßtuvvww×yzz
                         ^
                         |
                         this is the greek Beta character (in case it
                         got lost in the transmission)

Notice how some characters only show up once, and the one greek
character.

Any insights would be appreciated.

Regards,

--
Mun
Reply | Threaded
Open this post in threaded view
|

Re: laststatus=2 anomaly (was: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed)

Eric Arnold-3
On 6/2/06, Mun Johl <[hidden email]> wrote:
> Hi,
>
> After taking a couple of helpful hints from Eric, and doing a bunch of
> experiments, I have isolated some odd behavior to 'laststatus'.
>
> As a reminder, this issue only shows up when I compile vim7 using GTK-1;
> it does not occur when I compile with Motif or GTK-2.  My system is a
> Sun workstation running Solaris 8 and I use gcc 3.3.2 for compilation.

Have you tried both gvim and vim via an xterm?

> The problem is that when I compile vim7 using GTK-1, certain characters
> need to be typed twice on the _search_ line.  Note that it only appears
> as if the search line is affected.  Text entry and command entry don't
> appear to be affected.

I forgot, are you now testing with   gvim -u NONE -U NONE   ?  You
need to be sure that there aren't any plugins or mappings involved.

> If I set laststatus to 0 or 1, the problem goes away.  If I set it to 2
> again, the problem re-appears.

Does the problem correlate to the presence or absence of the displayed
statusline?
I.e. can you have  'laststatus' at '1', and have two or more windows
split so that a statusline is displayed.

Do you have anything interesting in the 'statusline' option?


> This doesn't always occur either; some files edit just fine.  So there
> is some other dependency as well it seems--but I haven't discovered that
> yet.  But, when it does occur, changing laststatus to 0 or 1 always
> corrects the issue.


Is incremental search on?

Also, you could do a binary search (i.e. chop it up into chunks) on an
affected file to try to find out what text is triggering it.


> Here's a sample of what I get when I type each letter in the English
> alphabet twice in a row (e.g.: aabbccddeeff...):
>
> abbcdeffgghijjkklmmnopqqrßtuvvww×yzz
>                          ^
>                          |
>                          this is the greek Beta character (in case it
>                          got lost in the transmission)
>
> Notice how some characters only show up once, and the one greek
> character.


Too weird.



> Any insights would be appreciated.
>
> Regards,
>
> --
> Mun
>
Reply | Threaded
Open this post in threaded view
|

Re: laststatus=2 anomaly (was: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed)

Mun Johl
Hi Eric,

Please see my comments below.

On Fri, Jun 02, 2006 at 10:42 AM PDT, Eric Arnold wrote:
EA> On 6/2/06, Mun Johl <[hidden email]> wrote:
EA> >Hi,
EA> >
EA> >After taking a couple of helpful hints from Eric, and doing a bunch of
EA> >experiments, I have isolated some odd behavior to 'laststatus'.
EA> >
EA> >As a reminder, this issue only shows up when I compile vim7 using GTK-1;
EA> >it does not occur when I compile with Motif or GTK-2.  My system is a
EA> >Sun workstation running Solaris 8 and I use gcc 3.3.2 for compilation.
EA>
EA> Have you tried both gvim and vim via an xterm?

Note that I am no longer going through Exceed; rather I'm running right
on my Sun box.  So on my Sun box I have tried running vim within my
dtterm.  As expected, there is no problem when running vim within the
dtterm.

EA> >The problem is that when I compile vim7 using GTK-1, certain characters
EA> >need to be typed twice on the _search_ line.  Note that it only appears
EA> >as if the search line is affected.  Text entry and command entry don't
EA> >appear to be affected.
EA>
EA> I forgot, are you now testing with   gvim -u NONE -U NONE   ?  You
EA> need to be sure that there aren't any plugins or mappings involved.

I did try that, and I didn't see the issue after doing so.  After that,
I started homing in on whether it was the loading .gvimrc or .vimrc that
caused the problem; and then which line(s) until I finally landed on my
laststatus setting.

EA> >If I set laststatus to 0 or 1, the problem goes away.  If I set it to 2
EA> >again, the problem re-appears.
EA>
EA> Does the problem correlate to the presence or absence of the displayed
EA> statusline?

Yes.  If 'laststatus' is 1 and I split the window, the problem shows up.
But depending on what file is in the new split window, that window my
not experience the problem.  But if I have a "problematic" file in both
split windows, they will both experience the problem.

Also, the same file will not _always_ have the problem.  It seems that
if I set 'laststatus' to 0 or 1 and then exit and re-open the file with
'laststatus' == 2, I don't see the problem.  So I guess that implies
that the .viminfo file has some influence.  But setting 'laststatus' to
2 and exiting/re-entering doesn't always bring the problem back.  Sigh.

EA> I.e. can you have  'laststatus' at '1', and have two or more windows
EA> split so that a statusline is displayed.
EA>
EA> Do you have anything interesting in the 'statusline' option?

I commented out my specific 'statusline' settings for most of the
testing; so that does not seem to make a difference.

EA> >This doesn't always occur either; some files edit just fine.  So there
EA> >is some other dependency as well it seems--but I haven't discovered that
EA> >yet.  But, when it does occur, changing laststatus to 0 or 1 always
EA> >corrects the issue.
EA>
EA>
EA> Is incremental search on?

Yes.  But, if I turn it off the problem disappears!  If I turn it on
again, the problem reappears.

EA> Also, you could do a binary search (i.e. chop it up into chunks) on an
EA> affected file to try to find out what text is triggering it.

Heh, wait until you hear this... I took a file that at the time was
experiencing the problem.  I finally got it to the point that if the
file contained the single character "3", then no problem.  But if the
file had two characters "3.", I'd hit the problem.  Other experiments
showing file contents and whether or not I saw a problem:

   "33"   : No problem
   "33."  : Problem
   "33.3" : Problem
   "333"  : No Problem

I realize there are MANY other combinations to try; but I don't have
that kind of time :)

EA> >Here's a sample of what I get when I type each letter in the English
EA> >alphabet twice in a row (e.g.: aabbccddeeff...):
EA> >
EA> >abbcdeffgghijjkklmmnopqqrßtuvvww×yzz
EA> >                         ^
EA> >                         |
EA> >                         this is the greek Beta character (in case it
EA> >                         got lost in the transmission)
EA> >
EA> >Notice how some characters only show up once, and the one greek
EA> >character.
EA>
EA>
EA> Too weird.

Agreed.

--
Mun
Reply | Threaded
Open this post in threaded view
|

Re: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed

Charles E Campbell Jr
In reply to this post by Mun Johl
Mun Johl wrote:

>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 .
>  
>
I suggest narrowing down the problem.

vim -u NONE -U NONE

for starters.   Then try to source in a minimal file (I believe you
mentioned something about laststatus).
If you get the double strike effect,  you've got something that others
have a chance at duplicating, and in particular,
Bram M has a shot at fixing.

If not, try to include bits and pieces of your .vimrc until you find the
problematic settings.  Does the laststatus setting
cause problems by itself?

Regards,
Chip Campbell

Reply | Threaded
Open this post in threaded view
|

Re: laststatus=2 anomaly (was: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed)

Karl Guertin
In reply to this post by Mun Johl
On 6/2/06, Mun Johl <[hidden email]> wrote:
> abbcdeffgghijjkklmmnopqqrßtuvvww×yzz
>                          ^
>                          |
>                          this is the greek Beta character (in case it
>                          got lost in the transmission)
>

That's not a beta, that's a german double s (forget what it's called).
Reply | Threaded
Open this post in threaded view
|

Re: laststatus=2 anomaly

Russell Bateman
Eszett; takes the place of ss and sz in German.

Karl Guertin wrote:

> On 6/2/06, Mun Johl <[hidden email]> wrote:
>> abbcdeffgghijjkklmmnopqqrßtuvvww×yzz
>>                          ^
>>                          |
>>                          this is the greek Beta character (in case it
>>                          got lost in the transmission)
>>
>
> That's not a beta, that's a german double s (forget what it's called).
>
>

Reply | Threaded
Open this post in threaded view
|

Re: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed

Charles E Campbell Jr
In reply to this post by Charles E Campbell Jr
Charles E Campbell Jr wrote:

> I suggest narrowing down the problem.
>
> vim -u NONE -U NONE
>
> for starters.   Then try to source in a minimal file (I believe you
> mentioned something about laststatus).
> If you get the double strike effect,  you've got something that others
> have a chance at duplicating, and in particular,
> Bram M has a shot at fixing.
>
> If not, try to include bits and pieces of your .vimrc until you find
> the problematic settings.  Does the laststatus setting
> cause problems by itself?

I should've also requested that you send a copy of such a minimalest
setup that causes the problem to the list.

Regards,
Chip Campbell

Reply | Threaded
Open this post in threaded view
|

Re: laststatus=2 anomaly

A.J.Mechelynck
In reply to this post by Russell Bateman
Russell Bateman wrote:

> Eszett; takes the place of ss and sz in German.
>
> Karl Guertin wrote:
>> On 6/2/06, Mun Johl <[hidden email]> wrote:
>>> abbcdeffgghijjkklmmnopqqrßtuvvww×yzz
>>>                          ^
>>>                          |
>>>                          this is the greek Beta character (in case it
>>>                          got lost in the transmission)
>>>
>>
>> That's not a beta, that's a german double s (forget what it's called).
>>
>>
>
>
>
Eszet. It can be entered by hitting <Ctrl-K> s s or, if 'digraph' is set
(it usually isn't), s <Backspace> s (disregard the spaces and <...> is
one key).

Maybe you have a mapping ending in a stray Ctrl-K (just guessing)?


Best regards,
Tony.
Reply | Threaded
Open this post in threaded view
|

Re: laststatus=2 anomaly (was: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed)

Eric Arnold-3
In reply to this post by Karl Guertin
On 6/2/06, Karl Guertin <[hidden email]> wrote:

> On 6/2/06, Mun Johl <[hidden email]> wrote:
> > abbcdeffgghijjkklmmnopqqrßtuvvww×yzz
> >                          ^
> >                          |
> >                          this is the greek Beta character (in case it
> >                          got lost in the transmission)
> >
>
> That's not a beta, that's a german double s (forget what it's called).
>

scharfes s
Reply | Threaded
Open this post in threaded view
|

Re: laststatus=2 anomaly (was: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed)

Eric Arnold-3
In reply to this post by Mun Johl
Ok.  So we know three things:

  The incremental search feature
  + the gvim/gui input method
  + the statusline

It would be interesting to try:

:feedkeys( "/3\<CR>", "t")

^R=some expression

this will tell us if the problem is in the "get char from use" vs the
"process char with incsearch".



On 6/2/06, Mun Johl <[hidden email]> wrote:

> Hi Eric,
>
> Please see my comments below.
>
> On Fri, Jun 02, 2006 at 10:42 AM PDT, Eric Arnold wrote:
> EA> On 6/2/06, Mun Johl <[hidden email]> wrote:
> EA> >Hi,
> EA> >
> EA> >After taking a couple of helpful hints from Eric, and doing a bunch of
> EA> >experiments, I have isolated some odd behavior to 'laststatus'.
> EA> >
> EA> >As a reminder, this issue only shows up when I compile vim7 using GTK-1;
> EA> >it does not occur when I compile with Motif or GTK-2.  My system is a
> EA> >Sun workstation running Solaris 8 and I use gcc 3.3.2 for compilation.
> EA>
> EA> Have you tried both gvim and vim via an xterm?
>
> Note that I am no longer going through Exceed; rather I'm running right
> on my Sun box.  So on my Sun box I have tried running vim within my
> dtterm.  As expected, there is no problem when running vim within the
> dtterm.
>
> EA> >The problem is that when I compile vim7 using GTK-1, certain characters
> EA> >need to be typed twice on the _search_ line.  Note that it only appears
> EA> >as if the search line is affected.  Text entry and command entry don't
> EA> >appear to be affected.
> EA>
> EA> I forgot, are you now testing with   gvim -u NONE -U NONE   ?  You
> EA> need to be sure that there aren't any plugins or mappings involved.
>
> I did try that, and I didn't see the issue after doing so.  After that,
> I started homing in on whether it was the loading .gvimrc or .vimrc that
> caused the problem; and then which line(s) until I finally landed on my
> laststatus setting.
>
> EA> >If I set laststatus to 0 or 1, the problem goes away.  If I set it to 2
> EA> >again, the problem re-appears.
> EA>
> EA> Does the problem correlate to the presence or absence of the displayed
> EA> statusline?
>
> Yes.  If 'laststatus' is 1 and I split the window, the problem shows up.
> But depending on what file is in the new split window, that window my
> not experience the problem.  But if I have a "problematic" file in both
> split windows, they will both experience the problem.
>
> Also, the same file will not _always_ have the problem.  It seems that
> if I set 'laststatus' to 0 or 1 and then exit and re-open the file with
> 'laststatus' == 2, I don't see the problem.  So I guess that implies
> that the .viminfo file has some influence.  But setting 'laststatus' to
> 2 and exiting/re-entering doesn't always bring the problem back.  Sigh.
>
> EA> I.e. can you have  'laststatus' at '1', and have two or more windows
> EA> split so that a statusline is displayed.
> EA>
> EA> Do you have anything interesting in the 'statusline' option?
>
> I commented out my specific 'statusline' settings for most of the
> testing; so that does not seem to make a difference.
>
> EA> >This doesn't always occur either; some files edit just fine.  So there
> EA> >is some other dependency as well it seems--but I haven't discovered that
> EA> >yet.  But, when it does occur, changing laststatus to 0 or 1 always
> EA> >corrects the issue.
> EA>
> EA>
> EA> Is incremental search on?
>
> Yes.  But, if I turn it off the problem disappears!  If I turn it on
> again, the problem reappears.
>
> EA> Also, you could do a binary search (i.e. chop it up into chunks) on an
> EA> affected file to try to find out what text is triggering it.
>
> Heh, wait until you hear this... I took a file that at the time was
> experiencing the problem.  I finally got it to the point that if the
> file contained the single character "3", then no problem.  But if the
> file had two characters "3.", I'd hit the problem.  Other experiments
> showing file contents and whether or not I saw a problem:
>
>    "33"   : No problem
>    "33."  : Problem
>    "33.3" : Problem
>    "333"  : No Problem
>
> I realize there are MANY other combinations to try; but I don't have
> that kind of time :)
>
> EA> >Here's a sample of what I get when I type each letter in the English
> EA> >alphabet twice in a row (e.g.: aabbccddeeff...):
> EA> >
> EA> >abbcdeffgghijjkklmmnopqqrßtuvvww×yzz
> EA> >                         ^
> EA> >                         |
> EA> >                         this is the greek Beta character (in case it
> EA> >                         got lost in the transmission)
> EA> >
> EA> >Notice how some characters only show up once, and the one greek
> EA> >character.
> EA>
> EA>
> EA> Too weird.
>
> Agreed.
>
> --
> Mun
>
Reply | Threaded
Open this post in threaded view
|

Re: laststatus=2 anomaly (was: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed)

Mun Johl
Hi Eric,

Please see my comments below.

On Fri, Jun 02, 2006 at 03:22 PM PDT, Eric Arnold wrote:
EA> Ok.  So we know three things:
EA>
EA>  The incremental search feature
EA>  + the gvim/gui input method
EA>  + the statusline
EA>
EA> It would be interesting to try:
EA>
EA> :feedkeys( "/3\<CR>", "t")

I'll look into this further over the weekend, but when I tried to
execute the :feedkeys command you suggested, I receive E492:

E492: Not an editor command: feedkeys(...)

EA> ^R=some expression

I don't understand what you want me to try with the ^R command above.

--
Mun

EA> this will tell us if the problem is in the "get char from use" vs the
EA> "process char with incsearch".
EA>
EA>
EA>
EA> On 6/2/06, Mun Johl <[hidden email]> wrote:
EA> >Hi Eric,
EA> >
EA> >Please see my comments below.
EA> >
EA> >On Fri, Jun 02, 2006 at 10:42 AM PDT, Eric Arnold wrote:
EA> >EA> On 6/2/06, Mun Johl <[hidden email]> wrote:
EA> >EA> >Hi,
EA> >EA> >
EA> >EA> >After taking a couple of helpful hints from Eric, and doing a bunch of
EA> >EA> >experiments, I have isolated some odd behavior to 'laststatus'.
EA> >EA> >
EA> >EA> >As a reminder, this issue only shows up when I compile vim7 using
EA> >GTK-1;
EA> >EA> >it does not occur when I compile with Motif or GTK-2.  My system is a
EA> >EA> >Sun workstation running Solaris 8 and I use gcc 3.3.2 for compilation.
EA> >EA>
EA> >EA> Have you tried both gvim and vim via an xterm?
EA> >
EA> >Note that I am no longer going through Exceed; rather I'm running right
EA> >on my Sun box.  So on my Sun box I have tried running vim within my
EA> >dtterm.  As expected, there is no problem when running vim within the
EA> >dtterm.
EA> >
EA> >EA> >The problem is that when I compile vim7 using GTK-1, certain
EA> >characters
EA> >EA> >need to be typed twice on the _search_ line.  Note that it only
EA> >appears
EA> >EA> >as if the search line is affected.  Text entry and command entry don't
EA> >EA> >appear to be affected.
EA> >EA>
EA> >EA> I forgot, are you now testing with   gvim -u NONE -U NONE   ?  You
EA> >EA> need to be sure that there aren't any plugins or mappings involved.
EA> >
EA> >I did try that, and I didn't see the issue after doing so.  After that,
EA> >I started homing in on whether it was the loading .gvimrc or .vimrc that
EA> >caused the problem; and then which line(s) until I finally landed on my
EA> >laststatus setting.
EA> >
EA> >EA> >If I set laststatus to 0 or 1, the problem goes away.  If I set it to
EA> >2
EA> >EA> >again, the problem re-appears.
EA> >EA>
EA> >EA> Does the problem correlate to the presence or absence of the displayed
EA> >EA> statusline?
EA> >
EA> >Yes.  If 'laststatus' is 1 and I split the window, the problem shows up.
EA> >But depending on what file is in the new split window, that window my
EA> >not experience the problem.  But if I have a "problematic" file in both
EA> >split windows, they will both experience the problem.
EA> >
EA> >Also, the same file will not _always_ have the problem.  It seems that
EA> >if I set 'laststatus' to 0 or 1 and then exit and re-open the file with
EA> >'laststatus' == 2, I don't see the problem.  So I guess that implies
EA> >that the .viminfo file has some influence.  But setting 'laststatus' to
EA> >2 and exiting/re-entering doesn't always bring the problem back.  Sigh.
EA> >
EA> >EA> I.e. can you have  'laststatus' at '1', and have two or more windows
EA> >EA> split so that a statusline is displayed.
EA> >EA>
EA> >EA> Do you have anything interesting in the 'statusline' option?
EA> >
EA> >I commented out my specific 'statusline' settings for most of the
EA> >testing; so that does not seem to make a difference.
EA> >
EA> >EA> >This doesn't always occur either; some files edit just fine.  So there
EA> >EA> >is some other dependency as well it seems--but I haven't discovered
EA> >that
EA> >EA> >yet.  But, when it does occur, changing laststatus to 0 or 1 always
EA> >EA> >corrects the issue.
EA> >EA>
EA> >EA>
EA> >EA> Is incremental search on?
EA> >
EA> >Yes.  But, if I turn it off the problem disappears!  If I turn it on
EA> >again, the problem reappears.
EA> >
EA> >EA> Also, you could do a binary search (i.e. chop it up into chunks) on an
EA> >EA> affected file to try to find out what text is triggering it.
EA> >
EA> >Heh, wait until you hear this... I took a file that at the time was
EA> >experiencing the problem.  I finally got it to the point that if the
EA> >file contained the single character "3", then no problem.  But if the
EA> >file had two characters "3.", I'd hit the problem.  Other experiments
EA> >showing file contents and whether or not I saw a problem:
EA> >
EA> >   "33"   : No problem
EA> >   "33."  : Problem
EA> >   "33.3" : Problem
EA> >   "333"  : No Problem
EA> >
EA> >I realize there are MANY other combinations to try; but I don't have
EA> >that kind of time :)
EA> >
EA> >EA> >Here's a sample of what I get when I type each letter in the English
EA> >EA> >alphabet twice in a row (e.g.: aabbccddeeff...):
EA> >EA> >
EA> >EA> >abbcdeffgghijjkklmmnopqqrßtuvvww×yzz
EA> >EA> >                         ^
EA> >EA> >                         |
EA> >EA> >                         this is the greek Beta character (in case it
EA> >EA> >                         got lost in the transmission)
EA> >EA> >
EA> >EA> >Notice how some characters only show up once, and the one greek
EA> >EA> >character.
EA> >EA>
EA> >EA>
EA> >EA> Too weird.
EA> >
EA> >Agreed.
EA> >
EA> >--
EA> >Mun
EA> >
Reply | Threaded
Open this post in threaded view
|

Re: laststatus=2 anomaly

A.J.Mechelynck
Mun Johl wrote:

> Hi Eric,
>
> Please see my comments below.
>
> On Fri, Jun 02, 2006 at 03:22 PM PDT, Eric Arnold wrote:
> EA> Ok.  So we know three things:
> EA>
> EA>  The incremental search feature
> EA>  + the gvim/gui input method
> EA>  + the statusline
> EA>
> EA> It would be interesting to try:
> EA>
> EA> :feedkeys( "/3\<CR>", "t")
>
> I'll look into this further over the weekend, but when I tried to
> execute the :feedkeys command you suggested, I receive E492:
>
> E492: Not an editor command: feedkeys(...)
>
> EA> ^R=some expression
>
> I don't understand what you want me to try with the ^R command above.
>
>  
feedkeys is not a command, it's a function. Try either

    :call feedkeys(...etc...)

or

    :echo feedkeys(...etc...)


In Insert or Command-line mode, Ctrl-R followed by an equal sign and an
expression (then Enter) enters the value obtained by evaluating the
expression.


Best regards,
Tony.
Reply | Threaded
Open this post in threaded view
|

Re: laststatus=2 anomaly (was: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed)

Eric Arnold-3
In reply to this post by Mun Johl
On 6/2/06, Mun Johl <[hidden email]> wrote:

> Hi Eric,
>
> Please see my comments below.
>
> On Fri, Jun 02, 2006 at 03:22 PM PDT, Eric Arnold wrote:
> EA> Ok.  So we know three things:
> EA>
> EA>  The incremental search feature
> EA>  + the gvim/gui input method
> EA>  + the statusline
> EA>
> EA> It would be interesting to try:
> EA>
> EA> :feedkeys( "/3\<CR>", "t")
>
> I'll look into this further over the weekend, but when I tried to
> execute the :feedkeys command you suggested, I receive E492:
>
> E492: Not an editor command: feedkeys(...)
>
> EA> ^R=some expression
>
> I don't understand what you want me to try with the ^R command above.


Sorry.  I meant

:call feedkeys( "/3\<CR>", "t")

About ^R, you can type ^R in search/etc mode, and there are several
things you can do from that point.  See

:h i_CTRL-R

In the above case, ^R= should put you into "expression evaluation"
mode, and you can type any expression, or your test string:

aabbccddeeff....
Reply | Threaded
Open this post in threaded view
|

Re: laststatus=2 anomaly (was: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed)

Matthew Winn
In reply to this post by Karl Guertin
On Fri, Jun 02, 2006 at 03:21:26PM -0400, Karl Guertin wrote:
> On 6/2/06, Mun Johl <[hidden email]> wrote:
> >abbcdeffgghijjkklmmnopqqrßtuvvww×yzz
> >                         ^
> >                         this is the greek Beta character (in case it
> >                         got lost in the transmission)
>
> That's not a beta, that's a german double s (forget what it's called).

Also, the character that falls between the w and the y is not an x,
but a multiplication sign.  It looks as through there's some sort of
automatic digraph processing going on, and it may not be coincidence
that most of the letters that are lost are those that have accented
or similar forms in western and eastern European languages.

--
Matthew Winn ([hidden email])
Reply | Threaded
Open this post in threaded view
|

Re: laststatus=2 anomaly (was: I sometimes have to "double strike" when using gvim7 over Hummingbird Exceed)

Mun Johl
In reply to this post by Eric Arnold-3
Hi Eric, et al.,

Please see my comments below.

On Fri, Jun 02, 2006 at 04:50 PM PDT, Eric Arnold wrote:
EA> On 6/2/06, Mun Johl <[hidden email]> wrote:

... Text Deleted ...

EA> Sorry.  I meant
EA>
EA> :call feedkeys( "/3\<CR>", "t")

This executes fine.  I can substitute any text for the "3" and it works
fine.

EA> About ^R, you can type ^R in search/etc mode, and there are several
EA> things you can do from that point.  See
EA>
EA> :h i_CTRL-R
EA>
EA> In the above case, ^R= should put you into "expression evaluation"
EA> mode, and you can type any expression, or your test string:
EA>
EA> aabbccddeeff....

This also works fine.

As time permits, I'm still trying to narrow down my .gvimrc and .vimrc
files to the minimum required to exhibit the problem--but I'm not there
yet.

Thanks.

--
Mun
12