Robert Bragg wrote:
Hi,
So it turns out, I'm the only one in the world that wants more than 8
cscope connections, but I really do :-)
I track / work with the source for several GNOME projects, and have my
own builds for various common GNOME and freedesktop.org libraries which
I have
Bram Moolenaar wrote:
Dominique Pelle wrote:
...snip...
I'm not sure whether this current behavior for PageDown is
intentional or whether it is a bug. It looks like a bug and I
think it should behave like pressing 'f'. In any case, it not
documented in :help more-prompt.
On the other
Hi
Valgrind memory checker detects the following memory leak in Vim-7.2.148:
==26113== 36 bytes in 1 blocks are definitely lost in loss record 23 of 41
==26113==at 0x402603E: malloc (vg_replace_malloc.c:207)
==26113==by 0x8113A62: lalloc (misc2.c:866)
==26113==by 0x8158375:
Hi
When output of a Vim commands spans multiple screens, it is
possible to press 'f', PageDown or Space to move down
page by page until the bottom of the output. But the keys
behave differently when reaching the bottom of the output:
- pressing 'f' will stop at the prompt Press ENTER or
type
Hi
I can reproduce the following error with Vim-7.2.148 using
Valgrind memory checker. The steps to reproduce the error
are too complicated to detail here. I have not found a
simple test case but I can reproduce the problem 100% of
the time.
==15886== Invalid read of size 1
==15886==at
In :help :history, I see...
:his[tory] [{name}] [{first}][, [{last}]]
List the contents of history {name} which can be:
c[md]or : command-line history
s[earch] or / search string history
e[xpr] or = expression register
Lech Lorens wrote:
The attached patch makes the quickfix / location list window's title
reflect the command that yielded the error list.
Additionally, two commands have been added:
:cse[ttitle]
:lse[ttitle]
Additional attached patch adds documentation of
:csettitle and :lsettitle to
Tony Mechelynck wrote:
On 19/03/09 13:08, Yakov Lerner wrote:
On Tue, Mar 17, 2009 at 12:41, Yakov Lerneriler...@gmail.com wrote:
We have separae highlighting, StatusLineNC, for non-current.
I wish I had different *format*, too, for noncurrent statusline. I do not
think differnt format
1/ According to :help functions, function cursor() is meant
to return a value of type 'Number'. But function cursor()
(f_cursor() in eval.c) does not return anything. So doing
:echo cursor(1,1) prints an uninitialized value and valgrind
reports the following error:
==20458== Use of
Recent patch 7.2.143 introduced completion for the :cscope command.
Attached patch improves completion further to also add completion for
the :lcscope and :scscope commands:
:lcscope completion is identical to :cscope
:scscope completion restricts to subcommands which can run in split window.
Doing :set t_Co=256 causes to the color scheme to be
sourced. That's fine when value of t_Co changes, but if
value of t_Co is set to the same value as previous value, it
seems useless.
Sourcing color scheme script can be slow. Attached patch
avoids to re-source colorscheme if t_Co is set to the
Hi
Command custom completion (:help :command-completion-customlist)
is leaking memory when redefining completion for a command
multiple times. I see this bug in latest Vim-7.2.132.
The following script illustrates the problem: memory usage keeps
growing at each iteration when redefining a
James Vega wrote:
On Sat, Mar 07, 2009 at 04:30:30PM -0500, James Vega wrote:
There seems to be an edge case when positioning the cursor and
'virtualedit' is set to all that causes gvim to crash. This was
introduced between 6.4 and 7.0b.
It can be reproduced using the attached files as
Bram Moolenaar wrote:
Thanks for the patch. I thought of catching the problem at the cause,
by disallowing the autocommands to do something that will cause trouble.
However, it's very difficult to catch all situations.
So I think we can do both: disallow autocommands to do things that are
Buffer name [Command Line] is not translated with gettext.
This is the buffer name which shows up when doing q:
Attached patch (from Vim-7.2.128) allows to translate it,
for those who use Vim with non-English locales.
Regards
-- Dominique
--~--~-~--~~~---~--~~
Hi
I observe a bug in Vim-7.2.128 with the omni-completion popup menu
when the option 'splitbelow' is set (bug does not happen when
'splitbelow' is not set).
When pressing the Down key in the omni-completion menu,
I see 2 pum: one above the current line and another one
below the current line.
Bram Moolenaar wrote:
Dominique Pelle wrote:
Buffer name [Command Line] is not translated with gettext.
This is the buffer name which shows up when doing q:
Attached patch (from Vim-7.2.128) allows to translate it,
for those who use Vim with non-English locales.
Not translating
Bram Moolenaar wrote:
Dominique Pelle wrote:
...snip...
Without marking the variable volatile, there is a risk I think,
that some compilers might optimize making code incorrect
sometimes by not seeing that the variable gets automagically
updated asynchronously by a signal handler
Signs are not freed when exiting Vim as one would expect when
building with -DEXITFREE. Attached patch fixes it. This is a
minor problem. It's not a real memory leak. Fixing it only helps
to avoid seeing spurious leaks when searching for memory leaks.
-- Dominique
Hi
Attached patch fixes a race condition which causes Vim to hang
when resuming (with fg) after having suspended Vim with CTRL-Z.
Bug does not happen 100% of the time, but once in a while. I
can reproduce the bug with Vim-7.2.121 in a xterm on Linux x86
after doing
CTRL-Z
fg
CTRL-Z
fg
, etc,
Bram Moolenaar wrote:
Dominique Pelle wrote:
Attached patch fixes a race condition which causes Vim to hang
when resuming (with fg) after having suspended Vim with CTRL-Z.
Bug does not happen 100% of the time, but once in a while. I
can reproduce the bug with Vim-7.2.121 in a xterm
Nazri Ramliy wrote:
On Fri, Feb 20, 2009 at 9:18 AM, Nazri ayieh...@gmail.com wrote:
I'm refining the patch - fixing a memory leak (stupid me :), and
improving the shortening of the matching paths to get the minimum
unique length of each. This is much much better than the simple (and
not
björn wrote:
Hi,
For the last two weeks or so I've been getting this warning when
compiling Vim (on Mac OS X):
ex_docmd.c: In function 'do_one_cmd':
ex_docmd.c:5937: warning: 'end' may be used uninitialized in this function
ex_docmd.c: In function 'do_one_cmd':
ex_docmd.c:5937: warning:
Bram Moolenaar wrote:
Dominique Pelle wrote:
Vim-7.2.108 can read and write beyond allocated memory when
using autocmd VimResized. Bug happens if a shell command is
used in VimResized autocmd such as...
:au! VimResized * sil !echo -ne \033]12;green\007
With this autocmd, I observe
Bram Moolenaar wrote:
Dominique Pelle wrote:
Testing autocommands, I see that Vim-7.2.107 (and older)
is using memory already freed when doing silly autocommands
such as:
$ touch foobar
$ valgrind ./vim -u NONE -c 'au! BufReadPre * cd /tmp' \
-c 'e foobar' 2
Testing autocommands, I see that Vim-7.2.107 (and older)
is using memory already freed when doing silly autocommands
such as:
$ touch foobar
$ valgrind ./vim -u NONE -c 'au! BufReadPre * cd /tmp' \
-c 'e foobar' 2 vg.log
In vg.log, I then see the following error:
Attached are a couple of low priority patches.
In netbeans.c, there are 2 format mismatches (%d instead of %ld):
- fixed-format-netbeans.c.patch
In nbdebug.c, I see 2 functions [nbtrace() nbprt()] which are
defined but which are never called from anywhere (are they needed?):
-
Dominique Pelle wrote:
But the patch breaks something. See the 2 screenshots
before after patch (gvim-7.2.102 with/without patch):
http://dominique.pelle.free.fr/pic/visual-sel-before-patch.png
http://dominique.pelle.free.fr/pic/visual-sel-after-patch.png
After patch, the column
Dewr wrote:
oops. I have not attached any file.
look at this -
ftp://foobar.dnip.net:2121/upload/dewry/brokendownalphabets.bmp
I don't know what the problem is. But your screenshot is very slow
to download (~ 5.3 Mb) I reduced it to just 73 Kbytes by doing:
$ convert -strip -depth 4
björn wrote:
Dominique: It is strange that my patch does not fix the problem for
you...maybe fast_breakcheck() doesn't call gui_mch_update() often
enough on your system (although that seems unlikely judging from the
amount of times this loop iterates as I mentioned above)? It does
take
2009/2/5 Andreas Bernauer andr...@lysium.de:
björn wrote:
2009/2/4 Bram Moolenaar:
So what's the problem you are trying to solve?
The original problem was this: go to e.g. the vim src/ directory and
enter :grep a *.c. During this operation it is impossible to halt
Vim using ctrl-c.
harpchad wrote:
Additional details:
VIM 7.2
Included patches: 1-88
Huge version without GUI.
Compilation: /opt/studio/SOS11/SUNWspro/bin/cc -c -I. -Iproto -
DHAVE_CONFIG_H -I/opt/csw/include -xO3 -xarch=v9 -I/opt/csw/include
Linking: /opt/studio/SOS11/SUNWspro/bin/cc -xarch=v9
Dominique Pelle wrote
***
*** 4961,4968
typedef struct sblock_S sblock_T;
struct sblock_S
{
- sblock_T *sb_next; /* next block in list */
int sb_used;/* nr of bytes already in use */
char_usb_data[1]; /* data, actually
Hi
I observe that test51 fails as follows when locale
is set to es_ES.UTF-8 (it succeeds for other locale,
well, I did not try all of them yet):
$ export LANGUAGE=es_ES.UTF-8
$ cd vim7/src
$ make test
Test results:
test51 FAILED
$ diff -c testdir/test51.{ok,failed}
*** testdir/test51.ok
Bram Moolenaar wrote:
=[1] hash_init(0x100313ac4, 0x3b0, 0x1003139fc, 0x440, 0x90,
0x100313aec), at 0x1000bbd00
hash_init() only has one argument, I wonder what the numbers mean.
I think that's because the debugger did not know how
many arguments the function has (because Vim was
compiled
Tony Mechelynck wrote:
On 24/01/09 12:25, Bram Moolenaar wrote:
Dominique Pelle wrote:
[...]
Notice also the FIXME comment in the attached patch: shouldn't
E118 and E740 error message be the same error message?
See how similar they are:
E740: Too many arguments for function %s
E118
Ingo Karkat wrote:
Hello VIM developers,
I've encountered occasional endless loops when trying to jump to the next
misspelled word (via ]s) in HTML documents, in the case when there aren't any
misspellings. VIM then starts consuming all available CPU until the operation
is
aborted via
I noticed a few error messages which are not translated with gettext in eval.c.
For example, I do:
:lang fr_FR.UTF-8
:call filter(list)
I get an error message in English...
E116: Invalid arguments for function filter
... which I'd expect to be translated with gettext in French.
Attached
Hi
URLs in doxygen syntax highlighting are not properly highlighted
when they contain a tilde ~ character (which is a fairly frequent
character in a URL).
Attached trivial patch fixes it.
Regards
-- Dominique
--~--~-~--~~~---~--~~
You received this message from
Benjamin Fritz wrote
A patch is attached for the behavior discussed in these threads:
http://groups.google.com/group/vim_use/browse_thread/thread/8532e7236f113ab7/0b508a50b767a1e1
http://groups.google.com/group/vim_dev/browse_thread/thread/56d5debad6f5f351/44cc7eb3b4787440
Also attached is
Benjamin Fritz:
A patch is attached for the behavior discussed in these threads:
http://groups.google.com/group/vim_use/browse_thread/thread/8532e7236f113ab7/0b508a50b767a1e1
http://groups.google.com/group/vim_dev/browse_thread/thread/56d5debad6f5f351/44cc7eb3b4787440
Also attached is an
Valery Kondakoff wrote:
Hi!
If there is a 'set encoding=utf-8' line in my _vimrc gVim 7.2 hangs when
issuing ':h shortmess' command consuming ~50% of CPU usage.
Can anyone confirm this?
The ':h shortmess' command works as expected when I'm commenting the
'set encoding=utf-8' line out and
Ben Fritz wrote
On Jan 17, 9:54 am, Ben Fritz fritzophre...@gmail.com wrote:
I can't apply the patch cleanly unfortunately. There are conflicts.
I could use SVN if the runtime files are up-to-date in
there. It looks like the ones in CVS are not. I would probably prefer
this method,
Hi,
Attached patch fixes a low priority cosmetic bug.
When doing :cs help, messages are properly aligned
in English but are misaligned on some other languages
when using utf-8 encoding. So it looks ugly.
Misalignment buglet happens in languages which uses
non ASCII characters and happens at
2009/1/14 Tony Mechelynck antoine.mechely...@gmail.com:
On 14/01/09 07:16, Yasuhiro MATSUMOTO wrote:
Oops. sorry.
However, the problem happen with the script as your said. :-)
Thanks.
E486: Pattern not found means that there was no match. Are you sure
you ran that script while the
Hi
When the argument of the commands :diffget or :diffput
results in the same buffer as the current buffer, the command
corrupts the content of the current buffer.
Steps to reproduce:
1/ create 2 sample files
$ echo foo file1
$ echo bar file2
2/ run vim in diff mode
$ vim -u NONE -d file1
2008/12/27 Matt Wozniski wrote:
I found a SEGV that I can reproduce reliably, but can't seem to track
down. It SEGVs without gdb or valgrind, doesn't SEGV under valgrind,
and SEGVs under gdb. The steps that I'm using to reproduce this are
complicated, and possibly very specific to the
Matt Wozniski wrote:
I tried to reproduce it but I could not.
Yeah, I'm not surprised... the fact that it seems tied to a hash
table resizing makes me think that it's very much tied to the number
of plugins I have loaded, the number of variables I have defined, and
a whole bunch of other,
Richard Hartmann wrote:
On Thu, Dec 25, 2008 at 18:52, Dominique Pelle
dominique.pe...@gmail.com wrote:
set completeopt=menuone,longest
set tags=tags
set keymap=arabic
Are you actually seeing those in your daily work with Vim or do
you run an automated test suite that set
Dominique Pelle wrote:
Lech Lorens skribis:
Problem:
The cursor position is not updated after deleting a fold based on
markers. This results in an invalid memory reference in some scenarios.
How to reproduce:
In normal mode perform zRgg$zdaa while editing a file with the following
Bram Moolenaar skribis:
Matt Wozniski wrote:
function! ReturnArgs(...)
return a:000
endfunction
Seems to work fine?
echo ReturnArgs(1, 2, 3)
SEGV
echo string(ReturnArgs(1, 2, 3))
function! MakeArgsDict(...)
return { 'args': a:000 }
endfunction
E685
Lech Lorens skribis:
Problem:
The cursor position is not updated after deleting a fold based on
markers. This results in an invalid memory reference in some scenarios.
How to reproduce:
In normal mode perform zRgg$zdaa while editing a file with the following
contents:
[[[
blah blah blah
2008/12/16 Bram Moolenaar b...@moolenaar.net:
Matt Wozniski wrote:
function! ReturnArgs(...)
return a:000
endfunction
Seems to work fine?
echo ReturnArgs(1, 2, 3)
SEGV
echo string(ReturnArgs(1, 2, 3))
function! MakeArgsDict(...)
return { 'args': a:000 }
endfunction
E685
Attached patch fixes a few minor errors in vim help files.
Diff is against latest version available at ftp.nluug.nl::Vim/runtime/
Regards
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit
Matt Wozniski wrote:
function! ReturnArgs(...)
return a:000
endfunction
Seems to work fine?
echo ReturnArgs(1, 2, 3)
SEGV
echo string(ReturnArgs(1, 2, 3))
function! MakeArgsDict(...)
return { 'args': a:000 }
endfunction
E685 Internal Error
echo MakeArgsDict(1, 2, 3)
SEGV
Lee Naish wrote:
The J command seems to have a complexity bug when given a large numeric
argument, eg 10J
...
ie, doubling the number of lines increased the runtime by a factor of 4
exactly - seems like there is a O(N^2) component to the algorithm.
The = command also has O(n^2)
Bram Moolenaar wrote:
Lee Naish wrote:
The J command seems to have a complexity bug when given a large numeric
argument, eg 10J
eg:
% yes | head -10 vimtest
% time vim vimtest
Joined all lines using 9J
17.2u 0.0s 2:29.74 11.5% 0+0k 0+10232io 0pf+0w
% yes | head
Lee Naish wrote:
The J command seems to have a complexity bug when given a large numeric
argument, eg 10J
eg:
% yes | head -10 vimtest
% time vim vimtest
Joined all lines using 9J
17.2u 0.0s 2:29.74 11.5% 0+0k 0+10232io 0pf+0w
% yes | head -20 vimtest
% time vim
2008/12/6 Bram Moolenaar wrote:
Dominique Pelle wrote:
[...]
I've never used SNiFF+, but I'm curious about it. I searched for it on
Google. It seems that this product was taken over by Windriver, but
there is nothing about SNiFF+ on Windriver's website.
- Is SNiFF+ dead?
- Is there any
Buffer name [Scratch] is currently not translated with gettext.
Attached patch fixes it.
[Scratch] is the name of the buffer that you can see by doing
this for example:
$ vim -u NONE -c 'set bt=nofile laststatus=2'
-- Dominique
--~--~-~--~~~---~--~~
You
Tests 58 and 59 fail when doing 'make test' with latest Vim-7.2.55
(huge version, tested on Linux).
I tried older versions:
- Vim-7.2.49 All tests pass
- Vim-7.2.50 Tests 58 59 fail.
Patch 7.2.50 introduces the regression:
--- 8 --- cut here --- 8 --- cut here --- 8 ---
Patch
2008/11/29 Bram Moolenaar wrote:
Dominique Pelle wrote:
Tests 58 and 59 fail when doing 'make test' with latest Vim-7.2.55
(huge version, tested on Linux).
I tried older versions:
- Vim-7.2.49 All tests pass
- Vim-7.2.50 Tests 58 59 fail.
Patch 7.2.50 introduces
Hi
The attached patch fixes a compilation warning in vim-7.2.49:
getchar.c: In function 'makemap':
getchar.c:4705: warning: format not a string literal and no format arguments
getchar.c: In function 'put_escstr':
getchar.c:4804: warning: format not a string literal and no format arguments
This
2008/11/20 Charles Campbell [EMAIL PROTECTED]:
Bram Moolenaar wrote:
Patch 7.2.041-7.2.048 (not sure which one)
Hello!
I'm starting to get some warnings that I didn't used to get...
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include
2008/11/18 Bram Moolenaar [EMAIL PROTECTED]:
Dominique Pelle wrote:
I observe a bug with the latest Vim-7.2.42 (huge) on Linux x86.
It's not recently introduced since I can reproduce at least with
Vim-7.1.314 which comes with Ubuntu-8.10. It only happens in
a terminal (gvim does not seem
2008/11/18 Danek Duvall [EMAIL PROTECTED]:
In enc_locale(), there's a for loop that looks like this:
for (i = 0; s[i] != NUL s + i buf + sizeof(buf) - 1; ++i)
but I can't figure out what the purpose is for that second test. If I'm
reading it correctly, it's testing that the address
2008/11/19 Tony Mechelynck [EMAIL PROTECTED]:
On 18/11/08 22:29, Dominique Pelle wrote:
[...]
But I can simplify the way to reproduce it. It happens whenever
I do a visual selection in between:
- selecting text in clipboard with the mouse
- and pasting with middle click.
Example:
1
2008/11/19 John Little [EMAIL PROTECTED]:
Dominique
When I follow this:
1/ start vim with valgrind: valgrind 2 valgrind.log vim -u NONE
2/ select some text with mouse outside vim (one line is enough)
3/ enter INSERT mode in vim and type some text: iThis is a testEsc
4/ visual select
Hi
I observe a bug with the latest Vim-7.2.42 (huge) on Linux x86.
It's not recently introduced since I can reproduce at least with
Vim-7.1.314 which comes with Ubuntu-8.10. It only happens in
a terminal (gvim does not seem affected).
Steps to reproduce:
1/ start Vim in a terminal (xterm or
2008/11/17 Dominique Pelle [EMAIL PROTECTED]:
Hi
I observe a bug with the latest Vim-7.2.42 (huge) on Linux x86.
It's not recently introduced since I can reproduce at least with
Vim-7.1.314 which comes with Ubuntu-8.10. It only happens in
a terminal (gvim does not seem affected).
Steps
2008/11/16 Bram Moolenaar [EMAIL PROTECTED]:
Apparently -fstack-protector is on by default. The inline-functions
apparently does something to reveal the size of the destination to
strcpy(). That's a bit unexpected though.
Why not compile Vim with -fno-stack-protector ? Can you try with
2008/11/16 Dominique Pelle [EMAIL PROTECTED]:
2008/11/16 Bram Moolenaar [EMAIL PROTECTED]:
Apparently -fstack-protector is on by default. The inline-functions
apparently does something to reveal the size of the destination to
strcpy(). That's a bit unexpected though.
Why not compile Vim
Hi
I notice that Vim-7.2.40 (huge) crashes on start up when I
compile it with gcc 4.3.2 with -O3 (that's the default gcc
version from Ubuntu-8.10), but it works perfectly fine when
compiled with -O0, -O1 or -O2.
Here is the crash:
$ ./vim
***
Using latest vim-7.2.40 from CVS, I notice that 'make test' fails on test42.
Looking at previous versions, I see that:
- vim-7.2.33 fails test42
- vm-7.2.32 succeeds for every tests
So regression is introduced by patch 7.2.33, which explicitly
mentions that it touches test42:
2008/11/15 Bram Moolenaar [EMAIL PROTECTED]:
Another solution is to use the trick what's done for self a few lines
higher:
v = fc.fixvar[fixvar_idx++].var;
name = v-di_key;
STRCPY(name, self);
So we can do the same for 000:
v = fc.fixvar[fixvar_idx++].var;
On Nov 15, 5:25 pm, Nico Weber [EMAIL PROTECTED] wrote:
This code looks OK to me. Maybe it's a bug in gcc or maybe this
construction is just not portable. I suspect it's a bug in gcc but
I'm not 100% sure.
Isn't it better to file this as a bug with gcc?
Agreed. I just opened a gcc bug
2008/11/15 Tony Mechelynck [EMAIL PROTECTED]:
On 15/11/08 11:12, Dominique Pelle wrote:
Hi
I notice that Vim-7.2.40 (huge) crashes on start up when I
compile it with gcc 4.3.2 with -O3 (that's the default gcc
version from Ubuntu-8.10), but it works perfectly fine when
compiled with -O0
=[abcdeabcdefghijpqrstuvwxyz]
* actual =[abcdeabcdeabcdepqrstuvwxyz]
* testing descending memmove() with overlapping mem...OK
* testing ascending memmove() with overlapping mem...OK
*
* Dominique Pelle [EMAIL PROTECTED]
*/
#include string.h
#include stdio.h
#include stdlib.h
/* Compare expected
2008/11/9 Dominique Pelle [EMAIL PROTECTED]:
$ gcc -Wall -o test-memcpy-memmove test-memcpy-memmove.c
$ ./memcpy-memmove
testing descending memcpy() with overlapping mem...OK
testing ascending memcpy() with overlapping mem...FAIL
expected=[abcdeabcdeabcdepqrstuvwxyz]
actual
2008/11/9 Bram Moolenaar [EMAIL PROTECTED]:
Patch 7.2.031
Problem:Information in the viminfo file about previously edited files is
not available to the user. There is no way to get a complete list
of files edited in previous Vim sessions.
Patch 7.2.031 breaks
Hi
Using valgrind, I observe the following error with Vim-7.2.32 when
exiting Vim. It happens only when Vim is compiled with -DEXITFREE
so it's a minor bug, since Vim is normally not compiled with -DEXITFREE.
Doing vim -u NONE -c q is enough to trigger it.
It did not happen with Vim-7.2.30. So
Hi
Attached patch fixes a bug with Vim-7.2.30 when built with GUI GTK
with -DEXITFREE (configure --with-features=huge --enable-gui=gtk).
It's a low priority bug since Vim is normally not built with
-DEXITFREE. Only GTK GUI is affected (GTK2, athena, Motif are OK).
From what I see, GTK takes
Hi
While using Vim-7.2.30 built with GUI GTK (huge), I stumbled
upon this error with Valgrind memory checker:
==13326== Source and destination overlap in memcpy(0x4B5D8D8, 0x4B5D8E4, 13)
==13326==at 0x4024C92: memcpy (mc_replace_strmem.c:402)
==13326==by 0x8102E99: LookupName
Hi
Valgrind memory checker detects mismatches between malloc()/vim_free()
and alloc()/free in vim-7.2.30:
- If malloc() is used, then free() should be used,
- if alloc() is used, then vim_free() should be used.
It only really matters when compiling vim with '#define MEM_PROFILE',
because
2008/11/8 Dominique Pelle [EMAIL PROTECTED]:
Hi
Valgrind memory checker detects mismatches between malloc()/vim_free()
and alloc()/free in vim-7.2.30:
- If malloc() is used, then free() should be used,
- if alloc() is used, then vim_free() should be used.
It only really matters when
Hi
Attached is a patch to fix an obvious grammar mistake in :help E303
in vim-7.2.25.
Regards
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
Hi
The following vim script leaks memory at each iteration, using
latest Vim-7.2.25:
:set spell
:while 1
:copen
:bd
:endwhile
Run this script with 'vim -u NONE -S leak.vim' and watch memory
increasing steadily. Valgrind reports this leak:
$ valgrind
On Sat, Sep 13, 2008 at 4:09 PM, Bram Moolenaar wrote:
Dominique Pelle wrote:
Valgrind memory checker finds a memory leak in Vim-7.2.15.
The steps to reproduce are a bit too messy to describe here
and I have not been able to find a simple way to reproduce it.
However I can reproduce it 100
Hi
Valgrind memory checker finds a memory leak in Vim-7.2.15.
The steps to reproduce are a bit too messy to describe here
and I have not been able to find a simple way to reproduce it.
However I can reproduce it 100% of the time:
==1182== 150 bytes in 2 blocks are definitely lost in loss record
On Sun, Mar 16, 2008 at 2:21 PM, Bram Moolenaar [EMAIL PROTECTED] wrote:
Dominique Pelle wrote:
Valgrind memory checker detects the following bug in Vim-7.1.280:
==11795== Invalid read of size 1
==11795==at 0x4023572: strncmp (mc_replace_strmem.c:318)
==11795==by 0x80B6653
On Sun, Aug 31, 2008 at 12:06 PM, Dominique Pelle
[EMAIL PROTECTED] wrote:
On Sun, Mar 16, 2008 at 2:21 PM, Bram Moolenaar [EMAIL PROTECTED] wrote:
Dominique Pelle wrote:
Valgrind memory checker detects the following bug in Vim-7.1.280:
==11795== Invalid read of size 1
==11795
Attached patch fixes a missing parenthesis in runtime/doc/pattern.txt
in Vim-7.2.
Cheers
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
On Fri, Aug 22, 2008 at 3:32 AM, Matt Wozniski wrote:
Not sure what's going on here, but I've found a crash that's easy to
reproduce. First, open two X11 enabled vim (not gvim) processes. In
the first, do:
:let @+ = repeat('a', 1024*1024)
in order to store 1MB of data to the clipboard.
On Mon, Aug 18, 2008 at 10:15 PM, Charles Campbell wrote:
Hello!
I've issued a new plugin on my website:
http://mysite.verizon.net/astronaut/vim/index.html#RLTVNMBR . It uses
the signs capability of huge vim to give relative numbering. After
some comment period I expect to release it on
Hi
I noticed that Vim's spelling checker highlight spelling mistakes
in some parts of doxygen comments, but not everywhere.
The following screenshot illustrates the problem (notice that
not all spelling mistakes are highlighted):
http://dominique.pelle.free.fr/doxygen-spelling.png
Attached
On Mon, Jul 14, 2008 at 9:48 PM, Bram Moolenaar wrote:
Kana Natsuno wrote:
I noticed that Vim 7.2b.001 still cannot be compiled with with multi-byte
feature but without GUI or clipboard, because check_col() and check_row() are
missing. The following is a patch to fix this problem:
Darn,
Hi, Valgrind memory checker finds the following bug in
Vim-7.2.b.4 BETA. It's not a new issue, since it
also happens at least in Vim-7.1.214 for example:
==17908== Conditional jump or move depends on uninitialised value(s)
==17908==at 0x578E51: get_tags (tag.c:3823)
==17908==by 0x4467DB:
UTF_COMPOSINGLIKE() on an illegal byte. In
msg_outtrans_len_attr() use char2cells() instead of ptr2cells().
In utf_ptr2char() don't check second byte when first byte is
! illega. (Dominique Pelle)
Files: src/mbyte.c, src/message.c
Patch 7.2a.011
--- 6847,6853
On Tue, Jul 8, 2008 at 9:32 PM, Dominique Pelle wrote:
Hi,
I observe a bug in the omni completion popup menu when doing omni
completion at the end of a line which is longer than the terminal
width and with set nowrap. The menu is not drawn at the correct
location when pressing Down when
On Tue, Jul 8, 2008 at 9:32 PM, Dominique Pelle wrote:
Hi,
I observe a bug in the omni completion popup menu when doing omni
completion at the end of a line which is longer than the terminal
width and with set nowrap. The menu is not drawn at the correct
location when pressing Down when
1 - 100 din 173 matches
Mail list logo
