undo file location was: Re: Update on Vim 7.3 status
When editing a file over a network or a removable media (USB stick) it's very easy to misplace the undo file. Also, when a file is edited by several people, or the same person with different login names or from different systems, the undo file would go in the wrong place. Also problems with renaming a directory, moving a directory tree, backups, etc. I see many problems with this solution: more people than one can edit the same file. So they should share the undo file?! Or there will be one undo file for each user? And what if the user is unknown, for example on network-attached disks where the original user (from the far computer) even does not exist on the local one? And what about directories where it is not a good idea to create files without a very good reason like directories exported via http, directories under version control etc. etc. Imagine usual user of mercurial or Novell BuildService: they use the command addremove quite often. And if there was a file created automatically on the background they add it to the repository accidentally. This is not a good idea, is it? And there are many other examples. Status files of the editor should be in the storage area reserved for such editor. In this case it is ~/.vim (on UN*X) This is the (unspoken?) rule valid for decades on UN*X systems. Yes, it means that we loose some automatic features you probably meant like a persistent undo working over file transfer on USB key from comp1 to comp2. But this is not what should be done by editor, at least not by default. The list of complications is much longer and more serious than such advantage. I vote for following standards in this case. Milan -- 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: Update on Vim 7.3 status
On 24/05/10 23:52, Jordan Lewis wrote: [...] I should have worded my post better - I did mean the directory of the file as you indicate. And the patch doesn't blindly name all undo files the same if they have the same filename - with a common undo directory, the files will be named path_to_vim73_Makefile.un~, path_to_vim73_src_Makefile.un~, etc. - Jordan Ah, well, I guess that's one detail missing in the help: under 'undofile' it is said that the name of the undofile is specified by 'undodir', but 'undodir' specifies the _directory_ of the undofile, resending to 'backupdir' for details, but nowhere (that I can find) does the help specify the _name_ of the undo file. The version of the help file I'm looking at is: *options.txt* For Vim version 7.3a. Last change: 2010 May 13 Best regards, Tony. -- Windows M!uqomz -- 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: Update on Vim 7.3 status
On Tue, May 25, 2010 at 01:21:43PM +0200, Tony Mechelynck wrote: On 24/05/10 23:52, Jordan Lewis wrote: [...] I should have worded my post better - I did mean the directory of the file as you indicate. And the patch doesn't blindly name all undo files the same if they have the same filename - with a common undo directory, the files will be named path_to_vim73_Makefile.un~, path_to_vim73_src_Makefile.un~, etc. - Jordan Ah, well, I guess that's one detail missing in the help: under 'undofile' it is said that the name of the undofile is specified by 'undodir', but 'undodir' specifies the _directory_ of the undofile, resending to 'backupdir' for details, but nowhere (that I can find) does the help specify the _name_ of the undo file. From :help 'undodir' . means using the directory of the file. The undo file name for file.txt is .file.txt.un~. For other directories the file name is the full path of the edited file, with path separators replaced with %. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Update on Vim 7.3 status
On Tue, May 25, 2010 at 02:29:23PM +0200, Bram Moolenaar wrote: James Vega wrote: Are the undo files supposed to be hidden when 'undodir' is not the current directory? If so, that's not currently the case. When putting undo files with the edited files they are made hidden, just like swap files. When putting undo files in a specified undo directory they are not hidden. The file name is completely different then: It is the full path with path separators changed to '%'. That's what happens now, right? It is. I just hadn't fully read the help when I sent the email and was expecting, for some reason, the undo files to always be hidden regardless of the directory they are stored in. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Update on Vim 7.3 status
On 25/05/10 14:19, James Vega wrote: On Tue, May 25, 2010 at 01:21:43PM +0200, Tony Mechelynck wrote: On 24/05/10 23:52, Jordan Lewis wrote: [...] I should have worded my post better - I did mean the directory of the file as you indicate. And the patch doesn't blindly name all undo files the same if they have the same filename - with a common undo directory, the files will be named path_to_vim73_Makefile.un~, path_to_vim73_src_Makefile.un~, etc. - Jordan Ah, well, I guess that's one detail missing in the help: under 'undofile' it is said that the name of the undofile is specified by 'undodir', but 'undodir' specifies the _directory_ of the undofile, resending to 'backupdir' for details, but nowhere (that I can find) does the help specify the _name_ of the undo file. From :help 'undodir' . means using the directory of the file. The undo file name for file.txt is .file.txt.un~. For other directories the file name is the full path of the edited file, with path separators replaced with %. My bad, I didn't read attentively enough. Best regards, Tony. -- Whistler's Law: You never know who is right, but you always know who is in charge. -- 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: Update on Vim 7.3 status
Christian Brabandt wrote: On Mon, May 24, 2010 10:06 pm, Bram Moolenaar wrote: I also changed it to put the undofile with the edited file. That should work, as writing a file usually means the undofile can be written there as well. It's possible to change this with the 'undodir' option. Is this a good idea? Generally I wouldn't mind if I am the only one who edits certain files. But what about project directories, that are accessed by several people? .names.un~ files would accumulate (and since I usually have to work on Windows, they will even be visible for everybody). This might be a problem for production servers, on which only certain files are allowed to be. Well, I guess I have to set 'undodir'. (Will it be possible to set 'undodir' only for certain files via e.g. autocommands?) This completely depends on what you are doing. When a file has been edited by someone else, using Vim, you can undo his changes. That can be very useful. On the other hand, the undo file will reveal anything you undid, perhaps things you never wanted others to see. We probably need to add an example for a BufWritePre autocommand that only sets 'undofile' for files under your home directory. Perhaps this works: set noundofile au BufWritePre $HOME/* setlocal undofile Untested! Another solution would be to always have 'undofile' set and change 'undodir' depending on the file name. Note that despite the checks it might still be possible that the undo information is corruped and changes your text in unexpected ways. Be careful. Yes I have noted that. BTW: If the undolevels setting is negative, you won't need to write a undo-file, right? Yes, when there is no undo info the file should not be written. But an old file should still be deleted, as it will no longer be valid. And secondly using the provided binary, I could not successfully read in an undo file. I always get this error message: File contents changed, cannot use undo info Hmm, I wonder why. I hope someone can debug this. Oh and for some reason, my vim was killed several times, when I tried the vim73 beta. Unfortunately, I am on Windows and did not get any error message so I don't know how to debug this. The first time I noticed, was when I tried to write a large Textfile. Don't know, if this was related to the undo-file settings, which was turned on. It's the first time I use this compiler. Not sure if that is related. You can try the self-installing executable: ftp://ftp.vim.org/pub/vim/unstable/gvim73a.exe This should be: ftp://ftp.vim.org/pub/vim/unstable/pc/gvim73a.exe Right. -- I AM THANKFUL... ...for the clothes that fit a little too snug because it means I have more than enough to eat. /// 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: Update on Vim 7.3 status
On Tue, May 25, 2010 at 12:48, Christian Brabandt cbli...@256bit.org wrote: On Mon, May 24, 2010 10:06 pm, Bram Moolenaar wrote: I also changed it to put the undofile with the edited file. That should work, as writing a file usually means the undofile can be written there as well. It's possible to change this with the 'undodir' option. Is this a good idea? Generally I wouldn't mind if I am the only one who edits certain files. But what about project directories, that are accessed by several people? .names.un~ files would accumulate (and since I usually have to work on Windows, they will even be visible for everybody). This might be a problem for production servers, on which only certain files are allowed to be. Well, I guess I have to set 'undodir'. (Will it be possible to set 'undodir' only for certain files via e.g. autocommands?) If there’s one thing I’ve learned it’s that you should never work on production servers or network file-systems. All modifications should be done to local copies (under version control) that are then installed with make/install or similar solutions. This way of working avoids all sorts of problems, like messed up permission and ownership, stale auxiliary files (such as the undo files), and overwritten changes (when someone else edits the same file as you at the same time). That said, I think persistent undo is more or less useless and, well, just a big pile of potential problems. Persistent undo is in the version control system, not in the editor. -- 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 : Update on Vim 7.3 status
That said, I think persistent undo is more or less useless and, well, just a big pile of potential problems. Persistent undo is in the version control system, not in the editor. I agree with that. This would probably be best left to versionning systems. Shouldn't Vim be used for purely text editing tasks only? -- 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 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: Update on Vim 7.3 status
Michael Wookey wrote: On 25 May 2010 06:06, Bram Moolenaar b...@moolenaar.net wrote: As you may have noticed, I have added the persistent undo patch yesterday. There is a minor typo in the doc for 'persistent-undo'. Patch attached. Thanks! -- Bare feet magnetize sharp metal objects so they point upward from the floor -- especially in the dark. /// 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: undo file location was: Re: Update on Vim 7.3 status
On Tuesday 25 May 2010 13:11:34 Milan Vancura wrote: When editing a file over a network or a removable media (USB stick) it's very easy to misplace the undo file. Also, when a file is edited by several people, or the same person with different login names or from different systems, the undo file would go in the wrong place. Also problems with renaming a directory, moving a directory tree, backups, etc. I see many problems with this solution: more people than one can edit the same file. So they should share the undo file?! Yes. Not sharing undo file makes it useless. m. -- 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 7.2.427
On Fri, May 14, 2010 at 11:53 AM, Bram Moolenaar b...@moolenaar.net wrote: Patch 7.2.427 Problem: The swapfile is created using the destination of a symlink, but recovery doesn't follow symlinks. Solution: When recovering, resolve symlinks. (James Vega) Files: src/memline.c After this patch, “vim -r” (no arguments) crashes. Attached patch fixes it. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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 swapcrash.diff Description: Binary data
Re: Update on Vim 7.3 status
Nikolai Weibull wrote: That said, I think persistent undo is more or less useless and, well, just a big pile of potential problems. Persistent undo is in the version control system, not in the editor. I think this is a bit harsh. Not every file is in version control. And even if you do use a version control system, persistent undo allows you to undo with a smaller granularity than simply reverting revisions in version control system. Users of Vim find different features more or less useful. I don't use all features. Does anybody use all Vim features? :-) I don't use the GUI or tabs for example. But I can see that other people find them useful and I would not call them useless. Maybe persistent undo is not for everybody, but I'm confident it will be useful to many, including myself. Cheers -- 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: Update on Vim 7.3 status
2010/5/25 Dominique Pellé dominique.pe...@gmail.com: Nikolai Weibull wrote: That said, I think persistent undo is more or less useless and, well, just a big pile of potential problems. Persistent undo is in the version control system, not in the editor. I think this is a bit harsh. And I think persistent undo is a lot problematic and only a bit useful. Not every file is in version control. And that’s the problem. And even if you do use a version control system, persistent undo allows you to undo with a smaller granularity than simply reverting revisions in version control system. One user added a FileWritePost autocmd to commit changed files to Git whenever he saved. Not that I’d recommend that, but that’s a solution. Users of Vim find different features more or less useful. And persistent undo is on par with window tabs in terms of usefulness, just above floating point numbers. -- 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 7.2.427
On 25-May-2010 James Vega james...@jamessan.com wrote: On Fri, May 14, 2010 at 11:53 AM, Bram Moolenaar b...@moolenaar.net wrote: Patch 7.2.427 Problem: The swapfile is created using the destination of a symlink, but recovery doesn't follow symlinks. Solution: When recovering, resolve symlinks. (James Vega) Files: src/memline.c After this patch, “vim -r” (no arguments) crashes. Attached patch fixes it. The attached patch seems to fix the problem. -- 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 diff --git a/src/memline.c b/src/memline.c index 74f94ed..9f6f637 100644 --- a/src/memline.c +++ b/src/memline.c @@ -1404,13 +1404,14 @@ recover_names(fname, list, nr) int i; char_u *dirp; char_u *dir_name; -char_u *fname_res = *fname; +char_u *fname_res = fname ? *fname + : NULL; #ifdef HAVE_READLINK char_u fname_buf[MAXPATHL]; /* Expand symlink in the file name, because the swap file is created with * the actual file instead of with the symlink. */ -if (resolve_symlink(*fname, fname_buf) == OK) +if (fname resolve_symlink(*fname, fname_buf) == OK) fname_res = fname_buf; #endif
inoremap esc bug?
inoremap esc bug? http://vim.wikia.com/wiki/Avoid_the_escape_key I tried the Improving the Esc key on that page. inoremap Esc Esc`^ In Mac terminal and Linux urxvt it has side effects for the arrow keys. The arrow keys up, down, right, left produce A, B, C, D respectively. Hmmm, vim keycodes found using ^V: up ^[OA down ^[OB right ^[OC left ^[OD Since ^[ is the same as esc Is the ^[ doing esc`^ as though it were typed? It seems up arrow is now doing: ^[ Exit insert mode `^ To position where the cursor was the last time when Insert mode was stopped O Begin a new line above the cursor and insert text A Type the letter A Is this a bug? Seems inoremap is not working here. -- 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: Update on Vim 7.3 status
Hi Nikolai! On Di, 25 Mai 2010, Nikolai Weibull wrote: 2010/5/25 Dominique Pellé dominique.pe...@gmail.com: Nikolai Weibull wrote: That said, I think persistent undo is more or less useless and, well, just a big pile of potential problems. Persistent undo is in the version control system, not in the editor. I think this is a bit harsh. And I think persistent undo is a lot problematic and only a bit useful. And now what? You can always disable it at compile time. Not every file is in version control. And that’s the problem. You don't always have a VCS System available. Sometimes there are constraints that prevent you from using an VCS System only for yourself. And you can't always change that. And even if you do use a version control system, persistent undo allows you to undo with a smaller granularity than simply reverting revisions in version control system. One user added a FileWritePost autocmd to commit changed files to Git whenever he saved. Not that I’d recommend that, but that’s a solution. chrisbra t41:~/vim [1008]% git zsh: command not found: git zsh: exit 127 git Users of Vim find different features more or less useful. And persistent undo is on par with window tabs in terms of usefulness, just above floating point numbers. As I said, nobody forces you to use vim 7.3. You can always disable it at compile time. Or even use vim7. regards, Christian -- 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: Update on Vim 7.3 status
On Tue, May 25, 2010 at 19:42, Christian Brabandt cbli...@256bit.org wrote: On Di, 25 Mai 2010, Nikolai Weibull wrote: 2010/5/25 Dominique Pellé dominique.pe...@gmail.com: Nikolai Weibull wrote: That said, I think persistent undo is more or less useless and, well, just a big pile of potential problems. Persistent undo is in the version control system, not in the editor. I think this is a bit harsh. And I think persistent undo is a lot problematic and only a bit useful. And now what? What? As I said, nobody forces you to use vim 7.3. And no one forced you to defend this feature. Why does everyone have to come in and say basically the same thing in response to my opinion? It’s not like I’m suggesting that it be removed. I’m just stating the claim that what you really want is real version control, not a half-assed form of it. -- 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
C-N , C-P causes crash
Hi, When I try to complete using C-N or C-P in insert mode, I routinely get a crash. I just download the latest svn svn co https://vim.svn.sourceforge.net/svnroot/vim/vim7 I have the following in my _vimrc: set complete+=s*.py set complete-=k complete+=k Below is the error listing: Unhandled exception at 0x00547c75 in gvim.exe: 0xC005: Access violation reading location 0x0286c000. First-chance exception at 0x00547c75 in gvim.exe: 0xC005: Access violation reading location 0x0286c004. Unhandled exception at 0x00547c75 in gvim.exe: 0xC005: Access violation reading location 0x0286c004. First-chance exception at 0x00547e25 in gvim.exe: 0xC005: Access violation reading location 0x0286c000. Unhandled exception at 0x00547e25 in gvim.exe: 0xC005: Access violation reading location 0x0286c000. First-chance exception at 0x00547e37 in gvim.exe: 0xC005: Access violation writing location 0x0286c000. Unhandled exception at 0x00547e37 in gvim.exe: 0xC005: Access violation writing location 0x0286c000. First-chance exception at 0x00547e37 in gvim.exe: 0xC005: Access violation writing location 0x0286c000. The thread 'Win32 Thread' (0x1054) has exited with code 0 (0x0). Unhandled exception at 0x00547e37 in gvim.exe: 0xC005: Access violation writing location 0x0286c000. and here is the call stack from VisualStudio 2008: gvim.exe!ins_compl_add_infercase(unsigned char * str=0x0283a8d3, int len=1, int icase=1, unsigned char * fname=0x0285c118, int dir=1, int flags=0) Line 2280 + 0x18 bytes C gvim.exe!ins_compl_files(int count=40, unsigned char * * files=0x0285c1d0, int thesaurus=1, int flags=1, regmatch_T * regmatch=0x0012f740, unsigned char * buf=0x0283a898, int * dir=0x0012f730) Line 3062 + 0x29 bytes C gvim.exe!ins_compl_dictionaries(unsigned char * dict_start=0x0222d1fa, unsigned char * pat=0x028403e0, int flags=1, int thesaurus=1) Line 2964 + 0x21 bytes C gvim.exe!ins_compl_get_exp(pos_T * ini=0x007d6c0c) Line 4042 + 0xd2 bytes C gvim.exe!ins_compl_next(int allow_get_expansion=1, int count=1, int insert_match=1) Line 4439 + 0xa bytes C gvim.exe!ins_complete(int c=14) Line 5072 + 0x21 bytes C gvim.exe!edit(int cmdchar=105, int startln=0, long count=1) Line 1348 + 0x9 bytes C gvim.exe!invoke_edit(cmdarg_S * cap=0x0012fb80, int repl=0, int cmd=105, int startln=0) Line 8911 + 0x14 bytes C gvim.exe!nv_edit(cmdarg_S * cap=0x0012fb80) Line 8884 + 0x14 bytes C gvim.exe!normal_cmd(oparg_S * oap=0x0012fc1c, int toplevel=1) Line 1188 + 0x12 bytes C gvim.exe!main_loop(int cmdwin=0, int noexmode=0) Line 1211 + 0xb bytes C gvim.exe!VimMain() Line 955 + 0x9 bytesC gvim.exe!WinMain(HINSTANCE__ * hInstance=0x0040, HINSTANCE__ * hPrevInst=0x, char * lpszCmdLine=0x00222466, int nCmdShow=10) Line 125 + 0xe bytes C gvim.exe!__tmainCRTStartup() Line 263 + 0x2c bytes C gvim.exe!WinMainCRTStartup() Line 182 C any help appreciated. Thanks! -- 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: Update on Vim 7.3 status
On Tue, 25 May 2010, Nikolai Weibull wrote: And no one forced you to defend this feature. True, nobody is forcing anybody to defend the feature, but what do you expect to happen when you complain about it? Why does everyone have to come in and say basically the same thing in response to my opinion? Why do you have to state, and re-state your opinion in the first place? It’s not like I’m suggesting that it be removed. Again I have to ask: Then why did you complain at all? To me it seems like you're implying that since it can't be perfect--by YOUR definition of perfection, for YOUR use cases--that it shouldn't be there at all. I’m just stating the claim that what you really want is real version control, not a half-assed form of it. I am looking forward to the persistent undo feature, and no, real version control is _not_ what I want; I have access to various version control systems, and I do use them, but I still want _this_ feature in Vim. Yes, I agree that there will be problems, and that it's yet another feature, and so on. It still has merit, and considering it's #4 on the voting page means that a lot of people think so. (http://www.vim.org/sponsor/vote_results.php) Version control has its place, and this feature has its place. Just because it can't always be shared doesn't make it useless, as you stated in an earlier reply. (Of course, you also said only a bit useful in another reply--which is it?) - Christian -- Christian J. Robinson hept...@gmail.com -- 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) yank and a particular utf-8 character
Hello! Set up a file tmp with a single line: (this line should appear as a -1 with a m exponent; ie. char-0x1D50 -1ᵐ Use the following command: vim -u simple.vimrc tmp and try Yp (yank and put). simple.vimrc: set nocp set enc=utf-8 I see --11ᵐ instead of -1ᵐ -1ᵐ ie. its picking up the -1 but ignoring the m exponent. Regards, Chip Campbell -- 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: Update on Vim 7.3 status
On Tue, May 25, 2010 at 21:04, Christian J. Robinson hept...@gmail.com wrote: On Tue, 25 May 2010, Nikolai Weibull wrote: And no one forced you to defend this feature. True, nobody is forcing anybody to defend the feature, but what do you expect to happen when you complain about it? I figured that “That said, I think persistent undo is more or less useless and, well, just a big pile of potential problems. Persistent undo is in the version control system, not in the editor.” is me stating an opinion about it, not saying “please remove it”. Why does everyone have to come in and say basically the same thing in response to my opinion? Why do you have to state, and re-state your opinion in the first place? I gave what I considered to be the deeper solution to a problem that one user figured that persistent undo would bring and that was to keep edits local. That someone chose to only focus on the fact that I said that I thought persistent undo was a non-solution was where it started. It’s not like I’m suggesting that it be removed. Again I have to ask: Then why did you complain at all? Because I like complaining and because the person that responded to my post was too dismissive. To me it seems like you're implying that since it can't be perfect--by YOUR definition of perfection, for YOUR use cases--that it shouldn't be there at all. Oh, was that what I implied? I didn’t realize. Perhaps I missed reading one of my posts. (See below for a discussion on what I actually wanted to imply.) I’m just stating the claim that what you really want is real version control, not a half-assed form of it. Yes, I agree that there will be problems, and that it's yet another feature, and so on. It still has merit, and considering it's #4 on the voting page means that a lot of people think so. (http://www.vim.org/sponsor/vote_results.php) Which doesn’t necessarily mean that it will be as useful as those people may hope. Version control has its place, and this feature has its place. Just because it can't always be shared doesn't make it useless, as you stated in an earlier reply. (Of course, you also said only a bit useful in another reply--which is it?) Strawman, much? “I think persistent undo is more or less useless” is what I initially wrote, followed by “persistent undo is in the version control system, not in the editor”, which I figured would imply that my point was that persistent undo is the wrong solution to the problem. -- 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] invalid memory access when removing a funcref variable
There is a possibility of Vim crashing when a variable or an option
('omnifunc' or 'completefunc') is unset or has its value modified.
The crash is due to an invalid memory access, which is reported by
Valgrind as follows:
#v+
==19657== Invalid write of size 1
==19657==at 0x8077102: call_func (eval.c:8208)
==19657==by 0x8076BA9: get_func_tv (eval.c:7976)
==19657==by 0x8073188: eval7 (eval.c:5023)
==19657==by 0x8072AA1: eval6 (eval.c:4690)
==19657==by 0x8072697: eval5 (eval.c:4506)
==19657==by 0x8071C41: eval4 (eval.c:4201)
==19657==by 0x8071AAF: eval3 (eval.c:4113)
==19657==by 0x8071951: eval2 (eval.c:4042)
==19657==by 0x80717A2: eval1 (eval.c:3967)
==19657==by 0x8086DD6: ex_echo (eval.c:19459)
==19657==by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
==19657==by 0x809EA29: do_cmdline (ex_docmd.c:1098)
==19657==by 0x809CCD4: do_source (ex_cmds2.c:3204)
==19657==by 0x809C4FF: cmd_source (ex_cmds2.c:2809)
==19657==by 0x809C457: ex_source (ex_cmds2.c:2782)
==19657==by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
==19657==by 0x809EA29: do_cmdline (ex_docmd.c:1098)
==19657==by 0x809E0E3: do_cmdline_cmd (ex_docmd.c:704)
==19657==by 0x80E2572: exe_commands (main.c:2733)
==19657==by 0x80DFF26: main (main.c:888)
==19657== Address 0x4e17343 is 11 bytes inside a block of size 12 free'd
==19657==at 0x4023836: free (vg_replace_malloc.c:325)
==19657==by 0x810E0EC: vim_free (misc2.c:1647)
==19657==by 0x80858FA: clear_tv (eval.c:18562)
==19657==by 0x80862A8: delete_var (eval.c:19029)
==19657==by 0x8070E6A: do_unlet (eval.c:3555)
==19657==by 0x8070CB8: do_unlet_var (eval.c:3499)
==19657==by 0x8070BC3: ex_unletlock (eval.c:3462)
==19657==by 0x8070A22: ex_unlet (eval.c:3400)
==19657==by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
==19657==by 0x809EA29: do_cmdline (ex_docmd.c:1098)
==19657==by 0x808ABDC: call_user_func (eval.c:21332)
==19657==by 0x8076F55: call_func (eval.c:8130)
==19657==by 0x8076BA9: get_func_tv (eval.c:7976)
==19657==by 0x8073188: eval7 (eval.c:5023)
==19657==by 0x8072AA1: eval6 (eval.c:4690)
==19657==by 0x8072697: eval5 (eval.c:4506)
==19657==by 0x8071C41: eval4 (eval.c:4201)
==19657==by 0x8071AAF: eval3 (eval.c:4113)
==19657==by 0x8071951: eval2 (eval.c:4042)
==19657==by 0x80717A2: eval1 (eval.c:3967)
==19657==by 0x8086DD6: ex_echo (eval.c:19459)
==19657==by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
==19657==by 0x809EA29: do_cmdline (ex_docmd.c:1098)
==19657==by 0x809CCD4: do_source (ex_cmds2.c:3204)
==19657==by 0x809C4FF: cmd_source (ex_cmds2.c:2809)
==19657==by 0x809C457: ex_source (ex_cmds2.c:2782)
==19657==by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
==19657==by 0x809EA29: do_cmdline (ex_docmd.c:1098)
==19657==by 0x809E0E3: do_cmdline_cmd (ex_docmd.c:704)
==19657==by 0x80E2572: exe_commands (main.c:2733)
==19657==by 0x80DFF26: main (main.c:888)
#v-
The invalid memory access can be triggered by executing the following
script:
#v+
func FuncWithRef(a)
unlet g:FuncRef
return a:a
endfunc
let g:FuncRef=function(FuncWithRef)
echo g:FuncRef(333)
q
#v-
The attached patch fixes the problem and modifies test 34 to cause the
freed memory.
--
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
diff --git a/src/eval.c b/src/eval.c
index be59f98..caa3224 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -8023,26 +8023,36 @@ call_func(name, len, rettv, argcount, argvars, firstline, lastline,
int i;
int llen;
ufunc_T *fp;
-int cc;
#define FLEN_FIXED 40
char_u fname_buf[FLEN_FIXED + 1];
char_u *fname;
+char_u *name_save;
+
+/* NOTE that if name comes from a funcref variable, while evaluating the
+ * function it is possible that the memory pointed to by name will be
+ * freed as a result of executing e.g.
+ * unlet FuncRefVariable
+ * Let's make a copy of name to be able to modify the string to heart's
+ * content without having to restore it afterwards.
+ */
+name_save = vim_strsave(name);
+if (name_save == NULL)
+ return FAIL;
/*
* In a script change SIDname() and s:name() to K_SNR 123_name().
* Change SNR123_name() to K_SNR 123_name().
* Use fname_buf[] when it fits, otherwise allocate memory (slow).
*/
-cc = name[len];
-name[len] = NUL;
-llen = eval_fname_script(name);
+name_save[len] = NUL;
+llen = eval_fname_script(name_save);
if (llen 0)
{
fname_buf[0] = K_SPECIAL;
fname_buf[1] = KS_EXTRA;
fname_buf[2] = (int)KE_SNR;
i = 3;
- if (eval_fname_sid(name)) /* SID or s: */
+ if (eval_fname_sid(name_save)) /* SID or s: */
{
if (current_SID = 0)
error = ERROR_SCRIPT;
@@ -8052,25 +8062,25 @@ call_func(name, len, rettv, argcount,
Patch 7.2.438
Patch 7.2.438 (after 7.2.427)
Problem:vim -r crashes.
Solution: Don't use NULL pointer argument.
Files: src/memline.c
*** ../vim-7.2.437/src/memline.c2010-05-14 17:52:35.0 +0200
--- src/memline.c 2010-05-25 21:36:01.0 +0200
***
*** 1404,1418
int i;
char_u*dirp;
char_u*dir_name;
! char_u*fname_res = *fname;
#ifdef HAVE_READLINK
char_ufname_buf[MAXPATHL];
/* Expand symlink in the file name, because the swap file is created with
* the actual file instead of with the symlink. */
if (resolve_symlink(*fname, fname_buf) == OK)
fname_res = fname_buf;
#endif
if (list)
{
--- 1404,1425
int i;
char_u*dirp;
char_u*dir_name;
! char_u*fname_res = NULL;
#ifdef HAVE_READLINK
char_ufname_buf[MAXPATHL];
+ #endif
+ if (fname != NULL)
+ {
+ #ifdef HAVE_READLINK
/* Expand symlink in the file name, because the swap file is created with
* the actual file instead of with the symlink. */
if (resolve_symlink(*fname, fname_buf) == OK)
fname_res = fname_buf;
+ else
#endif
+ fname_res = *fname;
+ }
if (list)
{
*** ../vim-7.2.437/src/version.c2010-05-21 13:08:51.0 +0200
--- src/version.c 2010-05-25 21:30:12.0 +0200
***
*** 683,684
--- 683,686
{ /* Add new patch number below this line */
+ /**/
+ 438,
/**/
--
A fool learns from his mistakes, a wise man from someone else's.
/// 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
netbeans patches on vim73
I have tested successfully the following two netbeans vim73 patches
with pyclewn and by running the pyclewn test suite:
o changeset: 2200:8c6a66e2b3cc
| branch: vim73
| user:Bram Moolenaar b...@vim.org
| date:Sat May 22 21:34:09 2010 +0200
| summary: Add :nbstart and :nbclose.
|
o changeset: 2199:d0ddf7ba1630
| branch: vim73
| user:Bram Moolenaar b...@vim.org
| date:Sat May 22 18:28:27 2010 +0200
| summary: Included the patch to support netbeans in a terminal.
About the following comment in netbeans.c:
/* TODO: when should this not be defined? */
#define INET_SOCKETS
When INET_SOCKETS is not defined in netbeans.c:
* netbeans.c does not compile (on linux) if sys/un.h is not
included (this was the case up to the 'nbstart' patch)
* netbeans uses a unix socket instead of an internet socket and
the {addr} field in the '-nb' command line parameter (which is
the port number, when using an inet socket) is the socket unix
file name
* this feature is not documented (tested ?)
If we remove the code that implements netbeans over unix sockets, we
don't need to define INET_SOCKETS any more, since all the code would
then be inet socket only. I can send a patch if needed.
Xavier
--
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: C-N , C-P causes crash
On 25-May-2010 reckoner recko...@gmail.com wrote: Hi, When I try to complete using C-N or C-P in insert mode, I routinely get a crash. I just download the latest svn svn co https://vim.svn.sourceforge.net/svnroot/vim/vim7 I have the following in my _vimrc: set complete+=s*.py set complete-=k complete+=k Below is the error listing: Unhandled exception at 0x00547c75 in gvim.exe: 0xC005: Access violation reading location 0x0286c000. First-chance exception at 0x00547c75 in gvim.exe: 0xC005: Access violation reading location 0x0286c004. Unhandled exception at 0x00547c75 in gvim.exe: 0xC005: Access violation reading location 0x0286c004. First-chance exception at 0x00547e25 in gvim.exe: 0xC005: Access violation reading location 0x0286c000. Unhandled exception at 0x00547e25 in gvim.exe: 0xC005: Access violation reading location 0x0286c000. First-chance exception at 0x00547e37 in gvim.exe: 0xC005: Access violation writing location 0x0286c000. Unhandled exception at 0x00547e37 in gvim.exe: 0xC005: Access violation writing location 0x0286c000. First-chance exception at 0x00547e37 in gvim.exe: 0xC005: Access violation writing location 0x0286c000. The thread 'Win32 Thread' (0x1054) has exited with code 0 (0x0). Unhandled exception at 0x00547e37 in gvim.exe: 0xC005: Access violation writing location 0x0286c000. and here is the call stack from VisualStudio 2008: gvim.exe!ins_compl_add_infercase(unsigned char * str=0x0283a8d3, int len=1, int icase=1, unsigned char * fname=0x0285c118, int dir=1, int flags=0) Line 2280 + 0x18 bytes C gvim.exe!ins_compl_files(int count=40, unsigned char * * files=0x0285c1d0, int thesaurus=1, int flags=1, regmatch_T * regmatch=0x0012f740, unsigned char * buf=0x0283a898, int * dir=0x0012f730) Line 3062 + 0x29 bytes C gvim.exe!ins_compl_dictionaries(unsigned char * dict_start=0x0222d1fa, unsigned char * pat=0x028403e0, int flags=1, int thesaurus=1) Line 2964 + 0x21 bytes C gvim.exe!ins_compl_get_exp(pos_T * ini=0x007d6c0c) Line 4042 + 0xd2 bytesC gvim.exe!ins_compl_next(int allow_get_expansion=1, int count=1, int insert_match=1) Line 4439 + 0xa bytesC gvim.exe!ins_complete(int c=14) Line 5072 + 0x21 bytes C gvim.exe!edit(int cmdchar=105, int startln=0, long count=1) Line 1348 + 0x9 bytes C gvim.exe!invoke_edit(cmdarg_S * cap=0x0012fb80, int repl=0, int cmd=105, int startln=0) Line 8911 + 0x14 bytes C gvim.exe!nv_edit(cmdarg_S * cap=0x0012fb80) Line 8884 + 0x14 bytes C gvim.exe!normal_cmd(oparg_S * oap=0x0012fc1c, int toplevel=1) Line 1188 + 0x12 bytes C gvim.exe!main_loop(int cmdwin=0, int noexmode=0) Line 1211 + 0xb bytes C gvim.exe!VimMain() Line 955 + 0x9 bytesC gvim.exe!WinMain(HINSTANCE__ * hInstance=0x0040, HINSTANCE__ * hPrevInst=0x, char * lpszCmdLine=0x00222466, int nCmdShow=10) Line 125 + 0xe bytes C gvim.exe!__tmainCRTStartup() Line 263 + 0x2c bytes C gvim.exe!WinMainCRTStartup() Line 182 C any help appreciated. I'll be happy to help but I can't reproduce the problem. Would it be possible for you to share your _vimrc, the file you edit while getting the crash and the *.py files you use as your thesaurus files? If not, can you simplify the procedure for getting the crash in such a way that you can share the details? Thanks! -- 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: Update on Vim 7.3 status
2010/5/25 Dominique Pellé dominique.pe...@gmail.com: Does anybody use all Vim features? :-) Does anybody actually know all Vim features? :-) Sometimes I accidentally quit Vim while editing a file (hitting w and q at the same time when saving for instance), losing the undo history at the same time. I can certainly see a utility to persistent undo for such cases. Even if this feature will not be the most useful to me, I'm glad to see new features added to Vim that make it even better. -- 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: inoremap esc bug?
On 25/05/10 18:03, Bee wrote:
inoremapesc bug?
http://vim.wikia.com/wiki/Avoid_the_escape_key
I tried the Improving the Esc key on that page.
inoremapEsc Esc`^
In Mac terminal and Linux urxvt it has side effects for the arrow
keys. The arrow keys up, down, right, left produce A, B, C, D
respectively.
Hmmm, vim keycodes found using ^V:
up ^[OA
down ^[OB
right ^[OC
left ^[OD
Since ^[ is the same asesc
Is the ^[ doingesc`^ as though it were typed?
It seems up arrow is now doing:
^[ Exit insert mode
`^ To position where the cursor was the last time when Insert mode
was stopped
O Begin a new line above the cursor and insert text
A Type the letter A
Is this a bug? Seems inoremap is not working here.
I recommend
:set timeout timeoutlen=5000 ttimeoutlen=100
(or similar), where
- both times are in milliseconds
- 'timeoutlen' should be longer than the longest time between keystrokes
when you're hesitating about which key to type next in a multikey {lhs}
for a mapping
- 'ttimeoutlen' should be shorter than the shortest time between
keystrokes at your fastest typing speed but longer than the (longest)
time between successive bytes sent to you by the keyboard for a single key.
When bytes arrive with a shorter interval between them than
'ttimeoutlen' milliseconds, Vim will then accept them as a multibyte
keycode (if found in the current termcap) in preference to a mapping.
See the corresponding help topics for details.
Best regards,
Tony.
--
Real World, The n.:
1. In programming, those institutions at which programming may
be used in the same sentence as FORTRAN, COBOL, RPG, IBM, etc. 2. To
programmers, the location of non-programmers and activities not related
to programming. 3. A universe in which the standard dress is shirt and
tie and in which a person's working hours are defined as 9 to 5. 4.
The location of the status quo. 5. Anywhere outside a university.
Poor fellow, he's left MIT and gone into the real world. Used
pejoratively by those not in residence there. In conversation, talking
of someone who has entered the real world is not unlike talking about a
deceased person.
--
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 7.2.427
James Vega wrote: On Fri, May 14, 2010 at 11:53 AM, Bram Moolenaar b...@moolenaar.net wrote: Patch 7.2.427 Problem:   The swapfile is created using the destination of a symlink, but       recovery doesn't follow symlinks. Solution:  When recovering, resolve symlinks. (James Vega) Files:    src/memline.c After this patch, “vim -r†(no arguments) crashes. Attached patch fixes it. Thanks. I just sent out a very similar patch. -- From know your smileys: :-EHas major dental problems /// 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: (bug) yank and a particular utf-8 character
Charles Campbell wrote: Set up a file tmp with a single line: (this line should appear as a -1 with a m exponent; ie. char-0x1D50 -1áµ Use the following command: vim -u simple.vimrc tmp and try Yp (yank and put). simple.vimrc: set nocp set enc=utf-8 I see --11áµ instead of -1áµ -1áµ ie. its picking up the -1 but ignoring the m exponent. I can't reproduce it... -- I AM THANKFUL... ...for the piles of laundry and ironing because it means I have plenty of clothes to wear. /// 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 mem access with :wundo foo when foo exists its size is 0
Dominique Pelle wrote:
I see the following error with Valgrind in Vim-7.3a BETA (c81f0a037059)
when doing :wundo foo and when file foo already exists and has size 0:
==4957== Conditional jump or move depends on uninitialised value(s)
==4957==at 0x81BCB49: u_write_undo (undo.c:1293)
==4957==by 0x80AFBE6: ex_wundo (ex_docmd.c:8471)
==4957==by 0x80A70DC: do_one_cmd (ex_docmd.c:2639)
==4957==by 0x80A49B5: do_cmdline (ex_docmd.c:1108)
==4957==by 0x812A219: nv_colon (normal.c:5226)
==4957==by 0x8123AA3: normal_cmd (normal.c:1188)
==4957==by 0x80E71DC: main_loop (main.c:1216)
==4957==by 0x80E6CD3: main (main.c:960)
==4957== Uninitialised value was created by a stack allocation
==4957==at 0x81BC9F2: u_write_undo (undo.c:1226)
undo.c:
1289 char_u buf[2];
1290
1291 vim_read(fd, buf, 2);
1292 close(fd);
1293 if ((buf[0] 8) + buf[1] != UF_START_MAGIC)
1294 {
1295 if (name != NULL || p_verbose 0)
1296 smsg((char_u *)_(Will not overwrite,
this is not an undo file: %s),
1297
file_name);
1298 goto theend;
1299 }
Code did not check whether vim_read() succeeds at line undo.c:1291.
Attached patch fixes it.
Thanks, I'll include it.
--
From know your smileys:
:-| :-| Deja' vu!
/// 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
undo file location was: Re: Update on Vim 7.3 status
Milan Vancura wrote:
When editing a file over a network or a removable media (USB stick) it's
very easy to misplace the undo file. Also, when a file is edited by
several people, or the same person with different login names or from
different systems, the undo file would go in the wrong place. Also
problems with renaming a directory, moving a directory tree, backups,
etc.
I see many problems with this solution: more people than one can edit
the same file. So they should share the undo file?! Or there will be
one undo file for each user?
There needs to be one undo file, otherwise it would not work. If user A
edits a file and saves the undo file, then user B makes a change to the
file, the undo file of user A is no longer valid and will not work.
Only when the undo file is shared it would actually be possible to undo
with multiple users.
This is moot though, a file edited by several people is very unusual,
and if it does happen an undo file won't be very useful. Better not
enable the undofile option for this kind of file.
And what if the user is unknown, for example on network-attached disks
where the original user (from the far computer) even does not exist on
the local one?
Normally such a user cannot save a file, as permissions cannot be
checked.
And what about directories where it is not a good idea to create
files without a very good reason like directories exported via http,
directories under version control etc. etc. Imagine usual user of
mercurial or Novell BuildService: they use the command addremove
quite often. And if there was a file created automatically on the
background they add it to the repository accidentally. This is not a
good idea, is it?
On published directories you already have to take care not to store
backup files. Undo files are similar to that.
The undo files are hidden, all version control systems I know will
ignore them. E.g. swap files are normally not a problem.
And there are many other examples. Status files of the editor should
be in the storage area reserved for such editor. In this case it is
~/.vim (on UN*X) This is the (unspoken?) rule valid for decades on
UN*X systems.
The undo files are not status files, they contain the text of the edited
file. I don't know of the rule you mention, do you have a reference?
Yes, it means that we loose some automatic features you probably meant
like a persistent undo working over file transfer on USB key from
comp1 to comp2. But this is not what should be done by editor, at
least not by default. The list of complications is much longer and
more serious than such advantage.
I don't agree. Renaming a directory is very common, and would cause all
undo information stored below it to be lost. Loss of data is much more
serious than all the things you mention.
I vote for following standards in this case.
What standards are you referring to? Without a reference it is no more
than your personal preference.
--
From know your smileys:
C=};*{)) Drunk, devilish chef with a toupee in an updraft,
a mustache, and a double chin
/// 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] invalid memory access when removing a funcref variable
Lech Lorens wrote:
There is a possibility of Vim crashing when a variable or an option
('omnifunc' or 'completefunc') is unset or has its value modified.
The crash is due to an invalid memory access, which is reported by
Valgrind as follows:
#v+
==19657== Invalid write of size 1
==19657==at 0x8077102: call_func (eval.c:8208)
==19657==by 0x8076BA9: get_func_tv (eval.c:7976)
==19657==by 0x8073188: eval7 (eval.c:5023)
==19657==by 0x8072AA1: eval6 (eval.c:4690)
==19657==by 0x8072697: eval5 (eval.c:4506)
==19657==by 0x8071C41: eval4 (eval.c:4201)
==19657==by 0x8071AAF: eval3 (eval.c:4113)
==19657==by 0x8071951: eval2 (eval.c:4042)
==19657==by 0x80717A2: eval1 (eval.c:3967)
==19657==by 0x8086DD6: ex_echo (eval.c:19459)
==19657==by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
==19657==by 0x809EA29: do_cmdline (ex_docmd.c:1098)
==19657==by 0x809CCD4: do_source (ex_cmds2.c:3204)
==19657==by 0x809C4FF: cmd_source (ex_cmds2.c:2809)
==19657==by 0x809C457: ex_source (ex_cmds2.c:2782)
==19657==by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
==19657==by 0x809EA29: do_cmdline (ex_docmd.c:1098)
==19657==by 0x809E0E3: do_cmdline_cmd (ex_docmd.c:704)
==19657==by 0x80E2572: exe_commands (main.c:2733)
==19657==by 0x80DFF26: main (main.c:888)
==19657== Address 0x4e17343 is 11 bytes inside a block of size 12 free'd
==19657==at 0x4023836: free (vg_replace_malloc.c:325)
==19657==by 0x810E0EC: vim_free (misc2.c:1647)
==19657==by 0x80858FA: clear_tv (eval.c:18562)
==19657==by 0x80862A8: delete_var (eval.c:19029)
==19657==by 0x8070E6A: do_unlet (eval.c:3555)
==19657==by 0x8070CB8: do_unlet_var (eval.c:3499)
==19657==by 0x8070BC3: ex_unletlock (eval.c:3462)
==19657==by 0x8070A22: ex_unlet (eval.c:3400)
==19657==by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
==19657==by 0x809EA29: do_cmdline (ex_docmd.c:1098)
==19657==by 0x808ABDC: call_user_func (eval.c:21332)
==19657==by 0x8076F55: call_func (eval.c:8130)
==19657==by 0x8076BA9: get_func_tv (eval.c:7976)
==19657==by 0x8073188: eval7 (eval.c:5023)
==19657==by 0x8072AA1: eval6 (eval.c:4690)
==19657==by 0x8072697: eval5 (eval.c:4506)
==19657==by 0x8071C41: eval4 (eval.c:4201)
==19657==by 0x8071AAF: eval3 (eval.c:4113)
==19657==by 0x8071951: eval2 (eval.c:4042)
==19657==by 0x80717A2: eval1 (eval.c:3967)
==19657==by 0x8086DD6: ex_echo (eval.c:19459)
==19657==by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
==19657==by 0x809EA29: do_cmdline (ex_docmd.c:1098)
==19657==by 0x809CCD4: do_source (ex_cmds2.c:3204)
==19657==by 0x809C4FF: cmd_source (ex_cmds2.c:2809)
==19657==by 0x809C457: ex_source (ex_cmds2.c:2782)
==19657==by 0x80A1150: do_one_cmd (ex_docmd.c:2629)
==19657==by 0x809EA29: do_cmdline (ex_docmd.c:1098)
==19657==by 0x809E0E3: do_cmdline_cmd (ex_docmd.c:704)
==19657==by 0x80E2572: exe_commands (main.c:2733)
==19657==by 0x80DFF26: main (main.c:888)
#v-
The invalid memory access can be triggered by executing the following
script:
#v+
func FuncWithRef(a)
unlet g:FuncRef
return a:a
endfunc
let g:FuncRef=function(FuncWithRef)
echo g:FuncRef(333)
q
#v-
The attached patch fixes the problem and modifies test 34 to cause the
freed memory.
Good catch. I'll add it to the todo list.
--
From know your smileys:
:-| :-| Deja' vu!
/// 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: Update on Vim 7.3 status
On Tue, May 25, 2010 at 2:27 PM, Nikolai Weibull n...@bitwi.se wrote: I figured that “That said, I think persistent undo is more or less useless and, well, just a big pile of potential problems. Persistent undo is in the version control system, not in the editor.” is me stating an opinion about it, not saying “please remove it”. [...] I gave what I considered to be the deeper solution to a problem that one user figured that persistent undo would bring and that was to keep edits local. That someone chose to only focus on the fact that I said that I thought persistent undo was a non-solution was where it started. [...] Strawman, much? “I think persistent undo is more or less useless” is what I initially wrote, followed by “persistent undo is in the version control system, not in the editor”, which I figured would imply that my point was that persistent undo is the wrong solution to the problem. Responding to give another perspective on where persistent undo might fit relative to all of the ways we have to keep track of the history of things. I think that persistent undo is an excellent *complement* to version control. It is not a replacement. I use git to manage revisions and history of every project I work on these days, yet persistent undo is still a great boon to my productivity. For example, pretend you're developing the ultimate novel Vim feature, but you've caused a bug, and want to trace it in gdb. You edit Vim's makefile to enable -g in CFLAGS, recompile, track down the bug, and want to compile a release version. I wouldn't have committed enabling -g in git, as it's a transient change that I don't want to make permanent. So I edit again and undo the change. As another example, pretend you're editing your Apache config in an attempt to get a new module working on your web page. The workflow here is a tight loop - edit, reload apache, test, repeat. If it's too much overhead in this tight loop to continue committing small changes to git, then it's no problem to undo the failed couple lines of new configuration and try again. Persistent undo is a good complement to revision control because it fills in a lower 'tier' of persistence, between session-limited undos and revision control. I think of this space as the realm of small, experimental changes, but of course that is open to the interpretation that works best with the user's workflow. And of course, as others have mentioned, it is an optional feature, so the user may choose to ignore it as she wishes. - Jordan -- 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: C-N , C-P causes crash
Lech: Thanks for your reply. I'm attaching the _vimrc (sorry it's kind of messy). The tricky part is that I can't reliably reproduce the error, even though it happens consistently. In other words, I can't exactly articulate a finite series of steps that lead to the crash other than I keep doing C-N and C-P until it does happen. It seems like it depends on the accumulation of a number of previous events before it finally happens. Also, it doesn't seem to matter which python files are being used. I have run into this problem before while editing many different python files. The only thing is that I recompiled the gvim binary using a new python installation (Python version 2.6) using the PYTHON and PYTHON_VER flags with DYNAMIC_PYTHON=no and using Visual Studio 2008. I then took the existing vim installation (which is vim 7.2 from the installer) and then simply replaced the gvim binary with the one I personally compiled for Python version 2.6. Thanks again. Any help appreciated. On 5/25/2010 1:06 PM, Lech Lorens wrote: On 25-May-2010 reckonerrecko...@gmail.com wrote: Hi, When I try to complete using C-N or C-P in insert mode, I routinely get a crash. I just download the latest svn svn co https://vim.svn.sourceforge.net/svnroot/vim/vim7 I have the following in my _vimrc: set complete+=s*.py set complete-=k complete+=k Below is the error listing: Unhandled exception at 0x00547c75 in gvim.exe: 0xC005: Access violation reading location 0x0286c000. First-chance exception at 0x00547c75 in gvim.exe: 0xC005: Access violation reading location 0x0286c004. Unhandled exception at 0x00547c75 in gvim.exe: 0xC005: Access violation reading location 0x0286c004. First-chance exception at 0x00547e25 in gvim.exe: 0xC005: Access violation reading location 0x0286c000. Unhandled exception at 0x00547e25 in gvim.exe: 0xC005: Access violation reading location 0x0286c000. First-chance exception at 0x00547e37 in gvim.exe: 0xC005: Access violation writing location 0x0286c000. Unhandled exception at 0x00547e37 in gvim.exe: 0xC005: Access violation writing location 0x0286c000. First-chance exception at 0x00547e37 in gvim.exe: 0xC005: Access violation writing location 0x0286c000. The thread 'Win32 Thread' (0x1054) has exited with code 0 (0x0). Unhandled exception at 0x00547e37 in gvim.exe: 0xC005: Access violation writing location 0x0286c000. and here is the call stack from VisualStudio 2008: gvim.exe!ins_compl_add_infercase(unsigned char * str=0x0283a8d3, int len=1, int icase=1, unsigned char * fname=0x0285c118, int dir=1, int flags=0) Line 2280 + 0x18 bytesC gvim.exe!ins_compl_files(int count=40, unsigned char * * files=0x0285c1d0, int thesaurus=1, int flags=1, regmatch_T * regmatch=0x0012f740, unsigned char * buf=0x0283a898, int * dir=0x0012f730) Line 3062 + 0x29 bytes C gvim.exe!ins_compl_dictionaries(unsigned char * dict_start=0x0222d1fa, unsigned char * pat=0x028403e0, int flags=1, int thesaurus=1) Line 2964 + 0x21 bytesC gvim.exe!ins_compl_get_exp(pos_T * ini=0x007d6c0c) Line 4042 + 0xd2 bytes C gvim.exe!ins_compl_next(int allow_get_expansion=1, int count=1, int insert_match=1) Line 4439 + 0xa bytes C gvim.exe!ins_complete(int c=14) Line 5072 + 0x21 bytes C gvim.exe!edit(int cmdchar=105, int startln=0, long count=1) Line 1348 + 0x9 bytesC gvim.exe!invoke_edit(cmdarg_S * cap=0x0012fb80, int repl=0, int cmd=105, int startln=0) Line 8911 + 0x14 bytes C gvim.exe!nv_edit(cmdarg_S * cap=0x0012fb80) Line 8884 + 0x14 bytes C gvim.exe!normal_cmd(oparg_S * oap=0x0012fc1c, int toplevel=1) Line 1188 + 0x12 bytes C gvim.exe!main_loop(int cmdwin=0, int noexmode=0) Line 1211 + 0xb bytes C gvim.exe!VimMain() Line 955 + 0x9 bytesC gvim.exe!WinMain(HINSTANCE__ * hInstance=0x0040, HINSTANCE__ * hPrevInst=0x, char * lpszCmdLine=0x00222466, int nCmdShow=10) Line 125 + 0xe bytesC gvim.exe!__tmainCRTStartup() Line 263 + 0x2c bytes C gvim.exe!WinMainCRTStartup() Line 182 C any help appreciated. I'll be happy to help but I can't reproduce the problem. Would it be possible for you to share your _vimrc, the file you edit while getting the crash and the *.py files you use as your thesaurus files? If not, can you simplify the procedure for getting the crash in such a way that you can share the details? Thanks! -- 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 _vimrc Description: Binary data
Re: Patch 7.2.427
On 25-May-2010 Lech Lorens lech.lor...@gmail.com wrote: On 25-May-2010 James Vega james...@jamessan.com wrote: On Fri, May 14, 2010 at 11:53 AM, Bram Moolenaar b...@moolenaar.net wrote: Patch 7.2.427 Problem: The swapfile is created using the destination of a symlink, but recovery doesn't follow symlinks. Solution: When recovering, resolve symlinks. (James Vega) Files: src/memline.c After this patch, “vim -r” (no arguments) crashes. Attached patch fixes it. The attached patch seems to fix the problem. Duh, what made me stop reading after the first dot? ... -- 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: inoremap esc bug?
On May 25, 1:19 pm, Tony Mechelynck antoine.mechely...@gmail.com
wrote:
On 25/05/10 18:03, Bee wrote:
inoremapesc bug?
http://vim.wikia.com/wiki/Avoid_the_escape_key
I tried the Improving the Esc key on that page.
inoremapEsc Esc`^
In Mac terminal and Linux urxvt it has side effects for the arrow
keys. The arrow keys up, down, right, left produce A, B, C, D
respectively.
Hmmm, vim keycodes found using ^V:
up ^[OA
down ^[OB
right ^[OC
left ^[OD
Since ^[ is the same asesc
Is the ^[ doingesc`^ as though it were typed?
It seems up arrow is now doing:
^[ Exit insert mode
`^ To position where the cursor was the last time when Insert mode
was stopped
O Begin a new line above the cursor and insert text
A Type the letter A
Is this a bug? Seems inoremap is not working here.
I recommend
:set timeout timeoutlen=5000 ttimeoutlen=100
(or similar), where
- both times are in milliseconds
- 'timeoutlen' should be longer than the longest time between keystrokes
when you're hesitating about which key to type next in a multikey {lhs}
for a mapping
- 'ttimeoutlen' should be shorter than the shortest time between
keystrokes at your fastest typing speed but longer than the (longest)
time between successive bytes sent to you by the keyboard for a single key.
When bytes arrive with a shorter interval between them than
'ttimeoutlen' milliseconds, Vim will then accept them as a multibyte
keycode (if found in the current termcap) in preference to a mapping.
See the corresponding help topics for details.
Hi Tony
I tried what you suggested and it had no effect, tried other values,
still get the A, B, C, D.
Also tried with:
vim -N -i NONE -u NONE
Still getting:
The arrow keys up, down, right, left produce A, B, C, D respectively.
--
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: Update on Vim 7.3 status
On Tue, May 25, 2010 at 22:38, Jordan Lewis jordanthele...@gmail.com wrote: For example, pretend you're developing the ultimate novel Vim feature, but you've caused a bug, and want to trace it in gdb. You edit Vim's makefile to enable -g in CFLAGS, recompile, track down the bug, and want to compile a release version. I wouldn't have committed enabling -g in git, as it's a transient change that I don't want to make permanent. So I edit again and undo the change. % git checkout -- Makefile As another example, pretend you're editing your Apache config in an attempt to get a new module working on your web page. The workflow here is a tight loop - edit, reload apache, test, repeat. % EOF Makefile install_and_reload: install httpd.conf /etc/init.d/apache reload EOF % vim httpd.conf # Edit :mak[e] install_and_reload # Edit more @: :make even saves the buffer for you, so that’s all you need to do. If it's too much overhead in this tight loop to continue committing small changes to git, then it's no problem to undo the failed couple lines of new configuration and try again. If you’re referring to a lot of unnecessary git commits, which, again, I wasn’t suggesting, you can always use git rebase --interactive to weed out, join, and reorder commits. -- 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: Update on Vim 7.3 status
Hi Bram!
On Di, 25 Mai 2010, Bram Moolenaar wrote:
Christian Brabandt wrote:
This completely depends on what you are doing. When a file has been
edited by someone else, using Vim, you can undo his changes. That can
be very useful. On the other hand, the undo file will reveal anything
you undid, perhaps things you never wanted others to see.
We probably need to add an example for a BufWritePre autocommand that
only sets 'undofile' for files under your home directory. Perhaps this
works:
set noundofile
au BufWritePre $HOME/* setlocal undofile
Untested!
Not sure this works. Further testing shows, that the provided binary
crashes always when using :wundo filename (doesn't matter what
undofile is set to). This does not happen with a self built mingw binary
or a cygwin binary.
BTW: If the undolevels setting is negative, you won't need to write a
undo-file, right?
Yes, when there is no undo info the file should not be written. But an
old file should still be deleted, as it will no longer be valid.
But if I set ul=-1 an undofile will still be written.
If I understand the code corectly, this should fix it:
chrisbra t41:~/vim/src [1070]% hg diff undo.c
diff -r 271a5907f944 src/undo.c
--- a/src/undo.cTue May 25 22:09:21 2010 +0200
+++ b/src/undo.cTue May 25 22:54:13 2010 +0200
@@ -1265,6 +1265,14 @@
perm = 0600;
#endif
}
+if (p_ul 0)
+{
+ mch_remove(file_name);
+ if (p_verbose 0)
+ smsg((char_u *)_('undolevels' is negative, won't write the
undofile: %s),
+ file_name);
+ goto theend;
+}
/* set file protection same as original file, but strip s-bit */
perm = perm 0777;
regards,
Christian
--
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: C-N , C-P causes crash
On 25/05/10 19:51, reckoner wrote: Hi, When I try to complete using C-N or C-P in insert mode, I routinely get a crash. I just download the latest svn svn co https://vim.svn.sourceforge.net/svnroot/vim/vim7 I have the following in my _vimrc: set complete+=s*.py set complete-=k complete+=k Below is the error listing: Unhandled exception at 0x00547c75 in gvim.exe: 0xC005: Access violation reading location 0x0286c000. First-chance exception at 0x00547c75 in gvim.exe: 0xC005: Access violation reading location 0x0286c004. Unhandled exception at 0x00547c75 in gvim.exe: 0xC005: Access violation reading location 0x0286c004. First-chance exception at 0x00547e25 in gvim.exe: 0xC005: Access violation reading location 0x0286c000. Unhandled exception at 0x00547e25 in gvim.exe: 0xC005: Access violation reading location 0x0286c000. First-chance exception at 0x00547e37 in gvim.exe: 0xC005: Access violation writing location 0x0286c000. Unhandled exception at 0x00547e37 in gvim.exe: 0xC005: Access violation writing location 0x0286c000. First-chance exception at 0x00547e37 in gvim.exe: 0xC005: Access violation writing location 0x0286c000. The thread 'Win32 Thread' (0x1054) has exited with code 0 (0x0). Unhandled exception at 0x00547e37 in gvim.exe: 0xC005: Access violation writing location 0x0286c000. and here is the call stack from VisualStudio 2008: gvim.exe!ins_compl_add_infercase(unsigned char * str=0x0283a8d3, int len=1, int icase=1, unsigned char * fname=0x0285c118, int dir=1, int flags=0) Line 2280 + 0x18 bytes C gvim.exe!ins_compl_files(int count=40, unsigned char * * files=0x0285c1d0, int thesaurus=1, int flags=1, regmatch_T * regmatch=0x0012f740, unsigned char * buf=0x0283a898, int * dir=0x0012f730) Line 3062 + 0x29 bytes C gvim.exe!ins_compl_dictionaries(unsigned char * dict_start=0x0222d1fa, unsigned char * pat=0x028403e0, int flags=1, int thesaurus=1) Line 2964 + 0x21 bytes C gvim.exe!ins_compl_get_exp(pos_T * ini=0x007d6c0c) Line 4042 + 0xd2 bytes C gvim.exe!ins_compl_next(int allow_get_expansion=1, int count=1, int insert_match=1) Line 4439 + 0xa bytes C gvim.exe!ins_complete(int c=14) Line 5072 + 0x21 bytes C gvim.exe!edit(int cmdchar=105, int startln=0, long count=1) Line 1348 + 0x9 bytes C gvim.exe!invoke_edit(cmdarg_S * cap=0x0012fb80, int repl=0, int cmd=105, int startln=0) Line 8911 + 0x14 bytes C gvim.exe!nv_edit(cmdarg_S * cap=0x0012fb80) Line 8884 + 0x14 bytes C gvim.exe!normal_cmd(oparg_S * oap=0x0012fc1c, int toplevel=1) Line 1188 + 0x12 bytes C gvim.exe!main_loop(int cmdwin=0, int noexmode=0) Line 1211 + 0xb bytes C gvim.exe!VimMain() Line 955 + 0x9 bytes C gvim.exe!WinMain(HINSTANCE__ * hInstance=0x0040, HINSTANCE__ * hPrevInst=0x, char * lpszCmdLine=0x00222466, int nCmdShow=10) Line 125 + 0xe bytes C gvim.exe!__tmainCRTStartup() Line 263 + 0x2c bytes C gvim.exe!WinMainCRTStartup() Line 182 C any help appreciated. Thanks! When you type :version (without the quotes, but with Enter afterward), what are the first lines of the reply, until and including the line which ends with Features included (+) or not (-):? To capture the output: :redir @+ :version :redir END This copies the :version output to the sytem clmipboard, you can then paste it into an email (you may remove many lines of gibberish after the first handful, before you send). Best regards, Tony. -- ARTHUR: Be quiet! DENNIS: Well you can't expect to wield supreme executive power just 'cause some watery tart threw a sword at you! ARTHUR: Shut up! DENNIS: I mean, if I went around sayin' I was an empereror just because some moistened bint had lobbed a scimitar at me they'd put me away! The Quest for the Holy Grail (Monty Python) -- 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 for updated swedish spell files
On May 22, 4:03 pm, Stefan Karlsson te...@gmail.com wrote: /.../ My attempt to contact the original maintainer resulted in a mail bounce /.../ It was me that you were trying to contact -- sorry about that :-) No worries, just glad you're alive! As I don't have much spare time these days, it's good that you take over the Vim spelling-checking of The Language of Honour and Heroes. Don't forget Language of Valor, Good looks and Modesty! ;) /.../ if anyone could help me with testing the patches themselves, and of course the patched files in themselves. I'd be happy to give them a go. I'll use them at work (Windows XP) and at home (Arch Linux X86_64); hopefully I'll be able to give some feedback during the next week. Awesome! I think some of the stuff you patched has been fixed in the original -- but if I've patched away anything that should be in there, let me know. -- o/ Mattias -- 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
3 remarks about undo.c
Hi
3 remarks about vim/src/undo.c (at changeset: 271a5907f944):
(1) Using persistent-undo, I notice once in a while the following memory
leak, but I have not found the way to reproduce it all the time:
==3371== 10 bytes in 2 blocks are definitely lost in loss record 23 of 116
==3371==at 0x4024F70: malloc (vg_replace_malloc.c:236)
==3371==by 0x8114F98: lalloc (misc2.c:919)
==3371==by 0x81BCC06: u_read_undo (undo.c:983)
==3371==by 0x80C5359: readfile (fileio.c:2591)
==3371==by 0x8053976: open_buffer (buffer.c:132)
==3371==by 0x8098ABE: do_ecmd (ex_cmds.c:3658)
==3371==by 0x80AEF7B: do_exedit (ex_docmd.c:7620)
==3371==by 0x80AEC38: ex_edit (ex_docmd.c:7516)
==3371==by 0x80A782C: do_one_cmd (ex_docmd.c:2639)
==3371==by 0x80A5105: do_cmdline (ex_docmd.c:1108)
==3371==by 0x812AD39: nv_colon (normal.c:5226)
==3371==by 0x81245C3: normal_cmd (normal.c:1188)
==3371==by 0x80E7938: main_loop (main.c:1216)
==3371==by 0x80E742F: main (main.c:960)
It's this alloc in undo.c:
983array = (char_u **)U_ALLOC_LINE(
984 (unsigned)(sizeof(char_u *) * uep-ue_size));
Looking at the undo.c code, memory seems to be properly freed
but I might be missing something since Valgrind does not generally
give spurious leak messages.
(2) In vim/src/undo.c I see at line 92:
91 /* See below: use malloc()/free() for memory management. */
92 #define U_USE_MALLOC 1
Whether U_USE_MALLOC is defined or not selects different
implementations of U_FREE_LINE and U_ALLOC_LINE.
Is the implementation when U_USE_MALLOC is undefined
still meant to be used? Or can it be removed?
I'm asking because if I comment out the line #define U_USE_MALLOC 1
at line undo.c:92, then Vim quickly crashes when using persistent-undo.
In other words, persistent undo only works when U_USE_MALLOC is defined.
(3) When U_USE_MALLOC is defined (default behavior), I see that 1 byte
is added to every allocations at line 117:
115 #ifdef U_USE_MALLOC
116 # define U_FREE_LINE(ptr) vim_free(ptr)
117 # define U_ALLOC_LINE(size) lalloc((long_u)((size) + 1), FALSE)
118 #else
This extra 1 byte is odd since it's not needed everywhere U_ALLOC_LINE(...)
is used. I think it's better if the caller is responsible for adding +1
when needed to avoid wasting memory. Attached patch does that.
Maybe this patch also fixes the leak (1) but I'm not sure since I don't
know how to reproduce it all the time. At least, I have not seen the
leak so far after applying the attached patch.
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 271a5907f944 src/undo.c
--- a/src/undo.c Tue May 25 22:09:21 2010 +0200
+++ b/src/undo.c Tue May 25 23:12:27 2010 +0200
@@ -114,7 +114,7 @@
#ifdef U_USE_MALLOC
# define U_FREE_LINE(ptr) vim_free(ptr)
-# define U_ALLOC_LINE(size) lalloc((long_u)((size) + 1), FALSE)
+# define U_ALLOC_LINE(size) lalloc((long_u)((size)), FALSE)
#else
static void u_free_line __ARGS((char_u *ptr, int keep));
static char_u *u_alloc_line __ARGS((unsigned size));
@@ -896,7 +896,7 @@
goto error;
else if (str_len 0)
{
-if ((line_ptr = U_ALLOC_LINE(str_len)) == NULL)
+if ((line_ptr = U_ALLOC_LINE(str_len + 1)) == NULL)
goto error;
for (i = 0; i str_len; i++)
line_ptr[i] = (char_u)getc(fp);
@@ -917,10 +917,13 @@
/* uhp_table will store the freshly created undo headers we allocate
* until we insert them into curbuf. The table remains sorted by the
* sequence numbers of the headers. */
-uhp_table = (u_header_T **)U_ALLOC_LINE(num_head * sizeof(u_header_T *));
-if (uhp_table == NULL)
-goto error;
-vim_memset(uhp_table, 0, num_head * sizeof(u_header_T *));
+if (num_head 0)
+{
+ uhp_table = (u_header_T **)U_ALLOC_LINE(num_head * sizeof(u_header_T *));
+ if (uhp_table == NULL)
+ goto error;
+ vim_memset(uhp_table, 0, num_head * sizeof(u_header_T *));
+}
c = get2c(fp);
while (c == UF_HEADER_MAGIC)
@@ -980,14 +983,16 @@
uep-ue_lcount = get4c(fp);
uep-ue_size = get4c(fp);
uep-ue_next = NULL;
-array = (char_u **)U_ALLOC_LINE(
+
+array = (uep-ue_size == 0)
+ ? NULL : (char_u **)U_ALLOC_LINE(
(unsigned)(sizeof(char_u *) * uep-ue_size));
for (i = 0; i uep-ue_size; i++)
{
line_len = get4c(fp);
/* U_ALLOC_LINE provides an extra byte for the NUL terminator.*/
line = (char_u *)U_ALLOC_LINE(
- (unsigned) (sizeof(char_u) * line_len));
+ (unsigned) (sizeof(char_u) * line_len + 1));
if (line == NULL)
goto error;
for (j = 0; j line_len; j++)
@@ -1100,8 +1105,7 @@
Re: (bug) yank and a particular utf-8 character
Charles Campbell wrote: Hello! Set up a file tmp with a single line: (this line should appear as a -1 with a m exponent; ie. char-0x1D50 -1ᵐ Use the following command: vim -u simple.vimrc tmp and try Yp (yank and put). simple.vimrc: set nocp set enc=utf-8 I see --11ᵐ instead of -1ᵐ -1ᵐ ie. its picking up the -1 but ignoring the m exponent. Regards, Chip Campbell Hi Charles I don't see this bug using Vim-7.3a BETA, Linux x86. -- 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: (bug) yank and a particular utf-8 character
On 25/05/10 22:37, Bram Moolenaar wrote: Charles Campbell wrote: Set up a filetmp with a single line: (this line should appear as a -1 with a m exponent; ie. char-0x1D50 -1áµ Use the following command: vim -u simple.vimrc tmp and try Yp (yank and put). simple.vimrc: set nocp set enc=utf-8 I see --11áµ instead of -1áµ -1áµ ie. its picking up the -1 but ignoring the m exponent. I can't reproduce it... Neither can I. (My OS locale is en_US.UTF-8 so I started Vim with vim -u NONE -N minus-one-em.txt ). Which Vim version? I tried Vim 7.3a c81f0a037059 (Mon May 24 22:06:04 2010 +0200 And another small fix for persistent undo.) and also Vim 7.2.437. My file minus-one-em.txt contains your three characters and a linefeed, no BOM (hex 2D 31 E1 B5 90 0A). I see what you describe when doing y0p or y^p instead (starting at the exponent-m in Normal mode), which is normal since 0 and ^ are exclusive motions. y$p (starting in column 1) gives --1ᵐ1ᵐ which is also normal since $ is inclusive. Best regards, Tony. -- Rules for driving in New York: (1) Anything done while honking your horn is legal. (2) You may park anywhere if you turn your four-way flashers on. (3) A red light means the next six cars may go through the intersection. -- 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: C-N , C-P causes crash
On 25-May-2010 reckoner recko...@gmail.com wrote: Lech: Thanks for your reply. I'm attaching the _vimrc (sorry it's kind of messy). The tricky part is that I can't reliably reproduce the error, even though it happens consistently. In other words, I can't exactly articulate a finite series of steps that lead to the crash other than I keep doing C-N and C-P until it does happen. It seems like it depends on the accumulation of a number of previous events before it finally happens. Also, it doesn't seem to matter which python files are being used. I have run into this problem before while editing many different python files. The only thing is that I recompiled the gvim binary using a new python installation (Python version 2.6) using the PYTHON and PYTHON_VER flags with DYNAMIC_PYTHON=no and using Visual Studio 2008. I then took the existing vim installation (which is vim 7.2 from the installer) and then simply replaced the gvim binary with the one I personally compiled for Python version 2.6. Thanks again. Any help appreciated. I can reproduce an invalid memory access for C-XC-T and C-XC-K, but have no clue how to cause this for C-N or C-P. Are you sure this happens when you do C-N or C-P? If so, please, do your best to find the right steps to make the problem appear. -- 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: inoremap esc bug?
On Tue, May 25, 2010 at 4:53 PM, Bee beeyaw...@gmail.com wrote:
On May 25, 1:19 pm, Tony Mechelynck antoine.mechely...@gmail.com
wrote:
On 25/05/10 18:03, Bee wrote:
Is this a bug? Seems inoremap is not working here.
I recommend
:set timeout timeoutlen=5000 ttimeoutlen=100
(or similar), where
- both times are in milliseconds
- 'timeoutlen' should be longer than the longest time between keystrokes
when you're hesitating about which key to type next in a multikey {lhs}
for a mapping
- 'ttimeoutlen' should be shorter than the shortest time between
keystrokes at your fastest typing speed but longer than the (longest)
time between successive bytes sent to you by the keyboard for a single key.
When bytes arrive with a shorter interval between them than
'ttimeoutlen' milliseconds, Vim will then accept them as a multibyte
keycode (if found in the current termcap) in preference to a mapping.
See the corresponding help topics for details.
Hi Tony
I tried what you suggested and it had no effect, tried other values,
still get the A, B, C, D.
Also tried with:
vim -N -i NONE -u NONE
Still getting:
The arrow keys up, down, right, left produce A, B, C, D respectively.
Yes, this is a known vim bug that has been reported multiple times -
at least once by me.
~Matt
--
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
