Marc Weber wrote:
> Yet another suggestion - what about adding &rtp to sys.path somehow ?
> (with or without python version site-packages or the like)
>
> Then you could
> - write .py files
> - use them from python by
>
> import module
> do_stuff()
>
> Yes - it can be trivially impleme
вторник, 21 мая 2013 г., 5:36:45 UTC+4 пользователь MarcWeber написал:
> Yet another suggestion - what about adding &rtp to sys.path somehow ?
> (with or without python version site-packages or the like)
>
> Then you could
> - write .py files
> - use them from python by
>
> import module
>
oh and it would be cool if python/*.py files could be loaded then, too ?
Did I also miss such feature proposal?
Marc Weber
--
--
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
Yet another suggestion - what about adding &rtp to sys.path somehow ?
(with or without python version site-packages or the like)
Then you could
- write .py files
- use them from python by
import module
do_stuff()
Yes - it can be trivially implemented in tools like vim-addon-manager,
but
Excerpts from ZyX's message of Mon May 20 17:04:25 +0200 2013:
> Python is not VimL: proposed API is not good for python; and I have already
> written
Well - I just thought it would be a nice improvement for VimL, because
it will never happen that all plugins get rewritten using python.
So we need
Added tags interface, vim.environ, signs.find(linenr), suggestion for
__enter__/__exit__:
``vim._tag_files``, ``{buffer}._tag_files``:
Iterators yielding tag file names. ``list(vim._tag_files)`` is an expanded
version of ``&tags`` option.
``vim.tags``, ``{buffer}.tags``:
Mapping-li
> If we are at it: The signs feature is broken by design, because its the
> user setting "sign ids" - so multiple scripts don't know where to start.
>
> What about adding a next_sign_id() function returning a new unused id ?
> A simple counter should be enough. The perfect fix would be dropping t
> vim.signs:
> Mapping-like object mapping sign names to vim.Sign attributes. Iterates
> over
> keys, supports item assignment.
If we are at it: The signs feature is broken by design, because its the
user setting "sign ids" - so multiple scripts don't know where to start.
What about add
On Thu, 16 May 2013 14:20:13 +0200, Roland Eggner
wrote:
> • The age of punch cards is over. Nowadays the common 80 columns limit is
> just
> a habit without any technical reasons. Few people realized it, e.g. the
> Funtoo
> Linux Project has a coding standard with line length up to 160 char
> "f" means function in my dictionary, no confusion.
> You can grep for "vim.f." easily.
“f” is commonly used for file objects (*one* file object for each f). It may
also refer to *one* function. We have more functions there.
> > • The age of punch cards is over. Nowadays the common 80 columns
Roland Eggner wrote:
> Hi Bram!
>
> On 2013-05-15 Wednesday at 20:51 +0200 Bram Moolenaar wrote:
> >
> > 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
On Thursday, May 16, 2013 7:20:13 AM UTC-5, Roland Eggner wrote:
> • The age of punch cards is over. Nowadays the common 80 columns limit is
> just
>
> a habit without any technical reasons.
I agree with using long self-documenting variable names. But 80 characters DOES
have technical meanin
Hi Bram!
On 2013-05-15 Wednesday at 20:51 +0200 Bram Moolenaar wrote:
>
> 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
> 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
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
>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
>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
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
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
RFC was updated. In addition to @Andy Kittner’s suggestions I also added a few
words about exceptions. Main proposal here: transform VimL errors/exceptions
into python ones; this should be relatively easy as we already have :try whose
implementation can be hacked.
--
--
You received this mess
Thanks for the reply.
>I took some time today to look more closely at the RFC and the other resonses
>in this thread. I also played around a bit with creating a "meta-plugin" that
>would allow writing python-only plugins, just to get a feel of things. So,
>with
>all that in mind here is my pri
On Fri, May 10, 2013 at 03:49:45AM +0200, Bram Moolenaar wrote:
ZyX wrote:
This is a description of proposed new python interfaces.
Well, that's a very long list. Do we really need all of this?
Let's at least order by usefulness.
I took some time today to look more closely at the RFC and
> Feature request here if I may.
>
> vim.fnameescape() and vim.evalescape() :: string -> string
> Escapes string so it can be used as argument to command that takes a
> filename or in a vim function respectively.
>
> This could be further extended so evalescape (or perhaps just escape?)
>
On Thu, 9 May 2013 08:30:00 -0700 (PDT), ZyX wrote:
> This is a description of proposed new python interfaces.
...
> =
> Auxilary/helper functions
> =
Feature request here if I may.
vim.fnameescape() and vim.evalescape() :: string -> string
Esc
>> >That is impossible. You may skip some of the list, dict and other Vim
>> >language features, but when it comes to options, regexp, autocommands
>> >and many, many other things you need to know how Vim works. Making a
>> >Python interface for them won't change how Vim works.
>> >
>> >For examp
ZyX wrote:
> >That is impossible. You may skip some of the list, dict and other Vim
> >language features, but when it comes to options, regexp, autocommands
> >and many, many other things you need to know how Vim works. Making a
> >Python interface for them won't change how Vim works.
> >
> >Fo
ZyX wrote:
> >I can’t omit this part of Vim commands. But I can hide it. Also
> >note that we are not talking about user. There is exactly no
> >difference for user between modifying option initally set by
> >import re
> >import json
> >lcs = vim.eval('&lcs')
> >lcs = re.sub(',?eo
>I can’t omit this part of Vim commands. But I can hide it. Also note that we
>are not talking about user. There is exactly no difference for user between
>modifying option initally set by
>import re
>import json
>lcs = vim.eval('&lcs')
>lcs = re.sub(',?eol:.,?', lcs, ',')
>lc
>> And adding python interface that is the same as VimL is
>> 1. throwing away some of the benefits python provides
>> 2. intentionally creating interfaces with design flaws
>> 3. intentionally ignoring python principles like “explicit is
>> better then implicit” (for 2. and 3. refer to my explanat
>That is impossible. You may skip some of the list, dict and other Vim
>language features, but when it comes to options, regexp, autocommands
>and many, many other things you need to know how Vim works. Making a
>Python interface for them won't change how Vim works.
>
>For example, you can make s
ZyX wrote:
> > We also need to keep in mind that all the Vim functionality is nicely
> > documented and there are examples, while if we add a different way to do
> > this in Python this requires documenting how that works. Thus a script
> > writer will have two sets of functionality to learn
Created a gist with suggestions:
https://gist.github.com/ZyX-I/5561409#file-rfc-rst.
--
--
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 t
> Negative impact to the performance will be there, but nothing as critical as
> fallback implementation for vim.bindeval would show.
* Negative impact will not be that great only in absolute measures and because
I don’t need to pass about a hundred KiBs with these new interfaces like I
needed
> Where it is feasible to implement it directly in python that sounds like
> a good idea to me since it would probably ease the future maintenance
> and allow more people to contribute to it.
>
> Though for some of the suggested additions I imagine that it will
> negatively impact the performan
> We also need to keep in mind that all the Vim functionality is nicely
> documented and there are examples, while if we add a different way to do
> this in Python this requires documenting how that works. Thus a script
> writer will have two sets of functionality to learn to use. It will be
On Sat, May 11, 2013 at 03:50:50PM +0200, Bram Moolenaar wrote:
[...]
If most things are already possible, then it should be possible to write
Python functions that work as a nice interface for the functionality.
Thus not change the C implementation of the Python interface.
Where it is feasible t
ZyX wrote:
> > Well, that's a very long list. Do we really need all of this?
> > Let's at least order by usefulness. First add things that help
> > plugin writers most. I'm assuming that very few users will type
> > Python commands, I expect them to be used in scripts.
> > We could lower prior
> Well, that's a very long list. Do we really need all of this?
> Let's at least order by usefulness. First add things that help
> plugin writers most. I'm assuming that very few users will type
> Python commands, I expect them to be used in scripts.
> We could lower priority for things that are
ZyX wrote:
> This is a description of proposed new python interfaces.
Well, that's a very long list. Do we really need all of this?
Let's at least order by usefulness. First add things that help
plugin writers most. I'm assuming that very few users will type
Python commands, I expect them to
This is a description of proposed new python interfaces.
==
New python objects
==
vim.mappings/{buffer}.mappings:
Dictionary-like object mapping mode characters to vim.modemappings objects
below. Unlike vim.buffers iteration is being done for keys.
modema
42 matches
Mail list logo
