headers
Bram Moolenaar | 1 Mar 2009 02:22
Picon

Re: [patch] fixed access to free memory when using some autocommands


Dominique Pelle wrote:

> >> Testing autocommands, I see that Vim-7.2.107 (and older)
> >> is using memory already freed when doing silly autocommands
> >> such as:
> >>
> >> $ touch foobar
> >> $ valgrind ./vim -u NONE -c 'au! BufReadPre * cd /tmp' \
> >>             -c 'e foobar' 2> vg.log
> >>
> >> In vg.log, I then see the following error:
> >>
> >> ==15058== Syscall param open(filename) points to unaddressable byte(s)
> >> ==15058==  at 0x40007D2: (within /lib/ld-2.8.90.so)
> >> ==15058==  by 0x805365E: open_buffer (buffer.c:130)
> >> ==15058==  by 0x8098548: do_ecmd (ex_cmds.c:3655)
> >> ==15058==  by 0x80AE8E9: do_exedit (ex_docmd.c:7557)
> >> ==15058==  by 0x80AE560: ex_edit (ex_docmd.c:7452)
> >> ==15058==  by 0x80A6FE7: do_one_cmd (ex_docmd.c:2622)
> >> ==15058==  by 0x80A4867: do_cmdline (ex_docmd.c:1096)
> >> ==15058==  by 0x80A3F00: do_cmdline_cmd (ex_docmd.c:702)
> >> ==15058==  by 0x80E8A07: exe_commands (main.c:2693)
> >> ==15058==  by 0x80E63A7: main (main.c:874)
> >> ==15058== Address 0x54312d4 is 4 bytes inside a block of size 11 free'd
> >> ==15058==  at 0x4024E5A: free (vg_replace_malloc.c:323)
> >> ==15058==  by 0x8114D5D: vim_free (misc2.c:1631)
> >> ==15058==  by 0x80C97DF: shorten_fnames (fileio.c:5715)
> >> ==15058==  by 0x80AF1A9: ex_cd (ex_docmd.c:7942)
> >> ==15058==  by 0x80A6FE7: do_one_cmd (ex_docmd.c:2622)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bram Moolenaar | 1 Mar 2009 02:45
Picon

Patch 7.2.128


Patch 7.2.128 (after 7.2.055)
Problem:    Using ":lcd" makes session files not work.
Solution:   Compare return value of mch_chdir() properly. (Andreas Bernauer)
Files:      src/ex_docmd.c

*** ../vim-7.2.127/src/ex_docmd.c	Sat Feb 21 20:36:30 2009
--- src/ex_docmd.c	Sun Mar  1 02:39:38 2009
***************
*** 8792,8798 ****
  		else if (*dirnow != NUL
  			&& (ssop_flags & SSOP_CURDIR) && globaldir != NULL)
  		{
! 		    if (mch_chdir((char *)globaldir) == OK)
  			shorten_fnames(TRUE);
  		}

--- 8799,8805 ----
  		else if (*dirnow != NUL
  			&& (ssop_flags & SSOP_CURDIR) && globaldir != NULL)
  		{
! 		    if (mch_chdir((char *)globaldir) == 0)
  			shorten_fnames(TRUE);
  		}

*** ../vim-7.2.127/src/version.c	Tue Feb 24 04:36:50 2009
--- src/version.c	Sun Mar  1 02:42:47 2009
***************
*** 678,679 ****
--- 678,681 ----
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bram Moolenaar | 1 Mar 2009 03:07
Picon

Re: [patch] remote-raise option


Paul Egan wrote:

> Attached is a patch which adds a "raise" option to the --remote
> arguments.  Use of this option requests the window manager to
> raise the remote server window into focus and explicitly 
> moves it to the current desktop if required.
> 
> My first attempt at this functionality was to use a --remote-send
> ":call foreground()<CR>", however most window managers (or the
> versions patched by Fedora, Ubuntu, etc) will ignore the 
> resulting gtk_window_present call - or at least just "pulse" the 
> window list item - which isn't very useful.
> 
> There's a long running debate about the correct actions that 
> should be taken for gtk_window_present and _NET_ACTIVE_WINDOW,
> with each app and wm having a slightly different take.  It could
> be argued that the "issue" this patch fixes should really be dealt
> with by the window manager rather than the application.  Perhaps
> in the future there might be support for application hinting that 
> could allow vim to have foreground()/gtk_window_present work as 
> "expected", but in the meantime this patch performs an explicit 
> move & raise.
> 
> I added the code to if_xcmdsrv.c since it's toolkit independent 
> and there's already similar X functions there.
> 
> I hope others find this useful.

The patch moves the gvim server from one desktop to another.  In my
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tony Mechelynck | 1 Mar 2009 04:11
Picon
Gravatar

Re: Patch 7.2.128


On 01/03/09 02:45, Bram Moolenaar wrote:
>
> Patch 7.2.128 (after 7.2.055)
> Problem:    Using ":lcd" makes session files not work.
> Solution:   Compare return value of mch_chdir() properly. (Andreas Bernauer)
> Files:      src/ex_docmd.c

Bram, since you're publishing patches again, I don't notice any bad 
side-effects from that keymap/iminsert patch of yours that I've been 
testing.

