[patch] MS-Windows uninstaller fail to run on 32 bit systems
I found the 7.3d NSIS installer I built cannot uninstall Vim on Windows XP SP3. When I replicate the uninstallation process manually, the following error was reported when launch "uninstal.exe": Entry Point Not Found: The procedure entry point RegDeleteKeyExA could not be located in the dynamic link library ADVAPI32.DLL. It turns out RegDeleteKeyEx() is only available on 64 bit Windows, according to MSDN: http://msdn.microsoft.com/en-us/library/ms724847(VS.85).aspx Minimum supported client: Windows Vista, Windows XP Professional x64 Edition That function call was introduced in changeset b204ac54bea4: Fix: the MS-Windows uninstaller did not delete registry keys on 64 bit systems. The simple patch (against changeset 7f578da7edb2) I attached defines a macro REG_DELETE_KEY, which translates to RegDeleteKeyEx when WIN3264 defined, and to RegDeleteKey otherwise. I only tested the patch on Windows XP SP3, it works. I do not have 64-bit system to verify with, it should work in theory since the code is the same after pre-processing when WIN3264 is defined. Regards! -- Guopeng -- 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 reg-delete.patch Description: Binary data
Re: Oops (Was: Re: cygwin gcc buidling gvimext.dll fails)
On Sun, 1 Aug 2010, Chris Sutcliffe wrote: On 8/01/10 7:46 PM, Christian J. Robinson wrote: Oops, the subject should have been uninstal.c, not gvimext.dll The problem is that WINVER is defined as 0x0400 in Make_ming.mak and RegKeyDeleteEx is only available with WINVER 0x0502 and above. I'm using Make_cyg.mak, but the same holds true there. I changed it to 0x0502 and the error disappeared. Thank you. - Christian -- Christian J. Robinson -- http://christianrobinson.name/ -- 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
Re: Question about :find completion support in Vim 7.3b
On Thu, Jul 29, 2010 at 4:39 AM, Bram Moolenaar wrote:
> I have included the recent patches, but not the one that resets
> "recursive" in gen_expand_wildcards(). That is probably causing that
> crash.
I noticed that mch_expandpath() is defined on both unix and windows as
unix_expandpath() and dos_expandpath(), respectively. I'll see if it
can be used in place of globpath() (which calls gen_expand_wildcards())
in the function expand_in_path().
If that is successful I'll send a new patch for that and also revert thechanges
I did in globpath() (skipping url path).
In the mean time here is the patch to prevent ":find " from crashing on
windows when 'path" is set to something like "c:\src\**".
nazri.
--
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
diff --git a/src/misc1.c b/src/misc1.c
index 11c2b1b..48dcd36 100644
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -9675,7 +9675,10 @@ gen_expand_wildcards(num_pat, pat, num_file, file, flags)
#ifdef SPECIAL_WILDCHAR
return mch_expand_wildcards(num_pat, pat, num_file, file, flags);
#else
+{
+ recursive = FALSE;
return FAIL;
+}
#endif
#ifdef SPECIAL_WILDCHAR
Re: Oops (Was: Re: cygwin gcc buidling gvimext.dll fails)
On 8/01/10 7:46 PM, Christian J. Robinson wrote: Oops, the subject should have been uninstal.c, not gvimext.dll The problem is that WINVER is defined as 0x0400 in Make_ming.mak and RegKeyDeleteEx is only available with WINVER 0x0502 and above. Chris -- 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
Oops (Was: Re: cygwin gcc buidling gvimext.dll fails)
Oops, the subject should have been uninstal.c, not gvimext.dll -- Christian J. Robinson -- http://christianrobinson.name/ -- 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
cygwin gcc buidling gvimext.dll fails
g++-3 -shared -O2 -mno-cygwin -s -o gvimext.dll \ -Wl,--enable-auto-image-base \ -Wl,--enable-auto-import \ -Wl,--whole-archive \ gvimext.o gvimext.res gvimext_ming.def \ -Wl,--no-whole-archive \ -L/lib/w32api -luuid [...]/AppData/Local/Temp/ccISkFaJ.o:uninstal.c:(.text+0x44a): undefined reference to `_RegDeleteKeyEx' [...message repeats...] collect2: ld returned 1 exit status make: *** [uninstal.exe] Error 1 - Christian -- Christian J. Robinson -- http://christianrobinson.name/ -- 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
[bug] access to uninitialized memory in blowfish.c
Hi
Vim-7.3d (2467:7f578da7edb2) accesses uninitialized memory when
encrypting an empty buffer with cryptmethod=blowfish:
$ valgrind --num-callers=50 --track-origins=yes --log-file=/tmp/vg.log \
vim -u NONE -N -c 'set cm=blowfish' \
-c 'call feedkeys(":X\foo\foo\:sav! /tmp/foo\")'
... and /tmp/vg.log contains:
==6126== Use of uninitialised value of size 4
==6126==at 0x805C630: bf_e_block (blowfish.c:340)
==6126==by 0x805CCAB: bf_e_cblock (blowfish.c:385)
==6126==by 0x805D20E: bf_crypt_encode (blowfish.c:611)
==6126==by 0x811AFC9: crypt_encode (misc2.c:3868)
==6126==by 0x80FDFFB: ml_encrypt_data (memline.c:4849)
==6126==by 0x80F6422: mf_write_block (memfile.c:1165)
==6126==by 0x80F632D: mf_write (memfile.c:1121)
==6126==by 0x80F59A4: mf_sync (memfile.c:599)
==6126==by 0x80FA11D: ml_preserve (memline.c:2330)
==6126==by 0x80C8919: buf_write (fileio.c:4160)
==6126==by 0x809832D: do_write (ex_cmds.c:2706)
==6126==by 0x8097DF0: ex_write (ex_cmds.c:2519)
==6126==by 0x80A85C8: do_one_cmd (ex_docmd.c:2656)
==6126==by 0x80A5EA1: do_cmdline (ex_docmd.c:1122)
==6126==by 0x812E54B: nv_colon (normal.c:5319)
==6126==by 0x8127BE7: normal_cmd (normal.c:1190)
==6126==by 0x80E8ECF: main_loop (main.c:1260)
==6126==by 0x80E8904: main (main.c:965)
==6126== Uninitialised value was created by a heap allocation
==6126==at 0x4024F70: malloc (vg_replace_malloc.c:236)
==6126==by 0x8117E4E: lalloc (misc2.c:920)
==6126==by 0x8117D3E: alloc (misc2.c:818)
==6126==by 0x80F4F79: mf_open (memfile.c:133)
==6126==by 0x80F68D7: ml_open (memline.c:311)
==6126==by 0x8053830: open_buffer (buffer.c:93)
==6126==by 0x80EABB0: create_windows (main.c:2597)
==6126==by 0x80E8598: main (main.c:809)
(and more errors after that)
It happens with 'cm=blowfish' but not with 'cm=zip'.
I have not found the fix yet.
Regards
-- Dominique
--
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
Re: Wrong window selected at the end of session startup (SOLVED)
On 01-Aug-2010 Tony Mechelynck wrote: > hm... > hg log -f runtime/plugin/netrwPlugin.vim --style changelog > hg diff -r 6de9efd58dc0 -r e52d87a2bb3e runtime/plugin/netrwPlugin.vim > > Ah, I see it now, in the 2nd hunk. > > Would never have guessed that my only remote buffer (in a different > tab) was the culprit. It was probably not. I had a similar problem when trying to execute a "session file" which opened two local files. -- Cheers, Lech -- 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
Re: Wrong window selected at the end of session startup (SOLVED)
On 01/08/10 22:51, Lech Lorens wrote: On 31-Jul-2010 Tony Mechelynck wrote: On 19/07/10 00:25, Tony Mechelynck wrote: [...] (after creating a "first tab" with many windows in it, then several additional tabs with one window each), however when clearing the intro screen after startup (e.g. by hitting the spacebar) I am in the top window, not in the 2nd from bottom. The same happened with the two :wincmd lines above replaced by the single [...] I don't know exactly when, but the problem has disappeared. Best regards, Tony. It was with the latest plugin/netrwPlugin.vim update. hm... hg log -f runtime/plugin/netrwPlugin.vim --style changelog hg diff -r 6de9efd58dc0 -r e52d87a2bb3e runtime/plugin/netrwPlugin.vim Ah, I see it now, in the 2nd hunk. Would never have guessed that my only remote buffer (in a different tab) was the culprit. Best regards, Tony. -- A parent can be arrested if his child cannot hold back a burp during a church service. [real standing law in Nebraska, United States of America] -- 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
Re: Wrong window selected at the end of session startup (SOLVED)
On 31-Jul-2010 Tony Mechelynck wrote: > On 19/07/10 00:25, Tony Mechelynck wrote: [...] > >(after creating a "first tab" with many windows in it, then several > >additional tabs with one window each), however when clearing the intro > >screen after startup (e.g. by hitting the spacebar) I am in the top > >window, not in the 2nd from bottom. The same happened with the two > >:wincmd lines above replaced by the single [...] > > I don't know exactly when, but the problem has disappeared. > > Best regards, > Tony. It was with the latest plugin/netrwPlugin.vim update. -- Cheers, Lech -- 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
Re: Vim 7.3 version conflict
Tony Mechelynck wrote: > Even after "make reconfig" (which did not happen spontaneously), the > latest Vim 7.3 installs its runtimes in $VIM/vim73d but looks for them > in $VIM/vim73c (:version displays "VIM - Vi IMproved 7.3c BETA"). > > Is there a conflict between the src/Makefile and the version.h ? > > src/version.h line 36: > #define VIM_VERSION_NODOT "vim73c" > > src/Makefile line 933 > VIMMINOR = 3d Right, I forgot to update src/version.h. Done now. -- You can test a person's importance in the organization by asking how much RAM his computer has. Anybody who knows the answer to that question is not a decision-maker. (Scott Adams - The Dilbert principle) /// 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. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Vim 7.3 version conflict
Even after "make reconfig" (which did not happen spontaneously), the latest Vim 7.3 installs its runtimes in $VIM/vim73d but looks for them in $VIM/vim73c (:version displays "VIM - Vi IMproved 7.3c BETA"). Is there a conflict between the src/Makefile and the version.h ? src/version.h line 36: #define VIM_VERSION_NODOT "vim73c" src/Makefile line 933 VIMMINOR = 3d Best regards, Tony. -- Hugh Hefner is a virgin. -- 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
Re: Vim 7.3c ready for beta testing
I wrote: > Hello Vim users, > > > Announcing: Vim (Vi IMproved) version 7.3c BETA [...] > Known problem: The MS-Windows self-installing executable for 7.3c does > not delete the install key on 64 bit systems. You can remove it through > the control panel. I managed to fix this quickly. The gvim73c.exe on the ftp site already has the fix. -- For large projects, Team Leaders use sophisticated project management software to keep track of who's doing what. The software collects the lies and guesses of the project team and organizes them in to instantly outdated charts that are too boring to look at closely. This is called "planning". (Scott Adams - The Dilbert principle) /// 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. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Vim 7.3c ready for beta testing
Hello Vim users, Announcing: Vim (Vi IMproved) version 7.3c BETA This is a BETA release of Vim 7.3. It consists of Vim 7.2 plus all patches, updated runtime files and some more. 7.3c both includes lots of fixes and a few new features. Everything needs to be tested to verify no new problems have been introduced. Please report every problem you find! The 7.3 release should not contain a problem because you didn't report it. The biggest additions since 7.2: - Persistent undo, undo for reload - Blowfish encryption, also encrypt the swap file - Conceal text (note: since 7.3a 'conc' was renamed to 'cole') - Lua interface - Python 3 interface I will no longer include new features in 7.3, it's only testing now. Once you have installed Vim 7.3c BETA you can find details about the changes since Vim 7.2 with: :help version-7.3 Known problem: The MS-Windows self-installing executable for 7.3c does not delete the install key on 64 bit systems. You can remove it through the control panel. Testing --- Please especially test the persistent undo and encryption. These need to work reliably. Report anything that isn't right. That includes a crash but also a typo in the documentation and a missing file. Gratitude - If you like Vim, this is the way to say thanks: http://iccf-holland.org/clinic.html Where to get it --- The best way to obtain the latest Vim 7.3 is using Mercurial. Summary: hg clone https://vim.googlecode.com/hg/ vim cd vim hg update vim73 More information here: http://www.vim.org/mercurial.php All downloadable files can be found below this directory: ftp://ftp.vim.org/pub/vim/unstable/ Direct link to the MS-Windows self-installing executable: ftp://ftp.vim.org/pub/vim/unstable/pc/gvim73c.exe Information about which files to download for what system (don't use the links, they are still for Vim 7.2): http://www.vim.org/download.php A list of mirror sites can be found here: http://www.vim.org/mirrors.php An overview of the files below "unstable": UNIX: unix/vim-7.3c.tar.bz2 sources + runtime files, bzip2 compressed MS-WINDOWS one-size-fits-all: pc/gvim73c.exe self-installing, includes all runtime files VARIOUS: doc/vim73chtml.zip help files converted to HTML MS-WINDOWS separate files: pc/vim73crt.zip runtime files pc/gvim73c.zip GUI binary for Windows 95/98/NT/2000/XP pc/gvim73cole.zip GUI binary with OLE support pc/gvim73c_s.zipGUI binary for Windows 3.1 (untested) pc/vim73cd32.zipconsole version for MS-DOS/Windows 95/98 pc/vim73cw32.zipconsole version for Windows NT/2000/XP pc/vim73csrc.zipsources for PC (with CR-LF) DIFFS TO PREVIOUS RELEASE: unix/vim-7.3b-7.3c.diff.gz sources + runtime files Omitted in this version are: - Extra and lang archives, these are now included in the main source and runtime archives. - The 16-bit DOS, OS/2 and Amiga versions, these are obsolete. Mailing lists - For user questions you can turn to the Vim mailing list. There are a lot of tips, scripts and solutions. You can ask your Vim questions, but only if you subscribe. See http://www.vim.org/maillist.php#vim If you want to help Vim development, discuss new features or get the latest patches, subscribe to the vim-dev mailing list. See http://www.vim.org/maillist.php#vim-dev Subject specific lists: Multi-byte issues: http://www.vim.org/maillist.php#vim-multibyte Macintosh issues: http://www.vim.org/maillist.php#vim-mac Before you ask a question you should search the archives, someone may already have given the answer. Reporting bugs -- Send them to . Please describe the problem precisely. All the time spent on answering mail is subtracted from the time that is spent on improving Vim! Always give a reproducible example and try to find out which settings or other things influence the appearance of the bug. Try starting without your own vimrc file: "vim -u NONE". Try different machines if possible. See ":help bugs" in Vim. Send me a patch if you can! Happy Vimming! -- If your company is not involved in something called "ISO 9000" you probably have no idea what it is. If your company _is_ involved in ISO 9000 then you definitely have no idea what it is. (Scott Adams - The Dilbert principle) /// 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. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.p
Re: if_ole.c no longer compiles under cygwin
Christian J. Robinson wrote: > At some point in the last 12 or so hours Vim stopped compiling for me > when using cygwin to build a "native" Windows binary with OLE enabled: > > % make -f Make_cyg.mak -j2 PERL=/cygdrive/c/strawberry/perl DYNAMIC_PERL=yes > OLE=yes FEATURES=BIG > > gcc-3 -c -O3 -fomit-frame-pointer -freg-struct-return -fno-strength-reduce > -DWIN32 -DHAVE_PATHDEF -DFEAT_BIG -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 > -DFEAT_PERL -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\"perl512.dll\" > -DDYNAMIC_GETTEXT -DDYNAMIC_ICONV -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME > -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_OLE > -march=i386 -Iproto -I/cygdrive/c/strawberry/perl/lib/CORE -s -mno-cygwin > if_ole.cpp -o gobj/if_ole.o > if_ole.cpp: In static member function `static CVim* CVim::Create(int*)': > if_ole.cpp:161: error: `KEY_WOW64_64KEY' undeclared (first use this function) > if_ole.cpp:161: error: (Each undeclared identifier is reported only once for > each function it appears in.) > if_ole.cpp: In function `void RecursiveDeleteKey(HKEY__*, const char*)': > if_ole.cpp:654: error: `KEY_WOW64_64KEY' undeclared (first use this function) > if_ole.cpp: In function `void SetKeyAndValue(const char*, const char*, const > char*)': > if_ole.cpp:697: error: `KEY_WOW64_64KEY' undeclared (first use this function) > if_ole.cpp: In function `void InitOLE(int*)': > if_ole.cpp:756: warning: passing NULL used for non-pointer converting 3 of > `HRESULT RegisterActiveObject(IUnknown*, const CLSID&, DWORD, DWORD*)' > make: *** [gobj/if_ole.o] Error 1 > > > This is a 64 bit Vista machine, if that helps at all. The compiler apparently doesn't define the KEY_WOW64_64KEY. I'll add code for that. -- Our job was to build a computer information system for the branch banks. We were the perfect people for the job: Dean had seen a computer once, and I had heard Dean talk about it. (Scott Adams - The Dilbert principle) /// 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. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
if_ole.c no longer compiles under cygwin
At some point in the last 12 or so hours Vim stopped compiling for me when using cygwin to build a "native" Windows binary with OLE enabled: % make -f Make_cyg.mak -j2 PERL=/cygdrive/c/strawberry/perl DYNAMIC_PERL=yes OLE=yes FEATURES=BIG gcc-3 -c -O3 -fomit-frame-pointer -freg-struct-return -fno-strength-reduce -DWIN32 -DHAVE_PATHDEF -DFEAT_BIG -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DFEAT_PERL -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\"perl512.dll\" -DDYNAMIC_GETTEXT -DDYNAMIC_ICONV -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_OLE -march=i386 -Iproto -I/cygdrive/c/strawberry/perl/lib/CORE -s -mno-cygwin if_ole.cpp -o gobj/if_ole.o if_ole.cpp: In static member function `static CVim* CVim::Create(int*)': if_ole.cpp:161: error: `KEY_WOW64_64KEY' undeclared (first use this function) if_ole.cpp:161: error: (Each undeclared identifier is reported only once for each function it appears in.) if_ole.cpp: In function `void RecursiveDeleteKey(HKEY__*, const char*)': if_ole.cpp:654: error: `KEY_WOW64_64KEY' undeclared (first use this function) if_ole.cpp: In function `void SetKeyAndValue(const char*, const char*, const char*)': if_ole.cpp:697: error: `KEY_WOW64_64KEY' undeclared (first use this function) if_ole.cpp: In function `void InitOLE(int*)': if_ole.cpp:756: warning: passing NULL used for non-pointer converting 3 of `HRESULT RegisterActiveObject(IUnknown*, const CLSID&, DWORD, DWORD*)' make: *** [gobj/if_ole.o] Error 1 This is a 64 bit Vista machine, if that helps at all. - Christian -- Christian J. Robinson -- http://christianrobinson.name/ -- 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
Re: filetypedetect for perl6
tyru wrote: > When this patch included? It has already been included in vim73 branch (on July 30). See: $ hg diff -c c587f56735cc -- Dominique -- 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
Re: filetypedetect for perl6
When this patch included? -- 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
Re: [patch] avoid useless call to STRLEN(...) in function uniquefy_paths().
Dominique Pelle wrote: > Attached patch avoids a useless call to STRLEN(...) in function > uniquefy_paths(). Thanks! -- "You're fired." (1980) "You're laid off." (1985) "You're downsized." (1990) "You're rightsized." (1992) (Scott Adams - The Dilbert principle) /// 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. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [patch] fixed uninitialized memory access in i_CTRL-X_s (spell suggestion)
On 01/08/10 16:06, Bram Moolenaar wrote:
Dominique Pelle wrote:
I still see other Valgrind errors with spell suggestion with
Vim-7.2.446 and Vim-7.3c (2448:943280505f72) when doing:
$ valgrind --num-callers=50 --track-origins=yes 2> vg.log \
vim -u NONE -c 'set spell|call feedkeys("i,,\s")'
==4200== Conditional jump or move depends on uninitialised value(s)
==4200==at 0x8123C84: utf_head_off (mbyte.c:3290)
==4200==by 0x8198E00: suggest_trie_walk (spell.c:11666)
==4200==by 0x8197E64: suggest_try_change (spell.c:11229)
==4200==by 0x8197100: spell_suggest_intern (spell.c:10777)
==4200==by 0x8196D1E: spell_find_suggest (spell.c:10641)
==4200==by 0x81966A3: spell_suggest_list (spell.c:10494)
==4200==by 0x81A248D: expand_spelling (spell.c:16021)
==4200==by 0x806AD4E: ins_compl_get_exp (edit.c:4163)
==4200==by 0x806B793: ins_compl_next (edit.c:4506)
==4200==by 0x806C9DB: ins_complete (edit.c:5139)
==4200==by 0x80669B4: edit (edit.c:1366)
==4200==by 0x8134208: invoke_edit (normal.c:9024)
==4200==by 0x81341AE: nv_edit (normal.c:8997)
==4200==by 0x8127B87: normal_cmd (normal.c:1190)
==4200==by 0x80E8E97: main_loop (main.c:1260)
==4200==by 0x80E88CC: main (main.c:965)
==4200== Uninitialised value was created by a stack allocation
==4200==at 0x8197D56: suggest_try_change (spell.c:11204)
Attached new patch fixes it but don't think it's ideal
since giving spell suggestion when only typing punctuation
does not make much sense.
Thanks. I'll include it as is.
While trying to reproduce this I encountered a crash: Soundfolding
breaks on a 0x300 character.
Perhaps there are a few more bugs in this area...
U+0300 is a combining grave accent, its UTF-8 representation in hex is
CC 80. Maybe Vim chokes on the 0x80 trailing byte? Any byte except the
first in the UTF-8 representation of a Unicode codepoint may have that
value without being in any way "special".
As a reminder, UTF-8 strictly segregates the values bytes may have, as
follows:
00-7F single bytes
80-BF trailing bytes (any but the first) in a multibyte sequence
C0-DF first byte in a 2-byte sequence
E0-EF first byte in a 3-byte sequence
F0-F7 first byte in a 4-byte sequence
F8-FB first byte in a 5-byte sequence
FC-FD first byte in a 6-byte sequence
FE-FF invalid
In addition, the Unicode Consortium has decided that no codepoint will
ever be accepted above U+10FFFD, not even for private use, and that
"overlong sequences" are not to be tolerated; this makes byte values F5
and above "invalid for interchange".
Best regards,
Tony.
--
Economics, n.:
Economics is the study of the value and meaning of J. K.
Galbraith ...
-- Mike Harding, "The Armchair Anarchist's Almanac"
--
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
[patch] avoid useless call to STRLEN(...) in function uniquefy_paths().
Hi Attached patch avoids a useless call to STRLEN(...) in function uniquefy_paths(). Regards -- Dominique -- 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 diff -r 22a6f99e6477 src/misc1.c --- a/src/misc1.c Sun Aug 01 16:13:51 2010 +0200 +++ b/src/misc1.c Sun Aug 01 16:57:43 2010 +0200 @@ -2274,7 +2274,7 @@ * existing line. Otherwise a new line has to be allocated * Can't do this when using Netbeans, because we would need to invoke * netbeans_removed(), which deallocates the line. Let ml_replace() take - * care of notifiying Netbeans. + * care of notifying Netbeans. */ #ifdef FEAT_NETBEANS_INTG if (netbeans_active()) @@ -5142,7 +5142,7 @@ } /* - * Recognize a "public/private/proctected" scope declaration label. + * Recognize a "public/private/protected" scope declaration label. */ int cin_isscopedecl(s) @@ -6034,7 +6034,7 @@ int ind_open_imag = 0; /* - * spaces from the prevailing indent for a line that is not precededof by + * spaces from the prevailing indent for a line that is not preceded by * an opening brace. */ int ind_no_brace = 0; @@ -9301,7 +9301,7 @@ } /* - * Split the 'path' option to a an array of strings as garray_T. Relative + * Split the 'path' option into an array of strings in garray_T. Relative * paths are expanded to their equivalent fullpath. This includes the "." * (relative to current buffer directory) and empty path (relative to current * directory) notations. @@ -9412,7 +9412,6 @@ char_u *pat; char_u *file_pattern; char_u *curdir = NULL; -int len_curdir = 0; regmatch_T regmatch; garray_T path_ga; @@ -9445,7 +9444,6 @@ if ((curdir = alloc((int)(MAXPATHL))) == NULL) return; mch_dirname(curdir, MAXPATHL); -len_curdir = (int)STRLEN(curdir); expand_path_option(curdir, &path_ga);
Re: Combining characters and case-changing
On 01/08/10 16:06, Bram Moolenaar wrote: Tony Mechelynck wrote: Using latest Vim 7.3c, compiled 2010-07-31 21:22:42 +0200 immediately after pulling. Hitting ~ (tilde) on a letter + combining character gives faulty result. Reproducible: Always. Steps to reproduce(1): 1. Type text in some case-sensitive script (not Hebrew or Arabic) with some combining characters in it (e.g. Russian with combining acute accent(s)). 2. In Normal mode, move the cursor over a letter with combining accent and hit ~ (tilde). Expected result: The letter should change case and keep its combining accent. Actual result: The accented letter is replaced by both its upper- and lower-case variants, without the accent. I'll fix this. Note that for the example it's very useful to give the actual text to reproduce it on. Well, previously (in the Ctrl-R case) I had done it, but the Russian characters in my text quoted in your answer were totally garbled (wrong Content-Type charset maybe?). You could have reused the same example text, or any text with any combining character; I used the combining acute accent U+0301; there are other combining codepoints in the same Unicode block. Steps to reproduce(2) 1. Like before, type text with some combining characters in it. 2. Select a section of text (I used V for single-line linewise-visual). 3. Hit the tilde. Expected result: The text should change case, with the combining characters remaining where they belong. Actual result: - Accented characters become doubled, losing their accent. - At the end of the selection, the last characters (as many as there were accents) are not case-toggled. I can't reproduce doubling the characters. Do you have 'delcombine' set perhaps? Yes I do. This way I can easily correct an error if I notice that I have put the accent on the wrong syllable, or the wrong diacritic on the right letter. Additional info: I haven't tested what happens with _several_ combining characters on a single letter (e.g. non-precomposed Classical Greek with breathing, accent and/or iota-subscript/adscript on the same vowel), or with spacing and combining characters of different byte-length (Cyrillic letters and combining-acute are all two bytes per codepoint in UTF-8). Neither did I check that ~ in case-neutral text with combining characters (such as vocalised Semitic text) is a no-op. I have fixed one problem. Please check if you can still reproduce the others. If so, please include the text. No, the tilde now works correctly, both in Normal mode (when toggling one character at a time, with 'tildeop' at its default off setting), and in linewise Visual mode (when toggling a full line in one operation). The length of the Visual text operated upon is now also correct. Best regards, Tony. -- "It took me fifteen years to discover that I had no talent for writing, but I couldn't give up because by that time I was too famous." -- Robert Benchly -- 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
Re: syntax/r.vim
On Sun, Aug 1, 2010 at 11:06 AM, Bram Moolenaar wrote: > > Jakson A. Aquino wrote: > >> I tried to contact the maintainer of syntax/r.vim by sending email to >> both his address at the syntax/r.vim (13 days ago) and the one >> published at http://uosis.mif.vu.lt/~zemlys (4 days ago). I didn't >> get any reply. Chen Zhuojun also reports at >> http://www.vim.org/scripts/script.php?script_id=2984 that the >> maintainer of syntax/r.vim didn't reply to an attempt of contact. >> >> The filetype plugin that I maintain has a few improvements to R syntax >> highlighting and I would be glad if all users could benefit from these >> improvements and not just the ones who download the plugin. How should >> I proceed? I submitted two scripts related to R some days ago to this >> list but it seems that this is not a good moment to make big changes >> in the runtime files. > > If a maintainer doesn't respond then we need to find someone to take > over. If you want to do this, that's great. I would like to maintain the syntax/r.vim since I'm already doing this in my plugin. > If the current version doesn't work, then replacing it with one that > does work can be done right now. If your plugin adds a lot of features > and the old one did work then we better postpone including it until > after the 7.3 release. The current version works well. My plugin adds just a few improvements. The most important are the specification of spell regions (comments and strings) and the highlighting of R functions, but this last feature is achieved by an additional file containing the list of all functions. I'm not sure if it's a good idea to add this list to the official Vim runtime because each new version of R includes new functions and exclude others. Moreover, each user loads a different set of R packages and, thus, the list of functions isn't the same for all users. I'll send a patch to the syntax/r.vim after the release of 7.3 if the current maintainer doesn't respond until the release. Thanks! Jakson Aquino -- 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
Re: Combining characters and case-changing
On 01/08/10 13:43, Jakson A. Aquino wrote: On Sun, Aug 1, 2010 at 5:59 AM, Tony Mechelynck wrote: Using latest Vim 7.3c, compiled 2010-07-31 21:22:42 +0200 immediately after pulling. Hitting ~ (tilde) on a letter + combining character gives faulty result. Reproducible: Always. Steps to reproduce(1): 1. Type text in some case-sensitive script (not Hebrew or Arabic) with some combining characters in it (e.g. Russian with combining acute accent(s)). 2. In Normal mode, move the cursor over a letter with combining accent and hit ~ (tilde). Expected result: The letter should change case and keep its combining accent. Actual result: The accented letter is replaced by both its upper- and lower-case variants, without the accent. Steps to reproduce(2) 1. Like before, type text with some combining characters in it. 2. Select a section of text (I used V for single-line linewise-visual). 3. Hit the tilde. Expected result: The text should change case, with the combining characters remaining where they belong. Actual result: - Accented characters become doubled, losing their accent. - At the end of the selection, the last characters (as many as there were accents) are not case-toggled. Additional info: I haven't tested what happens with _several_ combining characters on a single letter (e.g. non-precomposed Classical Greek with breathing, accent and/or iota-subscript/adscript on the same vowel), or with spacing and combining characters of different byte-length (Cyrillic letters and combining-acute are all two bytes per codepoint in UTF-8). Neither did I check that ~ in case-neutral text with combining characters (such as vocalised Semitic text) is a no-op. Here it happens what was expected. I tested with tutor.utf-8 (fr, ru, el, vi). I'm using Ubuntu 10.04 in pt_BR.UTF-8 locale with Vim from current hg. Best regards, Jakson The problem I saw existed only in text containing combining characters (i.e. Unicode codepoints which are drawn superimposed on the preceding character, such as e.g. U+0301 COMBINING ACUTE ACCENT). When the accent is part of a spacing codepoint (e.g. é U+00E9 LATIN SMALL LETTER E WITH ACUTE) there was no problem. With Vim, combining characters have to be entered each separately, and if 'delcombine' is on they can also be removed one-by-one, separately from the letter over which they are drawn. I was using gvim; if you were using Vim in an mlterm console (with 'termbidi' on) the drawing of the full line (including displaying words in RTL scripts right-to-left even in LTR sentences, and displaying combining characters superimposed if there are any) is handled by the terminal, not by Vim: this might make a difference. In Russian, for instance, the combining acute accent is the only way to add an accent over a Cyrillic letter; it is used to indicate stress in dictionaries, in reading books for children or foreigners learning the language, and sometimes to avoid ambiguity as in "у белых теперь бо́льшая выгода" "u byelyh teper' BOLshaya vygoda", "White now has a bigger advantage", which I saw once in a Russian book about chess; without the written accent (у белых теперь большая выгода) it would be read "u byelyh teper' bolSHAya vygoda", "White now has a big advantage". In SeaMonkey I see this accent over the letter л, which is wrong; Vim correctly displays it over the о; but SeaMonkey, unlike Vim, has the possibility to place the cursor between the combining character and the spacing character preceding it. Similarly, Hebrew and Arabic (where case differences don't exist) optionally use combining characters to denote short vowels etc. (again, in dictionaries, reading books for children or foreigners, sacred writings, and in any text to avoid ambiguity); in many scripts the possibility exists to use combining characters, but precombined characters, when they exist, are often preferred in practice. Bram corrected the problem in a changeset dated 14:22:48 +0200 today (that would be shortly after your reply), and it works. Thanks Bram! Best regards, Tony. -- Snoring is prohibited unless all bedroom windows are closed and securely locked. [real standing law in Massachusetts, United States of America] -- 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
Re: syntax/r.vim
Jakson A. Aquino wrote: > I tried to contact the maintainer of syntax/r.vim by sending email to > both his address at the syntax/r.vim (13 days ago) and the one > published at http://uosis.mif.vu.lt/~zemlys (4 days ago). I didn't > get any reply. Chen Zhuojun also reports at > http://www.vim.org/scripts/script.php?script_id=2984 that the > maintainer of syntax/r.vim didn't reply to an attempt of contact. > > The filetype plugin that I maintain has a few improvements to R syntax > highlighting and I would be glad if all users could benefit from these > improvements and not just the ones who download the plugin. How should > I proceed? I submitted two scripts related to R some days ago to this > list but it seems that this is not a good moment to make big changes > in the runtime files. If a maintainer doesn't respond then we need to find someone to take over. If you want to do this, that's great. If the current version doesn't work, then replacing it with one that does work can be done right now. If your plugin adds a lot of features and the old one did work then we better postpone including it until after the 7.3 release. -- The acknowledged parents of reengineering are Michael Hammer and James Champy. When I say they're the "parents" I don't mean they had sex - and I apologize for making you think about it. I mean they wrote the best-selling business book _Reengineering the Corporation_, which was published in 1993. Businesses flocked to reengineering like frat boys to a drunken cheerleader. (This analogy wasn't necessary, but I'm trying to get my mind off that Hammer and Champy thing.) (Scott Adams - The Dilbert principle) /// 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. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [patch] fixed uninitialized memory access in i_CTRL-X_s (spell suggestion)
Dominique Pelle wrote:
> I still see other Valgrind errors with spell suggestion with
> Vim-7.2.446 and Vim-7.3c (2448:943280505f72) when doing:
>
> $ valgrind --num-callers=50 --track-origins=yes 2> vg.log \
> vim -u NONE -c 'set spell|call feedkeys("i,,\s")'
>
> ==4200== Conditional jump or move depends on uninitialised value(s)
> ==4200==at 0x8123C84: utf_head_off (mbyte.c:3290)
> ==4200==by 0x8198E00: suggest_trie_walk (spell.c:11666)
> ==4200==by 0x8197E64: suggest_try_change (spell.c:11229)
> ==4200==by 0x8197100: spell_suggest_intern (spell.c:10777)
> ==4200==by 0x8196D1E: spell_find_suggest (spell.c:10641)
> ==4200==by 0x81966A3: spell_suggest_list (spell.c:10494)
> ==4200==by 0x81A248D: expand_spelling (spell.c:16021)
> ==4200==by 0x806AD4E: ins_compl_get_exp (edit.c:4163)
> ==4200==by 0x806B793: ins_compl_next (edit.c:4506)
> ==4200==by 0x806C9DB: ins_complete (edit.c:5139)
> ==4200==by 0x80669B4: edit (edit.c:1366)
> ==4200==by 0x8134208: invoke_edit (normal.c:9024)
> ==4200==by 0x81341AE: nv_edit (normal.c:8997)
> ==4200==by 0x8127B87: normal_cmd (normal.c:1190)
> ==4200==by 0x80E8E97: main_loop (main.c:1260)
> ==4200==by 0x80E88CC: main (main.c:965)
> ==4200== Uninitialised value was created by a stack allocation
> ==4200==at 0x8197D56: suggest_try_change (spell.c:11204)
>
> Attached new patch fixes it but don't think it's ideal
> since giving spell suggestion when only typing punctuation
> does not make much sense.
Thanks. I'll include it as is.
While trying to reproduce this I encountered a crash: Soundfolding
breaks on a 0x300 character.
Perhaps there are a few more bugs in this area...
--
Team-building exercises come in many forms but they all trace their roots back
to the prison system. In your typical team-building exercise the employees
are subjected to a variety of unpleasant situations until they become either a
cohesive team or a ring of car jackers.
(Scott Adams - The Dilbert principle)
/// 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.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: The :list command uses 'listchars' (undocumented)
Tony Mechelynck wrote: > Neither :help 'listchars' nor :help :list mention that the latter uses > the former: for instance, with > > :set listchars=tab:\|_,eol:¶ > > the :list command will show a ¶ (not a dollar sign as stated) at the end > of each line, and hard tabs will be diplayed as ||___|___ > not ^I^I^I > > I suggest the attached documentation patch. Thanks. -- Managers are like cats in a litter box. They instinctively shuffle things around to conceal what they've done. (Scott Adams - The Dilbert principle) /// 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. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [patch] avoid useless call to update_single_line() when 'modifiable' is changed
Dominique Pelle wrote: > Changeset 2266:fb627e94e6c6 introduced a call to update_single_line() > when 'modifiable' option is changed. At the time this change was needed > since 'modifiable' option had a influence on the way concealable items > were shown. > > But now this change is useless I think since 'modifiable' no longer has > an influence on concealable items. Attached patch rolls back part of > 2266:fb627e94e6c6 to avoid a useless redraw when changing option > 'modifiable' and to simplify code slightly. Thanks. -- The word "leader" is derived from the word "lead", as in the material that bullets are made out of. The term "leader" was popularized at about the same time as the invention of firearms. It grew out of the observation that the person in charge of every organization was the person whom everyone wanted to fill with hot lead. I don't recomment this; it's just a point of historical interest. (Scott Adams - The Dilbert principle) /// 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. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [patch] fixed uninitialized memory access in i_CTRL-X_s (spell suggestion)
Dominique Pelle wrote:
> Valgrind detects access to uninitialized memory in both Vim-7.2.446 and
> Vim-7.3.c BETA (2448:943280505f72) with the i_CTRL-X_s feature: spell
> suggestion of word in front of cursor. It happens when word in front of
> cursor is only 1 letter long and a vowel. I think that vowels are ignored
> in the Soundex algorithm so variable goodsound at spell.c:14758 is an
> empty string and goodsound[1] is accessed (beyond end of string).
>
> Steps to reproduce:
>
> 1) Run:
>
> $ valgrind --num-callers=50 --track-origins=yes 2> vg.log \
> vim -u NONE -c 'set spell' -c 'call feedkeys("aa\s")'
>
> 2) Observe following error in vg.log:
>
> ==3666== Conditional jump or move depends on uninitialised value(s)
> ==3666==at 0x81A000B: soundalike_score (spell.c:14758)
> ==3666==by 0x819CC0C: stp_sal_score (spell.c:13142)
> ==3666==by 0x819E3F2: rescore_one (spell.c:13923)
> ==3666==by 0x819E2EC: rescore_suggestions (spell.c:13896)
> ==3666==by 0x8197186: spell_suggest_intern (spell.c:10791)
> ==3666==by 0x8196D66: spell_find_suggest (spell.c:10641)
> ==3666==by 0x81966EB: spell_suggest_list (spell.c:10494)
> ==3666==by 0x81A24D5: expand_spelling (spell.c:16021)
> ==3666==by 0x806AD86: ins_compl_get_exp (edit.c:4163)
> ==3666==by 0x806B7CB: ins_compl_next (edit.c:4506)
> ==3666==by 0x806CA13: ins_complete (edit.c:5139)
> ==3666==by 0x80669EC: edit (edit.c:1366)
> ==3666==by 0x813427C: invoke_edit (normal.c:9024)
> ==3666==by 0x8134222: nv_edit (normal.c:8997)
> ==3666==by 0x8127BFB: normal_cmd (normal.c:1190)
> ==3666==by 0x80E8ECF: main_loop (main.c:1260)
> ==3666==by 0x80E8904: main (main.c:965)
> ==3666== Uninitialised value was created by a stack allocation
> ==3666==at 0x819C9BB: stp_sal_score (spell.c:13096)
>
> Attached patch fixes it, but please review it as I can't say
> that understand all details of the soundalike algorithm.
I could see it happen when finding a suggestion for the word "u".
Some of the alternatives, such as "W" or "Y" have an empty soundfold
result.
I think changing "*" to empty deserves a score of SCORE_DEL. If there
is more after the "*" then SCORE_MAXMAX seems appropriate.
I'll make it work like that.
--
I once paid $12 to peer at the box that held King Tutankhamen's little
bandage-covered midget corpse at the De Young Museum in San Francisco. I
remember thinking how pleased he'd be about the way things turned out in his
afterlife.
(Scott Adams - The Dilbert principle)
/// 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.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: [patch] fixed typos in README files
Dominique Pelle wrote: > Attached patch fixes typos in README files. Thanks. -- Are leaders born or made? And if they're made, can we return them under warranty? (Scott Adams - The Dilbert principle) /// 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. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Combining characters and case-changing
Tony Mechelynck wrote: > Using latest Vim 7.3c, compiled 2010-07-31 21:22:42 +0200 immediately > after pulling. > > Hitting ~ (tilde) on a letter + combining character gives faulty result. > > > Reproducible: Always. > > > Steps to reproduce(1): > 1. Type text in some case-sensitive script (not Hebrew or Arabic) with > some combining characters in it (e.g. Russian with combining acute > accent(s)). > 2. In Normal mode, move the cursor over a letter with combining accent > and hit ~ (tilde). > > Expected result: > The letter should change case and keep its combining accent. > > Actual result: > The accented letter is replaced by both its upper- and lower-case > variants, without the accent. I'll fix this. Note that for the example it's very useful to give the actual text to reproduce it on. > Steps to reproduce(2) > 1. Like before, type text with some combining characters in it. > 2. Select a section of text (I used V for single-line linewise-visual). > 3. Hit the tilde. > > Expected result: > The text should change case, with the combining characters remaining > where they belong. > > Actual result: > - Accented characters become doubled, losing their accent. > - At the end of the selection, the last characters (as many as there > were accents) are not case-toggled. I can't reproduce doubling the characters. Do you have 'delcombine' set perhaps? > Additional info: > I haven't tested what happens with _several_ combining characters on a > single letter (e.g. non-precomposed Classical Greek with breathing, > accent and/or iota-subscript/adscript on the same vowel), or with > spacing and combining characters of different byte-length (Cyrillic > letters and combining-acute are all two bytes per codepoint in UTF-8). > Neither did I check that ~ in case-neutral text with combining > characters (such as vocalised Semitic text) is a no-op. I have fixed one problem. Please check if you can still reproduce the others. If so, please include the text. -- Scientists decoded the first message from an alien civilization: SIMPLY SEND 6 TIMES 10 TO THE 50 ATOMS OF HYDROGEN TO THE STAR SYSTEM AT THE TOP OF THE LIST, CROSS OFF THAT STAR SYSTEM, THEN PUT YOUR STAR SYSTEM AT THE BOTTOM OF THE LIST AND SEND IT TO 100 OTHER STAR SYSTEMS. WITHIN ONE TENTH GALACTIC ROTATION YOU WILL RECEIVE ENOUGH HYDROGREN TO POWER YOUR CIVILIZATION UNTIL ENTROPY REACHES ITS MAXIMUM! IT REALLY WORKS! /// 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. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Combining characters and case-changing
On Sun, Aug 1, 2010 at 5:59 AM, Tony Mechelynck wrote: > Using latest Vim 7.3c, compiled 2010-07-31 21:22:42 +0200 immediately after > pulling. > > Hitting ~ (tilde) on a letter + combining character gives faulty result. > > > Reproducible: Always. > > > Steps to reproduce(1): > 1. Type text in some case-sensitive script (not Hebrew or Arabic) with some > combining characters in it (e.g. Russian with combining acute accent(s)). > 2. In Normal mode, move the cursor over a letter with combining accent and > hit ~ (tilde). > > Expected result: > The letter should change case and keep its combining accent. > > Actual result: > The accented letter is replaced by both its upper- and lower-case variants, > without the accent. > > > Steps to reproduce(2) > 1. Like before, type text with some combining characters in it. > 2. Select a section of text (I used V for single-line linewise-visual). > 3. Hit the tilde. > > Expected result: > The text should change case, with the combining characters remaining where > they belong. > > Actual result: > - Accented characters become doubled, losing their accent. > - At the end of the selection, the last characters (as many as there were > accents) are not case-toggled. > > > Additional info: > I haven't tested what happens with _several_ combining characters on a > single letter (e.g. non-precomposed Classical Greek with breathing, accent > and/or iota-subscript/adscript on the same vowel), or with spacing and > combining characters of different byte-length (Cyrillic letters and > combining-acute are all two bytes per codepoint in UTF-8). Neither did I > check that ~ in case-neutral text with combining characters (such as > vocalised Semitic text) is a no-op. Here it happens what was expected. I tested with tutor.utf-8 (fr, ru, el, vi). I'm using Ubuntu 10.04 in pt_BR.UTF-8 locale with Vim from current hg. Best regards, Jakson -- 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
Re: [patch] Modern UI upgrade for Vim NSIS installer
On 01/08/10 09:50, Guopeng Wen wrote: On Sun, Aug 1, 2010 at 7:57 AM, Tux wrote: [...] BTW while you're at it, what about a better sidebar banner? The existing one looks rather boring. I'm not really good with GFX, but maybe someone from this list could do it. That's the pristine banner from NSIS. Yes it's better to use a banner for Vim. I'm not good at artwork either, so, I'm expecting other talented guys to create one to be used in the installer. Regards! Guopeng Boring or not, those graphics have the merit of being "consistent" with Windows installers for various programs. I think they are acceptable. If we want to design a specific image for Vim, IMHO it would have to - be based on the Vim "V" or "Vim" logo - not be so trendy that next year it'd be out of fashion - not make the text hard to read, not even for colour-blind people. The latter probably implies either (a) text outside the image, or (b) text inside the image, but on a relatively flat-coloured part of it, and in contrasting tones (white text on dark BG, black text on light BG, etc.). Best regards, Tony. -- "He's not pining, he's passed on! This parrot won't squawk! He's ceased to be! He's expired, and gone to meet his maker! It's a stiff! No breath of life, he may rest in peace! If you hadn't nailed him to the perch, he'd be pushing up the daisies! He's off the twig! He's kicked the bucket! He's curled up his tooties! He's shuffled off this mortal world! He's run down the curtain, and joined the bleed'n Choir Invincible! HE'S FUCKING SNUFFED IT! Vis-a-vi his metabolic processes is head is lost. All statements concerning this parrot is no longer a going concern, after from now on, Inoperative... THIS IS AN EX-PARROT!! -- 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
Combining characters and case-changing
Using latest Vim 7.3c, compiled 2010-07-31 21:22:42 +0200 immediately after pulling. Hitting ~ (tilde) on a letter + combining character gives faulty result. Reproducible: Always. Steps to reproduce(1): 1. Type text in some case-sensitive script (not Hebrew or Arabic) with some combining characters in it (e.g. Russian with combining acute accent(s)). 2. In Normal mode, move the cursor over a letter with combining accent and hit ~ (tilde). Expected result: The letter should change case and keep its combining accent. Actual result: The accented letter is replaced by both its upper- and lower-case variants, without the accent. Steps to reproduce(2) 1. Like before, type text with some combining characters in it. 2. Select a section of text (I used V for single-line linewise-visual). 3. Hit the tilde. Expected result: The text should change case, with the combining characters remaining where they belong. Actual result: - Accented characters become doubled, losing their accent. - At the end of the selection, the last characters (as many as there were accents) are not case-toggled. Additional info: I haven't tested what happens with _several_ combining characters on a single letter (e.g. non-precomposed Classical Greek with breathing, accent and/or iota-subscript/adscript on the same vowel), or with spacing and combining characters of different byte-length (Cyrillic letters and combining-acute are all two bytes per codepoint in UTF-8). Neither did I check that ~ in case-neutral text with combining characters (such as vocalised Semitic text) is a no-op. Best regards, Tony. -- Brady's First Law of Problem Solving: When confronted by a difficult problem, you can solve it more easily by reducing it to the question, "How would the Lone Ranger have handled this?" -- 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
Re: [patch] fixed uninitialized memory access in i_CTRL-X_s (spell suggestion)
Dominique Pellé :
> Hi
>
> Valgrind detects access to uninitialized memory in both Vim-7.2.446 and
> Vim-7.3.c BETA (2448:943280505f72) with the i_CTRL-X_s feature: spell
> suggestion of word in front of cursor. It happens when word in front of
> cursor is only 1 letter long and a vowel. I think that vowels are ignored
> in the Soundex algorithm so variable goodsound at spell.c:14758 is an
> empty string and goodsound[1] is accessed (beyond end of string).
>
> Steps to reproduce:
>
> 1) Run:
>
> $ valgrind --num-callers=50 --track-origins=yes 2> vg.log \
> vim -u NONE -c 'set spell' -c 'call feedkeys("aa\s")'
>
> 2) Observe following error in vg.log:
>
> ==3666== Conditional jump or move depends on uninitialised value(s)
> ==3666== at 0x81A000B: soundalike_score (spell.c:14758)
> ==3666== by 0x819CC0C: stp_sal_score (spell.c:13142)
> ==3666== by 0x819E3F2: rescore_one (spell.c:13923)
> ==3666== by 0x819E2EC: rescore_suggestions (spell.c:13896)
> ==3666== by 0x8197186: spell_suggest_intern (spell.c:10791)
> ==3666== by 0x8196D66: spell_find_suggest (spell.c:10641)
> ==3666== by 0x81966EB: spell_suggest_list (spell.c:10494)
> ==3666== by 0x81A24D5: expand_spelling (spell.c:16021)
> ==3666== by 0x806AD86: ins_compl_get_exp (edit.c:4163)
> ==3666== by 0x806B7CB: ins_compl_next (edit.c:4506)
> ==3666== by 0x806CA13: ins_complete (edit.c:5139)
> ==3666== by 0x80669EC: edit (edit.c:1366)
> ==3666== by 0x813427C: invoke_edit (normal.c:9024)
> ==3666== by 0x8134222: nv_edit (normal.c:8997)
> ==3666== by 0x8127BFB: normal_cmd (normal.c:1190)
> ==3666== by 0x80E8ECF: main_loop (main.c:1260)
> ==3666== by 0x80E8904: main (main.c:965)
> ==3666== Uninitialised value was created by a stack allocation
> ==3666== at 0x819C9BB: stp_sal_score (spell.c:13096)
Hi
I still see other Valgrind errors with spell suggestion with
Vim-7.2.446 and Vim-7.3c (2448:943280505f72) when doing:
$ valgrind --num-callers=50 --track-origins=yes 2> vg.log \
vim -u NONE -c 'set spell|call feedkeys("i,,\s")'
==4200== Conditional jump or move depends on uninitialised value(s)
==4200==at 0x8123C84: utf_head_off (mbyte.c:3290)
==4200==by 0x8198E00: suggest_trie_walk (spell.c:11666)
==4200==by 0x8197E64: suggest_try_change (spell.c:11229)
==4200==by 0x8197100: spell_suggest_intern (spell.c:10777)
==4200==by 0x8196D1E: spell_find_suggest (spell.c:10641)
==4200==by 0x81966A3: spell_suggest_list (spell.c:10494)
==4200==by 0x81A248D: expand_spelling (spell.c:16021)
==4200==by 0x806AD4E: ins_compl_get_exp (edit.c:4163)
==4200==by 0x806B793: ins_compl_next (edit.c:4506)
==4200==by 0x806C9DB: ins_complete (edit.c:5139)
==4200==by 0x80669B4: edit (edit.c:1366)
==4200==by 0x8134208: invoke_edit (normal.c:9024)
==4200==by 0x81341AE: nv_edit (normal.c:8997)
==4200==by 0x8127B87: normal_cmd (normal.c:1190)
==4200==by 0x80E8E97: main_loop (main.c:1260)
==4200==by 0x80E88CC: main (main.c:965)
==4200== Uninitialised value was created by a stack allocation
==4200==at 0x8197D56: suggest_try_change (spell.c:11204)
Attached new patch fixes it but don't think it's ideal
since giving spell suggestion when only typing punctuation
does not make much sense.
-- Dominique
--
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
diff -r 943280505f72 src/spell.c
--- a/src/spell.c Sat Jul 31 22:03:44 2010 +0200
+++ b/src/spell.c Sun Aug 01 10:36:28 2010 +0200
@@ -11658,7 +11658,7 @@
* words, the edit distance and then add them. */
add_sound_suggest(su, preword, sp->ts_score, lp);
}
- else
+ else if (sp->ts_fidx > 0)
{
/* Give a penalty when changing non-word char to word
* char, e.g., "thes," -> "these". */
@@ -14755,6 +14755,8 @@
* counted so much, vowels halfway the word aren't counted at all. */
if ((*badsound == '*' || *goodsound == '*') && *badsound != *goodsound)
{
+ if (*goodsound == NUL || *badsound == NUL)
+ return SCORE_MAXMAX;
if (badsound[1] == goodsound[1]
|| (badsound[1] != NUL
&& goodsound[1] != NUL
Re: [patch] Modern UI upgrade for Vim NSIS installer
On Sat, Jul 31, 2010 at 11:57 PM, gongqian li wrote: > What about a portable version like the one created in > http://portableapps.com/news/2009-10-13_-_gvim_portable_7.2 which doesn't > depend on windows registry? that will be really nice. I checked the web site you mentioned. It seems that's a different installation system (although it's based on NSIS, if I read correctly). That means if we build that installer, we may have to distributed two different installers for Windows. Please note I have not checked if its license allow us to distribute such installer directly or not. Anyway, it does not look like I can make the decision to include such installer in Vim distribution. That said, I assume you've tried that distribution yourself, I'm curious about whether it provides shell extension etc. or not. Does it provides context menu (the "Open with Vim" right mouse click menu)? If you run "gvim" directly from command line in any directory, could it launch Vim? Does it provide MS Visual Studio integration? If answer to all of those questions are no, maybe we can do emulate that by leaving out some components. But I'm afraid things are more complex than that. Regards! Guopeng -- 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
Re: [patch] Modern UI upgrade for Vim NSIS installer
On Sun, Aug 1, 2010 at 7:57 AM, Tux wrote: > Guopeng Wen schrob am 31.07.2010 17:34: > >> When should installer do if it found Vim has already installed? >> Vim instance still running? > > I would propose a message box that tells the user to exit Vim first and > continues the installation after clicking "OK" or something. It would be > the easiest way IMO. See my reply to Tony. > BTW while you're at it, what about a better sidebar banner? The existing > one looks rather boring. I'm not really good with GFX, but maybe someone > from this list could do it. That's the pristine banner from NSIS. Yes it's better to use a banner for Vim. I'm not good at artwork either, so, I'm expecting other talented guys to create one to be used in the installer. Regards! Guopeng -- 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
Re: [patch] Modern UI upgrade for Vim NSIS installer
Resend, previous reply send to Tony only. Sorry to the duplicated message, Tony. On Sun, Aug 1, 2010 at 7:22 AM, Tony Mechelynck wrote: > On 31/07/10 17:34, Guopeng Wen wrote: >> >> On 07/31/2010 10:46 PM, Tony Mechelynck wrote: >>> >>> Hm, I'm not concerned (since I'm on Linux), but it seems to go in the >>> opposite direction to Steve Hall's "one-click" installer. >>> >>> What about a first page with two radio buttons: >>> >>> (*) Standard install >>> ( ) Custom install >>> >>> ? The first option would install Vim with "typical" settings (and >>> sufficiently powerful to let the user customize it later via vimrc >>> etc.), bypassing all those menus of yours, which would appear if the >>> user selects "Custom install"? >>> >>> >>> Best regards, >>> Tony. >> >> Hmmm, "one-click" is not powerful enough, how about "no-click" :) >> >> You just brought up another topic I'm trying to touch. NSIS >> installer is in fact quite flexible - it can be executed "silently". >> That is, slap some control parameters on command line, it can run >> from beginning to end. Well, it cannot happen automatically, you >> need to do something in the script to make that happen. It's used >> for mass installation, which is apparently appealing to Linux users >> who also use Windows (like me). Silent installer is in fact one of >> the TODO item of Vim. Does it sound like what you expected? >> >> Here's some of design issues I have not decided yet: >> >> - Control granularity? >> Just let user specifies installation type, or makes it possible to >> specify which component to install (needs config file for this). >> I think installation type should probably be OK. >> >> - Error handing? >> When should installer do if it found Vim has already installed? >> Vim instance still running? I think the dumb solution should be >> use - just panic and abort. >> >> - Log? >> I have not tried that yet. Apparently some kind of log should be >> create during silent installation, so the user can check if >> something go wrong. However, it seems default build of NSIS has >> not enabled logging. You need a custom build to enable that. >> >> Feedbacks are welcomed. >> > > If Vim is already installed, not running, and lower version (or same version > and lower patchlevel), maybe no panic but default to upgrade? (if different > version, leave the "old" $VIMRUNTIME in place? Remove it? Let the user > decide?) > > If already running, then clear error message: something like "Vim is already > running. Please quit Vim before upgrading" or similar. Or if possible (if > the running instance has +clientserver) maybe close the existing Vim by > means of the client-server facility (after asking user's permission) Sorry I didn't make it clear that those "design issues" I listed above are for silent mode only. For normal mode, the installer behaves mostly like what you described, except that it won't close any open Vim automatically, which I think is too dangerous to do. Silent mode is different in that you should not ask for any user feedback once started. > If at all possible, IMHO a log should be produced for every installation, > silent or otherwise (and if the logfile already exists, append to it, maybe > with a datestamp first to separate successive logs). I agree install log is a nice thing to have. There's a few approaches to do it, but most of them needs whoever build Vim installer do something different (a custom build of NSIS, or add more plugins). I'll check if there's less intrusive way to do it. > > Best regards, > Tony. Regards! Guopeng -- 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
