Re: [Lazarus] RFC : "Resolved View"

2016-02-12 Thread Giuliano Colla

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




--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] RFC : "Resolved View"

2016-02-12 Thread Michael Van Canneyt



On Fri, 12 Feb 2016, Martin Frb wrote:


On 11/02/2016 23:54, 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.


Aha, so there is hope :)



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.


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 ;)



- 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.


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.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] RFC : "Resolved View"

2016-02-12 Thread Michael Van Canneyt



On Fri, 12 Feb 2016, Mattias Gaertner wrote:


On Fri, 12 Feb 2016 00:54:38 +0100 (CET)
Michael Van Canneyt  wrote:


[...]
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.


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?


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





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.


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


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



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.


; So many ideas, so little time

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

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] RFC : "Resolved View"

2016-02-12 Thread Mattias Gaertner
On Fri, 12 Feb 2016 15:25:11 +0100 (CET)
Michael Van Canneyt  wrote:

>[...]
> > 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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] RFC : "Resolved View"

2016-02-12 Thread Michael Van Canneyt



On Fri, 12 Feb 2016, Mattias Gaertner wrote:


On Fri, 12 Feb 2016 15:25:11 +0100 (CET)
Michael Van Canneyt  wrote:


[...]

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.


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


[...]
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.


[Michael falls from his chair in disbelief]

All my beliefs shattered


Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] RFC : "Resolved View"

2016-02-12 Thread Martin Frb

On 12/02/2016 12:45, 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.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] RFC : "Resolved View"

2016-02-12 Thread Martin Frb

On 12/02/2016 16:10, Michael Van Canneyt wrote:


On Fri, 12 Feb 2016, Martin Frb wrote:



Not really on todo, only remembered as being wanted.


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


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.


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] RFC : "Resolved View"

2016-02-12 Thread Michael Van Canneyt



On Fri, 12 Feb 2016, Martin Frb wrote:


On 12/02/2016 12:45, 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.


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

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


[Lazarus] RFC : "Resolved View"

2016-02-11 Thread Michael Van Canneyt


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.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] RFC : "Resolved View"

2016-02-11 Thread Martin Frb

On 11/02/2016 23:54, 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.



--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus