Planning Vim 7.3
Bram Moolenaar
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
[...]
> 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é
":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
Are you considering any patches from
http://groups.google.com/group/vim_dev/web/vim-patches
for inclusion?
regards,
Christian
Bram Moolenaar
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.
ron
> It's about time for 7.3!
Great!!
> 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.
You might like to take a look at the installer script I am using
(NSIS), here:
http://dev.ronware.org/p/vim/finfo?name=gvim.nsi
(also note I'm using "Fossil" for source control...)
I've started doing a Hebrew menu.vim (and I'll do a he.po as well).
But the
RTL stuff really doesn't work so well when the UI is LTR ...
Tony Mechelynck
>
> 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.
Tony Mechelynck
There are already two possibilities for the main display:
- Let Vim handle RTL or LTR at the window level (:set invrightleft)
or
- Run Vim in console mode in a full-bidi terminal (such as mlterm),
leave 'rightleft' off, and let the terminal handle characterwise bidi.
It is possible to use menus in console mode (with 'wildmenu', :emenu,
and, in the vimrc, :runtime! menu.vim); I suppose in that case mlterm
will apply true-bidi but console Vim in other terminals (or gvim with
:emenu) won't. Not sure how to display RTL menus at the top of the GUI
(and in which GUI flavour...).
Best regards,
Tony.
--
He hadn't a single redeeming vice.
-- Oscar Wilde
Edward L. Fox
>
> 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
(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
Lech Lorens
> #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.
Pretty stable alpha, I'd say. It's of limited use for programming but
I've been using it for configuration files and it's been totally
reliable since the last update in Nov 2009.
--
Cheers,
Lech
Jordan Lewis
--
You received this message from the "vim_dev" maillist.
Mun
On Mon, Apr 12, 2010 at 04:03 PM PDT, Jordan Lewis wrote:
JL> Any thoughts about including persistent undo in Vim 7.3? It's being
JL> maintained in Markus Heidelberg's vim_extended repository here
JL> http://repo.or.cz/w/vim_extended.git/shortlog/refs/heads/feat/persistent-undo.
JL> It's also the 3rd most popular new feature on the new feature voting list.
I'd like to see the persistent undo patch included in v7.3 . But I
would also like greater control than provided by 'undofile' (as
mentioned in an old thread).
Along these same lines, if persistent undo is included it would be
beneficial if the Undo Branches were tagged by Time *and* Date; rather
than just Time.
Regards,
--
Mun
Bram Moolenaar
Jordan Lewis wrote:
> Any thoughts about including persistent undo in Vim 7.3? It's being
> maintained in Markus Heidelberg's vim_extended repository here
> http://repo.or.cz/w/vim_extended.git/shortlog/refs/heads/feat/persistent-undo.
> It's also the 3rd most popular new feature on the new feature voting list.
I do like the functionality of this patch, but this is something that
requires a lot of testing. You don't want your text to be changed in
unexpected ways (lines go missing or duplicated where you aren't
looking).
What helps with this is someone writing a good test. One that also
tries to find the border cases. In this specific case it's not so easy,
since it involves restarting Vim to check that loading undo information
from a file works as expected. But it doesn't involve writing C code,
any advanced Vim user should be able to do this.
--
DENNIS: Look, strange women lying on their backs in ponds handing out
swords ... that's no basis for a system of government. Supreme
executive power derives from a mandate from the masses, not from some
farcical aquatic ceremony.
Ernie Rael
> Jordan Lewis wrote:
>
>
>> Any thoughts about including persistent undo in Vim 7.3?
>>
> requires a lot of testing. You don't want your text to be changed in
> unexpected ways (lines go missing or duplicated where you aren't
> looking).
>
>
>
that the file in question, with persistent undo info, has not been
modified since last open. For example with a crc?
-ernie
Christian Brabandt
On Di, 13 Apr 2010, Bram Moolenaar wrote:
> What helps with this is someone writing a good test. One that also
> tries to find the border cases. In this specific case it's not so easy,
> since it involves restarting Vim to check that loading undo information
> from a file works as expected. But it doesn't involve writing C code,
> any advanced Vim user should be able to do this.
Could you elaborate on that (maybe taking this to private mail, in case
this is disturbing here)? I am willing to help out and write test cases.
regards,
Christian
--
Wer sich zum Alleinherrscer erhebt und Brutus nicht t�tet, oder wer
einen Freistaat gr�ndet und die S�hne des Brututs nicht hinrichten
l��t, wird sich nicht lange halten.
-- Niccol� Machiavelli (Vom Start)
Jordan Lewis
Bram Moolenaar
Christian Brabandt wrote:
> On Di, 13 Apr 2010, Bram Moolenaar wrote:
> > What helps with this is someone writing a good test. One that also
> > tries to find the border cases. In this specific case it's not so easy,
> > since it involves restarting Vim to check that loading undo information
> > from a file works as expected. But it doesn't involve writing C code,
> > any advanced Vim user should be able to do this.
>
> Could you elaborate on that (maybe taking this to private mail, in case
> this is disturbing here)? I am willing to help out and write test cases.
Basically:
- look at the documentation
- look at what the code does (fix documentation when needed)
- test that what it's supposed to do actually works, possibly trying
every documented feature
- think of border cases (empty file, one very long line, missing line
break, binary file, etc.) and test that all works
- have a brainstorm about what could go wrong and test that (e.g.,
changing the file with another editor, renaming another file in its
place)
Using some kind of script to make this less work. Could perhaps be a
Vim script that writes a script file and runs another Vim with "!vim -S
scriptfile filename". That way it's portable.
--
BLACK KNIGHT: The Black Knight always triumphs. Have at you!
ARTHUR takes his last leg off. The BLACK KNIGHT's body lands upright.
BLACK KNIGHT: All right, we'll call it a draw.
Lech Lorens
>
> 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.
vim-dev about a year ago. This is against Vim 7.2.411.
--
Cheers,
Lech
--
Do not top-post! Type your reply below the text you are replying to.
Lech Lorens
>
>
> > 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 into Vim 7.3 (or any later version for that matter). If it's the bug
fixes that worry you, then I can't think of a solution. But if you
simply don't like the idea of providing the users with Vim that might be
unstable, then maybe you would accept one of the solutions:
- let Vim stay in 7.3-alpha stage for a longer while,
- release Vim 7.3 but then create a testing branch of Vim. The main
branch and the testing branch would get normal bug fixes, but the
testing branch would also be the place for developing new features.
Either way, I believe there are people who would be willing to accept
Vim of alpha quality for the price of getting interesting features in
(I for one would, perhaps the vim-dev subscribers as well).
By the way, if there is any task during preparing Vim 7.3 that you think
you could "outsource" ;-) I can commit myself to spending a day a week
on Vim for the next month or two.
Bram Moolenaar
Lech Lorens wrote:
> On 11-Apr-2010 Bram Moolenaar <Br...@Moolenaar.net> wrote:
> >
> > 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.
>
> I attached a patch enabling the quickfix window titles which I sent to
> vim-dev about a year ago. This is against Vim 7.2.411.
6 In the quickfix window statusline add the command used to get the list of
errors, e.g. ":make foo", ":grep something *.c".
Patch by Lech Lorens, 2009 Mar 23.
Comments from Andreas Bernauer 24th, Dominique Pelle 24th
Docs patch by Dominique Pelle, Mar 25
Update 2009 Mar 28.
Fix for invalid memory access. (Lech Lorens, 2009 Apr 17)
Did others try it out the version of 2009 Apr 17?
--
Team-building exercises come in many forms but they all trace their roots back
to the prison system. In your typical team-building exercise the employees
are subjected to a variety of unpleasant situations until they become either a
cohesive team or a ring of car jackers.
(Scott Adams - The Dilbert principle)
/// 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 ///
Gregor Uhlenheuer
>
> 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.
>
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
--
Do not top-post! Type your reply below the text you are replying to.
Lech Lorens
> 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
which called it 'guidecolumn'. I can remember an argument that
'guidecolumn' is not a good name because it would be confusing to get
the option when trying to complete ":help gui". But in the same manner
isn't it confusing that ":help win" completes both the functions for
window interaction and features related to the Windows OS?
I prefer 'guidecolumn' to 'margincolumn' and feel that the former name
better reflects what the option is about since other editors allegedly
call it guide lines. Try searching the web for images of "Visual Studio
margin line" (no hits in the first 40 results) vs "Visual Studio guide
line" (I got 6 hits among the first 8 images; don't feel like checking
the first 40 results).
--
Cheers,
Lech
Lech Lorens
> On 18-Apr-2010 Gregor Uhlenheuer <kong...@googlemail.com> wrote:
> >
> > 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
>
> I like the feature very much. However, I used the version of the patch
> which called it 'guidecolumn'. I can remember an argument that
> 'guidecolumn' is not a good name because it would be confusing to get
> the option when trying to complete ":help gui". But in the same manner
> isn't it confusing that ":help win" completes both the functions for
> window interaction and features related to the Windows OS?
>
> I prefer 'guidecolumn' to 'margincolumn' and feel that the former name
> better reflects what the option is about since other editors allegedly
> call it guide lines. Try searching the web for images of "Visual Studio
> margin line" (no hits in the first 40 results) vs "Visual Studio guide
> line" (I got 6 hits among the first 8 images; don't feel like checking
> the first 40 results).
fixed in the patch sent in message 20091031234444.GA5716@neo (
http://groups.google.com/group/vim_dev/browse_frm/thread/e4ae0ece884bf356/b669f55218f127fb?q=#b669f55218f127fb
).
I attached an updated patch for 'margincolumn' with a tiny fix.
Luis Carvalho
> > August 2008. There have been many patches, but not everybody will use
> > them. It's about time for 7.3!
> > 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.
> http://groups.google.com/group/vim_dev/web/vim-patches
> for inclusion?
against Vim 7.2.411 can be found at:
http://vim-iflua.googlecode.com/files/vim72-lua-0.7.patch.gz
Thanks,
Luis
--
Computers are useless. They can only give you answers.
-- Pablo Picasso
--
Luis Carvalho (Kozure)
lua -e 'print((("lexca...@NO.gmail.SPAM.com"):gsub("(%u+%.)","")))'
--
Do not top-post! Type your reply below the text you are replying to.
Bram Moolenaar
Roland Puntaier wrote:
> since I had to set up windows I updated the patch for the python3 support
> to vim trunk 7.2.411.
> It is attached.
it works without problems. Or that nobody uses it...
Who tested the Python 3 support? Does it still build with Python 2.x?
Do old scripts still work?
--
It's totally unfair to suggest - as many have - that engineers are socially
inept. Engineers simply have different objectives when it comes to social
interaction.
/// 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 ///
Edward L. Fox
>
> Roland Puntaier wrote:
>
>> since I had to set up windows I updated the patch for the python3 support
>> to vim trunk 7.2.411.
>> It is attached.
>
> Thanks. I didn't hear about anybody using the patch. That might mean
> it works without problems. Or that nobody uses it...
> Who tested the Python 3 support? Does it still build with Python 2.x?
> Do old scripts still work?
scripts will not work under Python 3.x.
Roland Puntaier
> "Edward L. Fox" <edy...@gmail.com>
> Gesendet von: vim...@googlegroups.com
>
> On Thu, Apr 29, 2010 at 20:27, Bram Moolenaar <Br...@moolenaar.net> wrote:
> >
> > Thanks. I didn't hear about anybody using the patch. That might mean
> > it works without problems. Or that nobody uses it...
> > Who tested the Python 3 support? Does it still build with Python 2.x?
> > Do old scripts still work?
>
> No, Python 3.x is considered as another language. So most Python 2.x
> scripts will not work under Python 3.x.
:py3
for Python 3.x
and legacy
:py[thon]
for Python 2.x.
Python 3.x is treated as another language.
Both Python 2.x and Python 3.x can be supported at the same time, if vim is configured accordingly.
Cheers, Roland
Christian Brabandt
Hi Bram!
> Basically:
> - look at the documentation
> - look at what the code does (fix documentation when needed)
> - test that what it's supposed to do actually works, possibly trying
> every documented feature
> - think of border cases (empty file, one very long line, missing line
> break, binary file, etc.) and test that all works
> - have a brainstorm about what could go wrong and test that (e.g.,
> changing the file with another editor, renaming another file in its
> place)
>
> Using some kind of script to make this less work. Could perhaps be a
> Vim script that writes a script file and runs another Vim with "!vim -S
> scriptfile filename". That way it's portable.
feature. This is really awesome and I have been missing it so much. I
already started testing it. There are some issues I already noticed:
1) This does not work very well with files that are symlinked. If
you start by editing a symlink file, the undo will be saved and
remembered only for the symlink. If you are later start editing
the symlink target, there won't be any undo-state remembered and
further you are loosing your old remembered undo points (because
even if you later again start editing the symlink file, you
won't be able to undo changes.
2) What happens with old undo files? They seem to accumulate and
it seems that sooner or later you'll have in ~/.vim/undo/ a bunch
of unusable undo files. Could they be deleted automatically,
when they become unusable or is there a way to force reading the
undo-file?
3) :rundo should at least output some message, if it can't restore
the undo points from a previous session, since the file has been
modified by some other program.
I'll keep on testing it.
regards,
Christian
Jordan Lewis
Thanks for letting me know. Today it's the first time I tested this
feature. This is really awesome and I have been missing it so much. I
already started testing it. There are some issues I already noticed:
1) This does not work very well with files that are symlinked. If
you start by editing a symlink file, the undo will be saved and
remembered only for the symlink. If you are later start editing
the symlink target, there won't be any undo-state remembered and
further you are loosing your old remembered undo points (because
even if you later again start editing the symlink file, you
won't be able to undo changes.
2) What happens with old undo files? They seem to accumulate and
it seems that sooner or later you'll have in ~/.vim/undo/ a bunch
of unusable undo files. Could they be deleted automatically,
when they become unusable or is there a way to force reading the
undo-file?
3) :rundo should at least output some message, if it can't restore
the undo points from a previous session, since the file has been
modified by some other program.
I'll keep on testing it.
Markus Heidelberg
I have reviewed the patch for relative line numbers and while going
through the changes again, from the point of regressions I think it is
hard to introduce any in this patch, because most of the changes for the
'relativenumber' option are pretty parallel to the 'number' option.
Bram Moolenaar, 2010-04-11 16:33:
> 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.
several people (I don't have numbers). I can't remember problem reports
except for a compilation problem in the tiny build.
> I will check the voting list to see what the most popular features are:
> http://www.vim.org/sponsor/vote_results.php
Not the most popular feature, but at least it has already 45 points from
3 voters and it's only in this list since 3 weeks.
Markus
Nazri Ramliy
> This should be a relatively easy fix, if the desired behavior is to have all
> of the symlinks associate to the same undo file as the target. Same story
> for hard links.
a totally different animal than soft link:
With hard link you have 1 or more filenames that associates with the same inode.
With soft link you have 1 or more filenames that associates with the
same filename.
With hard link it's harder (impossible?) to determine what the 'target'
is based on their file names because of ambiguity: one hardlink is no
different than another - they are all first class 'file names'.
Using the SHA1 of the content of the target file as the unique id into
its associated undo file might solve the problem.
If this is the solution that you had in mind when you said that it is
a relatively easy
fix then please ignore my ramblings above :)
nazri
Jordan Lewis
With hard link it's harder (impossible?) to determine what the 'target'
is based on their file names because of ambiguity: one hardlink is no
different than another - they are all first class 'file names'.
Using the SHA1 of the content of the target file as the unique id into
its associated undo file might solve the problem.
Andy Kittner
Hi,
On Thu, Apr 29, 2010 at 03:22:51PM +0200, Roland Puntaier wrote:
> [..]
>
>The patch has
> :py3
>for Python 3.x
>and legacy
> :py[thon]
>for Python 2.x.
>
>Python 3.x is treated as another language.
>Both Python 2.x and Python 3.x can be supported at the same time, if vim
>is configured accordingly.
I gave this patch a quick testing and the only issue I found so far is a
build error if both python2 & 3 are enabled and python3 is compiled with
wide-unicode (UCS4) support.
I have attached a patch (on top of Roland's patch) for this situation.
Regards,
Andy
--
To be intoxicated is to feel sophisticated but not be able to say it.
Milan Vancura
> 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 resend my fixes of test29 and also a patch replacing O(n2) algorithm of line
join by O(n) one. There are no significant changes in those patches since I
published them on this list in past, they are just updated to current vim73
sources from mercurial.
A fix of test29 is straigthforward, it is clear that (and how) it was wrong.
A line join algorithm replacement may be considered as a feature but it was
tested for a long time by all users of git branch vim-extended with no negative
report for all that time.
May you include them in vim 7.3, please?
Milan Vancura
Bram Moolenaar
Milan Vancura 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 Bram,
>
> I resend my fixes of test29 and also a patch replacing O(n2) algorithm
> of line join by O(n) one. There are no significant changes in those
> patches since I published them on this list in past, they are just
> updated to current vim73 sources from mercurial.
>
> A fix of test29 is straigthforward, it is clear that (and how) it was
> wrong.
>
> A line join algorithm replacement may be considered as a feature but
> it was tested for a long time by all users of git branch vim-extended
> with no negative report for all that time.
>
> May you include them in vim 7.3, please?
I have a long list of patches that could be included, I'll have to stop
some time, otherwise 7.3 never gets done.
--
hundred-and-one symptoms of being an internet addict:
59. Your wife says communication is important in a marriage...so you buy
another computer and install a second phone line so the two of you can
chat.
/// 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 ///
epanda
In the first post you say that you want to improve installer for
Windows deploy.
I think gvim' toolbar is an old fashion one. I have done another look
with new icons.
Can I submit to you before you release the 7.3 please ?
Thank you
Bram Moolenaar
callingelvis wrote:
If you would like to change the looks, please send a patch and/or
screenshot to the vim-dev list. I'm sure others will want to make
remarks.
--
hundred-and-one symptoms of being an internet addict:
110. You actually volunteer to become your employer's webmaster.
Gregor Uhlenheuer
> 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.
>
Hi again,
since I am hoping that the 'margincolumn' feature will find its way
into the oncoming vim 7.3 release I tried to extend the feature by
allowing to define multiple columns to be highlighted.
As far as I could test the changes it works pretty well. A few notes
regarding the implementation: The 'margincolumn' setting is now a
string type setting used like this:
" highlight columns 20, 40 and textwidth+1
:set mc=-1,20,40
Internally the columns are stored inside a sorted fixed-size integer
array to reduce redrawing time. As far I can tell this way merely
increases redrawing time. Perhaps there is an even better solution out
there (sadly this win_line() function is a really ugly beast ;)) but
this is the best working solution I could come up with.
Perhaps you guys want to give it a try
The patch against the latest vim73 mercurial changeset is attached.
Cheers,
Gregor
Gary Johnson
> On 04/18/2010 12:44 PM, Gregor Uhlenheuer wrote:
> > 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.
> >
>
> Hi again,
>
> since I am hoping that the 'margincolumn' feature will find its way
> into the oncoming vim 7.3 release I tried to extend the feature by
> allowing to define multiple columns to be highlighted.
>
> As far as I could test the changes it works pretty well. A few notes
> regarding the implementation: The 'margincolumn' setting is now a
> string type setting used like this:
>
> " highlight columns 20, 40 and textwidth+1
> :set mc=-1,20,40
I like the feature and hope it becomes part of 7.3, but being able
to highlight more than one column gives even more reason to call it
'guidecolumn' rather than 'margincolumn'.
I could see wanting a highlighted column at some distance to the
left of 'textwidth'. Could the notation be changed so that -n means
"&tw-n", +n means "&tw+n" and 0 (maybe -0 or +0) means "&tw"?
Regards,
Gary
Gregor Uhlenheuer
>
> I could see wanting a highlighted column at some distance to the
> left of 'textwidth'. Could the notation be changed so that -n means
> "&tw-n", +n means "&tw+n" and 0 (maybe -0 or +0) means "&tw"?
If this is desired this could be implemented pretty easily I guess.
But this behavior can be accomplished with vimscript as well -
something like:
function! GuideCol(cols)
let columns = []
for col in split(a:cols, ',')
if col =~ '[-+]\d\+'
call insert(columns, str2nr(col) + &tw)
else
call insert(columns, col)
endif
endfor
exe 'set mc=' . join(columns, ',')
endfunction
com! -nargs=1 GuideColumn :call GuideCol(<f-args>)
Cheers,
Gregor
Marko Mahnič
> The documentation is too short. Looking at it I have many questions:
> - Does this change the text in the buffer? I suppose not, then what
> happens when the text is redisplayed?
Since the data is written directly to the screen, the displayed
data is lost after a redraw. No other Vim internal data is changed.
> - Why only these specific functions?
This is the minimal interface that is needed so that Vim can
display popup windows. It is exported to Python because the
rest was much easier to implement there instead of using C.
The interface is used by script#2606 to display popup windows
with various lists (buffers, directory browser, recent files,
etc). I find it more convenient to display lists in popup
windows instead of (v)splitting every time I want to open a
file or select a buffer. And since Vim doesn't provide
a suitable facility I created my own.
> - And why allow things that can't
> even be done with Vim functions?
Vim functions can't draw directly to the screen, that's true.
But Vim can use ncurses through Python to achieve the same
effect as provided by the exported functions.
The patch is only necessary for GVim and for scripts
that need to know the exact position of the cursor and the
windows on the screen. In a terminal, script #2606 uses
ncurses when python_screen is not present.
> - The examples should be in the help.
>
> I don't see much use for it and it might break something, I'm not
> including this in 7.3.
>
No problem. It will still be included with script#2606 for those
who want to use it.
Thanks,
Marko
Bram Moolenaar
Roland -
The Python 3 support has been included in Vim 7.3b. Please take a look
and verify recent changes didn't cause trouble.
We did encounter one serious problem: On Unix, when using this sequence
of commands, Vim crashes:
:python print "hello"
:py3 print("hello")
:python print "hello"
I tried solving it by unloading one python library when loading the
other, but that didn't really work. Thus for now I reject using both
Python versions in one Vim session.
It would be nice if you can help finding a solution.
--
Dogs must have a permit signed by the mayor in order to congregate in groups
of three or more on private property.
[real standing law in Oklahoma, United States of America]
Roland Puntaier
That's good news to me.
I'll check the sources and look into the crash as soon as possible.
Roland
Br...@Moolenaar.net schrieb am 25.07.2010 14:24:18:
> Von: Bram Moolenaar <Br...@Moolenaar.net>