'Re: [quanta-devel] Annotation support'

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

List:       quanta-devel
Subject:    Re: [quanta-devel] Annotation support
From:       Andras Mantia <amantia () kde ! org>
Date:       2005-04-23 5:09:51
Message-ID: 200504230810.01858.amantia () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]

On Saturday 23 April 2005 04:26, Jens Herden wrote:
> Hi Andras,
>
> >  I've talked a little with Eric about annotation support in Quanta.
>
> I have not seen this on the list, so I think this was private. What a
> pity because now I am in the role of the complainer again :-(
It was on the phone. ;-) This also makes it more error prone that I 
misunderstood something.

> >  This means you can assign comments to documents (to specific lines
> > in the documents). The comments can be browsed in a new toolview.
>
> What is the difference between annotation and comment? I don't see
> one. Adding comments to a file is not a really new concept, but
> browsing them is.

Yes, I think this is the main addition. You can browse them easily. It's 
true, KDevleop has also a similar browser for FIXME and TODO comments.

> I like the idea of making comments more visible but frankly spoken
> the implementation is very poor.
>
> First of all. The idea of storing information in two different files
> that belong to each other is very bad. Think about copy and move of
> the textfile. You will be forced to do it in Quanta if you want the
> comment-file moved and copied as well.
Right.

> Think about other editors than 
> Quanta, let's say I open a file in Kate and insert some lines in the
> textfile. Either the relation between comments and linenumbers is
> instantly broken or your comments-file must know about the content
> and not only the linenumber. (I don't know what you are doing, I did
> not look into the code)

Yes, taking care of line shifting is not implemented yet. Forgot to 
mention in the issues. And yes, editing the same document outside of 
Quanta would broke the annotations. 

>
> All this brought people to invent tools like Doxygen, so that you can
> comment your code inside of the document.

Hm, Doxygen. I forgot about it. Can it work with XML files?

>
> So what are the problems you want to solve?
>
> 1. You want to browse the annotations of one file and be able to jump
> to a line.
> We have this concept already, it is called structure tree and I see
> no problem in adding a subtree for comments there.

The structure tree can be very big. Also not all comments are 
annotations.

> 2. You don't want to see all comment, just the important one.
> Lets use a kind of tag system to filter the important one out. (like
> @annotation inside of the comment or so)

That makes more sense.

> 3. You want to have all comments inside of the project available.
> This would mean parsing all files in the project and would suggest to
> do this when we move to KDevelop. There should be some kind of
> background parsing. 

I'm not sure they have background project parsing. The CPP parser is 
threaded AFAIK, but the project parsing is not.

> The result should be stored in the project file 
> not in the filesystem so that on startup no rescan is necessary.
Now I have to say that storing such information in the project file is 
not anymore different then storing in an external file (except that it 
is faster to scan).

> 4. You don't want to see your comments during normal editing, just
> the icon as hint.
> This could be something that might Kate implement inside of the code
> folding stuff. Just always fold comments away and give a tooltip if
> you stay over the folded block. Otherwise Quanta could hide it form
> the editor. But my favorite solution would be a action in Kate to
> hide/show all comments.

The problem is that in most languages comments can be one or multiline. 
In case of multiline comments hiding may be possible, for one line 
comments I'm not sure it even makes sense.

> I think we should drop this implementation and think about another
> approach to get what you want. Don't invent new features for problems
> that are already solved but improve the handling of the current
> solution is the way to go.

I don't want to drop the whole feature, but change the storing of the 
annotations. ;-) What do you think about this:
1) store inside the document as comments (in comment nodes), as you 
suggested, and use the special tag @annotation. So in case of XML:
 (can be multiline as well) or
 (the annotation is the same).
In case of PHP:
/* @annotation My comment */ or
/* something @annotation My comment */ or
// @annotation My comment
and so on.

This solves the problem of line shifting. moving and editing outside of 
Quanta. But doesn't help in parsing the whole project for comments.

2) in the project file (or the session file?) create an index with the 
files having annotations in the form of:
<annotations>
 <item url="filename" time="timestamp" lines="11, 23, 50" />
 ...
</annotations>

- On startup only the files from the project not under <annotations> or 
those having a different timestamp than stored there are scanned.
- Whenever a file is saved, added to the project,  updated from CVS is 
performed, it is scanned for annotations and the project file is 
updated. 
- editing of the annotations can be done either by entering the comment 
manually or editing in the annotations view. I'm not sure if in this 
case we need the context menu entry or not.

What do you think about this proposal?

BTW, no problem if you disagree. I may have worked a little in plus with 
this, but whatever. I can bare it. ;-) And you usually have good ideas.

Andras

-- 
Quanta Plus developer - http://quanta.sourceforge.net
K Desktop Environment - http://www.kde.org

[Attachment #5 (application/pgp-signature)]

_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel

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