Re: CodeEditor 0.4.3 is released

[Yen-Ju Chen]

Hi,

> From: Stefan Urbanek <urbanek@host.sk>
> To: Yen-Ju Chen <yjchenx@hotmail.com>
> CC: discuss-gnustep@gnu.org
> Subject: Re: CodeEditor 0.4.3 is released
> Date: Sun, 05 Oct 2003 01:57:49 +0200
>
>
> Would it be possible to strip all type info and leave just selector? 
> Instead of -(void)setObject:(id)anObject forKey:(NSString *)key there will 
> be just setObject:forKey:. Another things are: it should be resizable and 
> when I select a method I would prefer to scroll text view so the method is 
> at the top.

 I'll try to do that. The scrolling is more complicated.
 It uses some existing method in NSTextView for that,
 and there is some small problems in the language bundle.
 But they should be easy to fix.

> > CodeEditor is a text editor so that I won't address much on code parsing.
> > But the parsing mechanism might be suitable for other projects.
>
> Would not it be better to leave "general purpose text editor path" in the 
> favor of the application name: CodeEditor which will really understand the 
> code developer is writing there?

 That problem is that CodeEditor deal one file at a time,
 not header and implementation together.
 But it's the matter of choice. See below.

> Features in very distant future: find implementation of given selector.
>
> > If you want some features for CodeEditor, especially on the text view,
> > please let me know so that I can start "thinking" of it. :)
>
> The tabbed editing is confusing and I would suggest removing it in the 
> fawor of more intelligent code organising and browsing.
>
> I would prefer some very simple scrollabe window with similar functionality 
> like the Windows menu. Functionality: browser with last path component of a 
> filename; when single-clicked window is taken into focus. There should be 
> optional buttons/Popup button menu: Hide others (will hide all other 
> windows except  selected), Minimise selected windows (multiple selection), 
> Close selected windows.
>
> Btw. if your codeeditor understands ObjC code, you can have class names in 
> that window instead of filenames, and by pointing on a class, corresponding 
> window with its implementation/interface is opened.
>
> What do you think?

 That's the choice of where CodeEditor should go.
 Originally, I'm thinking it is a non-rich text editor with some code 
handling functions.
 Therefore, it handles on the file content only, not extends to other 
related files.
 I think working among related files is the function of project manager, 
aka ProjectCenter.
 In this case, CodeEditor won't be able to handle header and implementation
 because at most of the time, they are in different files.
 I do think to take off the tab view and use a browser for fast file 
switching.
 But it seems to be a function of project manager so I didn't do that.

 Now, the non-rich text editor and code handling functions are mixed 
together,
 limit each other, and makes implementation a little big harder.
 I'm thinking to seperate the non-rich text view and code handling into 
different bundle/library.
 In the non-rich text view, you can only use one font, can change color, 
etc,
 which will make rendering much faster than NSTextView,
 which handle too much functions like attachment, different fonts, etc.
 In code handling functions, it may just be some classes.
 Then I will have a non-rich text editor, which use non-rich text view;
 and an code editor, which use code handling functions and display the 
result
 in the non-rich text view.
 The code editor can have any functions people want,
 but it will be very similiar to ProjectCenter, which make me think whether
 ProjectCenter should support these functions rather than a seperated code 
editor.
 By doing these, I probably need a framework rather than a lot of 
bundles/libraries,
 which give the rise of the question whether we need a unified framework
 for ProjectCenter, Gorm and CodeEditor.

 In short, the design of CodeEditor need some big changes now.
 I probably will take the non-rich text view out of it and make it 
independent.
 The goal is to have a fast rendering text view assuming
 only one font, no attachement, etc (non-rich text).
 Then the question is where the rest go ?
 It could be just a library for ProjectCenter and Gorm in code parsing.
 Or it could be an independent code editor
 but has some overlapping functions with ProjectCenter.
 I'm open mind in this question and prefer the first choice (just a library 
for PC and Gorm)
 to reduce the work to maintain a full application because if everything 
goes well,
 I probably will not be able to maintain codeeditor less than one year 
later.

 Sorry for the lenghy reply. That's just something in my mind
 and would like to hear some suggestions and comments.

 Yen-Ju


> Best regards,
>
> Stefan
> --
> http://urbanek.host.sk
>
> First they ignore you, then they laugh at you, then they fight you, then 
> you win.
> - Mahatma Gandhi

_________________________________________________________________
Get MSN 8 Dial-up Internet Service FREE for one month.  Limited time offer-- 
sign up now!   http://join.msn.com/?page=dept/dialup