Re: GPS issues: laundry list

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

On Thu, 13 Sep 2012 06:55:11 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Wed, 12 Sep 2012 07:53:21 -0400, Stephen Leake wrote:
>>
>>> - I can't change the environment ADA_PROJECT_PATH from within GPS. I
>>>   change that more often than the compiler; typically each project
>>>   requires a different path (mms_version_07, _06; gpm vs mms, lynx 4 vs
>>>   lynx 5, etc).
>>
>> Why don't you use scenario variables for this? I handle multi-targeted
>> projects (Windows/Linux/VxWorks) using scenarios. It works perfectly
>> well.
> 
> Scenario variables are defined and used within project files.
> 
> ADA_PROJECT_PATH selects which project files to use.

I see. Yes, it is a problem with the gpr-project files that one cannot make
a "with" dependent on the scenario.

> How can you do that with scenarios? Note that the source code is
> different between the versions, indeed the project files may be
> different between the versions.

This particular task is rather for a source control system, not for the
IDE. The project file name and its selection must not depend on its
version, IMO.
 
>>> - tab completion and regexp name match on switch buffers. I often have
>>>   dozens of buffers open; tab navigation just does not work in that scenario.
>>
>> This is indeed a problem, but I doubt that tab completion could be a
>> solution, unless you type the names reverse (Ada units tend to have same
>> prefix and differentiate in the suffix).
> 
> In Emacs, I use both; I start by typing a glob that narrows the field,
> then tab complete to finish the selection.

You must have an extraordinary memory to be able to memorize file names. I
bet very few people can do that.

>> For a small project the project view works very well. For large projects,
>> especially ones with many generic instances, nothing helps. No idea how to
>> improve that, but tabs and regex are definitely non-starters to me.
> 
> Have you actually tried Emacs iswitchb?

All people are divided into those who can use Emacs and others. I am in the
second category. Should neurologists ever make brain scans of the Emacs
users, they would certainly find it sufficiently different. Aliens live
among us! (:-))

>>> I think the hardest one to fix is the help system.
>>
>> I never used it and never felt it necessary to have.
> 
> Amazing. How do you find out how to do anything?

There is an old saying that if nothing else works, you may read the manual.
GPS is WYSIWYG. Everything you need, you can guess how to do it by simple
try and error. If you cannot, then, likely, you just don't need it. Why
bother reading anything? (:-))
 
> Let me guess; you have a resident guru, who has read the help, and you
> just ask them.

It would be so nice. Alas, no.

> Doesn't work for me.

Somebody, who can Emacs, who can memorize source file names, does need
on-line help?

>>> But such functionality is
>>> critical when working on writing new features for the system (or fixing
>>> bugs in the existing code).
>>
>> Why?
> 
> Might as well ask fish why water is necessary.
> 
> I take it you have never tried developing code for Emacs in Emacs (or
> some similar system).
> 
> Have you written GUI code for GPS? For example, added a new feature to
> the VCS interface?

Very rudimentary, I modified some menus. Once I saw python and XML, I
backed off. (Who would expect that from AdaCore?)

> Have you tried to debug the crash you describe above?

No, it freezes.

Since GPS is a GTK application, its debugging must be a nightmare, even if
you know the internals of GPS very well. Freezing should have something to
do with a deadlock in an event handler. This is a common case you run into
when designing complex GTK stuff. An extremely nasty thing, I had it
multiple times in my GtkAda projects. On-line help is the last thing that
would assist you here. I would use tracing to catch it.

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