Bug in :set-termcap
At :help :set-termcap, an example shows the command
:set M-b=^[b
This command does not work as expected when 'encoding' is set to
something multibyte. The reason seems to be that vim recognizes the
input bytes 0x1B 0x62 as a metafied 'b', and then stuffs 0xE2 into its
internal text buffers - a byte which is not reasonable unicode. As a
result, vim continues waiting for more bytes to finish the
(unintentional) sequence, until it gives up, decides that the sequence
is invalid multibyte, and just returns the first byte as a character.
The attached patch fixes this by stuffing the multibyte bytes
corresponding to the given codepoint into the input buffer instead.
I'm not sure if there's a better way to handle changing the size of
MAX_KEY_CODE_LEN in src/keymap.h, but Bram will know for sure.
~Matt
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
diff --git a/src/keymap.h b/src/keymap.h
index 39837e5..99f38e6 100644
--- a/src/keymap.h
+++ b/src/keymap.h
@@ -479,6 +479,13 @@ enum key_extra
*
* K_SPECIAL KS_MODIFIER bitmask K_SPECIAL KS_EXTRA KT_LEFTDRAG.
*
- * This is a total of 6 tokens, and is currently the longest one possible.
+ * This is a total of 6 tokens, and is currently the longest one possible. In
+ * a multibyte encoding, it is also possible that a keycode representing a wide
+ * string taking up multiple bytes will need to be interpreted. In this case,
+ * the maximum becomes the maximum number of bytes to a character.
*/
-#define MAX_KEY_CODE_LEN6
+#ifdef FEAT_MBYTE
+# define MAX_KEY_CODE_LEN(MB_MAXBYTES)
+#else
+# define MAX_KEY_CODE_LEN6
+#endif
diff --git a/src/term.c b/src/term.c
index f795144..a991127 100644
--- a/src/term.c
+++ b/src/term.c
@@ -4919,8 +4919,20 @@ check_termcode(max_offset, buf, buflen)
/* Finally, add the special key code to our string */
key_name[0] = KEY2TERMCAP0(key);
key_name[1] = KEY2TERMCAP1(key);
- if (key_name[0] == KS_KEY)
- string[new_slen++] = key_name[1]; /* from :set M-b=xx */
+ if (key_name[0] == KS_KEY) {
+#ifdef FEAT_MBYTE
+ if (has_mbyte) {
+ char_u buf[MB_MAXBYTES];
+ int numbytes;
+ numbytes = (*mb_char2bytes)(key_name[1], buf);
+ buf[numbytes] = NUL;
+ STRCPY(string, buf);
+ new_slen += numbytes;
+ }
+ else
+#endif
+ string[new_slen++] = key_name[1]; /* from :set M-b=xx */
+ }
else
{
string[new_slen++] = K_SPECIAL;
Re: Bug in :set-termcap
Matt Wozniski wrote: At :help :set-termcap, an example shows the command :set M-b=^[b This command does not work as expected when 'encoding' is set to something multibyte. The reason seems to be that vim recognizes the input bytes 0x1B 0x62 as a metafied 'b', and then stuffs 0xE2 into its internal text buffers - a byte which is not reasonable unicode. As a result, vim continues waiting for more bytes to finish the (unintentional) sequence, until it gives up, decides that the sequence is invalid multibyte, and just returns the first byte as a character. The attached patch fixes this by stuffing the multibyte bytes corresponding to the given codepoint into the input buffer instead. I'm not sure if there's a better way to handle changing the size of MAX_KEY_CODE_LEN in src/keymap.h, but Bram will know for sure. Thanks for the patch. This stuff is a bit complicated, it does looks like your solution is the right one. -- Why isn't there mouse-flavored cat food? /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
[PATCH] Obj-C filetype detection
Hi, The attached patch properly detects Objective-C files (.m) which start with C++ style comments (//). The current filetype.vim only looks for C-style comments (/*) and hence often comes to the conclusion that Obj-C files are Matlab files. Björn --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- filetype.vim.diff Description: Binary data
Re: [PATCH] Obj-C filetype detection
Bjorn Wickler wrote: The attached patch properly detects Objective-C files (.m) which start with C++ style comments (//). The current filetype.vim only looks for C-style comments (/*) and hence often comes to the conclusion that Obj-C files are Matlab files. Fine with me. If nobody objects I'll include this. -- ARTHUR: Charge! [They all charge with swords drawn towards the RABBIT. A tremendous twenty second fight with Peckinpahish shots and borrowing heavily also on the Kung Fu and karate-type films ensues, in which some four KNIGHTS are comprehensively killed.] ARTHUR: Run away! Run away! Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [PATCH] Obj-C filetype detection
Le Sat, 13 Dec 2008 20:50:15 +0100, Bram Moolenaar a écrit dans le message 200812131950.mbdjofcq051...@moolenaar.net : Fine with me. If nobody objects I'll include this. I have a patch for gedcom files detection for LifeLines (Unix and Windows). -- Patrick Texier --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- filetype.patch Description: Gedcom detection for LifeLines
