From vim-dev Wed Nov 13 09:53:12 2002 From: Philippe FREMY Date: Wed, 13 Nov 2002 09:53:12 +0000 To: vim-dev Subject: RE: [kvim-dev] Re: Vim's future ? X-MARC-Message: https://marc.info/?l=vim-dev&m=103718139821163 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/