On Dec 3, 1:46 am, Tony Mechelynck <antoine.mechely...@...>
wrote:
> On 03/12/09 05:20, JD wrote:
>
> > Vim is hardlocking for me on every single run on my FreeBSD 5.4
> > system. I've tried 7.2.299, 7.2.309 and 7.2.315 and all are broken.
>
> > It appears to compile fine, but on run, it fails to respond to any
> > keystrokes and eats nearly 100% of my CPU till I send it a
> > SIGKILL...Please help. :)
>
> > Thanks
>
> Does it always hang, even if you start it as
>
>         vim -N -u NONE
> or
>         gvim -N -u NONE
> ?
>
> Best regards,
> Tony.
> --
> Re graphics: A picture is worth 10K words -- but only those to describe
> the picture.  Hardly any sets of 10K words can be adequately described
> with pictures.

It appears to work fine launching vim with -N -u NONE, when not
launching with '-N -u NONE', i've so far narrowed it down to 2
filetypes. I tried opening a ruby script, a perl script, a python
script and a C++ source file and the only ones that failed and caused
vim to lock were the ruby script and the perl script. I moved the
affected scripts to a different directory (same dir as the C++ source)
and the issue still occurred and as far as i can tell, the permissions
on all 4 files are the same.

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

On Wed, 2 Dec 2009 22:55:10 -0800 (PST)
JD <jdhore1@...> wrote:

> Thanks for the response Gary. I believe i built vim with debug symbols
> correctly, but after it hardlocks, kill -6 doesn't dump a core file
> anywhere i can see nor does it terminate the process....
>

Probably you need to set core file size limit too.
For bash it is: ulimit -c <size>

--
Michal Kurgan


--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

On Dec 3, 3:04 am, Michal Kurgan <michal.kur...@...> wrote:
> On Wed, 2 Dec 2009 22:55:10 -0800 (PST)
>
> JD <jdho...@...> wrote:
> > Thanks for the response Gary. I believe i built vim with debug symbols
> > correctly, but after it hardlocks, kill -6 doesn't dump a core file
> > anywhere i can see nor does it terminate the process....
>
> Probably you need to set core file size limit too.
> For bash it is: ulimit -c <size>
>
> --
> Michal Kurgan

I have my ulimit set to unlimited. :)

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

jdhore1@... wrote:

> Vim is hardlocking for me on every single run on my FreeBSD 5.4
> system. I've tried 7.2.299, 7.2.309 and 7.2.315 and all are broken.
>
> It appears to compile fine, but on run, it fails to respond to any
> keystrokes and eats nearly 100% of my CPU till I send it a
> SIGKILL...Please help. :)
>
> Thanks

You can attach to the running process with gdb and look at
the stack trace with 'backtrace' gdb command.  You can also
use the 'continue' gdb command and interrupt again with CTRL-C
to run 'backtrace' several times (in case the backtrace is not always
the same).

Example:

   $ gdb
   ...
   (gdb) attach PID
   ...
   (gdb) backtrace
   ...
   (gdb) continue
   (gdb) CTRL-C
   (gdb) backtrace


(replace PID with the process ID of the Vim process which hogs the CPU)

The output of backtrace may help to figure out why it hogs the CPU.
You will need to compile/link Vim with symbols (-g -O0) to get a proper
stack trace with gdb.

-- Dominique

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

On 03/12/09 08:03, JD wrote:
> On Dec 3, 1:46 am, Tony Mechelynck<antoine.mechely...@...>
> wrote:
>> On 03/12/09 05:20, JD wrote:
>>
>>> Vim is hardlocking for me on every single run on my FreeBSD 5.4
>>> system. I've tried 7.2.299, 7.2.309 and 7.2.315 and all are broken.
>>
>>> It appears to compile fine, but on run, it fails to respond to any
>>> keystrokes and eats nearly 100% of my CPU till I send it a
>>> SIGKILL...Please help. :)
>>
>>> Thanks
>>
>> Does it always hang, even if you start it as
>>
>>          vim -N -u NONE
>> or
>>          gvim -N -u NONE
>> ?
>>
>> Best regards,
>> Tony.
>> --
>> Re graphics: A picture is worth 10K words -- but only those to describe
>> the picture.  Hardly any sets of 10K words can be adequately described
>> with pictures.
>
> It appears to work fine launching vim with -N -u NONE, when not
> launching with '-N -u NONE', i've so far narrowed it down to 2
> filetypes. I tried opening a ruby script, a perl script, a python
> script and a C++ source file and the only ones that failed and caused
> vim to lock were the ruby script and the perl script. I moved the
> affected scripts to a different directory (same dir as the C++ source)
> and the issue still occurred and as far as i can tell, the permissions
> on all 4 files are the same.
>

Hm. This is a little bit out of my depth, but I suggest the following:

- does the hang still happen when editing these filetypes in a Vim
started with

	 vim -u /usr/local/share/vim/vim72/vimrc_example.vim

? (assuming that that's your $VIMRUNTIME directory -- it should be,
unless you changed the default at compile-time or unless you're using an
obsolete version older than 7.2.0)

