Planning Vim 7.3

52 views
Skip to first unread message

Bram Moolenaar

unread,
Apr 11, 2010, 10:33:31 AM4/11/10
to vim-an...@vim.org, vim...@vim.org, v...@vim.org, vim...@vim.org, vim-mu...@vim.org

Hello Vim users!

It has been a long time since the last release: Vim 7.2 was released in
August 2008. There have been many patches, but not everybody will use
them. It's about time for 7.3!

I will try to include a few patches that have been pending for a while.
I don't have much time available, thus I will only include things that
take a few hours of my time. That basically means patches that are
ready to be included.

I will check the voting list to see what the most popular features are:
http://www.vim.org/sponsor/vote_results.php

One thing that I will certainly do is improve the MS-Windows installer.
I recently installed Vim on a new laptop and it didn't work very well.
More and more people are using Windows 7. I think that taking Window XP
as the minimal platform will work well. I hope we can make installing
Vim on MS-Windows as simple and reliable as possible.

I also plan to drop the split in "lang" and "extra" archives. The
burden to have several feature sets is no longer justified by the
slightly smaller distribution. Putting everything together makes things
a lot simpler.

Mercurial is going to be the primary method for distribution. I'll
drop CVS, it slows me down too much. Someone else might be able to
mirror the Mercurial repository in CVS, like it's done for Subversion.

I hope to bring out a first beta version by the end of May. That gives
everybody time to send me updated and polished patches and runtime
files. I need to have these halfway May, I also need some time to
integrate everything.

It would also be nice if we can update the spell files. Volunteers
wanted! See $VIMRUNTIME/spell/README.txt, the "MAINTAINING A LANGUAGE"
section.

--
SOLDIER: What? A swallow carrying a coconut?
ARTHUR: It could grip it by the husk ...
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

--
You received this message from the "vim_announce" maillist.
For more information, visit http://www.vim.org/maillist.php

To unsubscribe, reply using "remove me" as the subject.

Tony Mechelynck

unread,
Apr 11, 2010, 11:31:05 AM4/11/10
to vim_mu...@googlegroups.com, Bram Moolenaar, Vim Developers, Vim List, vim...@googlegroups.com
On 11/04/10 16:33, Bram Moolenaar wrote:
[...]

> It would also be nice if we can update the spell files. Volunteers
> wanted! See $VIMRUNTIME/spell/README.txt, the "MAINTAINING A LANGUAGE"
> section.
>

IIUC, Mozilla uses the same spellfile format as Vim? If that's the case,
and if the Mozilla license (which, BTW, is undergoing revision, see
among others
http://blog.lizardwrangler.com/2010/03/10/updating-the-mozilla-public-license/
), or whatever other license some of these dictionaries may be using, is
found to be compatible with the Vim license, then maybe we could "just"
borrow the desired files from the dictionaries at
https://addons.mozilla.org/en-US/thunderbird/browse/type:3 ? (Note: an
.xpi is just a .zip under another name.)


Best regards,
Tony.
--
Heavy, adj.:
Seduced by the chocolate side of the force.

Dominique Pellé

unread,
Apr 11, 2010, 12:10:57 PM4/11/10
to vim...@googlegroups.com, vim_mu...@googlegroups.com, Bram Moolenaar, Vim List, vim...@googlegroups.com
Tony Mechelynck wrote:


":help spell-mkspell" says:

----------------------------------------------------------------------------
You can create a Vim spell file from the .aff and .dic files that Myspell
uses. Myspell is used by OpenOffice.org and Mozilla. You should be able to
find them here:
http://wiki.services.openoffice.org/wiki/Dictionaries
----------------------------------------------------------------------------

The link in help file contains dictionaries for the old OpenOffice-2.x.

OpenOffice-3.x has changed the format of the dictionaries
OpenOffice-3.x dictionaries are available at:

http://extensions.services.openoffice.org/dictionary

Does anybody knows whether it's possible to convert the
OpenOffice-3.x dictionaries to Vim dictionaries?

OpenOffice-3.x has more dictionaries than OpenOffice-2.x.
For example, I'm interested in converting the Breton dictionary
to Vim, but it's only available for OpenOffice-3.x and not OpenOffice-2.x.

