On 31/03/10 12:10, Nisha Chaudhari wrote:
Hi,
      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.

--
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

--
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

Raspunde prin e-mail lui