Re: laststatus=2 anomaly (was: I sometimes have to double strike when using gvim7 over Hummingbird Exceed)
On Tue, Jun 06, 2006 at 10:04:14PM -0700, Mun Johl wrote: GK Aha! That beta is actually a German SS, szlig; (sz ligature) iirr. GK GK The 'X' is a math times (times; no?). GK GK All the other (usually) vowels have similar compounding, eg, GK [aeiou] with accents of various types (try typing a' or a:, GK ferinstance), Polish l/ (slashed-ell, don't know the sgml entity GK offhand), Spanish n~ (en-tilde, ntilde;), and so on. Very interesting observation! Did nobody notice when I made much the same observation on Monday morning? Hello? Can anyone hear me? -- Matthew Winn ([EMAIL PROTECTED])
Re: laststatus=2 anomaly (was: I sometimes have to double strike when using gvim7 over Hummingbird Exceed)
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 [EMAIL PROTECTED] 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
RE: laststatus=2 anomaly (was: I sometimes have to double strike when using gvim7 over Hummingbird Exceed)
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. Aha! That beta is actually a German SS, szlig; (sz ligature) iirr. The 'X' is a math times (times; no?). All the other (usually) vowels have similar compounding, eg, [aeiou] with accents of various types (try typing a' or a:, ferinstance), Polish l/ (slashed-ell, don't know the sgml entity offhand), Spanish n~ (en-tilde, ntilde;), and so on. Try some funky combinations like l/, n~, etc., and see what pops up. If this is the case, then I don't *think* it's an issue with 'vim', but something with the GTK1 compile, that maybe it includes as a bonus some cooked keystroke editing to be able to easily get weirdo characters right from the keyboard for functions like getc(), scanf(), etc. We may be on to something now... :D
Re: laststatus=2 anomaly (was: I sometimes have to double strike when using gvim7 over Hummingbird Exceed)
On Fri, Jun 02, 2006 at 03:21:26PM -0400, Karl Guertin wrote: On 6/2/06, Mun Johl [EMAIL PROTECTED] 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 ([EMAIL PROTECTED])
Re: laststatus=2 anomaly (was: I sometimes have to double strike when using gvim7 over Hummingbird Exceed)
On 6/2/06, Mun Johl [EMAIL PROTECTED] 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
Re: laststatus=2 anomaly (was: I sometimes have to double strike when using gvim7 over Hummingbird Exceed)
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 [EMAIL PROTECTED] 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
Re: laststatus=2 anomaly (was: I sometimes have to double strike when using gvim7 over Hummingbird Exceed)
On 6/2/06, Karl Guertin [EMAIL PROTECTED] wrote: On 6/2/06, Mun Johl [EMAIL PROTECTED] 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
Re: laststatus=2 anomaly (was: I sometimes have to double strike when using gvim7 over Hummingbird Exceed)
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: laststatus=2 anomaly (was: I sometimes have to double strike when using gvim7 over Hummingbird Exceed)
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 EA33 : No problem EA33. : Problem EA33.3 : Problem EA333 : 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
Re: laststatus=2 anomaly (was: I sometimes have to double strike when using gvim7 over Hummingbird Exceed)
On 6/2/06, Mun Johl [EMAIL PROTECTED] 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
