[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-05 21:49:14
[Download RAW message or body]


Philippe Fremy wrote:

[seems I'm going backwards in time with these messages...]

> - vim is strongly tied to its current user interface:
> 	-> the processing of events is blocking. This was ok for a text only
> 	vim but it creates numerous problems for a gui vim or a vim
> 	component.

I don't really understand what you mean with "blocking" here.  Every GUI
normally handles one event at a time.  Vim does the same thing: waits
for a character, does something, then waits for the next.  GUI events
are handled just like characters.  Also note that Vim doesn't completely
block events while it's executing a command, gui_mch_update() is called
at irregular intervals.

It would be very difficult to change the event handling.  A GUI often
has an event driven loop, with some way to remember the current state to
decide what to do with an event.  Vim waits for a next character to be
typed in various places.  The place where this is done inherently
specifies the current state.  However, for all GUIs it was possible to
find a way around this, mostly by handling events and putting them in an
input queue.  This is not ideal, but it works.

Another solution would be to have the GUI stuff run in a separate
thread.  You would still need buffers to pass events between the two
threads, thus I don't see much advantage in this for simplicitiy of the
code.  The GUI behavior could be smoother though.

> 	-> wrong abstractions for gui stuff: Vim tries to define an abstract
> 	layer for every widget. The result is that the layer is as
> 	powerful as the poorest gui toolkit used.

Vim tries to provide the same features for all GUIs, but it's not really
true for everything.  For example, not all GUIs have a font selector.
The power available through the GUI is limited, mostly to avoid it
becoming too complicated.  GUIs tend to cost a _lot_ of code to make it
work nicely.

>	And most of the facilities of every
> 	toolkit can not be used. The use of the character '|' as a vertical
> 	splitter is nice for a text based vim, but completely strange in a
> 	graphical application.  All toolkits already have a splitter widget.

The reason for this is that most redrawing is common for the console and
the GUI versions.  When using GUI widgets for each window it would look
nicer, but you end up with having to implement the console stuff with a
semi-GUI.  That's lots of work for just making it look nicer.  Also,
performance and size is probably going to become worse for the console
version.

> 	-> it is very difficult to use vim as a gui component, without
> 	menu and toolbars.

Probably depends on what you expect.  I'm mostly using Vim in an xterm
thus without menus and toolbar.  It's difficult to distinguish this from
running Vim with a GUI with the menus and toolbar disabled.  The
scrollbars are the main difference (if they are enabled).  What is
special about a component that makes it difficult?  I can even imagine
using a terminal-emulator component with a console Vim running inside of
it.

> - some interfaces of vim are interesting but not versatile enough: I had the
>   problem when I wanted to use the quickfix mode with two different
>   program at the same time. Quickfix mode works with only one program
>   at the same time.  This is not the only place where vim has a an
>   interesting but too limited feature.

How would you use quickfix with two programs at the same time?  You can
use ":colder" and "cnewer" to switch between two error lists.  Is that
not sufficient?

> All these problems made it very difficult for us to use vim in
> KDevelop or in KDE. We had to use hacks and things are still not
> guaranteed to work properly.

Please explain every problem separately.  Otherwise I have no idea what
the real reasons are for the changes you propose.  Drastic changes
require well defined reasons.

> We have managed to have vim embedded into a Qt widget, but the focus is not
> working properly (a deep X problem).

This probably requires knowing a lot about the X event handling.  Don't
see how this is related to the design though.

> It looks very difficult for us to have two vim separate windows on the
> same text.

When there are two separate Vim instances, this should not be possible
(unless you make at least one of them read-only).  If it's in the same
Vim instance it should just work.  It's true that running two Vims to
get two toplevel windows has the limitation that you can't both show the
same file.

> The menu and toolbar must be explicitely disabled in the launching of
> the vim component: we must start it with
> 
>     "vim -g --cmd --servername <serverName> -c  source <kvimscript>
>       --cmd ':set guioptions-=m' -c 'set guioptions-=m' 
>       --cmd ':set guioptions-=T' -c ':set guioptions-=T'".
> 
>       As you see, one could hope for something cleaner.

Why not set 'guioptions' in the kvimscript file you are apparently
using?  Otherwise, Vim should be able to detect that it's being used as
a widget and to the things needed for that.

Don't you need something in that command to specify that Vim is to run
inside an existing window?

That first "--cmd" appears to be misplaced.

> One interesting stuff that we planned to do with the kvim component was to
> have it integrated into Kate (also named KWrite). Kate is a kind of
> generic text editor framework (like UltraEdit on windows). It manages
> all kind of things that are not directly related to editing a text
> file: agregating files into a project, grepping files, source control,
> ...  The editing part of a file is provided as a KDE editor component.
> It will be very difficult to use our vim component with Kate because
> of all the problems I already mention (and a few non vim related
> others).

The focus problem?  Then why do other editors (e.g. nedit, emacs, elvis,
joe) not have this problem?

> Honestly, I am thinking about starting a vi clone for KDE, because it would
> be easier to redevelop a vim from scratch using Qt than to modify the
> current vim to fit into what we need. However, I really prefer relying
> on a stable established reliable codebase, from the vim project
> itself.

I'm glad you prefer that.  Don't underestimate the work involved in
making something new (it would be lots of fun though).

> You may well say that you don't care about KDE (or Gnome) vim component. I
> find it cool to have vim available as a graphical editor component. It
> is like a second birth for the editor. And more importantely, this
> problem is more general than just the KDE vim component, which is why
> I am posting here. 

Agreed, I would very much like to see Vim used as a component in other
applications.  And it already works.  The Sun Workshop interface is the
most complete.  This does run Vim as a separate toplevel window though.

> What I suggest is to separate vim into three or more projects:

Here it starts going in the wrong direction.  You mention a few problems
that need to be solved, and then jump to the conclusion that a
completely different approach is needed.  I have not yet been convinced
that this drastic approach is justified.

It might be that what you are actually aiming at is improving the
internal interface with the GUI-specific things.  It might indeed be
possible to improve this.  But I think this is not a drastic change,
more like doing a bit of reorganisation and cleaning up.

> This core vim would fix the problem we had with the vim component. It
> should have a non-blocking event processing loop and should be easy to
> control entirely from another process.

This is a quite drastic redesign by itself.  Can you explain why this is
really needed?  The current solution works for all GUIs.

> 3. Vim framework:
> -----------------
> 
> This is where I would put all the features that do not belong directly
> to the previous parts. The quickfix mode and the grep mode would be
> implemented here for example. They would be implemented using the vim
> UI and the core Vim.

This sounds a lot like "it would be nice if...".  I don't see a real
advantage of splitting this off.  Actually, it's already mostly
separated by putting the code in quickfix.c.

> Vimdiff would also fit there. This part could probably be splitted
> into many plugins. Plugins would replace the selection of compilation
> options that vim currentely uses to determine its set of features.

Difficult, because the main work for vimdiff is to have all commands
handle filler lines and handling changes in the text while there are
diffs present.  And again, I don't see a real advantage of changing
this.

Overall I would say that the separation you propose is nice, but will
result in different problems than the current design.  Not necesarely
less problems.

> Currentely, vim is so monolithic that it is difficult to contribute
> without reading a lot of code.

It's not as monolithic as it might seem.  Although some cleaning up
would certainly be good, and some interfaces are not documented, the
structure can't be improved that much without running into trouble.
Main problem may be that I tend to dump many functions in one C file.
You can easily work around that by using ctags.

> Current vim code is usually composed of very big C files with no
> header files.  This is a pity because header file are the best place
> to document functions.

I completely disagree with you here.  Header files are only useful to
specify data structures and global variables.  Functions should be
documented only where they are defined.  Don't want to spread the info
about a function over several files, making it difficult to find and
maintain.  Unfortunately, C doesn't provide the features that Java does
for this, thus we still need header files.  That's why the header files
for functions are generated.

> Reading a set of documented header files, you understand very quickly
> the role of the functions there. Currentely, you must read huge amount
> of source code to get the same effect.

Mostly it's easier to read and understand the source code (with
carefully placed comments where needed), than the blah blah of
documentation.  You also need to consider the extra time it takes to
write the documentation and (horror!) the risk of the documentation
getting outdated.  That mostly happens eventually...

-- 
ARTHUR: It is I, Arthur, son of Uther Pendragon, from the castle of Camelot.
        King of all Britons, defeator of the Saxons, sovereign of all England!
   [Pause]
SOLDIER: Get away!
                 "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]