On 16/01/14 07:07, Tony wrote:
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.
<blush /> I'm not a "core Vim developer"; in fact AFAIK I'm not a "Vim
developer" at all. I've written a small script or two, but Dr. Chip
wrote much more than I did, and he goes on fixing them when bugs are
found, or staying abreast in changes in Vim; and of the C code I've
written exactly zero lines, "zilch, nada, nothing". Bram of course wrote
most of it but there are a number of other people who've been fixing
bugs in the binary.
I don't feel different from any other Vim user. I've been using Vim
since release 6.1 which means I'm neither among the newest nor the
oldest players at this game. What I mostly do when I'm around is
answering other users' questions, when there is one to which I think I
know the answer and which hasn't yet been answered by someone else. And
only after sorting all my incoming email, which takes me quite some time
even though (summarily) handling spam goes comparatively quite fast.
Yes, it is true that "how to code Vim" is rather sketchily documented
compared to "how to use Vim". But OTOH most users' questions turn around
"how can I this kind of edit by means of Vim?", not around "where in the
code do I find how Vim does that specific thing?" and indeed, the best
way not to get "left out of the loop" is to describe some editing task
you haven't succeeded to do, even after searching the help (if your
question show that you didn't properly search the help, you will still
be answered, and not insultingly — we all at one time had trouble
finding the help paragraph we needed — but maybe tersely by a short
sequence of :help commands telling you where the answer is to be found).
In many cases a single editing task can be achieved by means of several
different commands or sequences of commands, and IMHO that's part of the
beauty of Vim; but I still mean a pragmatic question about a concrete
editing task; if you ask "how do I make Vim behave like Emacs?" (or
"like MS-Word", for that matter) you're bound to be treated like a troll
— i.e., probably left without an answer, or maybe sneered at.
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?
Hmm, that wouldn't be easy stuff.
I think that those internals which happen by means of Vim scripts (such
as: syntax highlighting, keymaps, menus…) are already documented, mostly
in the help, sometimes at vim.wikia.com, or maybe both; but the
internals of the C (and similar) code, well, well, well, I for sure
wouldn't know where to begin, and I'm sure that the people who would
know what to say about what have better things to do: Vim is a purely
volunteer project, remember, with the possible exception of one day per
week Bram gets off from his other chores at Google to let him work on Vim.
And all volunteer projects have one thing in common: NO OBLIGATION. The
only way to make sure that a bug gets fixed is to fix it yourself, or,
if you don't know how to, to first learn how to and _then_ do it
yourself; but getting the necessary knowledge may require resources
which aren't there, or not yet, so one RFE or bug report might spawn a
number of additional RFEs about developer documentation — and that may
take years. Did I say "years"? Maybe "decades" would be closer to the
mark. So, yes, me too I'd like to know how Vim works internally, but I
don't want it badly enough to follow the execution path (and all its
possible branches) all around the source. Do you? Probably not. So I
suppose all you or I can do about it is hope, or silently pray, that
someday some developer (or, more likely, several of them) will have the
good idea to write some good developer documentation about the
organization of Vim's C code. If they don't, it doesn't mean we're left
out of the loop, it just means there is no "loop", i.e., no one has at
the same time the time, the expertise and the willingness to do anything
about it.
Best regards,
Tony.
--
There once was a lady from Kansas
Whose cunt was as big as Bonanzas.
It was nine inches deep
And the sides were quite steep --
It had whiskers like General Carranza's.
--
--
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.
