On 10/16/2016 10:26 PM, Xavier de Gaye wrote:
> vim version: 8.0.13
> python version: 3.5.2
> Linux 4.7.6-1-ARCH: archlinux
>
> When running the following command from the gvim command line:
> :!python -c "print(input('Prompt: '))"
>
> the output when e
vim version: 8.0.13
python version: 3.5.2
Linux 4.7.6-1-ARCH: archlinux
When running the following command from the gvim command line:
:!python -c "print(input('Prompt: '))"
the output when entering '0' from the main keyboard:
Prompt: 0
0
and the output when entering 0 from the
On 07/01/2016 12:51 PM, Bram Moolenaar wrote:
>
> Patch 7.4.1969
> Problem:When the netbeans channel is closed consuming the buffer may cause
> a crash.
> Solution: Check for nb_channel not to be NULL. (Xavier de Gaye)
> Files: src/netbeans.c
The pycle
:version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jul 1 2016 10:03:37)
Included patches: 1-1967
The backtrace:
#0 0x7f603d2545c7 in kill () from /usr/lib/libc.so.6
(gdb) bt
#0 0x7f603d2545c7 in kill () from /usr/lib/libc.so.6
#1 0x005338d6 in may_core_dump () at
On 06/08/2016 08:17 PM, Bram Moolenaar wrote:
>
> Patch 7.4.1908
> Problem:Netbeans uses uninitialzed pointer and freed memory.
> Solution: Set "buffer" at the right place (hint by Ken Takata)
> Files: src/netbeans.c
The full pyclewn test suite runs ok now :). Thanks Bram.
BTW when
On 06/07/2016 10:16 PM, Bram Moolenaar wrote:
>
> Patch 7.4.1906
> Problem:Collapsing channel buffers and searching for NL does not work
> properly. (Xavier de Gary, Ramel Eshed)
> Solution: Do not assume the buffer contains a NUL or not. Change NUL bytes
> to NL to
On 06/06/2016 11:14 PM, Bram Moolenaar wrote:
> Xavier de Gaye wrote:
>> >> Or how could I reproduce this myself?
>>
>> Install pyclewn and run in the distribution directory:
>
> What is the distribution directory? I looked in
> /usr/loc
On 06/05/2016 04:11 PM, Bram Moolenaar wrote:
>> Xavier de Gaye wrote:
>>
>>> Two pyclewn tests fail after patch 7.4.1891. It seems that not all 'insert'
>>> function messages are matched with a reply from Vim after this patch.
>>> This happens with a t
Two pyclewn tests fail after patch 7.4.1891. It seems that not all 'insert'
function messages are matched with a reply from Vim after this patch.
This happens with a test that sends 50 'insert' of 353 bytes in a row
interleaved with about the same amount of 'remove' and only 5 of these
are
Pyclewn 2.3 has been released at http://pyclewn.sourceforge.net/
Pyclewn is a Python program that allows the use of Vim as a front end to the
GNU debugger gdb and the Python debugger pdb.
New features
* A dynamic watch variable, for example an STL container, is now displayed
On 03/14/2016 02:26 PM, Charles E Campbell wrote:
> Xavier de Gaye wrote:
>> This is a regression introduced somewhere after 7.4.944.
>>
>> This error occurs when opening a file and when:
>> let g:netrw_browse_split = 3" open file in new tab
>>
&g
This is a regression introduced somewhere after 7.4.944.
This error occurs when opening a file and when:
let g:netrw_browse_split = 3" open file in new tab
Error message:
Error detected while processing function 27_NetrwBrowseChgDir:
line 135:
E121: Undefined variable:
Pyclewn 2.2 has been released at http://pyclewn.sourceforge.net/
Pyclewn is a Python program that allows the use of Vim as a front end to the
GNU debugger gdb and the Python debugger pdb.
This release fixes the following bugs:
* Print the return value when the inferior stops after 'finish'.
Pyclewn 2.1 has been released at http://pyclewn.sourceforge.net/
Pyclewn is a Vim front-end to the gdb and pdb debuggers.
Version 2.1 brings full gdb completion and a better handling of Vim windows.
See below for the full details.
Xavier
===
New features
* Full gdb
On 03/14/2015 03:38 PM, Bram Moolenaar wrote:
Patch 7.4.663
Problem:When using netbeans a buffer is not found in another tab.
Solution: When 'switchbuf' is set to usetab then switch to another tab
when possible. (Xavier de Gaye)
Files: src/netbeans.c
*** ../vim
On 03/14/2015 12:13 AM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
The Vim netbeans interface is not tabpage aware and does not check the
'switchbuf' option. So, even when a buffer is already loaded in the window of
a tab, placing an annotation in this buffer will cause the buffer
On 03/14/2015 12:13 AM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
The Vim netbeans interface is not tabpage aware and does not check the
'switchbuf' option. So, even when a buffer is already loaded in the window of
a tab, placing an annotation in this buffer will cause the buffer
On 03/12/2015 08:28 PM, Bram Moolenaar wrote:
Bruno Sutic wrote:
It appears google code is shutting down:
http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html
Any thoughts on where will vim source code repo be moved?
I know I'd be more than delighted if it was hosted
The Vim netbeans interface is not tabpage aware and does not check the
'switchbuf' option. So, even when a buffer is already loaded in the window of
a tab, placing an annotation in this buffer will cause the buffer to be loaded
in the current window of the current tab instead of moving to the tab
On 03/07/2015 03:04 PM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
This unused two characters-wide sign column wastes space, take for example a
screen that is vertically splitted to show multiple buffers. The attached
patch fixes this.
For reference, a link to the pyclewn issue tracker
This unused two characters-wide sign column wastes space, take for example a
screen that is vertically splitted to show multiple buffers. The attached
patch fixes this.
For reference, a link to the pyclewn issue tracker that raised the issue:
https://bitbucket.org/xdegaye/pyclewn/issue/7
Patch
On 02/27/2015 07:35 PM, Bram Moolenaar wrote:
Patch 7.4.645
Problem:When splitting the window in a BufAdd autocommand while still in
the first, empty buffer the window count is wrong.
Solution: Do not reset b_nwindows to zero and don't increment it.
Files: src/buffer.c,
Run the following script named nwindows.vim and call Nwindows() with an
argument of 0 or 1:
gvim -u NONE -S nwindows.vim
:call Nwindows(1) --- BufWinLeave events (there should be no
BufWinLeave event): 1
:call Nwindows(0) --- BufWinLeave events (there should be no
Pyclewn 2.0, a Vim front-end to the gdb and pdb debuggers, has been
released at http://pyclewn.sourceforge.net/
New features
* Three clewn buffers are updated by gdb, they list the breakpoints, the
backtrace and the threads. One can jump with the CR key or the mouse to
the
On 02/11/2015 04:50 AM, Justin M. Keyes wrote:
On Tue, Jan 27, 2015 at 5:26 AM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
On 01/25/2015 03:59 PM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
In the following test case, 'foobar' and 'dummy_file' are two
non-existent files
On 02/07/2015 03:59 PM, Bram Moolenaar wrote:
Charles Campbell wrote:
Looks like patch#592 stops netrw from working with remote files: vim
scp://hostname/ no longer works.
What this patch does is that when :e filename is used when the
'buftype' is not a file, it does not empty the
On 01/28/2015 06:21 PM, Gary Johnson wrote:
On 2015-01-28, Xavier de Gaye wrote:
On 01/27/2015 01:29 PM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
Running the DirDiff plugin with the latest 7.4.592 produces the following
error message:
E16: Invalid range: 3wincmd
This occurs
On 01/27/2015 01:29 PM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
Running the DirDiff plugin with the latest 7.4.592 produces the following
error message:
E16: Invalid range: 3wincmd
This occurs since 7.4.565.
There are other related reports, for example the thread :wincmd bug
On 01/27/2015 11:26 AM, Bram Moolenaar wrote:
Patch 7.4.592
Problem:When doing :e foobar when already editing foobar and 'buftype'
is nofile the buffer is cleared. (Xavier de Gaye)
Solution: Do no clear the buffer.
Files: src/ex_cmds.c
*** ../vim-7.4.591/src
Running the DirDiff plugin with the latest 7.4.592 produces the following error
message:
E16: Invalid range: 3wincmd
This occurs since 7.4.565.
There are other related reports, for example the thread :wincmd bug at
http://thread.gmane.org/gmane.editors.vim.devel/48814
I guess this is
On 01/27/2015 11:26 AM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
On 01/25/2015 03:59 PM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
In the following test case, 'foobar' and 'dummy_file' are two
non-existent files:
gvim -o foobar dummy_file
:set buftype=nofile
On 01/25/2015 03:59 PM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
In the following test case, 'foobar' and 'dummy_file' are two
non-existent files:
gvim -o foobar dummy_file
:set buftype=nofile
:call append(1, second line)- foobar contains now two lines
CTRL-W W
In the following test case, 'foobar' and 'dummy_file' are two non-existent
files:
gvim -o foobar dummy_file
:set buftype=nofile
:call append(1, second line)- foobar contains now two lines
CTRL-W W
:edit foobar - a) foobar still contains two lines
:edit foobar
On Mon, May 27, 2013 at 9:54 PM, ZyX wrote:
The patch is not correct:
'bytes' is declared in OptionsAssItem(), in the block (line 1689):
'else if (PyUnicode_Check(valObject))'
This declaration shadows the declaration of 'bytes' made by DICTKEY_DECL at
the start of the function.
On Sun, May 26, 2013 at 7:12 PM, Bram Moolenaar wrote:
ZyX wrote:
This is the last huge hunk I can write before the end of May. Other
parts of RFC are to be delayed.
Thanks for all your work!
I have a few more patches for Python listed, hopefully I can include
them all this week.
The
On Sat, May 25, 2013 at 10:47 AM, ZyX wrote:
# HG changeset patch
# User ZyX kp-...@ya.ru
# Date 1369465902 -14400
# Node ID f3a1f7c373ee941b71739260f72f6babbff6ce0f
# Parent e3fac877d315709055ffaec4cc32a5f971ef5e97
Fix invalid read errors:
defer DICTKEY_UNREF until key is no longer
On Sat, May 18, 2013 at 11:33 PM, Tony Mechelynck wrote:
On 18/05/13 14:52, Xavier de Gaye wrote:
On Sat, May 18, 2013 at 2:07 PM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
runtime/doc/tags is under Mercurial control:
$ hg locate runtime/doc/tags
runtime/doc/tags
This file
On Sat, May 18, 2013 at 4:12 PM, ZyX wrote:
Interesting. So we would have a $VIMRUNTIME/python directory and we can
put Python scripts there that we include with the distribution.
I'm sure it is only a small step that users will ask to have a python
directory in ~/.vim/python. Or more
On Fri, May 17, 2013 at 9:22 PM, Bram Moolenaar wrote:
ZyX wrote:
Interesting. So we would have a $VIMRUNTIME/python directory and we can
put Python scripts there that we include with the distribution.
I'm sure it is only a small step that users will ask to have a python
directory in
On Fri, May 17, 2013 at 9:07 PM, ZyX wrote:
Interesting. So we would have a $VIMRUNTIME/python directory and we can
put Python scripts there that we include with the distribution.
I'm sure it is only a small step that users will ask to have a python
directory in ~/.vim/python. Or more
On Fri, May 17, 2013 at 11:56 PM, ZyX wrote:
These patches make all variants of invoking python use the same
DoPyCommand function (renamed from DoPy3Command and DoPythonCommand)
and moved actual implementation to if_py_both. Also made new py*do
commands use this and use other existing
runtime/doc/tags is under Mercurial control:
$ hg locate runtime/doc/tags
runtime/doc/tags
This file is automatically generated during vim build.
It is annoying to have it appear sometimes in the output of 'hg status'
or when creating a patch with 'hg diff'. You must revert it first
On Sat, May 18, 2013 at 2:07 PM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
runtime/doc/tags is under Mercurial control:
$ hg locate runtime/doc/tags
runtime/doc/tags
This file is automatically generated during vim build.
It is annoying to have it appear sometimes in the output
The error message:
objects/if_python3.o: In function `set_option_value_for':
if_python3.c:(.text+0x1704): undefined reference to `win_find_tabpage'
collect2: ld returned 1 exit status
link.sh: Linking failed
Note that the undefined reference is actually in if_py_both.h, and not
On Fri, May 17, 2013 at 3:28 PM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
On Wed, May 15, 2013 at 8:51 PM, Bram Moolenaar wrote:
:python os.chdir('/tmp') makes short buffer names invalid. (Xavier de
Gaye)
Check directory and call shorten_fnames()?
Probably not only the python
On Fri, May 17, 2013 at 5:44 PM, Xavier de Gaye wrote:
On Fri, May 17, 2013 at 3:28 PM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
On Wed, May 15, 2013 at 8:51 PM, Bram Moolenaar wrote:
:python os.chdir('/tmp') makes short buffer names invalid. (Xavier de
Gaye)
Check directory
On Wed, May 15, 2013 at 8:51 PM, Bram Moolenaar wrote:
:python os.chdir('/tmp') makes short buffer names invalid. (Xavier de
Gaye)
Check directory and call shorten_fnames()?
Probably not only the python problem.
I wonder if there is a hook inside Python, so that we can do the
equivalent
On Thu, May 16, 2013 at 2:28 PM, James McCoy wrote:
On Thu, May 16, 2013 at 01:53:11PM +0200, Xavier de Gaye wrote:
Note that we must add the current directory to sys.path in order to be
able to import vim_hook. I believe this is another bug.
No, it actually isn't. Please see CVE-2009-0316
On Fri, May 10, 2013 at 10:54 AM, Jan Pobrislo wrote:
I'm quite curious what is meant by IDE-like features. From my experience
most of that is covered by plugins already, except for one significant
roadblock: inability to communicate with external processes without blocking
whole UI. There
On Fri, Apr 20, 2012 at 7:47 PM, Bram Moolenaar wrote:
Patch 7.3.502
Problem: Netbeans insert halfway a line actually appends to the line.
Solution: Insert halfway the line. (Brian Victor)
Files: src/netbeans.c
FWIW the pyclewn testsuite runs with success after this patch (7 tests
On Mon, Apr 16, 2012 at 7:46 PM, Bram Moolenaar wrote:
Brian Victor wrote:
As described in [1], the netbeans protocol insert command is behaving
incorrectly when the offset is in the middle of the line. After some
source diving, I discovered that the code was appending for
simplicity. This
On Tue, Apr 17, 2012 at 2:22 PM, Senthil Kumaran wrote:
On Tuesday, 17 April 2012 09:59:25 UTC+8, char101 wrote:
Just add this line in your .vimrc before using any python commands
let $PYTHONHOME='your python install dir'
I tried this, but it did not help.
The error message has something
On Apr 14, 5:28 am, Brian Victor wrote:
It appears from my testing (with code checked out with hg today) that
the offset parameter means different things in the netbeans insert
command than it does in the remove command. The Vim insert and remove
event offsets appear to match the remove
On Fri, Oct 28, 2011 at 11:03 PM, Xavier de Gaye wrote:
I use loadview and mkview with autocommands. It happens quite often
that upon returning to a buffer, a fold becomes unexpectedly closed.
In that case, whatever fold I attempt to open in this buffer next, it
will be closed after I leave
On Fri, Nov 25, 2011 at 6:48 PM, Xavier de Gaye wrote:
I use loadview and mkview with autocommands. It happens quite often
that upon returning to a buffer, a fold becomes unexpectedly closed.
In that case, whatever fold I attempt to open in this buffer next, it
will be closed after I leave
On Sat, Nov 19, 2011 at 8:33 AM, Jan Larres wrote:
The problem is that the python interface in Vim is not thread safe.
That's what I was worried about. I assume there's no easy way to fix
this then, other than using a higher sleep() value. But that just seems
wrong, especially since it can
On Fri, Nov 18, 2011 at 6:39 AM, Jan Larres wrote:
Hi,
I just spent some time hunting done a segfault that was cropping up recently
for me, and I have narrowed it down to some python threading that the
clang_complete plugin is doing. I have attached a minimal vimrc that is needed
to make the
On Wed, Nov 16, 2011 at 7:39 AM, Kerneels Roos wrote:
Thanks for that info. OK, since 'putBufferNumber' is a Command-type message
from IDE to editor (vim controller to vim editor) the format should be:
{bufferNumber}:putBufferNumber!{seqno} {pattern}
where all arguments in braces are
On Tue, Nov 15, 2011 at 11:34 AM, Kerneels Roos wrote:
The Focus and Cursor AutoCommands looks great for this purpose, but when I
try the ':nbkey' command to try and send something to the server it only
keeps on sending the same line:
0:fileOpened=0 C:\\Visual Studio Projects\\...path to the
I use loadview and mkview with autocommands. It happens quite often
that upon returning to a buffer, a fold becomes unexpectedly closed.
In that case, whatever fold I attempt to open in this buffer next, it
will be closed after I leave the buffer and on returning to it again.
Attached are a test
On Wed, Oct 19, 2011 at 7:00 AM, sinbad wrote:
i want to be able to mark locations in files with some text (marking-
text) of my choice.
You can use a temporary file to store your marks and the quickfix
window to navigate through them. For example source the script listed
below and mark a
On Wed, Oct 19, 2011 at 4:38 PM, Yegappan Lakshmanan
yegapp...@gmail.com wrote:
Hi,
On Wed, Oct 19, 2011 at 3:55 AM, Xavier de Gaye xdeg...@gmail.com wrote:
On Wed, Oct 19, 2011 at 7:00 AM, sinbad wrote:
i want to be able to mark locations in files with some text (marking-
text) of my
On Fri, Sep 30, 2011 at 4:12 PM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
...
When building an automated test case with netbeans, it is not obvious
how to have Vim made to call the idle loop. The attached patch adds a
call to netbeans_parse_messages() when the Vim :sleep command is
run
The netbeans implementation in Vim receives the netbeans messages in
the gui event loop (or the select event loop) and processes these
messages by calling netbeans_parse_messages() in the idle loop when
Vim is waiting for user input.
When building an automated test case with netbeans, it is not
The cursor disappears after the processing of the 'setDot' netbeans
command when vim runs in a terminal. Any further action (such as a
movement key) turns back on the cursor.
The attached patch to the current vim 7.3.138 fixes this problem.
--
Xavier
Les Chemins de Lokoti:
On Fri, Dec 17, 2010 at 12:19 PM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
2010/12/14 Dominique Pellé wrote:
clang static analyzer complains with the following warning:
netbeans.c:329:6: warning: Value stored to 'sd' is never read
sd = mch_open(hostname, O_RDONLY, 0
On Wed, Dec 8, 2010 at 5:10 PM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
On Tue, Dec 7, 2010 at 6:59 PM, Xavier de Gaye wrote:
I am not sure if the hack above is acceptable. I will look into the tty
attributes problem.
The hack must not be used. Instead, when the error occurs
2010/12/14 Dominique Pellé wrote:
clang static analyzer complains with the following warning:
netbeans.c:329:6: warning: Value stored to 'sd' is never read
sd = mch_open(hostname, O_RDONLY, 0);
^ ~~~
File descriptor sd is leaked
On Wed, Dec 8, 2010 at 5:10 PM, Bram Moolenaar wrote:
This looks like a hack. I think the proper solution is to have
vim_read() check for EINTR and retry.
I'm a bit confused about what happens when read() is interrupted before
reading anything, does it return zero or -1? Perhaps this
On Mon, Dec 6, 2010 at 7:54 PM, Benjamin R. Haskell wrote:
If Vim receives a SIGWINCH (_sig_nal that the _win_dow _ch_anged size) while
editing stdin, a program piping input to Vim gets killed prematurely. Is
there an easy way to avoid this?
Actually, it is Vim that terminates prematurely.
On Tue, Dec 7, 2010 at 6:47 PM, Xavier de Gaye wrote:
I am not sure if the hack above is acceptable. I will look into the tty
attributes problem.
The hack must not be used. Instead, when the error occurs in vim_read() and
the error is EINTR, vim should retry reading from stdin.
--
Xavier
On Tue, Dec 7, 2010 at 6:59 PM, Xavier de Gaye wrote:
I am not sure if the hack above is acceptable. I will look into the tty
attributes problem.
The hack must not be used. Instead, when the error occurs in vim_read() and
the error is EINTR, vim should retry reading from stdin.
The attached
On Mon, Dec 6, 2010 at 7:55 AM, ron wrote:
Thank you; however, I cannot force people to have python installed to
run a debugger.
FWIW, Python is a scripting language (optional) for gdb since gdb 7.0.
The tutorial of Tom Tromey at
http://sourceware.org/gdb/wiki/PythonGdbTutorial shows some of
Problem:
As a workaround to the netbeans bug fixed by Vim 7.3.060 (Netbeans:
crash when socket is disconnected unexpectedly), pyclewn sends a
'DETACH' netbeans message to terminate the netbeans session instead of
just closing the socket. This causes Vim to crash when running the new
Problem:
Vim crashes with SEGV or BUS when netbeans is processing a command and
concurrently receives a socket disconnection event. This is difficult
to reproduce as timing is critical. The first two backtraces below
are the result of such a crash. In both cases, examination of the
variables
On Thu, Oct 14, 2010 at 9:29 PM, Bram Moolenaar wrote:
Patch 7.3.028 (after 7.3.024)
Problem: Signs don't show up. (Charles Campbell)
Solution: Don't use negative numbers. Also assign a number to signs that
have a name of all digits to avoid using a sign number twice.
Files:
On Sun, Aug 22, 2010 at 4:19 PM, Tony Mechelynck wrote:
I see in various places in this patch (in the + lines)
... defined(FEAT_GUI_X11) || defined(FEAT_GUI_GTK) ...
... !defined(FEAT_GUI_X11) !defined(FEAT_GUI_GTK) ...
Isn't the GTK2 GUI an X11 GUI? I mean, is it possible to have
On Sat, Aug 21, 2010 at 6:48 PM, Tony Mechelynck wrote:
On 18/08/10 14:49, Xavier de Gaye wrote:
Actually, having multiple heads in the same branch may be considered
as not a problem. When we have local changes, after pulling from the
official repository, in order to merge the new official
The :nbstart command does not print an error message and attempts to
connect the netbeans socket when vim is built with a gui that is not
supported by netbeans.
The attached patch fixes this bug.
Xavier
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply
On Thu, Aug 19, 2010 at 8:56 PM, Lech Lorens wrote:
On 19-Aug-2010 Xavier de Gaye wrote:
I will propose a patch to support netbeans on vim-athena, unless
someone else wants to do it.
Thank you so much! I for one will be extremely grateful for this
feature!
The attached patch adds support
On Fri, Aug 20, 2010 at 12:11 PM, Xavier de Gaye wrote:
The :nbstart command does not print an error message and attempts to
connect the netbeans socket when vim is built with a gui that is not
supported by netbeans.
The attached patch fixes this bug.
In my previous mail, the 'nbstart-fail
The type number of a sign is negative when the sign name does not
start with a digit. This is not correctly implemented.
The attached patch fixes this, as well as a memory not freed on error.
Xavier
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below
On Thu, Aug 19, 2010 at 3:43 PM, David Harrison wrote:
Is it possible to build simply gvim-athena without having to
install too much athena stuff ?
Athena used to come with a standard X distribution. I don't know if
it still does, but I'm willing to bet that it's still there. Just
look
On Wed, Aug 18, 2010 at 7:11 AM, John Beckett wrote:
Xavier de Gaye wrote:
As there won't be a vimGdb patch for vim73, can you please
also remove:
6. vimGdb
I have updated the patches list:
http://groups.google.com/group/vim_dev/web/vim-patches
Thanks for having removed vimGdb.
Xavier
On Wed, Aug 18, 2010 at 2:01 PM, James Vega wrote:
On Tue, Aug 17, 2010 at 11:26:36PM +0200, Bram Moolenaar wrote:
I think what would normally happen is to merge the development branch
back into the default branch. But just like the problems you have now,
I suspect that migth not work very
On Tue, Aug 17, 2010 at 8:19 PM, Lech Lorens wrote:
I am using the Athena GUI. The one thing that I find annoyingly lacking
in this GUI flavour is being able to use Gvim with Pyclewn.
About 3 months ago Vim was patched to enable support for the NetBeans
protocol in console. If NetBeans is
On Tue, Aug 17, 2010 at 11:03 AM, björn wrote:
Looking at the Mercurial repo I see 7.3.002 applied twice, but I can't
see 7.3.001 anywhere. At first I suspected only the commit messages
were wrong but it looks like 7.3.002 really has been applied twice.
The changes are different:
On Tue, Aug 17, 2010 at 12:05 PM, Xavier de Gaye wrote:
On Tue, Aug 17, 2010 at 11:03 AM, björn wrote:
The changes are different:
vim-hg-working$ hg extdiff -c fde086181841 -p diff -o -qr
Files vim-hg-working.f0915ae869cf/src/ex_docmd.c and
vim-hg-working.fde086181841/src/ex_docmd.c differ
On Mon, Aug 16, 2010 at 7:01 PM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
The 'vim73' branch can be given the name of the 'default' branch with
the 'hg branch --force default' command after the 'default' branch is
named 'vim72' with the 'hg branch vim72' command (both followed
On Sun, Aug 15, 2010 at 10:19 PM, Bram Moolenaar wrote:
Xavier de Gaye wrote:
The 'vim73' branch can be given the name of the 'default' branch with
the 'hg branch --force default' command after the 'default' branch is
named 'vim72' with the 'hg branch vim72' command (both followed by
commit
BTW the Graph log extension is easy to setup and very handy to follow
branches in a mercurial repository and to see where is the parent of
the working directory (indicated by '@' in the graph)
See http://mercurial.selenic.com/wiki/GraphlogExtension
Xavier
--
You received this message from the
On Mon, Aug 16, 2010 at 4:12 AM, John Beckett wrote:
At Bram's suggestion, I will remove some patches listed at:
http://groups.google.com/group/vim_dev/web/vim-patches
Descriptions for the following items will be removed to simplify
the list of patches by omitting those that are included in
On Tue, Aug 10, 2010 at 11:15 PM, Bram Moolenaar wrote:
Thanks for testing! Keep an eye out for any remaining problem.
7.3 is going to be released real soon now!
I did another review of the 'netbeans-console' patch, and could not
find anything wrong.
Xavier
--
You received this message
On Mon, Aug 9, 2010 at 10:55 PM, Bram Moolenaar wrote:
Thanks, but it's not quite rigth. Most GUI functions must not be called
when gui.starting is TRUE, only when gui.in_use is TRUE. You might not
notice this when testing, as there are some dependencies on timing.
Also, you missed a few
On Mon, Aug 9, 2010 at 12:02 AM, Lech Lorens wrote:
I just tried using Vim with Pyclewn. According to :help netbeans.txt,
the NetBeans interface is supported in some GUI variants and in console
Vim. I get:
$ pyclewn -e vim
Vim: Caught deadly signal SEGV
Vim: Finished
I can reproduce it
On Fri, May 28, 2010 at 2:59 AM, Tony Mechelynck wrote:
...
I would add not only .*.swp but even .*.sw? (to ignore .swo .swn etc.),
src/auto/config.mk (which is regenerated by configure from the
config.mk.dist and a couple of others) and runtime/doc/tags (which is
regenerated by make
I have tested successfully the following two netbeans vim73 patches
with pyclewn and by running the pyclewn test suite:
o changeset: 2200:8c6a66e2b3cc
| branch: vim73
| user:Bram Moolenaar b...@vim.org
| date:Sat May 22 21:34:09 2010 +0200
| summary: Add :nbstart
On Wed, May 19, 2010 at 12:34 PM, Tony Mechelynck wrote:
...
The problem with that is that though it
is possible to say this is the same revision as that, it is not obvious,
when different, to say which is the latest one. For that we would need a
time reference or something.
...
This
On Wed, May 19, 2010 at 3:36 PM, Tony Mechelynck wrote:
But even if I patched version.c to add one more line to the output of
:version, for me the latest changeset would always be my latest commit
(usually a merge, unless I recently made some new local changes), and that
would not be relevant
On Thu, Feb 11, 2010 at 8:55 PM, Bram Moolenaar wrote:
You move the code to connect for different GUI versions to another
place, away from the disconnect code. I don't see a reason for this.
Why not keep it as it was?
Hi Bram,
netbeans_startup_done() has been split in two parts:
*
1 - 100 din 134 matches
Mail list logo