Cheers
-- Dominique

Christian Brabandt

unread,
Apr 11, 2010, 2:28:46 PM4/11/10
to vim...@googlegroups.com, vim...@vim.org, v...@vim.org, vim...@vim.org, vim-mu...@vim.org
Hi Bram!

Are you considering any patches from
http://groups.google.com/group/vim_dev/web/vim-patches
for inclusion?

regards,
Christian

Bram Moolenaar

unread,
Apr 11, 2010, 4:16:53 PM4/11/10
to Christian Brabandt, vim...@googlegroups.com, vim...@vim.org, v...@vim.org, vim...@vim.org, vim-mu...@vim.org

Christian Brabandt wrote:

> Are you considering any patches from
> http://groups.google.com/group/vim_dev/web/vim-patches
> for inclusion?

Yes, but many of these patches are not mature. E.g., first one,
"Improved regular expression engine", is still lacking the tests to
verify that it doesn't break anything. That's a pity, because it can
make syntax highlighting much faster.

I want to avoid that I include something that triggers a long sequence
of bug fixes. "Works fine for me" is not always a good indication.
7.3 is going to be a stable release, thus I don't want to take too much
risc. Part of my work will be to estimate the risc, which involves
carefully looking through the code changes.

--
CART DRIVER: Bring out your dead!
We follow the cart through a wretched, impoverished plague-ridden village.
A few starved mongrels run about in the mud scavenging. In the open
doorway of one house perhaps we jug glimpse a pair of legs dangling from
the ceiling. In another doorway an OLD WOMAN is beating a cat against a
wall rather like one does with a mat. The cart passes round a dead donkey
or cow in the mud. And a MAN tied to a cart is being hammered to death by
four NUNS with huge mallets.

Asif Iqbal

unread,
Apr 11, 2010, 4:33:02 PM4/11/10
to vim...@googlegroups.com, vim...@googlegroups.com, vim_mu...@googlegroups.com, Bram Moolenaar, vim...@googlegroups.com
2010/4/11 Dominique Pellé <dominiq...@gmail.com>:

> Tony Mechelynck wrote:
>
>> On 11/04/10 16:33, Bram Moolenaar wrote:
>> [...]
>>>
>>> It would also be nice if we can update the spell files.  Volunteers
>>> wanted!  See $VIMRUNTIME/spell/README.txt, the "MAINTAINING A LANGUAGE"
>>> section.
>>>
>>
>> IIUC, Mozilla uses the same spellfile format as Vim? If that's the case, and
>> if the Mozilla license (which, BTW, is undergoing revision, see among others
>> http://blog.lizardwrangler.com/2010/03/10/updating-the-mozilla-public-license/
>> ), or whatever other license some of these dictionaries may be using, is
>> found to be compatible with the Vim license, then maybe we could "just"
>> borrow the desired files from the dictionaries at
>> https://addons.mozilla.org/en-US/thunderbird/browse/type:3 ? (Note: an .xpi
>> is just a .zip under another name.)
>
>
> ":help spell-mkspell" says:

would be nice if there is a feature for english (american english) grammar.
even better a google plugin to suggest correct usage that grammar
alone may not help
like

I is sick
He was play football

stuff like that. I use vim as my email editor with mutt, so this would
be really useful

>
> ----------------------------------------------------------------------------
> You can create a Vim spell file from the .aff and .dic files that Myspell
> uses.  Myspell is used by OpenOffice.org and Mozilla.  You should be able to
> find them here:
>        http://wiki.services.openoffice.org/wiki/Dictionaries
> ----------------------------------------------------------------------------
>
> The link in help file contains dictionaries for the old OpenOffice-2.x.
>
> OpenOffice-3.x has changed the format of the dictionaries
> OpenOffice-3.x dictionaries are available at:
>
> http://extensions.services.openoffice.org/dictionary
>
> Does anybody knows whether it's possible to convert the
> OpenOffice-3.x dictionaries to Vim dictionaries?
>
> OpenOffice-3.x has more dictionaries than OpenOffice-2.x.
> For example, I'm interested in converting the Breton dictionary
> to Vim, but it's only available for OpenOffice-3.x and not OpenOffice-2.x.
>
> Cheers
> -- Dominique
>