- did you compile with +ruby or -ruby, +perl or -perl ? (see the output
of ":version" -- if you enable them at configure-time, but configure
doesn't find the right files, it will turn them off)
- do you have any "custom" scripts (scripts not distributed with Vim)
which apply to Perl and/or Ruby? (and which ones if you do?)
- what are the dates mentioned near the top of the _text_ of the
following scripts? I'm mentioning what I see in mine

	 $VIMRUNTIME/filetype.vim 2009 Sep 18
	 $VIMRUNTIME/ftplugin/perl.vim 20 Jan 2009
	 $VIMRUNTIME/ftplugin/ruby.vim 2008/06/29 04:18:43
	 $VIMRUNTIME/syntax/perl.vim 2006 November 23
	 $VIMRUNTIME/syntax/ruby.vim 2008/06/29 04:33:41
	 $VIMRUNTIME/indent/perl.vim 2005 Sep 07
	 $VIMRUNTIME/indent/ruby.vim 2008/06/29 04:18:43

- does the hang happen if you do
	 (a) syntax off
	 (b) filetype indent off
	 (c) filetype plugin off
before editing the files? (try them one at a time, and turn them back on
afterwards)


Best regards,
Tony.
--
The law will never make men free; it is men who have got to make the
law free.
		 -- Henry David Thoreau

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

On 03/12/09 09:58, Dominique Pellé wrote:
[...]
> The output of backtrace may help to figure out why it hogs the CPU.
> You will need to compile/link Vim with symbols (-g -O0) to get a proper
> stack trace with gdb.
>
> -- Dominique
>

...and, of course, run the non-stripped executable, i.e., the one in the
same directory as the source, NOT the one which "make install" copied
into the $PATH.


Best regards,
Tony.
--
It has been said that man is a rational animal.  All my life I have
been searching for evidence which could support this.
		 -- Bertrand Russell

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

On 12/02/2009 11:59 AM, Bram Moolenaar wrote:
> Patch 7.2.315
> Problem:    Python libs can't be found on 64 bit system.
> Solution:   Add lib64 to the list of directories. (Michael Henry)
> Files:     src/auto/configure, src/configure.in
>

Thanks, Bram, I can confirm that this patch works for me.

Michael Henry

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

On Dec 3, 2:14 am, "John Beckett" <johnb.beck...@...> wrote:
> Steve Hall wrote:
> > Hmm, so then the original MyDiff() might have been ok for you?
>
> No. People have complained on the wiki that the "Vim without
> Cream" distribution does NOT work with diff. There were several
> misguided suggestions for how to make it work. Last March, I did
> some quick investigations and rewrote the tip:
>
> http://vim.wikia.com/wiki/Running_diff

I was wondering why I hadn't discovered this problem, and then I
realised it's because I haven't used the _vimrc that "Vim without
Cream" uses since I first installed Vim. Diffing with Vim on Windows
works excellently with 'diffexpr=', and I suggest that Steve removes
the setting of 'diffexpr' and the MyDiff() function from the default
_vimrc.

While we're at it, I also suggest removing 'source $VIMRUNTIME/
mswin.vim'. It might seem that it makes the transition to Vim for
windows users easier, when all it really does is delay the inevitable
'learn to use Vim the way it was meant to be used' brick wall that
every user has to run into sooner or later. At the very least, there
should be a warning sign on that line, saying that using 'mswin.vim'
changes the default behaviour of Vim, and that it might cause
confusion when asking for help. (Also note that 'mswin.vim' does
'behave mswin', so that line is redundant anyway.)

I'd prefer just using 'vimrc_example.vim' as the default _vimrc for
Windows. It contains good defaults, and good comments, and it helps
the user to understand what the _vimrc is. For more opinions, I think
raising the question on vim_use would be a good idea.

Henrik.

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

Hi,

I've got a bugreport that you might end up with invalid syntax files when the automated download for new spell files is used.

On Thu, Dec 03, 2009 at 01:06:54PM +0100, Karsten Hopp wrote:
> Hi,
>
> I've got a bugreport that you might end up with invalid syntax files
> when the automated download for new spell files is used.
> That's https://bugzilla.redhat.com/show_bug.cgi?id=518791
>
> It looks like elinks -dump formats the contents of the downloaded file,
> try p.e.
>
> elinks 'http://ftp.vim.org/pub/vim/runtime/spell/de.utf-8.spl' -dump >
> de.utf-8.spl_elinks   and compare it with
> lynx 'http://ftp.vim.org/pub/vim/runtime/spell/de.utf-8.spl' -dump >
> de.utf-8.spl_lynx
>
> This can be avoided by using -source instead of -dump for the elinks
> command in autoload/netrw.vim

I've previously sent a patch to Chip (attached here too) to revert
netrw's default behavior back to using -source instead of -dump, but got
no response.  My reasoning was mainly that it was a change in behavior
and wasn't consistent among the tools netrw will use for http downloads.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@...>

James Vega wrote:
> On Thu, Dec 03, 2009 at 01:06:54PM +0100, Karsten Hopp wrote:
>
>> Hi,
>>
>> I've got a bugreport that you might end up with invalid syntax files
>> when the automated download for new spell files is used.
>> That's https://bugzilla.redhat.com/show_bug.cgi?id=518791
>>
>> It looks like elinks -dump formats the contents of the downloaded file,
>> try p.e.
>>
>> elinks 'http://ftp.vim.org/pub/vim/runtime/spell/de.utf-8.spl' -dump >
>> de.utf-8.spl_elinks   and compare it with
>> lynx 'http://ftp.vim.org/pub/vim/runtime/spell/de.utf-8.spl' -dump >
>> de.utf-8.spl_lynx
>>
>> This can be avoided by using -source instead of -dump for the elinks
>> command in autoload/netrw.vim
>>
>
> I've previously sent a patch to Chip (attached here too) to revert
> netrw's default behavior back to using -source instead of -dump, but got
> no response.  My reasoning was mainly that it was a change in behavior
> and wasn't consistent among the tools netrw will use for http downloads.
>
>
I do remember your patch, James, but there wasn't a reason other than,
presumably, preference.  I'd thought that I'd communicated that before.
However, Karsten has come up with a good reason for reverting back to
-dump.  So, netrw v136q now has -dump as its default (mentioning -source
in the help).

Its now available at my website
(http://mysite.verizon.net/astronaut/vim/index.html).  I have a bug to
fix before I release it as v136 to Bram.

Regards,
Chip Campbell

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

On Thu, Dec 3, 2009 at 12:30 PM, Charles Campbell
<Charles.E.Campbell@...> wrote:
> James Vega wrote:
>> On Thu, Dec 03, 2009 at 01:06:54PM +0100, Karsten Hopp wrote:
>>
>>> Hi,
>>>
>>> I've got a bugreport that you might end up with invalid syntax files
>>> when the automated download for new spell files is used.
>>> That's https://bugzilla.redhat.com/show_bug.cgi?id=518791
>>>
>>> It looks like elinks -dump formats the contents of the downloaded file,
>>> try p.e.
>>>
>>> elinks 'http://ftp.vim.org/pub/vim/runtime/spell/de.utf-8.spl' -dump >
>>> de.utf-8.spl_elinks   and compare it with
>>> lynx 'http://ftp.vim.org/pub/vim/runtime/spell/de.utf-8.spl' -dump >
>>> de.utf-8.spl_lynx
>>>
>>> This can be avoided by using -source instead of -dump for the elinks
>>> command in autoload/netrw.vim
>>>
>>
>> I've previously sent a patch to Chip (attached here too) to revert
>> netrw's default behavior back to using -source instead of -dump, but got
>> no response.  My reasoning was mainly that it was a change in behavior
>> and wasn't consistent among the tools netrw will use for http downloads.
>>
>>
> I do remember your patch, James, but there wasn't a reason other than,
> presumably, preference.  I'd thought that I'd communicated that before.

The inconsistency among the different http handlers was my main concern,
as the default behavior of netrw varied based on which http handler was
present.

The secondary concern was the change in behavior, but I do understand
your take on preference.

Your reply must have been rejected at Debian's end since I uploaded a
fix with my patch and closed the bug.  Once the bug got archived, it
doesn't accept further correspondence without being unarchived first.

> However, Karsten has come up with a good reason for reverting back to
> -dump.  So, netrw v136q now has -dump as its default (mentioning -source
> in the help).

Thanks! :)

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

On Dec 3, 4:26 am, Tony Mechelynck <antoine.mechely...@...>
wrote:
> On 03/12/09 08:03, JD wrote:
>
>
>
> > On Dec 3, 1:46 am, Tony Mechelynck<antoine.mechely...@...>
> > wrote:
> >> On 03/12/09 05:20, JD wrote:
>
> >>> Vim is hardlocking for me on every single run on my FreeBSD 5.4
> >>> system. I've tried 7.2.299, 7.2.309 and 7.2.315 and all are broken.
>
> >>> It appears to compile fine, but on run, it fails to respond to any
> >>> keystrokes and eats nearly 100% of my CPU till I send it a
> >>> SIGKILL...Please help. :)
>
> >>> Thanks
>
> >> Does it always hang, even if you start it as
>
> >>          vim -N -u NONE
> >> or
> >>          gvim -N -u NONE
> >> ?
>
> >> Best regards,
> >> Tony.
> >> --
> >> Re graphics: A picture is worth 10K words -- but only those to describe
> >> the picture.  Hardly any sets of 10K words can be adequately described
> >> with pictures.
>
> > It appears to work fine launching vim with -N -u NONE, when not
> > launching with '-N -u NONE', i've so far narrowed it down to 2
> > filetypes. I tried opening a ruby script, a perl script, a python
> > script and a C++ source file and the only ones that failed and caused
> > vim to lock were the ruby script and the perl script. I moved the
> > affected scripts to a different directory (same dir as the C++ source)
> > and the issue still occurred and as far as i can tell, the permissions
> > on all 4 files are the same.
>
> Hm. This is a little bit out of my depth, but I suggest the following:
>
> - does the hang still happen when editing these filetypes in a Vim
> started with
>
>         vim -u /usr/local/share/vim/vim72/vimrc_example.vim
>
> ? (assuming that that's your $VIMRUNTIME directory -- it should be,
> unless you changed the default at compile-time or unless you're using an
> obsolete version older than 7.2.0)
>
> - did you compile with +ruby or -ruby, +perl or -perl ? (see the output
> of ":version" -- if you enable them at configure-time, but configure
> doesn't find the right files, it will turn them off)
> - do you have any "custom" scripts (scripts not distributed with Vim)
> which apply to Perl and/or Ruby? (and which ones if you do?)
> - what are the dates mentioned near the top of the _text_ of the
> following scripts? I'm mentioning what I see in mine
>
>         $VIMRUNTIME/filetype.vim        2009 Sep 18
>         $VIMRUNTIME/ftplugin/perl.vim   20 Jan 2009
>         $VIMRUNTIME/ftplugin/ruby.vim   2008/06/29 04:18:43
>         $VIMRUNTIME/syntax/perl.vim     2006 November 23
>         $VIMRUNTIME/syntax/ruby.vim     2008/06/29 04:33:41
>         $VIMRUNTIME/indent/perl.vim     2005 Sep 07
>         $VIMRUNTIME/indent/ruby.vim     2008/06/29 04:18:43
>
> - does the hang happen if you do
>         (a) syntax off
>         (b) filetype indent off
>         (c) filetype plugin off
> before editing the files? (try them one at a time, and turn them back on
> afterwards)
>
> Best regards,
> Tony.
> --
> The law will never make men free; it is men who have got to make the
> law free.
>                 -- Henry David Thoreau

Here's the output of version:

VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Dec  3 2009 06:48:09)
Included patches: 1-315
Compiled by jdhore@...
Big version with GTK 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
+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
+postscript
+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_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  -I/usr/
local/include/gtk12 -I/usr/local/include/glib12 -I/usr/local/include -
I/usr/X11R6/include -I/usr/local/include  -g
Linking: gcc   -L/usr/local/lib -o vim   -L/usr/local/lib -L/usr/X11R6/
lib -lgtk-12 -lgdk-12 -Wl,-E -lgmodule-12 -lglib-12 -lintl -lXi -lXext
-lXt -lm -lncurses  -lintl

