Re: David, have you thought about using an existing editor?

["G.B." <bauhaus@futureapps.invalid>]

On 22.01.15 01:53, Shark8 wrote:
> On 21-Jan-15 16:16, Hubert wrote:
>> The code browser would indeed be the most important part. Right now,
>> with GPS, I'm having the problem that everything seems to become "flat"
>> for me, its not easy to describe, but with the list of files that all go
>> like
>> A
>> A.B
>> A.B.C.D
>> A.B.C.E
>
> I think it would be better with a "compilation unit" treeview -- the
> "outline view" is similar, in concept, but limited only to the entities
> of the file you're viewing rather than showing you the structure of your
> units.

What is it that makes people is fond of trees? Is it Windows™?
Not having seen something less trivial?

A tree basically does not have navigation within it;
it tends to not have any topics other than trivia of files/units;
it is, basically, a list, presented "graphically" with indentation,
that follows mechanically from whatever is used for sorting
things shown in the tree. I can see hardly a non-trivial, programmer
centric aspect that is made available through trees.
They take away from the screen, for something that I'd rather
like to generate ad hoc. (Like "grep -n 'procedure ' *.ad?" in an
editing window. This view then receives a list of results just like
from a compiler, and is used in similar fashion.)

Looking at a tree feels like looking at book shelves, and asking:
"Now, what books do I have at all?"
But this is not how I would find books, let alone learn which
one is relevant and what is in them–which is the interesting part.

Navigation capabilities,
Call graphs,
Object relationships,
aspects such as active types or I/O-related modules,

seem much more helpful to me, in particular if the views
are connected to each other.