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

List:       vim-dev
Subject:    RE: Vim's future ?
From:       Bram Moolenaar <Bram () moolenaar ! net>
Date:       2002-11-06 10:55:00
[Download RAW message or body]


Philippe Fremy wrote:

> > > I am not sure I understand everything you explain. But instead of adding
> > > more complexity to the current vim framework, I would prefer to see it
> > > simplified and more cleanly abstracted.
> > 
> > Hmm, isn't "not adding more complexity" in contradiction with adding an
> > API?  Adding an API is lots of work and will make the code more complex.
> 
> Yes it might be a lot of work. No, it won't make the code more complex. Yes,
> you must draw the line somewhere for the API. But once the line has been
> drawn, code is actually simpler.

You apparently have a very optimistic view of this API.  My experience
with APIs is that they are complicated to design and maintain.  An API
will make the code more complicated, adding something never makes it
easier.  The user of the API will be happy, of course, because he has a
nice interface to use.

> You know that if you use the API, you won't
> get any bugs. You know that fixing a bug for a given feature only requires
> studying a small set of functions, not browsing through the entire vim
> source to look for all the places where this feature might be used.

Adding an API doesn't change anything about the work that needs to be
done, the data structures, etc.  Thus the arguments you mention here are
not true.

> > Actually, the Vim Normal mode and ":" commands are an API.  It already
> > exists and is well documented.  What do you need another API for?
> 
> Sometimes, they might interfere with the user. But else, yes, it is a
> stable API which we are using.

Well, until it becomes clear what is really wrong with it, let's just
use what we already have.

> > > - a top window that can contain a menu bar, a tool bar, a status
> > > line and a view (simple or composed).
> > > 
> > > The window would be completly independant of a view, which itself
> > > would be completely independant from a buffer. You need a clean
> > > API to access buffers and views. That way you can have as many
> > > windows or views as you need, without any API modification.
> > 
> > You can't make these things independent.
> 
> By independant, I meant "that communicate using clearly defined API".

If you look into the data structures of the window and buffer and how
they are used, you will find out it's extremely difficult to define an
API that separates them.  I don't see the use for that API, thus let's
not waste time making it.

> > I really don't see how this is different from how Vim already works.
> 
> great. Then the only thing we need is to be able to use this without the
> rest of the vim framework.

Eh?  What "rest"?  What "framework"?  Don't you just mean you want to
add a few #ifdefs to compile Vim with less features?

> Mmh, I know one more thing we need, that vim currentely does not provide:
> non-blocking event loop. We need to be able to say to vim "here is the key
> typed by the user. Analyse it, treat it, do whatever you can and then give
> me the control back. I'll give you the next key when the user types it".
> This is a deep vim modification.

No, it already works that way.  Take a good look at the Win32 GUI code.
It uses an inputbuffer and gui_wait_for_chars() is the central function
that gives control back to the GUI.  In Win32 that's done with a call to
GetMessage().  I would be surprised if KDE doesn't have something
similar.

This is different from how a "normal" GUI application works, thus it
requires a bit of thinking and perhaps experimenting to make Vim work
with a GUI.  It has always been possible until now.  I would be
surprised if KDE is so different it wouldn't work at all.

> > One important difference from how most applications work, and
> > makes it difficult to use the "standard" solution, is that messages
> > scroll up from the bottom and push the windows/views upward.  Can't
> > change this without losing the "vi look&feel".
> 
> It should be possible, instead of saying "scroll text five lines up, then
> display those five lines", to have an API in gui for "display those five
> lines" and let the gui choose if they want to scroll up or not.

You are missing the point.  To be able to show those five lines, the
separator of vertically split windows has to be scrolled up as well.
That might be very tricky when using a widget.  It's not up to the GUI
to decide to scroll up or not, the scrolling must be done do get the Vi
look&feel.  You might do it with an overlapping window that resizes to
fit the message text, but it would still look different.

-- 
CART DRIVER: Bring out your dead!
LARGE MAN:   Here's one!
CART DRIVER: Ninepence.
BODY:        I'm not dead!
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 ///  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]