2017-07-22 3:11 GMT+09:00 Christian Brabandt <[email protected]>: > > On Fr, 21 Jul 2017, Mario Krajačić wrote: > > > Hello, > > > > I am student of IT from Croatia on finishing year for my bachelor's > degree. > > > > For the graduate thesis I would like to contribute some open source > project. For example it can be some bug fix. Language in I work is C. My > knowledge is shown in programs on git profile: https://github.com/mkrajaci > > > > Project which I choose will be sent to my professor - mentor who will > approve or not difficulty of project. > > > > Please advice me about how to help you and choose right project. > > Hi, > welcome to this community. We really appreciate if someone wants to > contribute. However, please note, this is a mature OpenSource project > that has been under development for over 25 years. That means, although > we are using git, we do not follow the github workflow much. Usually > patches are committed by Bram, acknowledging the author in the commit > message (therefore you'll see only one contributor at > https://github.com/vim/vim/graphs/contributors). > > You can create PRs at github and the automatic continuous integration > system will test that PR against the normal test suite, but they wont > get merged. Everything is handled by Bram as the project maintainer. > That also means, that Bram is very busy, so he might not react or review > immediately, so please be patient and the rest of us will try to comment > and give helpful advises. > > That does not mean, that patches are not appreciated, so do not let that > scare you! > > As for what could be done, this depends on your C-skills and the amount > of time you want to spend. The link to the todo list has already been > given. However, here are some things that come to my mind, where Vim > could need some improvements: > > - Make the gvim prettier >
One of the ways for making things easier to attain that purpose would be to separate GUI initialization and layout from core logic as much as possible, e.g., conversion from a pure C program https://developer.gnome.org/gtk3/stable/ch01s02.html into a combination of a piece of C code for the core logic and another piece of code to define the default resource values and describe the initial layout of the GUI https://developer.gnome.org/gtk3/stable/ch01s03.html, though there's effectively no core logic in this example, actually :) Because prettiness is more or less a matter of taste, it could be much better to provide a way to make the UI "prettier" with ease whenever necessary rather than aiming directly at prettiness itself. The separation is obviously helpful for that purpose (and more mentioned below :) For popups such as various dialogs, this should be done with ease. For the main UI, you would need to make GtkForm (Historical misnomer. That's Vim's own custom layout widget, actually) gtk-buildable so that it can easily be incorporated into an XML description. Furthermore, if you could make the main UI a subclass of GtkApplicationWindow (plus, replacement of gtk_main() with g_application_run()), then the GTK+3 GUI would be smoothly converted into the one for the coming GTK+ 4 with little effort, which would be much appreciated by the community. > - Implement smooth scrolling > Scroll consists of copy and repaint. Different operations happening at different places at different times, initiated by different entities. How can we make those operations seamless? There's no trivial answer. People often talk about double-buffering to attain that. But, does it actually work just as described in abstracted manners in textbooks on a given, actual windowing system on a given hardware? Can we fully take advantage of hardware's direct rendering though a GUI toolkit which is designed to work for various platforms? I think all those are good for undergrad thesis subjects (Actually, some of them might be grad level or even appropriate for dissertation, though they are not "modern" :). Oh, probably I need to mention use of cache, too. That could be useful to implement smooth scrolling. At the same time, however, we also need to care about loading time for huge files getting longer and all jump commands such as G losing their swiftness due to cache creation or update. Will people really like Vim more if it gives smooth scrolling like browsers at the cost of the current file loading and cursor jump behaviors as fast as lightning? That question makes the issue really tricky to address. Surely, anyone who is willing to challenge those issues as well as the ones mentioned by other people is always welcome and her/ his work is definitely appreciated. Best regards, Kazunobu - Drop dependency on external diff > - Implement missing VimScript API for e.g. :signs, :digraphs, (there are > probably more features, for which no native VimScript functions > exists) > - Analyse and profile Vim identifying bottlenecks and try to come up > with improvements (e.g. relativenumber and cursorline are known to be > slow. What could be done to improve performance here?) > - Make concealing work better. (e.g. mouse clicking does not take > concealed characters into account) > - See more here: http://vim.wikia.com/wiki/Vim_contribution_Ideas > > So if you want to work on Vim, you should make yourself familiar with > the Code base hang around here at vim-dev and at the github issue > tracker and try to reproduce problems and find out how to fix them. > There should be a couple of easy to reproduce bugs on the issue tracker. > That will help you getting an understanding of how the Code works and > will help us acknowledge that you really want to contribute ;) > > Oh and sorry for the long mail I usually do not write such long mails. > > Best, > Christian > -- > Die Menschen - dies beweiset die Liebe der Kinder - werden nicht zu > den Menschen erst hingewöhnt, sondern nur spät(er) von ihnen > abgewöhnt. > -- Jean Paul > > -- > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
