[PATCH]: store a range as position for a context import instead of a cursor

[Milian Wolff]

Am Samstag, 8. August 2009 21:58:00 schrieb David Nolden:
> Am Samstag 08 August 2009 15:12:08 schrieb Milian Wolff:
> > David, please review.
> >
> > Others: How do I update the kross stuff? Since I changed the kdevplatform
> > API
> >
> > Language-Plugin-Maintainer: you have to update your plugins and change
> > the calls to addImportedParentContext and pass a range instead of a
> > cursor. In cpp for example I pass the range between "" or <>.
> >
> > With my upcomming patch which will push the whole includewidget and other
> > stuff into kdevplatform it will be much easier to find the positions
> > where to show these widgets. You won't have to do string-comparison. Just
> > compare the ranges of the imports for the current file with the positoin
> > of the current cursor.
>
> Just btw.: String-comparison is very easy to do, so it doesn't necessarily
> have to be easier this way.

Then please help me getting this done for PHP. In cpp I don't argue with you. 
That's simple as hell since one include is on each line. Similar in python or 
Java. But in PHP you can put the include wherever you want... And you can use 
any expression as the path and we might be able to support quite a lot of 
these cases. E.g. the following:

require __DIR__ . '/../../' . SOME_CONSTANT;

That would be possible to support. But I doubt doing string-comparison is 
feasable here... It will really get kind of complicated, I see only the 
following solution using just the cursor:

- get a token stream up to the position of the cursor
- check if we are in an include statement
- check if there is an import in the range between the start of the include 
statement and the cursor position

Not trivial at all... but well.

Another question this rises is the following:

require SOME_CONSTANT;

With the current implementation, will I get two tooltips when I hover that?

- when hovering require I want to see documentation about the require language 
statement and also the includecontext widget
- when hovering some_constant I want to see where it got declared and stuff 
like that but also again the include context widget

Is that even possible? Will the tooltips stack?

> I've taken a look at the patch and the basic issue again, but there is one
> thing that I unfortunately forgot to think of when we first talked about
> the issue: The class DUContext::Import is very critical for the overall
> size of the duchain data, and needs to be kept as small as possible. When
> we talked about it I thought that the cursor/range was only stored for
> top-context imports, but that's not the case these days.
>
> Adding a SimpleRange instead of the SimpleCursor increases the size by 50%,
> so I fear we cannot do it this way.
>
> Even the SimpleCursor that was already there
> is already too much, as it isn't needed in 99% of the cases, and we need a
> way of associating additional data to imports, without blowing up the
> minimum required size.
>
> The most correct way of doing this would be allowing a direct association
> between a use and an import, and building a use that contains the range for
> such imports. But that raises the problem that uses don't have global
> identities within their top-context yet, and the whole concept might need
> some work, especially in the C++ support.

I would appreciate if you could get it working one day. I really hate 
replicating stuff again and again instead of storing the information one gets 
once and using that later on. I personally think it would make sense to have 
something similar to a declaration for imports:

- you associate a range with it
- when entering the range it gets highlighted
- when requesting a tooltip it gets shown

again, make sure the tooltips can stack (see above).

Would that be possible? Or is there anything which speaks against it? Size of 
the repo or something?

> >From a logical point of view, a cursor for an import should actually be
>
> enough. The basic idea behind that cursor is, that from that point on, the
> import is 'effective'. For example in C++, the content of #included files
> are only visible behind the #include directive, so the position of the
> directive is marked in the import, and is used during visibility checks.
>
> The range is a more detailed information similar to uses, which is not
> needed in most cases, and thus should not be stored on a general basis, but
> only in specific cases when required.
>
> Greetings, David
>
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090809/487d0c94/attachment.sig>