Windows incorrect rendering of international characters
On Windows, Vim does not correctly display international characters. To demonstrate this, create a file in UTF-8 encoding with the Unicode characters \x5000 \x5001 \x5002 in it. These should display as Chinese chacaters. With stock gvim (I'm using 7.4 with patches to 389) the characters are not displayed. The problem is the use of the ETO_IGNORELANGUAGE in gui_w32.c (function gui_mch_draw_string), which is documented by MS as Reserved for system use. If an application sets this flag, it loses international scripting support and in some cases it may display no text at all. which is more or less what happened. The following patch fixes this: diff --git a/src/gui_w32.c b/src/gui_w32.c --- a/src/gui_w32.c +++ b/src/gui_w32.c @@ -2342,8 +2342,8 @@ /* On NT, tell the font renderer not to help us with Hebrew and Arabic * text. This doesn't work in 9x, so we have to deal with it manually on * those systems. */ -if (os_version.dwPlatformId == VER_PLATFORM_WIN32_NT) - foptions |= ETO_IGNORELANGUAGE; +/* if (os_version.dwPlatformId == VER_PLATFORM_WIN32_NT) + foptions |= ETO_IGNORELANGUAGE; */ /* * We have to provide the padding argument because italic and bold versions The comments in the code imply that by disabling ETO_IGNORELANGUAGE, RL text display will be slow (line 2465). I have no idea how slow it is in practice, but I didn't see any perceptible slowdown with :set rl. Should I supply a clean patch (that removes the use of ETO_IGNORELANGUAGE completely rather than just commenting it out)? Paul -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
ftplugin/python.vim unconditionally enforces coding style
ftplugin/python.vim contains the following: As suggested by PEP8. setlocal expandtab shiftwidth=4 softtabstop=4 tabstop=8 Coding style is a user choice. PEP 8 (https://www.python.org/dev/peps/pep-0008/) acknowledges this. File type plugins should not dictate this choice. I suggest removing the offending line in ftplugin/python.vim. Enjoy life. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: ftplugin/python.vim unconditionally enforces coding style
Martin Grady wrote: ftplugin/python.vim contains the following: As suggested by PEP8. setlocal expandtab shiftwidth=4 softtabstop=4 tabstop=8 Coding style is a user choice. PEP 8 (https://www.python.org/dev/peps/pep-0008/) acknowledges this. File type plugins should not dictate this choice. I suggest removing the offending line in ftplugin/python.vim. The idea of filetype plugins is that it's settings that work for most people. They won't work for everybody. If we only include settings that nobody would object to the files end up mostly empty. You can always create a filetype plugin in the after directory to overrule the settings from the distributed plugin. -- The budget process was invented by an alien race of sadistic beings who resemble large cats. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Windows incorrect rendering of international characters
On Thursday, July 31, 2014 4:46:22 AM UTC-5, Paul Moore wrote: On Windows, Vim does not correctly display international characters. To demonstrate this, create a file in UTF-8 encoding with the Unicode characters \x5000 \x5001 \x5002 in it. These should display as Chinese chacaters. With stock gvim (I'm using 7.4 with patches to 389) the characters are not displayed. I don't see this problem. I opened a new Vim, where my .vimrc already sets encoding to utf-8, and the default file encoding for the first buffer is blank. I entered unicode characters 5000, 5001, and 5002 which you say are Chinese characters, by pressing C-Vu5000 in insert mode, and the same for the other two. When I set my font to BatangChe, they look like they could be Chinese characters to me, so I assume they are, but I do not know Chinese. I then quit Vim, and opened the file in Notepad. The characters are saved correctly. I then re-opened Vim, set my font to BatangChe again, and opened the file again. The characters are still displayed correctly. I'm using a self-compiled 7.4.183 on Windows Vista 32-bit, at the moment. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Windows incorrect rendering of international characters
On Thursday, 31 July 2014 14:08:16 UTC+1, Ben Fritz wrote: I don't see this problem. [...] I entered unicode characters 5000, 5001, and 5002 which you say are Chinese characters, by pressing C-Vu5000 in insert mode, and the same for the other two. When I set my font to BatangChe, they look like they could be Chinese characters to me, so I assume they are, but I do not know Chinese. Do they show if you use a non-Chinese font like Lucida Console or Courier New? They don't for me, but they do in Notepad using those fonts. I don't have BatangChe or any other Chinese-specific fonts. I originally hit this issue in a source code file that had a short Chinese string embedded. My apologies for not being sufficiently clear that the issue was when you *didn't* use a special font. Paul -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Windows incorrect rendering of international characters
On Thursday, July 31, 2014 8:30:36 AM UTC-5, Paul Moore wrote: On Thursday, 31 July 2014 14:08:16 UTC+1, Ben Fritz wrote: I don't see this problem. [...] I entered unicode characters 5000, 5001, and 5002 which you say are Chinese characters, by pressing C-Vu5000 in insert mode, and the same for the other two. When I set my font to BatangChe, they look like they could be Chinese characters to me, so I assume they are, but I do not know Chinese. Do they show if you use a non-Chinese font like Lucida Console or Courier New? They don't for me, but they do in Notepad using those fonts. I don't have BatangChe or any other Chinese-specific fonts. I originally hit this issue in a source code file that had a short Chinese string embedded. My apologies for not being sufficiently clear that the issue was when you *didn't* use a special font. I'm confused. You want Vim to show Chinese characters, in a font that doesn't have any glyphs for Chinese characters? -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Windows incorrect rendering of international characters
On 31/07/2014 14:30, Paul Moore wrote: On Thursday, 31 July 2014 14:08:16 UTC+1, Ben Fritz wrote: I don't see this problem. [...] I entered unicode characters 5000, 5001, and 5002 which you say are Chinese characters, by pressing C-Vu5000 in insert mode, and the same for the other two. When I set my font to BatangChe, they look like they could be Chinese characters to me, so I assume they are, but I do not know Chinese. Do they show if you use a non-Chinese font like Lucida Console or Courier New? They don't for me, but they do in Notepad using those fonts. I don't have BatangChe or any other Chinese-specific fonts. I originally hit this issue in a source code file that had a short Chinese string embedded. My apologies for not being sufficiently clear that the issue was when you *didn't* use a special font. There was a patch on the dev list a year or so back that implemented support for DirectX font rendering. This generally improves font rendering in Windows gVim, and also deals with this issue. It would be nice to see this patch get rolled into the repo. Attached is a screenshot showing gVim with and without the DirectX renderer being used with Consolas as the current font. This is 7.4.383 + directx patch on Win7 x64. Mike -- What's brown and sticky? A stick! -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Windows incorrect rendering of international characters
On 31-Jul-2014 15:43 +0200, Ben Fritz wrote: On Thursday, July 31, 2014 8:30:36 AM UTC-5, Paul Moore wrote: On Thursday, 31 July 2014 14:08:16 UTC+1, Ben Fritz wrote: I don't see this problem. [...] I entered unicode characters 5000, 5001, and 5002 which you say are Chinese characters, by pressing C-Vu5000 in insert mode, and the same for the other two. When I set my font to BatangChe, they look like they could be Chinese characters to me, so I assume they are, but I do not know Chinese. Do they show if you use a non-Chinese font like Lucida Console or Courier New? They don't for me, but they do in Notepad using those fonts. I don't have BatangChe or any other Chinese-specific fonts. I originally hit this issue in a source code file that had a short Chinese string embedded. My apologies for not being sufficiently clear that the issue was when you *didn't* use a special font. I'm confused. You want Vim to show Chinese characters, in a font that doesn't have any glyphs for Chinese characters? The difference between Vim and Notepad (and many other programs) is that Vim (on Windows!) does not fall back to glyphs from another font (that has these), but other programs do. (This may or may not be related to the proposed removal of the flag; I don't know.) -- regards, ingo -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Windows incorrect rendering of international characters
On 31 July 2014 14:52, Ingo Karkat sw...@ingo-karkat.de wrote: I'm confused. You want Vim to show Chinese characters, in a font that doesn't have any glyphs for Chinese characters? The difference between Vim and Notepad (and many other programs) is that Vim (on Windows!) does not fall back to glyphs from another font (that has these), but other programs do. (This may or may not be related to the proposed removal of the flag; I don't know.) I want Vim to display a file with mostly ASCII and some Unicode characters at least as well as Notepad does. That is, using my default font, show something a bit better than a no such character square box. I really don't care how it does it. Every other program I have tried (notepad, notepad++, Emacs, Sublime Text) does this. Removing the use of a flag which Microsoft explicitly notes as Reserved for system use does this. Probably, as Ingo says, by allowing fallback to a font that has the relevant characters. Paul. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Windows incorrect rendering of international characters
On 31 July 2014 14:52, Mike Williams mike.willi...@globalgraphics.com wrote: There was a patch on the dev list a year or so back that implemented support for DirectX font rendering. This generally improves font rendering in Windows gVim, and also deals with this issue. It would be nice to see this patch get rolled into the repo. Is this https://groups.google.com/forum/#!topic/vim_dev/t-v0_mJlogc the patch you mean? It sounds like it does what I want (and from the screenshot, it looks like it does, as well). What is needed to get this rolled into Vim? Paul -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Windows incorrect rendering of international characters
On 31/07/2014 15:44, Paul Moore wrote: On 31 July 2014 14:52, Mike Williams mike.willi...@globalgraphics.com wrote: There was a patch on the dev list a year or so back that implemented support for DirectX font rendering. This generally improves font rendering in Windows gVim, and also deals with this issue. It would be nice to see this patch get rolled into the repo. Is this https://groups.google.com/forum/#!topic/vim_dev/t-v0_mJlogc the patch you mean? That is the one. I have been using mq to keep it rolling forward with vim updates - haven't had reject yet from a qpush (of course, now I have said that ...) It sounds like it does what I want (and from the screenshot, it looks like it does, as well). What is needed to get this rolled into Vim? Bram's nod AFAIK. I have been using it for the last 18 months and have had no problems with it. I don't know if anyone else, other than the original developer, has been using it. Can't see any obvious problem rolling it out since people have to actively use it at the moment. Mike -- What's brown and sticky? A stick! -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Windows incorrect rendering of international characters
On 31 July 2014 15:51, Mike Williams mike.willi...@globalgraphics.com wrote: Bram's nod AFAIK. I have been using it for the last 18 months and have had no problems with it. I don't know if anyone else, other than the original developer, has been using it. Can't see any obvious problem rolling it out since people have to actively use it at the moment. Yeah, I guess what I really meant was is there any way to get Bram to review/approve it? Maybe this thread will remind him about it... Paul -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Windows incorrect rendering of international characters
On 31 July 2014 16:05, Paul Moore p.f.mo...@gmail.com wrote: On 31 July 2014 15:51, Mike Williams mike.willi...@globalgraphics.com wrote: Bram's nod AFAIK. I have been using it for the last 18 months and have had no problems with it. I don't know if anyone else, other than the original developer, has been using it. Can't see any obvious problem rolling it out since people have to actively use it at the moment. Yeah, I guess what I really meant was is there any way to get Bram to review/approve it? Maybe this thread will remind him about it... Actually, I also see the rendering bugs referred to in the thread there. Maybe there's still some work needed on that patch. On the other hand my proposal of removing use of ETO_IGNORELANGUAGE seems minimal and works without issues, as far as I can see. So I'd say implement that for the short term, and the full DirectX patch once the rendering issues are ironed out (the DirectX rendering is nicer than the default, so I do think it's worth using). Paul -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Windows incorrect rendering of international characters
On 31 July 2014 18:32, Andre Sihera andre.sih...@hotmail.co.jp wrote: The proposed patch may fix glyph replacement but have you broken right-to-left display using Hebrew and Arabic fonts? I haven't checked the code but it appears gViM may do its own RTL processing which is why this flag was specified. You should check this as well before declaring your patch safe. I did check that setting RTL worked as I expected, but I'm definitely not an expert in this. If someone can tell me exactly what needs testing, I'll happily check. The comments in the code say that the flag only exists under Windows NT and later, and there's fallback code for Windows 95 that does the job manually, but is slower. Essentially what I've done by removing the flag is to make Vim think it should use the Windows 95 (do it yourself) code always - so I don't think it's possible for my change to have introduced any bug that wasn't already in the code (for Windows 95, at least). The comments imply that by not using the flag, the redraw code could be slower. That's possible - all I can say is that I didn't notice any perceptible slowdown, and modern hardware is so much faster than what was around when the code was written that I'd be surprised if it were a practical issue. Paul -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Windows incorrect rendering of international characters
On 31 July 2014 18:51, Mike Williams mike.willi...@globalgraphics.com wrote: Actually, I also see the rendering bugs referred to in the thread there. Maybe there's still some work needed on that patch. Is this the cut'n'paste issue? Do you have test data? TIA It looks similar in behaviour (although I have to say I only skimmed the thread). But it wasn't after a cut and paste. I opened a file with the following text in it: unicode_text = uPolish: Ą Ł Ż Chinese: 倀 倁 倂 倃 倄 倅 倆 倇 倈 Musical Notes: ♬ ♫ ♯ If I remember correctly, I opened the file with the default encoding and then set enc=utf-8. When I scrolled down to the musical notes line, the second note was doubled and the rest of the line shifted along (as if the redraw code lost track of the correct horizontal position). Moving the cursor along the line with l (forcing a character by character redraw) fixed the display. I can't do a screenshot or reproduce it right now, as I don't currently have a patched copy of vim available. Paul -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Windows incorrect rendering of international characters
Paul Moore wrote: On Windows, Vim does not correctly display international characters. To demonstrate this, create a file in UTF-8 encoding with the Unicode characters \x5000 \x5001 \x5002 in it. These should display as Chinese chacaters. The question is: What version of Windows? Reading the comments it appears the behavior changed at some point. There are plenty of Chinese Vim users, I'm sure they would have complained loudly if Chinese characters don't show up. With stock gvim (I'm using 7.4 with patches to 389) the characters are not displayed. The problem is the use of the ETO_IGNORELANGUAGE in gui_w32.c (function gui_mch_draw_string), which is documented by MS as Reserved for system use. If an application sets this flag, it loses international scripting support and in some cases it may display no text at all. which is more or less what happened. The following patch fixes this: diff --git a/src/gui_w32.c b/src/gui_w32.c --- a/src/gui_w32.c +++ b/src/gui_w32.c @@ -2342,8 +2342,8 @@ /* On NT, tell the font renderer not to help us with Hebrew and Arabic * text. This doesn't work in 9x, so we have to deal with it manually on * those systems. */ -if (os_version.dwPlatformId == VER_PLATFORM_WIN32_NT) - foptions |= ETO_IGNORELANGUAGE; +/* if (os_version.dwPlatformId == VER_PLATFORM_WIN32_NT) + foptions |= ETO_IGNORELANGUAGE; */ /* * We have to provide the padding argument because italic and bold versions The comments in the code imply that by disabling ETO_IGNORELANGUAGE, RL text display will be slow (line 2465). I have no idea how slow it is in practice, but I didn't see any perceptible slowdown with :set rl. Should I supply a clean patch (that removes the use of ETO_IGNORELANGUAGE completely rather than just commenting it out)? -- Engineers are always delighted to share wisdom, even in areas in which they have no experience whatsoever. Their logic provides them with inherent insight into any field of expertise. This can be a problem when dealing with the illogical people who believe that knowledge can only be derived through experience. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Windows incorrect rendering of international characters
On 31 July 2014 19:38, Bram Moolenaar b...@moolenaar.net wrote: Paul Moore wrote: On Windows, Vim does not correctly display international characters. To demonstrate this, create a file in UTF-8 encoding with the Unicode characters \x5000 \x5001 \x5002 in it. These should display as Chinese chacaters. The question is: What version of Windows? Reading the comments it appears the behavior changed at some point. Sorry, this is Windows 7 64-bit. From my personal experience, I don't think the behaviour has changed, I was just used to Vim not ever displaying unusual characters properly, but I saw them so infrequently that it didn't bother me and I never dug into the exact details. But I recently encountered a file with UTF8 test data in it that was difficult to follow because of the rendering issue. It was a one-off problem, but annoying enough that I looked at other editors (I couldn't convince myself that it was *just* a rendering issue and I wasn't at risk of corrupting the data). I was surprised to find that *every* other editor displayed the file flawlessly. There are plenty of Chinese Vim users, I'm sure they would have complained loudly if Chinese characters don't show up. If I understand the issue it is with display of characters which don't have a glyph defined in the current font. Windows appears to have a way of falling back to another font which does contain the glyphs if needed, but the flag I disabled stops that fallback happening - hence the bad display. I guess Chinese users won't see an issue as I presume their fonts will contain the necessary glyphs. Paul -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Issue 237 in vim: solution problem with the command noswapfile on vimgolf
Comment #1 on issue 237 by zulolox4...@gmail.com: solution problem with the command noswapfile on vimgolf http://code.google.com/p/vim/issues/detail?id=237 Hello ! Created and tested the attached patch file for vim 7.4.389. Changed the command :noswapfile to :no_swapfile. Attachments: patch_no_swap7_4_389 3.8 KB -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Issue 237 in vim: solution problem with the command noswapfile on vimgolf
Comment #2 on issue 237 by vega.ja...@gmail.com: solution problem with the command noswapfile on vimgolf http://code.google.com/p/vim/issues/detail?id=237 Why should Vim change the command name just because it caused a specific completion to invalidate solutions to a gamification of Vim? There's no functional bug here, just a change in the minimum number of keys needed to solve those challenges. Take it as providing another opportunity to find a minimal solution to those challenges. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
