Hi,

I've been thinking about a recent problem posed by Anthony Walter on the fpc-pascal mailing list: the abundant use of include files and IFDEFS and the ensuing lack of 'overview'.

So I asked myself: what if we somehow "invert" the problem ?

How hard would it be to create a 'resolved view' of a unit in the IDE ?

By this I mean a view of a unit as the compiler will see it:
- Correct include files included
- IFDefs properly resolved.

The IDE groks include files and can already syntax highlight conditional code, so the necessary mechanisms surely are in place.

This view can be read-only for all I care, can optionally have gutter markers for 'special' locations (where includes occur or IFDEFS were observed). Maybe gutter colors/folds to indicate includes, etc. How this view is to be entered is also up for discussion.

Just running an idea up the flagpole...

If it's pure balderdash, feel free to say so.

Michael.

Michael Van Canneyt wrote

By this I mean a view of a unit as the compiler will see it: - Correct include files included

This has been long on the list. But still no in the doing.

Ignoring:
- any high/low-light or other markup to indicate the fact that the text comes from a different file
- probably also ignoring line numbering

this should actually be relatively easy.

There are already "views" wrapped around the textbuffer. All that it needs is to wrap another view around it, that combines 2 real textbuffers.

This could even be editable. Except it needs to prevent joining lines accross file bound.

There is work on the IDE side (outside SynEdit) to ensure it knows the file is open. Could be resolved by pretending it is open in its own editor (which is simply hidden)

- IFDefs properly resolved.

lowlight exists.

Actual hiding is more work, because it needs to shift x positions in some line. Probably needs big changes. Though readonly may be doable.

Il 12/02/2016 02:41, Martin Frb ha scritto:

Actual hiding is more work, because it needs to shift x positions in some line. Probably needs big changes. Though readonly may be doable.

IMHO such a feature would be typically used to read and understand code, therefore read-only is not only acceptable, but desirable.

Giuliano

Aha, so there is hope :)

And ask what to do if you delete all lines from an include: remove the include directive or the file.

There is work on the IDE side (outside SynEdit) to ensure it knows the file is open. Could be resolved by pretending it is open in its own editor (which is simply hidden)

So, this part is in fact pretty realistic ?

Well, if it is on the todo list, I don't need to file a feature request ;)

Hmh. I would think that preprocessing the text would be an easier approach here, no ?

I think for the second feature, read-only (as pointed out by Giuliano Colla) is the only viable option, because there are too many border cases. In that case preprocessing is an option.

Still, I suspect that Anthony Walter's original problem would be largely solved by handling the includes (so simply 'Inclusive view' :) )

Michael.

Yes, in fact the codetools create such a source as first step. It is called the "cleaned source". Skipped code is in special comments and there is a map to the original sources.
So it is possible to show it in a read-only synedit. With a bit more work the view can support code navigation and code explorer. It would be more work to integrate such a view in the source editor. Especially editing would be complex.
What should happen when the include file of the cursor is no longer in the unit?
What about include files used twice in a unit?

A read-only view is a good idea. Supporting editing might not be worth the trouble.

Maybe someone can implement a package adding a "unit explorer" - a window with pages for units, with code navigation and a light weight code explorer. Jumping between source editor and unit explorer could be done with menu items (and/or icons in the tool bar).

Another idea is to show links to the include structure of the unit, for example on top of an include file or in the code explorer.

Mattias

Yes, that happens in the RTL as a kind of poor-mans generics.

Indeed. In view of what can happen, I think read-only is the only viable option.

aaaahhhh; So many ideas, so little time....

Luckily we have a SuperMattias on board. Now to get that globe to spin backwards... ;)

Michael.

[...] > What about include files used twice in a unit? Yes, that happens in the RTL as a kind of poor-mans generics.

That's no problem when the file compiles. But while typing a directive the unit structure falls apart. That's no easy problem for a source editor.

[...] Luckily we have a SuperMattias on board. Now to get that globe to spin backwards... ;)

Actually Superman traveled back in time, not the globe. The film was wrong.

Mattias

Michael Van Canneyt wrote

Well, if it is on the todo list, I don't need to file a feature request ;)

Not really on todo, only remembered as being wanted.

Yes, absolutely.
Well, even a read-only view will get us a long way, I expect.

[Michael falls from his chair in disbelief]

All my beliefs shattered....

Michael.

Should I file a request anyway or has memory been sufficiently refreshed ?

Michael.

I had not yet read Mattias will go for a different approach solving it.

The problem for me is, that I will not have the time to look at it any time soon.

Also my approach would have more been "editing includes inline" rather than a cleaned source.

If I surprisingly will get time, then we can still have both one day in the future.