[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-12 18:32:46
[Download RAW message or body]


Jonathan said:

> [snip]
> > > Use a function call with remote_expr(), works in any state. 
> > 
> > Did not think about that. We could have a try.
> [snip]
> > > > There is a queue to store the first commands that can not be sent.
> > > 
> > > Using a pipe would be a lot simpler if you are starting Vim yourself.
> > 
> > Does vim accepts commands from its stdin ? I wasn't aware of that.
> 

> It seems that Bram might have a few suggestions to some of the problems -
> problems that may well already by solved for the existing Sun Workshop
> interface. 

Bram has a few suggestions for the least problematic stuff. And some hacks
that would make the kvim component evolve from a complete hack with a simple
architecture to a complete hack with a very complicated architecture
(threads, longjmp, ...).

Nothing yet that would make it possible to have a working maintainable vim
component. I am against doing workarounds after workarounds. I write code
for fun and praise. These wouldn't bring me any of them.

> Rather than telling him his code must be redesigned,

I did not tell that the code should be redesign. I did say we need a clear
architecture. As he pointed out, vim has the architecture we need, but
spreaded across several files without any defined API. Since the idea of
defining an API is even too much change for him, I fail to see how we can
use that.

> how about asking for a bit of help and being pointed in the right
direction?

And how about thinking that the current vim source code could be improved ?
The problems we have are in no way specific to KDE and Qt. Everybody wanting
to code for vim has had them. I have met a few developers that wanted to
code for vim but have runned away when seeing the source code. How many
useful contributions were lost that way ?

Don't you think there are better way to welcome contributors than 2000 lines
files with no header file, intermixed with each other ? I do. I have been
able to contribute to bigger projects than vim with less problems because
the way the source code was organised was better and they had an internal
API.

Something as simple as creating a directory for storing files that work
together is not a tremendeous change, but according to Bram, it doesn't
bring anything.

> As you've said, you've found the Vim code hard to understand at first,

The problem is not that it was hard to understand at first. This is the case
for every project. The problem is that after one year, it was still very
hard to understand. I have better things to do than spending two hours
trying to understand a drawing function and realising it is actually a
syntax highlighting function. Had the function had a proper naming, or been
in a file with a proper naming, I would not have spent that time. This is
like this for _everyhing_ in vi. The only thing that I have seen with a
clean easy-to-grasp interface is the gui code.

> there might be loads of tricks you don't know about that 
> could solve the problems with kvim.

I may not know all the vim internals but I know the problems of kvim and how
to solve them. Bram's propositions are at best a hacky workaround. This
means that it will be difficult to maintain, will probably not work
immiediatley if ever, will sometimes fail for difficult to reproduce
reasons, will be very difficult to improve.

We are in 21th century and I have code quality standards. I am sorry but vim
does not meet them and any step to go towards them has sofar being rejected
by Bram as "it doesn't bring anything".

> > Having a vim-engine without specific gui-code where we would be able to
plug
> > our own gui interface is a nice solution. I am _sure_ about this.
> 
> I'm sure you're right it would be nice, but it might not be the only
> option.
> 
> But having said that, I haven't worked with the kvim code and haven't
> tried to solve the problems you've encountered, so I'm not in a position
> to say much really ...

Indeed. Not that I reject opinions of non-coders, but you have to go through
vim and try to change anything to understand why I am so harsch.

	regards,

	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]