dates of those files:

$VIMRUNTIME/filetype.vim        2009 Dec 3 06:48 (UTC/GMT)
$VIMRUNTIME/ftplugin/perl.vim   2009 Dec 3 06:48
$VIMRUNTIME/ftplugin/ruby.vim   2009 Dec 3 06:48
$VIMRUNTIME/syntax/perl.vim     2009 Dec 3 06:48
$VIMRUNTIME/syntax/ruby.vim     2009 Dec 3 06:48
$VIMRUNTIME/indent/perl.vim     2009 Dec 3 06:48
$VIMRUNTIME/indent/ruby.vim     2009 Dec 3 06:48

The only custom scripts i have installed are: SyntaxAttr, BufExplorer,
securemodelines and taglist none of which (i believe) are ruby/perl
specific.

When i ran with 'vim -u /usr/local/share/vim/vim72/vimrc_example.vim',
it still hung. Also, gdb hasn't given me a useful backtrace.

With syntax, indent and plugin all off, the file(s) open fine.With
just syntax on, the file(s) open fine. With syntax and indent on, the
file(s) open fine. When i enabled plugin, that's when vim started
hanging. I removed all 4 plugins from .vim/plugin (the only place i
have any plugins) and with 'filetype plugin on', it still hung.

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

On 03/12/09 21:16, JD wrote:
> On Dec 3, 4:26 am, Tony Mechelynck<antoine.mechely...@...>
> wrote:
>> On 03/12/09 08:03, JD wrote:
>>
>>
>>
>>> On Dec 3, 1:46 am, Tony Mechelynck<antoine.mechely...@...>
>>> wrote:
>>>> On 03/12/09 05:20, JD wrote:
>>
>>>>> Vim is hardlocking for me on every single run on my FreeBSD 5.4
>>>>> system. I've tried 7.2.299, 7.2.309 and 7.2.315 and all are broken.
>>
>>>>> It appears to compile fine, but on run, it fails to respond to any
>>>>> keystrokes and eats nearly 100% of my CPU till I send it a
>>>>> SIGKILL...Please help. :)
>>
>>>>> Thanks
>>
>>>> Does it always hang, even if you start it as
>>
>>>>           vim -N -u NONE
>>>> or
>>>>           gvim -N -u NONE
>>>> ?
>>
>>>> Best regards,
>>>> Tony.
>>>> --
>>>> Re graphics: A picture is worth 10K words -- but only those to describe
>>>> the picture.  Hardly any sets of 10K words can be adequately described
>>>> with pictures.
>>
>>> It appears to work fine launching vim with -N -u NONE, when not
>>> launching with '-N -u NONE', i've so far narrowed it down to 2
>>> filetypes. I tried opening a ruby script, a perl script, a python
>>> script and a C++ source file and the only ones that failed and caused
>>> vim to lock were the ruby script and the perl script. I moved the
>>> affected scripts to a different directory (same dir as the C++ source)
>>> and the issue still occurred and as far as i can tell, the permissions
>>> on all 4 files are the same.
>>
>> Hm. This is a little bit out of my depth, but I suggest the following:
>>
>> - does the hang still happen when editing these filetypes in a Vim
>> started with
>>
>>          vim -u /usr/local/share/vim/vim72/vimrc_example.vim
>>
>> ? (assuming that that's your $VIMRUNTIME directory -- it should be,
>> unless you changed the default at compile-time or unless you're using an
>> obsolete version older than 7.2.0)
>>
>> - did you compile with +ruby or -ruby, +perl or -perl ? (see the output
>> of ":version" -- if you enable them at configure-time, but configure
>> doesn't find the right files, it will turn them off)
>> - do you have any "custom" scripts (scripts not distributed with Vim)
>> which apply to Perl and/or Ruby? (and which ones if you do?)
>> - what are the dates mentioned near the top of the _text_ of the
>> following scripts? I'm mentioning what I see in mine
>>
>>          $VIMRUNTIME/filetype.vim        2009 Sep 18
>>          $VIMRUNTIME/ftplugin/perl.vim   20 Jan 2009
>>          $VIMRUNTIME/ftplugin/ruby.vim   2008/06/29 04:18:43
>>          $VIMRUNTIME/syntax/perl.vim     2006 November 23
>>          $VIMRUNTIME/syntax/ruby.vim     2008/06/29 04:33:41
>>          $VIMRUNTIME/indent/perl.vim     2005 Sep 07
>>          $VIMRUNTIME/indent/ruby.vim     2008/06/29 04:18:43
>>
>> - does the hang happen if you do
>>          (a) syntax off
>>          (b) filetype indent off
>>          (c) filetype plugin off
>> before editing the files? (try them one at a time, and turn them back on
>> afterwards)
>>
>> Best regards,
>> Tony.
>> --
>> The law will never make men free; it is men who have got to make the
>> law free.
>>                  -- Henry David Thoreau
>
> Here's the output of version:
>
> VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Dec  3 2009 06:48:09)
> Included patches: 1-315
> Compiled by jdhore@...
> Big version with GTK 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
> +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
> +postscript
> +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_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  -I/usr/
> local/include/gtk12 -I/usr/local/include/glib12 -I/usr/local/include -
> I/usr/X11R6/include -I/usr/local/include  -g
> Linking: gcc   -L/usr/local/lib -o vim   -L/usr/local/lib -L/usr/X11R6/
> lib -lgtk-12 -lgdk-12 -Wl,-E -lgmodule-12 -lglib-12 -lintl -lXi -lXext
> -lXt -lm -lncurses  -lintl

