Re: Visibility problems with package instantiations.....

[Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>]

On 04 Dec 2003 08:09:22 -0500, Stephen Leake <stephen_leake@acm.org>
wrote:

>Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>> On 03 Dec 2003 13:09:25 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
>> wrote:
>> 
>> >Hmm. In emacs, I pull up the whole directory, then search in the
>> >buffer.
>> >
>> >But actually, to navigate Ada source, I don't tend to use file names;
>> >I use Ada names, and let Emacs figure out where the files are.
>> 
>> I see. You know, an ability to accept emacs is IMO sort of genetically
>> preprogrammed. (:-))
>
>Well, there do seem to be Emacs people and non-Emacs people. 
>
>> >File names that mimic the package tree are better than directories
>> >that mimic the package tree, in my opinion. I haven't heard any solid
>> >evidence here to contradict that.
>> 
>> As a emacs user you should see little difference between:
>> 
>>     fuzzy-graph-handle-learning-implementation.ads
>> 
>> and
>> 
>>     fuzzy/graph/handle/learning/implementation.ads
>> 
>> after all one can substitute '/' for '-' in emacs.
>
>Exactly; they are very much the same in readability. But, I have to
>add all directories to various search lists, so it is much easier to
>have only a few directories. Thus I prefer long file names over long
>directory paths.

It depends on the compiler and IDE. AdaGide does it very good for
GNAT. I found it easier to use than GPS (except for debugging of
course).

>> Then, do not you feel that packing everything in one directory is
>> similar to packing all packages in one huge all_stuff.ada file? 
>
>Since the Ada compiler treats compilation units in one file much
>differently than compilation units in separate files, but cares not at
>all about what directories things are in, these are very different issues.
>
>> I mean that if we accept the idea of mapping compilation units to
>> files, we should also, consequently, accept mapping of their
>> parent-child relations to the directory-file ones.
>
>I accept it as a possibility, but it is simply not as nice in practice.
>
>Java is the only language I have used that cares about directories; I
>found it annoying. But if I had to use it much, I'd teach Emacs how to
>deal with it efficiently (or, more likely, find an Emacs package that
>someone else has written that does that). Then I wouldn't notice
>anymore. The same could be done for Ada, of course, if we had a
>compiler that supported it. But I see no compelling reason to bother.
>
>If the tools you are using get in your way (don't allow an efficient,
>convenient way to find files), then get (or build) better tools. The
>compiler is not at fault; your IDE is.

Right. With a good IDE there should be no reason to care about files.
But the issue will arise in another form, as you write below.

>I find GPS annoying with long file names, because it does not allow
>searching on anything other than the first letter of the file name (as
>do most GUI IDEs). Emacs allows searching on any portion of the file
>name.

Yes GPS has a long way to go. One problem is that the project view
shows files (and their directories) instead of compilation units. I.e.
it should be sort of:

+ specifications
   + window
      + pop_up
         - dialog

instead of:

+ some-irrelevant-directory-path
   - window-pop_up-dialog.ads

with a negative effect of consuming too much of screen space.

One can organize project view in a directory-tree-like way under
MSVC++. In C++ there is no parent/child relation, so one should create
project "directories" manually. ObjectAda at least supports separation
of specifications and bodies. But in Ada there is a natural
"partitioning" base on parent-child/separate body relation. Should IDE
support it, then, yes, one could forget about all file names.

>Give Emacs another try; it will be good for you :).

Maybe, when EU will allow experiments on stem cells, then a small
injection of emacs-cells and ... (:-))

--
Regards,
Dmitry Kazakov
http://www.dmitry-kazakov.de