Good evening, gentleman!Well, Vim 6.4 BeOS GUI code merged "back" into 7.2 sources. Some candies (GUI browse and dialogs) were newly implemented, available BeOS/Zeta/MultiByte/IME patches are harvested and applied, some BeBox Era anachronisms removed, nasty bugs fixed. Looks like here still lot of fixing work and future implementation of forgotten features but I hope somebody can find current version already useful. Patch for Vim release 7.2 sources was uploaded to HaikuPorts and available now here: http://ports.haiku-files.org/browser/haikuports/trunk/app-editors/vim/patches/vim-7.2.patch. Note, that I'll be very happy to read your overviews and suggestions on this changes. Note, that most of work was made by original vim BeOS porters. Unfortunately current version of beporter doesn't work with multiple source archives and cannot handle tar files compressed with bzip2 so you have to build with a bit manual work. Look into root Makefile for "BeOS/Haiku OS" build instruction. Happy building!
And as usual I have some questions. Sorry for a bit long quote from original BeOS GUI sources:
+ * Structure of the BeOS GUI code: + * + * There are 3 threads. + * 1. The initial thread. In gui_mch_prepare() this gets to run the + * BApplication message loop. But before it starts doing that, + * it creates thread 2 + * 2. The main() thread. This thread is created in gui_mch_prepare() + * and its purpose in life is to call main(argc, argv) again. + * This thread is doing the bulk of the work. + * 3. Sooner or later, a window is opened by the main() thread. This + * causes a second message loop to be created: the window thread. + * + * == alternatively === + * + * #if RUN_BAPPLICATION_IN_NEW_THREAD... + * + * 1. The initial thread. In gui_mch_prepare() this gets to spawn + * thread 2. After doing that, it returns to main() to do the + * bulk of the work, being the main() thread. + * 2. Runs the BApplication. + * 3. The window thread, just like in the first case. + * + * This second alternative is cleaner from Vim's viewpoint. However, + * the BeBook seems to assume everywhere that the BApplication *must* + * run in the initial thread. So perhaps doing otherwise is very wrong.
1) Is this "initial thread" restriction still actual for Haiku?
+ * However, from a B_SINGLE_LAUNCH viewpoint, the first is better. + * If Vim is marked "Single Launch" in its application resources, + * and a file is dropped on the Vim icon, and another Vim is already + * running, the file is passed on to the earlier Vim. This happens + * in BApplication::Run(). So we want Vim to terminate if + * BApplication::Run() terminates. (See the BeBook, on BApplication. + * However, it seems that the second copy of Vim isn't even started + * in this case... which is for the better since I wouldn't know how + * to detect this case.)
2) Personally I prefer to have running multiple instances of vim, but what is "ideologically" right? Note that currently only one binary executable of vim created during build process - all those gvim, evim etc. are just symlinks to single vim binary. As was already discussed here - starting any of them from Tracker will start GUI version of vim. Imagine, that we have marked vim as single instance application - how should open operations work from the Tracker in case we have _console_ session of vim already running? Has single instance launch any meaningful use for Haiku?
3) Finally we can do something with ticket 2887 ( http://dev.haiku-os.org/ticket/2887 ) Many people in comments to that issue say that they'll be happy to have vim as optional package. I have fixed some problems in building "tiny" and "small" versions of vim and now it is possible to save some space and use those reduced vim versions for basic Haiku distribution. Which set of features "is required" for "stock" version of vim in Haiku? What is your opinions? Are we need gui, menu, etc?
4) Have anybody something against if I update current version of vim on Haiku source tree from 6.4 to 7.2 and switch the build from "normal" to gui-less "tiny" or "small" version after the discussion about my question #3 will be finished with any decision?
5) As I can see, usual place for most of optional packages is haiku-files.org. Is it possible to put full featured Vim optional package on it? Who should I contact to provide all required information about build procedure?
Let stop now with any more questions and ...
... Good Night!