No perl and no ruby. If the ftplugins assume that you got the interfaces
if you edit the files, you're stuck. The versions I have don't seem to,
though (ftplugin/perl.vim doesn't call the Vim/Perl interface and
ftplugin/ruby.vim properly tests <if has("ruby")> AFAICT. However, there
could be something I didn't notice.

>
> dates of those files:
>
> $VIMRUNTIME/filetype.vim        2009 Dec 3 06:48 (UTC/GMT)
> $VIMRUNTIME/ftplugin/perl.vim   2009 Dec 3 06:48
> $VIMRUNTIME/ftplugin/ruby.vim   2009 Dec 3 06:48
> $VIMRUNTIME/syntax/perl.vim     2009 Dec 3 06:48
> $VIMRUNTIME/syntax/ruby.vim     2009 Dec 3 06:48
> $VIMRUNTIME/indent/perl.vim     2009 Dec 3 06:48
> $VIMRUNTIME/indent/ruby.vim     2009 Dec 3 06:48

Sorry, you misunderstood me. I didn't want the modification dates as set
out in the directory (which are the dates you installed these files) but
the dates mentioned in the _text_ of the files, somewhere near the top,
which are the "Last change" dates written there by whoever edited them.

>
> The only custom scripts i have installed are: SyntaxAttr, BufExplorer,
> securemodelines and taglist none of which (i believe) are ruby/perl
> specific.
>
> When i ran with 'vim -u /usr/local/share/vim/vim72/vimrc_example.vim',
> it still hung. Also, gdb hasn't given me a useful backtrace.
>
> With syntax, indent and plugin all off, the file(s) open fine.With
> just syntax on, the file(s) open fine. With syntax and indent on, the
> file(s) open fine. When i enabled plugin, that's when vim started
> hanging. I removed all 4 plugins from .vim/plugin (the only place i
> have any plugins) and with 'filetype plugin on', it still hung.
>

You also have the filetype-plugins distributed with Vim, namely
$VIMRUNTIME/ftplugin/perl.vim and $VIMRUNTIME/ftplugin/ruby.vim. These
are enabled/disabled by "filetype plugin on/off".


Best regards,
Tony.
--
"The identical is equal to itself, since it is different."
		 -- Franco Spisani

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

On Thu, 2009-12-03 at 03:49 -0800, Henrik Öhman wrote:
>
> I was wondering why I hadn't discovered this problem, and then I
> realised it's because I haven't used the _vimrc that "Vim without
> Cream" uses since I first installed Vim.

I have to admit, I haven't used a default vimrc since 1999. :)

> Diffing with Vim on Windows works excellently with 'diffexpr=', and
> I suggest that Steve removes the setting of 'diffexpr' and the
> MyDiff() function from the default _vimrc.

It is up to the Vim project (Bram) to decide what the default _vimrc
is, our distro is simply going to mirror it.

> While we're at it, I also suggest removing 'source $VIMRUNTIME/
> mswin.vim'. It might seem that it makes the transition to Vim for
> windows users easier, when all it really does is delay the
> inevitable 'learn to use Vim the way it was meant to be used' brick
> wall that every user has to run into sooner or later. At the very
> least, there should be a warning sign on that line, saying that
> using 'mswin.vim' changes the default behaviour of Vim, and that it
> might cause confusion when asking for help. (Also note that
> 'mswin.vim' does 'behave mswin', so that line is redundant anyway.)

Again, I believe referencing mswin in the vimrc is the default, which
is the only reason our distro does it.

I agree with your sentiments regarding the suitability of mswin, too,
although in addition to your "learning Vim" concerns, I include that
it also doesn't go far enough to help on the other side. Windows
applications (as well as Mac and Gnome ones) use a whole set of common
interface rules that mswin does not address, and so a user referencing
it is left in a sort of semi-Vim state. (And no where close to a CUA
state as they might expect.) Say, I know a configuration that does
this though... :)

