Re: Color Support for :! and :Shell system command execution
On 23/03/11 3:21 AM, Kevin wrote: Wanted to suggest adding support for terminal colors to gvim. I want this, too, and it's on my to-do list to investigate implementing some time. That certainly shouldn't stop anyone else jumping in and doing it, though. No idea when I might have enough time to look into it. But it's something I care enough about that I'll probably eventually look at it. Ben. -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Color Support for :! and :Shell system command execution
Will Gray (graywh) wrote: On Mar 22, 1:27 pm, Charles Campbell wrote: Perhaps the AnsiEsc plugin which colorizes text according to ansi escape sequences does what you want; you can get the plugin from: http://vim.sourceforge.net/scripts/script.php?script_id=302 (stable) http://mysite.verizon.net/astronaut/vim/index.html#ANSIESC(cutting edge) He's asking about GVim's built-in dumb terminal, not a buffer. He should be able to redirect the output to a buffer. Chip Campbell -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: problem saving file (or other command mode)
On 03/22/2011 09:28 PM, skeept wrote: > Since a couple of days I have been having the following problem with > vim: > > I use it normally and after a while I am unable to save the file > using :wa > Each time I press enter nothing happens and when I press other key > other then enter (say space) the following > shows up > :wa92_parse_cmd_line() > > I searched in the vim source with grep and in my .vim folder but could > not find this string. > Any thoughts on how to proceed to try to diagnose what is causing > this? > I am using the latest vim version (143) > > Thanks. > It's just a wild guess but it could be the vim-space plugin. If that's true you can find the project on github: https://github.com/spiiph/vim-space Maybe you can then submit a bug report there (I am using that plugin just fine). Cheers, Gregor -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Fwd: Re: Crash in python command
Tobias Columbus wrote: > > On Tuesday 22 March 2011 13:40:19 you wrote: > > > Kearn Holliday reported that this Python command crashes > > > some versions > > > > > > of Vim: > > > :python help(dir) > > > > > > This is the stack I get in gdb: > SNIP > > > Does someone have an idea why this happens or how to fix it? > > > > I just had a look at what's going on there. > SNIP > > I tracked the problem down to a call to > > type(sys.stdout) > > in the method pydoc.getpager(), which tries to determine what > > pager to use. > > The bug is indeed in type(sys.stdout). The attached patch fixes > the problem at least here. I modified all other Type > "constructors" for consistency reasons. Thanks. I'll verify it fixes the problem for me as well. -- ARTHUR: CHARGE! [The mighty ARMY charges. Thundering noise of feet. Clatter of coconuts. Shouts etc. Suddenly there is a wail of a siren and a couple of police cars roar round in front of the charging ARMY and the POLICE leap out and stop them. TWO POLICEMAN and the HISTORIAN'S WIFE. Black Marias skid up behind them.] HISTORIAN'S WIFE: They're the ones, I'm sure. "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Color Support for :! and :Shell system command execution
On Mar 22, 1:27 pm, Charles Campbell wrote: > Perhaps the AnsiEsc plugin which colorizes text according to ansi escape > sequences does what you want; you can get the plugin from: > > http://vim.sourceforge.net/scripts/script.php?script_id=302 (stable) > http://mysite.verizon.net/astronaut/vim/index.html#ANSIESC(cutting > edge) He's asking about GVim's built-in dumb terminal, not a buffer. -- Will Gray (graywh) -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Deleting a "Select line" selection at the end of a file leaves a blank line
Hi Bram!
On So, 20 Mär 2011, Bram Moolenaar wrote:
>
> Christian Brabandt wrote:
>
> > On Do, 17 Mär 2011, Bram Moolenaar wrote:
> >
> > > If you do gH it deletes the line. It's only on the last line that
> > > it makes the line empty. Let's call that a bug.
> > >
> > > Someone who wants to fix this?
> >
> > diff --git a/src/normal.c b/src/normal.c
> > --- a/src/normal.c
> > +++ b/src/normal.c
> > @@ -1776,6 +1776,11 @@
> > ++oap->line_count;
> > }
> > }
> > + if ( VIsual_select
> > + && ( cap->nchar == 'H' || (oap->start.col == 0
> > + && oap->end.col ==
> > (colnr_T)STRLEN(ml_get(oap->end.lnum))-1))
> > + && *p_sel != 'o')
> > + oap->motion_type = MLINE;
> > }
> >
> > redo_VIsual_busy = FALSE;
> >
> > That also fixes the bug, that when you select a whole line with the
> > mouse and press delete, the line is left empty.
>
> Thanks. I wonder why gH doesn't set the motion to linewise anyway. If
> you do gH in any line but the last it already deletes the whole
> line. Your patch doesn't check the line number, while it was only wrong
> in the last line. So perhaps it needs to be solved elsewhere?
Yeah, that is confusing. But just above these lines there is this code:
/* Try to include the newline, unless it's an operator
* that works on lines only */
if (*p_sel != 'o'
&& !op_on_lines(oap->op_type)
&& oap->end.lnum < curbuf->b_ml.ml_line_count)
{
++oap->end.lnum;
oap->end.col = 0;
# ifdef FEAT_VIRTUALEDIT
oap->end.coladd = 0;
# endif
++oap->line_count;
}
This will not trigger, when the last line is selected, cause obviously,
oap->end.lnum is not smaller then b_ml.ml_line_count. And as I
understand the code, this will take care of selecting the newlines.
regards,
Christian
--
Der beste Hellseher ist der, der gut raten kann.
-- Euripides (580-406 v. Chr.)
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Patch 7.3.140
Hi Bram! On Di, 22 Mär 2011, Bram Moolenaar wrote: > > Christian Brabandt wrote: > > > On Tue, March 22, 2011 1:29 pm, Bram Moolenaar wrote: > > > > > > Patch 7.3.140 > > > Problem:Crash when drawing the "$" at end-of-line for list mode just > > > after > > > the window border and 'cursorline' is set. > > > Solution: Don't check for 'cursorline'. (Quentin Carbonneaux) > > > Files:src/screen.c > > > > This effectively reverts patch 7.3.116 and there will be the problem > > again, that the cursorline is drawn too short. > > So 7.3.116 was the wrong way to solve it. I rather have a short > 'cursurline' than a crash, obviously. Yeah. But I just wanted to point out that now the old problem still persists. > Do you know the right way to draw the cursorline longer? Not really, but it doesn't crash for me (from the description of this patch). Mit freundlichen Grüßen Christian -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: problem saving file (or other command mode)
Hi Benjamin! On Di, 22 Mär 2011, Benjamin R. Haskell wrote: > On Tue, 22 Mar 2011, Christian Brabandt wrote: > > >Hi skeept! > > > >On Di, 22 Mär 2011, skeept wrote: > > > >>[...] when I press other key other then enter (say space) the > >>following shows up :wa92_parse_cmd_line() > >> > >>I searched in the vim source with grep and in my .vim folder but > >>could not find this string. > >>[...] > > > >This is probably a plugin you are using. grep for something like > >parse_cmd_line in your ~/.vim folder. > > Easier would be to see what #92 is in the output of :scriptnames. > (Documented toward the end of :help ). Oh yes true. regards, Christian -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: problem saving file (or other command mode)
Reply to message «problem saving file (or other command mode)», sent 23:28:30 22 March 2011, Tuesday by skeept: > I searched in the vim source with grep and in my .vim folder but could > not find this string. You should not have searched for this string, but for `s:parse_cmd_line': see `:h ' (`92_' is a result of expansion of `s:' in function name). > Any thoughts on how to proceed to try to diagnose what is causing > this? Look for script #92 in `scriptnames' output. It is likely some mapping is defined somewhere in the script. Original message: > Since a couple of days I have been having the following problem with > vim: > > I use it normally and after a while I am unable to save the file > using :wa > Each time I press enter nothing happens and when I press other key > other then enter (say space) the following > shows up > > :wa92_parse_cmd_line() > > I searched in the vim source with grep and in my .vim folder but could > not find this string. > Any thoughts on how to proceed to try to diagnose what is causing > this? > I am using the latest vim version (143) > > Thanks. signature.asc Description: This is a digitally signed message part.
Re: problem saving file (or other command mode)
On Tue, 22 Mar 2011, Christian Brabandt wrote: Hi skeept! On Di, 22 Mär 2011, skeept wrote: [...] when I press other key other then enter (say space) the following shows up :wa92_parse_cmd_line() I searched in the vim source with grep and in my .vim folder but could not find this string. [...] This is probably a plugin you are using. grep for something like parse_cmd_line in your ~/.vim folder. Easier would be to see what #92 is in the output of :scriptnames. (Documented toward the end of :help ). -- Best, Ben -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: problem saving file (or other command mode)
Hi skeept! On Di, 22 Mär 2011, skeept wrote: > Since a couple of days I have been having the following problem with > vim: > > I use it normally and after a while I am unable to save the file > using :wa > Each time I press enter nothing happens and when I press other key > other then enter (say space) the following > shows up > :wa92_parse_cmd_line() > > I searched in the vim source with grep and in my .vim folder but could > not find this string. > Any thoughts on how to proceed to try to diagnose what is causing > this? > I am using the latest vim version (143) This is probably a plugin you are using. grep for something like parse_cmd_line in your ~/.vim folder. regards, Christian -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
problem saving file (or other command mode)
Since a couple of days I have been having the following problem with vim: I use it normally and after a while I am unable to save the file using :wa Each time I press enter nothing happens and when I press other key other then enter (say space) the following shows up :wa92_parse_cmd_line() I searched in the vim source with grep and in my .vim folder but could not find this string. Any thoughts on how to proceed to try to diagnose what is causing this? I am using the latest vim version (143) Thanks. -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Fwd: Re: Crash in python command
> On Tuesday 22 March 2011 13:40:19 you wrote:
> > Kearn Holliday reported that this Python command crashes
> > some versions
> >
> > of Vim:
> > :python help(dir)
> >
> > This is the stack I get in gdb:
SNIP
> > Does someone have an idea why this happens or how to fix it?
>
> I just had a look at what's going on there.
SNIP
> I tracked the problem down to a call to
> type(sys.stdout)
> in the method pydoc.getpager(), which tries to determine what
> pager to use.
The bug is indeed in type(sys.stdout). The attached patch fixes
the problem at least here. I modified all other Type
"constructors" for consistency reasons.
Tobias Columbus
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
diff --git a/src/if_python.c b/src/if_python.c
--- a/src/if_python.c
+++ b/src/if_python.c
@@ -780,7 +780,8 @@
PythonIO_Init(void)
{
/* Fixups... */
-OutputType.ob_type = &PyType_Type;
+// OutputType.ob_type = &PyType_Type;
+PyType_Ready(&OutputType);
return PythonIO_Init_io();
}
@@ -1402,12 +1403,12 @@
static char *(argv[2]) = {"/must>not&exist/foo", NULL};
/* Fixups... */
-BufferType.ob_type = &PyType_Type;
-RangeType.ob_type = &PyType_Type;
-WindowType.ob_type = &PyType_Type;
-BufListType.ob_type = &PyType_Type;
-WinListType.ob_type = &PyType_Type;
-CurrentType.ob_type = &PyType_Type;
+PyType_Ready(&BufferType);
+PyType_Ready(&RangeType);
+PyType_Ready(&WindowType);
+PyType_Ready(&BufListType);
+PyType_Ready(&WinListType);
+PyType_Ready(&CurrentType);
/* Set sys.argv[] to avoid a crash in warn(). */
PySys_SetArgv(1, argv);
Re: Crash in python command
Tobias Columbus wrote:
> On Tuesday 22 March 2011 13:40:19 you wrote:
> > Kearn Holliday reported that this Python command crashes some
> > versions
> >
> > of Vim:
> > :python help(dir)
> >
> > This is the stack I get in gdb:
>
> [...]
>
> I just had a look at what's going on there.
> :py help(dir) as well as other :py help("something that exists")
> all crash vim.
> I tracked the problem down to a call to
> type(sys.stdout)
> in the method pydoc.getpager(), which tries to determine what
> pager to use.
>
> Moreover,
> :py type(sys.stdout)
> also causes a SIGSEV.
>
> It seems to me that vim's sys.stdout has no well-defined python
> type and hence this call crashes.
>
> However, I do not know, how to fix this. An ad-hoc workaround is
> the following (working on any machine with less installed):
>
> :py import pydoc
> :py pydoc.pager = lambda text : pydoc.pipepager( text, 'less' )
> :py help(dir)
>
> This makes pydoc believe that pydoc.pager already was set by
> pydoc.getpager() and therefore the crashing pydoc.getpager() is
> not called anymore.
> The above code causes no SIGSEV, but vim seems to somewhat broken
> afterwards...At least it indicates that the problem really is
> where I claim it to be.
Getting the type of something should not crash. How do we fix this?
If we can't fix that, how do we make sys.stdout a proper object?
--
ARTHUR: If you do not open these doors, we will take this castle by force ...
[A bucket of slops land on ARTHUR. He tries to retain his dignity.]
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Patch 7.3.143
Dominique Pelle wrote: > Patch-7.3.143 is meant to add src/memfile_test.c. I see the new file > in the patch, but it's missing in Mercurial. Sorry, forgot to do "hg addremove". Should be OK now. -- 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 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Patch 7.3.143
Bram Moolenaar wrote: > Patch 7.3.143 > Problem: Memfile is not tested sufficiently. Looking up blocks in a > memfile is slow when there are many blocks. > Solution: Add high level test and unittest. Adjust the number of hash > buckets to the number of blocks. (Ivan Krasilnikov) > Files: Filelist, src/Makefile, src/main.c, src/memfile.c, > src/memfile_test.c src/structs.h src/testdir/Make_amiga.mak, > src/testdir/Make_dos.mak, src/testdir/Make_ming.mak, > src/testdir/Make_os2.mak, src/testdir/Make_vms.mak, > src/testdir/Makefile, src/testdir/test77.in, src/testdir/test77.ok Hi Patch-7.3.143 is meant to add src/memfile_test.c. I see the new file in the patch, but it's missing in Mercurial. As a result, doing "make test" gives: === Test results: ALL DONE make[2]: Leaving directory `/home/pel/sb/vim/src/testdir' make -f Makefile unittest make[2]: Entering directory `/home/pel/sb/vim/src' make[2]: *** No rule to make target `memfile_test.c', needed by `objects/memfile_test.o'. Stop. make[2]: Leaving directory `/home/pel/sb/vim/src' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/pel/sb/vim/src' make: *** [test] Error 2 === "hg -v log" shows: === changeset: 2730:e0a90042318d tag: v7-3-143 user:Bram Moolenaar date:Tue Mar 22 18:10:45 2011 +0100 files: Filelist src/Makefile src/main.c src/memfile.c src/structs.h src/testdir/Make_amiga.mak src/testdir/Make_dos.mak src/testdir/Make_ming.mak src/testdir/Make_os2.mak src/testdir/Makefile src/version.c description: updated for version 7.3.143 Problem:Memfile is not tested sufficiently. Looking up blocks in a memfile is slow when there are many blocks. Solution: Add high level test and unittest. Adjust the number of hash buckets to the number of blocks. (Ivan Krasilnikov) === src/memfile_test.c is not listed in "hg -v log". Regards -- Dominique -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Color Support for :! and :Shell system command execution
Kevin wrote: Wanted to suggest adding support for terminal colors to gvim. Currently, vim in a terminal can get colored output from system commands that offer a colored output feature (grep, ls, grep alternatives like ack-grep.) gvim doesn't interpret the terminal color control characters shows the ascii parts of them in the output of :!... or :Shell. It'd be a nice feature for gvim to support the color codes, so that gvim works the same way vim in a terminal emulator does in this situation, as well as allowing for improved display of information. Especially in instances where vim promotes the use of system commands (like :grep.) Perhaps the AnsiEsc plugin which colorizes text according to ansi escape sequences does what you want; you can get the plugin from: http://vim.sourceforge.net/scripts/script.php?script_id=302 (stable) http://mysite.verizon.net/astronaut/vim/index.html#ANSIESC (cutting edge) Regards, Chip Campbell -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Error in "make it.mo" for "make languages" for "make" after recent runtime files update between 7.3.139 and 7.3.140 [SOLVED]
On 22/03/11 16:20, Tony Mechelynck wrote: make[1]: Entering directory `/root/.build/vim/vim-hg/vim/src/po' OLD_PO_FILE_INPUT=yes msgfmt -v -o it.mo it.po it.po:3790: `msgid' and `msgstr' entries do not both end with '\n' msgfmt: found 1 fatal error 1781 translated messages. make[1]: *** [it.mo] Error 1 make[1]: Leaving directory `/root/.build/vim/vim-hg/vim/src/po' make: *** [languages] Error 2 Best regards, Tony. Ah, I see the problem has been fixed now. :-) Best regards, Tony. -- Dear Mister Language Person: I am curious about the expression, "Part of this complete breakfast". The way it comes up is, my 5-year-old will be watching TV cartoon shows in the morning, and they'll show a commercial for a children's compressed breakfast compound such as "Froot Loops" or "Lucky Charms", and they always show it sitting on a table next to some actual food such as eggs, and the announcer always says: "Part of this complete breakfast". Don't that really mean, "Adjacent to this complete breakfast", or "On the same table as this complete breakfast"? And couldn't they make essentially the same claim if, instead of Froot Loops, they put a can of shaving cream there, or a dead bat? Answer: Yes. -- Dave Barry, "Tips for Writer's" -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Patch 7.3.143
Patch 7.3.143
Problem:Memfile is not tested sufficiently. Looking up blocks in a
memfile is slow when there are many blocks.
Solution: Add high level test and unittest. Adjust the number of hash
buckets to the number of blocks. (Ivan Krasilnikov)
Files: Filelist, src/Makefile, src/main.c, src/memfile.c,
src/memfile_test.c src/structs.h src/testdir/Make_amiga.mak,
src/testdir/Make_dos.mak, src/testdir/Make_ming.mak,
src/testdir/Make_os2.mak, src/testdir/Make_vms.mak,
src/testdir/Makefile, src/testdir/test77.in, src/testdir/test77.ok
*** ../vim-7.3.142/Filelist 2010-08-15 21:57:20.0 +0200
--- Filelist2011-03-22 17:39:22.0 +0100
***
*** 39,44
--- 39,45
src/mark.c \
src/mbyte.c \
src/memfile.c \
+ src/memfile_test.c \
src/memline.c \
src/menu.c \
src/message.c \
***
*** 686,691
--- 687,694
runtime/tutor/tutor.utf-8 \
runtime/tutor/tutor.?? \
runtime/tutor/tutor.??.* \
+ runtime/tutor/tutor.bar \
+ runtime/tutor/tutor.bar.* \
runtime/spell/README.txt \
runtime/spell/??/*.diff \
runtime/spell/??/main.aap \
*** ../vim-7.3.142/src/Makefile 2011-02-15 15:27:00.0 +0100
--- src/Makefile2011-03-22 18:07:25.0 +0100
***
*** 561,567
#CFLAGS = -g -O2 '-DSTARTUPTIME="vimstartup"' -fno-strength-reduce -Wall
-Wmissing-prototypes
# Use this with GCC to check for mistakes, unused arguments, etc.
! #CFLAGS = -g -Wall -Wextra -Wmissing-prototypes -Wunreachable-code
-D_FORTIFY_SOURCE=1 -DU_DEBUG
#CFLAGS = -g -O2 -Wall -Wextra -Wmissing-prototypes -D_FORTIFY_SOURCE=1
-DU_DEBUG
#PYTHON_CFLAGS_EXTRA = -Wno-missing-field-initializers
#MZSCHEME_CFLAGS_EXTRA = -Wno-unreachable-code -Wno-unused-parameter
--- 561,567
#CFLAGS = -g -O2 '-DSTARTUPTIME="vimstartup"' -fno-strength-reduce -Wall
-Wmissing-prototypes
# Use this with GCC to check for mistakes, unused arguments, etc.
! #CFLAGS = -g -Wall -Wextra -Wmissing-prototypes -Wunreachable-code
-D_FORTIFY_SOURCE=1
#CFLAGS = -g -O2 -Wall -Wextra -Wmissing-prototypes -D_FORTIFY_SOURCE=1
-DU_DEBUG
#PYTHON_CFLAGS_EXTRA = -Wno-missing-field-initializers
#MZSCHEME_CFLAGS_EXTRA = -Wno-unreachable-code -Wno-unused-parameter
***
*** 594,601
# PROFILING - Uncomment the next two lines to do profiling with gcc and gprof.
# Might not work with GUI or Perl.
! # For unknown reasons adding "-lc" fixes a linking problem with GCC. That's
! # probably a bug in the "-pg" implementation.
# Need to recompile everything after changing this: "make clean" "make".
#PROFILE_CFLAGS = -pg -g -DWE_ARE_PROFILING
#PROFILE_LIBS = -pg
--- 594,602
# PROFILING - Uncomment the next two lines to do profiling with gcc and gprof.
# Might not work with GUI or Perl.
! # For unknown reasons adding "-lc" fixes a linking problem with some versions
! # of GCC. That's probably a bug in the "-pg" implementation.
! # After running Vim see the profile result with: gmon vim gmon.out | vim -
# Need to recompile everything after changing this: "make clean" "make".
#PROFILE_CFLAGS = -pg -g -DWE_ARE_PROFILING
#PROFILE_LIBS = -pg
***
*** 606,613
# Configuration is in the .ccmalloc or ~/.ccmalloc file.
# Doesn't work very well, since memory linked to from global variables
# (in libraries) is also marked as leaked memory.
! #PROFILE_CFLAGS = -DEXITFREE
! #PROFILE_LIBS = -lccmalloc
#
### Specific systems, check if yours is listed! ### {{{
--- 607,614
# Configuration is in the .ccmalloc or ~/.ccmalloc file.
# Doesn't work very well, since memory linked to from global variables
# (in libraries) is also marked as leaked memory.
! #LEAK_CFLAGS = -DEXITFREE
! #LEAK_LIBS = -lccmalloc
#
### Specific systems, check if yours is listed! ### {{{
***
*** 1329,1335
PRE_DEFS = -Iproto $(DEFS) $(GUI_DEFS) $(GUI_IPATH) $(CPPFLAGS)
$(EXTRA_IPATHS)
POST_DEFS = $(X_CFLAGS) $(MZSCHEME_CFLAGS) $(TCL_CFLAGS) $(EXTRA_DEFS)
! ALL_CFLAGS = $(PRE_DEFS) $(CFLAGS) $(PROFILE_CFLAGS) $(POST_DEFS)
# Exclude $CFLAGS for osdef.sh, for Mac 10.4 some flags don't work together
# with "-E".
--- 1330,1336
PRE_DEFS = -Iproto $(DEFS) $(GUI_DEFS) $(GUI_IPATH) $(CPPFLAGS)
$(EXTRA_IPATHS)
POST_DEFS = $(X_CFLAGS) $(MZSCHEME_CFLAGS) $(TCL_CFLAGS) $(EXTRA_DEFS)
! ALL_CFLAGS = $(PRE_DEFS) $(CFLAGS) $(PROFILE_CFLAGS) $(LEAK_CFLAGS)
$(POST_DEFS)
# Exclude $CFLAGS for osdef.sh, for Mac 10.4 some flags don't work together
# with "-E".
***
*** 1358,1364
$(PY
Color Support for :! and :Shell system command execution
Wanted to suggest adding support for terminal colors to gvim. Currently, vim in a terminal can get colored output from system commands that offer a colored output feature (grep, ls, grep alternatives like ack-grep.) gvim doesn't interpret the terminal color control characters shows the ascii parts of them in the output of :!... or :Shell. It'd be a nice feature for gvim to support the color codes, so that gvim works the same way vim in a terminal emulator does in this situation, as well as allowing for improved display of information. Especially in instances where vim promotes the use of system commands (like :grep.) --Kevin Hamer -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Crash in python command
On Tuesday 22 March 2011 13:40:19 you wrote:
> Kearn Holliday reported that this Python command crashes some
> versions
>
> of Vim:
> :python help(dir)
>
> This is the stack I get in gdb:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0097d726 in ?? () from /usr/lib/libpython2.6.so.1.0
> (gdb) where
> #0 0x0097d726 in ?? () from /usr/lib/libpython2.6.so.1.0
> #1 0x009c2c5f in PyEval_EvalFrameEx () from
> /usr/lib/libpython2.6.so.1.0 #2 0x009c3b66 in
> PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0 #3
> 0x009c3b66 in PyEval_EvalFrameEx () from
> /usr/lib/libpython2.6.so.1.0 #4 0x009c52b9 in
> PyEval_EvalCodeEx () from /usr/lib/libpython2.6.so.1.0 #5
> 0x009c359d in PyEval_EvalFrameEx () from
> /usr/lib/libpython2.6.so.1.0 #6 0x009c3b66 in
> PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0 #7
> 0x009c52b9 in PyEval_EvalCodeEx () from
> /usr/lib/libpython2.6.so.1.0 #8 0x0094d62f in ?? () from
> /usr/lib/libpython2.6.so.1.0 #9 0x0091e77c in PyObject_Call
> () from /usr/lib/libpython2.6.so.1.0 #10 0x00930604 in ?? ()
> from /usr/lib/libpython2.6.so.1.0 #11 0x0091e77c in
> PyObject_Call () from /usr/lib/libpython2.6.so.1.0 #12
> 0x0092f816 in ?? () from /usr/lib/libpython2.6.so.1.0 #13
> 0x0091e77c in PyObject_Call () from
> /usr/lib/libpython2.6.so.1.0 #14 0x009c23aa in
> PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0 #15
> 0x009c52b9 in PyEval_EvalCodeEx () from
> /usr/lib/libpython2.6.so.1.0 #16 0x0094d537 in ?? () from
> /usr/lib/libpython2.6.so.1.0 #17 0x0091e77c in PyObject_Call
> () from /usr/lib/libpython2.6.so.1.0 #18 0x00930604 in ?? ()
> from /usr/lib/libpython2.6.so.1.0 #19 0x0091e77c in
> PyObject_Call () from /usr/lib/libpython2.6.so.1.0 #20
> 0x0098667d in ?? () from /usr/lib/libpython2.6.so.1.0 #21
> 0x0091e77c in PyObject_Call () from
> /usr/lib/libpython2.6.so.1.0 #22 0x009c2f42 in
> PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0 #23
> 0x009c52b9 in PyEval_EvalCodeEx () from
> /usr/lib/libpython2.6.so.1.0 #24 0x009c53d3 in
> PyEval_EvalCode () from /usr/lib/libpython2.6.so.1.0 #25
> 0x009e2f8e in PyRun_StringFlags () from
> /usr/lib/libpython2.6.so.1.0 #26 0x009e4333 in
> PyRun_SimpleStringFlags () from /usr/lib/libpython2.6.so.1.0
> #27 0x081f80f2 in DoPythonCommand (eap=0xbfffee0c,
> cmd=0x839cb2f "help(dir)") at if_python.c:650
> #28 0x081f816b in ex_python (eap=0xbfffee0c) at
> if_python.c:687 #29 0x080c2ee2 in do_one_cmd
> (cmdlinep=0xbfffefc0, sourcing=0, cstack=0xbfffefc8,
> fgetline=0x80d61a2 , cookie=0x0) at
> ex_docmd.c:2657
> #30 0x080c07ce in do_cmdline (cmdline=0x0, fgetline=0x80d61a2
> , cookie=0x0, flags=0) at ex_docmd.c:1123
> #31 0x0813e9ce in nv_colon (cap=0xb320) at normal.c:5342
> #32 0x08138041 in normal_cmd (oap=0xb3dc, toplevel=1) at
> normal.c:1193 #33 0x08200e7c in main_loop (cmdwin=0,
> noexmode=0) at main.c:1262 #34 0x082008a5 in main (argc=1,
> argv=0xb624) at main.c:964
>
> Does someone have an idea why this happens or how to fix it?
I just had a look at what's going on there.
:py help(dir) as well as other :py help("something that exists")
all crash vim.
I tracked the problem down to a call to
type(sys.stdout)
in the method pydoc.getpager(), which tries to determine what
pager to use.
Moreover,
:py type(sys.stdout)
also causes a SIGSEV.
It seems to me that vim's sys.stdout has no well-defined python
type and hence this call crashes.
However, I do not know, how to fix this. An ad-hoc workaround is
the following (working on any machine with less installed):
:py import pydoc
:py pydoc.pager = lambda text : pydoc.pipepager( text, 'less' )
:py help(dir)
This makes pydoc believe that pydoc.pager already was set by
pydoc.getpager() and therefore the crashing pydoc.getpager() is
not called anymore.
The above code causes no SIGSEV, but vim seems to somewhat broken
afterwards...At least it indicates that the problem really is
where I claim it to be.
Tobias Columbus
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Error in "make it.mo" for "make languages" for "make" after recent runtime files update between 7.3.139 and 7.3.140
make[1]: Entering directory `/root/.build/vim/vim-hg/vim/src/po' OLD_PO_FILE_INPUT=yes msgfmt -v -o it.mo it.po it.po:3790: `msgid' and `msgstr' entries do not both end with '\n' msgfmt: found 1 fatal error 1781 translated messages. make[1]: *** [it.mo] Error 1 make[1]: Leaving directory `/root/.build/vim/vim-hg/vim/src/po' make: *** [languages] Error 2 Best regards, Tony. -- "When are you BUTTHEADS gonna learn that you can't oppose Gestapo tactics *with* Gestapo tactics?" -- Reuben Flagg -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: multi repeat on intel x64
On Mar 21, 6:02 pm, Ivan Krasilnikov wrote: > On Mon, Mar 21, 2011 at 13:48, pmehrwald 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: > > * Logfile ~100Mb opened > > * execute :%g!/xxx/d to remove some lines > > Can you try this command instead and tell us if the problem is gone - > :%g!/xxx/"_d > The "_ part here tells d not to yank each line it deletes. Sounds like the OP found a solution on his own, but FYI this command will not work as intended. You're adding the comment instead of deleting to the black-hole register. Note that the :g command takes an ex command, not a normal-mode command. Your command should read: :%g!/xxx/d _ or even better: :v/xxx/d _ (% is the default range for g/v commands and :v is a synonym for :g!) -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Patch 7.3.142
Patch 7.3.142
Problem:Python stdout doesn't have a flush() method, causing an import to
fail.
Solution: Add a dummy flush() method. (Tobias Columbus)
Files: src/if_py_both.h
*** ../vim-7.3.141/src/if_py_both.h 2010-10-27 12:17:54.0 +0200
--- src/if_py_both.h2011-03-22 15:37:43.0 +0100
***
*** 33,38
--- 33,39
static PyObject *OutputWrite(PyObject *, PyObject *);
static PyObject *OutputWritelines(PyObject *, PyObject *);
+ static PyObject *OutputFlush(PyObject *, PyObject *);
/* Function to write a line, points to either msg() or emsg(). */
typedef void (*writefn)(char_u *);
***
*** 47,55
static struct PyMethodDef OutputMethods[] = {
/* name, function, calling,documentation */
! {"write", OutputWrite,1, "" },
! {"writelines", OutputWritelines, 1, "" },
! { NULL, NULL, 0, NULL }
};
#define PyErr_SetVim(str) PyErr_SetString(VimError, str)
--- 48,57
static struct PyMethodDef OutputMethods[] = {
/* name, function, calling,documentation */
! {"write", OutputWrite,1, ""},
! {"writelines", OutputWritelines, 1, ""},
! {"flush", OutputFlush,1, ""},
! { NULL, NULL, 0, NULL}
};
#define PyErr_SetVim(str) PyErr_SetString(VimError, str)
***
*** 123,128
--- 125,139
return Py_None;
}
+ static PyObject *
+ OutputFlush(PyObject *self UNUSED, PyObject *args UNUSED)
+ {
+ /* do nothing */
+ Py_INCREF(Py_None);
+ return Py_None;
+ }
+
+
/* Buffer IO, we write one whole line at a time. */
static garray_T io_ga = {0, 0, 1, 80, NULL};
static writefn old_fn = NULL;
*** ../vim-7.3.141/src/version.c2011-03-22 14:35:01.0 +0100
--- src/version.c 2011-03-22 15:45:38.0 +0100
***
*** 716,717
--- 716,719
{ /* Add new patch number below this line */
+ /**/
+ 142,
/**/
--
Living on Earth includes an annual free trip around the Sun.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Patch 7.3.140
Christian Brabandt wrote: > On Tue, March 22, 2011 1:29 pm, Bram Moolenaar wrote: > > > > Patch 7.3.140 > > Problem:Crash when drawing the "$" at end-of-line for list mode just > > after > > the window border and 'cursorline' is set. > > Solution: Don't check for 'cursorline'. (Quentin Carbonneaux) > > Files: src/screen.c > > This effectively reverts patch 7.3.116 and there will be the problem > again, that the cursorline is drawn too short. So 7.3.116 was the wrong way to solve it. I rather have a short 'cursurline' than a crash, obviously. Do you know the right way to draw the cursorline longer? -- A law to reduce crime states: "It is mandatory for a motorist with criminal intentions to stop at the city limits and telephone the chief of police as he is entering the town. [real standing law in Washington, United States of America] /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Python sys.stdout.flush
Tobias Columbus wrote: > This is my first post here and I am not 100% sure if this topic > really belongs here.. Anyway, I'll give it a try. > > I recently dealt with using vim's python omnicompletion for SAGE > development (see www.sagemath.org). > In order to get SAGE working in vim I tried > > :py import sage.all > > However, this fails due to the minimalistic implementation of > sys.stdout in vim's python interpreter (... and, to be honest, > due to a bug in SAGE which imports unnecessary stuff, which relies > on attributes that are not guaranteed to exist). > > To be more precise, :py import sage.all crashes because vim's > sys.stdout has no 'flush' attribute. > I patched vim to include a dummy implementation of > sys.stdout.flush, which does nothing at all. > A corresponding patch file is attached. > > I wondered, if this modification could be merged into upstream? > > Admittedly, the changes are quite specific and the python > documentation of sys.stdout states that vim's implementation is > 100% correct: > > [...] stdout and stderr needn’t be built-in file objects: any > object is acceptable as long as it has a write() method that > takes a string argument. > (See http://docs.python.org/library/sys.html) > > However, the documentation of file.flush() also says: > > [...] This may be a no-op on some file-like objects. > (See http://docs.python.org/library/stdtypes.html#file-objects) > > So it seems to me that my dummy flush implementation is alright > and should break no working code. Thanks. Looks harmless to me. A few more lines can be omitted that you apparently copied from OutputWrite(). I was hoping this would also fix the crash for ":python help(dir)", but it doesn't. -- No children may attend school with their breath smelling of "wild onions." [real standing law in West Virginia, United States of America] /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Patch 7.3.140
On Tue, March 22, 2011 1:29 pm, Bram Moolenaar wrote: > > Patch 7.3.140 > Problem:Crash when drawing the "$" at end-of-line for list mode just > after > the window border and 'cursorline' is set. > Solution: Don't check for 'cursorline'. (Quentin Carbonneaux) > Files:src/screen.c > > This effectively reverts patch 7.3.116 and there will be the problem again, that the cursorline is drawn too short. regards, Christian -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Patch 7.3.141
Patch 7.3.141
Problem:When a key code is not set get a confusing error message.
Solution: Change the error message to say the key code is not set.
Files: src/option.c, runtime/doc/options.txt
*** ../vim-7.3.140/src/option.c 2011-01-22 00:11:42.0 +0100
--- src/option.c2011-03-22 14:25:52.0 +0100
***
*** 4352,4358
p = find_termcode(key_name);
if (p == NULL)
{
! errmsg = (char_u *)N_("E518: Unknown option");
goto skip;
}
else
--- 4352,4358
p = find_termcode(key_name);
if (p == NULL)
{
! errmsg = (char_u *)N_("E846: Key code not set");
goto skip;
}
else
***
*** 4700,4707
|| s[i] == ','
|| s[i] == NUL))
break;
! /* Count backspaces. Only a comma with an
!* even number of backspaces before it is
* recognized as a separator */
if (s > origval && s[-1] == '\\')
++bs;
--- 4700,4707
|| s[i] == ','
|| s[i] == NUL))
break;
! /* Count backslashes. Only a comma with an
!* even number of backslashes before it is
* recognized as a separator */
if (s > origval && s[-1] == '\\')
++bs;
*** ../vim-7.3.140/runtime/doc/options.txt 2010-12-02 21:43:10.0
+0100
--- runtime/doc/options.txt 2011-03-22 14:32:14.0 +0100
***
*** 150,155
--- 150,167
(the ^[ is a real here, use CTRL-V to enter it)
The advantage over a mapping is that it works in all situations.
+ You can define any key codes, e.g.: >
+ :set t_xy=^[foo;
+ There is no warning for using a name that isn't recognized. You can map these
+ codes as you like: >
+ :map something
+ < *E846*
+ When a key code is not set, it's like it does not exist. Trying to get its
+ value will result in an error: >
+ :set t_kb=
+ :set t_kb
+ E846: Key code not set: t_kb
+
The t_xx options cannot be set from a |modeline| or in the |sandbox|, for
security reasons.
*** ../vim-7.3.140/src/version.c2011-03-22 13:29:20.0 +0100
--- src/version.c 2011-03-22 14:32:59.0 +0100
***
*** 716,717
--- 716,719
{ /* Add new patch number below this line */
+ /**/
+ 141,
/**/
--
"I know that there are people who don't love their fellow man,
and I hate those people!" - Tom Lehrer
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Crash in python command
Kearn Holliday reported that this Python command crashes some versions of Vim: :python help(dir) This is the stack I get in gdb: Program received signal SIGSEGV, Segmentation fault. 0x0097d726 in ?? () from /usr/lib/libpython2.6.so.1.0 (gdb) where #0 0x0097d726 in ?? () from /usr/lib/libpython2.6.so.1.0 #1 0x009c2c5f in PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0 #2 0x009c3b66 in PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0 #3 0x009c3b66 in PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0 #4 0x009c52b9 in PyEval_EvalCodeEx () from /usr/lib/libpython2.6.so.1.0 #5 0x009c359d in PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0 #6 0x009c3b66 in PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0 #7 0x009c52b9 in PyEval_EvalCodeEx () from /usr/lib/libpython2.6.so.1.0 #8 0x0094d62f in ?? () from /usr/lib/libpython2.6.so.1.0 #9 0x0091e77c in PyObject_Call () from /usr/lib/libpython2.6.so.1.0 #10 0x00930604 in ?? () from /usr/lib/libpython2.6.so.1.0 #11 0x0091e77c in PyObject_Call () from /usr/lib/libpython2.6.so.1.0 #12 0x0092f816 in ?? () from /usr/lib/libpython2.6.so.1.0 #13 0x0091e77c in PyObject_Call () from /usr/lib/libpython2.6.so.1.0 #14 0x009c23aa in PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0 #15 0x009c52b9 in PyEval_EvalCodeEx () from /usr/lib/libpython2.6.so.1.0 #16 0x0094d537 in ?? () from /usr/lib/libpython2.6.so.1.0 #17 0x0091e77c in PyObject_Call () from /usr/lib/libpython2.6.so.1.0 #18 0x00930604 in ?? () from /usr/lib/libpython2.6.so.1.0 #19 0x0091e77c in PyObject_Call () from /usr/lib/libpython2.6.so.1.0 #20 0x0098667d in ?? () from /usr/lib/libpython2.6.so.1.0 #21 0x0091e77c in PyObject_Call () from /usr/lib/libpython2.6.so.1.0 #22 0x009c2f42 in PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0 #23 0x009c52b9 in PyEval_EvalCodeEx () from /usr/lib/libpython2.6.so.1.0 #24 0x009c53d3 in PyEval_EvalCode () from /usr/lib/libpython2.6.so.1.0 #25 0x009e2f8e in PyRun_StringFlags () from /usr/lib/libpython2.6.so.1.0 #26 0x009e4333 in PyRun_SimpleStringFlags () from /usr/lib/libpython2.6.so.1.0 #27 0x081f80f2 in DoPythonCommand (eap=0xbfffee0c, cmd=0x839cb2f "help(dir)") at if_python.c:650 #28 0x081f816b in ex_python (eap=0xbfffee0c) at if_python.c:687 #29 0x080c2ee2 in do_one_cmd (cmdlinep=0xbfffefc0, sourcing=0, cstack=0xbfffefc8, fgetline=0x80d61a2 , cookie=0x0) at ex_docmd.c:2657 #30 0x080c07ce in do_cmdline (cmdline=0x0, fgetline=0x80d61a2 , cookie=0x0, flags=0) at ex_docmd.c:1123 #31 0x0813e9ce in nv_colon (cap=0xb320) at normal.c:5342 #32 0x08138041 in normal_cmd (oap=0xb3dc, toplevel=1) at normal.c:1193 #33 0x08200e7c in main_loop (cmdwin=0, noexmode=0) at main.c:1262 #34 0x082008a5 in main (argc=1, argv=0xb624) at main.c:964 Does someone have an idea why this happens or how to fix it? -- Girls are like internet domain names, the ones I like are already taken. Well, you can stil get one from a strange country :-P /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Patch 7.3.140
Patch 7.3.140
Problem:Crash when drawing the "$" at end-of-line for list mode just after
the window border and 'cursorline' is set.
Solution: Don't check for 'cursorline'. (Quentin Carbonneaux)
Files: src/screen.c
*** ../vim-7.3.139/src/screen.c 2011-02-09 17:09:26.0 +0100
--- src/screen.c2011-03-22 13:29:04.0 +0100
***
*** 5099,5109
#ifdef FEAT_DIFF
|| filler_todo > 0
#endif
! || (wp->w_p_list && lcs_eol != NUL && p_extra != at_end_str
! #ifdef FEAT_SYN_HL
! && !wp->w_p_cul
! #endif
! )
|| (n_extra != 0 && (c_extra != NUL || *p_extra != NUL)))
)
{
--- 5099,5105
#ifdef FEAT_DIFF
|| filler_todo > 0
#endif
! || (wp->w_p_list && lcs_eol != NUL && p_extra != at_end_str)
|| (n_extra != 0 && (c_extra != NUL || *p_extra != NUL)))
)
{
*** ../vim-7.3.139/src/version.c2011-03-22 13:07:19.0 +0100
--- src/version.c 2011-03-22 13:27:26.0 +0100
***
*** 716,717
--- 716,719
{ /* Add new patch number below this line */
+ /**/
+ 140,
/**/
--
Lawmakers made it obligatory for everybody to take at least one bath
each week -- on Saturday night.
[real standing law in Vermont, United States of America]
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Python sys.stdout.flush
Hi all,
This is my first post here and I am not 100% sure if this topic
really belongs here.. Anyway, I'll give it a try.
I recently dealt with using vim's python omnicompletion for SAGE
development (see www.sagemath.org).
In order to get SAGE working in vim I tried
:py import sage.all
However, this fails due to the minimalistic implementation of
sys.stdout in vim's python interpreter (... and, to be honest,
due to a bug in SAGE which imports unnecessary stuff, which relies
on attributes that are not guaranteed to exist).
To be more precise, :py import sage.all crashes because vim's
sys.stdout has no 'flush' attribute.
I patched vim to include a dummy implementation of
sys.stdout.flush, which does nothing at all.
A corresponding patch file is attached.
I wondered, if this modification could be merged into upstream?
Admittedly, the changes are quite specific and the python
documentation of sys.stdout states that vim's implementation is
100% correct:
[...] stdout and stderr needn’t be built-in file objects: any
object is acceptable as long as it has a write() method that
takes a string argument.
(See http://docs.python.org/library/sys.html)
However, the documentation of file.flush() also says:
[...] This may be a no-op on some file-like objects.
(See http://docs.python.org/library/stdtypes.html#file-objects)
So it seems to me that my dummy flush implementation is alright
and should break no working code.
Tobias Columbus
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
*** src/src/if_py_both.h 2011-03-19 17:20:20.642621721 +0100
--- patches/src/if_py_both.h 2011-03-19 17:23:09.019620937 +0100
*** Python_Release_Vim(void)
*** 33,38
--- 33,39
static PyObject *OutputWrite(PyObject *, PyObject *);
static PyObject *OutputWritelines(PyObject *, PyObject *);
+ static PyObject *OutputFlush( PyObject *, PyObject *);
/* Function to write a line, points to either msg() or emsg(). */
typedef void (*writefn)(char_u *);
*** static struct PyMethodDef OutputMethods[
*** 49,54
--- 50,56
/* name, function, calling,documentation */
{"write", OutputWrite, 1, "" },
{"writelines", OutputWritelines, 1, "" },
+ {"flush", OutputFlush,1, ""},
{ NULL, NULL, 0, NULL }
};
*** OutputWritelines(PyObject *self, PyObjec
*** 123,128
--- 125,145
return Py_None;
}
+ static PyObject *
+ OutputFlush(PyObject *self, PyObject *args)
+ {
+ int len;
+ char *str;
+ int error = ((OutputObject *)(self))->error;
+
+ if (!PyArg_ParseTuple(args, "s#", &str, &len))
+ return NULL;
+
+ Py_INCREF(Py_None);
+ return Py_None;
+ }
+
+
/* Buffer IO, we write one whole line at a time. */
static garray_T io_ga = {0, 0, 1, 80, NULL};
static writefn old_fn = NULL;
Patch 7.3.139
Patch 7.3.139 (after 7.3.137)
Problem:When 'lazyredraw' is set ":ver" output can't be read.
Solution: Don't redraw the screen when at a prompt or command line.
Files: src/getchar.c, src/message.c, src/misc1.c
*** ../vim-7.3.138/src/getchar.c2011-03-03 15:04:01.0 +0100
--- src/getchar.c 2011-03-22 12:16:23.0 +0100
***
*** 2713,2719
* changed text so far. Also for when 'lazyredraw' is set and
* redrawing was postponed because there was something in the
* input buffer (e.g., termresponse). */
! if (((State & INSERT) || p_lz) && advance && must_redraw != 0)
{
update_screen(0);
setcursor(); /* put cursor back where it belongs */
--- 2713,2720
* changed text so far. Also for when 'lazyredraw' is set and
* redrawing was postponed because there was something in the
* input buffer (e.g., termresponse). */
! if (((State & INSERT) != 0 || p_lz) && (State & CMDLINE) == 0
! && advance && must_redraw != 0 && !need_wait_return)
{
update_screen(0);
setcursor(); /* put cursor back where it belongs */
*** ../vim-7.3.138/src/message.c2011-02-01 17:12:20.0 +0100
--- src/message.c 2011-03-22 13:06:24.0 +0100
***
*** 879,894
if (msg_silent != 0)
return;
! /*
! * With the global command (and some others) we only need one return at the
! * end. Adjust cmdline_row to avoid the next message overwriting the last one.
! * When inside vgetc(), we can't wait for a typed character at all.
! */
if (vgetc_busy > 0)
return;
if (no_wait_return)
{
- need_wait_return = TRUE;
if (!exmode_active)
cmdline_row = msg_row;
return;
--- 879,895
if (msg_silent != 0)
return;
! /*
! * When inside vgetc(), we can't wait for a typed character at all.
! * With the global command (and some others) we only need one return at
! * the end. Adjust cmdline_row to avoid the next message overwriting the
! * last one.
! */
if (vgetc_busy > 0)
return;
+ need_wait_return = TRUE;
if (no_wait_return)
{
if (!exmode_active)
cmdline_row = msg_row;
return;
*** ../vim-7.3.138/src/misc1.c 2011-03-03 15:04:01.0 +0100
--- src/misc1.c 2011-03-22 12:15:26.0 +0100
***
*** 3116,3122
if (n == KEYLEN_REMOVED) /* key code removed */
{
! if (must_redraw)
{
/* Redrawing was postponed, do it now. */
update_screen(0);
--- 3116,3122
if (n == KEYLEN_REMOVED) /* key code removed */
{
! if (must_redraw != 0 && !need_wait_return && (State & CMDLINE) == 0)
{
/* Redrawing was postponed, do it now. */
update_screen(0);
*** ../vim-7.3.138/src/version.c2011-03-03 15:54:45.0 +0100
--- src/version.c 2011-03-22 13:06:33.0 +0100
***
*** 716,717
--- 716,719
{ /* Add new patch number below this line */
+ /**/
+ 139,
/**/
--
"Software is like sex... it's better when it's free."
-- Linus Torvalds, initiator of the free Linux OS
Makes me wonder what FSF stands for...?
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: trivial fix to comment in options.c
Ernie Rael wrote: > backspace --> backslash Thanks! -- It is illegal to take more than three sips of beer at a time while standing. [real standing law in Texas, United States of America] /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [PATCH] Upstart syntax file
James Hunt wrote: > Updated patch attached. Thanks, I'll include it. When you make improvements, please send me the new version of the file. -- No man may purchase alcohol without written consent from his wife. [real standing law in Pennsylvania, United States of America] /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: multi repeat on intel x64
Hi all, Thank you very much for your answers. Today in the morning I had an idea which lead me to the solution: I used perfmon.exe for further analysis and I realized that C1 Transitions/sec, C2 Transitions/sec, C3 Transitions/sec which is basically the power down on idle for the processor went up all the time during my grep. And I was just wondering why my processor is always shutting down when I need it the most. I now switched off the power management in the bios and it's working like a charm again. We guess, as we were changing the OS from XP to Windows 7/Server 2008 (on the same PCs) that there were some changes in power management of windows which lead to this problem. More Information on this permon value: http://technet.microsoft.com/en-us/library/cc786359%28WS.10%29.aspx Thank you very much for your help! Philipp From: Ivan Krasilnikov To: vim_dev@googlegroups.com Cc: pmehrwald Sent: Tue, 22 March, 2011 0:02:44 Subject: Re: multi repeat on intel x64 On Mon, Mar 21, 2011 at 13:48, pmehrwald 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: > * Logfile ~100Mb opened > * execute :%g!/xxx/d to remove some lines Can you try this command instead and tell us if the problem is gone - :%g!/xxx/"_d The "_ part here tells d not to yank each line it deletes. -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
