> yet another wiki
Well yes - but its also "minimal" only offering features I think are
important:
- feature matrices.
- edit with vim
- git
- and simple way to contribute (online editing without accounts)
Of course its "my view on things". But its what adds values beacuse it
makes it easier for people to get an idea about differences. I know that
this will never be accurate.
And yes - I'd love to make the wiki "official" one day - but I also had
to find a way to document some things only once so that I can reference
them.. I welcome everybody to join - and everybody who wants can get
push access (I even randomly added maybe 100 people who had some viml
code on their repositories).
If you download "ruby debugging plugins" and you notice than that you
cannot even step 5 times - then you get an understanding about what
could be all wrong.
> And this kind of documentation *does add value*. It is crucial in making
> sure that a developer understands the context of any fix/enhancement
> before attempting the fix. It ensures that any change has the highest
> chance of working properly and integrating with surrounding sub-
> systems with minimum breakage and/or regression, which increases final
> acceptance probability and allows more good features to be integrated
> (e.g. timers, background task queues, multiple language bindings, etc).
> Just start reading the code. Some of those subsystems implement their
> own threading, because Vim does not.
I agree that I didn't work much with vim's source code. What I did is:
- try figuring out how to improve the async patch for vim (which was non
gui only) - figuring out that adding gui support would be pain in the
ass (more work than I would have time for).
- trying to understand interrupt handling on linux - wondering why
ctrl-c interrupts are not used to cancel viml or py or ruby.
Then abort a endless python/ruby loop would be trivial.
And I started the "why vim sucks" page because I've learnt a lot of
details later (after implementing python,ruby,scala repl, xdebug
suppport, ruby debug ide, rdebug and pdb support)
You can find those implementations on my github page.
It works just good enough, but sometimes there are issues.
Developing them was "pain in the ass", because if you send data to viml
using client server you don't see errors which happen in viml code and
the like. Maybe I just did everything wrong ..
> For those who have worked on any properly organised project, Open
> Source or not, having an overview of *how the code was designed*
> and *how it works* is more important than just "understanding code".
Its not only about Vim, its also about "organizing the communtiy"
The project also fails horribly here.
There are many wikis because there is no "true single one satisfying
needs". I just don't want to contribute to web forms only. I don't want
to read wikis full of ads (even though I could login).
I've spend much time on writing VAM - just to learn - that people still
reinvent the wheel (eg NeoPlugin, vundle, some more). In the NeoPlugin
case the new plugin was written due to "lack of knowledge about VAM".
Finally it does add some additional features VAM does not provide
(parallel installation) - doesn't change the fact that I would have been
willing to collaborate in the first place.
> For example, the Linux kernel, which I have developed and debugged
> as part of my job, has a "readme.txt"-style file for every logical sub-
> system.
Many kernel devs get payed for working on the kernel.
Vim users get payed for writing (non vim) code or text usually.
> 1) an overview of how code is executed from upper layers, how lower
> layers are called, and a *logical* data-flow description (e.g. key strokes
> are passed in via X and processed by Y", or "disk buffers come in
> through x.c and are queued using y.c". References to code-level
> structures are also made to familiarise the developer with the headers.
There are 2-3 event loops - two implementations for vim, and at least
one gtk for gui (maybe more). The main issue is that when you write
for i in range(1,2000)
echo 'x'
vim may arbitrarely stop executing the for loop (eg every X hundered
iterations) - to look for ctrl-c. The problem when looking for ctrl-c is
that in gtk mode Vim has to run the event loop of gtk - which in turn
processes resize events, which in turn can trigger arbitrary viml code
*while* your for loop is still executing. Thus your vim may behave like
this if you're unlucky:
for i in range(1,2000)
if (i % 200)
run au command resize
echo 'x'
Getting this right might require introducing threads - which in turn
would require rewriting much code.
And that is one of the reasons (another one Vim being written in C)
makes it somewhat hard for me to get started because I know it would
take me a couple of weeks eventually.
And if you truly want to start using async features, eg client-server,
then additional questions arise such as "is it ok to process async
requests if you're in command window?" ...
But there is more to it: if_* interfaces differs greatly in features.
Anyway, if somebody wants to get started why not.
I started this bitbucket community repository which could be used for
sharing patches code, documentation:
https://bitbucket.org/vimcommunity
bitbucket supports both mercurial and git.
If somebody wants to be added as admin or such just drop me a line.
Yes - its again "just me having had this idea" - but maybe we can move
more community maintained stuff there. At least it solves the risk of a
maintainer becoming unavailable - because others can take over and add
comments ensuring upstream. I'm not sure how well github does solve this
(unless there are multiple maintainers).
The most important questions are:
- how much benefit could happen if we rewrote Vim from scratch?
(Eg what about having vim in browser without lvm C to JS terminal
emulation)
- How much "old code/backends" could be dropped today?
- which of vim's futures are most important, and which are less
important?
- what about 0 bytes in strings (viml)?
Yes - xdebug does uses them in its protocol.
My workaround was to encode "ab\0c" as ["ab", "c"]
- ..
Marc Weber
--
--
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.
