[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vim-dev
Subject:    RE: [kvim-dev] Re: Vim's future ?
From:       Bram Moolenaar <Bram () moolenaar ! net>
Date:       2002-11-13 21:57:43
[Download RAW message or body]


Philippe Fremy wrote:

> Just a few questions to satisfy my curiosity:
> 
> - are you the only one working on vim ? Do you have something like
> co-developers or regular contributors ?

I'm doing most of the work and the only one who has the final word on
what goes in and what doesn't.  There are several people sending me
patches at irregular intervals.

> - are the gui maintained by their author or are you the only one maintaining
> them ?

Originally all GUI implementations were done by others, but most of them
stopped maintaining their work.  That means I have to do it myself, or
ask someone to fix it and send me a patch.

Fortunately there are enough people that help me maintain the code.  But
some problems get fixed very slowly (see the todo list).

> > Vim doesn't specify the syntax for the font name itself, it uses
> > whatever is being used on the system it's running on. 
> 
> I think the gtk vim does use a specific font name syntax, so we tried to be
> compabible with that.

That's the ugly X11 font name.  It's OK to use this, but a font selector
is very useful then.

> Just curious, are you going to implement aap in a console mode too ?

Hopefully that will be possible.  But the GUI IDE will come first,
because it is what most people will want to use.  The Console mode IDE
is to be used in situations where a GUI won't be available, e.g., when
debugging on machine over telnet.  Not for a large audience, but
extremely useful for that audience.  I don't think there already is a
modular IDE for use in a console.

> > I'm afraid I don't know what you mean with a "Vim engine". 
> 
> This is an abstract vim library that we would feed with key-stroke and
> would tell us what to do. This is vim with the gui specific code
> teared apart. We would use that to put our own gui code on top of it.

If you put it like this, the Vim engine would be most of the Vim code,
still getting key strokes and mouse events for the text area, but
excludes the lower level UI stuff to display text and other items.
This should not be too difficult to make.  The interface could be
at the gui_write() function for displaying and around the input buffer
for key strokes.


[ About shifting files around to make the code more readable ]

It appears that you have learned a certain way to browse code, and
expect Vim to be approachable that way.  Since this apparently doesn't
work very well, you start suggesting that the Vim code should be
reorganised to fit your browsing methods.

I suggest to use my ideas for browsing the code: use ctags to find the
function definitions, that's where the comments are you want to read.
Use ":grep" to find where things are used.  I'm sure you can find your
the comments you are looking for, without the need to copy the comments
to other files.

> > And I still don't see the advantage, since you are just duplicating
> > the text. 
> 
> This is interesting for people that want to peek quickly through the code
> architecture, to have a better idea of what's inside a file and where they
> should be looking for.

I mostly use "]]" to jump to the next function.  If you really just want
to see the comments, use folding.

-- 
How To Keep A Healthy Level Of Insanity:
6. In the memo field of all your checks, write "for sexual favors".

 ///  Bram Moolenaar -- Bram@moolenaar.net -- http://www.moolenaar.net  \\\
///          Creator of Vim - Vi IMproved -- http://www.vim.org          \\\
\\\           Project leader for A-A-P -- http://www.a-a-p.org           ///
 \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
[prev in list] [next in list] [prev in thread] [next in thread]