Crash with vim 7.3 Beta
I am not sure, if this is really a crash or simply just warnings, but anyway, I can't use vim after the incident (since I loose the keyboard control). Since the errors seem to appear in a GTK-functions, they may as well be an error in there and not specifically vim related, but I thought I let you know anyway. It basically happened, after I did :r!ifconfig when viewing the readonly file /etc/resolv.conf I cannot always reproduce it, but it occurs every once in a while. This was a fresh vim7.3 small version, compiled today after updating the hg repository: :version VIM - Vi IMproved 7.3 BETA (2010 May 15, compiled Jun 8 2010 08:19:05) Compiled by chris...@t41 Small version with GTK2 GUI. Features included (+) or not (-): -arabic -autocmd -balloon_eval -browse +builtin_terms -byte_offset -cindent -clientserver +clipboard -cmdline_compl +cmdline_hist -cmdline_info -comments -conceal -cryptv -cscope -cursorbind +cursorshape +dialog_gui -diff -digraphs +dnd -ebcdic -emacs_tags -eval -ex_extra -extra_search -farsi -file_in_path -find_in_path -float -folding -footer +fork() -gettext -hangul_input +iconv -insert_expand +jumplist -keymap -langmap -libcall -linebreak -lispindent -listcmds -localmap -menu -mksession -modify_fname +mouse -mouseshape -mouse_dec -mouse_gpm -mouse_jsbterm -mouse_netterm -mouse_sysmouse -mouse_xterm +multi_byte -multi_lang -mzscheme -netbeans_intg -osfiletype -path_extra -perl -persistent_undo -printer -profile -python -quickfix -reltime -rightleft -ruby -scrollbind -signs -smartindent -sniff -startuptime -statusline -sun_workshop -syntax -tag_binary -tag_old_static -tag_any_white -tcl +terminfo +termresponse -textobjects -title -toolbar -user_commands -vertsplit -virtualedit +visual -visualextra -viminfo -vreplace +wildignore -wildmenu +windows +writebackup -X11 -xfontset +xim -xsmp -xterm_clipboard -xterm_save system vimrc file: $VIM/vimrc user vimrc file: $HOME/.vimrc user exrc file: $HOME/.exrc system gvimrc file: $VIM/gvimrc user gvimrc file: $HOME/.gvimrc system menu file: $VIMRUNTIME/menu.vim fall-back for $VIM: /home/chrisbra/local/share/vim Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/inc lude/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g - DDEBUG -Wall -Wshadow -Wmissing-prototypes Linking: gcc -L/usr/local/lib -o vim -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lgio-2.0 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lm -lncurses -lselinux -lacl -lgpm DEBUG BUILD The error message is (sorry for the chaotic formating, but this was thrown to me like this): (process:30149): GLib-GObject-CRITICAL **: /build/buildd-glib2.0_2.24.0-1-i386-o5zIuQ/glib2.0-2.24.0/gobject/gtype.c:2706: You forgot to call g_type_init() (process:30149): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed (process:30149): GLib-GObject-CRITICAL **: /build/buildd-glib2.0_2.24.0-1-i386-o5zIuQ/glib2.0-2.24.0/gobject/gtype.c:2706: You forgot to call g_type_init() (process:30149): GLib-GObject-CRITICAL **: /build/buildd-glib2.0_2.24.0-1-i386-o5zIuQ/glib2.0-2.24.0/gobject/gtype.c:2706: You forgot to call g_type_init() (process:30149): GLib-GObject-CRITICAL **: /build/buildd-glib2.0_2.24.0-1-i386-o5zIuQ/glib2.0-2.24.0/gobject/gtype.c:2706: You forgot to call g_type_init() (process:30149): GLib-GObject-CRITICAL **: g_type_add_interface_static: assertion `G_TYPE_IS_INSTANTIATABLE (instance_type)' failed (process:30149): GLib-GObject-CRITICAL **: /build/buildd-glib2.0_2.24.0-1-i386-o5zIuQ/glib2.0-2.24.0/gobject/gtype.c:2706: You forgot to call g_type_init() (process:30149): GLib-GObject-CRITICAL **: g_type_add_interface_static: assertion `G_TYPE_IS_INSTANTIATABLE (instance_type)' failed (process:30149): GLib-GObject-CRITICAL **:
Re: Help unclear under +cmd
On 07/06/10 15:20, Andy Wokula wrote:
Am 06.06.2010 21:56, schrieb Tony Mechelynck:
Under :help +cmd in doc/editing.txt, I think something should be added
or changed to mention that +/pattern positions the cursor, not on the
*first* line matching /pattern/ (from the top of the file), but on the
*next* matching line after wherever the cursor ends up after (at least)
BufReadPost autocommands have been run (I haven't tested BufWinEnter,
but I happen to have a BufReadPost autocommand to recover the latest
known cursor position, see lines 77sqq. of vimrc_example.vim): if the
cursor was previously on the only line matching the pattern, I get a
search hit BOTTOM, continuing at TOP message (fleetingly, but recorded
in the message history); that message doesn't appear if I use +1/pattern
instead of just +/pattern .
You mean +0/pattern instead of +1/pattern, right?
I'd suggest to turn
+/{pat} Start at first line containing {pat}.
into
+0/{pat} Start at first line containing {pat}.
I used +1/pattern/ but the match wasn't on line 1. You're right, it
would skip anything on line 1. +0/pattern/ starts before line 1, so if
the match is on line 1 it finds it.
I suppose that +{num} +{pat} and +{num}/{pat} are only particular cases
of +{command}, since an ex-command consisting only of a range is a go
to line command, see the paragraph just below :help gg.
Best regards,
Tony.
--
I am an atheist, thank God!
--
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: Warning regarding use of %ld vs %lld
On 6 June 2010 18:23, Tony Mechelynck wrote: On 06/06/10 15:12, björn wrote: Hi, Lately I've been getting the following warning (on Mac OS X 10.6, 64 bit): fileio.c: In function ‘msg_add_lines’: fileio.c:5230: warning: format ‘%ld’ expects type ‘long int’, but argument 6 has type ‘off_t’ fileio.c:5247: warning: format ‘%ld’ expects type ‘long int’, but argument 5 has type ‘off_t’ Apparently, LONG_LONG_OFF_T is not getting defined which causes %ld to be used instead of %lld inside 'msg_add_lines'. If I define it (in vim.h) everything compiles fine. The relevant lines in vim.h are: #if defined(SIZEOF_OFF_T) (SIZEOF_OFF_T SIZEOF_LONG) # define LONG_LONG_OFF_T #endif On my system neither SIZEOF_OFF_T nor SIZEOF_LONG are defined (in auto/config.h). Not only that, I've checked and sizeof(off_t) = 8 sizeof(long) = 8 I guess we need some other heuristic as to when LONG_LONG_OFF_T should be defined, but I don't know which exactly. Does anybody else have any ideas? Björn In src/auto/config.log I see the following which ought to (and, on my system, do) give the right sizeof() values for long and off_t (and two others); Part of the problem is that the right values of long and off_t are the same (both 8) on my machine, so even if SIZEOF_OFF_T and SIZEOF_LONG were defined the test in vim.h would not define LONG_LONG_OFF_T as it should. maybe you should try a make reconfig? (and NOT run configure except through make because in some cases make may invoke configure itself, which would override any parameters you gave on the configure command-line -- see http://users.skynet.be/antoine.mechelynck/compunix.htm about setting configure arguments via environment variables given to make). No, it makes no difference. configure:11492: checking size of off_t configure:11497: gcc -o conftest -O2 -fno-strength-reduce -Wall -D_FORTIFY_SOURCE=1 -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L/usr/local/lib conftest.c -lm -lncurses -lnsl -lacl -lattr -lgpm 5 configure:11497: $? = 0 configure:11497: ./conftest configure:11497: $? = 0 configure:11512: result: 8 My config.log looks like this: configure:11865: checking for off_t configure:11895: gcc -c -O2 -fno-strength-reduce -Wall -DMACOS_X_UNIX -no-cpp-precomp conftest.c 5 configure:11901: $? = 0 configure:11916: result: yes It seems that it never even tries to figure out the proper size. This results in the following src/auto/config.h lines 37-51: /* Defined to the size of a long */ #define SIZEOF_LONG 4 /* Defined to the size of off_t */ #define SIZEOF_OFF_T 8 These two are always undefined for me. To conclude; there are two problems: (1) On Mac OS X 10.6 configure fails to check the size of long and off_t (I'm guessing I'm not the only person having this problem, but I don't know.) (2) On Mac OS X 10.6 sizeof(long) == sizeof(off_t) so the test in vim.h would never do anything even if (1) was ok. A new test is needed as to when LONG_LONG_OFF_T should be defined in vim.h. I guess this will need to be Mac OS X specific, but I don't know for sure hence my first post asking for advice. Björn -- 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: Warning regarding use of %ld vs %lld
On Sun, Jun 6, 2010 at 1:42 PM, björn bjorn.winck...@gmail.com wrote: On 6 June 2010 18:23, Tony Mechelynck wrote: [snip] Part of the problem is that the right values of long and off_t are the same (both 8) on my machine, so even if SIZEOF_OFF_T and SIZEOF_LONG were defined the test in vim.h would not define LONG_LONG_OFF_T as it should. That's not a problem. That's exactly as it should be. LONG_LONG_OFF_T is specifically for the case where off_t and long have different sizes. My config.log looks like this: configure:11865: checking for off_t configure:11895: gcc -c -O2 -fno-strength-reduce -Wall -DMACOS_X_UNIX -no-cpp-precomp conftest.c 5 configure:11901: $? = 0 configure:11916: result: yes It seems that it never even tries to figure out the proper size. That's the only occurence of off_t? The size checking is performed much later than checking for the existence of off_t. This results in the following src/auto/config.h lines 37-51: /* Defined to the size of a long */ #define SIZEOF_LONG 4 /* Defined to the size of off_t */ #define SIZEOF_OFF_T 8 These two are always undefined for me. To conclude; there are two problems: (1) On Mac OS X 10.6 configure fails to check the size of long and off_t (I'm guessing I'm not the only person having this problem, but I don't know.) It sounds like your configure script is not current. Either that or you're checking src/auto/config.h before the configure script has been run. src/auto/config.h is updated by the results of the configure script, so make sure you're checking it at the end of a build. (2) On Mac OS X 10.6 sizeof(long) == sizeof(off_t) so the test in vim.h would never do anything even if (1) was ok. A new test is needed as to when LONG_LONG_OFF_T should be defined in vim.h. I guess this will need to be Mac OS X specific, but I don't know for sure hence my first post asking for advice. The sole purpose of LONG_LONG_OFF_T is for systems where sizeof(long) != sizeof(off_t), since on those systems we can't simply print off_t as a long. Since you've shown that the sizes are the same on your system, and forcing use of %lld makes your compiler shut up, it looks like a bug in your compiler. -- 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
Re: Arbitrary tab stops
On Mon, Jun 7, 2010 at 16:07, Ingo Karkat sw...@ingo-karkat.de wrote: I haven't used it personally, but it surely sounds interesting. If some people try this out now and report back positive news, maybe Bram will still include it in 7.3 or at least consider it for the following release. My personal build of Vim has incorporated this patch for ages and it's really useful. I have not rebuilt it in a while, but my last status is that it applies, builds and helps. Richard -- 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: Suggest a Gvim 7.3 new look
Nico Io wrote: I am currently using Gvim 7.2 rebuild with this new toolbar. I think : 1. Gvim has to improve its visual interface to seduce new users. 1.a I suggest the toolbar in 48px size border mixed with the existing menu = Gvim takes a new look AND you can attach your new vimscript plugin to a visual icon 1.b In the futur, to enable a slide feature to this toolbar in order to permit to add dynamically more icons than the toolbar's width permit it. 2. Think that several existing Icon of current gvim 7.2 toolbar are obsolete meanwhile.meanwhile today everybody use usb key. so I think we have to develop some vimscript around this usb key. 2. a. Some script to store or retrieve data like vimfiles into/to usb key (see usb key icon), I have done a vimscript 2. b. To develop many features around managing _vimrc and vimfiles to usb key in order to be able to work everywhere with gvim. So, I can work for the community to add this new toolbar to Gvim 7.3 release if enough people agree with my thoughts. Thank you to see my jpg joined.Epanda.French. Gvim Evangelist Well, it looks nice, but it takes a lot of space. Vim users tend to be very practical. Quite a few people disable the toolbar. Perhaps we can use this for Easy Vim (evim)? usb key. Do you mean USB stick? Isn't that just another place to store files? If you mean you would like to store your Vim configuration in a way you can move it to other computers, that's indeed useful. But tricky to make work. Probably requires the user to put their Vim files in specific places. -- The CIA drives around in cars with the Intel inside logo. /// 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: Internal error: hash_add()
Peter Odding wrote:
Hi all. I wrote a Vim plug-in* that automatically keeps my global tags
file up-to-date by executing Exuberant Ctags from a CursorHold autocmd.
I've been happily using the plug-in for months now and today it started
throwing the following error which I've never seen before:
easytags.vim: Vim(let):E685: Internal error: hash_add() (at function
easytags#autoload..easytags#highlight_cmd, line 4)
When I looked up :help E685 I found the following:
This is an internal error. If you can reproduce it, please send in a
bug report.
The good news is that reproducing the E685 error is a matter of calling
taglist('.') using my tags file but the bad news is that the relevant
tags file contains 5810 lines (649K) of personal information (e.g.
extracts from several LaTeX documents) and I've never debugged Vim (nor
any other binary for that matter). I don't really mind providing the
tags file to someone who's willing to analyze this problem but I'm not
happy with posting the file on a public mailing list either :-)
Does anyone have suggestions?
Well, first save that tags file, generating it again may get rid of the
problem and we won't be able to reproduce it.
It's trange, hash tables are used a lot, it's unlikely that hash_add()
itself is wrong. Perhaps memory got corrupted somehow?
Can you reproduce the problem without loading scripts, just calling
taglist('.') before doing anything else?
I'm afraid that anonymyzing your tags file may make the problem go
away... Perhaps you can try :%s/[a-zA-Z]/x/g on it? Make a copy
first.
Ah! when I do this on the Vim source tags file I can actually reproduce
it! I'll put this in the todo list.
--
If Microsoft would build a car...
... You'd have to press the Start button to turn the engine off.
/// 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: Warning regarding use of %ld vs %lld
On 06/06/10 19:42, björn wrote: Sorry, your post just arrived; apparently it got held more than two days between the first two gmail servers on its way. On 6 June 2010 18:23, Tony Mechelynck wrote: On 06/06/10 15:12, björn wrote: Hi, Lately I've been getting the following warning (on Mac OS X 10.6, 64 bit): fileio.c: In function ‘msg_add_lines’: fileio.c:5230: warning: format ‘%ld’ expects type ‘long int’, but argument 6 has type ‘off_t’ fileio.c:5247: warning: format ‘%ld’ expects type ‘long int’, but argument 5 has type ‘off_t’ Apparently, LONG_LONG_OFF_T is not getting defined which causes %ld to be used instead of %lld inside 'msg_add_lines'. If I define it (in vim.h) everything compiles fine. The relevant lines in vim.h are: #if defined(SIZEOF_OFF_T)(SIZEOF_OFF_TSIZEOF_LONG) # define LONG_LONG_OFF_T #endif On my system neither SIZEOF_OFF_T nor SIZEOF_LONG are defined (in auto/config.h). Not only that, I've checked and sizeof(off_t) = 8 sizeof(long) = 8 I guess we need some other heuristic as to when LONG_LONG_OFF_T should be defined, but I don't know which exactly. Does anybody else have any ideas? Björn In src/auto/config.log I see the following which ought to (and, on my system, do) give the right sizeof() values for long and off_t (and two others); Part of the problem is that the right values of long and off_t are the same (both 8) on my machine, so even if SIZEOF_OFF_T and SIZEOF_LONG were defined the test in vim.h would not define LONG_LONG_OFF_T as it should. maybe you should try a make reconfig? (and NOT run configure except through make because in some cases make may invoke configure itself, which would override any parameters you gave on the configure command-line -- see http://users.skynet.be/antoine.mechelynck/compunix.htm about setting configure arguments via environment variables given to make). No, it makes no difference. configure:11492: checking size of off_t configure:11497: gcc -o conftest -O2 -fno-strength-reduce -Wall -D_FORTIFY_SOURCE=1 -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L/usr/local/lib conftest.c -lm -lncurses -lnsl -lacl -lattr -lgpm5 configure:11497: $? = 0 configure:11497: ./conftest configure:11497: $? = 0 configure:11512: result: 8 My config.log looks like this: configure:11865: checking for off_t configure:11895: gcc -c -O2 -fno-strength-reduce -Wall -DMACOS_X_UNIX -no-cpp-precomp conftest.c5 configure:11901: $? = 0 configure:11916: result: yes That's some 500 lines lower. Nothing near line 11492 of configure, just after it defines SIZEOF_INT ? Maybe you should rerun make autoconf, or make sure you have the right src/auto/configure ? Oh, and since May 15 15:04:53 2010 +0200 both Vim 7.2 and Vim 7.3a use autoconv 2.65 rather than 2.63, there was a changeset about that in both branches on the Mercurial repo. See also the comment at lines 1614-1632 of src/Makefile. Here's what I see at src/configure.in lines 2977-2980: AC_CHECK_SIZEOF([int]) AC_CHECK_SIZEOF([long]) AC_CHECK_SIZEOF([time_t]) AC_CHECK_SIZEOF([off_t]) It should generate similar checks in auto/configure for all four. It seems that it never even tries to figure out the proper size. This results in the following src/auto/config.h lines 37-51: /* Defined to the size of a long */ #define SIZEOF_LONG 4 /* Defined to the size of off_t */ #define SIZEOF_OFF_T 8 These two are always undefined for me. To conclude; there are two problems: (1) On Mac OS X 10.6 configure fails to check the size of long and off_t (I'm guessing I'm not the only person having this problem, but I don't know.) (2) On Mac OS X 10.6 sizeof(long) == sizeof(off_t) so the test in vim.h would never do anything even if (1) was ok. A new test is needed as to when LONG_LONG_OFF_T should be defined in vim.h. I guess this will need to be Mac OS X specific, but I don't know for sure hence my first post asking for advice. Do you mean on Mac Os X 10.6/64 a long int is shorter than a long ? Björn Best regards, Tony. -- APL is a mistake, carried through to perfection. It is the language of the future for the problems of the past: it creates a new generation of coding bums. -- 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: CTRL-L with incsearch, ignorecase and smartcase
On Mon, Jun 07, 2010 at 09:12:26AM -0700, Erik Wognsen wrote:
If there's already something upper case in the search pattern and the
new char is converted to lower case, the pattern will again stop
matching! Maybe the search pattern needs to be scanned for case
inside the if (p_ic p_scs) and only convert to lower case if the
search pattern is already only lower case (i.e. not triggering the
case sensitivity of 'smartcase')?
Yeah, I missed that case in my first attempt. Please see (and test) the
patch below.
It refactors some code out of search.c and adds the function
has_uppercase to misc1.c. In misc1.c it turns a return into a
Return in an unrelated comment because I was in that area of the file
anyway.
The diff is made using hg extdiff -p -o -rc as I know context diffs
are appreciated :-)
Martin
diff -rc vim.63157185aea5/runtime/doc/cmdline.txt vim/runtime/doc/cmdline.txt
*** vim.63157185aea5/runtime/doc/cmdline.txtTue Jun 8 23:33:29 2010
--- vim/runtime/doc/cmdline.txt Tue Jun 8 23:33:29 2010
***
*** 416,422
than the pattern, no completion is done.
When 'incsearch' is set, entering a search pattern for / or
? and the current match is displayed then CTRL-L will add
! one character from the end of the current match.
The 'wildchar' option defaults to Tab (CTRL-E when in Vi compatible mode; in
a previous version Esc was used). In the pattern standard wildcards '*' and
--- 416,425
than the pattern, no completion is done.
When 'incsearch' is set, entering a search pattern for / or
? and the current match is displayed then CTRL-L will add
! one character from the end of the current match. If
! 'ignorecase' and 'smartcase' are set and the command line has
! no uppercase characters, the added character is converted to
! lowercase.
The 'wildchar' option defaults to Tab (CTRL-E when in Vi compatible mode; in
a previous version Esc was used). In the pattern standard wildcards '*' and
diff -rc vim.63157185aea5/runtime/doc/options.txt vim/runtime/doc/options.txt
*** vim.63157185aea5/runtime/doc/options.txtTue Jun 8 23:33:29 2010
--- vim/runtime/doc/options.txt Tue Jun 8 23:33:29 2010
***
*** 3939,3945
The highlighting can be set with the 'i' flag in 'highlight'.
See also: 'hlsearch'.
CTRL-L can be used to add one character from after the current match
! to the command line.
CTRL-R CTRL-W can be used to add the word at the end of the current
match, excluding the characters that were already typed.
NOTE: This option is reset when 'compatible' is set.
--- 3939,3947
The highlighting can be set with the 'i' flag in 'highlight'.
See also: 'hlsearch'.
CTRL-L can be used to add one character from after the current match
! to the command line. If 'ignorecase' and 'smartcase' are set and the
! command line has no uppercase characters, the added character is
! converted to lowercase.
CTRL-R CTRL-W can be used to add the word at the end of the current
match, excluding the characters that were already typed.
NOTE: This option is reset when 'compatible' is set.
diff -rc vim.63157185aea5/src/ex_getln.c vim/src/ex_getln.c
*** vim.63157185aea5/src/ex_getln.c Tue Jun 8 23:33:29 2010
--- vim/src/ex_getln.c Tue Jun 8 23:33:29 2010
***
*** 1411,1416
--- 1411,1421
!equalpos(curwin-w_cursor, old_cursor))
{
c = gchar_cursor();
+ /* If 'ignorecase' and 'smartcase' are set and the
+ * command line has no uppercase characters, convert
+ * the character to lowercase */
+ if (p_ic p_scs !has_uppercase(ccline.cmdbuff))
+ c = MB_TOLOWER(c);
if (c != NUL)
{
if (c == firstc || vim_strchr((char_u *)(
diff -rc vim.63157185aea5/src/misc1.c vim/src/misc1.c
*** vim.63157185aea5/src/misc1.cTue Jun 8 23:33:29 2010
--- vim/src/misc1.c Tue Jun 8 23:33:29 2010
***
*** 9575,9581
}
/*
! * return TRUE when need to go to Insert mode because of 'insertmode'.
* Don't do this when still processing a command or a mapping.
* Don't do this when inside a :normal command.
*/
--- 9575,9581
}
/*
! * Return TRUE when need to go to Insert mode because of 'insertmode'.
* Don't do this when still processing a command or a mapping.
* Don't do this when inside a :normal command.
*/
***
*** 9583,9586
--- 9583,9632
goto_im()
{
return (p_im stuff_empty() typebuf_typed());
+ }
+
+ /*
+ * Return TRUE when pattern
Re: CTRL-L with incsearch, ignorecase and smartcase
On Tue, Jun 08, 2010 at 11:37:09PM +0200, Martin Toft wrote: The diff is made using hg extdiff -p -o -rc Make that hg extdiff -p diff -o -rc. -- 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: Internal error: hash_add()
On 08-Jun-2010 Bram Moolenaar b...@moolenaar.net wrote:
Well, first save that tags file, generating it again may get rid of the
problem and we won't be able to reproduce it.
It's trange, hash tables are used a lot, it's unlikely that hash_add()
itself is wrong. Perhaps memory got corrupted somehow?
Can you reproduce the problem without loading scripts, just calling
taglist('.') before doing anything else?
I'm afraid that anonymyzing your tags file may make the problem go
away... Perhaps you can try :%s/[a-zA-Z]/x/g on it? Make a copy
first.
Ah! when I do this on the Vim source tags file I can actually reproduce
it! I'll put this in the todo list.
I simplified the tags file to a single entry making the problem appear
(find the file attached).
I might be able to look at the problem tomorrow.
--
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
!_TAG_FILE_FORMAT 2 /extended format; --format=1 will not append ;
to lines/
!_TAG_FILE_SORTED 1 /0=unsorted, 1=sorted, 2=foldcase/
!_TAG_PROGRAM_AUTHORDarren Hiebert /dhieb...@users.sourceforge.net/
!_TAG_PROGRAM_NAME Exuberant Ctags //
!_TAG_PROGRAM_URL http://ctags.sourceforge.net/official site/
!_TAG_PROGRAM_VERSION 5.8 //
x_ ./xxx_xx.x /^x_,$/; x :__32
:
Re: Internal error: hash_add()
Bram Moolenaar wrote:
Well, first save that tags file, generating it again may get rid of the
problem and we won't be able to reproduce it.
I already put the buggy tags file in a TAR to be sure I wouldn't
accidentally modify it. And the problem did indeed go away after
modifying the tags file. The modification that solved the problem was
:g/\.tex\t/d so the problem was with one of the tags entries for a LaTeX
document, which are very long (e.g. paragraph length) and contain spaces
and other weird characters in the tag name field. I don't use tags in
LaTeX documents anyway so I've since disabled all tag generation for
*.tex files.
It's trange, hash tables are used a lot, it's unlikely that hash_add()
itself is wrong. Perhaps memory got corrupted somehow?
Can you reproduce the problem without loading scripts, just calling
taglist('.') before doing anything else?
Yes I tested that using the following command before sending the initial
message:
gvim -u NONE --noplugin -c ':set tags=~/.vimtags | call taglist(.)'
I'm afraid that anonymyzing your tags file may make the problem go
away... Perhaps you can try :%s/[a-zA-Z]/x/g on it? Make a copy
first.
Ah! when I do this on the Vim source tags file I can actually reproduce
it! I'll put this in the todo list.
Well that :substitute command replaces all extra flags in the tags file
as well. When I actually try it though, I get the same error message as
reported before, but now repeated a dozen times all over my screen :-)
Since you mentioned you can reproduce the problem (and I just saw a mail
by Lech Lorens stating the same) I guess there's no point in polluting
vim_dev with a 900K attachment.
Thanks for your work on Vim!
- Peter Odding
--
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
Automatic folding breaks completion menu?
Hi list,
I've been writing LaTeX for the last few hours and I have Vim configured
to use fold markers and automatically open/close folds as I move the
cursor. I mark each \section and \subsection in my LaTeX documents with
a trailing comment and fold marker, e.g.:
\subsection{Mediatheek opdracht} % {{{2
So that when I move the cursor outside of all folded text I get a nice
outline of the document which is really useful because LaTeX documents
tend to grow quite large. I typed the following line:
\subsC-xC-l
Expecting to get a completion menu listing all of the existing
subsections. What happens however is that Vim draws the menu and
completes the first matching line, sees the fold marker that was just
introduced in the buffer by completing the first match and folds the
text above the new fold marker, which causes the completion menu to close.
In effect this makes it impossible to use the completion menu to
complete whole lines containing fold markers when you also have Vim
configured to automatically open/close folds.
A seemingly simple workaround would be to disable all automatic text
folding while the completion menu is visible. Is this easy to implement
in Vim and do others agree this is a more sensible thing to do?
Thanks for your time,
- Peter Odding
--
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: Automatic folding breaks completion menu?
A seemingly simple workaround would be to disable all automatic text folding while the completion menu is visible. Is this easy to implement in Vim and do others agree this is a more sensible thing to do? To clarify: By disable I meant temporarily ignore changes to folding, not unfold all text and then start the completion because that would get very annoying very quickly :-) - Peter Odding -- 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.442
On Sun, Jun 6, 2010 at 4:26 PM, Bram Moolenaar wrote: James Vega wrote: On Sat, Jun 05, 2010 at 10:37:39PM +0200, Patrick Texier wrote: Le Sat, 05 Jun 2010 16:16:06 +0200, Bram Moolenaar a écrit dans le message 201006051416.o55eg6to002...@masaka.moolenaar.net : Patch 7.2.442 (after 7.2.201) Using Linux/GCC 3.2/GTK 1, I can't compile this patch. I think that gtk_selection_clear_targets is not available with GTK 1. It isn't and I don't see equivalent functionality in GTK 1's API. One possibility is to keep the old code for builds using GTK 1, which would resurface the buggy interaction with OpenOffice.org for anyone still building against GTK 1. Although, OpenOffice.org requires GTK 2, so you probably won't run into that problem. Personally, I'd prefer to remove all the GTK 1 code from Vim since GTK 1 isn't supported by its upstream anymore and has been deprecated for years. As it is, parts of Vim will need to be changed for compatibility with GTK 3 when that comes out, and supporting three different GTK versions just seems like overkill, in my opinion. gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk) You're using a Linux distribution that was released 8 years ago, a year and a half after the last release of GTK 1. I'm surprised this is the first new release of a piece of software that hasn't worked. What do others think about removing support for GTK 1? It makes sense, any system where you would try to build Vim 7.3 should be able to install GTK 2 libraries. It will clean up the Vim source code. I'm a fan of the idea. I work on systems with the Motif gvim and the GTK 2 gvim, but I don't think I've ever worked on a system with a GTK1 gvim. The number of #ifdef's in the GUI code is ridiculous, so I strongly support anything that will make life easier for Bram and other contributors. ~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
Re: Suggest a Gvim 7.3 new look
On 08/06/10 21:08, nico io wrote: Hi, Hi. I don't know why you're suddenly nico io after having been epanda — and neither name sounds authentic — but I don't mind. I think that your proposal is serious and, as a sign of respect from someone who doesn't share your opinions in this domain, I have taken the time to write a point-by-point rebuttal. Don't take it badly: I think there is room for argument, especially if other people join the debate. I am currently using Gvim 7.2 rebuild with this new toolbar. I think : 1. Gvim has to improve its visual interface to seduce new users. I don't think Vim is the kind of software which seduces new users by its pretty toolbars. What keeps Vim users faithful is sheer editing power (but it takes time for them to realize just how powerful Vim can be). I don't know what kinds of toolbars there are in XEmacs, but they could be as sexy as you like, they won't make me switch editors. In general I prefer no-nonsense looks with everything where I need it, to flashy stuff where half of what I need is missing or tucked away. Happily the gvim toolbar, in its present size, doesn't bother me too much so I keep it displayed even though I practically never use it, but if it played too much the game of the frog trying to be a bull, I would quickly add :set go-=T to my vimrc. 1.a I suggest the toolbar in 48px size border mixed with the existing menu = Gvim takes a new look AND you can attach your new vimscript plugin to a visual icon Like Bram, I think that a 48px high toolbar takes up a lot of space. IMHO 32px is a maximum, it might perhaps be possible to make do with 24. This said, if this new toolbar can be installed by the user _instead_ of the normal one without recompiling gvim, by adding some statement in the vimrc, then why not? But not as default. 1.b In the futur, to enable a slide feature to this toolbar in order to permit to add dynamically more icons than the toolbar's width permit it. The only reason you feel that this is necessary is because you've installed huge buttons. Yours take up about 80% of the width, mine about 66 or 70%, and it looks to me like there is room for many more buttons — if desired, which is not obvious. 2. Think that several existing Icon of current gvim 7.2 toolbar are obsolete meanwhile .meanwhile today everybody use usb key. so I think we have to develop some vimscript around this usb key. To Vim a USB key is just a place to store files, it is no different from a disk: in today's Unix language it's a filesystem, in the language I used 40 years ago on Honeywell mainframes it's a mass-storage device. Also, if USB drives are so hip, why are you displaying (obsolete) diskettes as the icons for your Save and Save all buttons? Probably because anyone will recognize that they are disks, which is not necessarily the case with a CD icon... 2. a. Some script to store or retrieve data like vimfiles into/to usb key (see usb key icon), I have done a vimscript No need for a script. Retrieve with :e foobar.baz, store with :w or :saveas bazbar.foo. Include paths as needed, or :cd to the USB drive beforehand. 2. b. To develop many features around managing _vimrc and vimfiles to usb key in order to be able to work everywhere with gvim. I think there is a project about that somewhere, to be able to use the same Vim setup on several computers, but it isn't obvious to make it work. You couldn't rasily take advantage of 64-bit processors if you have to keep compatibility with another computer's 32-bit one. And try as you will, a single executable won't work on any two of Windows, Linux and Mac, even if all three have the same Intel processor. Also, self-installers (as used on Windows) and .dmg disk image archives (as used on the Mac) have their advantages. So, I can work for the community to add this new toolbar to Gvim 7.3 release if enough people agree with my thoughts. Even though there are already a lot of improvements in gvim 7.3a compared to 7.2, it is still a minor release. There were much more important changes between 6 and 7, and yet (with the exception of a tab bar) the look of gvim didn't change at all. I think that if we want a radical change of gvim's look and feel, it would be for Vim 8 at the earliest. Unless, as I said, the present look can be kept as default, with the possibility to change it to yours by some command in the vimrc, or maybe in a colorscheme. Thank you to see my jpg joined. Epanda. French. Gvim Evangelist Finally, IIUC, builds of gvim for various OSes borrow their toolbar buttons from the corresponding GUI themes. My toolbar buttons come from Gnome, not from Bram (or rather, Bram wrote the source so that gvim for GTK2/Gnome2 GUI borrows its buttons from Gnome): for instance, the button Choose a Vim script to run for the Toolbar.RunScript menu is a smaller but exact copy of the cogwheels button on my Gnome taskbar,