> I'd prefer just using 'vimrc_example.vim' as the default _vimrc for
> Windows. It contains good defaults, and good comments, and it helps
> the user to understand what the _vimrc is. For more opinions, I
> think raising the question on vim_use would be a good idea.

I'm happy to adjust our distro to do whatever ends up in the default
Vim distribution.


--
Steve Hall  [ digitect dancingpaper com ]


--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

On 03/12/09 12:49, Henrik Öhman wrote:
> On Dec 3, 2:14 am, "John Beckett"<johnb.beck...@...>  wrote:
>> Steve Hall wrote:
>>> Hmm, so then the original MyDiff() might have been ok for you?
>>
>> No. People have complained on the wiki that the "Vim without
>> Cream" distribution does NOT work with diff. There were several
>> misguided suggestions for how to make it work. Last March, I did
>> some quick investigations and rewrote the tip:
>>
>> http://vim.wikia.com/wiki/Running_diff
>
> I was wondering why I hadn't discovered this problem, and then I
> realised it's because I haven't used the _vimrc that "Vim without
> Cream" uses since I first installed Vim. Diffing with Vim on Windows
> works excellently with 'diffexpr=', and I suggest that Steve removes
> the setting of 'diffexpr' and the MyDiff() function from the default
> _vimrc.
>
> While we're at it, I also suggest removing 'source $VIMRUNTIME/
> mswin.vim'. It might seem that it makes the transition to Vim for
> windows users easier, when all it really does is delay the inevitable
> 'learn to use Vim the way it was meant to be used' brick wall that
> every user has to run into sooner or later. At the very least, there
> should be a warning sign on that line, saying that using 'mswin.vim'
> changes the default behaviour of Vim, and that it might cause
> confusion when asking for help. (Also note that 'mswin.vim' does
> 'behave mswin', so that line is redundant anyway.)