> --
> You received this message from the "vim_use" 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
>
> To unsubscribe, reply using "remove me" as the subject.
>

--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Tony Mechelynck

unread,
Apr 12, 2010, 3:08:06 AM4/12/10
to vim_mu...@googlegroups.com, Bram Moolenaar, Christian Brabandt, vim...@googlegroups.com, vim...@vim.org, v...@vim.org, vim...@vim.org, vim-mu...@vim.org
On 11/04/10 22:16, Bram Moolenaar wrote:
>
> Christian Brabandt wrote:
>
>> Are you considering any patches from
>> http://groups.google.com/group/vim_dev/web/vim-patches
>> for inclusion?
>
> Yes, but many of these patches are not mature. E.g., first one,
> "Improved regular expression engine", is still lacking the tests to
> verify that it doesn't break anything. That's a pity, because it can
> make syntax highlighting much faster.
>
> I want to avoid that I include something that triggers a long sequence
> of bug fixes. "Works fine for me" is not always a good indication.
> 7.3 is going to be a stable release, thus I don't want to take too much
> risc. Part of my work will be to estimate the risc, which involves
> carefully looking through the code changes.
>

It is true that they are in different stages of development. Here are my
top five; not in preference order.

#14 (Vince Negri's conceal/ownsyntax/cursorbind) already has a long
track record. I first heard about it when I first learned about Steve
Hall's Vim for Windows, that must have been in Vim 6.2 or 6.3 time, and
it was not new even then. Has documentation. Maybe too controversial
(not enough "mainline"-like) to be included by default? OTOH it has been
victim of bit-rotting in the past (i.e. conflict with "mainline"
patches) and of course bringing it in would eliminate that problem
forever. A compile-time option maybe (or two, or three)? You're the boss.

#13 (Access W32 clipboard from Cygwin "Unix" Vim) is interesting but
still in beta. IIUC ifdeffed by whatever FEAT_* corresponds to
has('win32unix'). Bring 'em in or let it bake some more?

#10 (Variable tabstops) sounds interesting. I haven't tested it.
Reportedly still in alpha. Probably wait some more (Vim 8.0 ?) but keep
an eye on it.

#9 (Relative line numbers) sounds interesting. I haven't tested it. Its
authors say "it works". I don't feel competent to evaluate it by
eyeballing the code.

#7 (Bill McCarthy's additional float functions). This one I've taken up
in my "Huge" Vim. Not a single problem AFAICT. Code examination shows
that it is done cleanly and simply, within #ifdef FEAT_FLOAT, and does
not interfere with other stuff outside the "call function -> return
value" codepath. IMHO this one is the most worthy of including into
mainline Vim (and perhaps the least risky). Maybe a one-time check in a
build with FEAT_EVAL on and FEAT_FLOAT off to make sure no #ifdef was
forgotten. (I already compile a Tiny build without +eval in addition to
my Huge build, from the same source, and no problems there either.)
Documentation exists and is well-written, as a separate helpfile to
avoid problems with rsync; probably merge that into eval.txt.


Best regards,
Tony.
--
n = ((n >> 1) & 0x55555555) | ((n << 1) & 0xaaaaaaaa);
n = ((n >> 2) & 0x33333333) | ((n << 2) & 0xcccccccc);
n = ((n >> 4) & 0x0f0f0f0f) | ((n << 4) & 0xf0f0f0f0);
n = ((n >> 8) & 0x00ff00ff) | ((n << 8) & 0xff00ff00);
n = ((n >> 16) & 0x0000ffff) | ((n << 16) & 0xffff0000);

-- C code which reverses the bits in a word.

mmarko

unread,
Apr 12, 2010, 4:20:45 AM4/12/10
to vim_use
On 11 apr., 16:33, Bram Moolenaar <B...@Moolenaar.net> wrote:
> Hello Vim users!

>
> I will try to include a few patches that have been pending for a while.
> I don't have much time available, thus I will only include things that
> take a few hours of my time.  That basically means patches that are
> ready to be included.
>
> I will check the voting list to see what the most popular features are:http://www.vim.org/sponsor/vote_results.php
>

Hi Bram!

