Hi, I've been getting the following warnings in terminal when using
gtk vim on recent versions of ubuntu:
LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that doesn't
believe we're it's parent.
For example, the warning triggered by selecting some file for editing
with netrw plugin:
start
2011/10/29 Thilo Six t@gmx.de:
attached is a example file. When searching in there with:
/vi\|vim
or
/vim\|vi
does not give the same results. Which is what i would expect.
This is the intended behavior. From :help regexp:
A pattern is one or more branches, separated by \|. ...
If more
Hello,
After updating to vim 7.3.347+ I started to get Gtk-WARNING **:
unable to find signal handler for object ... warnings in console
while using gvim.
I build vim with flags --with-features=huge --enable-gui=gnome2.
Here is how I can reliable reproduce the problem on my system (a
customized
Attached are stack traces of these warnings. Warnings are printed
inside removeEventHandler() at gui_beval.c:479..487 as a result of
some let beval = ... statement.
Apparently, removeEventHandler() is called twice somewhere.
--
You received this message from the vim_dev maillist.
Do not
On Tue, Nov 29, 2011 at 22:49, Bram Moolenaar b...@moolenaar.net wrote:
Just guessing, does this patch solve the problem:
Yes. It fixed the warnings for me. Thank you.
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
vim --help after patch 7.3.315 in gtk-enabled vim started to print the
following message at the end of help:
E852: The child process failed to start the GUI
(or E233: cannot open display if launched not in X11)
Press ENTER or type command to continue
And after pressing Enter, it doesn't quit but
Proposed patch - setting gui.dofork to FALSE at the end of usage(),
where it says Gnome gives extra messages for --help if we continue,
seems to solve this problem,
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For
On Thu, Dec 1, 2011 at 20:59, Bram Moolenaar b...@moolenaar.net wrote:
Do you mean this:
*** ../vim-7.3.363/src/main.c 2011-10-04 16:43:49.0 +0200
--- src/main.c 2011-12-01 20:14:40.0 +0100
***
*** 3294,3300
--- 3294,3303
#ifdef FEAT_GUI_GNOME
I've found that vim syntax file (runtime/syntax/vim.vim) doesn't know
about some options of :command -complete=.
For example, it highlights color in the line below as an error:
command -nargs=1 -complete=color ...
Please consider updating the list of keywords in it on line 206 to:
augroup buffer
On Thu, Apr 12, 2012 at 02:43, KyleFlavin kyle.fla...@gmail.com wrote:
It doesn't seem to like the line:
done $IP_RANGES
Try putting let g:is_bash=1 in your vimrc. This syntax is a bash extension.
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below
4.74 1.53
3200 16.85 8.60 3.0516.78 9.45 3.26
6400 32.62 17.16 5.5532.98 19.08 5.94
12800 66.71 34.38 11.2766.51 38.09 12.40
Other values of load factor up to ~ 256 seem also good to me.
--
Ivan Krasilnikov
--
You received this message from
On Dec 17, 9:14 am, StarWing weasley...@gmail.com wrote:
Why not use hashtable in hashtab.c for data storage?
It's only for string keys. In mf_hash the key is blocknr_T.
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
So, Bram, what do you think of this patch? Will it see the light of day?
On Fri, Dec 17, 2010 at 07:01, Ivan Krasilnikov inf...@gmail.com wrote:
Hello,
Recently I was using vim to edit large, multi-gigabyte text files and
I noticed that writing a file back to disk takes significantly longer
Hi, Bram,
I have fixed stylistic issues with this patch and wrote a couple of
tests for it:
mfhash_testdir.patch - a simple test for existing test suite which
inserts many lines into a buffer and verifies the buffer's contents,
as you suggested to do earlier.
mfhash_unittest.patch - a more
On Tue, Mar 1, 2011 at 00:05, Bram Moolenaar b...@moolenaar.net wrote:
I had a quick look and it looks good.
I think assert.h is not available everywhere. If you only use the
assert() method, perhaps we can use a configure check and when assert.h
is not available define it ourselves? This
Hi, I'm observing the following bug under Ubuntu and FreeBSD, which
seems to have been introduced by this patch.
$ cd /tmp
$ seq 1 100 file # bug happens with any sufficiently large file
$ echo 'set nocompatible foldmethod=marker lazyredraw' vimrc
$ vim -u vimrc --noplugin file
vim doesn't
On Thu, Mar 3, 2011 at 09:37, Kirill A. Shutemov kir...@shutemov.name wrote:
It's in xterm with 256 colors support enabled, isn't it? I have the same
problem.
Right. It happens to me in Ubuntu's xterm, gnome-terminal, konsole, on
a FreeBSD machine via ssh in these terminal emulators. But it
On Fri, Mar 4, 2011 at 00:03, Bram Moolenaar b...@moolenaar.net wrote:
Attached is the patch as I have it now. I fixed several warnings and
made a few cosmetic changes. The core code changes looks good. I'm not
sure if the tests cover enough of normal usage though.
Let me know if anyone
On Sun, Mar 6, 2011 at 12:02, Bram Moolenaar b...@moolenaar.net wrote:
For me, memfile_test linking fails with these errors:
objects/if_xcmdsrv.o: In function `serverEventProc':
src/if_xcmdsrv.c:1362: undefined reference to `serverConvert'
src/if_xcmdsrv.c:1416: undefined reference to
On Mon, Mar 21, 2011 at 13:48, pmehrwald phil_mehrw...@yahoo.com wrote:
Hi,
We are facing a severe problem on using :g on our machines at work. On
two different dell machines this command causes problems after
updating to x64 Windows 7 or Windows Server 2008.
The scenario is as follows:
*
+vim_dev@
On Tue, May 24, 2011 at 18:14, Ivan Krasilnikov inf...@gmail.com wrote:
I confirm the problem. Looks like there's a bug in UTF-8 handling in
function mb_strnicmp() in mbyte.c, specifically in the following if
which was introduced by patch 7.3.040:
/* Don't case-fold illegal bytes
Also mb_strnicmp() assumes that lowercase and uppercase characters
have the same length in UTF-8 representation. This isn't the case.
Here are a few counterexamples:
$ python -c 'print .join([0x%.2X % n for n in range(65536) if
len(unichr(n).encode(utf8)) !=
On Wed, May 25, 2011 at 14:09, Bram Moolenaar b...@moolenaar.net wrote:
Yes, this code just returns -1, no matter if the first or second string
is bigger.
Your other remark about difference in byte length of a character is
right, but it's not so easy to fix. Can you suggest a patch?
On Wed, May 25, 2011 at 22:39, Ivan Krasilnikov inf...@gmail.com wrote:
Hi, here's my patch for mbyte.c and a few testcases.
I've eliminated those return -1's by doing a bytewise comparison of
strings after the first corrupted character. This should make the
comparisons transitive at least
On Fri, May 27, 2011 at 00:19, Bram Moolenaar b...@moolenaar.net wrote:
I'm not sure what would be a convenient way to solve this. Making
patches for the runtime files would be the correct thing perhaps?
Can't fix what is already broken though.
Why not abandon patches altogether? Maintaining
On Thu, Aug 18, 2011 at 10:49, Delian Xu delia...@gmail.com wrote:
Hi guys,
I'm trying to compile a static VIM so that I can launch it every where (On
machines with different Linux distributions and library versions).
I got it to link statically by passing in the LDFLAGS at configure
time
26 matches
Mail list logo
