Re: Vim 8 pre-announcement
Hello Bram,
On 8/16/2016 6:43 PM, Bram Moolenaar wrote:
> Hello Vim users,
>
> Work on Vim 8.0 is coming close to an end. I hope version 8.0 can be
> released in about two weeks.
>
> This is a last chance to modify new features in a way that is not
> backwards compatible. Once 8.0 is out we can't make changes that would
> break plugins.
>
> An overview of new features can be found in:
> https://github.com/vim/vim/blob/master/runtime/doc/version8.txt
> A version with links (but a day older):
> http://vimhelp.appspot.com/version8.txt.html
>
> Please review the new features, try them out and report what should be
> changed on the vim-dev maillist. Of course you should also report bugs
> you find.
>
> Happy Vimming!
>
>
> PS. If you are interested in meeting Vim users: Vimfest is happening in
> Berlin Sept. 16-18. http://vimfest.org
I was wondering whether you could also include into Vim 8 the following patch
(the original reason for pull request https://github.com/vim/vim/pull/543,
which you can reject, since the langmap part doesn't seem to have a chance in,
anyway)
The behavior this patch tries to achieve is given by the test case in the patch.
diff --git src/getchar.c src/getchar.c
index 1c170cc..ce68a2f 100644
--- src/getchar.c
+++ src/getchar.c
@@ -2144,12 +2144,15 @@ vgetorpeek(int advance)
/*
* Only consider an entry if the first character
* matches and it is for the current state.
- * Skip ":lmap" mappings if keys were mapped.
*/
if (mp->m_keys[0] == c1
&& (mp->m_mode & local_State)
-&& ((mp->m_mode & LANGMAP) == 0
-|| typebuf.tb_maplen == 0))
+ /* && ((mp->m_mode & LANGMAP) == 0 ||
typebuf.tb_maplen == 0)
+ * Used to skip ":lmap" mappings for keymap'ed
keys here,
+ * but the result of the keymap is not placed in
the register,
+ * so the register content needs to be remapped
here.
+ */
+ )
{
#ifdef FEAT_LANGMAP
intnomap = nolmaplen;
diff --git src/testdir/test_digraph.vim src/testdir/test_digraph.vim
index 9550085..3578ced 100644
--- src/testdir/test_digraph.vim
+++ src/testdir/test_digraph.vim
@@ -450,6 +450,20 @@ func! Test_loadkeymap()
bw!
endfunc
+func! Test_registerkeymap()
+ if !has('keymap')
+return
+ endif
+ new
+ set keymap=russian-jcukenwin
+ set iminsert=1
+ call feedkeys("qqods\qdd@q", 'tx')
+ call assert_equal("вы", getline('.'))
+ " reset keymap and encoding option
+ set keymap=
+ bw!
+endfunc
+
func! Test_digraph_cmndline()
" Create digraph on commandline
" This is a hack, to let Vim create the digraph in commandline mode
--
--
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 to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [vim] allow KEYMAP with @a and langmap issues (#543)
Hello Bram, Now I've changed the langmap implementation in this pull request, too (https://github.com/vim/vim/pull/543). Building and running make in testdir worked locally (on archlinux, apart from test87, but only because archlinux has python 3 as default (TypeError->ValueError)). I don't know wether the fact, that not all Travis CI builds succeeded, is related to my changes. Please review and merge. Thanks. Roland. On 1/5/2016 3:46 PM, Roland Puntaier wrote: On 1/3/2016 3:35 PM, Bram Moolenaar wrote: Roland Puntaier wrote: On 12/31/2015 6:22 PM, Bram Moolenaar (Vim Github Repository) wrote: No, the langmap and keymap options relate to the keyboard. Replaying a register does not involve the keyboard. When replaying a register one doesn't know where the characters came from, they might be typed or the result of something else, e.g. a yank operation. I wonder how you managed to get characters into a register that you want to apply 'keymap' or 'langmap' to. This translation should have already happened when typing the characters. - do ":help russian" - use the keymap as described there - insert some russian text - record a macro @a that inserts some russian text - play the macor @a This is a bit vague... Perhaps the problem is that when recording into a register the keymap/langmap is not applied, resulting in the wrong characters in the register? I look at keymap/langmap as a low level operation, which is applied when typing on the keyboard, before it goes to the rest of Vim, which is unaware of this filtering. It's possible that this interferes with other things, such as terminal codes and other mappings. It's quite complicated. Many changes in this area are not backwards compatible and break someone's carefully tuned setup. I have thought of re-implementing this, but haven't found the time to dive into it. Dear Bram, Of course a cleaner implementation would be desirable and that could store to a register after applying keymap. But as of now the typed chars are stored into the register before applying keymap, i.e. //getchar.c:2515 if (keylen > typebuf.tb_maplen) gotchars(typebuf.tb_buf + typebuf.tb_off + typebuf.tb_maplen, keylen - typebuf.tb_maplen); is before //getchar.c:2610 i = ins_typebuf(s, noremap, So my patch fits to the current implementation by applying the keymap to chars in the register. I also added tests for keymap. There haven't been any so far. Regarding applying langmap to ':'-CMDLINE I've found that only patch v7.4.773 had removed the langmap mapping from CMDLINE. For / and ? commands that is good. langmap shouldn't apply, because you want to find text. So it should be like for the insert mode, i.e keyboard layout should be used. But for :-commands, if langmap is intended to enable russians or greeks to use vim without the need to switch to an english keyboard layout, langmap should apply. Otherwise you cannot enter :q, :w, :e,... commands. To enter non-english letters in :-commands, e.g. for :s, one can first search via / or yank and then do ^R/ or ^R". So this pull request is a modification and not an undo of patch 773. langmap now also is a better opposite to keymap. keymap does not apply to :-commands, so langmap should. I adapted the tests for langmap to fit the changes. I have also updated the documentation to mention: - langmap applies to ':'-CMDLINE mode (new) - keymap applies to non-':'-CMDLINE mode (current) From my side pull request https://github.com/vim/vim/pull/543 is ready now. Sorry, but this is not the right solution. Did you see the change that Christian Brabandt made, sent to the vim-dev list on July 25 last year? This also indicates what is wrong: need to apply langmap before checking for matching mappings. So, what needs to be done is in vgetorpeek() to apply langmap to the head of the typeahead buffer and put the result in a copy-buffer. Then use this copy-buffer to check for mappings and otherwise get the character from. Then gotchars() will record the characters after applying langmap and replaying the register will work. The calls to LANGMAP_ADJUST() in other places of the code have to be removed. This also fixes the problem with multi-byte characters that Christian solved. This is not easy, but we need to do this properly, otherwise we'll get a sequence of slightly incompatible changes that is annoying for users. I've now looked into the vim-dev entry by Christian Brabandt you've mentioned. https://groups.google.com/forum/#!topic/vim_dev/cqYj7seoEWg It references https://github.com/vim/vim/issues/297 https://groups.google.com/forum/#!msg/vim_dev/5D1WSL2gj-A/OgCBNZQEHNEJ I also browsed through langmap search results. From this I have added some te
Re: [vim] allow KEYMAP with @a and langmap issues (#543)
On 1/3/2016 3:35 PM, Bram Moolenaar wrote: Roland Puntaier wrote: On 12/31/2015 6:22 PM, Bram Moolenaar (Vim Github Repository) wrote: No, the langmap and keymap options relate to the keyboard. Replaying a register does not involve the keyboard. When replaying a register one doesn't know where the characters came from, they might be typed or the result of something else, e.g. a yank operation. I wonder how you managed to get characters into a register that you want to apply 'keymap' or 'langmap' to. This translation should have already happened when typing the characters. - do ":help russian" - use the keymap as described there - insert some russian text - record a macro @a that inserts some russian text - play the macor @a This is a bit vague... Perhaps the problem is that when recording into a register the keymap/langmap is not applied, resulting in the wrong characters in the register? I look at keymap/langmap as a low level operation, which is applied when typing on the keyboard, before it goes to the rest of Vim, which is unaware of this filtering. It's possible that this interferes with other things, such as terminal codes and other mappings. It's quite complicated. Many changes in this area are not backwards compatible and break someone's carefully tuned setup. I have thought of re-implementing this, but haven't found the time to dive into it. Dear Bram, Of course a cleaner implementation would be desirable and that could store to a register after applying keymap. But as of now the typed chars are stored into the register before applying keymap, i.e. //getchar.c:2515 if (keylen > typebuf.tb_maplen) gotchars(typebuf.tb_buf + typebuf.tb_off + typebuf.tb_maplen, keylen - typebuf.tb_maplen); is before //getchar.c:2610 i = ins_typebuf(s, noremap, So my patch fits to the current implementation by applying the keymap to chars in the register. I also added tests for keymap. There haven't been any so far. Regarding applying langmap to ':'-CMDLINE I've found that only patch v7.4.773 had removed the langmap mapping from CMDLINE. For / and ? commands that is good. langmap shouldn't apply, because you want to find text. So it should be like for the insert mode, i.e keyboard layout should be used. But for :-commands, if langmap is intended to enable russians or greeks to use vim without the need to switch to an english keyboard layout, langmap should apply. Otherwise you cannot enter :q, :w, :e,... commands. To enter non-english letters in :-commands, e.g. for :s, one can first search via / or yank and then do ^R/ or ^R". So this pull request is a modification and not an undo of patch 773. langmap now also is a better opposite to keymap. keymap does not apply to :-commands, so langmap should. I adapted the tests for langmap to fit the changes. I have also updated the documentation to mention: - langmap applies to ':'-CMDLINE mode (new) - keymap applies to non-':'-CMDLINE mode (current) From my side pull request https://github.com/vim/vim/pull/543 is ready now. Sorry, but this is not the right solution. Did you see the change that Christian Brabandt made, sent to the vim-dev list on July 25 last year? This also indicates what is wrong: need to apply langmap before checking for matching mappings. So, what needs to be done is in vgetorpeek() to apply langmap to the head of the typeahead buffer and put the result in a copy-buffer. Then use this copy-buffer to check for mappings and otherwise get the character from. Then gotchars() will record the characters after applying langmap and replaying the register will work. The calls to LANGMAP_ADJUST() in other places of the code have to be removed. This also fixes the problem with multi-byte characters that Christian solved. This is not easy, but we need to do this properly, otherwise we'll get a sequence of slightly incompatible changes that is annoying for users. I've now looked into the vim-dev entry by Christian Brabandt you've mentioned. https://groups.google.com/forum/#!topic/vim_dev/cqYj7seoEWg It references https://github.com/vim/vim/issues/297 https://groups.google.com/forum/#!msg/vim_dev/5D1WSL2gj-A/OgCBNZQEHNEJ I also browsed through langmap search results. From this I have added some test to test_mapping.in. Changes are between CHANGED_START and CHANGED_END Test for mappings and abbreviations STARTTEST :so small.vim :so mbyte.vim :set encoding=utf-8 : " abbreviations with р (0x80) should work :inoreab чкпр vim GAчкпр :" mapping of ctrl-c in Insert mode :set cpo-=< cpo-=k :inoremap :cnoremap dummy :cunmap GA TEST2: CTRL-C | A| :unmap :unmap! :" :"
Re: [vim] allow KEYMAP with @a (#543)
On 12/31/2015 6:22 PM, Bram Moolenaar (Vim Github Repository) wrote: No, the langmap and keymap options relate to the keyboard. Replaying a register does not involve the keyboard. When replaying a register one doesn't know where the characters came from, they might be typed or the result of something else, e.g. a yank operation. > > I wonder how you managed to get characters into a register that you want to > > apply 'keymap' or 'langmap' to. This translation should have already happened > > when typing the characters. > > - do ":help russian" > - use the keymap as described there > - insert some russian text > - record a macro @a that inserts some russian text > - play the macor @a This is a bit vague... Perhaps the problem is that when recording into a register the keymap/langmap is not applied, resulting in the wrong characters in the register? I look at keymap/langmap as a low level operation, which is applied when typing on the keyboard, before it goes to the rest of Vim, which is unaware of this filtering. It's possible that this interferes with other things, such as terminal codes and other mappings. It's quite complicated. Many changes in this area are not backwards compatible and break someone's carefully tuned setup. I have thought of re-implementing this, but haven't found the time to dive into it. Dear Bram, Of course a cleaner implementation would be desirable and that could store to a register after applying keymap. But as of now the typed chars are stored into the register before applying keymap, i.e. //getchar.c:2515 if (keylen > typebuf.tb_maplen) gotchars(typebuf.tb_buf + typebuf.tb_off + typebuf.tb_maplen, keylen - typebuf.tb_maplen); is before //getchar.c:2610 i = ins_typebuf(s, noremap, So my patch fits to the current implementation by applying the keymap to chars in the register. I also added tests for keymap. There haven't been any so far. Regarding applying langmap to ':'-CMDLINE I've found that only patch v7.4.773 had removed the langmap mapping from CMDLINE. For / and ? commands that is good. langmap shouldn't apply, because you want to find text. So it should be like for the insert mode, i.e keyboard layout should be used. But for :-commands, if langmap is intended to enable russians or greeks to use vim without the need to switch to an english keyboard layout, langmap should apply. Otherwise you cannot enter :q, :w, :e,... commands. To enter non-english letters in :-commands, e.g. for :s, one can first search via / or yank and then do ^R/ or ^R". So this pull request is a modification and not an undo of patch 773. langmap now also is a better opposite to keymap. keymap does not apply to :-commands, so langmap should. I adapted the tests for langmap to fit the changes. I have also updated the documentation to mention: - langmap applies to ':'-CMDLINE mode (new) - keymap applies to non-':'-CMDLINE mode (current) From my side pull request https://github.com/vim/vim/pull/543 is ready now. Best Regards, Roland -- -- 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 to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim] allow KEYMAP with @a (#543)
On 12/31/2015 1:49 AM, Tony Mechelynck wrote: I see. Sounds like we need to: (a) make langmaps apply to command-line mode by default, so Russian, Greek, etc. users can type ex-commands by using them; I agree. keymap applies to non-':'-cmdline. Since langmap is the inverse of keymap, langmap should apply to ':'-cmdline (b) implement some way of toggling them on/off "on the fly" That should be possible already by an according mapping made by the user. -- -- 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 to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim] allow KEYMAP with @a (#543)
On 12/30/2015 9:59 PM, Tony Mechelynck wrote:
The help for i_CTRL-R says "The text is inserted as if you typed it,
but mappings and abbreviations are not used."; language-mappings
(keymaps) are not used either, so that e.g. in an HTML file in
Russian, when I hit ^Ri what gets inserted is (the contents of the
register) and not <и> which wouldn't be a proper HTML tag, even if at
that point my "cyrillic-phonetic" keymap is enabled ('iminsert' = 1).
Does 'iminsert' apply to this option too? I couldn't find the answer
in the help for any of 'langmap', 'iminsert' and i_CTRL-^ (maybe
translate even text typed in Insert mode when 'iminsert' is 0 [to
insert Latin text] but not when it is 1 [to insert Cyrillic text])?
:set keymap=russian-jcukenwin
Will set iminsert=1. So this means keymap set.
^Ri is completely independent of keymap and it remains so with my patch.
I'm not very familiar with the 'langmap' option but I would expect
registers containing Cyrillic text to be pasted in Cyrillic and
registers containing Latin text to be pasted in Latin in that case too.
If you had e.g. a russian keyboard layout, you wouldn't be able to use
vim, e.g. to move around in normal mode, like with the english
keyboard's hjkl. langmap will translate ролд to hjkl.
While langmap applies for normal mode, keymap works in INSERT and
CMDLINE mode.
Langmap will not apply for CMDLINE, so you will not be able to enter vim
commands like :g, because the g is п on the russian keyboard. So langmap
is probably not very useful.
Keymap on the other hand will keep the english keyboard in normal mode
and for : commands. So you can still enter :g. It applies for /, so you
can search for russian text. (Behavior not changed with my patch.)
--
--
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 to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: keymap not applied when playing back macro
I've created a pull request regarding this: https://github.com/vim/vim/pull/543 On 12/5/2015 6:18 PM, Roland Puntaier wrote: Hello, Steps to reproduce: :set keymap=russian-jcukenwin "record macro qqighbdtn ^[ "replay macro. "result is ghbdtn and not привет Is this known bug? Is there an easy way to correct this? Regard, Roland -- -- 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 to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
keymap not applied when playing back macro
Hello, Steps to reproduce: :set keymap=russian-jcukenwin "record macro qqighbdtn ^[ "replay macro. "result is ghbdtn and not привет Is this known bug? Is there an easy way to correct this? Regard, Roland -- -- 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 to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: increase font size and you don't see the command line any more (bug?)
On 11/20/2012 12:03 PM, Bram Moolenaar wrote: Roland Puntaier wrote: One probably doesn't change the font size very often, but I recently did and could not see the command line any more. Looking into the code I've seen that vim increases the window size instead of adapting the line number, but interestingly not so for windows. I happen to use Xmonad, where window size does not change, so I first regarded this as a bug. Still the behavior seems not sensible to me. When I change the font size I don't think of changing the window size. Or: The windows size seems more important to me than the line number. If you agree, please apply the following patch: diff -r 57e8b75298d6 src/gui.c --- a/src/gui.cTue Oct 23 05:35:34 2012 +0200 +++ b/src/gui.cSun Nov 18 11:34:58 2012 +0100 @@ -905,13 +905,7 @@ # endif gui_mch_set_font(gui.norm_font); #endif -gui_set_shellsize(FALSE, -#ifdef MSWIN -TRUE -#else -FALSE -#endif -, RESIZE_BOTH); +gui_set_shellsize(FALSE, TRUE, RESIZE_BOTH); } return ret; I can't remember why it's different for MS-Windows. Perhaps because it didn't work reliably on Unix? I could just include this patch and wait until someone complains... Yes, please do. Thanks. -- 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
AttributeError module object has no attribute stderror
Hello,
the above error is issued when closing gvim with python3 configured (for
vim it's displayed too short to be seen). With this patch it's gone:
diff -r 57e8b75298d6 src/if_python3.c
--- a/src/if_python3.cTue Oct 23 05:35:34 2012 +0200
+++ b/src/if_python3.cSun Nov 18 10:11:49 2012 +0100
@@ -657,7 +657,6 @@
static PyObject *globals;
static int PythonIO_Init(void);
-static void PythonIO_Fini(void);
PyMODINIT_FUNC Py3Init_vim(void);
/**
@@ -685,7 +684,6 @@
// acquire lock before finalizing
pygilstate = PyGILState_Ensure();
-PythonIO_Fini();
Py_Finalize();
}
@@ -989,13 +987,6 @@
return PythonIO_Init_io();
}
-static void
-PythonIO_Fini(void)
-{
-PySys_SetObject("stdout", NULL);
-PySys_SetObject("stderr", NULL);
-}
-
/**
* 3. Implementation of the Vim module for Python
*/
Regards,
Roland
--
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
increase font size and you don't see the command line any more (bug?)
Hi! One probably doesn't change the font size very often, but I recently did and could not see the command line any more. Looking into the code I've seen that vim increases the window size instead of adapting the line number, but interestingly not so for windows. I happen to use Xmonad, where window size does not change, so I first regarded this as a bug. Still the behavior seems not sensible to me. When I change the font size I don't think of changing the window size. Or: The windows size seems more important to me than the line number. If you agree, please apply the following patch: diff -r 57e8b75298d6 src/gui.c --- a/src/gui.cTue Oct 23 05:35:34 2012 +0200 +++ b/src/gui.cSun Nov 18 11:34:58 2012 +0100 @@ -905,13 +905,7 @@ # endif gui_mch_set_font(gui.norm_font); #endif -gui_set_shellsize(FALSE, -#ifdef MSWIN -TRUE -#else -FALSE -#endif -, RESIZE_BOTH); +gui_set_shellsize(FALSE, TRUE, RESIZE_BOTH); } return ret; Regards, Roland -- 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
Re: Patch for py[3] command to avoid print calls
On 8/18/2012 3:05 AM, Maxim Philippov wrote:
суббота, 18 августа 2012 г., 0:51:46 UTC+4 пользователь Vlad Irnov написал:
There are plugins that implement REPL-like behavior:
http://www.vim.org/scripts/script.php?script_id=3484
http://www.vim.org/scripts/script.php?script_id=3327
http://www.vim.org/scripts/script.php?script_id=3231
and probably other.
It makes no sense for :python commands to behave differently from
other commands. That is, we currently need to type
:echo 2+2
to see the result, why :python should be different?
Though this scripts are useful, I think typing ":py 2+2" is more fluent (and maybe more
lightweight) than ":PyInteractiveEval 2+2" or running full REPL session.
We need to type ":echo 2+2" because of the vim's script syntax, ":4" by itself
is a command, there is no need for this in python.
Often I forget to call "print" because as a python user I expect expression
result to be printed automatically. It is difficult to switch from python REPL to vim's
current implementation, so why not have the best from both worlds? =)
A macro like
py3<','exec'),globals())
except:
eval(compile(' '.join(args),'','exec'),globals())
print(py_res)
EOL
command! -narg=* Py py3 python_with_print()
in $MYVIMRC
would allow you to write
:Py from math import *
:Py sin(30*pi/180)
an you would get results or None on the command line.
Regards,
Roland
--
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
Re: [patch] Python 3: Add support for assigning to slices on RangeObject
Hello Bram,
will you include this patch?
Regards, Roland
Original Message
Subject: Re: [patch] Python 3: Add support for assigning to slices on
RangeObject
Date: Wed, 07 Sep 2011 01:08:22 +0200
From: Roland Puntaier
Reply-To: vim_dev@googlegroups.com
To: vim_dev@googlegroups.com
CC: Brett Overesch
On 09/03/2011 07:26 AM, Brett Overesch wrote:
Hello,
I've been working with Python 3 scripts a lot lately and noticed that
the range objects in the vim modules (e.g. vim.current.range) do not
support assignment via slices. The Python 2.x interface does support
this, and it works on the buffer object in the Python 3 interface. For
example:
vim.current.range[2:10] = ["some new text"]
or
vim.current.range[5:5] = ["adding a new line at position 5"]
This should work, but instead you get an error stating: "Index must be
int or slice", which of course it is. I created a patch to add this,
trying my best to conform to the existing code structure. Not sure if
this has been covered already; I looked back a few days and searched,
and didn't see anything related. Well, I found a post from someone
stating the problem, but no patches. Anyway, just thought some fellow
vim users might find it useful when working with the Python 3
interface. Have a nice day!
-Brett Overesch
--
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
I've applied your patch and tested it on a line like:
:py3 vim.current.buffer.range(1,3)[0:2]=['line1','line2']
Before your patch this did work for :py but not for :py3.
I've found that
:py3 print(vim.current.buffer.range(1,3)[0:2])
had one entry too much compared to
:py print(vim.current.buffer.range(1,3)[0:2])
I made a little correction for that. The following patch is your patch
plus this one line correction.
-Roland
--
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 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
diff -r 2665b456ee59 src/if_python3.c
--- a/src/if_python3.c Wed Sep 07 19:30:21 2011 +0200
+++ b/src/if_python3.c Wed Sep 07 00:59:25 2011 +0200
@@ -867,6 +867,7 @@
static PyObject* RangeSubscript(PyObject *self, PyObject* idx);
static Py_ssize_t RangeAsItem(PyObject *, Py_ssize_t, PyObject *);
+static Py_ssize_t RangeAsSubscript(PyObject *self, PyObject* idx, PyObject*
val);
/* Current objects type - Implementation functions
* ---
@@ -1084,7 +1085,7 @@
PyMappingMethods RangeAsMapping = {
/* mp_length */ (lenfunc)RangeLength,
/* mp_subscript */ (binaryfunc)RangeSubscript,
-/* mp_ass_subscript */ (objobjargproc)0,
+/* mp_ass_subscript */ (objobjargproc)RangeAsSubscript,
};
/* Line range object - Implementation
@@ -1123,6 +1124,15 @@
&((RangeObject *)(self))->end);
}
+static Py_ssize_t
+RangeAsSlice(PyObject *self, Py_ssize_t lo, Py_ssize_t hi, PyObject *val)
+{
+return RBAsSlice(((RangeObject *)(self))->buf, lo, hi, val,
+ ((RangeObject *)(self))->start,
+ ((RangeObject *)(self))->end,
+ &((RangeObject *)(self))->end);
+}
+
static PyObject *
RangeSubscript(PyObject *self, PyObject* idx)
{
@@ -1138,13 +1148,36 @@
&step, &slicelen) < 0) {
return NULL;
}
- return RangeSlice(self,start,stop+1);
+ return RangeSlice(self,start,stop);
} else {
PyErr_SetString(PyExc_IndexError, "Index must be int or slice");
return NULL;
}
}
+static Py_ssize_t
+RangeAsSubscript(PyObject *self, PyObject* idx, PyObject* val)
+{
+if (PyLong_Check(idx)) {
+ long n = PyLong_AsLong(idx);
+ return RangeAsItem(self, n, val);
+} else if (PySlice_Check(idx)) {
+ Py_ssize_t start, stop, step, slicelen;
+
+ if (PySlice_GetIndicesEx((PySliceObject *)idx,
+ ((RangeObject *)(self))->end-((RangeObject *)(self))->start+1,
+ &start, &stop,
+ &step, &slicelen) < 0) {
+ return -1;
+ }
+ return RangeAsSlice(self, start, stop, val);
+} else {
+ PyErr_SetString(PyExc_IndexError, "Index must be int or slice");
+ return -1;
+}
+}
+
+
/* Buffer list object - Definitions
*/
Re: [patch] Python 3: Add support for assigning to slices on RangeObject
On 09/03/2011 07:26 AM, Brett Overesch wrote:
Hello,
I've been working with Python 3 scripts a lot lately and noticed that
the range objects in the vim modules (e.g. vim.current.range) do not
support assignment via slices. The Python 2.x interface does support
this, and it works on the buffer object in the Python 3 interface. For
example:
vim.current.range[2:10] = ["some new text"]
or
vim.current.range[5:5] = ["adding a new line at position 5"]
This should work, but instead you get an error stating: "Index must be
int or slice", which of course it is. I created a patch to add this,
trying my best to conform to the existing code structure. Not sure if
this has been covered already; I looked back a few days and searched,
and didn't see anything related. Well, I found a post from someone
stating the problem, but no patches. Anyway, just thought some fellow
vim users might find it useful when working with the Python 3
interface. Have a nice day!
-Brett Overesch
--
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
I've applied your patch and tested it on a line like:
:py3 vim.current.buffer.range(1,3)[0:2]=['line1','line2']
Before your patch this did work for :py but not for :py3.
I've found that
:py3 print(vim.current.buffer.range(1,3)[0:2])
had one entry too much compared to
:py print(vim.current.buffer.range(1,3)[0:2])
I made a little correction for that. The following patch is your patch
plus this one line correction.
-Roland
--
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
diff -r 2665b456ee59 src/if_python3.c
--- a/src/if_python3.c Wed Sep 07 19:30:21 2011 +0200
+++ b/src/if_python3.c Wed Sep 07 00:59:25 2011 +0200
@@ -867,6 +867,7 @@
static PyObject* RangeSubscript(PyObject *self, PyObject* idx);
static Py_ssize_t RangeAsItem(PyObject *, Py_ssize_t, PyObject *);
+static Py_ssize_t RangeAsSubscript(PyObject *self, PyObject* idx, PyObject*
val);
/* Current objects type - Implementation functions
* ---
@@ -1084,7 +1085,7 @@
PyMappingMethods RangeAsMapping = {
/* mp_length */ (lenfunc)RangeLength,
/* mp_subscript */ (binaryfunc)RangeSubscript,
-/* mp_ass_subscript */ (objobjargproc)0,
+/* mp_ass_subscript */ (objobjargproc)RangeAsSubscript,
};
/* Line range object - Implementation
@@ -1123,6 +1124,15 @@
&((RangeObject *)(self))->end);
}
+static Py_ssize_t
+RangeAsSlice(PyObject *self, Py_ssize_t lo, Py_ssize_t hi, PyObject *val)
+{
+return RBAsSlice(((RangeObject *)(self))->buf, lo, hi, val,
+ ((RangeObject *)(self))->start,
+ ((RangeObject *)(self))->end,
+ &((RangeObject *)(self))->end);
+}
+
static PyObject *
RangeSubscript(PyObject *self, PyObject* idx)
{
@@ -1138,13 +1148,36 @@
&step, &slicelen) < 0) {
return NULL;
}
- return RangeSlice(self,start,stop+1);
+ return RangeSlice(self,start,stop);
} else {
PyErr_SetString(PyExc_IndexError, "Index must be int or slice");
return NULL;
}
}
+static Py_ssize_t
+RangeAsSubscript(PyObject *self, PyObject* idx, PyObject* val)
+{
+if (PyLong_Check(idx)) {
+ long n = PyLong_AsLong(idx);
+ return RangeAsItem(self, n, val);
+} else if (PySlice_Check(idx)) {
+ Py_ssize_t start, stop, step, slicelen;
+
+ if (PySlice_GetIndicesEx((PySliceObject *)idx,
+ ((RangeObject *)(self))->end-((RangeObject *)(self))->start+1,
+ &start, &stop,
+ &step, &slicelen) < 0) {
+ return -1;
+ }
+ return RangeAsSlice(self, start, stop, val);
+} else {
+ PyErr_SetString(PyExc_IndexError, "Index must be int or slice");
+ return -1;
+}
+}
+
+
/* Buffer list object - Definitions
*/
Re: bug when configuring for both python and python3 (was :python forwarding to :py3 and vice-versa in case of incompatibility)
On 08/31/2011 12:02 AM, Bram Moolenaar wrote: Roland Puntaier wrote: I've tried ./configure --enable-pythoninterp --enable-python3interp on Linux From Scratch with python 2.7 and python 3.2 both compiled with --enable-shared. I would have expected both to work in one instance of vim, but the same messages came up. E836: This Vim cannot execute :python after using :py3 E837: This Vim cannot execute :py3 after using :python I had a look at auto/config.log and it showed that both could do without RTLD_GLOBAL. On the other hand auto/config.h only had #define PY_NO_RTLD_GLOBAL 1 It turns out that an according #undef needs to be in config.h.in. I've added it for python 3, then a vim instance worked with both :python and :py3. The patch is attached. Thanks for finding this pesky little problem! I'll include it soon. after trying with LFS I've tried with ArchLinux, which compiles python 3 and python 2 with --enable-shared. Doing so I've found another little problem: Archlinux VIM also enables perl and then the python[3] configure test for RTLD_GLOBAL does not compile, because it doesn't find the symbols in libdl (dlopen, dlsym, ... ). The solution: -ldl needs to go before the other LDFLAGS. The patch is attached. Roland -- 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 *** configure.in2011-08-31 08:24:58.821189763 +0200 --- /home/roland/src/vim/src/configure.in 2011-08-30 21:47:14.014551690 +0200 *** *** 1161,1167 cflags_save=$CFLAGS CFLAGS="$CFLAGS $PYTHON_CFLAGS" ldflags_save=$LDFLAGS ! LDFLAGS="-ldl $LDFLAGS" AC_RUN_IFELSE([ #include /* If this program fails, then RTLD_GLOBAL is needed. --- 1161,1167 cflags_save=$CFLAGS CFLAGS="$CFLAGS $PYTHON_CFLAGS" ldflags_save=$LDFLAGS ! LDFLAGS="$LDFLAGS -ldl" AC_RUN_IFELSE([ #include /* If this program fails, then RTLD_GLOBAL is needed. *** *** 1205,1211 cflags_save=$CFLAGS CFLAGS="$CFLAGS $PYTHON3_CFLAGS" ldflags_save=$LDFLAGS ! LDFLAGS="-ldl $LDFLAGS" AC_RUN_IFELSE([ #include #include --- 1205,1211 cflags_save=$CFLAGS CFLAGS="$CFLAGS $PYTHON3_CFLAGS" ldflags_save=$LDFLAGS ! LDFLAGS="$LDFLAGS -ldl" AC_RUN_IFELSE([ #include #include
bug when configuring for both python and python3 (was :python forwarding to :py3 and vice-versa in case of incompatibility)
I've tried ./configure --enable-pythoninterp --enable-python3interp on Linux From Scratch with python 2.7 and python 3.2 both compiled with --enable-shared. I would have expected both to work in one instance of vim, but the same messages came up. E836: This Vim cannot execute :python after using :py3 E837: This Vim cannot execute :py3 after using :python I had a look at auto/config.log and it showed that both could do without RTLD_GLOBAL. On the other hand auto/config.h only had #define PY_NO_RTLD_GLOBAL 1 It turns out that an according #undef needs to be in config.h.in. I've added it for python 3, then a vim instance worked with both :python and :py3. The patch is attached. Regards, Roland -- 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 *** config.h.in 2011-08-29 19:01:36.0 +0200 --- ../../vim-7.3.289/src/config.h.in 2011-08-29 23:38:43.0 +0200 *** *** 346,351 --- 346,354 /* Define if dynamic python does not require RTLD_GLOBAL */ #undef PY_NO_RTLD_GLOBAL + /* Define if dynamic python does not require RTLD_GLOBAL */ + #undef PY3_NO_RTLD_GLOBAL + /* Define if you want to include the Ruby interpreter. */ #undef FEAT_RUBY
Re: :python forwarding to :py3 and vice-versa in case of incompatibility
On 08/23/2011 07:09 PM, James Vega wrote:
On Tue, Aug 23, 2011 at 08:37:09PM +0400, ZyX wrote:
Reply to message «Re: :python forwarding to :py3 and vice-versa in case of
incompatibility»,
sent 15:57:44 23 August 2011, Tuesday
by Roland Puntaier:
Here I meant the scenario, where we would go without loading the python
shared object (SO).
Then we would have to do a AC_DEFINE() in the configure.in with the
version.
In that scenario has('python3') would not load the SO, but since
configured, would return true.
I suggest seeking for more information at this point: at least, check whether
python3 so or, especially, DLL exists and only then return true. Especially
because if I am not mistaking, vim without cream is compiled with py3 support,
but this does not guarantee that :py3 will actually work (in my Gentoo adding
python USE flag to vim will also install python, so this is not a problem).
Won't the following work: fork and load library in child, then make it report
about errors and exit?
Another option is to make the language-binding code standalone modules
that are linked with the relevant libraries and Vim dlopen()s the
language modules (as Danek Duvall suggested[0]) instead of having the
language bindings dlopen() the language libraries.
This would also fix the current problem that's preventing me from
enabling dynamic loading for the Debian packages (and I'd imagine
similarly for other binary distributions). Basically, the current
implementation makes it difficult to properly express the library
dependency, so when a new version of the library is introduced there's
no easy way to know whether Vim needs to be rebuilt to work with the new
library version (c.f., discussion in Debian's BTS[1]). With the
standalone modules, it's obvious what the library dependency is since
the module is directly linked to the library.
[0]: http://thread.gmane.org/gmane.editors.vim.devel/22759/focus=22765
[1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611573
The title of this thread is not valid any more. The problem initiating the
thread was that has('python') issued an error message. Currently it's about
whether has('python') should load the library. I think that's not a problem.
Possibly Bram agrees.
The latest contributions made the context broader again. For this let me
summarize the problem about Python3 embedding in general.
1) In most Linux distros it is not possible to import Python extension
libraries
like termios unless a dynamic VIM Python embedding uses RTLD_GLOBAL for
dlopen.
It's in the way Python was compiled for these distros.
Debian e.g. has a statically build Python package and in addition a dynamic
libpython. One Python with binary extensions configured with
--enable-shared
and the problem wouldn't be there.
2) Now using RTLD_GLOBAL would mix the namespaces from Python2.x and
Python3.x,
therefore both are not possible. When I ported to Python3 ([1]) and the
problem arose the idea to make an extra SO, which binds to either
Python2.x or
Python3.x, thus keeping the symbols separate, was there. Then VIM would
have to
be compiled to allow the shared object embedding have access to its symbols
([0]). Then actually all interpreters best should be embedded that way
and allow
to add embeddings later on for specific interpreter versions.
3) The current embedding idea: If a distro has a symbolic link
libpyton2.so and
libpython3.so to the actual version and VIM is configured for both
Python2 and
Python3, then if such a libpythonX.so is there then VIM has the
embedding else
not. I need to add, that actually currently VIM's configure doesn't allow to
specify the python SO. One needs to change auto/config.mk after configure.
In general that's not so bad, expecially if that Python with all binary
extension modules was configured with --enable-shared.
4) Anyway, there are these distros that don't have these --enable-shared
configured Python2.x and Python3.x. So one VIM instance cannot use :py3 and
:python together. The first call will determine which python embedding is
activated. has('python') or has('python3') does also activate the version.
5) I would keep VIM Python embedding it this way for now.
I would like distro's to better consider to the current VIM python3
embedding.
Links:
[0]
Link to dlopen wiki:
http://en.wikipedia.org/wiki/Dynamic_loading#UNIX-like_operating_systems_.28Linux.2C_.2ABSD.2C_Mac_OS_X.2C_Solaris.2C_etc..29_3
[1]
Link to python3 embedding thread:
http://groups.google.com/group/vim_dev/browse_thread/thread/164c2a02f73046e9#
@James: Would a solution like in 3) work for debian?
--
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
Re: :python forwarding to :py3 and vice-versa in case of incompatibility
On 08/22/2011 10:11 PM, Bram Moolenaar wrote:
Roland Puntaier wrote:
This still has the problem that just checking for python or python3
being available loads the library before knowing what version it is.
Thus a plugin checking for python causes python to be loaded and thereby
disabling python3.
Perhaps we don't care? At least the user can put has('python3') in his
vimrc to force loading the preferred version.
This is fine.
The other solution with a configure define would have another problem:
has('python3')
python
has('python3')
The first time it would be true and the second time false.
I don't think so. Did you try it? For me the python command fails.
Here I meant the scenario, where we would go without loading the python
shared object (SO).
Then we would have to do a AC_DEFINE() in the configure.in with the
version.
In that scenario has('python3') would not load the SO, but since
configured, would return true.
:python would load python2 SO, because also configure.
Now has('python3'), which would take into account that both cannot run
in the same instance, would return false.
The change in python.vim and vim.vim would be good to have, too.
I'm not familiar with aap, so that change was just to make you give it a
thought.
The problem is that checking with has() actually loads that python
version and may prevent the other to load.
I did understand that. I said that this is fine, i.e. no problem,
because the user can put a has('python3') or has('python') or a
python/py3 command into his vimrc.
I basically agreed to your 'Perhaps we don't care? ...',
Will you take over the changes in python.vim and vim.vim as well?
Sorry, for not expressing myself well.
Roland
--
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
Re: :python forwarding to :py3 and vice-versa in case of incompatibility
On 08/21/2011 05:53 PM, Bram Moolenaar wrote:
Roland Puntaier wrote:
On 08/19/2011 10:29 PM, Bram Moolenaar wrote:
Roland Puntaier wrote:
E836: This Vim cannot execute :python after using :py3
This happened to me several times already when changing to a buffer with
python code, e.g. to my .vimrc file. The reason was that omnifunc was
set to pythoncomplete#Complete.
Correction: the reason was that has("python") issued the error if I had
used :py3.
Python 2.6 and python 2.7 have had changes to make it more compatible
with python3. It is now quite easy to write code that works for both,
python2.x and python3.x.
You mean Python 2.6, 2.7 and 3.x. Not for Python 2.5 and earlier.
With the error message triggering and the latter thought I tried to go
for the following: forward to the other python command.
- The first time vim realizes that it cannot run python (py3) because of
the RTLD problem this error message is issued:
E836: This Vim cannot execute :python after using :py3. Will
forward future calls to :py3.
or
E837: This Vim cannot execute :py3 after using :python. Will
forward future calls to python.
(Of course, I've not changed the translations of the these messages.)
- The second time the python command is forwarded to the other python
command
- If the system/python version allows both, python 2.x and python 3.x,
there is no forwarding.
- This applies only if vim is configure for both python versions
If somebody has a script, which uses either :py3 or :python, the
following sequence in the .vimrc as first python interaction will
redirect all calls to :py3.
"redirect :python to :py3
py3 3
python 2
"argument has no meaning
If the order is changed :py3 calls will be redirected to :python.
@Bram: If you agree, please merge it to the main vim line.
@Aaron: Since the changes in python3complete.vim do work for python 2.6
and python 2.7 (I've test it), I have moved it to pythoncomplete.vim.
The patch contains this move. The original pythoncomplete.vim I've moved
to python25complete.vim with according internal renaming. It is attached.
Do you agree with this proceeding?
I'm moving to ArchLinux and in the vim package there pythoncomplete.vim
is separate. The same version is already included in the vim sources.
I know quite a few people use Python 2.4, because some scripts don't
work with later versions.
This is about my change in pythoncomplete.vim.
I agree.
@Aaron: No change regarding pythoncomplete.vim and python3complete.vim.
I don't like getting an error only the first time something goes wrong,
it can easily be missed.
Why not add a way to ask Vim what Python versions are available. This
can use PYTHON_API_VERSION or PY_VERSION_HEX. Depending on that a
script can try loading the version it wants and check with has() if it's
actually available. Then define a user command with :py3 or :python, as
desired. Or give an error message if the Python version is not
supported.
Something like:
if pythonversion() =~ '2\.[67]'&& has('python')
command Pyt python
elseif pythonversion() =~ '3\.'&& has('python3')
command Pyt py3
else
echoerr "No usable Python version"
endif
A function like
interpreter_version('lua'|'mzscheme'|'perl'|'python'|'python3'|'ruby'|'tcl')
wouldn't harm, but it's not needed.
If we know whether Python2 or Python3 then the rest can be found out by
a Python script.
The same is true for the other interpreters, else such a function would
have been missed.
It is enough when has() takes into account the case where
both 2.x and 3.x are configured but only one can be active per VIM
instance.
*Then has() should return true only for the active one and not issue an
error.*
The change in has() and some little adaptations in vim files are attached.
That's copying code unneccessarily. The EMSG in
python_runtime_link_init() is lacking a check for the verbose argument.
See patch below.
Of course. I missed the verbose parameter.
This still has the problem that just checking for python or python3
being available loads the library before knowing what version it is.
Thus a plugin checking for python causes python to be loaded and thereby
disabling python3.
Perhaps we don't care? At least the user can put has('python3') in his
vimrc to force loading the preferred version.
This is fine.
The other solution with a configure define would have another problem:
has('python3')
python
has('python3')
The first time it would be true and the second time false.
The change in python.vim and vim.vim would be good to have, too.
I'm not familiar with aap, so that change was just to make you give it a
thought.
Thanks again.
Rolan
Re: :python forwarding to :py3 and vice-versa in case of incompatibility
On 08/19/2011 10:29 PM, Bram Moolenaar wrote:
Roland Puntaier wrote:
E836: This Vim cannot execute :python after using :py3
This happened to me several times already when changing to a buffer with
python code, e.g. to my .vimrc file. The reason was that omnifunc was
set to pythoncomplete#Complete.
Correction: the reason was that has("python") issued the error if I had
used :py3.
Python 2.6 and python 2.7 have had changes to make it more compatible
with python3. It is now quite easy to write code that works for both,
python2.x and python3.x.
You mean Python 2.6, 2.7 and 3.x. Not for Python 2.5 and earlier.
With the error message triggering and the latter thought I tried to go
for the following: forward to the other python command.
- The first time vim realizes that it cannot run python (py3) because of
the RTLD problem this error message is issued:
E836: This Vim cannot execute :python after using :py3. Will
forward future calls to :py3.
or
E837: This Vim cannot execute :py3 after using :python. Will
forward future calls to python.
(Of course, I've not changed the translations of the these messages.)
- The second time the python command is forwarded to the other python
command
- If the system/python version allows both, python 2.x and python 3.x,
there is no forwarding.
- This applies only if vim is configure for both python versions
If somebody has a script, which uses either :py3 or :python, the
following sequence in the .vimrc as first python interaction will
redirect all calls to :py3.
"redirect :python to :py3
py3 3
python 2
"argument has no meaning
If the order is changed :py3 calls will be redirected to :python.
@Bram: If you agree, please merge it to the main vim line.
@Aaron: Since the changes in python3complete.vim do work for python 2.6
and python 2.7 (I've test it), I have moved it to pythoncomplete.vim.
The patch contains this move. The original pythoncomplete.vim I've moved
to python25complete.vim with according internal renaming. It is attached.
Do you agree with this proceeding?
I'm moving to ArchLinux and in the vim package there pythoncomplete.vim
is separate. The same version is already included in the vim sources.
I know quite a few people use Python 2.4, because some scripts don't
work with later versions.
This is about my change in pythoncomplete.vim.
I agree.
@Aaron: No change regarding pythoncomplete.vim and python3complete.vim.
I don't like getting an error only the first time something goes wrong,
it can easily be missed.
Why not add a way to ask Vim what Python versions are available. This
can use PYTHON_API_VERSION or PY_VERSION_HEX. Depending on that a
script can try loading the version it wants and check with has() if it's
actually available. Then define a user command with :py3 or :python, as
desired. Or give an error message if the Python version is not
supported.
Something like:
if pythonversion() =~ '2\.[67]'&& has('python')
command Pyt python
elseif pythonversion() =~ '3\.'&& has('python3')
command Pyt py3
else
echoerr "No usable Python version"
endif
A function like
interpreter_version('lua'|'mzscheme'|'perl'|'python'|'python3'|'ruby'|'tcl')
wouldn't harm, but it's not needed.
If we know whether Python2 or Python3 then the rest can be found out by
a Python script.
The same is true for the other interpreters, else such a function would
have been missed.
It is enough when has() takes into account the case where
both 2.x and 3.x are configured but only one can be active per VIM
instance.
*Then has() should return true only for the active one and not issue an
error.*
The change in has() and some little adaptations in vim files are attached.
Thanks.
- Roland
--
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
diff -r 3edc4535acfa runtime/ftplugin/python.vim
--- a/runtime/ftplugin/python.vim Wed Aug 10 18:36:54 2011 +0200
+++ b/runtime/ftplugin/python.vim Sat Aug 20 16:59:28 2011 +0200
@@ -14,7 +14,11 @@
setlocal comments-=:%
setlocal commentstring=#%s
-setlocal omnifunc=pythoncomplete#Complete
+if has("python")
+setlocal omnifunc=pythoncomplete#Complete
+elseif has("python3")
+setlocal omnifunc=python3complete#Complete
+endif
set wildignore+=*.pyc
diff -r 3edc4535acfa runtime/syntax/aap.vim
--- a/runtime/syntax/aap.vimWed Aug 10 18:36:54 2011 +0200
+++ b/runtime/syntax/aap.vimSat Aug 20 16:59:28 2011 +0200
@@ -118,9 +118,9 @@
" A Python line starts with @. Can be continued with a trailing backslash.
syn region aapPythonRegion st
:python forwarding to :py3 and vice-versa in case of incompatibility
Hello Bram!
Hallo Aaron!
E836: This Vim cannot execute :python after using :py3
This happened to me several times already when changing to a buffer with
python code, e.g. to my .vimrc file. The reason was that omnifunc was
set to pythoncomplete#Complete.
Python 2.6 and python 2.7 have had changes to make it more compatible
with python3. It is now quite easy to write code that works for both,
python2.x and python3.x.
With the error message triggering and the latter thought I tried to go
for the following: forward to the other python command.
- The first time vim realizes that it cannot run python (py3) because of
the RTLD problem this error message is issued:
E836: This Vim cannot execute :python after using :py3. Will
forward future calls to :py3.
or
E837: This Vim cannot execute :py3 after using :python. Will
forward future calls to python.
(Of course, I've not changed the translations of the these messages.)
- The second time the python command is forwarded to the other python
command
- If the system/python version allows both, python 2.x and python 3.x,
there is no forwarding.
- This applies only if vim is configure for both python versions
If somebody has a script, which uses either :py3 or :python, the
following sequence in the .vimrc as first python interaction will
redirect all calls to :py3.
"redirect :python to :py3
py3 3
python 2
"argument has no meaning
If the order is changed :py3 calls will be redirected to :python.
@Bram: If you agree, please merge it to the main vim line.
@Aaron: Since the changes in python3complete.vim do work for python 2.6
and python 2.7 (I've test it), I have moved it to pythoncomplete.vim.
The patch contains this move. The original pythoncomplete.vim I've moved
to python25complete.vim with according internal renaming. It is attached.
Do you agree with this proceeding?
I'm moving to ArchLinux and in the vim package there pythoncomplete.vim
is separate. The same version is already included in the vim sources.
- Roland
--
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
diff -r 3edc4535acfa runtime/autoload/pythoncomplete.vim
--- a/runtime/autoload/pythoncomplete.vim Wed Aug 10 18:36:54 2011 +0200
+++ b/runtime/autoload/pythoncomplete.vim Wed Aug 17 05:35:24 2011 +0200
@@ -3,6 +3,9 @@
" Version: 0.9
" Last Updated: 18 Jun 2009
"
+" Roland Puntaier: this file contains adaptations for python3, which also work
for python2.6 onward.
+" The original pythoncomplete.vim has been moved to python25complete.vim with
according internal renamings
+"
" Changes
" TODO:
" 'info' item output can use some formatting work
@@ -41,8 +44,8 @@
" rewrite.
"
-if !has('python')
-echo "Error: Required vim compiled with +python"
+if !has('python3') && !has('python')
+echo "Error: Required vim compiled with +python or +python3"
finish
endif
@@ -88,42 +91,23 @@
function! s:DefPython()
python << PYTHONEOF
-import sys, tokenize, cStringIO, types
+import sys, tokenize, io, types
from token import NAME, DEDENT, NEWLINE, STRING
debugstmts=[]
def dbg(s): debugstmts.append(s)
def showdbg():
-for d in debugstmts: print "DBG: %s " % d
+for d in debugstmts: print("DBG: %s " % d)
def vimcomplete(context,match):
global debugstmts
debugstmts = []
try:
import vim
-def complsort(x,y):
-try:
-xa = x['abbr']
-ya = y['abbr']
-if xa[0] == '_':
-if xa[1] == '_' and ya[0:2] == '__':
-return xa > ya
-elif ya[0:2] == '__':
-return -1
-elif y[0] == '_':
-return xa > ya
-else:
-return 1
-elif ya[0] == '_':
-return -1
-else:
- return xa > ya
-except:
-return 0
cmpl = Completer()
cmpl.evalsource('\n'.join(vim.current.buffer),vim.eval("line('.')"))
all = cmpl.get_completions(context,match)
-all.sort(complsort)
+all.sort(key=lambda x:x['abbr'].replace('_','z'))
dictstr = '['
# have to do this for double quoting
for cmpl in all:
@@ -147,44 +131,43 @@
sc = self.parser.parse(text,line)
src = sc.get_code()
dbg("source: %s" % src)
-try: exec(src) in self.
bug: vim 7.3 Python 3.2 FATAL "take_gil: NULL state"
Hello Bram, I've compiled vim7.3 with Python3.2 and got "take_gil: NULL state" when doing :py3 ... After some investigation I found that with Python3.2 PyEval_InitThreads() must be called after Py_Initialize(). This needs to be changed in if_python3.c. regards, Roland -- 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
[patch] Py_SetPythonHome for Python2 and Python3
Hi James,
Hi Bram,
I recently sent a patch for Python3, because it was not possible to
import modules,
if Python3 was installed in /usr/local. I have now extended the patch
for Python2.
Py_Initialize() had come back with a sys.path for /usr instead of
/usr/local.
@James: Py_GetPrefix would come back with /usr just like Py_Initialize().
So the patch calls Py_SetPythonHome() with a path provided by the
configuration script.
This is also used for the configuration test, whether RTLD_GLOBAL is
necessary.
Cheers, Roland
--
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
--- a/src/configure.in Sun Aug 15 15:24:20 2010 +0200
+++ b/src/configure.in Tue Nov 09 22:51:40 2010 +0100
@@ -857,9 +857,9 @@
PYTHON_LIBS="${vi_cv_path_python_plibs}"
if test "${vi_cv_path_python_pfx}" = "${vi_cv_path_python_epfx}"; then
- PYTHON_CFLAGS="-I${vi_cv_path_python_pfx}/include/python${vi_cv_var_python_version}"
+ PYTHON_CFLAGS="-I${vi_cv_path_python_pfx}/include/python${vi_cv_var_python_version} -DPYTHON_PREFIX=L\"${vi_cv_path_python_pfx}\""
else
- PYTHON_CFLAGS="-I${vi_cv_path_python_pfx}/include/python${vi_cv_var_python_version} -I${vi_cv_path_python_epfx}/include/python${vi_cv_var_python_version}"
+ PYTHON_CFLAGS="-I${vi_cv_path_python_pfx}/include/python${vi_cv_var_python_version} -I${vi_cv_path_python_epfx}/include/python${vi_cv_var_python_version} -DPYTHON_PREFIX=L\"${vi_cv_path_python_pfx}\""
fi
PYTHON_SRC="if_python.c"
dnl For Mac OSX 10.2 config.o is included in the Python library.
@@ -871,7 +871,7 @@
if test "${vi_cv_var_python_version}" = "1.4"; then
PYTHON_OBJ="$PYTHON_OBJ objects/py_getpath.o"
fi
- PYTHON_GETPATH_CFLAGS="-DPYTHONPATH='\"${vi_cv_path_pythonpath}\"' -DPREFIX='\"${vi_cv_path_python_pfx}\"' -DEXEC_PREFIX='\"${vi_cv_path_python_epfx}\"'"
+PYTHON_GETPATH_CFLAGS="-DPYTHONPATH='\"${vi_cv_path_pythonpath}\"' -DPREFIX='\"${vi_cv_path_python_pfx}\"' -DEXEC_PREFIX='\"${vi_cv_path_python_epfx}\"'"
dnl On FreeBSD linking with "-pthread" is required to use threads.
dnl _THREAD_SAFE must be used for compiling then.
@@ -1029,9 +1029,9 @@
PYTHON3_LIBS="${vi_cv_path_python3_plibs}"
if test "${vi_cv_path_python3_pfx}" = "${vi_cv_path_python3_epfx}"; then
-PYTHON3_CFLAGS="-I${vi_cv_path_python3_pfx}/include/python${vi_cv_var_python3_version}"
+PYTHON3_CFLAGS="-I${vi_cv_path_python3_pfx}/include/python${vi_cv_var_python3_version} -DPYTHON3_PREFIX=L\"${vi_cv_path_python3_pfx}\""
else
-PYTHON3_CFLAGS="-I${vi_cv_path_python3_pfx}/include/python${vi_cv_var_python3_version} -I${vi_cv_path_python3_epfx}/include/python${vi_cv_var_python3_version}"
+PYTHON3_CFLAGS="-I${vi_cv_path_python3_pfx}/include/python${vi_cv_var_python3_version} -I${vi_cv_path_python3_epfx}/include/python${vi_cv_var_python3_version} -DPYTHON3_PREFIX=L\"${vi_cv_path_python3_pfx}\""
fi
PYTHON3_SRC="if_python3.c"
dnl For Mac OSX 10.2 config.o is included in the Python library.
@@ -1109,28 +1109,32 @@
if test "$python_ok" = yes && test "$python3_ok" = yes; then
AC_DEFINE(DYNAMIC_PYTHON)
AC_DEFINE(DYNAMIC_PYTHON3)
- AC_MSG_CHECKING(whether we can do without RTLD_GLOBAL)
+ AC_MSG_CHECKING(whether we can do without RTLD_GLOBAL for Python)
cflags_save=$CFLAGS
- CFLAGS="$CFLAGS $PYTHON3_CFLAGS"
+ CFLAGS="$CFLAGS $PYTHON_CFLAGS"
ldflags_save=$LDFLAGS
LDFLAGS="$LDFLAGS -ldl"
AC_RUN_IFELSE([
#include
+#include
+#include
/* If this program fails, then RTLD_GLOBAL is needed.
* RTLD_GLOBAL will be used and then it is not possible to
* have both python versions enabled in the same vim instance.
* Only the first pyhton version used will be switched on.
*/
-int no_rtl_global_needed_for(char *python_instsoname)
+int no_rtl_global_needed_for(char *python_instsoname, char *prefix)
{
int needed = 0;
void* pylib = dlopen(python_instsoname, RTLD_LAZY);
if (pylib != 0)
{
+ void (*pfx)(char *home) = dlsym(pylib, "Py_SetPythonHome");
void (*init)(void) = dlsym(pylib, "Py_Initialize");
int (*simple)(char*) = dlsym(pylib, "PyRun_SimpleString");
void (*final)(void) = dlsym(pylib, "Py_Finalize");
+ (*pfx)(prefix);
(*init)();
needed = (*simple)("import termios") == -1;
(*final)();
@@ -1142,13 +1146,63 @@
int main(int argc, char** argv)
{
int not_needed = 0;
- if (no_rtl_global_needed_for("libpython2.7.so.1.0") && no_rtl_global_needed_for("libpython3.1.so.1.0"))
+ char *prefix = malloc(PATH_MAX);//malloc because no brackets allowed
+ memset(prefix,0,PATH_MAX);
+ wcstombs(prefix, PYTHON_PREFIX, wcslen(PYTHON_PREFIX) );
+ if (no_rtl_global_needed_for("${python_INSTSONAME}"prefix))
n
Re: [patch] Py_SetPythonHome for python3 to make import work
James Vega wrote: On Sun, Nov 07, 2010 at 06:04:35PM +0200, Roland Puntaier wrote: Hi Bram, After installing vim7.3 on a ubuntu system, I had again the problem that import did not work for .so libraries in lib-dynload. I found that sys.path was initialized with "/usr/..." instead of "/usr/local/...". On ubuntu (and probably on other linux distros as well) python3 is installed in /usr/local while python2 is installed in /usr. That's not the case at all[0]. No distribution package should install to /usr/local as that's a reserved directory structure for the system administrator[1]. If your Python3 install is in /usr/local, then whoever admins that system installed it there. OK, maybe I didn't use apt-get. Nevertheless, as most original sources do, python 3.x defaults to /usr/local prefix. And anyway, for the problem, it doesn't matter how it got there. The attached patch calls Py_SetPythonHome with PYTHON3_PREFIX defined by configure. This solves the problem. This should probably be done for Python2.x as well. Yeah, you are right. I will send a new patch soon. -- 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
Re: Py_SetPythonHome for python3 to make import work
Philippe Vaucher wrote: Why the hell happened there? Seems you replied to the wrong thread and managed to change the subject. Look at http://groups.google.com/group/vim_dev/browse_thread/thread/6972ae8d369cf671/a183f61488f3006c# Philippe Sorry Philippe, Using Thunderbird I've chosen an arbitrary message from vim_dev and changed subject and body. I didn't know that the threading is done on invisible email message fields other than the subject. I looked at the email source and found fields like References and In-Reply-To. There is always something new to learn. For my next message I'll take it into account. -- 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
[patch] Py_SetPythonHome for python3 to make import work
Hi Bram,
After installing vim7.3 on a ubuntu system, I had again the problem that
import did not work for .so libraries in lib-dynload. I found that
sys.path was initialized with "/usr/..." instead of "/usr/local/...". On
ubuntu (and probably on other linux distros as well) python3 is
installed in /usr/local while python2 is installed in /usr.
The attached patch calls Py_SetPythonHome with PYTHON3_PREFIX defined by
configure.
This solves the problem.
regards, Roland
--
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
diff -r ee53a39d5896 src/auto/configure
--- a/src/auto/configure Sun Aug 15 15:24:20 2010 +0200
+++ b/src/auto/configure Sun Nov 07 12:06:52 2010 +0100
@@ -5560,9 +5560,9 @@
PYTHON3_LIBS="${vi_cv_path_python3_plibs}"
if test "${vi_cv_path_python3_pfx}" = "${vi_cv_path_python3_epfx}"; then
-PYTHON3_CFLAGS="-I${vi_cv_path_python3_pfx}/include/python${vi_cv_var_python3_version}"
+PYTHON3_CFLAGS="-I${vi_cv_path_python3_pfx}/include/python${vi_cv_var_python3_version} -DPYTHON3_PREFIX=L\\\"${vi_cv_path_python3_pfx}\\\""
else
-PYTHON3_CFLAGS="-I${vi_cv_path_python3_pfx}/include/python${vi_cv_var_python3_version} -I${vi_cv_path_python3_epfx}/include/python${vi_cv_var_python3_version}"
+PYTHON3_CFLAGS="-I${vi_cv_path_python3_pfx}/include/python${vi_cv_var_python3_version} -I${vi_cv_path_python3_epfx}/include/python${vi_cv_var_python3_version} -DPYTHON3_PREFIX=L\\\"${vi_cv_path_python3_pfx}\\\""
fi
PYTHON3_SRC="if_python3.c"
if test "x$MACOSX" = "xyes"; then
diff -r ee53a39d5896 src/configure.in
--- a/src/configure.in Sun Aug 15 15:24:20 2010 +0200
+++ b/src/configure.in Sun Nov 07 12:06:52 2010 +0100
@@ -1029,9 +1029,9 @@
PYTHON3_LIBS="${vi_cv_path_python3_plibs}"
if test "${vi_cv_path_python3_pfx}" = "${vi_cv_path_python3_epfx}"; then
-PYTHON3_CFLAGS="-I${vi_cv_path_python3_pfx}/include/python${vi_cv_var_python3_version}"
+PYTHON3_CFLAGS="-I${vi_cv_path_python3_pfx}/include/python${vi_cv_var_python3_version} -DPYTHON3_PREFIX=L\\\"${vi_cv_path_python3_pfx}\\\""
else
-PYTHON3_CFLAGS="-I${vi_cv_path_python3_pfx}/include/python${vi_cv_var_python3_version} -I${vi_cv_path_python3_epfx}/include/python${vi_cv_var_python3_version}"
+PYTHON3_CFLAGS="-I${vi_cv_path_python3_pfx}/include/python${vi_cv_var_python3_version} -I${vi_cv_path_python3_epfx}/include/python${vi_cv_var_python3_version} -DPYTHON3_PREFIX=L\\\"${vi_cv_path_python3_pfx}\\\""
fi
PYTHON3_SRC="if_python3.c"
dnl For Mac OSX 10.2 config.o is included in the Python library.
diff -r ee53a39d5896 src/if_python3.c
--- a/src/if_python3.c Sun Aug 15 15:24:20 2010 +0200
+++ b/src/if_python3.c Sun Nov 07 12:06:52 2010 +0100
@@ -132,6 +132,7 @@
# define PyType_Ready py3_PyType_Ready
#undef Py_BuildValue
# define Py_BuildValue py3_Py_BuildValue
+# define Py_SetPythonHome py3_Py_SetPythonHome
# define Py_Initialize py3_Py_Initialize
# define Py_Finalize py3_Py_Finalize
# define Py_IsInitialized py3_Py_IsInitialized
@@ -170,6 +171,7 @@
* Pointers for dynamic link
*/
static int (*py3_PySys_SetArgv)(int, wchar_t **);
+static void (*py3_Py_SetPythonHome)(wchar_t *home);
static void (*py3_Py_Initialize)(void);
static PyObject* (*py3_PyList_New)(Py_ssize_t size);
static PyGILState_STATE (*py3_PyGILState_Ensure)(void);
@@ -254,6 +256,7 @@
} py3_funcname_table[] =
{
{"PySys_SetArgv", (PYTHON_PROC*)&py3_PySys_SetArgv},
+{"Py_SetPythonHome", (PYTHON_PROC*)&py3_Py_SetPythonHome},
{"Py_Initialize", (PYTHON_PROC*)&py3_Py_Initialize},
{"PyArg_ParseTuple", (PYTHON_PROC*)&py3_PyArg_ParseTuple},
{"PyList_New", (PYTHON_PROC*)&py3_PyList_New},
@@ -539,6 +542,11 @@
init_structs();
+
+#ifdef PYTHON3_PREFIX
+Py_SetPythonHome(PYTHON3_PREFIX);
+#endif
+
/* initialise threads */
PyEval_InitThreads();
Re: Vim 7.3: Python3 support
On 08.12.2010 22:43:06 b...@moolenaar.net wrote : > Can you please also write some text for the help about this? > I'll change the E999 to a valid number, we should have a tag in the help > file that explains the message. In my yesterday's patch I have changed the E999 line in if_python.c and if_python3.c. Please restore it to the original line. Here is the diff for if_pyth.txt with a E999 tag. -- 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 if_pyth_rtld_global.diff Description: Binary data
Re: Vim 7.3: Python3 support
On 12.08.2010 06:33:07 James Vega wrote: > On Tue, Aug 10, 2010 at 11:15:41PM +0200, Bram Moolenaar wrote: > > A configure check would help to decide whether everything works without > > RTLD_GLOBAL global. If it does, then the current solution is best. If > > it doesn't it might be better to switch to the other solution: do use > > RTLD_GLOBAL but disallow using both python commands. > > Attached is a configure check that determines if RTLD_GLOBAL is needed, > when building with dynamic python. If so, it enables the "only one > Python interface can be used per session" code. Hi James, I agree with you, that it makes sense, to have such a test at configuration time. It makes a good guess for the system. Since we are at the configuration step, one could turn off Python2 or Python3 altogether, but I agree that it's not so bad to keep them enabled, so, when starting vim, the first Python version used will be switched on, i.e. the user can have both in a binary distribution, just not both at the same time. The user is unlikely to need both python versions at the same time, I would say. My other arguments are for those who do their own configuration and would like to have both enabled even if one will not work for some extension libraries. But probably one can also expect from them that they manually define PY_NO_RTLD_GLOBAL. The C code checks for Python 3 only. Whether Python 2 needs RTLD_GLOBAL is independent of whether Python3 needs RTLD_GLOBAL. The crash happens if any one or both use RTLD_GLOBAL. I changed it. Here is the new diff. The define should be PY_NO_RTLD_GLOBAL, so if not defined, as is the case for a configuration of only one dynamically linked Python version, it defaults to using RTLD_GLOBAL. But I've seen that unlike for e.g. PERL or LUA --enable-pythoninterp=dynamic does not work. I have changed that, too. Roland -- 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 if_py23_rtld_global.diff Description: Binary data
Re: Vim 7.3: Python3 support
On 08.09.2010 22:02:48 b...@moolenaar.net wrote: > > I would opt for the following: > > > > If only one, Python 2.x xor Python 3.x, is configured (and if > > DYNAMIC_PYTHON), then use RTLD_GLOBAL: > > #define load_dll(n) dlopen((n), RTLD_LAZY|RTLD_GLOBAL) > > > > If both are configured use without RTLD_GLOBAL: > > #define load_dll(n) dlopen((n),RTLD_LAZY) > > OK, that's a reasonable compromise, should make most things work for > most people. > > Can you please document this in the help? We need to update the section > about the Python 3 support anyway! What differences are there? There are no differences apart from :py3 <-> :py[thon], and the discussed consequences, and the possible restrictions in python functionality, if both versions are enabled, as discussed in this thread. I had a look at the current documentation. You already mention Python 3. Since there are no other differences this should suffice. With the above compromise I suggest the following as last chapter in if_pyth.txt. == 7. Python 3 *python3* *:py3* *:python3* The |:py3| and |:python3| commands work similar to |:python|. *:py3file* The |:py3file| command works similar to |:pyfile|. Vim can be built in four ways (:version output): 1. No Python support(-python, -python3) 2. Python 2 support only(+python or +python/dyn, -python3) 3. Python 3 support only(-python, +python3 or +python3/dyn) 4. Python 2 and 3 support (+python/dyn, +python3/dyn) You can see that when Python 2 and Python 3 are both supported they must be loaded dynamically. On Linux/Unix systems this can only be done without importing global symbols. In this case python's "import" might fail, if the library expects the symbols to be provided by vim. To work around this 1. either the problematic library, or python in case of standard libraries, must be recompiled to link to the according libpython.so file (--enable-shared in case of python). 2. Or you recompile vim for only one python version. In this case all symbols can be imported into vim. == Regards, Roland -- 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
Re: Vim 7.3: Python3 support
On 08.09.2010 22:02:50 b...@moolenaar.net wrote: > James Vega wrote: > > On Mon, Aug 9, 2010 at 9:49 AM, Roland Puntaier > > wrote: > > > On Mon, 09 Aug 2010 13:49:43 > > > Andy Kittner wrote: > > >> > > I made the test in Vim 7.3: After removing RTLD_GLOBAL there wasno > > >> > > crash > > >> > > any more. > > >> > > > >> > If I'm not mistaken this flag was added to make "import termios" work. > > >> > Or something like that. > > >> > > >> The issue was that at least on some systems pythons C- > Extensions seemingly > > >> aren't linked against the python shared library, therefore they can't be > > >> imported unless the host application provides the required symbols. > > >> > > >> See this thread: "Linking errors when compiled with both python and > > >> python3" > > >> > > > http://groups.google.com/group/vim_dev/browse_frm/thread/10be77eb81ad1c2d/fed7c6d9e3932ef5?tvc=1 > > > > > > I had the same problem with PyQt 4.7, first, but at a later try it worked, > > > probably because that linked against libpython 3.1.2. > > > Andy reported termios to work as well on his system. > > > > > Maybe we can optimistically assume that for most python > libraries / systems > > > it works. > > > > > > I would opt for the following: > > > > > > If only one, Python 2.x xor Python 3.x, is configured (and if > > > DYNAMIC_PYTHON), then use RTLD_GLOBAL: > > > #define load_dll(n) dlopen((n), RTLD_LAZY|RTLD_GLOBAL) > > > > > > If both are configured use without RTLD_GLOBAL: > > > #define load_dll(n) dlopen((n),RTLD_LAZY) > > > > I would instead suggest a configure-time check to determine whether it's > > possible to load one of the lib-dynload modules without RTLD_GLOBAL set. > > Simply deciding not to use RTLD_GLOBAL because both Python versions have > > been chosen means that neither will work on systems where the > > lib-dynload modules aren't linked against libpython since some of the > > lib-dynload modules are always used by Python. > > What do you suggest we do when RTLD_GLOBAL is needed? Disallow building > with two versions of Python? Or restrict use at runtime, as it is now? > We could add an option to switch using RTLD_GLOBAL on/off, but it's > really ugly. I would rather tell users to build two versions of Vim, > one with Python 2 and one with Python 3. So without RTLD_GLOBAL we have found that certain python C extension modules that were not linked to libpython cannot be loaded. This is less a problem than a crash. It can also be tackled by recompiling that extension module or the system package. For termios, I suppose recompiling python with --enable-shared should work. My assumption is that certain distros distribute python without --enable-shared and the libpython gets into the system by other packages. On the other hand a crash is not acceptable and thus RTLD_GLOBAL when both python version are enable is not acceptable. To find out during configuration is expensive and the outcome is only that enabling both can lead to one, possibly both version with reduced functionality. Such a message could be issued at configuration time, but without the expense to actually verify, whether there will be reduced functionality. To disable one python version either at configuration time or runtime is against the intention of the user to have both enabled. Maybe the user can live with the reduced python functionality. If not, there are options: 1) reconfigure vim for one python version only 2) recompile and properly link the problematic library, or python as a whole in case of its standard libraries. Regards, Roland -- 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
Re: Vim 7.3: Python3 support
On Mon, 09 Aug 2010 13:49:43 Andy Kittner wrote: > > > I made the test in Vim 7.3: After removing RTLD_GLOBAL there wasno crash > > > any more. > > > > If I'm not mistaken this flag was added to make "import termios" work. > > Or something like that. > > The issue was that at least on some systems pythons C-Extensions seemingly > aren't linked against the python shared library, therefore they can't be > imported unless the host application provides the required symbols. > > See this thread: "Linking errors when compiled with both python and python3" > http://groups.google.com/group/vim_dev/browse_frm/thread/10be77eb81ad1c2d/fed7c6d9e3932ef5?tvc=1 Hi Bram, I missed that thread. I had the same problem with PyQt 4.7, first, but at a later try it worked, probably because that linked against libpython 3.1.2. Andy reported termios to work as well on his system. Maybe the problematic termios was older or not linked against libpython, because it was not there at the time termios was configured. Maybe we can optimistically assume that for most python libraries / systems it works. I would opt for the following: If only one, Python 2.x xor Python 3.x, is configured (and if DYNAMIC_PYTHON), then use RTLD_GLOBAL: #define load_dll(n) dlopen((n), RTLD_LAZY|RTLD_GLOBAL) If both are configured use without RTLD_GLOBAL: #define load_dll(n) dlopen((n),RTLD_LAZY) -- 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
Re: Vim 7.3: Python3 support
Hello Bram, sorry about my late response, first I was on holiday, then I was quite busy. I compared the vim7.3d sources to my original ones on Saturday. Most of the functions are basically the same, but I spotted a relevant difference: I had: #define load_dll(n) dlopen((n),RTLD_LAZY) Vim 7.3 has: #define load_dll(n) dlopen((n), RTLD_LAZY|RTLD_GLOBAL) I recalled, that back then I had had the same crash, probably because global static variables got mixed up. I made the test in Vim 7.3: After removing RTLD_GLOBAL there was no crash any more. Regards, Roland b...@moolenaar.net schrieb am 06.08.2010 21:16:39: > Von: Bram Moolenaar > An: Roland Puntaier > Kopie: vim_dev@googlegroups.com > Datum: 06.08.2010 21:16 > Betreff: Re: Vim 7.3: Python3 support > Gesendet von: b...@moolenaar.net > > > Roland - > > You have been quiet for a while. I still have the workaround that in > one Vim session one can only use either :python or :py3 to avoid > problems mixing the shared library. Is there a better solution? I hope > you can come up with something really soon, since we are getting very > close to the 7.3 release and I don't want to risc making changes that > could crash Vim. > > -- > hundred-and-one symptoms of being an internet addict: > 26. You check your mail. It says "no new messages." So you check it again. > > /// Bram Moolenaar -- b...@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_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
Re: Vim 7.3: Python3 support
Hi Bram,
That's good news to me.
I'll check the sources and look into the crash as soon as possible.
Roland
b...@moolenaar.net schrieb am 25.07.2010 14:24:18:
> Von: Bram Moolenaar
> An: Roland Puntaier
> Kopie: vim_dev@googlegroups.com
> Datum: 25.07.2010 14:24
> Betreff: Vim 7.3: Python3 support
> Gesendet von: b...@moolenaar.net
>
>
> 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]
>
> /// Bram Moolenaar -- b...@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_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
Re: Planning Vim 7.3: Python3 support?
vim_dev@googlegroups.com schrieb am 29.04.2010 14:59:57: > "Edward L. Fox" > Gesendet von: vim_dev@googlegroups.com > > > On Thu, Apr 29, 2010 at 20:27, Bram Moolenaar 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. 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. Cheers, Roland -- 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
Re: :python print sys.version reports 2.5.1 instead of 2.6.2
vim_dev@googlegroups.com schrieb am 24.09.2009 17:18:37: > > Hi, > > the question is at the end of this post, after the rather lengthy > intro. :) > > I am on OS X 10.5.8. I have 2 version of Python installed. The default > one provided by Apple, Python 2.5.1. And one I installed from > MacPorts, Python2.6.2. > > The MacVim snapshot is built against Python 2.3.x. So I had to build > my own version of from source. I followed the instructions on the > MacVim wiki to build MacVim.app with one exception. I want to build > against 2.6.2. So I did this: > > ./configure --without-x --disable-gpm --disable-nls --with- > tlib=ncurses --enable-multibyte --enable-rubyinterp --enable- > pythoninterp --enable-gui=macvim --with-python-config-dir=/opt/local/ > Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config > && make > > This picks up Python 2.6 during the configure and builds the "vim" > binary. If i start the newly built version of Vim and do: > :python import sys; print sys.version > > it reports this: > 2.5.1 (r251:54863, Jun 17 2009, 20:37:34) > [GCC 4.0.1 (Apple Inc. build 5465)] > > So, my question is, why does it go to 2.5.1 is there any way to force > it to use 2.6.2? Alternatively, how does vim choose which version of > python to use when one runs ":python" The auto/configure script uses python to find out certain information. So set the path such that it will find the python you want it to find. Then you also don't need to specify --with-python-config-dir. Also: look into the src/Makefile. There is a good description about your options. ... and I had another look into auto/configure: you can override vi_cv_path_python in the shell. One among many good things about open source: you can have a look and find out by yourself. Roland --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: :python print sys.version reports 2.5.1 instead of 2.6.2
vim_dev@googlegroups.com schrieb am 24.09.2009 17:18:37: > > Hi, > > the question is at the end of this post, after the rather lengthy > intro. :) > > I am on OS X 10.5.8. I have 2 version of Python installed. The default > one provided by Apple, Python 2.5.1. And one I installed from > MacPorts, Python2.6.2. > > The MacVim snapshot is built against Python 2.3.x. So I had to build > my own version of from source. I followed the instructions on the > MacVim wiki to build MacVim.app with one exception. I want to build > against 2.6.2. So I did this: > > ./configure --without-x --disable-gpm --disable-nls --with- > tlib=ncurses --enable-multibyte --enable-rubyinterp --enable- > pythoninterp --enable-gui=macvim --with-python-config-dir=/opt/local/ > Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config > && make > > This picks up Python 2.6 during the configure and builds the "vim" > binary. If i start the newly built version of Vim and do: > :python import sys; print sys.version > > it reports this: > 2.5.1 (r251:54863, Jun 17 2009, 20:37:34) > [GCC 4.0.1 (Apple Inc. build 5465)] > > So, my question is, why does it go to 2.5.1 is there any way to force > it to use 2.6.2? Alternatively, how does vim choose which version of > python to use when one runs ":python" The auto/configure script uses python to find out certain information. So set the path such that it will find the python you want it to find. Then you also don't need to specify --with-python-config-dir. Also: look into the src/Makefile. There is a good description about your options. Roland --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: inquiry regarding vim patch to support python3 interface
Aaron Griffin schrieb am 23.09.2009 21:52:51:
> On Wed, Sep 23, 2009 at 6:54 AM, Bram Moolenaar
wrote:
> > Roland Puntaier wrote:
> >
> >> I hope you can add this to the trunk: I supports now both python 3.x
and
> >> python 2.x.
> >
> > Wow, this is a big patch. Thanks for all your work.
>
> Agreed. Thankfully, my part in this is small.
>
> Roland, I know you copied pythoncomplete to python3complete, but were
> any additional changes made? I'd be happy to add in support for
> has('python3') to the existing script if it were more clear what
> actually needed to be done.
I made adaptations necessary to make it work with python3, so no immediate
work is required.
But it seems you are improving your pythoncomplete from time
to time and it would be good if you could take into that process
python3complete as well.
cheers, Roland
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: inquiry regarding vim patch to support python3 interface
b...@moolenaar.net schrieb am 23.09.2009 16:33:27:
>
> Roland Puntaier wrote:
>
> > > In the source code changes I notice you now define FEAT_PYTHON3, but
> > > there is no FEAT_PYTHON2. I would think we need both, since we can
have
> > > Vim with:
> > >- only Python 2 (current situation)
> > >- only Python 3 (future)
> > >- both Python 2 and 3
> >
> > FEAT_PYTHON corresponds to FEAT_PYTHON2. You could rename it.
>
> Aren't there multiple places with
>
> #if defined(FEAT_PYTHON) || defined(FEAT_PYTHON3)
>
> I think having FEAT_PYTHON for any version avoids confusion.
Actually I found only two places where we have something like that.
I'd rather regard them as two separate interpreters, just like
there is FEAT_PYTHON and FEAT_PERL, there can be FEAT_PYTHON and
FEAT_PYTHON3.
OK one could rename FEAT_PYTHON to FEAT_PYTHON2, but I think that is not a
good idea either.
FEAT_PYTHON corresponds to the PYTHON make variable or the vim
has("python"),
and to change any would not be backward compatible to existing build
scripts (like in gentoo)
or vim scripts.
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: inquiry regarding vim patch to support python3 interface
Hi Bram, > In the source code changes I notice you now define FEAT_PYTHON3, but > there is no FEAT_PYTHON2. I would think we need both, since we can have > Vim with: >- only Python 2 (current situation) >- only Python 3 (future) >- both Python 2 and 3 FEAT_PYTHON corresponds to FEAT_PYTHON2. You could rename it. cheers, Roland --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Fwd: inquiry regarding vim patch to support python3 interface
Hi Bram, > - When Vim was compiled with Python 2.x ":py3" gives an error > - When Vim was compiled with Python 3.x ":python" gives an error > - When Vim was compiled with both 2.x and 3.x both commands work or put differently: if (command starts with :py) - following digits are interpreted as part of the command and an error results if the command is not available - this entails that a :pyxxx command must end in non-letter and non-digit (but still allows '.',',','+',...) And we accept the potential problems mentioned earlier. If that's fine for you, it's fine for me, too. I will do the changes and send a patch to vim_dev. Roland b...@moolenaar.net schrieb am 03.09.2009 13:13:27: > > Roland Puntaier wrote: > > > Hi Bram, > > > > > Having two Vim executables is a bad idea. Next you have two versions of > > > Perl, small and big features, etc. You end up with many different Vim > > > executables. It's better to try and have one executable. > > > > OK, let's have both python2.x and python3.x. > > > > But let's get a common understanding first. > > Then, if you feel comfortable to integrate that in the official sources, > > I can do the changes needed. > > > > > It's a lot easier if the Python script itself specifies what version of > > > Python it is for. E.g., by something in the first line. Then one can > > > use the ":python" command and get an error if the Python version doesn't > > > match. If it would be possible to build Vim with both Python 2.x and > > > 3.x then it would always work. > > > > Now I understand what you mean: > > the vim python command gets dispatched to a C function that pre-scans to > > see > > which python version to use > > and then calls the according ex_python() or ex_python3() C functions. > > > > First thought: For single line statements one could use a simple "3" to > > decide. > > But note: '3+X' is a valid python expression which could change X. > > Lagacy ':python3+X' would then suddenly be forwarded to python3 as '+X', > > which is also valid. This could all get undetected. > > > > So 3 cannot be used to distinguish. > > Hmm, annoying. We should have required white space after the command. > We could require that now. That still has the problem that this is > valid: ":python3 +X" > And would be interpreted in current Vim as ":python 3 +X" > But do we really care? > > I actually can't think of a useful Python command that starts with 3. > You can have a valid command like ":py3+4", but it has no effect, so it > should not actually be used. Is there anything else than an expression > that starts with the number 3? > > To be as backwards compatible as possible, we would require white space > after ":python3", but ":pythonXXX" would still be accepted. XXX would > need to start with a non-letter, but not a 3. To stay on the safe side > we should not accept any number. > > > And anyway, there is no big difference from script solution to having two > > commands. > > (Please comment) > > > > > > I suggest a new command for python 3. > > > > My favourite currently > > :PYTHON > > I know that this is contrary to the policy to use small letters for > > builtin ex commands, > > but :py3 and :python3 would have problems like the one mentioned above. > > (:_python possibly would do, too.) > > (please comment) > > Upper case letters are reserved for user commands. Breaking this > convention makes things too complicated and confusing. > > An alternative would be ":pythonthree". But that looks ugly. > ":pythree" is not nice either. > > Perhaps we should use ":py3", with the requirement that white space > follows. It's not perfect, but probably the best compromise. > Is ":py_3" better? Looks strange. > > - When Vim was compiled with Python 2.x ":py3" gives an error > - When Vim was compiled with Python 3.x ":python" gives an error > - When Vim was compiled with both 2.x and 3.x both commands work > > > -- > hundred-and-one symptoms of being an internet addict: > 179. You wonder why your household garbage can doesn't have an > "empty recycle bin" button. > > /// Bram Moolenaar -- b...@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_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Fwd: inquiry regarding vim patch to support python3 interface
Hi Bram,
> Having two Vim executables is a bad idea. Next you have two versions of
> Perl, small and big features, etc. You end up with many different Vim
> executables. It's better to try and have one executable.
OK, let's have both python2.x and python3.x.
But let's get a common understanding first.
Then, if you feel comfortable to integrate that in the official sources,
I can do the changes needed.
> It's a lot easier if the Python script itself specifies what version of
> Python it is for. E.g., by something in the first line. Then one can
> use the ":python" command and get an error if the Python version doesn't
> match. If it would be possible to build Vim with both Python 2.x and
> 3.x then it would always work.
Now I understand what you mean:
the vim python command gets dispatched to a C function that pre-scans to
see
which python version to use
and then calls the according ex_python() or ex_python3() C functions.
First thought: For single line statements one could use a simple "3" to
decide.
But note: '3+X' is a valid python expression which could change X.
Lagacy ':python3+X' would then suddenly be forwarded to python3 as '+X',
which is also valid. This could all get undetected.
So 3 cannot be used to distinguish.
And anyway, there is no big difference from script solution to having two
commands.
(Please comment)
I suggest a new command for python 3.
My favourite currently
:PYTHON
I know that this is contrary to the policy to use small letters for
builtin ex commands,
but :py3 and :python3 would have problems like the one mentioned above.
(:_python possibly would do, too.)
(please comment)
Roland
b...@moolenaar.net schrieb am 27.08.2009 14:17:34:
>
> Roland Puntaier wrote:
>
> > to embed both python 2.x and python 3.x in vim is possible (See PSS)
> >
> > But I am not really convinced that this is necessary.
> > With the current implementation one already has the possibility to
> > either compile the code with python 2.x or with python 3.x.
> >
> > One can do the forking in the system by making two vim executables
> > and name one differently.
> > There is no need to duplicate the other vim files.
>
> Having two Vim executables is a bad idea. Next you have two versions of
> Perl, small and big features, etc. You end up with many different Vim
> executables. It's better to try and have one executable.
>
> > In scripts one can do something like this (see also PSSS)
> > (from pythoncomplete.vim attached in this mail):
> >
> > py << PYTHONEOF
> > import sys
> > vim.command("silent let g:python_hexversion = %i" %
sys.hexversion)
> > PYTHONEOF
> >
> > function! s:DefPython()
> > if g:python_hexversion < 0x0300
> > python << PYTHONEOF
> > ...
> > PYTHONEOF
> > else
> > python << PYTHONEOF
> > ...
> > PYTHONEOF
> > endif
> > endfunction
> >
> > And normally it is not a big deal to convert the python code to
python3.
> > The necessity to do something might speed up the convertion of
existing
> > scripts.
>
> Don't underestimate how much effort it is to do the conversion for
> someone who doesn't know Python. Very often scripts are abandoned by
> the original author and it's up to the user to make it work again.
> It's a lot simpler if old scripts still work.
>
> > The executable versions would have python2.x embedded until the time
has
> > come to change that, too.
> > If somebody uses python with vim he probably will also be able to
compile
> > vim by himself.
>
> Python is often used as part of extensions by people who don't know
> anything about Python.
>
> > To include both in the sources allows those to do so more easily,
> > because vim sources change and the python3 patch might not be
appliable
> > any more in the future.
>
> Unfortunately the embedding of Python in Vim has had its incompatibility
> problems. But with a series of #ifdefs one can make it work.
>
> > Up to now I did't have any problem with the python3 patch. It should
be OK
> > to include in the trunk.
> > The only difference I know about: vim.current.buffer.mark(b'<') intead
of
> > vim.current.buffer.mark('<').
>
> [...]
>
> > pythoncomplete.vim is part of the vim sources, but not yet adapted to
> > python 3 in the above patch.
>
> Hmm, so we need to maintain two versions of pythoncomplete.vim?
> At least for the Python part of it.
>
> >
