About Internationalization project
Nisha Chaudhari
We are Final year students of COEP. We are trying to fix rendering problems in Indic script in gvim. Can you please help us with compiling gui files in vim source code?
Thanking you.
Marc Weber
If you're a final year student you should be a able to give more details
about your trouble. Eg you should at least include: operating system and
compilation failure.
Just asking for help is not enough. Nobody will be able to help you this
way. That's my impression about your request.
Marc Weber
Tony Mechelynck
> 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
Well, the Vim source is available for download. After reading
http://vim.wikia.com/wiki/Getting_the_Vim_source_with_Mercurial
and one of
http://users.skynet.be/antoine.mechelynck/vim/compile.htm (W32)
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm (Unix)
you should be able to compile an unmodified Vim: that's your first step,
to make sure you understand the procedures. (Use the vim73 branch of the
Mercurial repository to get bleeding-edge development sources.)
Since in this case you want your changes to apply to *any* GUI version
of Vim, I suppose that you could patch gui.h and gui.c (plus a few
others I suppose), and possibly (if you have a lot of new code) add a
new module, the way Nadim Shaikli did for Arabic script (which is now
supported by arabic.h and arabic.c, plus maybe some code in other
modules: look for ifdef lines testing FEAT_ARABIC).
If you add a new module, you will want to change the configure script
and all Makefiles (Make* in the src/ sirectory) to make sure that your
new module is included in the link when it was not excluded by an
incompatible choice of compile-time options.
Before you begin with the C code, be sure to read attentively the whole
helpfile develop.txt (see :help develop.txt) and maybe follow some
pointers found there. Also, starting before you start coding and
polishing up while you develop the code, be sure to write a help file of
the same high level of quality as the rest of the Vim help. This is
extremely important if you want your code to be accepted by the
community, and it will serve you as a kind of roadmap while you develop
the code.
And finally, after (and if) you write the code, compile it with various
sets of options (you will probably want to make your code an optional
feature, depending on FEAT_MBYTE i.e. +multi_byte) and if possible on
various platforms (ideally Linux-i686, Mac, Win32, Linux-x86_64 and
Win64 but maybe you won't have all the necessary hardware, not to
mention zOS) and test that it compiles and works the way you want it to,
including testing that no compile errors appear when the new feature is
present in the source but excluded at compile-time, you may want to
submit the fruit of your efforts as an "unofficial patch" to be included
with those at http://groups.google.com/group/vim_dev/web/vim-patches so
that the Vim community at large may test it, interact with you about
fixing any bugs they might find, and, who knows? maybe Bram will decide
to include it in the "standard" code for Vim 7.4 or Vim 8, the way many
of the existing "unofficial patches" have, after "baking" there for
months or sometimes years, been included in the source which will become
Vim 7.3.
Best regards,
Tony.
--
"If I had only known, I would have been a locksmith."
-- Albert Einstein