Re: [patch] fixed overlapping memcpy() in if_xcmdsrv.c
2008/11/9 Matt Wozniski [EMAIL PROTECTED]:
On Sat, Nov 8, 2008 at 11:18 PM, Tony Mechelynck wrote:
Configure is supposed to check whether one of the system provided
string-move operations handle overlap. Here's what I see in the logs and
files produced by configure on my system:
snip
So I suppose mch_memmove should be used everywhere for moves of byte
strings (overlapping or not), and it will be resolved by bcopy, memmove,
memcpy or the owncoded function according to what configure has found.
You're right up til this point, but mch_memmove() should only be used
where the bytes are overlapping, since it's so much less efficient
than just a normal memcpy() and that loss is only justified when its
extra feature is being used. memmove() should never be used in the
vim sources.
~Matt
Yes, memcpy() is more efficient then memmove() for copying
memory, and can/should be used when there we can guarantee
that there is such overlap. If there can be overlap, memmove()
must be used, but it does not exists on all systems, hence the
need for mch_memmove() for portability. See man pages of
memcpy() memmove().
In practice, memcpy() may actually work on some system,
or may not work depending on compiler, optimization options
or whether copy goes upward or downward, etc. In any case,
don't rely on it, it's not portable.
I just wrote a simple test case, to see how my system (linux x86)
behaves, it shows that memcpy() does not work in practice for
overlapping memory:
$ 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 =[abcdeabcdefghijpqrstuvwxyz]
testing descending memmove() with overlapping mem...OK
testing ascending memmove() with overlapping mem...OK
Interestingly, running the same test case under valgrind gives
different results:
$ valgrind ./test-memcpy-memmove 2 vg.log
testing descending memcpy() with overlapping mem...OK
testing ascending memcpy() with overlapping mem...OK
testing descending memmove() with overlapping mem...OK
testing ascending memmove() with overlapping mem...OK
Results may be different on other systems, but at least,
on Linux x86, using memcpy() for overlapping memory
does not give the correct results. So don't treat those
overlapping memory messages from valgrind as theoretical
bugs, but as real severe nasty bugs.
I attach the source code of my test case if you want to
run it on your system.
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
/*
* Test whether memcpy()/memmove() give the correct
* results when moving overlapping memory upward or
* backward. mempcy() is not guarantee to be correct
* when memory overlaps, memmove() should be correct.
*
* Results on my system (Linux x86):
*
* $ gcc -O2 -Wall -o test-memcpy-memmove test-memcpy-memmove.c
* $ ./test-memcpy-memmove
* testing descending memcpy() with overlapping mem...OK
* testing ascending memcpy() with overlapping mem...FAIL
* expected=[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 and actual results, and print outcome */
static void compare(const char *expected, const char *actual)
{
if (strcmp(expected, actual) == 0) {
printf(OK\n);
} else {
printf(FAIL\n
expected=[%s]\n
actual =[%s]\n, expected, actual);
}
}
int main()
{
/* 0 1 2
* .01234567890123456789012345 */
const char *pristine_str = abcdefghijklmnopqrstuvwxyz;
char *str;
/* Expected results when copying 10 char by 5 positions (hence
* overlapping memory).
*
* When copying downward memmove(str, str + 5, 10)
* (.) for unchanged char (X) for changed char:
*
* pristine: abcdefghijklmnopqrstuvwxyx
* XX */
const const char *expected1 = fghijklmnoklmnopqrstuvwxyz;
/*
* When copying upward memmove(str + 5, str, 10)
* (.) for unchanged char (X) for changed char:
*
* pristine: abcdefghijklmnopqrstuvwxyx
* .XX... */
const const char *expected2 = abcdeabcdefghijpqrstuvwxyz;
printf(testing descending memcpy() with overlapping mem...);
str = strdup(pristine_str);
memcpy(str, str + 5, 10);
compare(str, expected1);
printf(testing ascending memcpy() with overlapping mem...);
Re: [patch] fixed overlapping memcpy() in if_xcmdsrv.c
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 =[abcdeabcdefghijpqrstuvwxyz]
testing descending memmove() with overlapping mem...OK
testing ascending memmove() with overlapping mem...OK
Oops, small mistake, which does not change the conclusion,
output should have been:
$ ./memcpy-memmove
testing descending memcpy() with overlapping mem...OK
testing ascending memcpy() with overlapping mem...FAIL
expected=[abcdeabcdefghijpqrstuvwxyz]
actual =[abcdeabcdeabcdepqrstuvwxyz]
testing descending memmove() with overlapping mem...OK
testing ascending memmove() with overlapping mem...OK
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
/*
* Test whether memcpy()/memmove() give the correct
* results when moving overlapping memory upward or
* backward. mempcy() is not guarantee to be correct
* when memory overlaps, memmove() should be correct.
*
* Results on my system (Linux x86):
*
* $ gcc -O2 -Wall -o test-memcpy-memmove test-memcpy-memmove.c
* $ ./test-memcpy-memmove
* testing descending memcpy() with overlapping mem...OK
* testing ascending memcpy() with overlapping mem...FAIL
* expected=[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 and actual results, and print outcome */
static void compare(const char *expected, const char *actual)
{
if (strcmp(expected, actual) == 0) {
printf(OK\n);
} else {
printf(FAIL\n
expected=[%s]\n
actual =[%s]\n, expected, actual);
}
}
int main()
{
/* 0 1 2
* .01234567890123456789012345 */
const char *pristine_str = abcdefghijklmnopqrstuvwxyz;
char *str;
/* Expected results when copying 10 char by 5 positions (hence
* overlapping memory).
*
* When copying downward memmove(str, str + 5, 10)
* (.) for unchanged char (X) for changed char:
*
* pristine: abcdefghijklmnopqrstuvwxyx
* XX */
const const char *expected1 = fghijklmnoklmnopqrstuvwxyz;
/*
* When copying upward memmove(str + 5, str, 10)
* (.) for unchanged char (X) for changed char:
*
* pristine: abcdefghijklmnopqrstuvwxyx
* .XX... */
const const char *expected2 = abcdeabcdefghijpqrstuvwxyz;
printf(testing descending memcpy() with overlapping mem...);
str = strdup(pristine_str);
memcpy(str, str + 5, 10);
compare(expected1, str);
printf(testing ascending memcpy() with overlapping mem...);
strcpy(str, pristine_str);
memcpy(str + 5, str, 10);
compare(expected2, str);
printf(testing descending memmove() with overlapping mem...);
strcpy(str, pristine_str);
memmove(str, str + 5, 10);
compare(expected1, str);
printf(testing ascending memmove() with overlapping mem...);
strcpy(str, pristine_str);
memmove(str + 5, str, 10);
compare(expected2, str);
free(str);
return 0;
}
Re: netbeans connection when Vim is not compiled with netbeans_intg
On Sat, Nov 8, 2008 at 7:14 PM, sc [EMAIL PROTECTED] wrote: On Saturday 08 November 2008 10:12 am, Xavier de Gaye wrote: On Sat, Nov 8, 2008 at 2:24 PM, Bram Moolenaar [EMAIL PROTECTED] wrote: ... The place where you invoke mch_exit() looks a bit weird. Not sure if this is the best solution. And when compiled without GUI (e.g., starting a small version of Vim) this exit won't be reached. Would someone only use -nb with gvim? The message should be defined in one place, not twice. Right of course. I will try sending another patch fixing these points. Good, thanks. Attached is a patch that fixes the above issues. It's on top of version 7.2.28 (subversion revision 1226). oops -- please forgive the double post -- I so often hit Send and then engage my brain revision 1226 did indeed update my source to 7.2.28 but as it stands it will not compile for me (already noted in a previous post) Right, to compile Vim I had to comment out lines 656/657 in ex_cmds.h. Xavier --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Patch 7.2.031
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.
Solution: Add v:oldfiles and fill it with the list of old file names when
first reading the viminfo file. Add the :oldfiles command,
:browse oldfiles and the #123 special file name. Increase
the default value for 'viminfo' from '20 to '100.
Files: runtime/doc/cmdline.txt, runtime/doc/eval.txt,
runtime/doc/starting.txt, runtime/doc/usr_21.txt, src/eval.c,
src/ex_cmds.c, src/ex_cmds.h, src/ex_docmd.c, src/feature.h,
src/fileio.c, src/main.c, src/mark.c, src/misc1.c,
src/proto/eval.pro, src/proto/ex_cmds.pro, src/proto/mark.pro,
src/option.c, src/structs.h, src/vim.h
*** ../vim-7.2.030/runtime/doc/cmdline.txt Sat Aug 9 19:36:46 2008
--- runtime/doc/cmdline.txt Thu Sep 18 22:55:27 2008
***
*** 1,4
! *cmdline.txt* For Vim version 7.2. Last change: 2008 Jul 29
VIM REFERENCE MANUALby Bram Moolenaar
--- 1,4
! *cmdline.txt* For Vim version 7.2. Last change: 2008 Sep 18
VIM REFERENCE MANUALby Bram Moolenaar
***
*** 157,162
--- 157,167
(doesn't work at the expression prompt; some
things such as changing the buffer or current
window are not allowed to avoid side effects)
+ When the result is a |List| the items are used
+ as lines. They can have line breaks inside
+ too.
+ When the result is a Float it's automatically
+ converted to a String.
See |registers| about registers. {not in Vi}
Implementation detail: When using the |expression| register
and invoking setcmdpos(), this sets the position before
***
*** 730,748
In Ex commands, at places where a file name can be used, the following
characters have a special meaning. These can also be used in the expression
function expand() |expand()|.
! % is replaced with the current file name *:_%*
! # is replaced with the alternate file name*:_#*
#n (where n is a number) is replaced with the file name of
! buffer n. #0 is the same as #
! ## is replaced with all names in the argument list *:_##*
concatenated, separated by spaces. Each space in a name
is preceded with a backslash.
! Note that these give the file name as it was typed. If an absolute path is
! needed (when using the file name from a different directory), you need to add
! :p. See |filename-modifiers|.
Note that backslashes are inserted before spaces, so that the command will
correctly interpret the file name. But this doesn't happen for shell
! commands. For those you probably have to use quotes:
:!ls %
:r !spell %
--- 735,763
In Ex commands, at places where a file name can be used, the following
characters have a special meaning. These can also be used in the expression
function expand() |expand()|.
! % Is replaced with the current file name. *:_%* *c_%*
! # Is replaced with the alternate file name. *:_#* *c_#*
#n (where n is a number) is replaced with the file name of
! buffer n. #0 is the same as #.
! ## Is replaced with all names in the argument list *:_##* *c_##*
concatenated, separated by spaces. Each space in a name
is preceded with a backslash.
! #n (where n is a number 0) is replaced with old*:_#* *c_#*
! file name n. See |:oldfiles| or |v:oldfiles| to get the
! number. *E809*
! {only when compiled with the +eval and +viminfo features}
!
! Note that these, except #n, give the file name as it was typed. If an
! absolute path is needed (when using the file name from a different directory),
! you need to add :p. See |filename-modifiers|.
!
! The #n item returns an absolute path, but it will start with ~/ for files
! below your home directory.
!
Note that backslashes are inserted before spaces, so that the command will
correctly interpret the file name. But this doesn't happen for shell
! commands. For those you probably have to use quotes (this fails for files
! that contain a quote and wildcards):
:!ls %
:r !spell %
*** ../vim-7.2.030/runtime/doc/eval.txt Sat Aug 9 19:36:47 2008
--- runtime/doc/eval.txtSun Nov 2 14:25:38
Re: Vim syntax: highlight keyword not highlighted inside functions
%s/there are recent versions/there is no recent versions/ Sorry for small typo. -- Anton 2008/11/9, Anton Sharonov [EMAIL PROTECTED]: I should add that I'm using Vim 7.2.26, compiled by myself using the sources from the CVS, so I guess the syntax file also comes from the CVS. I get the same result when using Vim -u NONE -U NONE, and enabling only syntax highlighting after that. ... so I guess the syntax file also comes from the CVS. ... Unfortunately, it is not true. At least for SVN, (and I suspect that for CVS it is as well the case) there are recent versions of the runtime files (don't ask me why, for me it is also _very_ confusing). Anyway, to get recent runtime files, please use rsync, as described on Tony's howto [1] about compiling vim. -- Anton [1] Tony's how to for VIM compilation UNIX: http://users.skynet.be/antoine.mechelynck/vim/compunix.htm WINDOWS: http://users.skynet.be/antoine.mechelynck/vim/compile.htm --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim syntax: highlight keyword not highlighted inside functions
I should add that I'm using Vim 7.2.26, compiled by myself using the sources from the CVS, so I guess the syntax file also comes from the CVS. I get the same result when using Vim -u NONE -U NONE, and enabling only syntax highlighting after that. ... so I guess the syntax file also comes from the CVS. ... Unfortunately, it is not true. At least for SVN, (and I suspect that for CVS it is as well the case) there are recent versions of the runtime files (don't ask me why, for me it is also _very_ confusing). Anyway, to get recent runtime files, please use rsync, as described on Tony's howto [1] about compiling vim. -- Anton [1] Tony's how to for VIM compilation UNIX: http://users.skynet.be/antoine.mechelynck/vim/compunix.htm WINDOWS: http://users.skynet.be/antoine.mechelynck/vim/compile.htm --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Feature request? Cannot set the color of non selected entries in the wildmenu
Thanks for the trick! On Sun, Nov 9, 2008 at 07:01, Tony Mechelynck [EMAIL PROTECTED] wrote: On 08/11/08 14:12, François Ingelrest wrote: Hi all, The only highlight concerning the wildmenu I'm aware of is 'WildMenu'. This lets me choose how the current match should be highlighted, but I can't set the style of other entries in that menu. AFAICT, Vim automatically uses the highlight style of the status bar. This is annoying, because I like to use colors such as dark grey / white for this kind of things (e.g., completion menu, tabs), so that the current entry is clearly visible. However, to do that, I would have to set the foregound color of the status bar to dark grey, resulting in a status bar not easily readable most of the time (when the wildmenu is not currently used). Is there a solution to this problem? AFAIK, there isn't; but it's only a problem if you want it to be. The selected 'wildmenu' entry is in WildMenu highlight, and the rest in StatusLine highlight. You can change them at any time, and the current values will be used. In my colorscheme, I alternate the StatusLine highlight between two contrasting values, and the WildMenu is set to the other setting, as follows: let s:colors_name = almost-default [...] display the status line of the active window in a distinctive color: bold black on bright red in the GUI, white on green in the console (where the bg is never bright, and dark red is sometimes an ugly sort of reddish brown). hi StatusLine gui=NONE,bold guibg=red guifg=black \ cterm=NONE,bold ctermbg=darkgreen ctermfg=white hi WildMenu gui=NONE,bold guibg=green guifg=black \ cterm=NONE,bold ctermbg=black ctermfg=white make the status line bold-reverse (but BW) for inactive windows hi StatusLineNC gui=reverse,bold \ cterm=NONE ctermbg=black ctermfg=lightgrey make the active status line colours alternate between two settings to give a visual notice of the CursorHold/CursorHoldI events if ! exists(s:statuslineflag) let s:statuslineflag = 0 endif function! ToggleStatusLine() if s:statuslineflag hi StatusLine \ cterm=NONE,bold ctermbg=darkgreen ctermfg=white \ gui=NONE,bold guibg=red guifg=black hi WildMenu \ cterm=NONE,bold ctermbg=black ctermfg=white \ gui=NONE,bold guibg=green guifg=black else hi StatusLine \ cterm=NONE,bold ctermbg=black ctermfg=white \ gui=NONE,bold guibg=green guifg=black hi WildMenu \ cterm=NONE,bold ctermbg=darkgreen ctermfg=white \ gui=NONE,bold guibg=red guifg=black endif let s:statuslineflag = ! s:statuslineflag endfunction exe augroup s:colors_name au! CursorHold,CursorHoldI * call ToggleStatusLine() au! ColorScheme * \ if g:colors_name != s:colors_name \ | exe au! s:colors_name \ | endif augroup END [...] remember the current colorscheme name let g:colors_name = s:colors_name --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim syntax: highlight keyword not highlighted inside functions
On Sun, Nov 9, 2008 at 11:14, Anton Sharonov [EMAIL PROTECTED] wrote: Unfortunately, it is not true. At least for SVN, (and I suspect that for CVS it is as well the case) there are recent versions of the runtime files (don't ask me why, for me it is also _very_ confusing). Anyway, to get recent runtime files, please use rsync, as described on Tony's howto [1] about compiling vim. Thanks for pointing this. I've updated my runtime files, but the highlight problem is nevertheless still there. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.2.031
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 build when compiling with -DEXITFREE:
eval.c: In function 'eval_clear':
eval.c:849: error: 'struct vimvar' has no member named 'vv_string'
eval.c:850: error: 'struct vimvar' has no member named 'vv_string'
Attached patch fixes it.
Regards
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: eval.c
===
RCS file: /cvsroot/vim/vim7/src/eval.c,v
retrieving revision 1.268
diff -c -r1.268 eval.c
*** eval.c 9 Nov 2008 12:46:09 - 1.268
--- eval.c 9 Nov 2008 14:29:35 -
***
*** 846,853
p = vimvars[i];
if (p-vv_di.di_tv.v_type == VAR_STRING)
{
! vim_free(p-vv_string);
! p-vv_string = NULL;
}
else if (p-vv_di.di_tv.v_type == VAR_LIST)
{
--- 846,853
p = vimvars[i];
if (p-vv_di.di_tv.v_type == VAR_STRING)
{
! vim_free(p-vv_di.di_tv.vval.v_string);
! p-vv_di.di_tv.vval.v_string = NULL;
}
else if (p-vv_di.di_tv.v_type == VAR_LIST)
{
Re: VIM for programmers: what is needed ?
Have a look on eclim [1] project. This attempts to integrate vim into eclipse IDE. AFAIK, it has not yet support for C++, but this is just a question of time, in case of C++ support in eclipse is good enough (eclim already supports integration of java, python related features, so it must be possible to extend it for C++ as well). For Java programming IMO eclim is already in the stage of must have. -- Anton [1] Eclim http://eclim.sourceforge.net/ 2008/11/9, alex [EMAIL PROTECTED]: Hi, I use vim for writing documents in latex since a few years, and I think vim is the best editor for writing text files that exists ! The vim latex suite is also very good. Now I am beginning to learn C++ programming, and of course I need some tools for doing that. In other words I need an IDE or somthing like an IDE... Because vim is the best text editor, I would like to keep working with VIM and NOT switching to IDEs like NetBeans or Eclipse (I work on Linux and on Windows). I think that VIM could boost productivity far more than Eclipse does. It would also be possible to use VIM side by side with NetBeans or Eclipse switching between the two softwares... but in the practice all is not so simple. The only tool I miss in VIM (for now) is an efficeint class and source code browser, that recognizes the object oriented features of C++ (and other languages), so that i can find class members, etc. etc. I need something like an improved cscope for object oriented programming. I have tried exuberant ctags, the taglist plugin and omincppcomplete. Omincppcomplete seems to work good, but I dont have found nothing better than this packages (Vim intellisens works on Windows only). I tried GNU global too. Doxygen is very good, but it is not intended to be used dinamically, and does not support text editor integration (you use a HTML browser to see the infos about the classes and members in the source code). A possible alternative is to use the jVi (another vi clone) in NetBeans (nbvi). So the question is (I have read similar treads in this group): - does there exist some tools for navigating classes and members efficiently in C++ projects, better than exuberant ctags or cscope or GNU global or gnutags, that are simply to use and that can be used with vim or form the command line ? Or I have to use NetBeans or Eclipse ? Because there exists omnicppcomplete i do not give up my hopes. - where can i find a complete introduction to how to use the plugins for vim for programming (taglist, omincppcomplete, and others) ? - emacs has OObrowser, Ebrowse, xrefacotry. Does vim has similar tools ? - NetBeans has jVi, but why you dont work thowards a full integration of vim in Eclipse or NetBeans. I mean using all the (g)vim functionality within this modern IDEs... this would be a way for bringing vim in the 21st century. The editors of Eclipse and NetBeans are very poor if compared to vim ! - what tools can I use under GNU linux for programming and navigating object-oriented source code outside of vim ? Vim is only an editor, but the people do not need only an editor, they need IDEs too (or at least extra software like of course g++ make gdb etcetera). But modern IDEs simply do not have editors that are so good as vim, who is the best editor. Sorry for the long threat and thank you in advance for any reply (i have read all the similar threads but i still ask you). Thank you ! --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
netbeans killed events
It is not clear if netbeans killed events are correctly sent by Vim. For example with 2 windows displaying each a different buffer, ':[N]bunload' will trigger a killed event, and ':quit' on this same buffer will not trigger the event, however both commands have the same effects. killed events are sent by netbeans_file_closed(). Below is the reverse call-graph of netbeans_file_closed() (in this graph, a function is called by all functions at the next indentation level): netbeans_file_closed: (a) close_buffer set_curbuf do_ecmd ex_window win_close win_close_othertab ... do_buffer goto_buffer nb_do_cmd: (b) when processing close netbeans command do_bufdel: (c) ex_bunload nb_do_cmd: (d) only if netbeansBuffer, when processing stopDocumentListen netbeans command The global variable netbeansCloseFile is only used in netbeans_file_closed() and do_bufdel(). (a) pseudo code for netbeans_file_closed(): if netbeansCloseFile send killed event and forget the reference to the Vim buffer in the netbeans buffer structure else debug message: Ignoring file_closed. File was closed from IDE and return (b) nb_do_cmd: does not trigger a killed event (c) do_bufdel: set netbeansCloseFile = 1 at start, reset to zero before function exit (d) nb_do_cmd: triggers a killed event only if the buffer is a netbeansBuffer Occurences of killed events: * Only bunload, bdelete and bwipeout Vim commands trigger a killed event * In (d), why the netbeans application would want to receive a killed event when it is the one that sets the buffer as a netbeansBuffer and the one that is responsible for sending the stopDocumentListen command that triggers this event ? This does not make sense Note also that when setting netbeans debug mode, the message Ignoring file_closed. File was closed from IDE is printed when a buffer is closed by any Vim command other than bunload, bdelete, bwipeout and this message is obviously wrong since it is closed from Vim, not from the IDE. Conclusion: As it is, killed events are useless for the netbeans application (but they cannot be ignored as the bufno reference is not anymore valid after receiving the event). I would like to propose to remove the global netbeansCloseFile entirely from the code, expecting that this would cause a killed event whenever a buffer is not anymore visible in any window, but I don't know Vim code sufficiently to be sure that this is the case. Xavier --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Patch 7.2.032
Patch 7.2.032 (after 7.2.031)
Problem:Can't build with EXITFREE defined. (Dominique Pelle)
Solution: Change vv_string to vv_str.
Files: src/eval.c
*** ../vim-7.2.031/src/eval.c Sun Nov 9 13:43:25 2008
--- src/eval.c Sun Nov 9 17:16:06 2008
***
*** 846,853
p = vimvars[i];
if (p-vv_di.di_tv.v_type == VAR_STRING)
{
! vim_free(p-vv_string);
! p-vv_string = NULL;
}
else if (p-vv_di.di_tv.v_type == VAR_LIST)
{
--- 846,853
p = vimvars[i];
if (p-vv_di.di_tv.v_type == VAR_STRING)
{
! vim_free(p-vv_str);
! p-vv_str = NULL;
}
else if (p-vv_di.di_tv.v_type == VAR_LIST)
{
*** ../vim-7.2.031/src/version.cSun Nov 9 13:43:25 2008
--- src/version.c Sun Nov 9 17:21:00 2008
***
*** 678,679
--- 678,681
{ /* Add new patch number below this line */
+ /**/
+ 32,
/**/
--
hundred-and-one symptoms of being an internet addict:
218. Your spouse hands you a gift wrapped magnet with your PC's name
on it and you accuse him or her of genocide.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Patch 7.2.031
Dominique Pelle wrote: 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 build when compiling with -DEXITFREE: eval.c: In function 'eval_clear': eval.c:849: error: 'struct vimvar' has no member named 'vv_string' eval.c:850: error: 'struct vimvar' has no member named 'vv_string' Attached patch fixes it. Thanks. But a better solution is to change vv_string to vv_str. -- Don't be humble ... you're not that great. -- Golda Meir /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: netbeans killed events
Please remove me from your group! - Original Message - From: Xavier de Gaye [EMAIL PROTECTED] Sent: 11/09/2008 05:18 PM CET To: vim-dev [EMAIL PROTECTED] Subject: netbeans killed events It is not clear if netbeans killed events are correctly sent by Vim. For example with 2 windows displaying each a different buffer, ':[N]bunload' will trigger a killed event, and ':quit' on this same buffer will not trigger the event, however both commands have the same effects. killed events are sent by netbeans_file_closed(). Below is the reverse call-graph of netbeans_file_closed() (in this graph, a function is called by all functions at the next indentation level): netbeans_file_closed: (a) close_buffer set_curbuf do_ecmd ex_window win_close win_close_othertab ... do_buffer goto_buffer nb_do_cmd: (b) when processing close netbeans command do_bufdel: (c) ex_bunload nb_do_cmd: (d) only if netbeansBuffer, when processing stopDocumentListen netbeans command The global variable netbeansCloseFile is only used in netbeans_file_closed() and do_bufdel(). (a) pseudo code for netbeans_file_closed(): if netbeansCloseFile send killed event and forget the reference to the Vim buffer in the netbeans buffer structure else debug message: Ignoring file_closed. File was closed from IDE and return (b) nb_do_cmd: does not trigger a killed event (c) do_bufdel: set netbeansCloseFile = 1 at start, reset to zero before function exit (d) nb_do_cmd: triggers a killed event only if the buffer is a netbeansBuffer Occurences of killed events: * Only bunload, bdelete and bwipeout Vim commands trigger a killed event * In (d), why the netbeans application would want to receive a killed event when it is the one that sets the buffer as a netbeansBuffer and the one that is responsible for sending the stopDocumentListen command that triggers this event ? This does not make sense Note also that when setting netbeans debug mode, the message Ignoring file_closed. File was closed from IDE is printed when a buffer is closed by any Vim command other than bunload, bdelete, bwipeout and this message is obviously wrong since it is closed from Vim, not from the IDE. Conclusion: As it is, killed events are useless for the netbeans application (but they cannot be ignored as the bufno reference is not anymore valid after receiving the event). I would like to propose to remove the global netbeansCloseFile entirely from the code, expecting that this would cause a killed event whenever a buffer is not anymore visible in any window, but I don't know Vim code sufficiently to be sure that this is the case. Xavier __ This message contains information which may be confidential and privileged. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy, re-transmit, or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail @WMA.com, and delete the message. E-mail communication is highly susceptible to spoofing, spamming, and other tampering, some of which may be harmful to your computer. If you are concerned about the authenticity of the message or the source, please contact the sender directly. Please be advised that the William Morris Agency does not render legal services. Please consider the environment before printing this email. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: netbeans connection when Vim is not compiled with netbeans_intg
On 09/11/08 11:38, Xavier de Gaye wrote: On Sat, Nov 8, 2008 at 7:14 PM, sc[EMAIL PROTECTED] wrote: On Saturday 08 November 2008 10:12 am, Xavier de Gaye wrote: On Sat, Nov 8, 2008 at 2:24 PM, Bram Moolenaar[EMAIL PROTECTED] wrote: ... The place where you invoke mch_exit() looks a bit weird. Not sure if this is the best solution. And when compiled without GUI (e.g., starting a small version of Vim) this exit won't be reached. Would someone only use -nb with gvim? The message should be defined in one place, not twice. Right of course. I will try sending another patch fixing these points. Good, thanks. Attached is a patch that fixes the above issues. It's on top of version 7.2.28 (subversion revision 1226). oops -- please forgive the double post -- I so often hit Send and then engage my brain revision 1226 did indeed update my source to 7.2.28 but as it stands it will not compile for me (already noted in a previous post) Right, to compile Vim I had to comment out lines 656/657 in ex_cmds.h. Xavier There was an error in patch 7.2.027 (corrected in 7.2.030 and improved in 7.2.031) which caused compile errors. If you upgrade to the current source it ought to work. Best regards, Tony. -- According to Kentucky state law, every person must take a bath at least once a year. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
[patch] fixed access to freed memory with -DEXITFREE (introduced by patch-7.2.31)
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 it's introduced
by Vim-7.2.{31,32}.
==30738== Invalid read of size 4
==30738==at 0x806E81A: set_ref_in_ht (eval.c:6592)
==30738==by 0x807D751: garbage_collect (eval.c:6536)
==30738==by 0x808A4A4: eval_clear (eval.c:874)
==30738==by 0x81006FD: free_all_mem (misc2.c:1131)
==30738==by 0x813174F: mch_exit (os_unix.c:3057)
==30738==by 0x809E690: ex_quit (ex_docmd.c:6228)
==30738==by 0x80A63CB: do_one_cmd (ex_docmd.c:2622)
==30738==by 0x80A77BE: do_cmdline (ex_docmd.c:1096)
==30738==by 0x811423E: nv_colon (normal.c:5217)
==30738==by 0x8116C53: normal_cmd (normal.c:1184)
==30738==by 0x80DA03F: main_loop (main.c:1180)
==30738==by 0x80DD637: main (main.c:939)
==30738== Address 0x4c18ae4 is 4 bytes inside a block of size 2,048 free'd
==30738==at 0x402268C: free (vg_replace_malloc.c:323)
==30738==by 0x808A42C: eval_clear (eval.c:858)
==30738==by 0x81006FD: free_all_mem (misc2.c:1131)
==30738==by 0x813174F: mch_exit (os_unix.c:3057)
==30738==by 0x809E690: ex_quit (ex_docmd.c:6228)
==30738==by 0x80A63CB: do_one_cmd (ex_docmd.c:2622)
==30738==by 0x80A77BE: do_cmdline (ex_docmd.c:1096)
==30738==by 0x811423E: nv_colon (normal.c:5217)
==30738==by 0x8116C53: normal_cmd (normal.c:1184)
==30738==by 0x80DA03F: main_loop (main.c:1180)
==30738==by 0x80DD637: main (main.c:939)
Line eval.c:6536 where error happens is introduced by patch 7.2.31.
I attach a patch which fixes it, but please double check
that it's correct: calling hash_init(vimvarht) after
hash_clear(vimvarht) is needed to prevent
garbage_collect() from using the freed hash later.
Groetjes
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: eval.c
===
RCS file: /cvsroot/vim/vim7/src/eval.c,v
retrieving revision 1.269
diff -c -r1.269 eval.c
*** eval.c 9 Nov 2008 16:22:01 - 1.269
--- eval.c 9 Nov 2008 20:56:39 -
***
*** 856,861
--- 856,862
}
}
hash_clear(vimvarht);
+ hash_init(vimvarht);
hash_clear(compat_hashtab);
/* script-local variables */
Re: mac-osx and open
Nico Weber wrote: Hi Charles, On 09.11.2008, at 16:32, Charles E. Campbell, Jr. wrote: I was browsing the wiki -- and I noticed the tip Preview current HTML in browser on Mac OS X (well, a comment to it does): let g:netrw_browsex_viewer = 'open' so that the viewer triggered by x in the netrw browser will work on a mac. I'm not a mac user (yet), so for you mac user types: Would it be a good idea to use open if has(gui_mac) is true? This is probably better discussed on vim_mac, but: Yes, it's a good idea to use open, but as far as I understand, that's what's already happening. From the netrw.vim that ships with the latest MacVim snapshot: elseif has(macunix) executable(open) call Decho(exe silent !open .shellescape(fname,1). .redir) exe silent !open .shellescape(fname,1). .redir If I remember correctly, you added that about a year ago after I sent you a patch. So I guess the wiki is just outdated. I was thinking that I'd done something -- but searcing for gui_mac wasn't finding anything. I'm guessing that macunix is likely to be better, anyway. Glad not to need to do anything! and thanks (probably again) for that patch. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: netrw - double quoted question mark
in a query string should be passed as amp; or as %26 though many web pages don't use this, even though the W3C HTML guidelines require it. I don't believe that's accurate, Tony. Only if you are writing an HTML file need you use amp; ever and that's only because of the necessity to escape that character () in HTML; it has nothing to do with the URL. When a URL is in plain text, or passed to a web browser or whatever, it should simply be , if it is to have a special meaning in the scheme of choice, i.e. HTTP uses it for separating name-value pairs in query strings, or %26 if it is not to have that special meaning (i.e. if you want to actually be a part of a name or value). Of course, in passing that or %26 you need to escape it appropriately: if on a shell commandline, you might need backslashes, if in HTML, you might need amp;, if in Vim, you might need backslashes sometimes. Because some people/software insist on using amp; where they should just use , though, some software (PHP for example) contains, or can contain, code to treat amp; like (often in a hacky way--in PHP there is another side effect), even though technically it shouldn't. I suppose that if netrw has problems with the question mark (maybe for internal reasons) it can always be passed as %3F No; it would lose its special meaning (beginning the query string in the URL), and would become part of the path part of the URL if you did that. Equally wrong. All this is detailed in the RFCs to do with URLs/URIs and HTTP. I don't have time to look up the relevant parts now, though. It has nothing to do with HTML, except for the amp; thing, but that's not about the URL, but how it's represented in HTML. All that said, I haven't double checked what I've written, and I could have some details wrong too. So refer to the standards for the gore! Regards, Ben. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: mac-osx and open
Nico Weber wrote:
If I remember correctly, you added that about a year ago
after I sent you a patch. So I guess the wiki is just outdated.
Any chance you could update the tip? I recommend deleting any info that applies
only
to older Vim (before, say, Vim 7.0, but even 7.1 if it simplifies a tip). If you
believe that the tip is ok for current Vim, remove the {{review}} line.
http://vim.wikia.com/wiki/Preview_current_HTML_in_browser_on_Mac_OS_X
John
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: netrw - double quoted question mark
For example :view http://www.vim.org/scripts/script_search_results.php?keywords=netrw shows an empty buffer, because the URL that is passed to wget contains '\?'. I guess the URL is also inside quotes when passed to wget (via the shell)? If it isn't, it *should* have '\?' because ? has a special meaning in the shell. The shell should remove the '\' so that only the '?' reaches wget. Ben. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: netrw - double quoted question mark
On Nov 8, 11:25 pm, Tony Mechelynck [EMAIL PROTECTED]
wrote:
...
in a query string should be passed as amp; or as %26 though many web
pages don't use this, even though the W3C HTML guidelines require it.
I suppose that ifnetrwhas problems with the question mark (maybe for
internal reasons) it can always be passed as %3F (but of course not as
%253F which would be double percent escaping and miss the goal).
When the URL above is re-written using % symbol, it does not work
either, because
now it is % that gets double qouted. Of course, you have to type '\
%' in the URL,
otherwise % would be replaced by the active file.
Currently, the autocommands plugin/netrwPlugin.vim load URLs by
constructing an
exe Nread ... fnameescape(expand('amatch')) command,
where fnameescape causes double quoted ? or % symbols. However,
executing without
fnameescape (as done in the patch) is dangerous, because any | in
the URL would make vim
execute another command. Both issues would be avoided if autocommands
were calling
a function and passing it a string. Just my 2 cents. Cheers,
Pavol
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: How can I send a patch?
I will try to clear my words. When tab is pressed in column 0 or in a new word, a character tab is inserted. And when a Ctrl-x Ctrl-I is taped, a character tab is inserted too (I changed this too). I don't like to Ctrl-P because it's so slowed, a tab work better. I using a linux terminal and the tab complete is so cool. About the flexible, I think about this when I was working... But I didnt know how do this. Anyway I can work more to put this. 2008/11/8 Bram Moolenaar [EMAIL PROTECTED] Roberto Miura Honji wrote: I change something on vim code and some friends tell me that I would be send this to development group. How can I send this? The new function is: - Auto-complete using a tab key (like ctrl-p). - When the word have a '/' (linux separator of directories) auto-complete like a file (ctrl-x ctrl-f). - When the list search is returned, the tab can be used to scroll through the list. - when the previous char is space, tab, the cursor position is a col = 0 or ctrl-x ctrl-i is typed, the char tab is insert normally) I think that it's so cool to programmer that use the linux, actually terminal linux. The patch is: I have some trouble understanding how this works. If it works like CTRL-P, then why not use CTRL-P? At least that avoids the problem that someone wants to insert a Tab and gets completion instead. Your description sounds like it's a bit unpredictable. The patch is hard-coding things that should be flexible. For example, in MS-Windows the path separator is a backslash. And one should use 'isfname' to check if a character can be part of a file name. The code is also lacking support for multi-byte characters. Still some work to do! But before you spend time on that, we need to find out if we really want it to work this way. -- Spam seems to be something useful to novices. Later you realize that it's a bunch of indigestable junk that only clogs your system. Applies to both the food and the e-mail! /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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 /// -- -- Roberto Miura Honji LAS - Laboratório de Administração e Segurança de Sistemas Engenharia de Computação - 2006 Instituto de Computação - UNICAMP email: [EMAIL PROTECTED] (principal) email: [EMAIL PROTECTED] msn: [EMAIL PROTECTED] --- --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: netbeans killed events
On Sun, Nov 9, 2008 at 5:18 PM, Xavier de Gaye [EMAIL PROTECTED] wrote: It is not clear if netbeans killed events are correctly sent by Vim. ... Conclusion: As it is, killed events are useless for the netbeans application (but they cannot be ignored as the bufno reference is not anymore valid after receiving the event). I would like to propose to remove the global netbeansCloseFile entirely from the code, expecting that this would cause a killed event whenever a buffer is not anymore visible in any window, but I don't know Vim code sufficiently to be sure that this is the case. I have missed the following important point: the Vim signs placed in the buffer are removed by bdelete and by bwipeout, but not by bunload or by any other Vim command. The netbeans application must keep track of the Vim signs, so I suggest: * the semantics of the killed event is: the bufno reference is invalid the signs have been removed by Vim * the code is changed so that only bdelete and bwipeout trigger a killed event (not bunload) * the documentation is updated accordingly Xavier --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: mac-osx and open
Hi Charles, On 09.11.2008, at 16:32, Charles E. Campbell, Jr. wrote: I was browsing the wiki -- and I noticed the tip Preview current HTML in browser on Mac OS X (well, a comment to it does): let g:netrw_browsex_viewer = 'open' so that the viewer triggered by x in the netrw browser will work on a mac. I'm not a mac user (yet), so for you mac user types: Would it be a good idea to use open if has(gui_mac) is true? This is probably better discussed on vim_mac, but: Yes, it's a good idea to use open, but as far as I understand, that's what's already happening. From the netrw.vim that ships with the latest MacVim snapshot: elseif has(macunix) executable(open) call Decho(exe silent !open .shellescape(fname,1). .redir) exe silent !open .shellescape(fname,1). .redir If I remember correctly, you added that about a year ago after I sent you a patch. So I guess the wiki is just outdated. Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
how do I regenerate src/config.h.in?
Hi, I checked out vim7 from svn and I am now trying to add clisp interpreter support (similar to FEAT_RUBY et al). I added --enable-clispinterp to src/configure.in and regenerated src/auto/configure using make autoconf. alas, it did not update src/config.h.in and I do not see a rule in src/Makefile which does. a naive autoheader invocation fails: $ autoheader autoheader: warning: missing template: BAD_GETCWD autoheader: Use AC_DEFINE([BAD_GETCWD], [], [Description]) autoheader: warning: missing template: BROKEN_TOUPPER autoheader: warning: missing template: EBCDIC autoheader: warning: missing template: FEAT_BIG autoheader: warning: missing template: FEAT_CLISP autoheader: warning: missing template: FEAT_CSCOPE autoheader: warning: missing template: FEAT_GUI_GNOME autoheader: warning: missing template: FEAT_HANGULIN autoheader: warning: missing template: FEAT_HUGE autoheader: warning: missing template: FEAT_MBYTE autoheader: warning: missing template: FEAT_MZSCHEME autoheader: warning: missing template: FEAT_NETBEANS_INTG autoheader: warning: missing template: FEAT_NORMAL autoheader: warning: missing template: FEAT_PERL autoheader: warning: missing template: FEAT_PYTHON autoheader: warning: missing template: FEAT_RUBY autoheader: warning: missing template: FEAT_SMALL autoheader: warning: missing template: FEAT_SNIFF autoheader: warning: missing template: FEAT_SUN_WORKSHOP autoheader: warning: missing template: FEAT_TCL autoheader: warning: missing template: FEAT_TINY autoheader: warning: missing template: FEAT_XFONTSET autoheader: warning: missing template: FEAT_XIM autoheader: warning: missing template: HAVE_AIX_ACL autoheader: warning: missing template: HAVE_DATE_TIME autoheader: warning: missing template: HAVE_DEV_PTC autoheader: warning: missing template: HAVE_FLOAT_FUNCS autoheader: warning: missing template: HAVE_GETTEXT autoheader: warning: missing template: HAVE_GPM autoheader: warning: missing template: HAVE_GTK2 autoheader: warning: missing template: HAVE_GTK_MULTIHEAD autoheader: warning: missing template: HAVE_ICONV autoheader: warning: missing template: HAVE_NL_LANGINFO_CODESET autoheader: warning: missing template: HAVE_NL_MSG_CAT_CNTR autoheader: warning: missing template: HAVE_OSPEED autoheader: warning: missing template: HAVE_OUTFUNTYPE autoheader: warning: missing template: HAVE_POSIX_ACL autoheader: warning: missing template: HAVE_PTHREAD_NP_H autoheader: warning: missing template: HAVE_RENAME autoheader: warning: missing template: HAVE_SELINUX autoheader: warning: missing template: HAVE_SIGCONTEXT autoheader: warning: missing template: HAVE_SOLARIS_ACL autoheader: warning: missing template: HAVE_SS_BASE autoheader: warning: missing template: HAVE_ST_BLKSIZE autoheader: warning: missing template: HAVE_SVR4_PTYS autoheader: warning: missing template: HAVE_SYSCONF autoheader: warning: missing template: HAVE_SYSCTL autoheader: warning: missing template: HAVE_SYSINFO autoheader: warning: missing template: HAVE_SYSINFO_MEM_UNIT autoheader: warning: missing template: HAVE_SYSMOUSE autoheader: warning: missing template: HAVE_UNION_WAIT autoheader: warning: missing template: HAVE_UP_BC_PC autoheader: warning: missing template: HAVE_X11 autoheader: warning: missing template: HAVE_X11_XMU_EDITRES_H autoheader: warning: missing template: MODIFIED_BY autoheader: warning: missing template: NO_STRINGS_WITH_STRING_H autoheader: warning: missing template: OSPEED_EXTERN autoheader: warning: missing template: PTYGROUP autoheader: warning: missing template: PTYMODE autoheader: warning: missing template: PTYRANGE0 autoheader: warning: missing template: PTYRANGE1 autoheader: warning: missing template: RUNTIME_GLOBAL autoheader: warning: missing template: SIGRETURN autoheader: warning: missing template: SIZEOF_INT autoheader: warning: missing template: STAT_IGNORES_SLASH autoheader: warning: missing template: SYS_SELECT_WITH_SYS_TIME autoheader: warning: missing template: TERMINFO autoheader: warning: missing template: TGETENT_ZERO_ERR autoheader: warning: missing template: UNIX autoheader: warning: missing template: UP_BC_PC_EXTERN autoheader: warning: missing template: USEBCOPY autoheader: warning: missing template: USEMAN_S autoheader: warning: missing template: USEMEMCPY autoheader: warning: missing template: USEMEMMOVE autoheader: warning: missing template: USE_XSMP_INTERACT autoheader: warning: missing template: XPMATTRIBUTES_TYPE autoheader: warning: missing template: X_LOCALE $ so, how do I update src/config.h.in to reflect my src/configure.in changes? thanks. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: netbeans connection when Vim is not compiled with netbeans_intg
On Sunday 09 November 2008 1:18 pm, Tony Mechelynck wrote: [snip] There was an error in patch 7.2.027 (corrected in 7.2.030 and improved in 7.2.031) which caused compile errors. If you upgrade to the current source it ought to work. for whatever reason, svn is lagging behind posted patches -- if, like me, Xavier is waiting on svn, he is stuck at 7.2.28 (since Nov 6) this is fine for us, but if a newbie comes along expecting to build the latest and greatest vim by following instructions, he's going to wind up with sources that won't build -- not good, unless he has the perseverence to browse this group -- what he'll use to find Xavier's kind response to my whining I'm not sure, I just hope the experience doesn't turn him into an emacs user sc --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Please remove me (Was: netbeans killed events)
On 09/11/08 17:35, Holly Baril wrote: Please remove me from your group! The best-placed person to remove you from this group is yourself. There are two ways to do it, depending on how you interface with the group. a) If you used the Google Groups interface, go back to http://groups.google.com/groups/mysubs?hl=en (log in if necessary) then turn the drop-down at far right on the vim_dev line to make it say Unsubscribe. Then click Save group settings. I'm not sure what happens afterwards, you may have to read a last email and obey it to confirm that you really want to unsubscribe -- or maybe not. b) If you used the vim.org interface, send an email to [EMAIL PROTECTED] but MAKE SURE that the From: line on that email holds the exact address with which you subscribed and to which list mail is being sent. You will then get a last email at that address, telling you what to do in order to confirm that you really want to unsubscribe (and that it isn't some joker playing a bad-taste practical joke on you). Best regards, Tony. -- We're knights of the round table We dance whene'er we're able We do routines and chorus scenes With footwork impeccable. We dine well here in Camelot We eat ham and jam and spam a lot. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: netbeans connection when Vim is not compiled with netbeans_intg
On 09/11/08 21:45, sc wrote: On Sunday 09 November 2008 1:18 pm, Tony Mechelynck wrote: [snip] There was an error in patch 7.2.027 (corrected in 7.2.030 and improved in 7.2.031) which caused compile errors. If you upgrade to the current source it ought to work. for whatever reason, svn is lagging behind posted patches -- if, like me, Xavier is waiting on svn, he is stuck at 7.2.28 (since Nov 6) this is fine for us, but if a newbie comes along expecting to build the latest and greatest vim by following instructions, he's going to wind up with sources that won't build -- not good, unless he has the perseverence to browse this group -- what he'll use to find Xavier's kind response to my whining I'm not sure, I just hope the experience doesn't turn him into an emacs user sc Vim SVN is always lagging (sometimes by a week or two) behind CVS. OTOH the patches appear on the FTP server (and, I think, on CVS which I don't use) about as fast as they are published on vim_dev. I'm not sure about A-A-P but I think it uses CVS too. So it's just a question of which instructions to follow. On Windows, a newbie doesn't need to build Vim himself (he can just grab Steve Hall's cream-less Vim distributions on sourceforge) so the question arises mostly on Unix-like systems. As shown on my HowTo page, what I use is FTP for code and rsync for runtimes: this way I remain up-to-date. In the rare cases when the FTP site has a hiccup and the patches don't appear there in timely fashion, I grab the vim_dev post and check that it has Content-Transfer-Encoding: 8bit (or 7bit). Quoted-printable is not as easy, it must be doctored by hand, but it's doable. Best regards, Tony. -- Friends, Romans, Hipsters, Let me clue you in; I come to put down Caesar, not to groove him. The square kicks some cats are on stay with them; The hip bits, like, go down under; so let it lay with Caesar. The cool Brutus Gave you the message: Caesar had big eyes; If that's the sound, someone's copping a plea, And, like, old Caesar really set them straight. Here, copacetic with Brutus and the studs, -- for Brutus is a real cool cat; So are they all, all cool cats, -- Come I to make this gig at Caesar's laying down. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
