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 out
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 numer
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 os_unix.c:
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 i
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/local/lib/python2.7/d
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 wit
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 acknowl
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
usin
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 co
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 Ga
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
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
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/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 i
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.
>>
>&g
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 s
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/buff
On 02/20/2015 12:29 PM, Xavier de Gaye wrote:
> 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
>
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
BufWin
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 key or the mouse to
the corresp
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 th
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 no
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
er
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.
>> The
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 bei
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
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
>> &g
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 a
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
W
:edit foobar -> a) foobar still contains two lines
:edit foobar
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 we
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 o
On Sat, May 25, 2013 at 10:47 AM, ZyX wrote:
> # HG changeset patch
> # User ZyX
> # Date 1369465902 -14400
> # Node ID f3a1f7c373ee941b71739260f72f6babbff6ce0f
> # Parent e3fac877d315709055ffaec4cc32a5f971ef5e97
> Fix invalid read errors:
>
> defer DICTKEY_UNREF until key is no longer needed
>
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
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/pyt
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
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 in
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 v
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
then.
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 funct
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 m
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
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
>>
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&#x
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.
>
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. Ther
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 t
On Tue, Apr 17, 2012 at 5:00 PM, Senthil Kumaran wrote:
> On Tuesday, 17 April 2012 22:11:07 UTC+8, Xavier de Gaye wrote:
>> If you do not see 2.7.3 when you run:
>>
>> :python import sys; print sys.version
>>
>> then it is because you are running in Vim an &
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=''
>
> I tried this, but it did not help.
>
> The error message has something to do with
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
>> simp
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 com
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
>>
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 cl
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 i
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 mak
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
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 c
On Wed, Oct 19, 2011 at 4:38 PM, Yegappan Lakshmanan
wrote:
> Hi,
>
> On Wed, Oct 19, 2011 at 3:55 AM, Xavier de Gaye 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-
>> &g
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 loc
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() wh
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 ob
On Thu, Sep 15, 2011 at 10:48 AM, Kerneels Roos wrote:
> NETBEANS PROTOCOL:
> I've made some experiments with the netbeans protocol interfacing vim
> provides when started with the -nb flag or the :nbstart command inside a
> running instance.
>
> On win32 at least the -nb command line option with t
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: http://lokoti.alwaysda
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
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.
>> >
&
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
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 thi
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 read
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 readin
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 prematurel
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 o
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
'test_bp_restor
Support for athena in netbeans has been added with the following
patch:
patch 7.3.016: Support Athena, just like Motif
However the motif and athena code in netbeans still follows the old
design where netbeans-read() calls directly netbeans_parse_messages()
within the gui event loop. This had
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 'node
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.
> F
On Thu, Oct 14, 2010 at 2:21 AM, Charles E Campbell Jr wrote:
>
> This patch is causing "vanishing signs syndrome". Here's a test procedure:
>
> When in .../vim73/src,
> ./vim -g -N -u NONE -S tst.vim
>
> where tst.vim is:
>
> e! main.c
> 169
> sign define TestSign icon=../pixmaps/tb_close.xpm
>
On Wed, Sep 29, 2010 at 6:41 PM, Bram Moolenaar 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.
>
> Looking at this patch I'm wo
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 hav
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
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 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
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 :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 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
On Thu, Aug 19, 2010 at 3:45 PM, Ben Fritz wrote:
>
> I know about all of these except vimGdb. Wasn't that some sort of
> debugger integration? Is that really included in Vim 7.3? Or is it
> just no longer supported?
>
The patch is not included in Vim 7.3.
The patch is supported (see http://clewn
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 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 v
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
&
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 'd
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.fde086
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:
vim-
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
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 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
&g
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 mess
1 - 100 din 152 matches
Mail list logo
