ZyX wrote:
> Thanks. Same change should be added to test87.
"make test" succeeded for all test except test86.
So it was fine already. But perhaps it succeeded
because recent messages are not translated yet.
I'll look at it this coming weekend.
Dominique
--
--
You received this message from t
> Maybe code somewhere uses curwin to get current buffer in place of curbuf.
Testing with the following patch applied (note the hash after diff -r, it is
the same as parent of the posted patch) seems to prove my guess: it indeed does
work. I don’t know where bugs may lie if you set curwin->w_buf
> Python: Adding line to buffer other than the current one doesn't work
> correctly. (Rozbujnik, 2010 Dec 19)
The following patch fixes things, but don’t ask me why. Just taken code from
f_setbufvar for saving/restoring curbuf.
Maybe code somewhere uses curwin to get current buffer in place of c
# HG changeset patch
# User ZyX
# Date 1368672552 -14400
# Branch python-extended-2
# Node ID 5f8adb1d88b905d73dc2b4d106740759a66113b3
# Parent 02c4f613343a69eeba16a8a4742f5a9dee269861
Add tp_traverse and tp_clear
diff -r 02c4f613343a -r 5f8adb1d88b9 src/if_py_both.h
--- a/src/if_py_both.h Thu
# HG changeset patch
# User ZyX
# Date 1368673074 -14400
# Branch python-extended-2
# Node ID 02c4f613343a69eeba16a8a4742f5a9dee269861
# Parent 9ea73172864c892283abb0735b427cba5485820c
Record tabpage in window
Needed to report correct window.number for non-current-tabpage windows
For backwards
четверг, 16 мая 2013 г., 5:35:49 UTC+4 пользователь ZyX написал:
> Thanks. Same change should be added to test87.
Added to patch in "Python items in the todo list" thread.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replyi
# HG changeset patch
# User ZyX
# Date 1368668966 -14400
# Branch python-extended-2
# Node ID 9ea73172864c892283abb0735b427cba5485820c
# Parent bdbdab08cc4de3f8e44567bff7ff3a032287dec3
Fix tests: messages (:lang C suggested by Dominique Pelle) and iminsert
(replaced with shiftwidth)
diff -r bdb
Thanks. Same change should be added to test87.
--
--
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
---
You received this message because you are subscribed
Hi
test86 fails in Vim-7.3.959 when using the locale is
fr_FR.UTF8 (and possibly other locale).
It fails because some messages are translated and
test expects to find messages in English:
===
$ diff test86.ok test86.failed
334c334
< (1): 1 windows, curre
Patch 7.3.960
Problem:Compiler warning for unused variable.
Solution: Put declaration in #ifdef.
Files: src/window.c
*** ../vim-7.3.959/src/window.c 2013-05-15 15:12:25.0 +0200
--- src/window.c2013-05-15 23:11:02.0 +0200
***
*** 2124,2130
--- 2
Hi LCD!
On Mi, 15 Mai 2013, LCD 47 wrote:
> (1) getqfstack() / getlocstack() should simply return a list of
> loclists;
> (2) there should be a separate function for getting (and perhaps another
> one for setting) the stack pointer in these lists, namely a number
> in range 0 .. len(l
Bram Moolenaar wrote:
> Danek Duvall wrote:
>
> > On Wed, May 15, 2013 at 06:58:53PM +0200, Bram Moolenaar wrote:
> >
> > > Patch to dynamically load Python on Solaris. (Danek Duvall, 2009 Feb 16)
> > > Needs more work.
> >
> > I don't know that it's worth following up on this. The current pyt
Jan Pobrislo wrote:
Glib inside gvim, since gtk+ uses glib internally. More precisely glib is
that part of gtk+ that does not deal with gui, so there's no gvim without
glib. (Unless there's implementation of gvim not based on gtk which I'm
unaware of).
A gvim can be compiled using motif under L
Christian Brabandt wrote:
Hi Bram!
On Mo, 13 Mai 2013, Bram Moolenaar wrote:
Not. I only want to work with the syntax files that I have, which are
the distributed ones. I'm not going to download and install syntax
files for this test.
There are more than 500 syntax files, that should be mor
> Ideally we could do vim.f.{function-name}() for every function defined
> in eval.c. That's more than 250 functions. Creating a funcref for each
> of them might slow down startup. I assume we can do it only when used.
New funcref structure is something like `struct func_T {void *func_data; str
> Calling functions would be a very common thing. Thus I would keep the
> name as short as possible: vim.f.bufnr('%')
Adding cryptic names is not a good idea. Also note that calling built-in
functions it is not so common and will not become more common later. Most used
after examining sources o
Danek Duvall wrote:
> On Wed, May 15, 2013 at 06:58:53PM +0200, Bram Moolenaar wrote:
>
> > Patch to dynamically load Python on Solaris. (Danek Duvall, 2009 Feb 16)
> > Needs more work.
>
> I don't know that it's worth following up on this. The current python/dyn
> interface works just fine on
ZyX wrote:
[...]
> >Would it be possible to have most Vim functions made callable from
> >Python this way? Obviously it's much better than using vim.eval().
>
> I assumed it be a convenience wrapper replacing
>
> vim.bindeval('function("bufnr")')('%')
>
> (obviously, you can save `vim.b
ZyX 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 of ":cd" in Vim, handling the si
>I have included all the Python patches that I had listed in the todo
>file, except some old ones.
>
>Below is the list of remaining Python items. Please have a look and
>tell me what is still an issue and what can be dropped.
>
>There is also the patch from Yasuhiro Matsumoto that breaks the test
On Wed, May 15, 2013 at 06:58:53PM +0200, Bram Moolenaar wrote:
> Patch to dynamically load Python on Solaris. (Danek Duvall, 2009 Feb 16)
> Needs more work.
I don't know that it's worth following up on this. The current python/dyn
interface works just fine on Solaris, and while it's probably po
ZyX wrote:
> > + /* TODO: a proper error number */
> > + EMSG(_("E000: return value must be an instance of str"));
>
> You missed this TODO.
Thanks for noticing.
If you have time, it would be good to have the Python 2 equivalent.
And tests...
--
MESKIMEN'S LAW
There's
Patch 7.3.959 (after 7.3.957)
Problem:Missing error number.
Solution: Assign an error number.
Files: src/if_python3.c
*** ../vim-7.3.958/src/if_python3.c 2013-05-15 18:28:08.0 +0200
--- src/if_python3.c2013-05-15 19:41:51.0 +0200
***
*** 1007,1013 *
ZyX wrote:
> --=_Part_4970_15270404.1368633093914
> Content-Type: text/plain; charset=ISO-8859-1
>
> > *** ../vim-7.3.947/src/if_py_both.h 2013-05-15 14:39:47.0 +0200
> > --- src/if_py_both.h2013-05-15 14:49:11.0 +0200
> > ***
> > *** 564,569
> > ---
Patch 7.3.958
Problem:Python: Iteration destructor not set.
Solution: Put IterDestructor to use. (ZyX)
Files: src/if_py_both.c
*** ../vim-7.3.957/src/if_py_both.h 2013-05-15 17:49:00.0 +0200
--- src/if_py_both.h2013-05-15 19:00:19.0 +0200
***
*** 56
I have included all the Python patches that I had listed in the todo
file, except some old ones.
Below is the list of remaining Python items. Please have a look and
tell me what is still an issue and what can be dropped.
There is also the patch from Yasuhiro Matsumoto that breaks the tests,
see
> + /* TODO: a proper error number */
> + EMSG(_("E000: return value must be an instance of str"));
You missed this TODO.
--
--
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 informatio
> After including this patch the tests were failing. The .ok files had
> "" where the test results in "window". I assume those question
> marks were wrong, so I fixed the .ok files for that. But I wonder why
> this happened.
Because you have problems with encoding somewhere: there were no q
Patch 7.3.957
Problem:Python does not have a "do" command like Perl or Lua.
Solution: Add the ":py3do" command. (Lilydjwg)
Files: runtime/doc/if_pyth.txt, src/ex_cmds.h, src/ex_docmd.c,
src/if_python3.c, src/proto/if_python3.pro
*** ../vim-7.3.956/runtime/doc/if_pyth.txt
> *** ../vim-7.3.947/src/if_py_both.h 2013-05-15 14:39:47.0 +0200
> --- src/if_py_both.h 2013-05-15 14:49:11.0 +0200
> ***
> *** 564,569
> --- 564,570
> return (PyObject *)(self);
> }
>
> + #if 0 /* unused */
> static void
> IterDestructor
Patch 7.3.956
Problem:Python vim.bindeval() causes SIGABRT.
Solution: Make pygilstate a local variable. (Yukihiro Nakadaira)
Files: src/if_py_both.h, src/if_python.c, src/if_python3.c
*** ../vim-7.3.955/src/if_py_both.h 2013-05-15 16:11:46.0 +0200
--- src/if_py_both.h2
>Hi,
>
>I've written a couple of large vim plugins, I'm working with ZyX on
>Powerline, and I'd like to add my vote for the proposed functionality in
>this RFC.
>
>Having direct access to vim functionality with good bindings like
>suggested in this RFC would remove a huge hurdle with writing vim
Yasuhiro Matsumoto wrote:
> > I found problem of my patch. It doesn't work with here doc. I'll look into
> > it.
>
> I've updated.
Unfortunately, with the current source code this makes the tests fail.
Hopefully this can be fixed.
--
LAUNCELOT: I am, sir. I am a Knight of King Arthur.
FATHER
>On 05/15/13 13:06, Bram Moolenaar wrote:
>>
>> ZyX wrote:
>>
3. vim.functions:
Again, the introspection is not strictly necessary, but a convenience
wrapper that pulls the FuncRefs will make code look much nicer.
In that regard I'd also offer attribute access for built
>Would it be possible to have most Vim functions made callable from
>Python this way? Obviously it's much better than using vim.eval().
I assumed it be a convenience wrapper replacing
vim.bindeval('function("bufnr")')('%')
(obviously, you can save `vim.bindeval('function("bufnr")')` result
On 05/15/13 13:06, Bram Moolenaar wrote:
>
> ZyX wrote:
>
>>> 3. vim.functions:
>>> Again, the introspection is not strictly necessary, but a convenience
>>> wrapper that pulls the FuncRefs will make code look much nicer.
>>> In that regard I'd also offer attribute access for builtin/ glob
Patch 7.3.955
Problem:Python: Not enough tests.
Solution: Add tests for vim.{current,window*,tabpage*}. (ZyX)
Files: src/testdir/test86.in, src/testdir/test86.ok,
src/testdir/test87.in, src/testdir/test87.ok
*** ../vim-7.3.954/src/testdir/test86.in2013-05-15 14:51:
ZyX wrote:
> # HG changeset patch
> # User ZyX
> # Date 1367420260 -14400
> # Branch python-extended-2
> # Node ID 9f25c7e5b0bdee4ecace3c2a337af3e60394e03e
> # Parent 9a4df126f7c42e0b81df62eba1249300a906f450
> Add tests for vim.{current,window*,tabpage*}
After including this patch the tests we
Patch 7.3.954
Problem:No check if PyObject_IsTrue fails.
Solution: Add a check for -1 value. (ZyX)
Files: src/if_py_both.h
*** ../vim-7.3.953/src/if_py_both.h 2013-05-15 15:51:03.0 +0200
--- src/if_py_both.h2013-05-15 16:08:53.0 +0200
***
*** 700,70
Patch 7.3.953
Problem:Python: string exceptions are deprecated.
Solution: Make vim.error an Exception subclass. (ZyX)
Files: src/if_python.c, src/if_python3.c
*** ../vim-7.3.952/src/if_python.c 2013-05-15 15:44:24.0 +0200
--- src/if_python.c 2013-05-15 16:02:20.00
Hi,
I've written a couple of large vim plugins, I'm working with ZyX on
Powerline, and I'd like to add my vote for the proposed functionality in
this RFC.
Having direct access to vim functionality with good bindings like
suggested in this RFC would remove a huge hurdle with writing vim
plugin
Patch 7.3.952
Problem:Python: It's not easy to change window/buffer/tabpage.
Solution: Add ability to assign to vim.current.{tabpage,buffer,window}.
(ZyX)
Files: runtime/doc/if_pyth.txt, src/if_py_both.h
*** ../vim-7.3.951/runtime/doc/if_pyth.txt 2013-05-15 15:12:25.0
Patch 7.3.951
Problem:Python exceptions have problems.
Solution: Change some IndexErrors to TypeErrors. Make “line number out of
range” an IndexError. Make “unable to get option value” a
RuntimeError. Make all PyErr_SetString messages start with
lowercase
Patch 7.3.950
Problem:Python: Stack trace printer can't handle messages.
Solution: Make KeyErrors use PyErr_SetObject. (ZyX)
Files: src/if_py_both.h, src/if_python3.c, src/if_python.c
*** ../vim-7.3.949/src/if_py_both.h 2013-05-15 15:12:25.0 +0200
--- src/if_py_both.h2
Patch 7.3.949
Problem:Python: no easy access to tabpages.
Solution: Add vim.tabpages and vim.current.tabpage. (ZyX)
Files: runtime/doc/if_pyth.txt, src/if_py_both.h, src/if_python3.c,
src/if_python.c, src/proto/if_python3.pro,
src/proto/if_python.pro, src/proto/w
Patch 7.3.948
Problem:Cannot build with Python 2.2
Solution: Make Python interface work with Python 2.2
Make 2.2 the first supported version. (ZyX)
Files: src/if_py_both.h, src/if_python3.c, src/if_python.c,
src/testdir/test86.in, src/testdir/test86.ok,
Patch 7.3.947
Problem:Python: No iterator for vim.list and vim.bufferlist.
Solution: Add the iterators. Also fix name of FunctionType. Add tests for
vim.buffers. (ZyX)
Files: runtime/doc/if_pyth.txt, src/eval.c, src/if_py_both.h,
src/if_python3.c, src/if_python.
Patch 7.3.946
Problem:Sometimes get stuck in waiting for cursor position report,
resulting in keys starting with [ not working.
Solution: Only wait for more characters after [ if followed by '?', '>'
or a digit.
Files: src/term.c
*** ../vim-7.3.945/src/term.c
Am 15.05.2013 13:06, schrieb Bram Moolenaar:
Karsten Hopp wrote:
> Attached is a simple text file that triggers the E363: error on some
> of the brackets. Setting maxmempattern to 5000 instead of using the
> default 1000 works around this, but asthereseems to be nothing special
> in that file I
Patch 7.3.945
Problem:Python: List of buffers is not very useful.
Solution: Make vim.buffers a map. No iterator yet. (ZyX)
Files: runtime/doc/if_pyth.txt, src/if_py_both.h, src/if_python3.c,
src/if_python.c, src/testdir/test86.ok, src/testdir/test87.ok
*** ../vim-7.3.944/r
Karsten Hopp wrote:
> Attached is a simple text file that triggers the E363: error on some
> of the brackets. Setting maxmempattern to 5000 instead of using the
> default 1000 works around this, but asthereseems to be nothing special
> in that file I suspect a bug in the matchparen.vim plugin.
>
Christian Brabandt wrote:
> Hi Bram!
>
> On So, 12 Mai 2013, Bram Moolenaar wrote:
>
> >
> > Christian Brabandt wrote:
> >
> > > On So, 12 Mai 2013, Bram Moolenaar wrote:
> > >
> > > > Wouldn't it be better to have the entries and the titles in a list?
> > >
> > > We could do this as well.
Chiel Tenbrinke wrote:
> On Sunday, May 12, 2013 2:09:32 PM UTC+2, Chiel92 wrote:
> > Thank you for your explanation. So would it be appreciated to include
> > four compiler plugins for C# (csc,msc,msbuild,xbuild)?
> > I can create those easily from what we have now.
>
> Noticing that mcs is alre
ZyX wrote:
> >3. vim.functions:
> > Again, the introspection is not strictly necessary, but a convenience
> > wrapper that pulls the FuncRefs will make code look much nicer.
> > In that regard I'd also offer attribute access for builtin/ global
> > functions in addition to the getitem s
54 matches
Mail list logo