Best regards,
Tony.
--

-- 
    Another bucket of what can only be described as human ordure hits 
ARTHUR.
ARTHUR: ... Right!  (to the KNIGHTS) That settles it!
                  "Monty Python and the Holy Grail" PYTHON (MONTY) 
PICTURES LTD

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
Dominique Pelle | 1 Mar 2009 10:24
Picon

Re: [patch] fixed access to free memory when using some autocommands

Bram Moolenaar wrote:

> Thanks for the patch.  I thought of catching the problem at the cause,
> by disallowing the autocommands to do something that will cause trouble.
> However, it's very difficult to catch all situations.
>
> So I think we can do both: disallow autocommands to do things that are
> clearly wrong, and give an error if we notice side effects.  That should
> be safe.
>
> Please have a look at the patch below.  There might still be other
> autocommands that cause trouble.  If you see one, please report.

...snip...

I applied your patch to Vim-7.2.128.

I still observe something wrong after patching (something
which I did not think of testing earlier, so the problem
I see in your patch was also in my patch).

The bug I see only happens when opening a file in Vim
which does not exist but for which there is a swap file.

Steps to reproduce it:

# Open a file foobar (which does not exist) in vim to create
# swap file .foobar.swp
$ rm -f ~/foobar
$ vim ~/foobar
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dominique Pelle | 1 Mar 2009 12:48
Picon

[patch] fixed string "[Command Line]" not translated with gettext

Buffer name "[Command Line]" is not translated with gettext.
This is the buffer name which shows up when doing  q:

Attached patch (from Vim-7.2.128) allows to translate it,
for those who use Vim with non-English locales.

Regards
-- Dominique

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
Attachment (fix-command-line-not-translated-ex_getln.c.patch): text/x-diff, 1043 bytes
Permalink | Reply | 3 comments |
headers
Dominique Pelle | 1 Mar 2009 18:13
Picon

bug in omni completion popup menu when option 'splibelow' is set


Hi

I observe a bug in Vim-7.2.128 with the omni-completion popup menu
when the option 'splitbelow' is set (bug does not happen when
'splitbelow' is not set).

When pressing the <Down> key in the omni-completion menu,
I see 2 pum: one above the current line and another one
below the current line.

This video illustrates the bug:

  http://dominique.pelle.free.fr/vim/bug-splitbelow-pum.avi

I use Vim-7.2.128, with the omnicppcomplete-0.41 plugin and my
.vimrc file can be found at:

  http://dominique.pelle.free.fr/.vimrc

Regards
-- Dominique

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
Bram Moolenaar | 1 Mar 2009 23:59
Picon

Re: [patch] fixed string "[Command Line]" not translated with gettext


Dominique Pelle wrote:

> Buffer name "[Command Line]" is not translated with gettext.
> This is the buffer name which shows up when doing  q:
> 
> Attached patch (from Vim-7.2.128) allows to translate it,
> for those who use Vim with non-English locales.

Not translating this is more or less intentional.  One can use this name
to find the buffer.  I thought it was not much of a problem not
translating this.

--

-- 
hundred-and-one symptoms of being an internet addict:
145. You e-mail your boss, informing him you'll be late.

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

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 2 comments |
headers
Bram Moolenaar | 1 Mar 2009 23:59
Picon

Re: [patch] fixed access to free memory when using some autocommands


Dominique Pelle wrote:

> Bram Moolenaar wrote:
> 
> > Thanks for the patch.  I thought of catching the problem at the cause,
> > by disallowing the autocommands to do something that will cause trouble.
> > However, it's very difficult to catch all situations.
> >
> > So I think we can do both: disallow autocommands to do things that are
> > clearly wrong, and give an error if we notice side effects.  That should
> > be safe.
> >
> > Please have a look at the patch below.  There might still be other
> > autocommands that cause trouble.  If you see one, please report.
> 
> ...snip...
> 
> I applied your patch to Vim-7.2.128.
> 
> I still observe something wrong after patching (something
> which I did not think of testing earlier, so the problem
> I see in your patch was also in my patch).
> 
> The bug I see only happens when opening a file in Vim
> which does not exist but for which there is a swap file.
> 
> Steps to reproduce it:
> 
> # Open a file foobar (which does not exist) in vim to create
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dominique Pelle | 2 Mar 2009 00:59
Picon

Re: [patch] fixed string "[Command Line]" not translated with gettext


Bram Moolenaar wrote:

> Dominique Pelle wrote:
>
>> Buffer name "[Command Line]" is not translated with gettext.
>> This is the buffer name which shows up when doing  q:
>>
>> Attached patch (from Vim-7.2.128) allows to translate it,
>> for those who use Vim with non-English locales.
>
> Not translating this is more or less intentional.  One can use this name
> to find the buffer.  I thought it was not much of a problem not
> translating this.

OK, that's fine then.  Some other special buffers such as
[No Name], [Quickfix List], [Location List], [Preview], [Scratch]
are translated with gettext though, which is a bit inconsistent
if [Command Line] buffer is not translated.  But it's only a
nitpicking thing.

Is the buffer name string the only way to identify what kind of
special buffer it is?

Regards
-- Dominique

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

Permalink | Reply | 1 comment |

Gmane