I suggested years ago that mswin.vim be removed (when still on Vim 6.1
[my first Vim], I think, and in any case no later than 6.3) and AFAICT
most experienced Vim hands find mswin.vim a nuisance, but IIUC Bram was
(and is?) against it. Some people think that making Vim look "more like
Notepad" will bring more Windows users to Vim; I think that Vim is Vim,
Notepad is Notepad, and whoever tries to mix them up is bound to end up
with a self-inflicted shotgun wound in his foot.

>
> I'd prefer just using 'vimrc_example.vim' as the default _vimrc for
> Windows. It contains good defaults, and good comments, and it helps
> the user to understand what the _vimrc is. For more opinions, I think
> raising the question on vim_use would be a good idea.
>
> Henrik.
>

I regard vimrc_example.vim as a good starting point for a vimrc on any
platform. My recommendation is to start with a vimrc containing just

	 runtime vimrc_example.vim

and then, as time goes by, add more customizations below that (or very
rarely above it).


Best regards,
Tony.
--
Would you mind terribly much if I asked you to take your silly-assed
problem down the hall?

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

On Wed, Dec 02, 2009 at 08:20:40PM -0800, JD wrote:
> Vim is hardlocking ... FreeBSD 5.4

No offense, but are you really using such an old (2005-vintage) FreeBSD release?

Or is it really OpenBSD 5.4, a much more recent product?

--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Gregory H. Margo
gmargo at yahoo/com, gmail/com, pacbell/net; greg at margofamily/org

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

On Dec 3, 10:21 pm, Gregory Margo <gma...@...> wrote:
> On Wed, Dec 02, 2009 at 08:20:40PM -0800, JD wrote:
> > Vim is hardlocking ... FreeBSD 5.4
>
> No offense, but are you really using such an old (2005-vintage) FreeBSD
release?
>
> Or is it really OpenBSD 5.4, a much more recent product?
>
> --
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Gregory H. Margo
> gmargo at yahoo/com, gmail/com, pacbell/net; greg at margofamily/org

Because it's a production-level server (with well over a 2 years of
uptime at this point) and it's in a remote location and FreeBSD is not
a good OS to update remotely if you follow the recommended way to
update.

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

Hi Bram,
I just discoverd that uil.vim (maintained by me) as shipped with
vim 7.2 lists a wrong URL (no longer valid). The version on
http://gott-gehabt.de/800_wer_wir_sind/thomas/Homepage/Computer/vim/syntax/uil.v\
im
is correct, the 2 changed lines lead to a small diff:

~VIM/vim72/syntax> diff -u uil.vim
~/public_html/gg/800_wer_wir_sind/thomas/Homepage/Computer/vim/syntax/uil.vim
--- uil.vim     2008-08-10 06:24:10.000000000 +0200
+++
/home/jean-luc/public_html/gg/800_wer_wir_sind/thomas/Homepage/Computer/vim/synt\
ax/uil.vim       2009-07-29 11:57:40.000000000 +0200
@@ -1,8 +1,8 @@
  " Vim syntax file
  " Language:    Motif UIL (User Interface Language)
  " Maintainer:  Thomas Koehler <jean-luc@...>
-" Last Change: 2002 Sep 20
-" URL:         http://jeanluc-picard.de/vim/syntax/uil.vim
+" Last Change: 2005 March 14
+" URL:        
http://gott-gehabt.de/800_wer_wir_sind/thomas/Homepage/Computer/vim/syntax/uil.v\
im

  " Quit when a syntax file was already loaded
  if version < 600
~VIM/vim72/syntax>

Once checking syntax files, I found there is also a small error
in prolog.vim - also the URL is not correct.
It should be
http://gott-gehabt.de/800_wer_wir_sind/thomas/Homepage/Computer/vim/syntax/prolo\
g.vim
                   ^^^
                   missing...
Here is the diff for that one:

