:redraw vs Ctrl-L difference
I noticed that :redraw works differently from Ctrl-L in certain situations: 1) vim -u NONE :set laststatus=2 statusline ruler :help help get some text 2) Let's cause some screen mispaininting, so we can test :redraw: :silent! !echo aaa cause mispainted screen (this is ok) 3) :redraw does not repaint anything :redraw :redraw nope, does not repaint 4) Ctrl-L finally, works Is it bug or feature, that :redraw does not repaint screen at step 3 ? Yakov
Small question about the popup menu
Hi, In the vim documentation, there is a note about a possibility to display an icon thanks to the kind information of a popup item (:h complete-items) : The kind item uses a single letter to indicate the kind of completion. This may be used to show the completion differently (different color or icon). Is it possible to do this in the current version of Vim or is there a dev plan to implement a gui popup for the futur ? Thanks in advance, Best regards, -- Vissale Live For Speed Racer - http://www.liveforspeed.net
Re: :redraw vs Ctrl-L difference
Yakov Lerner wrote: I noticed that :redraw works differently from Ctrl-L in certain situations: 1) vim -u NONE :set laststatus=2 statusline ruler :help help get some text 2) Let's cause some screen mispaininting, so we can test :redraw: :silent! !echo aaa cause mispainted screen (this is ok) 3) :redraw does not repaint anything :redraw :redraw nope, does not repaint 4) Ctrl-L finally, works Is it bug or feature, that :redraw does not repaint screen at step 3 ? Yakov works for me in the GUI: I don't see any change in the display after :silent! !echo aaa. I'm using gvim 7.0.101, huge build with GTK2-GNOME GUI, running on SuSE Linux 7.3. Using the same build in console mode in a konsole window, :silent! !echo aaa makes the whole help text disappear, :redraw, entered manually, doesn't make it reappear, ^L does. Still with the same build but on the non-X linux text display, :silent! !echo aaa changes 'lines' from 47 to 64, making the bottom lines and the command-line disappear at the bottom of the screen. The help text doesn't disappear and I see a flicker which seems to indicate a spontaneous redraw. :redraw and ^L both repeat the flicker, but only :set lines=47 brings my command-line area back into view. Best regards, Tony.
Patch 7.0.102
Patch 7.0.102
Problem:Redrawing cmdline is not correct when using SCIM.
Solution: Don't call im_get_status(). (Yukihiro Nakadaira)
Files: src/ex_getln.c
*** ../vim-7.0.101/src/ex_getln.c Sun Sep 10 21:05:39 2006
--- src/ex_getln.c Tue Sep 12 20:52:51 2006
***
*** 2363,2369
{
if ((State CMDLINE)
xic != NULL
!im_get_status()
!p_imdisable
im_is_preediting())
{
--- 2363,2369
{
if ((State CMDLINE)
xic != NULL
! /* im_get_status() doesn't work when using SCIM */
!p_imdisable
im_is_preediting())
{
*** ../vim-7.0.101/src/version.cTue Sep 12 22:24:48 2006
--- src/version.c Thu Sep 14 10:23:45 2006
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 102,
/**/
--
TIM: That is not an ordinary rabbit ... 'tis the most foul cruel and
bad-tempered thing you ever set eyes on.
ROBIN: You tit. I soiled my armour I was so scared!
Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
/// 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///
Patch 7.0.104
Patch 7.0.104
Problem:The CursorHoldI event only triggers once in Insert mode. It also
triggers after CTRL-V and other two-key commands.
Solution: Set did_cursorhold before getting a second key. Reset
did_cursorhold after handling a command.
Files: src/edit.c, src/fileio.c
*** ../vim-7.0.103/src/edit.c Tue Aug 29 18:36:55 2006
--- src/edit.c Tue Sep 12 21:12:10 2006
***
*** 707,712
--- 707,717
lastc = c; /* remember previous char for CTRL-D */
c = safe_vgetc();
+ #ifdef FEAT_AUTOCMD
+ /* Don't want K_CURSORHOLD for the second key, e.g., after CTRL-V. */
+ did_cursorhold = TRUE;
+ #endif
+
#ifdef FEAT_RIGHTLEFT
if (p_hkmap KeyTyped)
c = hkmap(c); /* Hebrew mode mapping */
***
*** 1388,1393
--- 1393,1404
#endif
break;
} /* end of switch (c) */
+
+ #ifdef FEAT_AUTOCMD
+ /* If typed something may trigger CursorHoldI again. */
+ if (c != K_CURSORHOLD)
+ did_cursorhold = FALSE;
+ #endif
/* If the cursor was moved we didn't just insert a space */
if (arrow_used)
*** ../vim-7.0.103/src/fileio.c Sat Sep 9 14:51:43 2006
--- src/fileio.cTue Sep 12 20:58:55 2006
***
*** 8289,8295
{
int state;
! if (!did_cursorhold has_cursorhold() !Recording)
{
state = get_real_state();
if (state == NORMAL_BUSY || (state INSERT) != 0)
--- 8289,8299
{
int state;
! if (!did_cursorhold has_cursorhold() !Recording
! #ifdef FEAT_INS_EXPAND
!!ins_compl_active()
! #endif
! )
{
state = get_real_state();
if (state == NORMAL_BUSY || (state INSERT) != 0)
*** ../vim-7.0.103/src/version.cThu Sep 14 10:48:00 2006
--- src/version.c Thu Sep 14 11:05:33 2006
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 104,
/**/
--
A hamburger walks into a bar, and the bartender says: I'm sorry,
but we don't serve food here.
/// 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///
Patch 7.0.105
Patch 7.0.105
Problem:When using incremental search the statusline ruler isn't updated.
(Christoph Koegl)
Solution: Update the statusline when it contains the ruler.
Files: src/ex_getln.c
*** ../vim-7.0.104/src/ex_getln.c Thu Sep 14 10:25:34 2006
--- src/ex_getln.c Thu Sep 14 10:42:24 2006
***
*** 1756,1761
--- 1756,1766
end_pos = curwin-w_cursor; /* shutup gcc 4 */
validate_cursor();
+ # ifdef FEAT_WINDOWS
+ /* May redraw the status line to show the cursor position. */
+ if (p_ru curwin-w_status_height 0)
+ curwin-w_redr_status = TRUE;
+ # endif
save_cmdline(save_ccline);
update_screen(SOME_VALID);
*** ../vim-7.0.104/src/version.cThu Sep 14 11:07:08 2006
--- src/version.c Thu Sep 14 11:25:37 2006
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 105,
/**/
--
An indication you must be a manager:
You feel sorry for Dilbert's boss.
/// 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///
Re: Tags break when enabling large file support
Haakon Riiser wrote: After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything involving tags break, including the help system. Typing :h, or pressing ^] to jump to a tag, causes Vim to get caught in an infinite loop. Is there another way to get large file support that works? There's no ./configure argument to enable it, so I just added the above macro definition flag in CFLAGS. The problem with not having large file support is not that I need to edit files larger than 2 GiB, but that ^X^F doesn't expand large files, probably because stat() fails with EOVERFLOW. By the way, this problem was encountered on the following system: OS: Slackware Linux 10.2 Libc: 2.3.5 GCC: several versions: 3.3.6, 3.4.6, 4.1.1 Vim: several versions, including 7.0.0 and 7.0.101 I'm using gvim (currently 7.0.101 but soon I'll compile the recently-published patches) and, without any compiler defines other than those set by configure according to the configure flags shown on my howto page http://users.skynet.be/antoine.mechelynck/vim/compunix.htm I'm currently editing a file with 1,118,641 lines and 33,705,005 bytes of data (and growing). No probs with accessing the help in that same instance of gvim. Of course there's still some margin between 33 Meg and 2 G. I'm on SuSE Linux 9.3 with gcc 3.3.5 20050117 (prerelease) (SuSE Linux) and glibc 2.3.4. -D_FILE_OFFSET_BITS=64 is set on my gcc command-line without me having done anything special to get it. Best regards, Tony. P.S. :version VIM - Vi IMproved 7.0 (2006 May 7, compiled Sep 13 2006 00:24:04) Included patches: 1-101 Compiled by [EMAIL PROTECTED] Huge version with GTK2-GNOME GUI. Features included (+) or not (-): +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +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_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra +perl +postscript +printer +profile +python +quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent -sniff +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_interact +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: /usr/local/share/vim Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/opt/gnome/include/gtk-2.0 -I/opt/gnome/lib/gtk-2.0/include -I/usr/X11R6/include -I/opt/gnome/include/atk-1.0 -I/opt/gnome/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include -DORBIT2=1 -pthread -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/libart-2.0 -I/usr/include/libxml2 -I/opt/gnome/include/libgnomeui-2.0 -I/opt/gnome/include/libgnome-2.0 -I/opt/gnome/include/libgnomecanvas-2.0 -I/opt/gnome/include/gtk-2.0 -I/opt/gnome/include/gconf/2 -I/opt/gnome/include/libbonoboui-2.0 -I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include -I/opt/gnome/include/orbit-2.0 -I/opt/gnome/include/libbonobo-2.0 -I/opt/gnome/include/gnome-vfs-2.0 -I/opt/gnome/lib/gnome-vfs-2.0/include -I/opt/gnome/include/bonobo-activation-2.0 -I/opt/gnome/include/pango-1.0 -I/usr/include/freetype2 -I/opt/gnome/lib/gtk-2.0/include -I/usr/X11R6/include -I/opt/gnome/include/atk-1.0 -I/usr/include/freetype2/config -O2 -fno-strength-reduce -Wall -I/usr/X11R6/include -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/lib/perl5/5.8.6/i586-linux-thread-multi/CORE -I/usr/include/python2.4 -pthread -I/usr/include -D_LARGEFILE64_SOURCE=1 -I/usr/lib/ruby/1.8/i686-linux Linking: gcc -L/opt/gnome/lib -L/usr/X11R6/lib -rdynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.6/i586-linux-thread-multi/CORE -L/usr/local/lib -o vim -L/opt/gnome/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -L/opt/gnome/lib -L/usr/X11R6/lib -lgnomeui-2 -lbonoboui-2 -lxml2 -lz -lgnomecanvas-2 -lgnome-2 -lpopt -lart_lgpl_2 -lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
Re: Tags break when enabling large file support
On 9/14/06, Haakon Riiser [EMAIL PROTECTED] wrote:
After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything
involving tags break, including the help system. Typing :h,
or pressing ^] to jump to a tag, causes Vim to get caught in an
infinite loop.
Is there another way to get large file support that works?
There's no ./configure argument to enable it, so I just added
the above macro definition flag in CFLAGS. The problem with
not having large file support is not that I need to edit files
larger than 2 GiB, but that ^X^F doesn't expand large files,
probably because stat() fails with EOVERFLOW.
By the way, this problem was encountered on the following system:
OS: Slackware Linux 10.2
Libc: 2.3.5
GCC: several versions: 3.3.6, 3.4.6, 4.1.1
Vim: several versions, including 7.0.0 and 7.0.101
I also get infinite loop when I build vim with -D_FILE_OFFSET_BITS=64
on FedoraCode 3.
Applying 'strace -p' shows that vim is stuck searching for
tag, see the trace below. Apparently some read() in vim
does not have check for == 0 return value.
Yakov
[ here vim searches for tags in other file ... then ...]
open(/home/lerner/.vim/doc/tags, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2506, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7fbf000
read(3, :Brightness\txterm16.txt\t/*:Brigh..., 4096) = 2506
_llseek(3, 0, [2506], SEEK_END) = 0
_llseek(3, 0, [0], SEEK_SET)= 0
_llseek(3, 0, [0], SEEK_SET)= 0
read(3, :Brightness\txterm16.txt\t/*:Brigh..., 4096) = 2506
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
infinite .
Re: :redraw vs Ctrl-L difference
Yakov Lerner wrote: I noticed that :redraw works differently from Ctrl-L in certain situations: 1) vim -u NONE :set laststatus=2 statusline ruler :help help get some text 2) Let's cause some screen mispaininting, so we can test :redraw: :silent! !echo aaa cause mispainted screen (this is ok) 3) :redraw does not repaint anything :redraw :redraw nope, does not repaint 4) Ctrl-L finally, works Is it bug or feature, that :redraw does not repaint screen at step 3 ? If you messed up the screen in a way that Vim doesn't know about it, such as with an external command, you need to use :redraw!. - Bram -- An indication you must be a manager: You believe you never have any problems in your life, just issues and improvement opportunities. /// 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///
Re: Tags break when enabling large file support
Yakov Lerner wrote:
On 9/14/06, Haakon Riiser [EMAIL PROTECTED] wrote:
After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything
involving tags break, including the help system. Typing :h,
or pressing ^] to jump to a tag, causes Vim to get caught in an
infinite loop.
Is there another way to get large file support that works?
There's no ./configure argument to enable it, so I just added
the above macro definition flag in CFLAGS. The problem with
not having large file support is not that I need to edit files
larger than 2 GiB, but that ^X^F doesn't expand large files,
probably because stat() fails with EOVERFLOW.
By the way, this problem was encountered on the following system:
OS: Slackware Linux 10.2
Libc: 2.3.5
GCC: several versions: 3.3.6, 3.4.6, 4.1.1
Vim: several versions, including 7.0.0 and 7.0.101
I also get infinite loop when I build vim with -D_FILE_OFFSET_BITS=64
on FedoraCode 3.
Applying 'strace -p' shows that vim is stuck searching for
tag, see the trace below. Apparently some read() in vim
does not have check for == 0 return value.
Yakov
[ here vim searches for tags in other file ... then ...]
open(/home/lerner/.vim/doc/tags, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2506, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7fbf000
read(3, :Brightness\txterm16.txt\t/*:Brigh..., 4096) = 2506
_llseek(3, 0, [2506], SEEK_END) = 0
_llseek(3, 0, [0], SEEK_SET)= 0
_llseek(3, 0, [0], SEEK_SET)= 0
read(3, :Brightness\txterm16.txt\t/*:Brigh..., 4096) = 2506
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
infinite .
Can you find out where in the code this happens?
I suspect the 64 bit library functions work different from the normal
functions. Perhaps fgets(), since that's what is being used to read the
tags file.
--
Lose weight, NEVER Diet again with
The Invisible Weight Loss Patch
(spam 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///
Patch 7.0.106
Patch 7.0.106
Problem:The spell popup menu uses :amenu, triggering mappings. Other
PopupMenu autocommands are removed. (John Little)
Solution: Use :anoremenu and use an autocmd group.
Files: runtime/menu.vim
*** ../vim-7.0.105/runtime/menu.vim Tue Apr 18 00:06:31 2006
--- runtime/menu.vimThu Sep 14 13:14:25 2006
***
*** 2,8
You can also use this as a start for your own set of menus.
Maintainer: Bram Moolenaar [EMAIL PROTECTED]
! Last Change:2006 Apr 17
Note that :an (short for :anoremenu) is often used to make a menu work
in all modes and avoid side effects from mappings defined by the user.
--- 2,8
You can also use this as a start for your own set of menus.
Maintainer: Bram Moolenaar [EMAIL PROTECTED]
! Last Change:2006 Sep 14
Note that :an (short for :anoremenu) is often used to make a menu work
in all modes and avoid side effects from mappings defined by the user.
***
*** 885,890
--- 885,892
if exists(s:changeitem) s:changeitem != ''
call SIDSpellDel()
endif
+
+ Return quickly if spell checking is not enabled.
if !spell || spelllang == ''
return
endif
***
*** 908,925
let s:fromword = w
let pri = 1
for sug in s:suglist
! exe 'amenu 1.5.' . pri . ' PopUp.' . s:changeitem . '.' . escape(sug,
' .')
\ . ' :call SIDSpellReplace(' . pri . ')CR'
let pri += 1
endfor
let s:additem = 'add\ ' . escape(w, ' .') . '\ to\ word\ list'
! exe 'amenu 1.6 PopUp.' . s:additem . ' :spellgood ' . w . 'CR'
let s:ignoreitem = 'ignore\ ' . escape(w, ' .') . ''
! exe 'amenu 1.7 PopUp.' . s:ignoreitem . ' :spellgood! ' . w . 'CR'
! amenu 1.8 PopUp.-SpellSep- :
endif
endif
endfunc
--- 910,927
let s:fromword = w
let pri = 1
for sug in s:suglist
! exe 'anoremenu 1.5.' . pri . ' PopUp.' . s:changeitem . '.' .
escape(sug, ' .')
\ . ' :call SIDSpellReplace(' . pri . ')CR'
let pri += 1
endfor
let s:additem = 'add\ ' . escape(w, ' .') . '\ to\ word\ list'
! exe 'anoremenu 1.6 PopUp.' . s:additem . ' :spellgood ' . w . 'CR'
let s:ignoreitem = 'ignore\ ' . escape(w, ' .') . ''
! exe 'anoremenu 1.7 PopUp.' . s:ignoreitem . ' :spellgood! ' . w . 'CR'
! anoremenu 1.8 PopUp.-SpellSep- :
endif
endif
endfunc
***
*** 938,944
let s:changeitem = ''
endfun
! au! MenuPopup * call SIDSpellPopup()
endif
The GUI toolbar (for MS-Windows and GTK)
--- 940,948
let s:changeitem = ''
endfun
! augroup SpellPopupMenu
! au! MenuPopup * call SIDSpellPopup()
! augroup END
endif
The GUI toolbar (for MS-Windows and GTK)
***
*** 1013,1021
tmenu ToolBar.FindPrevFind Previous
tmenu ToolBar.Replace Find / Replace...
endif
! tmenu ToolBar.LoadSesn Chose a session to load
tmenu ToolBar.SaveSesn Save current session
! tmenu ToolBar.RunScript Chose a Vim Script to run
tmenu ToolBar.Make Make current project (:make)
tmenu ToolBar.RunCtags Build tags in current directory tree (!ctags -R
.)
tmenu ToolBar.TagJump Jump to tag under cursor
--- 1017,1025
tmenu ToolBar.FindPrevFind Previous
tmenu ToolBar.Replace Find / Replace...
endif
! tmenu ToolBar.LoadSesn Choose a session to load
tmenu ToolBar.SaveSesn Save current session
! tmenu ToolBar.RunScript Choose a Vim Script to run
tmenu ToolBar.Make Make current project (:make)
tmenu ToolBar.RunCtags Build tags in current directory tree (!ctags -R
.)
tmenu ToolBar.TagJump Jump to tag under cursor
*** ../vim-7.0.105/src/version.cThu Sep 14 11:27:12 2006
--- src/version.c Thu Sep 14 13:24:44 2006
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 106,
/**/
--
BROTHER MAYNARD: Armaments Chapter Two Verses Nine to Twenty One.
ANOTHER MONK:And St. Attila raised his hand grenade up on high saying O
Lord bless this thy hand grenade that with it thou mayest
blow thine enemies to tiny bits, in thy mercy. and the Lord
did grin and people did feast upon the lambs and sloths and
carp and anchovies and orang-utans and breakfast cereals and
fruit bats and...
BROTHER MAYNARD: Skip a bit brother ...
Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build
Re: Tags break when enabling large file support
On 9/14/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
Yakov Lerner wrote:
On 9/14/06, Haakon Riiser [EMAIL PROTECTED] wrote:
After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything
involving tags break, including the help system. Typing :h,
or pressing ^] to jump to a tag, causes Vim to get caught in an
infinite loop.
Is there another way to get large file support that works?
There's no ./configure argument to enable it, so I just added
the above macro definition flag in CFLAGS. The problem with
not having large file support is not that I need to edit files
larger than 2 GiB, but that ^X^F doesn't expand large files,
probably because stat() fails with EOVERFLOW.
By the way, this problem was encountered on the following system:
OS: Slackware Linux 10.2
Libc: 2.3.5
GCC: several versions: 3.3.6, 3.4.6, 4.1.1
Vim: several versions, including 7.0.0 and 7.0.101
I also get infinite loop when I build vim with -D_FILE_OFFSET_BITS=64
on FedoraCode 3.
Applying 'strace -p' shows that vim is stuck searching for
tag, see the trace below. Apparently some read() in vim
does not have check for == 0 return value.
Yakov
[ here vim searches for tags in other file ... then ...]
open(/home/lerner/.vim/doc/tags, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2506, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7fbf000
read(3, :Brightness\txterm16.txt\t/*:Brigh..., 4096) = 2506
_llseek(3, 0, [2506], SEEK_END) = 0
_llseek(3, 0, [0], SEEK_SET)= 0
_llseek(3, 0, [0], SEEK_SET)= 0
read(3, :Brightness\txterm16.txt\t/*:Brigh..., 4096) = 2506
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
read(3, , 4096) = 0
infinite .
Can you find out where in the code this happens?
I suspect the 64 bit library functions work different from the normal
functions. Perhaps fgets(), since that's what is being used to read the
tags file.
In situation where fgets() returns NULL, find_tags() enters
infinite loop as follows.
(gdb) where
#0 0xe410 in ?? ()
#1 0xbff7bab0 in ?? ()
#2 0x0015 in ?? ()
#3 0xb7f7b000 in ?? ()
#4 0x00235573 in __write_nocancel () from /lib/tls/libc.so.6
#5 0x001dc57f in _IO_new_file_write () from /lib/tls/libc.so.6
#6 0x001db02b in _IO_new_do_write () from /lib/tls/libc.so.6
#7 0x001dba70 in _IO_new_file_overflow () from /lib/tls/libc.so.6
#8 0x001dd1ca in __overflow () from /lib/tls/libc.so.6
#9 0x001d351f in puts () from /lib/tls/libc.so.6
#10 0x080c2bcc in vim_fgets (
buf=0x8244a78
xterm16fg_GroupName\txterm16.txt\t/*xterm16fg_GroupName*\n,
size=512,
fp=0x827c1f8) at fileio.c:5853
#11 0x08177494 in find_tags (pat=0x8244568 [EMAIL PROTECTED],
num_matches=0x14, matchesp=0x14, flags=40,
mincount=1, buf_ffname=0x0) at tag.c:1625
#12 0x08178b35 in do_tag (tag=0x81f1168 [EMAIL PROTECTED], type=1, count=1,
forceit=0, verbose=1)
at tag.c:548
#13 0x080a3b08 in ex_help (eap=0x827d1b0) at ex_cmds.c:5519
#14 0x080b1e72 in do_one_cmd (cmdlinep=0xbff7ce08, sourcing=0,
cstack=0xbff7ce80,
fgetline=0x80c1828 getexline, cookie=0x0) at ex_docmd.c:2616
#15 0x080b3082 in do_cmdline (cmdline=0x0, getline=0x80c1828
getexline, cookie=0x0, flags=0)
at ex_docmd.c:1098
#16 0x08113620 in nv_colon (cap=0xbff7d220) at normal.c:5150
#17 0x08116d2f in normal_cmd (oap=0xbff7d290, toplevel=1) at normal.c:1137
#18 0x080decee in main_loop (cmdwin=0, noexmode=0) at main.c:1154
#19 0x080e2077 in main (argc=20, argv=0x14) at main.c:934
(gdb) b tag.c:1626
Breakpoint 1 at 0x8177494: file tag.c, line 1626.
(gdb) cont
Continuing.
Breakpoint 1, find_tags (pat=0x8244568 [EMAIL PROTECTED], num_matches=0x1,
matchesp=0x1, flags=40,
mincount=1, buf_ffname=0x0) at tag.c:1626
1626if (!eof search_info.curr_offset != 0)
(gdb) n
1625eof = tag_fgets(lbuf, LSIZE, fp);
(gdb) n
1626if (!eof search_info.curr_offset != 0)
(gdb) n
1651search_info.match_offset = ftell(fp);
(gdb) n
1650state = TS_SKIP_BACK;
(gdb) n
1651search_info.match_offset = ftell(fp);
(gdb) n
1652search_info.curr_offset =
search_info.curr_offset_used;
(gdb) n
1860continue;
(gdb) n
1652search_info.curr_offset =
search_info.curr_offset_used;
(gdb) n
1562line_breakcheck(); /* check for CTRL-C typed */
(gdb) n
1564if ((flags TAG_INS_COMP)) /* Double brackets for gcc */
(gdb) n
1566if (got_int || compl_interrupted)
(gdb) n
1576if (mincount == TAG_MANY match_count = TAG_MANY)
(gdb) n
1582if (get_it_again)
(gdb) n
1588if
Re: Tags break when enabling large file support
Yakov Lerner wrote: On 9/14/06, Haakon Riiser [EMAIL PROTECTED] wrote: After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything involving tags break, including the help system. Typing :h, or pressing ^] to jump to a tag, causes Vim to get caught in an infinite loop. [...] Can you find out where in the code this happens? I suspect the 64 bit library functions work different from the normal functions. Perhaps fgets(), since that's what is being used to read the tags file. In situation where fgets() returns NULL, find_tags() enters infinite loop as follows. Sorry, this doesn't show me where the loop actually is. Please compile without the optimizer, otherwise code reordering confuses the debugger. At least tell us if Vim hangs in tag_fgets() or in find_tags(). If it's in tag_fgets() it's probably a bug in the library. If it's in find_tags() then please try to find out why using 64 bit support makes a difference. -- MONK: ... and the Lord spake, saying, First shalt thou take out the Holy Pin, then shalt thou count to three, no more, no less. Three shalt be the number thou shalt count, and the number of the counting shalt be three. Four shalt thou not count, neither count thou two, excepting that thou then proceed to three. Five is right out. Once the number three, being the third number, be reached, then lobbest thou thy Holy Hand Grenade of Antioch towards thou foe, who being naughty in my sight, shall snuff it. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// 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///
Re: Tags break when enabling large file support
On 9/14/06, Yakov Lerner [EMAIL PROTECTED] wrote:
On 9/14/06, Yakov Lerner [EMAIL PROTECTED] wrote:
On 9/14/06, Yakov Lerner [EMAIL PROTECTED] wrote:
On 9/14/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
Yakov Lerner wrote:
On 9/14/06, Haakon Riiser [EMAIL PROTECTED] wrote:
After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything
involving tags break, including the help system. Typing :h,
or pressing ^] to jump to a tag, causes Vim to get caught in an
infinite loop.
[...]
Can you find out where in the code this happens?
I suspect the 64 bit library functions work different from the
normal
functions. Perhaps fgets(), since that's what is being used to read
the
tags file.
In situation where fgets() returns NULL, find_tags() enters
infinite loop as follows.
Sorry, this doesn't show me where the loop actually is. Please compile
without the optimizer, otherwise code reordering confuses the debugger.
At least tell us if Vim hangs in tag_fgets() or in find_tags().
The loop is is inside find_tags(), and it procees around following line
numbers:
1625 1626 1642 1647 1650 1651 1652 1653 1562 1564 1566
1576 1582 1588 1601 1603 1604 1616 1619 1621 1625
and infinite loop repeats. Look at this:
gdb print print search_info.curr_offset
$2 = 5258708303049
And additionally:
(gdb) print search_info
$3 = {low_offset = 0, high_offset = 10526964844947, curr_offset =
5258708303049,
curr_offset_used = 5258708303049, match_offset = 10763188046282,
low_char = 0, high_char = 120}
But ftell(fp) prints sane value:
(gdb) print ftell(fp)
$4 = 2506
And filesize is OK, 2506
Yakov
Re: Tags break when enabling large file support
On 9/14/06, Yakov Lerner [EMAIL PROTECTED] wrote: On 9/14/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Yakov Lerner wrote: On 9/14/06, Haakon Riiser [EMAIL PROTECTED] wrote: After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything involving tags break, including the help system. Typing :h, or pressing ^] to jump to a tag, causes Vim to get caught in an infinite loop. [...] Can you find out where in the code this happens? I suspect the 64 bit library functions work different from the normal functions. Perhaps fgets(), since that's what is being used to read the tags file. In situation where fgets() returns NULL, find_tags() enters infinite loop as follows. Sorry, this doesn't show me where the loop actually is. Please compile without the optimizer, otherwise code reordering confuses the debugger. At least tell us if Vim hangs in tag_fgets() or in find_tags(). The loop is is inside find_tags(), and it procees around following line numbers: 1625 1626 1642 1647 1650 1651 1652 1653 1562 1564 1566 1576 1582 1588 1601 1603 1604 1616 1619 1621 1625 and infinite loop repeats. Look at this: gdb print print search_info.curr_offset $2 = 5258708303049 I cannot guess where this loop first gets beyond end of file (filesize=2506), but once it gets beyond, we are missing check that search_info.*offset''s are beyond end of file ? Maybe add such check somewhere ? I don't know where to add the check. Yakov
Re: Tags break when enabling large file support
On 9/14/06, Yakov Lerner [EMAIL PROTECTED] wrote: On 9/14/06, Yakov Lerner [EMAIL PROTECTED] wrote: On 9/14/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Yakov Lerner wrote: On 9/14/06, Haakon Riiser [EMAIL PROTECTED] wrote: After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything involving tags break, including the help system. Typing :h, or pressing ^] to jump to a tag, causes Vim to get caught in an infinite loop. [...] Can you find out where in the code this happens? I suspect the 64 bit library functions work different from the normal functions. Perhaps fgets(), since that's what is being used to read the tags file. In situation where fgets() returns NULL, find_tags() enters infinite loop as follows. Sorry, this doesn't show me where the loop actually is. Please compile without the optimizer, otherwise code reordering confuses the debugger. At least tell us if Vim hangs in tag_fgets() or in find_tags(). The loop is is inside find_tags(), and it procees around following line numbers: 1625 1626 1642 1647 1650 1651 1652 1653 1562 1564 1566 1576 1582 1588 1601 1603 1604 1616 1619 1621 1625 and infinite loop repeats. Look at this: gdb print print search_info.curr_offset $2 = 5258708303049 I cannot guess where this loop first gets beyond end of file (filesize=2506), but once it gets beyond, we are missing check that search_info.*offset''s are beyond end of file ? Maybe add such check somewhere ? I don't know where to add the check. Yakov It seems I found the culprint. It is line 1651, search_info.match_offset = ftell(fp); (gdb) p ftell(fp) $11 = 2506 (gdb) n 1652search_info.curr_offset = search_info.curr_offset_used; (gdb) p search_info.curr_offset $12 = 5258708302025 (gdb) Yakov
Re: Tags break when enabling large file support
On 9/14/06, Yakov Lerner [EMAIL PROTECTED] wrote: On 9/14/06, Yakov Lerner [EMAIL PROTECTED] wrote: On 9/14/06, Yakov Lerner [EMAIL PROTECTED] wrote: On 9/14/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Yakov Lerner wrote: On 9/14/06, Haakon Riiser [EMAIL PROTECTED] wrote: After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything involving tags break, including the help system. Typing :h, or pressing ^] to jump to a tag, causes Vim to get caught in an infinite loop. [...] Can you find out where in the code this happens? I suspect the 64 bit library functions work different from the normal functions. Perhaps fgets(), since that's what is being used to read the tags file. In situation where fgets() returns NULL, find_tags() enters infinite loop as follows. Sorry, this doesn't show me where the loop actually is. Please compile without the optimizer, otherwise code reordering confuses the debugger. At least tell us if Vim hangs in tag_fgets() or in find_tags(). The loop is is inside find_tags(), and it procees around following line numbers: 1625 1626 1642 1647 1650 1651 1652 1653 1562 1564 1566 1576 1582 1588 1601 1603 1604 1616 1619 1621 1625 and infinite loop repeats. Look at this: gdb print print search_info.curr_offset $2 = 5258708303049 I cannot guess where this loop first gets beyond end of file (filesize=2506), but once it gets beyond, we are missing check that search_info.*offset''s are beyond end of file ? Maybe add such check somewhere ? I don't know where to add the check. Yakov It seems I found the culprint. It is line 1651, search_info.match_offset = ftell(fp); (gdb) p ftell(fp) $11 = 2506 (gdb) n 1652search_info.curr_offset = search_info.curr_offset_used; (gdb) p search_info.curr_offset $12 = 5258708302025 (gdb) Ok, this must be gcc bug. It bites even without optimization. Rewriting lines 'search_info.curr_offset = ftell(fp)' fixes the problem if I rewrite them into this: long ltmp; ltmp = ftell(fp); search_info.curr_offset = ltmp; NB that ftell() returns long. Type of search_info.curr_offset is long long when -D_FILE_OFFSET_BITS=64. Simpe asignment search_info.curr_offset = ftell(fp) puts trash into lhs. ftell(fp) by itself returns correct number. this is gcc 3.4.2 Fedora3 Yakov
Re: Tags break when enabling large file support
On 9/14/06, Yakov Lerner [EMAIL PROTECTED] wrote: On 9/14/06, Yakov Lerner [EMAIL PROTECTED] wrote: On 9/14/06, Yakov Lerner [EMAIL PROTECTED] wrote: On 9/14/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Yakov Lerner wrote: On 9/14/06, Haakon Riiser [EMAIL PROTECTED] wrote: After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything involving tags break, including the help system. Typing :h, or pressing ^] to jump to a tag, causes Vim to get caught in an infinite loop. [...] Can you find out where in the code this happens? I suspect the 64 bit library functions work different from the normal functions. Perhaps fgets(), since that's what is being used to read the tags file. In situation where fgets() returns NULL, find_tags() enters infinite loop as follows. Sorry, this doesn't show me where the loop actually is. Please compile without the optimizer, otherwise code reordering confuses the debugger. At least tell us if Vim hangs in tag_fgets() or in find_tags(). The loop is is inside find_tags(), and it procees around following line numbers: 1625 1626 1642 1647 1650 1651 1652 1653 1562 1564 1566 1576 1582 1588 1601 1603 1604 1616 1619 1621 1625 and infinite loop repeats. Look at this: gdb print print search_info.curr_offset $2 = 5258708303049 I cannot guess where this loop first gets beyond end of file (filesize=2506), but once it gets beyond, we are missing check that search_info.*offset''s are beyond end of file ? Maybe add such check somewhere ? I don't know where to add the check. Yakov It seems I found the culprint. It is line 1651, search_info.match_offset = ftell(fp); (gdb) p ftell(fp) $11 = 2506 (gdb) n 1652search_info.curr_offset = search_info.curr_offset_used; (gdb) p search_info.curr_offset $12 = 5258708302025 (gdb) Thi screenshot did not who intormation rght. It shoudl look (gdb) b tag.c:1651 Breakpoint 1 at 0x81a5032: file tag.c, line 1651. (gdb) cont Continuing. Breakpoint 1, find_tags (pat=0x827b538 [EMAIL PROTECTED], num_matches=0xbff0696c, matchesp=0xbff06968, flags=40, mincount=1, buf_ffname=0x0) at tag.c:1651 1651search_info.match_offset = ftell(fp); (gdb) n 1652search_info.curr_offset = search_info.curr_offset_used; (gdb) p search_info.match_offset $1 = 10763188046282 (gdb) p ftell(fp) $2 = 2506 (gdb)
Re: Three oddities
Christoph Koegl wrote: I noticed the following in VIM 7: - When I have multiple tabs and windows in each tab open, and I am doing a :bufdo :e to reload all buffers, the list of files is printed as they are being reloaded. After finishing, however, the last file having been reloaded is put into the window which had the focus, instead of the file that had been there before. :bufdo does its work in the current window. You can do something like: :tabdo windo edit Be aware of side effects though! You probably want to tune this to your needs. - Options cursorline and cursorcolumn are very useful. I suspect that they complicate the already complicated highlighting interactions even further. E.g., hlsearch-highlighted patterns take precedence (which is ok!), but background colors of syntax-highlighted text don't. Can you add something to enable the user to choose which background color should prevail (i.e. syntax-background vs. cursorline-background)? I don't like adding options for such details. - In VIM 6, when starting an incremental search, as I was typing more and more letters, the line number shown in the status line was updated to be equal to the line of the current match, i.e. it increased as I was typing. This is no longer the case in VIM 7. I found the VIM 6 behavior more useful. This is probably due to an optimization in redrawing. I can force the ruler to be updated. -- ARTHUR: Charge! [They all charge with swords drawn towards the RABBIT. A tremendous twenty second fight with Peckinpahish shots and borrowing heavily also on the Kung Fu and karate-type films ensues, in which some four KNIGHTS are comprehensively killed.] ARTHUR: Run away! Run away! Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// 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///
Re: Tags break when enabling large file support
Haakon Riiser wrote: [A.J.Mechelynck] -D_FILE_OFFSET_BITS=64 is set on my gcc command-line without me having done anything special to get it. Strange; it doesn't do that on my system. Does it work if you invoke ./configure without any extra arguments? By the way, I noticed that your build also sets _LARGEFILE_SOURCE. I didn't think this macro was needed, since all it does it enable two extra functions, ftello() and fseeko(), which I assumed would not make any difference in the tags issue. Turns out that I was wrong -- defining _LARGEFILE_SOURCE somehow fixed the problem. Configure with no extra arguments will build a Normal version without Gnome and with no interpreters. Now that million-line file I spoke about is in UTF-8 and contains CJK characters mixed in with English text. A Normal-version Vim couldn't edit it because it would have no multi-byte editing support. Hmm... Which version are you using? - tiny, small, normal, large, big, huge? (I have huge) - no GUI, Motif, Athena, NextAW, GTK1, GTK1 with Gnome, GTK2, GTK2 with Gnome? Or MacOsX without X11? And in the latter case, Motorola, Intel or Universal binary? (I have GTK2 with Gnome on Linux i386) I suppose (rightly or wrongly) that one of Huge, GTK2 and Gnome (or something that is implied by them) is what turns on -D_LARGEFILE_SOURCE and -D_FILE_OFFSET_BITS=64 Best regards, Tony.
Re: Tags break when enabling large file support
Bram Moolenaar wrote:
Yakov Lerner wrote:
On 9/14/06, Haakon Riiser [EMAIL PROTECTED] wrote:
After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything
involving tags break, including the help system. Typing :h,
or pressing ^] to jump to a tag, causes Vim to get caught in an
infinite loop.
[...]
Can you find out where in the code this happens?
I suspect the 64 bit library functions work different from the
normal functions. Perhaps fgets(), since that's what is
being used to read the tags file.
In situation where fgets() returns NULL, find_tags() enters
infinite loop as follows.
Sorry, this doesn't show me where the loop actually is. Please compile
without the optimizer, otherwise code reordering confuses the debugger.
At least tell us if Vim hangs in tag_fgets() or in find_tags().
The loop is is inside find_tags(), and it procees around following line
numbers:
1625 1626 1642 1647 1650 1651 1652 1653 1562 1564 1566
1576 1582 1588 1601 1603 1604 1616 1619 1621 1625
and infinite loop repeats. Look at this:
gdb print print search_info.curr_offset
$2 = 5258708303049
The difference must be related to fseek(). I don't see where
search_info.curr_offset is first initialized, though.
The problem must be that either ftello() doesn't return the right
position or fseeko() doesn't position the read pointer properly. I
can't think of another reason.
And additionally:
(gdb) print search_info
$3 = {low_offset = 0, high_offset = 10526964844947, curr_offset = 5258708303049,
curr_offset_used = 5258708303049, match_offset = 10763188046282,
low_char = 0, high_char = 120}
This suggests that an unsigned number overflows and is turned into an
int somewhere. I can't guess where and I can't reproduce this. Perhaps
someone can think of a workaround and try it out.
One thing you can do: check that off_t is signed. You should have seen
compiler warnings then.
See Haakon's reply to my first post near the top of this thread: turning
on -D_LARGEFILE_SOURCE defines ftello() and fseeko(); it also makes the
bug disappear.
Best regards,
Tony.
Re: Tags break when enabling large file support
Haakon Riiser wrote: [A.J.Mechelynck] Configure with no extra arguments will build a Normal version without Gnome and with no interpreters. Now that million-line file I spoke about is in UTF-8 and contains CJK characters mixed in with English text. A Normal-version Vim couldn't edit it because it would have no multi-byte editing support. Hmm... Which version are you using? - tiny, small, normal, large, big, huge? (I have huge) - no GUI, Motif, Athena, NextAW, GTK1, GTK1 with Gnome, GTK2, GTK2 with Gnome? Or MacOsX without X11? And in the latter case, Motorola, Intel or Universal binary? (I have GTK2 with Gnome on Linux i386) Normal I guess. These are the configure options I use: --disable-acl --disable-gpm --disable-nls --disable-netbeans --disable-xsmp --disable-xsmp-interact --with-x=no --enable-gui=no Hm, yes; IIUC this would build a Normal version without GUI and without X11 (i.e. no access to the clipboard). So I suppose there is something in my Huge GTK2/Gnome2 gvim (with, as it turns out, all interpreters except MzScheme) which turns on those two large-file defines, and later on on the gcc command-line also -D_LARGEFILE64_SOURCE=1 Best regards, Tony.
Re: Tags break when enabling large file support
Yakov Lerner wrote: Surprisingly, changing ftell() to ftello() does not change anything. On systems that support ftello() ftell() is defined to use ftello(). Casting ftell() to (off_t) doesn't change anything. Funnily, casting ftell to (long) makes the problem go away (as it ftell does not already return long, it does): 1628 search_info.curr_offset = (long)ftell(fp); 1644 search_info.curr_offset = (long)ftell(fp); 1651 search_info.match_offset = (long)ftell(fp); This won't work correctly when off_t is bigger than long, e.g. long long. New developments: It looks like -D_FILE_OFFSET_BITS=64 alone is wrong because it's not complete. Correct build settings are: gcc -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE This makes problem go away without any changes in the sources. So gcc has an option to break your code? That can't be right. 3. Thou shalt not use Google as a verb. http://www.thechurchofgoogle.org/Scripture/10_Commandments.html One of the (many) false statements found on the internet. Google objects to using googling for searching in general, it's OK to use for searching with Google. -- Veni, Vidi, VW -- I came, I saw, I drove around in a little car. /// 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///
Re: Cannot build console Vim on Windows XP (Vim 7.0.106)
Hi! I forgot to mention, that my last build was version 7.0.101. It is probably patch 7.0.104 which introduced this problem. Best wishes, Georg Dahn Georg Dahn wrote: Hi! I have updated the sources of Vim from CVS (7.0.106) and tried to compile Vim. The GUI version can be built, but I get the following errors when I build the console version: fileio.obj : error LNK2019: unresolved external symbol _prof_child_exit referenced in function _apply_autocmds_group fileio.obj : error LNK2019: unresolved external symbol _prof_child_enter referenced in function _apply_autocmds_group fileio.obj : error LNK2001: unresolved external symbol _do_profiling vim.exe : fatal error LNK1120: 3 unresolved externals I build Vim with HUGE feature-set and use MS Visual C++ Toolkit 2003. Best wishes, Georg Dahn ___ Copy addresses and emails from any email account to Yahoo! Mail - quick, easy and free. http://uk.docs.yahoo.com/trueswitch2.html ___ All new Yahoo! Mail The new Interface is stunning in its simplicity and ease of use. - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html
Re: Patch 7.0.106
On Thu 14-Sep-06 6:35am -0600, Bram Moolenaar wrote: Patch 7.0.106 I encountered a problem that has appeared before patching files in runtime. I received the following from my patch invocation: patching file `menu.vim' Hunk #1 FAILED at 2. Hunk #2 FAILED at 885. Hunk #3 succeeded at 912 (offset 2 lines). Hunk #4 FAILED at 942. Hunk #5 FAILED at 1019. 4 out of 5 hunks FAILED -- saving rejects to menu.vim.rej patching file `src/version.c' I regularly update my local copy of vim with the following copy update command (4nt under WinXP): copy /u /s ftp://ftp.home.vim.org/pub/vim/runtime/dos/*; c:\vim\vim70\ I suspect your patches assume that users do not update their runtime files. Is this what's happening? -- Best regards, Bill
Re: Patch 7.0.106
Bill McCarthy wrote: On Thu 14-Sep-06 6:35am -0600, Bram Moolenaar wrote: Patch 7.0.106 I encountered a problem that has appeared before patching files in runtime. I received the following from my patch invocation: patching file `menu.vim' Hunk #1 FAILED at 2. Hunk #2 FAILED at 885. Hunk #3 succeeded at 912 (offset 2 lines). Hunk #4 FAILED at 942. Hunk #5 FAILED at 1019. 4 out of 5 hunks FAILED -- saving rejects to menu.vim.rej patching file `src/version.c' I regularly update my local copy of vim with the following copy update command (4nt under WinXP): copy /u /s ftp://ftp.home.vim.org/pub/vim/runtime/dos/*; c:\vim\vim70\ I suspect your patches assume that users do not update their runtime files. Is this what's happening? If you update your runtime files from the ftp site then you also get the patches, eventually. Mixing patches and downloading doesn't always work. In case of doubt use the files from the ftp site. -- [Another hideous roar.] BEDEVERE: That's it! ARTHUR: What? BEDEVERE: It's The Legendary Black Beast of Arrggghhh! Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// 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///
Re: Convert to HTML patch. Opinions / Testing.
On 14/09/06, Mikolaj Machowski [EMAIL PROTECTED] wrote: Dnia sobota, 9 września 2006 20:03, Edd Barrett napisał: - I removed p's because you cannot contain a span in a p according to w3. An unstyled p would make no difference in this case anyway. While I agree with most of your changes *where* span cannot be inside of p? m. Your right. You can have spans in p's.. hmmm . I could have swore the validator moaned at me the first time i tried it. Still the p's wouldnt make any difference to formatting in this case. If you really want them back I can alter the patch, but I dont really see the need. best Regards Edd
Re: distributing experimental patches with vim ?
Hello Yakov,
If I recall correctly, didn't you write the shell script which automatically
patches and installs Vim 7? If so, why not expand on it to allow (optionally)
installing unofficial patches from vim.org as well? Maybe a
'--with-patch=script_id' argument would work?
regards,
Peter
--- Yakov Lerner [EMAIL PROTECTED] wrote:
Vim patches submitted by external submitters are either
'incorporated' or 'outsude of vim sources'. That's black-and-white.
I thought it's possible to add some intermediate state, where
'experimental-patch' is neither outside of vim nor inside-vim. This
is useful because people can try experimental patches easier,
with clear understandnig that they are trying experimental patches.
It can work as follows.
(BTW I think Vince Negri conceal patch deserves this status.)
It can work as follows. Experimental patch is added as a _feature_
named 'x-*', say 'x-conceal'. It has it's #ifdef, FEAT_X_CONCEAL, and
none of x-* features are built by 'huge' (largest) built. The builder
needs to enable them manually with --enable-x-conceal or similar
configure flag.
To make it very clear that build includes experimental
features, the :version will have line seen from large distance:
CONTAINS EXPERIMENTAL FEATURES *
But then more people can try these experimental patches
and feedback on them, improve them, or report their uselessness.
Yakov
Do you Yahoo!?
Take part in Total Girls Ultimate Slumber Party and help break a world record
http://www.totalgirl.com.au
Re: Two problems
Ciao Peter, The Vim Book (http://iccf-holland.org/click5.html#oualline) will get you up to speed quickly on most of Vim's important features, and teach you how to use some important tools you might miss otherwise. Most complex commands can still be reduced down to one or two keystrokes, just post again if you need help with anything. Well.. the vim book is for vim 5.7.. Are there any plans to make a new version for vim 7.x? I would buy it if only it was up-to-date! :) -- [ Andrea Spadaccini - a.k.a. Lupino - from Catania - ICQ #: 91528290 ] [ GPG ID: 5D41ABF0 - key on keyservers - Gentoo GNU / Linux - 2.6.17 ] [ Linux Registered User 313388 - @: a.spadaccini(at)catania.linux.it ] signature.asc Description: PGP signature
Re: Two problems
Pete Johns schrieb:
For all lines longer than 72 characters, reformat the
paragraph from that line..
1,$g/.\{73,}/normal v}gq
or just
:set tw=72 if set otherwise
:g/./normal gqq
Andy
___
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail:
http://mail.yahoo.de
vim | multiple files editing and delete question
Hi,
I have a series of questions:
1. I want to edit multiple files from command line so I created a vim
script with all the commands (20). I use a batch file in WinXP:
|@echo off
vim -s script file.txt
exit
however I need to run this script on multiple files. In vim's help there is
this code for use in bash(?) shell
||for file in *.txt; do|
| vim -e -s $file change.vim|
| lpr -r tempfile|
|done
however it doesn't seem to work under Cygwin.
2.Can I delete after a pattern search? Sth like this:
:/^html\_.{-}body: /-3d
and how can I repeat this globally?
3. This is not Vim related but I wonder if anyone knows sth. I have the
following structure of folders and files:
..
folder1
file1
file2
folder2
file1
file2
.
and want to add the folder name into the filename:
||
folder1
||folder1|_|file1
||folder1|_|||file2
folder2
||folder2|_|||file1
||folder2|_|||file2
Thanks in advance,
Nikos
|
Re: vim | multiple files editing and delete question
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote: Hi, I have a series of questions: 1. I want to edit multiple files from command line so I created a vim script with all the commands (20). I use a batch file in WinXP: |@echo off vim -s script file.txt exit however I need to run this script on multiple files. In vim's help there is this code for use in bash(?) shell ||for file in *.txt; do| | vim -e -s $file change.vim| If you want to read vim commands from change.vim, then try: vim -e -s -c 'so change.vim' $file Also: :help argdo Yakov
Re: vim | multiple files editing and delete question
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote:
2.Can I delete after a pattern search? Sth like this:
:/^html\_.{-}body: /-3d
and how can I repeat this globally?
:g/^html\_.{-}body: /.-3d
Yakov
Re: vim | multiple files editing and delete question
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote:
3. This is not Vim related but I wonder if anyone knows sth. I have the
following structure of folders and files:
..
folder1
file1
file2
folder2
file1
file2
.
and want to add the folder name into the filename:
||
folder1
||folder1|_|file1
||folder1|_|||file2
folder2
||folder2|_|||file1
||folder2|_|||file2
Try this shell script:
for file in folder*/*; do
dir=$(basename $(dirname $file) )
base=$(basename $file)
mv $file $(dirname $file)/${dir}_${base}
done
Untested!
Yakov
Re: vim | multiple files editing and delete question
Yakov Lerner wrote:
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote:
2.Can I delete after a pattern search? Sth like this:
:/^html\_.{-}body: /-3d
and how can I repeat this globally?
:g/^html\_.{-}body: /.-3d
Yakov
I get an E16: invalid range error
--
Nikolaos A. Patsopoulos, MD
Department of Hygiene and Epidemiology
University of Ioannina School of Medicine
University Campus
Ioannina 45110
Greece
Tel: (+30) 26510-97804
mobile: +30 6972882016
Fax: (+30) 26510-97867 (care of Nikolaos A. Patsopoulos)
e-mail: [EMAIL PROTECTED]
Re: vim | multiple files editing and delete question
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote:
Yakov Lerner wrote:
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote:
2.Can I delete after a pattern search? Sth like this:
:/^html\_.{-}body: /-3d
and how can I repeat this globally?
:g/^html\_.{-}body: /.-3d
Yakov
I get an E16: invalid range error
Yeah, this can happen if pattern is found
in line number 4. (Then .-3 results in =0 which is invalid
line number). Just insert 4 dummy empty lines
at beginning of file to avoid this.
Yakov
Re: vim | multiple files editing and delete question
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote:
Yakov Lerner wrote:
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote:
Yakov Lerner wrote:
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote:
2.Can I delete after a pattern search? Sth like this:
:/^html\_.{-}body: /-3d
and how can I repeat this globally?
:g/^html\_.{-}body: /.-3d
Yakov
I get an E16: invalid range error
Yeah, this can happen if pattern is found
in line number 4. (Then .-3 results in =0 which is invalid
line number). Just insert 4 dummy empty lines
at beginning of file to avoid this.
Yakov
This means that the -3d counts from the beginning of the pattern?? In my
file The first occurrence of the patten expands from line 1 to line 82.
Yes, from the beginning of the pattern
Yakov
Re: vim | multiple files editing and delete question (bash script)
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote:
Yakov Lerner wrote:
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote:
3. This is not Vim related but I wonder if anyone knows sth. I have
the following structure of folders and files:
..
folder1
file1
file2
folder2
file1
file2
.
and want to add the folder name into the filename:
||
folder1
||folder1|_|file1
||folder1|_|||file2
folder2
||folder2|_|||file1
||folder2|_|||file2
Try this shell script:
for file in folder*/*; do
dir=$(basename $(dirname $file) )
base=$(basename $file)
mv $file $(dirname $file)/${dir}_${base}
done
Untested!
Yakov
Bash result: script started, file is typescript.
Nothing happens. Just an empty file called typescript appears in parent
folder.
Try on bash mailing list or bash irc chan.
Yakov
Re: vim | multiple files editing and delete question
Yakov Lerner wrote:
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote:
Yakov Lerner wrote:
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote:
Yakov Lerner wrote:
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote:
2.Can I delete after a pattern search? Sth like this:
:/^html\_.{-}body: /-3d
and how can I repeat this globally?
:g/^html\_.{-}body: /.-3d
Yakov
I get an E16: invalid range error
Yeah, this can happen if pattern is found
in line number 4. (Then .-3 results in =0 which is invalid
line number). Just insert 4 dummy empty lines
at beginning of file to avoid this.
Yakov
This means that the -3d counts from the beginning of the pattern?? In my
file The first occurrence of the patten expands from line 1 to line 82.
Yes, from the beginning of the pattern
Yakov
How can I force it to delete 3 lines from the end?
--
Nikolaos A. Patsopoulos, MD
Department of Hygiene and Epidemiology
University of Ioannina School of Medicine
University Campus
Ioannina 45110
Greece
Tel: (+30) 26510-97804
mobile: +30 6972882016
Fax: (+30) 26510-97867 (care of Nikolaos A. Patsopoulos)
e-mail: [EMAIL PROTECTED]
Re: vim | multiple files editing and delete question (bash script)
Yakov Lerner wrote:
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote:
Yakov Lerner wrote:
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote:
3. This is not Vim related but I wonder if anyone knows sth. I have
the following structure of folders and files:
..
folder1
file1
file2
folder2
file1
file2
.
and want to add the folder name into the filename:
||
folder1
||folder1|_|file1
||folder1|_|||file2
folder2
||folder2|_|||file1
||folder2|_|||file2
Try this shell script:
for file in folder*/*; do
dir=$(basename $(dirname $file) )
base=$(basename $file)
mv $file $(dirname $file)/${dir}_${base}
done
Untested!
Yakov
Bash result: script started, file is typescript.
Nothing happens. Just an empty file called typescript appears in parent
folder.
Try on bash mailing list or bash irc chan.
Yakov
Thanks. I'll do that.
Nikos
Re: vim | multiple files editing and delete question
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote Yakov
Lerner wrote:
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote:
Yakov Lerner wrote:
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote:
Yakov Lerner wrote:
On 9/14/06, Nikolaos A. Patsopoulos [EMAIL PROTECTED] wrote:
2.Can I delete after a pattern search? Sth like this:
:/^html\_.{-}body: /-3d
and how can I repeat this globally?
:g/^html\_.{-}body: /.-3d
Yakov
I get an E16: invalid range error
Yeah, this can happen if pattern is found
in line number 4. (Then .-3 results in =0 which is invalid
line number). Just insert 4 dummy empty lines
at beginning of file to avoid this.
Yakov
This means that the -3d counts from the beginning of the pattern?? In my
file The first occurrence of the patten expands from line 1 to line 82.
Yes, from the beginning of the pattern
Yakov
How can I force it to delete 3 lines from the end?
This is tricky, but try this:
:g/pattern/exe normal //e|.-3d
(untested)
Yakov
Re: vim | multiple files editing and delete question
On Thu, 2006-09-14 at 13:01 +0300, Nikolaos A. Patsopoulos wrote: 1. I want to edit multiple files from command line so I created a vim script with all the commands (20). I use a batch file in WinXP: |@echo off vim -s script file.txt exit however I need to run this script on multiple files. In vim's help there is this code for use in bash(?) shell ||for file in *.txt; do| | vim -e -s $file change.vim| | lpr -r tempfile| |done however it doesn't seem to work under Cygwin. To do an operation on multiple files in a WinXP DOS batch: for %%A in (*.txt) do [command] Chain multiple commands after the do statement with : for %%A in (*.txt) do vim -e -s change.vim %%A copy %%A lpt1 or call a separate batch that takes %1 as the argument: for %%A in (*.txt) do call MyEdit.bat %%A where MyEdit.bat is: @echo OFF echo File %1... vim -e -s change.vim %1 copy %1 lpt1 Note that I usually sprinkle double quotes liberally to avoid issues with spaces in paths. -- Steve Hall [ digitect dancingpaper com ]
Re: vim | multiple files editing and delete question
Steve Hall wrote: On Thu, 2006-09-14 at 13:01 +0300, Nikolaos A. Patsopoulos wrote: 1. I want to edit multiple files from command line so I created a vim script with all the commands (20). I use a batch file in WinXP: |@echo off vim -s script file.txt exit however I need to run this script on multiple files. In vim's help there is this code for use in bash(?) shell ||for file in *.txt; do| | vim -e -s $file change.vim| | lpr -r tempfile| |done however it doesn't seem to work under Cygwin. To do an operation on multiple files in a WinXP DOS batch: for %%A in (*.txt) do [command] Chain multiple commands after the do statement with : for %%A in (*.txt) do vim -e -s change.vim %%A copy %%A lpt1 or call a separate batch that takes %1 as the argument: for %%A in (*.txt) do call MyEdit.bat %%A where MyEdit.bat is: @echo OFF echo File %1... vim -e -s change.vim %1 copy %1 lpt1 Note that I usually sprinkle double quotes liberally to avoid issues with spaces in paths. That works great!!! Thanks! Nikos
Re: vim | multiple files editing and delete question
To do an operation on multiple files in a WinXP DOS batch: for %%A in (*.txt) do [command] Just a small caveat to the reader, this works within a batch file by escaping the variable (%A in this case). If you're running it from the command-line, you don't escape it, and thus use for %a in (*.txt) do [command using %a] instead of for %%a in (*.txt) do [command using %%a] Then again, maybe I'm among the freakish few that actually use for-loops at the dos-prompt. :) -tim
RE: vim | multiple files editing and delete question
If u have Cygwin then creating a batch file with the following would be the
simplest solution -
set TARGETDIR=C:\something
set SCRIPTDIR=C:\something_else
find %TARGETDIR% -name *.[ch] -exec gvim -s %SCRIPTDIR%\win32_vimscript.vim
{} ;
Basically use find to help u (actually it's just one instruction, so u
don't even need to have a batch file for it)
Regards,
Sibin
-Original Message-
From: Nikolaos A. Patsopoulos [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 14, 2006 3:31 PM
To: vim@vim.org
Subject: vim | multiple files editing and delete question
Hi,
I have a series of questions:
1. I want to edit multiple files from command line so I created a vim
script with all the commands (20). I use a batch file in WinXP:
|@echo off
vim -s script file.txt
exit
however I need to run this script on multiple files. In vim's help there is
this code for use in bash(?) shell
||for file in *.txt; do|
| vim -e -s $file change.vim|
| lpr -r tempfile|
|done
however it doesn't seem to work under Cygwin.
2.Can I delete after a pattern search? Sth like this:
:/^html\_.{-}body: /-3d
and how can I repeat this globally?
3. This is not Vim related but I wonder if anyone knows sth. I have the
following structure of folders and files:
..
folder1
file1
file2
folder2
file1
file2
.
and want to add the folder name into the filename:
||
folder1
||folder1|_|file1
||folder1|_|||file2
folder2
||folder2|_|||file1
||folder2|_|||file2
Thanks in advance,
Nikos
|
-
Disclaimer
-
This message(including attachment if any)is confidential and may be
privileged.Before opening attachments please check them
for viruses and defects.MindTree Consulting Private Limited (MindTree)will not
be responsible for any viruses or defects or
any forwarded attachments emanating either from within MindTree or outside.If
you have received this message by mistake please notify the sender by return
e-mail and delete this message from your system. Any unauthorized use or
dissemination of this message in whole or in part is strictly prohibited.
Please note that e-mails are susceptible to change and MindTree shall not be
liable for any improper, untimely or incomplete transmission.
-
Re: vim | multiple files editing and delete question
Sibin P. Thomas wrote:
If u have Cygwin then creating a batch file with the following would be the
simplest solution -
set TARGETDIR=C:\something
set SCRIPTDIR=C:\something_else
find %TARGETDIR% -name *.[ch] -exec gvim -s %SCRIPTDIR%\win32_vimscript.vim
{} ;
Basically use find to help u (actually it's just one instruction, so u
don't even need to have a batch file for it)
Regards,
Sibin
-Original Message-
From: Nikolaos A. Patsopoulos [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 14, 2006 3:31 PM
To: vim@vim.org
Subject: vim | multiple files editing and delete question
Hi,
I have a series of questions:
1. I want to edit multiple files from command line so I created a vim
script with all the commands (20). I use a batch file in WinXP:
|@echo off
vim -s script file.txt
exit
however I need to run this script on multiple files. In vim's help there is
this code for use in bash(?) shell
||for file in *.txt; do|
| vim -e -s $file change.vim|
| lpr -r tempfile|
|done
however it doesn't seem to work under Cygwin.
2.Can I delete after a pattern search? Sth like this:
:/^html\_.{-}body: /-3d
and how can I repeat this globally?
3. This is not Vim related but I wonder if anyone knows sth. I have the
following structure of folders and files:
..
folder1
file1
file2
folder2
file1
file2
.
and want to add the folder name into the filename:
||
folder1
||folder1|_|file1
||folder1|_|||file2
folder2
||folder2|_|||file1
||folder2|_|||file2
Thanks in advance,
Nikos
|
-
Disclaimer
-
This message(including attachment if any)is confidential and may be
privileged.Before opening attachments please check them
for viruses and defects.MindTree Consulting Private Limited (MindTree)will not
be responsible for any viruses or defects or
any forwarded attachments emanating either from within MindTree or outside.If you
have received this message by mistake please notify the sender by return e-mail and
delete this message from your system. Any unauthorized use or dissemination of this
message in whole or in part is strictly prohibited. Please note that e-mails are
susceptible to change and MindTree shall not be liable for any improper, untimely or
incomplete transmission.
-
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.12.3/447 - Release Date: 13/9/2006
Haven't tested your suggestion, but this works just fine:
for file in folder */*; do
dir=$(basename $(dirname $file))
base=$(basename $file)
mv $file $(dirname $file)/${dir}_${base}
done
vim | replacement question
Hi,
another two questions:
1. I want to delete all text that has a specific pattern. I use the
following code with s command but I want to keep the \a character in the
beginning:
:%s/\a,\_.\{-}\/td\/tr/
2.
how can I join lines that have non-numerical characters?
e.g.
153
Purdue
Canc Ct
1256
should be
153
Purdue Canc Ct
1256
Thanks in advance,
Nikos
Re: vim | replacement question
Nikolaos A. Patsopoulos wrote:
Hi,
another two questions:
1. I want to delete all text that has a specific pattern. I use the
following code with s command but I want to keep the \a character in the
beginning:
:%s/\a,\_.\{-}\/td\/tr/
To delete everything that matches a certain pattern
:%s/pattern//g
(i.e., replace by nothing). To keep something at the start, see
:help /\zs
:help /\@=
2.
how can I join lines that have non-numerical characters?
e.g.
153
Purdue
Canc Ct
1256
should be
153
Purdue Canc Ct
1256
Thanks in advance,
Nikos
(untested)
:%g/\D.*\n.*\D/join
i.e. join two successive lines, adding an intervening space, if there is
at least one non-digit anywhere in each of them.
Best regards,
Tony.
Re: Matchit's match_words Question
On Tue, Sep 12, 2006 at 07:30:55PM -0500, Bill McCarthy wrote: Thanks, Tony. I was just getting ready to respond to myself with another solution I found with a hint from the help file: let b:match_words = \'\%(\S\+\)\@!text\s*$:\%(\S\+\)\@!endtext\s*$' Hint from :help matchit-spaces Also :help /\@! But I'm still wondering why '\zs' didn't work. Even I do not know for sure. I think the point is that matchit takes 'pat1:pat2' and builds up the regex /\%(pat1\)\|\%(pat2\)/ . If you are just searching for /pat1/ then it does not matter if pat1 is \s*\zstext or \(\s*\)\@=text , but when you build the larger regex, it does make a difference. IIRC, early versions of the script were written before \@= was added so I included a special marker ( I think, inspired by :menu syntax) for when you wanted to position the cursor somewhere other than at the start of the match. HTH --Benji Fisher
Re: vim | replacement question
A.J.Mechelynck wrote:
Nikolaos A. Patsopoulos wrote:
Hi,
another two questions:
1. I want to delete all text that has a specific pattern. I use the
following code with s command but I want to keep the \a character in
the beginning:
:%s/\a,\_.\{-}\/td\/tr/
To delete everything that matches a certain pattern
:%s/pattern//g
(i.e., replace by nothing). To keep something at the start, see
:help /\zs
:help /\@=
2.
how can I join lines that have non-numerical characters?
e.g.
153
Purdue
Canc Ct
1256
should be
153
Purdue Canc Ct
1256
Thanks in advance,
Nikos
(untested)
:%g/\D.*\n.*\D/join
i.e. join two successive lines, adding an intervening space, if there
is at least one non-digit anywhere in each of them.
Best regards,
Tony.
For 1 I came up with this:
:%s/\(\a\),\_.\{-}\/td\/tr/\1
about 2
:%g/\D.*\n.*\D/join
.* captures some numeric values in between. Maybe sth like this would be
better:
:%g/\D.*\n.*[^\d]\D/join
but this is not right.
--
Nikolaos A. Patsopoulos, MD
Department of Hygiene and Epidemiology
University of Ioannina School of Medicine
University Campus
Ioannina 45110
Greece
Tel: (+30) 26510-97804
mobile: +30 6972882016
Fax: (+30) 26510-97867 (care of Nikolaos A. Patsopoulos)
e-mail: [EMAIL PROTECTED]
vim | insert filename into file
Hi, how can anyone add the filename in the file in ex-mode? C-R% and %p works only in normal mode Thanks, Nikos
Re: vim | insert filename into file
Hi, Nikolaos A. Patsopoulos wrote: how can anyone add the filename in the file in ex-mode? C-R% and %p works only in normal mode :put % Regards, Jürgen -- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. (Calvin)
Re: vim | insert filename into file
Jürgen Krämer wrote: Hi, Nikolaos A. Patsopoulos wrote: how can anyone add the filename in the file in ex-mode? C-R% and %p works only in normal mode :put % Regards, Jürgen That seems to insert the filename in random place. What if I want to place it e.g. in the beginning of each line?
Re: vim | insert filename into file
If you don't want to put the filename on a new line as :put % does, maybe try :normal %p -dan
Re: vim | insert filename into file
how can anyone add the filename in the file in ex-mode?
C-R% and %p works only in normal mode
:put %
Or, if you need to insert it at a particular place,
:10s/$/\=' '.expand('%')
will put it at the end of line #10. The basic idiom involves
replacing something (EOL, BOL, or some offset in the line) with
an evaluated expression that uses expand('%')
You can read more at
:help sub-replace-special
:help expand()
-tim
Re: vim | insert filename into file
To place at the beginning of each line try :%normal %P -dan
Re: vim | insert filename into file
:put %
That seems to insert the filename in random place. What if I
want to place it e.g. in the beginning of each line?
It inserts it on the line below where the cursor currently is.
You can specify a target (as in
:30put %
which will put it below line #30)
If you want it at the beginning of each line, you can use my
aforementioned suggestion of
:%s/^/\=expand('%').': '
(which also adds a colon and a space for visualization purposes,
but is totally omittable if you want)
-tim
Re: vim | insert filename into file
Tim Chase wrote:
:put %
That seems to insert the filename in random place. What if I
want to place it e.g. in the beginning of each line?
It inserts it on the line below where the cursor currently is. You can
specify a target (as in
:30put %
which will put it below line #30)
If you want it at the beginning of each line, you can use my
aforementioned suggestion of
:%s/^/\=expand('%').': '
(which also adds a colon and a space for visualization purposes, but
is totally omittable if you want)
-tim
:%s/^/\=expand('%')
works great!
Thank you all
Re: Two problems
--- Andrea Spadaccini [EMAIL PROTECTED] wrote: Well.. the vim book is for vim 5.7.. Are there any plans to make a new version for vim 7.x? I would buy it if only it was up-to-date! :) Many of Vim's best features were included in 5.7. It is still a great book to get you from a novice to intermediate user quickly. regards, Peter -- [ Andrea Spadaccini - a.k.a. Lupino - from Catania - ICQ #: 91528290 ] [ GPG ID: 5D41ABF0 - key on keyservers - Gentoo GNU / Linux - 2.6.17 ] [ Linux Registered User 313388 - @: a.spadaccini(at)catania.linux.it ] Do you Yahoo!? Take part in Total Girls Ultimate Slumber Party and help break a world record http://www.totalgirl.com.au
RE: Two problems
Ah, I can understand that. I have (so far) in my professional career never had the joy of maintaining someone else's code, or when I have it is written with nice guidelines that avoid lng lines ;) Hope you get on well with it! Max -Original Message- From: Meino Christian Cramer [mailto:[EMAIL PROTECTED] Sent: Thursday, September 14, 2006 7:21 PM To: Max Dyckhoff Cc: vim@vim.org Subject: Re: Two problems From: Max Dyckhoff [EMAIL PROTECTED] Subject: RE: Two problems Date: Wed, 13 Sep 2006 20:30:15 -0700 Hi Max, thanks a lot for your help ! :) (sorry for the late reply...) I am maintaining a source code from someone else (which left the company) and some of the lines of code are long. While reviewing the code I find myself often doing iC-jEsc and was curious whether someone of the vim-profeesionels would do this shorter and more elegant. Thanks a lot again! mcc I can't offer anything else immediately (I have a load of mappings and functions but they are all pretty tailored to my needs!), but I was interested why you would want to split a line in two like that. Can you give us an example? I'm not criticising, I'm just nosy :) Max FWIW: the most recent addition to my .vimrc is this, for after 14 hours of coding when my eyesight starts to fail me. Simple, but it has saved my eyes! :let g:maxd_FontSize=10 :let g:maxd_FontOpts=b :let g:maxd_Font=consolas :map C-S-kPlus:call ChangeFontSize(up)CR :map C-S-kMinus :call ChangeFontSize(down)CR :map C-S-kMultiply:call ChangeFontSize()CR function! ChangeFontSize(updown) if (a:updown==up) let g:maxd_FontSize= g:maxd_FontSize + 1 elseif (a:updown==down) let g:maxd_FontSize= g:maxd_FontSize - 1 endif exec set guifont=.g:maxd_Font.:h.g:maxd_FontSize.:.g:maxd_FontOpts endfunction
Re: Two problems
From: Pete Johns [EMAIL PROTECTED]
Subject: Re: Two problems
Date: Thu, 14 Sep 2006 13:46:42 +1000
On Thu, 2006-09-14 at 04:45:12 +0200, Meino Christian Cramer sent:
2.) Currently I am reading the ascii version of the vimtips
file. One thing I would like to change physically (that means:
The file should be changed that way, not only the visual
representation...) are the super long lines into 72 chars ones.
My attempt to do this was
gqG
which reformats /everything/ (even the embedded scripts). As
long as it was floating text, the result was ok, but the
scripts were obfuscated.
I would like to apply the gq-command only to lines longer than
72 chars -- so the scripts were automagically skipped (as I
hope...).
How can I accomplish this ?
Here's my attempt:
For all lines longer than 72 characters, reformat the
paragraph from that line..
1,$g/.\{73,}/normal v}gq
Hope this helps;
--paj
--
Pete Johns http://johnsy.com/
Contact Information http://johnsy.com/contact/
More On OptusNet http://johnsy.com/20060912132225
dsc00220 http://johnsy.com/albums/flickr/210370644
Hi Pete!
thank you very much for this line of code -- works like a charme!
The only bad thing is: I dont understand completly, how it
works
This far I got:
1,$for the beginning of the text til its end do
/.\{73,}/ find all lines longer than 72 chars and for each do
normal ??? go into normal mode ???
v ? visual mode (and for what is the good for?)
}gq only white noise for mea C-programme I would
say, that there is on } too many in the whole expression
but simultaneously I know, that I am wrong.???
Keep hacking!
mcc
Re: Two problems
On Fri, 2006-09-15 at 04:57:24 +0200, Meino Christian Cramer sent:
Hi Pete!
Hi!
thank you very much for this line of code -- works like a
charme!
Delighted to hear it.
The only bad thing is: I dont understand completly, how it
works
He he... I'm glad that someone's taken this apart :-)
1,$for the beginning of the text til its end do
And there's a 'g'...
/.\{73,}/ find all lines longer than 72 chars and for each do
Yup.
normal ??? go into normal mode ???
v ? visual mode (and for what is the good for?)
normalv}gq isn't an editor command, so you have to split 'normal'
and 'v'. There may be a better way of doing this.
}gq only white noise for mea C-programme I
would say, that there is on } too many in the whole expression
but simultaneously I know, that I am wrong.???
} is a motion: it moves one paragraph forward.
See :help }
gq formats the highlighted lines.
See :he gq
There are other ways of solving this problem, I am sure, but I
like the way this works because it leaves paragraphs alone that
are shorter then 73 characters wide, rather than expanding them.
Cheers;
--paj
--
Pete Johns http://johnsy.com/
Contact Information http://johnsy.com/contact/
More On OptusNet http://johnsy.com/20060912132225
dsc00220 http://johnsy.com/albums/flickr/210370644
pgpCPeNAGzZPh.pgp
Description: PGP signature