I have a patch for if_python.c that adds direct access to Vims
internal screen.
It creates a new python object vim.screen with the following methods:
puts, getHighlightAttr, mousex, mousey. The patch can be used to
create
"gui" forms that would be available in all versions of Vim (with
+python), especially
if more integration between Vim and Python is planned.

http://sourceforge.net/projects/vimuiex/files/vimpatch/vimpatch-0.6.6.zip/download
The patch changes: if_python.c, eval.c, version.c, configure.in and
config.h.in
The feature can be enabled during ./configure with --enable-
pythonscreen.
I've been using it for a year now without problems/crashes.

Marko

Edward L. Fox

unread,
Apr 12, 2010, 4:58:36 AM4/12/10
to vim...@googlegroups.com, vim-an...@vim.org, vim...@vim.org, v...@vim.org, vim...@vim.org, vim-mu...@vim.org
On Sun, Apr 11, 2010 at 04:33:31PM +0200, Bram Moolenaar wrote:
>
> Hello Vim users!
>
> [...]

>
> Mercurial is going to be the primary method for distribution. I'll
> drop CVS, it slows me down too much. Someone else might be able to
> mirror the Mercurial repository in CVS, like it's done for Subversion.

I don't think we have any reason to keep the CVS repository any
longer. It's way too slow and rather user-unfriendly. Nobody will
want to use CVS if he could have any other alternatives.

I think the Subversion repository should also be abandoned. I tried
Mercurial, it's rather powerful and very easy to use. I suggest that
we just stick with Mercurial and only use this as official repository.
If any other people wish to use other forms of repositories, they can
publish their unofficial mirrors, just as vim-cocoa does.

> I hope to bring out a first beta version by the end of May. That gives
> everybody time to send me updated and polished patches and runtime
> files. I need to have these halfway May, I also need some time to
> integrate everything.

What's the feature-freeze date? I want to submit a small feature and
a tiny feature. Hope I could have enough time for that.

> It would also be nice if we can update the spell files. Volunteers
> wanted! See $VIMRUNTIME/spell/README.txt, the "MAINTAINING A LANGUAGE"
> section.
>
> --
> SOLDIER: What? A swallow carrying a coconut?
> ARTHUR: It could grip it by the husk ...
> "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
>
> /// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
> /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\ download, build and distribute -- http://www.A-A-P.org ///
> \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
>
> --

> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.

Christian Brabandt

unread,
Apr 12, 2010, 5:43:50 AM4/12/10
to vim...@googlegroups.com, vim...@vim.org
Hi Tony!
(replying to vim_use and vim_dev. Should we keep the discussion on
vim_dev or rather on vim_use?)

Disclaimer:
I know, this is not a wishlist thread, but I could not resist ;)

On Mo, 12 Apr 2010, Tony Mechelynck wrote:
> It is true that they are in different stages of development. Here are
> my top five; not in preference order.
>
> #14 (Vince Negri's conceal/ownsyntax/cursorbind) already has a long
> track record. I first heard about it when I first learned about Steve
> Hall's Vim for Windows, that must have been in Vim 6.2 or 6.3 time, and
> it was not new even then. Has documentation. Maybe too controversial
> (not enough "mainline"-like) to be included by default? OTOH it has been
> victim of bit-rotting in the past (i.e. conflict with "mainline"
> patches) and of course bringing it in would eliminate that problem
> forever. A compile-time option maybe (or two, or three)? You're the boss.

I'd like that too.


>
> #13 (Access W32 clipboard from Cygwin "Unix" Vim) is interesting but
> still in beta. IIUC ifdeffed by whatever FEAT_* corresponds to
> has('win32unix'). Bring 'em in or let it bake some more?

I have no opinion on that.


>
> #10 (Variable tabstops) sounds interesting. I haven't tested it.
> Reportedly still in alpha. Probably wait some more (Vim 8.0 ?) but keep
> an eye on it.

I'd like that one.

>
> #9 (Relative line numbers) sounds interesting. I haven't tested it. Its
> authors say "it works". I don't feel competent to evaluate it by
> eyeballing the code.

I'd really like that one.