~VIM/vim72/syntax> diff -u prolog.vim
~/public_html/gg/800_wer_wir_sind/thomas/Homepage/Computer/vim/syntax/prolog.vim
--- prolog.vim  2009-04-06 10:10:45.000000000 +0200
+++
/home/jean-luc/public_html/gg/800_wer_wir_sind/thomas/Homepage/Computer/vim/synt\
ax/prolog.vim    2009-12-04 11:01:31.000000000 +0100
@@ -1,8 +1,8 @@
  " Vim syntax file
  " Language:    PROLOG
  " Maintainers: Thomas Koehler <jean-luc@...>
-" Last Change: 2009 April 6
-" URL:       
http://gott-gehabt/800_wer_wir_sind/thomas/Homepage/Computer/vim/syntax/prolog.v\
im
+" Last Change: 2009 December 4
+" URL:       
http://gott-gehabt.de/800_wer_wir_sind/thomas/Homepage/Computer/vim/syntax/prolo\
g.vim

  " There are two sets of highlighting in here:
  " If the "prolog_highlighting_clean" variable exists, it is rather sparse.
~VIM/vim72/syntax>

Sorry for the extra work I present to you.

Ciao,
Thomas

--
  Thomas Köhler       Email:       jean-luc@...
      <><             WWW:              http://gott-gehabt.de
                      IRC:                           tkoehler
                      PGP public key available from Homepage!

Dear vimmers,

I just occured a possible bug in vim. Instead of search and replace via
the substiute command I performed a macro record, recording a search
:/STRING
and a
ce
and typing something.
If I execute the recorded macro, it does not open the fold after jumping
to the found location and therefore deletes the whole line instead of
only the word. That is strange, since the foldopen option contains
search and works as expected outside macros. Is this behaviour known?

Kind regards,
Andre

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

Hi,

Andre Massing wrote:
>
> I just occured a possible bug in vim. Instead of search and replace via
> the substiute command I performed a macro record, recording a search
> :/STRING
> and a
> ce
> and typing something.
> If I execute the recorded macro, it does not open the fold after jumping
> to the found location and therefore deletes the whole line instead of
> only the word. That is strange, since the foldopen option contains
> search and works as expected outside macros. Is this behaviour known?

yes, and it's not a bug. It's even documented at

   :help 'foldopen'

Scroll down and have a look at the first paragraph after the allowed
items for 'foldopen'.

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)

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

Hi,

How can I change script type of my vim plugin?
It is 'ftplugin' at the moment but I'd like it to be 'utility'

http://www.vim.org/scripts/script.php?script_id=2226


Best wishes,
Maxim.

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

On 29 nov, 04:37, char101 <peac...@...> wrote:
> On Nov 28, 6:17 am, epanda <callingel...@...> wrote:
>
> > Hi,
>
> > Actually using Gvim on Xp, I would like to have a toolbar with
> > iconsize 32x32.
>
> > I have modifiedtools.bmpin order to pass size from 558x18 to 992x32.
>
> > Do I have only to build with this newtools.bmp?
>
> Hi,
>
> You'll also need to edit gui.h (around line 164)
>
> #ifdef FEAT_GUI_W16
> # define TOOLBAR_BUTTON_HEIGHT  15
> # define TOOLBAR_BUTTON_WIDTH   16
> #else
> # define TOOLBAR_BUTTON_HEIGHT  16
> # define TOOLBAR_BUTTON_WIDTH   16
> #endif


I try to edit a new tools.bmp but do I need to make a 8bits Bmp ? and
for 32 pixel height, is the width is 1116 ?
When I build, I have the four icon of tools.bmp not visible.
It seems that the toolbar is move to the left.
Thanks.

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

Thomas Koehler wrote:

> I just discoverd that uil.vim (maintained by me) as shipped with
> vim 7.2 lists a wrong URL (no longer valid). The version on
>
http://gott-gehabt.de/800_wer_wir_sind/thomas/Homepage/Computer/vim/syntax/uil.v\
im
> is correct, the 2 changed lines lead to a small diff:
[...]
>
> Once checking syntax files, I found there is also a small error
> in prolog.vim - also the URL is not correct.

Thanks, I'll include the changes.

--
hundred-and-one symptoms of being an internet addict:
15. Your heart races faster and beats irregularly each time you see a new WWW
     site address in print or on TV, even though you've never had heart
     problems before.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

On 17/11/09 22:13, Bram Moolenaar wrote:
> Dominique Pelle wrote:
[...]
>> I assumed that variables in .bss (search_hl in this case) are always
>> initialized to 0. Out of curiousity, on which version of Vim that is not
>> the case?
>>
>> =========================================
>> $ man elf
>> ...
>> Various sections hold program and control information:
>>
>> .bss      This section holds uninitialized data that contributes to the
>>            program’s  memory  image.  By definition, the system initial�
>>            izes the data with zeros when  the  program  begins  to  run.
>>            This  section is of type SHT_NOBITS.  The attribute types are
>>            SHF_ALLOC and SHF_WRITE.
>>        ...
>> =========================================
>
> On modern systems this should happen.  But there are a few systems where
> this does not happen.
[...]

The above is for elf binaries as used on Linux. But ISTR (somewhat
hazily, it was years and years ago, and on Dos, so don't take my word
for it) that the BSS segment (the heap IIRC) is usually left
uninitialized (i.e. whatever was there before loading the program; maybe
part of the compressed image in self-uncompressing binaries). That would
be in .EXE executables.


Best regards,
Tony.
--
Scott's second Law:
	 When an error has been detected and corrected, it will be found
to have been wrong in the first place.

Corollary:
	 After the correction has been found in error, it will be
