Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
(just in case anyone's watching this forum) - 0.8 of PythonScript has been released -
The highlights are that the startup bug that affected a few people has been fixed, and that there is no longer a dependence on the Visual C Runtime (vcredist). Python has also been updated to 2.7.
Here are the main changes:
- Fixed startup bug (many thanks to Stefan for helping track it down)
- Updated Scintilla wrapper to 2.21
- Added support for dynamic command IDs, for Notepad++ 5.8 and upwards (i.e. faster and safer menu processing)
- Updated to Python 2.7
- Removed Python's dependency on Visual C++ Runtime
- Added Python modules for SQLite, socket, XML and a few others
- Fixed bug with notepad.setStatusBar
- Fixed bug with notepad.runPluginCommand
- Fixed bug with clearing notepad callbacks from within a callback
Available from here http://npppythonscript.sourceforge.net/
Comments are of course welcome - if you spot any issues please let me know so they can be fixed before it goes out on Plugin Manager.
Is there a chance to get a python 3(.1) implementation, or, even better, use an arbitrary chosable own python installation to use for operation?
I would like to have a configuaration-option (wich by default points to your pythonxx.dll) to chose a python-installation to use.
3.x is very unlikely - unless someone wants to take up the challenge. The problem is that strings in 3.x are all unicode (so stored as wide char - "wchar_t"), and Scintilla (the edit component in Notepad++) stores all text as ANSI or UTF8 (so "char"), therefore I'd have to do all sorts of conversion magic whenever you sent text to Scintilla or retrieved it - not impossible, but I'm sure there are cases where it'd very be complicated. Maybe I or someone else will pick this up one day.
Arbitrary Python is, I believe, practically impossible. The library is linked at build time - sure, it is theoretically possible to use "LoadLibrary" and load it at runtime, however that complicates the code significantly, and, critically, it would need to be done for the boost::python library which PythonScript uses extensively to create the wrapper. That, is a challenge, to say the least, and probably not worth the hassle.
However, building PythonScript isn't actually all that hard - there's some notes in the help of 0.8, so it's reasonably straight forward, and you can do it all with free tools. Building boost::python is actually most of the work, making sure it's compiled against the Python source of your choice. Again, there's notes in the help of 0.8, and also the command lines to build boost::python with jam (the boost build tool) are noted in the Readme.txt in the repository.