Re: GPS issues: laundry list

[Stephen Leake <stephen_leake@stephe-leake.org>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Thu, 13 Sep 2012 06:55:11 -0400, Stephen Leake wrote:
>
> 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.

As usual, since you don't have a good answer to the original question,
you are changing the question. You seem to have some good ideas; it is a
shame it is so frustrating attempting to have a conversation with you.

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

Say what? That's exactly why I use glob matching; I only remember that I
want a file that deals with "star tracker", I don't remember the
complete name of the file.

On the other hand, I do use a strict naming convention, that helps a
lot.

And I do seem to remember details better than anyone else on my team.

>>> 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! (:-))

As usual, not actually answering the question.

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

As I indicated in my post, non-searchable help is the biggest problem
with GPS. I use Emacs help all the time, to find out what a particular
function does, or how to go about doing something I haven't done before.

In my real job, I spend quite a bit of time making sure the manuals that
describe our system are correct and up to date. That way, i can just
refer people to the manuals, and don't have to spend time answering the
same questions over and over. The time spent maintaining the manuals is
_very_ well spent! I expect the same from help systems, especially
commercially supported ones.

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

As I understand it, adding simple monotone support is mostly adding
python and XML, so that counts as "writing GUI code".

>> Have you tried to debug the crash you describe above?
>
> No, it freezes.

Ok, there are time when emacs freezes as well, and you are right, online
help is no help then.

But the main point here is this:

> Since GPS is a GTK application, its debugging must be a nightmare, even if
> you know the internals of GPS very well. 

That is _precisely_ why Emacs is better; debugging elisp is _not_ a
nightmare, _because_ it is an interactive system; you can always find
out what function a key invokes, you can find the source code that
implements that function, you can find the source code for all the
functions that calls. And then you can modify one function, and see the
results immediately, without quiting and recreating the current situation.

You get some of that with Ada source code navigation, if you have the
GPS source code compiled, and that project open in GPS. Of course, you
can only have one project open at a time (how limiting!). And you can't
recompile and load just one function.

I suspect the reason you prefer to code in Python and XML is because
they are interactive; you don't have to quit and restart GPS to see the
changes, so you can make small, incremental changes quickly.

-- 
-- Stephe