Similar previous post: https://groups.google.com/forum/#!searchin/vim_dev/internals/vim_dev/NDfhZs-364M/R1O4gD-uxksJ
This thread was made earlier, but never went everywhere. Sample response: > If you don't just want to spend your time on something you should > also consider talking about the reason causing your interest. > > Maybe there are faster ways to solve your problems (if any). > > Giving all context is a good idea always. I don't even know where to begin. And threads asking people to qualify what they probably *can't begin to articulate* because, *to fresh eyes*, I dare say, the code looks big. What does what? Even after a few months of peeking in and out of the source.. Is vim's source organized hackishly, are VIM's internals worthy of imitation? Is there a potential from reorganizing internals in some form in the future? On the other hand Tony Mechelynck was very helpful in this instance, I'm just sensitive to his / core developer's time. I feel left out of the loop, I know others do too. They feel they will be greeted with "Why's". Centralized, Internal docs, even in a broad sense, would be tremendously constructive. As an example I found very constructive before in open source: AOSA style, and take a look at the documentation on the headers of .C files in https://github.com/postgres/postgres. Can someone open a gist / wiki / create an INTERNALS.txt or doc file for developers to have a broad overview of how vim works internally? -- -- 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/groups/opt_out.
