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

List:       vim-dev
Subject:    RE: [kvim-dev] Re: Vim's future ?
From:       Philippe FREMY <P.FREMY () OBERTHURCS ! com>
Date:       2002-11-13 9:53:12
[Download RAW message or body]


	Hi again,

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 ?

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

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

I think the gtk vim does use a specific font name syntax, so we tried to be
compabible with that.

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

I'll check again but I clearly remember gvim to be really slow in comparison
with vim on a linux console.

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

I was not dismissing vim usefulness. Certainly a great editor. I was meaning
something like "For someone running a graphical desktop, if having gvim is
equivalent to having vim running in a console, there is not much interest in
the graphical part of vim". The interest of a graphical vim is to provide
more than the console vim. Menu and toolbars are a very first step. Things
like aap or a vim component are the ultimate goal.

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

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


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

I was just talking about adding existing documentation in the .pro file. The
change is about:
- adding one * to comments before functions, when they exist
- generating .pro files with the comments included.

> Just moving the comments to
> the proto/*.pro files would require using another tool to generate the
> prototypes. 

I can write a python script to do that. The /** */ syntax is better because
it is the standard for tools like doxygen and javadoc.

> And slowdown compiling a bit. 

True. We could make it optional.

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

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

Yes, but not everybody is using ctags. And ctags is good to navigate the
code, but not to summarise it.

> It seems your problem is that you have trouble navigating through the Vim
code

That's true. And I am not the only one to have this problem. Am I the first
one reporting it ? I am a decent programmer (not very good but not very
bad), so I think that if I have problems peeking trhough vim code, other
have problems too. I think current vim code layout is a deterrent to valid
contributors, because it is too difficult to grasp in a whole.

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

That is not true. I came here a few times to ask for example how the
character event-loop worked because I did not understand it. The gui code
was well abstracted, so we did not need your help for it. The other occasion
where we needed to go through the vim code was to fix our specific bugs so
it would have been wasting your time to ask you a question like "why does
syntax highlighting not work with kvim ?" (Answer found after one week of
code reading: we had forgotten to call an init() function).


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

It makes things clearer for people landing on the vim code. They do not need
to read the beginning of a file to know what it is for. If it is in
ui/console, it is clearly related to console UI and you do not need to read
it if you are not working on console code.

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

You don't have this information when doing your first ls in src/ . All you
see is plenty of files.

	Philippe.
###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/
[prev in list] [next in list] [prev in thread] [next in thread]