>
> #7 (Bill McCarthy's additional float functions). This one I've taken up
> in my "Huge" Vim. Not a single problem AFAICT. Code examination shows
> that it is done cleanly and simply, within #ifdef FEAT_FLOAT, and does
> not interfere with other stuff outside the "call function -> return
> value" codepath. IMHO this one is the most worthy of including into
> mainline Vim (and perhaps the least risky). Maybe a one-time check in a
> build with FEAT_EVAL on and FEAT_FLOAT off to make sure no #ifdef was
> forgotten. (I already compile a Tiny build without +eval in addition to
> my Huge build, from the same source, and no problems there either.)
> Documentation exists and is well-written, as a separate helpfile to
> avoid problems with rsync; probably merge that into eval.txt.

If you consider that, would you also consider including a random()
function call?

Additionally I'd like persistent undo (#4), unified colors (#12) and
correctly indent wrapped lines (#15) and maybe quickfix-title from the
extended git repository as well as fast-join and really nice would be
the margincolumn patch that was floating around vim_dev for some time.

regards,
Christian

Nicholas Cole

unread,
Apr 12, 2010, 5:57:37 AM4/12/10
to vim...@googlegroups.com, vim_mu...@googlegroups.com, Bram Moolenaar, Christian Brabandt, vim...@vim.org, v...@vim.org, vim...@vim.org, vim-mu...@vim.org

This thread has been a good reminder to renew my sponsorship, in part
because Vim deserves the support, and in part so I can vote again for
this patch! I've never been clear why this patch should be
controversial, though.

Best wishes,

Nicholas

Chris Sutcliffe

unread,
Apr 12, 2010, 7:17:02 AM4/12/10
to vim...@googlegroups.com
> #13 (Access W32 clipboard from Cygwin "Unix" Vim) is interesting but still
> in beta. IIUC ifdeffed by whatever FEAT_* corresponds to has('win32unix').
> Bring 'em in or let it bake some more?

I would really like this one. Even though it's possible to recreate
most of the functionality (via Fakeclip or through the tips mentioned
in the Wiki), it would be really nice to have this functionality built
in.

Cheers!

Chris

--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

Tom Link

unread,
Apr 12, 2010, 7:47:22 AM4/12/10
to vim_use

> I have a patch for if_python.c that adds direct access to Vims
> internal screen.

Is there a chance this functionality will be available from vimscript
as well (and therewith be available to ruby etc. too). As long as one
of the top items (use python) isn't implemented.

Gregor Uhlenheuer

unread,
Apr 18, 2010, 6:44:47 AM4/18/10
to Bram Moolenaar, vim...@vim.org, v...@vim.org, vim...@vim.org, vim-mu...@vim.org
On 04/11/2010 04:33 PM, Bram Moolenaar wrote:
>
> I will try to include a few patches that have been pending for a while.
> I don't have much time available, thus I will only include things that
> take a few hours of my time. That basically means patches that are
> ready to be included.
>

Hi,

a few months ago I posted an updated patch for the margincolumn
feature that actually allows you to highlight a specified column (i.e.
to show the current buffer's textwidth). Since then I kept updating it
and use it without any problems.

The patch for vim-7.2.411 is attached.

Cheers,
Gregor

--
You received this message from the "vim_use" 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

Subscription settings: http://groups.google.com/group/vim_use/subscribe?hl=en
margincolumn.patch

Bram Moolenaar

unread,
Jul 17, 2010, 3:26:13 PM7/17/10
to mmarko, vim_use

Mark Mahnic wrote:

> Hi Bram!
>
> I have a patch for if_python.c that adds direct access to Vims
> internal screen.
> It creates a new python object vim.screen with the following methods:
> puts, getHighlightAttr, mousex, mousey. The patch can be used to
> create
> "gui" forms that would be available in all versions of Vim (with
> +python), especially
> if more integration between Vim and Python is planned.
>
> http://sourceforge.net/projects/vimuiex/files/vimpatch/vimpatch-0.6.6.zip/download
> The patch changes: if_python.c, eval.c, version.c, configure.in and
> config.h.in
> The feature can be enabled during ./configure with --enable-
> pythonscreen.
> I've been using it for a year now without problems/crashes.

I had a look at the patch. It doesn't include documentation, thus it's
not easy to see how to use it.

Also, I have included support for Python 3 now. Can the same be done
for that?

--
WOMAN: I didn't know we had a king. I thought we were an autonomous
collective.
DENNIS: You're fooling yourself. We're living in a dictatorship. A
self-perpetuating autocracy in which the working classes--
WOMAN: Oh there you go, bringing class into it again.
DENNIS: That's what it's all about if only people would--
The Quest for the Holy Grail (Monty Python)

Marko Mahnič

unread,
Jul 18, 2010, 2:26:03 PM7/18/10
to Bram Moolenaar, vim_use
On 17. 07. 2010 21:26, Bram Moolenaar wrote:
>
> I had a look at the patch. It doesn't include documentation, thus it's
> not easy to see how to use it.

Here is an updated patch with minimal documentation added to
if_pyth.txt and a minor update in if_python.c.

Basically the patch exposes a few window attributes and a
new vim.screen object with two methods.

The new window attributes are: window.left, window.top and
window.wcursor. The attribute window.width is now exposed
uncontitionally (previously it was available only when
FEAT_VERTSPLIT was defined). With these attributes it is
possible to get the location of the cursor inside the window
(the old window.cursor is expressed in the number of
vim-lines/columns, not screen lines/columns).

The two methods of the screen object are used to write
strings directly to the vim screen (screen.puts) and to get
the raw attribute values of vim syntax elements
(screen.getHighlightAttr) which can be subsequently used
with puts. The parameters in puts are modelled after the
function puts in ncurses (the patch was developed as a part
of vimscript 2606 which initially only used ncurses).

All the functionality could also be implemented in VimScript
so that it could be used by other plugins:

- puts: a new function that exposes
screen_puts_len()
in VimScript (length could be omitted)

- getHihghlightAttr: expose a function that calls:
int id = syn_name2id(name);
int attr = syn_id2attr(id);
return attr

- a new function: get_win_cursor({nr}), returns a list:
(long)(this->win->w_wrow), (long)(this->win->w_wcol)

- a new function: get_win_pos({nr}), returns a list:
(long)(W_WINROW(this->win)), (long)(W_WINCOL(this->win))

- winwidth() and winheight() already exist

I'm not acquainted with VimScript internals but I think it
shouldn't be too hard to do this.

>
> Also, I have included support for Python 3 now. Can the same be done
> for that?
>

Currently I'm not using Python 3 but judging from a diff
between if_python.c and if_python3.c this could be done.
Most of the patch could just be copied into if_python3.c
except the screen object structure which should be changed.

Marko

pythonscreen.72_411b.zip

Marko Mahnič

unread,
Jul 18, 2010, 2:52:10 PM7/18/10
to vim_use
On 17. 07. 2010 21:26, Bram Moolenaar wrote:
>
> I had a look at the patch. It doesn't include documentation, thus it's
> not easy to see how to use it.
>

Here is an example:

python << EOF
import vim
attr = vim.screen.getHighlightAttr("ErrorMsg")
enc = vim.eval("&encoding")
text = u" Direct Write "
win = vim.current.window
vim.screen.puts(win.top + win.height/2, win.left+4, attr,
text.encode(enc, "replace"))
EOF

example.vim

Bram Moolenaar

unread,
Jul 18, 2010, 4:51:51 PM7/18/10
to Marko Mahnič, vim_use

Marko Mahni wrote:

Thanks. I'll add a note in the todo list. I don't expect to include
this soon, thus keep working on it.

--
ARTHUR: Be quiet!
DENNIS: Well you can't expect to wield supreme executive power just 'cause
some watery tart threw a sword at you!
ARTHUR: Shut up!
DENNIS: I mean, if I went around sayin' I was an empereror just because some
moistened bint had lobbed a scimitar at me they'd put me away!

Marko Mahnič

unread,
Jul 19, 2010, 4:01:35 PM7/19/10
to Bram Moolenaar, vim_use
On 18. 07. 2010 22:51, Bram Moolenaar wrote:
>
> Thanks. I'll add a note in the todo list. I don't expect to include
> this soon, thus keep working on it.
>

This patch adds the python_screen feature to python and python3.
Examples are in the archive.

Marko

pythonscreen.73a.zip
Reply all
Reply to author
Forward
0 new messages