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

List:       vim-dev
Subject:    RE: Vim's future ?
From:       Philippe FREMY <P.FREMY () OBERTHURCS ! com>
Date:       2002-11-05 18:06:32
[Download RAW message or body]


Bram said:

> 
> 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 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.

> 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.

> > The right architecture for vim is in my opinion a good doc/view one. If
I
> > would be designing it now, I would define:
> > 
> > - a set of buffer objects that vim can load. Each buffer has a text
inside,
> > a cursor position and a possible selection.
> 
> This is the "struct file_buffer", see structs.h.

good.

> > - a status line
> 
> Currently this is always part of a window.  You might say a window
> consists of a view and a status line.

indeed. I think it would make it easier to deal with.

> > - a view of a buffer. A view just renders the text contains in the
buffer
> > with nothing else.
> 
> That is a "struct window", see structs.h.

good.

> > - 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".

> The contents of a view is a
> buffer, thus when the buffer changes the view changes.  And when there
> are multiple views on one buffer they will interfere.  For example, if
> you change 'filetype' in one view the other view will also display the
> effect.  That's because 'filetype' is a buffer option, not a view
> option.  And when the toplevel window changes its size, the contained
> views also must change size.  There are dependencies like this all
> around.  That's what makes it so complicated.

This doesn't sound too complicated to me.

> 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.

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.


> 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.

Like most of the changes we need, it is only a matter of defining a lower
level or higher level abstraction than what vim currentely provides. Not a
10 man-year work :-)

	Philippe [ leaving now, see you tomorrow ]
[prev in list] [next in list] [prev in thread] [next in thread]