Re: Opening files with Unicode names under Windows?
On Sep 11, 1:08 am, Tony Mechelynck [EMAIL PROTECTED] wrote: On 10/09/08 22:59, Szabolcs Horvát wrote: 2008/9/10 Szabolcs[EMAIL PROTECTED]: It turns out that I was wrong. Vim *can* open these files if I use the :e command, or I browse to the file with Vim as you suggested, or I just drag it onto the Vim window. The problem is only present when I use the Edit with Vim entry of the right click menu. So I suppose that the gvimext shell extension is the culprit. It seems that gvimext does not support Unicode file names, so I attempted to fix it ... However, I am not a programmer, and I know absolutely nothing about Windows programming (I just Googled for documentation) ... I would appreciate it very much if someone could take a look at my primitive effort to add Unicode support, and tell me if I did something stupid. (It does appear to work when tested with the őű.txt file.) Well, I don't know anything about programming Windows for Unicode but you might test the following names (I'm adding quotes because some of them have spaces) Э-эй ухнем.txt Ĉu.ĉi-tie.ĉiuaŭtune.ŝiriĝas.folioj.htlm 爲無爲、則無不治。.txt أَلسَّلامُ عَلَيْكَمْ.txt Paste them, don't hand-copy them ;-). I don't think the content of the files matters. I expect the last two to be particularly difficult because of the high CJK codepoints and the RTL Arabic words with composing characters in them. I don't guarantee that all values are permitted as filenames but they are meaningful text (well, more or less; let's say they're linguistically OK) and I intentionally didn't use question marks and asterisks (which I think are Yes, all of these names are working. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
PHP syntax highlighting bug in gvim 7.2
In gvim 7.2 (on Windows Vista, using the default colorscheme), I found a syntax highlighting bug. I commented out a block of PHP using the HTML comment tags of !-- and --. But the PHP code was not grayed out as it is in other editors (like Topstyle). table width=100% cellpadding=2 trtd !-- ?php echo This should be grayed out, but retains syntax highlighting; ? -- ?phpecho This has proper syntax highlighting; ? /td/tr/table regards, Kurt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
[patch] fixed memory leak in do_sub() ex_cmds.c
Hi Valgrind memory checker finds a memory leak in Vim-7.2.15. The steps to reproduce are a bit too messy to describe here and I have not been able to find a simple way to reproduce it. However I can reproduce it 100% of the time: ==1182== 150 bytes in 2 blocks are definitely lost in loss record 24 of 34 ==1182==at 0x4C21FEB: malloc (vg_replace_malloc.c:207) ==1182==by 0x4D6927: lalloc (misc2.c:859) ==1182==by 0x4D689A: alloc_check (misc2.c:792) ==1182==by 0x457EC4: do_sub (ex_cmds.c:4822) ==1182==by 0x465561: do_one_cmd (ex_docmd.c:2621) ==1182==by 0x462D41: do_cmdline (ex_docmd.c:1095) ==1182==by 0x45FE46: ex_listdo (ex_cmds2.c:2374) ==1182==by 0x465561: do_one_cmd (ex_docmd.c:2621) ==1182==by 0x462D41: do_cmdline (ex_docmd.c:1095) ==1182==by 0x4EE779: nv_colon (normal.c:5214) ==1182==by 0x4E775D: normal_cmd (normal.c:1181) ==1182==by 0x4A79EF: main_loop (main.c:1179) ==1182==by 0x4A7535: main (main.c:938) I see at least 2 'break' statements that would cause such a leak at lines 4994 and line 5007 in ex_cmds.c: 4979 if (new_start != NULL) 4980 { 4981 /* 4982 * Copy the rest of the line, that didn't match. 4983 * matchcol has to be adjusted, we use the end of 4984 * the line as reference, because the substitute m 4985 * have changed the number of characters. Same for 4986 * prev_matchcol. 4987 */ 4988 STRCAT(new_start, sub_firstline + copycol); 4989 matchcol = (colnr_T)STRLEN(sub_firstline) - matchc 4990 prev_matchcol = (colnr_T)STRLEN(sub_firstline) 4991 - prev_match 4992 4993 if (u_savesub(lnum) != OK) !4994 break; 4995 ml_replace(lnum, new_start, TRUE); 4996 4997 if (nmatch_tl 0) 4998 { 4999 /* 5000 * Matched lines have now been substituted and 5001 * useless, delete them. The part after the m 5002 * has been appended to new_start, we don't ne 5003 * it in the buffer. 5004 */ 5005 ++lnum; 5006 if (u_savedel(lnum, nmatch_tl) != OK) !5007 break; Attached patch fixes it. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- Index: ex_cmds.c === RCS file: /cvsroot/vim/vim7/src/ex_cmds.c,v retrieving revision 1.113 diff -c -r1.113 ex_cmds.c *** ex_cmds.c 6 Aug 2008 13:03:07 - 1.113 --- ex_cmds.c 11 Sep 2008 18:22:00 - *** *** 5059,5064 --- 5059,5065 if (did_sub) ++sub_nlines; + vim_free(new_start); vim_free(sub_firstline); /* free the copy of the original line */ sub_firstline = NULL; }
Re: Opening files with Unicode names under Windows?
On 11/09/08 11:18, Szabolcs wrote: On Sep 11, 1:08 am, Tony Mechelynck[EMAIL PROTECTED] wrote: On 10/09/08 22:59, Szabolcs Horvát wrote: 2008/9/10 Szabolcs[EMAIL PROTECTED]: It turns out that I was wrong. Vim *can* open these files if I use the :e command, or I browse to the file with Vim as you suggested, or I just drag it onto the Vim window. The problem is only present when I use the Edit with Vim entry of the right click menu. So I suppose that the gvimext shell extension is the culprit. It seems that gvimext does not support Unicode file names, so I attempted to fix it ... However, I am not a programmer, and I know absolutely nothing about Windows programming (I just Googled for documentation) ... I would appreciate it very much if someone could take a look at my primitive effort to add Unicode support, and tell me if I did something stupid. (It does appear to work when tested with the őű.txt file.) Well, I don't know anything about programming Windows for Unicode but you might test the following names (I'm adding quotes because some of them have spaces) Э-эй ухнем.txt Ĉu.ĉi-tie.ĉiuaŭtune.ŝiriĝas.folioj.htlm 爲無爲、則無不治。.txt أَلسَّلامُ عَلَيْكَمْ.txt Paste them, don't hand-copy them ;-). I don't think the content of the files matters. I expect the last two to be particularly difficult because of the high CJK codepoints and the RTL Arabic words with composing characters in them. I don't guarantee that all values are permitted as filenames but they are meaningful text (well, more or less; let's say they're linguistically OK) and I intentionally didn't use question marks and asterisks (which I think are Yes, all of these names are working. Well, Bram, have you seen the patch to gvimext earlier in this thread? What do you think of it? Best regards, Tony. -- Schnuffel, n.: A dog's practice of continuously nuzzling in your crotch in mixed company. -- Rich Hall, Sniglets --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: PHP syntax highlighting bug in gvim 7.2
kkruecke schrieb: In gvim 7.2 (on Windows Vista, using the default colorscheme), I found a syntax highlighting bug. I commented out a block of PHP using the HTML comment tags of !-- and --. But the PHP code was not grayed out as it is in other editors (like Topstyle). Sure this is a bug? Looks more like a feature not supported by Topstyle. table width=100% cellpadding=2 trtd !-- ?php echo This should be grayed out, but retains syntax highlighting; ? -- ?phpecho This has proper syntax highlighting; ? /td/tr/table regards, Kurt You can try (funnily enough) :let html_wrong_comments = 1 or fiddle directly with the syntax (check 'runtimepath', create subdirs as needed, :h after ): ~/.vim/after/syntax/php.vim syn clear htmlCommentPart syn region htmlCommentPart start=/--/ end=/--\s*/ contained original htmlCommentPart contains @htmlPreproc which permits highlighting of ?php ... ? No warranty ... -- Andy --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug with screen redraw introduced by 7.1.329
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Sep 04, 2008 at 10:09:07PM +0200, Bram Moolenaar wrote: Tyler Spivey wrote: hello. I have noticed that starting from 7.1.329, using vim in the console with the encoding set to utf8, there is a bug with redrawing characters. The characters show up on the screen fine (at least to my screen reader), but my screen reader is reading out the character that I type, then the one before the one I just typed, then the one I typed again. for example, I type 12345. On the 2, it says 1 12. 3 says 2 23, etc. if I comment out these lines that were changed by the patch, it works fine: || (cols 1 ScreenLines[off_from + 1] != ScreenLines[off_to + 1]))) I've confirmed this also effects 7.2.009. That condition is needed for when the right halve of a double-wide character is drawn over any character that used to be there. We can't simply remove it. Are you typing this at the end of the line, not pushing any characters forward? And those numbers are really ASCII digits? These are ascii digits, and I'm at the end of the line. I'm not sure, but while we're on the subject of redraw bugs, every character I type on the command line, e.g. :12345, causes the command line to be redrawn. Is there a quick fix for this one also? I'm running vim on Linux. If you need any other information, I can provide it. That might be difficult to change. But I don't see this happening. Do you have any special settings? Try resetting 'arabicshape', as Ingo suggested. I don't have any special settings other than: set noruler set noshowcmd filetype on set noarabicshape The set noarabicshape helped with the command line, so that one is solved. The only remaining one is the editor itself, which I have no idea how to fix. P.S.: Sorry if the quoting is a little strange; I've always top-posted, but figured I could give this a shot. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjJna0ACgkQTsjaYASMWKRGxwCbBJ9cBKWp6m1Tmi4BgDGYACU+ vYsAmwdSTZmLaQMn+eGECoIER7GNx30F =E1ep -END PGP SIGNATURE- --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: PHP syntax highlighting bug in gvim 7.2
kkruecke wrote: In gvim 7.2 (on Windows Vista, using the default colorscheme), I found a syntax highlighting bug. I commented out a block of PHP using the HTML comment tags of !-- and --. But the PHP code was not grayed out as it is in other editors (like Topstyle). table width=100% cellpadding=2 trtd !-- ?php echo This should be grayed out, but retains syntax highlighting; ? -- ?phpecho This has proper syntax highlighting; ? /td/tr/table regards, Kurt The PHP parser doesn't know or care about HTML or XML comments, i.e. the '!--' and '--' strings are output to PHP, nothing more. So the syntax highlighting shown by Vim is correct and apparently the Topstyle editor does the wrong thing here. - Peter Odding --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---