[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-12 21:20:19
[Download RAW message or body]


Philippe Fremy wrote:

[... lots of things ...]

This is getting pointless.  You appear to take one viewpoint and decide
about what the Vim architecture should be.  Please don't forget that
there are several other viewpoints that need to be taken into account.

Whatever improvements we might decide would need to be done, the
limiting factor in all of this is: Who is going to do the work?  I
currently don't have time for more than a few minor changes.

> I see. Do you have anything against C++ ? Using objects to handle this kind
> of state would be make the process a lot easier.

Switching to C++ would mean a complete reimplementation with
unpredictable results.  A doubt the language matters for this issue
anyway.  C++ tends to have different problems, not less problems.

> > Again, please be specific.  I'm sure the interface between the non-GUI
> > part of Vim, the generic GUI part and the system-specific GUI part can
> > be improved. We need to do this step by step and making sure the code
> > still works for all GUIs.
> 
> So if someone submit patches to improve that, you will accept them ?

If they are good patches, yes.  If they are bad patches, no.

[about specifying a font name]
> Our initial goal was to be as compatible as possible with vim. So we havn't
> look into this solution yet.

Vim doesn't specify the syntax for the font name itself, it uses
whatever is being used on the system it's running on.  Except for Win32,
where the info is stored in a structure and we need to transform it into
a string.

> You specify a scrollbar size, but what if the current theme require a wider
> scrollbar ?

No, Vim obtains the size of the scrollbar from the system.  If it
changes during runtime you need to add some code to handle that.  Not
really a big problem.  I think it already works for GTK (or was it GTK
with Gnome?).

> No figures sorry. But there is a big difference between running vim in
> a konsole and running kvim. KVim is really slow to display typed text.
> Need to check that again.

Since the common GUI Vim code is the same the problem must be in the
GUI-specific code.  Doing a bit of profiling is often very enlightning.

> > > If having gvim is equivalent to have vim in a console, there is not
> > > much interest in gvim.
> > 
> > Can you show me statistics???
> 
> Should I count all the mails  of people who told me they have been waiting
> for a long time for such a vim component ? For one guy that wrote us, how
> many do agree with him and do not write to us ?

Since you're working on kvim I would not expect people who use Vim on
MS-DOS to send you a message.  Thus you can't draw conclusions from what
messages you receive.  Better find a more objective way to back up your
statements about where Vim users' interest lies.

> > > - lack of access to a pure vim engine.
> > 
> > Eh, isn't this what we have been using all along?
> 
> No we are using vim's application, which is quite different from a vim
> engine. Using vim the appliations creates numerous problems that could be
> avoided if vim-the-engine could be made separated from vim-the-application. 

I'm afraid I don't know what you mean with a "Vim engine".  It seems
to be irrelevant for the discussion about using Vim as a component
anyway, since the user would still want to type all the possible Vim
commands in it.

> > > Since most functions in the C file to have a comment before the function
> > > specifying what the function does, would it be possible to at
> > > least include this comment in the .pro file ? You could use the
> > > syntax of javadoc/doxygen, marking comments that are documentation
> > > with /** ... */ instead of just /* ... */.
> > 
> > I don't see the advantage in this.  When browsing through the source
> > code (I always forget how it really works :-) I never get into the
> > proto/*.pro files.  I only use "[I" to see the arguments used.  Using
> > CTRL-] to jump to a function is mostly sufficient to find out how it
> > works.  Sometimes I look for another place where a function is used and
> > use this as an example (the surrounding code is often useful as well).
> > Use ":grep" for that.
> 
> If it doesn't change anything for you and brings us benefit and is a minimal
> change, why do you refuse it. The fact that this is not a problem _to you_
> doesn't make the need void.

A minimal change?  Adding consistent documentation comments throughout
the code?  That would be months of work.  Just moving the comments to
the proto/*.pro files would require using another tool to generate the
prototypes.  And slowdown compiling a bit.  And I still don't see the
advantage, since you are just duplicating the text.  It's a lot easier
if you use ctags to jump to the function definition and read the comment
there.  No need to change anything.

> I am talking about an inexpensive modification of existing documentation.
> And yet for you it is too much! Your attitude is not very friendly to the
> people that want to contribute to vim. 

My remarks are based on experience and estimation of how much time it
takes to write good comments.  It has nothing to do with my attitude,
and if you have read the source code you already know that I have spend
quite a bit of time to explain the details of the code.  But my time is
limited, I add comments bit by bit.

> After a few month of reading through vim source, I have given up. I was
> disgusted of always having to go through 2000 lines files to find the
> function I was looking for. Yes, i was not using cscope. So vim source is
> "use cscope or die ?". I took the second option and kvim development
> stopped.

I never use cscope when working on Vim.  Just ctags and grep.  It seems
your problem is that you have trouble navigating through the Vim code
and you want to blame someone else for it.

> You have no idea how many people have been disgusted to work on vim because
> of the way the source code is layed out. But there are more than you think.
> On the three people working on kvim, we are three disgusted. This thing is
> making valid contributors go coding somewhere else. Too bad.

Strange that in all that time I have not had a single question from the
kvim people about how something worked.

Sorry, but I can do nothing than ignore these remarks.  They are
unconstructive and offensive.

Try fixing the problem instead of blaming others.

> You should think more about this. Don't you welcome contributions ?
> Then welcome additions that do not create problems for you and change
> the life of others.

Sure, I always welcome useful contributions.  Where haven't I?

> Want any suggestions ? Instead of putting all the gui files inside the main
> directory and call them gui_XXX, create a directory ui/ and subdirectories
> gtk/, athena/, X11/ and soon kde/ . Put the code specific to each gui in its
> own directory. Put the gui generic code (ui.c, gui.h) inside the ui
> directory.

I can't imagine moving files around solves any of the problems you mentioned.
Only perhaps that it looks more like what you are used to.

> This is not very obstrusive. Yet it would make things clear. It took me a
> while to figure out that gui_x11 was not needed for me. This is wasted time
> that I would have prefereed to spend on kvim. But I expect you to tell me "I
> don't see why I should do that, I have no problem with the way the current
> code is layed out". Too bad for me and the other contributors.

At the top of gui_x11.c it says:

/*
 * Common code for the Motif and Athena GUI.
 * Not used for GTK.
 */

Can it be any clearer?  Perhaps I should have added "not for kvim"
before you started working on it?

-- 
hundred-and-one symptoms of being an internet addict:
19. All of your friends have an @ in their names.

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