Re: I want to contribute and chose right project for graduate thesis
2017-07-22 3:11 GMT+09:00 Christian Brabandt: > > 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.
[doc][patch] There is one extra closing square bracket in document
Hi Bram and all, Patch attached. -- Best regards, Hirohito Higashi (h_east) -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. diff --git a/runtime/doc/eval.txt b/runtime/doc/eval.txt index add95bc..cc7539f 100644 --- a/runtime/doc/eval.txt +++ b/runtime/doc/eval.txt @@ -2179,7 +2179,7 @@ index({list}, {expr} [, {start} [, {ic}]]) Number index in {list} where {expr} appears input({prompt} [, {text} [, {completion}]]) String get input from the user -inputdialog({prompt} [, {text} [, {completion}]]]) +inputdialog({prompt} [, {text} [, {completion}]]) String like input() but in a GUI dialog inputlist({textlist}) Number let the user pick from a choice list inputrestore() Number restore typeahead
An error on patch 8.0.0736
Hello, I found an error on patch 8.0.0736. With the following sample function, 'diffthis' and 'diffoff' will cause "E788: Not allowed to edit anoter buffer now" on 'wincmd'. augroup xyz au! au OptionSet * call XYZ() augroup END function! XYZ() if expand('') == 'diff' let c = winnr() for w in range(1, winnr('$')) exec w . 'wincmd w' echo w . ':' . endfor exec c . 'wincmd w' endif endfunction The error does not happens when I removed ++curbuf_lock; --curbuf_lock; in set_diff_option() of diff.c. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.0.0739
On 21-Jul-2017 07:05, Bram Moolenaar wrote: Patch 8.0.0739 Problem:Terminal resizing doesn't work well. Solution: Resize the terminal to the Vim window and the other way around. Avoid mapping typed keys. Set the environment properly. Files: src/terminal.c, src/os_unix.c, src/structs.h After this patch, my build fails on HPUX like so (ok on mingw): ... cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/os_unix.o os_unix.c cc: "os_unix.c", line 4082: error 1588: "envbuf_Term" undefined. cc: "os_unix.c", line 4082: warning 563: Argument #1 is not the correct type. cc: "os_unix.c", line 4082: error 1594: The sizeof operator cannot be applied to types with unknown size. cc: "os_unix.c", line 4082: warning 527: Integral value implicitly converted to pointer in assignment. cc: "os_unix.c", line 4082: warning 563: Argument #2 is not the correct type. cc: "os_unix.c", line 4082: warning 526: Pointer implicitly converted to integral value in assignment. cc: "os_unix.c", line 4082: warning 563: Argument #3 is not the correct type. cc: "os_unix.c", line 4083: warning 563: Argument #1 is not the correct type. *** Error exit code 1 Stop. *** Error exit code 1 Stop. New variable envbuf_TERM (line 4062) is referred to as envbuf_Term on line 4082. Please check the attached patch which attempts to fix it. Cheers John -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. --- os_unix.c.orig 2017-07-21 07:12:52.120032000 +1000 +++ os_unix.c 2017-07-22 05:55:45.875933500 +1000 @@ -4059,7 +4059,7 @@ # ifdef HAVE_SETENV char envbuf[50]; # else -static charenvbuf_TERM[30]; +static charenvbuf_Term[30]; static charenvbuf_Rows[20]; static charenvbuf_Lines[20]; static charenvbuf_Columns[20];
Patch 8.0.0740
Patch 8.0.0740 Problem:Cannot resize a terminal window by the command running in it. Solution: Add support for the window size escape sequence. Make BS work. Files: src/terminal.c, src/libvterm/src/state.c *** ../vim-8.0.0739/src/terminal.c 2017-07-20 23:04:42.967282191 +0200 --- src/terminal.c 2017-07-21 21:05:44.680468274 +0200 *** *** 572,578 { case CAR: key = VTERM_KEY_ENTER; break; case ESC: key = VTERM_KEY_ESCAPE; break; ! case K_BS: key = VTERM_KEY_BACKSPACE; break; case K_DEL: key = VTERM_KEY_DEL; break; case K_DOWN:key = VTERM_KEY_DOWN; break; case K_END: key = VTERM_KEY_END; break; --- 572,579 { case CAR: key = VTERM_KEY_ENTER; break; case ESC: key = VTERM_KEY_ESCAPE; break; ! /* VTERM_KEY_BACKSPACE becomes 0x7f DEL */ ! case K_BS: c = BS; break; case K_DEL: key = VTERM_KEY_DEL; break; case K_DOWN:key = VTERM_KEY_DOWN; break; case K_END: key = VTERM_KEY_END; break; *** ../vim-8.0.0739/src/libvterm/src/state.c2017-07-07 11:53:29.519876497 +0200 --- src/libvterm/src/state.c2017-07-21 20:53:39.117709279 +0200 *** *** 9,14 --- 9,16 # define DEBUG_GLYPH_COMBINE #endif + static int on_resize(int rows, int cols, void *user); + /* Some convenient wrappers to make callback functions easier */ static void putglyph(VTermState *state, const uint32_t chars[], int width, VTermPos pos) *** *** 1396,1401 --- 1398,1411 break; + case 0x74: + switch(CSI_ARG(args[0])) { + case 8: /* CSI 8 ; rows ; cols t set size */ + if (argcount == 3) + on_resize(CSI_ARG(args[1]), CSI_ARG(args[2]), state); + } + break; + case INTERMED('\'', 0x7D): /* DECIC */ count = CSI_ARG_COUNT(args[0]); *** *** 1534,1540 switch(state->mode.cursor_shape) { case VTERM_PROP_CURSORSHAPE_BLOCK: reply = 2; break; case VTERM_PROP_CURSORSHAPE_UNDERLINE: reply = 4; break; ! case VTERM_PROP_CURSORSHAPE_BAR_LEFT: reply = 6; break; } if(state->mode.cursor_blink) reply--; --- 1544,1550 switch(state->mode.cursor_shape) { case VTERM_PROP_CURSORSHAPE_BLOCK: reply = 2; break; case VTERM_PROP_CURSORSHAPE_UNDERLINE: reply = 4; break; ! default: /* VTERM_PROP_CURSORSHAPE_BAR_LEFT */ reply = 6; break; } if(state->mode.cursor_blink) reply--; *** ../vim-8.0.0739/src/version.c 2017-07-20 23:04:42.971282163 +0200 --- src/version.c 2017-07-21 20:50:36.835026706 +0200 *** *** 771,772 --- 771,774 { /* Add new patch number below this line */ + /**/ + 740, /**/ -- Some of the well known MS-Windows errors: ESLEEP Operator fell asleep ENOERR No error yet EDOLLAR OS too expensive EWINDOWSMS-Windows loaded, system in danger /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: I want to contribute and chose right project for graduate thesis
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 - Implement smooth scrolling - 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: I want to contribute and chose right project for graduate thesis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21-Jul-2017 11:16 +0200, 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. Hello Mario, Thank you for your willingness to support Vim. The source code (mostly C code) can be found at [1], this includes instructions for compiling on the various platforms. There are many enhancement requests and bug fixes to choose from :-) Have a look at the Todo list [2], and the issue tracker [3]. If you have any questions / need help, or want to get feedback before embarking on a bigger task, feel free to ask on this mailing list. [1] https://github.com/vim/vim [2] https://github.com/vim/vim/blob/master/runtime/doc/todo.txt [3] https://github.com/vim/vim/issues - -- regards, ingo -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJZcie0AAoJEA7ziXlAzQ/vqHIH/3FeouFptHQX5zXqMeUssYhC fGQOeazDuFix/Pws4GX0HfjG5xaMMvhud0pxNz06X+cZmyC2wlQpyycczxis+1Jb /of13w1RMOZZDLTbsustpvdsoO4bRnVTRdvKeJbn7Q4y6rRMjPTBsi+Nt20RuclD 9S3jnD9Pf0HACSMCmhDIKXCBVO/OcaaYcgX3/Jrw3swXsYng72D2ArtOuAUFXMLQ wZyViAgL3+XfYjJ1tKsQxz0YeM0/HMdWfeIlDgwVsYbBsXrbLE0pBR7qxvGgUI9n DDqZOSTW1ZCHTO+XFS4Q7qc4vduX4c6E4zaq/shGx2xP8syi7MLrHyOYqN8iOF4= =k/w6 -END PGP SIGNATURE- -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: I want to contribute and chose right project for graduate thesis
* Mario Krajačić[2017-07-21 12:54]: > 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. ... Please > advice me about how to help you and choose right project. sounds you are looking for this: "I Want 2 Do Project. Tell Me Wat 2 Do." by Shakthi Kannan 978-935196738-5 Hardback 136 pages 2015-06-01 http://www.shakthimaan.com/what-to-do.html enjoy! :-) as for the project.. choose one about the software you are using. ask on the relevant IRC channels. be sure about your timeframe. be realistic about your goals. keep a log about what you learnt. talk to your advisor often. Sven -- Vimfest 2017 on Sep22-24 Fri/Sat/Sun in Berlin 2017-09-22/24 Fr-Sa VimFest http://vimfest.de/ chat via web:http://tinyurl.com/vimfestchat chat via gitter: https://gitter.im/vimberlin/vimfest participation: http://doodle.com/poll/dadrizhcp9uevde8 -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch to add support for parsing lines using setqflist()
Hi, On Fri, Jul 21, 2017 at 3:13 AM, LCD 47wrote: > On 20 July 2017, Yegappan Lakshmanan wrote: >> Hi, >> >> On Thu, Jul 20, 2017 at 6:59 AM, Yegappan Lakshmanan >> wrote: >> > Hi, >> > >> > I am investigating a memory leak reported by valgrind with this >> > patch. >> > >> >> I am attaching an updated patch with the fix for this memory leak and >> additional tests. >> >> Once this patch is incorporated, output can be parsed using >> 'errorformat' and resulting entries can be added to any >> quickfix/location list by using setqflist(). > > Sadly, this still won't allow one to parse errors with errorformat > to a list in memory, disconnected from the stack. > > You see, the problem with the stack is that in order to use it in > a plugin beyond basic lolder / lnewer navigation, you need to assume > your plugin is the only one manipulating said stack. If another plugin > comes into picture and you try to accomodate it, it immediately becomes > an uphill battle. There is no way to keep track which loclist belong > to which plugin, and there is basically no way to tell the state of the > stack. > A plugin can associate a context with a quickfix/location list and also save the quickfix/location list number. By checking the context, the plugin can make sure that it is updating the correct list. Of course, this will work only if all the plugins start using/checking the context information before updating the quickfix list. > > The other plugin can add or remove entries, and there is no way > for you to detect that. You could look at the number of elements, but > once the stack gets full that number becomes useless. You could hook > to autocmds, but quickfix commands can be run silent. You could keep > track of the stack pointer, but the other plugin can play tricks with > the stack pointer too. In fact I'd be very curious to see a plugin do > something useful with the quickfix / loclist stack without asserting > exclusive ownership to it. As it is, it's simply too user-hostile. > > Ok, I'll crawl under my rock now, this is likely to be my last > message on this topic. > The current quickfix implementation is heavily tied to managing a list in the quickfix stack. I am incrementally making changes to unwind some of these dependencies and cleaning up the code. The support for creating and managing a quickfix list in memory is coming. - Yegappan -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
I want to contribute and chose right project for graduate thesis
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. * God bless 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 --- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch to add support for parsing lines using setqflist()
On 20 July 2017, Yegappan Lakshmananwrote: > Hi, > > On Thu, Jul 20, 2017 at 6:59 AM, Yegappan Lakshmanan > wrote: > > Hi, > > > > I am investigating a memory leak reported by valgrind with this > > patch. > > > > I am attaching an updated patch with the fix for this memory leak and > additional tests. > > Once this patch is incorporated, output can be parsed using > 'errorformat' and resulting entries can be added to any > quickfix/location list by using setqflist(). Sadly, this still won't allow one to parse errors with errorformat to a list in memory, disconnected from the stack. You see, the problem with the stack is that in order to use it in a plugin beyond basic lolder / lnewer navigation, you need to assume your plugin is the only one manipulating said stack. If another plugin comes into picture and you try to accomodate it, it immediately becomes an uphill battle. There is no way to keep track which loclist belong to which plugin, and there is basically no way to tell the state of the stack. The other plugin can add or remove entries, and there is no way for you to detect that. You could look at the number of elements, but once the stack gets full that number becomes useless. You could hook to autocmds, but quickfix commands can be run silent. You could keep track of the stack pointer, but the other plugin can play tricks with the stack pointer too. In fact I'd be very curious to see a plugin do something useful with the quickfix / loclist stack without asserting exclusive ownership to it. As it is, it's simply too user-hostile. Ok, I'll crawl under my rock now, this is likely to be my last message on this topic. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.