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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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> >