impossible to fit the original quantity back into the equation.

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

Jürgen Krämer wrote:
> Hi,
>
> Andre Massing wrote:
>> I just occured a possible bug in vim. Instead of search and replace via
>> the substiute command I performed a macro record, recording a search
>> :/STRING
>> and a
>> ce
>> and typing something.
>> If I execute the recorded macro, it does not open the fold after jumping
>> to the found location and therefore deletes the whole line instead of
>> only the word. That is strange, since the foldopen option contains
>> search and works as expected outside macros. Is this behaviour known?
>
> yes, and it's not a bug. It's even documented at
>
>   :help 'foldopen'
>
> Scroll down and have a look at the first paragraph after the allowed
> items for 'foldopen'.

Thanks for the explanation and pointer, I scanned through it yesterday
but rushed through. Next time I will read more carefully, promised :)

Regards,
Andre

>
> Regards,
> Jürgen
>

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

Hi,

I would like to use a better resolution for icons.

Like icons of this site http://icones.pro/dossier-vert-ouvert-image-png.html.



When I edit tools.bmp under adobe photoshop it says the file is 8bits
indexed color.

Can I modifiy code in order to use a bmp with higher resolution ? 16
or 24bits ?

Thanks

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php

Hi

I can reproduce the following error (access to freed memory)
with Vim-7.2.315 (Motif GUI):

==31168== Invalid read of size 4
==31168==    at 0x484BDE7: XtDisplay (in /usr/lib/libXt.so.6.0.0)
==31168==    by 0x81EDAF9: gui_mch_init_font (gui_x11.c:1853)
==31168==    by 0x81E0324: gui_init_font (gui.c:715)
==31168==    by 0x815C376: did_set_string_option (option.c:6116)
==31168==    by 0x8159DBC: do_set (option.c:4679)
==31168==    by 0x80D12B7: ex_set (ex_docmd.c:10983)
==31168==    by 0x80C49D3: do_one_cmd (ex_docmd.c:2627)
==31168==    by 0x80C22AC: do_cmdline (ex_docmd.c:1096)
==31168==    by 0x81463F2: nv_colon (normal.c:5224)
==31168==    by 0x813FDEF: normal_cmd (normal.c:1188)
==31168==    by 0x8103CE4: main_loop (main.c:1204)
==31168==    by 0x81037DB: main (main.c:948)
==31168==  Address 0x5a77e30 is 88 bytes inside a block of size 312 free'd
==31168==    at 0x4024B56: free (vg_replace_malloc.c:325)
==31168==    by 0x4835E90: XtFree (in /usr/lib/libXt.so.6.0.0)
==31168==    by 0x48408ED: ??? (in /usr/lib/libXt.so.6.0.0)
==31168==    by 0x4840213: ??? (in /usr/lib/libXt.so.6.0.0)
==31168==    by 0x4840377: ??? (in /usr/lib/libXt.so.6.0.0)
==31168==    by 0x484062A: _XtDoPhase2Destroy (in /usr/lib/libXt.so.6.0.0)
==31168==    by 0x4840791: XtDestroyWidget (in /usr/lib/libXt.so.6.0.0)
==31168==    by 0x81F55FB: gui_xm_select_font (gui_xmdlg.c:1277)
==31168==    by 0x81EDAF9: gui_mch_init_font (gui_x11.c:1853)
==31168==    by 0x81E0324: gui_init_font (gui.c:715)
==31168==    by 0x815C376: did_set_string_option (option.c:6116)
==31168==    by 0x8159DBC: do_set (option.c:4679)
==31168==    by 0x80D12B7: ex_set (ex_docmd.c:10983)
==31168==    by 0x80C49D-3: do_one_cmd (ex_docmd.c:2627)
==31168==    by 0x80C22AC: do_cmdline (ex_docmd.c:1096)
==31168==    by 0x81463F2: nv_colon (normal.c:5224)
==31168==    by 0x813FDEF: normal_cmd (normal.c:1188)
==31168==    by 0x8103CE4: main_loop (main.c:1204)
==31168==    by 0x81037DB: main (main.c:948)

Steps to reproduce:

1) Start Vim with Valgrind:
    $ cd vim7/src
    $ valgrind --num-callers=20 ./vim -f -g -u NONE -U NONE 2> vg.log

2) Type Ex command:
    :set guifont=*

3) A modal window pops up to select a font, click on the
    "Cancel" button.

4) Observe the above Valgrind error as soon as you click on
    "Cancel".


src/gui_xmdlg.c:

1272  /* modal event loop */
1273  while (!data->exit)
1274      XtAppProcessEvent(XtWidgetToApplicationContext(data->dialog),
1275                                                      (XtInputMask)XtIMAll);
1276
1277  XtDestroyWidget(data->dialog);
1278
1279  if (data->old)
1280  {
1281      XFreeFont(XtDisplay(data->dialog),  data->old);
1282      XmFontListFree(data->old_list);
1283  }

data->dialog is destroyed at line gui_xmdlg.c:1277 but still
used just below at line gui_xmdlg.c:1281.

Attached patch fixes it.

Stack trace reported by Valgrind is slightly incorrect
by the way (not sure why) since XtDisplay() is called from:

   XtDisplay
   gui_xm_select_font (gui_xmdlg.c:1281)
   gui_mch_init_font (gui_x11.c:1853)

and not from:

   XtDisplay()
   gui_mch_init_font() (gui_x11.c:1853)

Cheers
-- Dominique

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php