Re: GPS issues: laundry list

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

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

> Maybe. But it is still an incredibly bad idea to manage versions by
> altering file names.

You have misunderstood what I'm proposing; I'm not editing file _names_,
just what directory the project is checked out in.

For version 07, the project is in mms_version_07/*. For version 08, the
project is in mms_version_08/*.

How else would you do it?

>>>>> 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.
>
> Didn't I? OK, the answer was no. I don't use Emacs (=> any feature of) and
> I don't plan to. 

"not using on a regular basis" is _not_ the same as "try it to see what
it's like".

I've tried vi, Eclipse, GPS, Visual *, all to be sure I'm not missing
anything in Emacs. I only use Emacs on a regular basis.

> I don't enjoy the very idea of "programming" source code in some kind
> of programming language. The idea the precursor generation of tools
> like Emacs, TeX et al represent. 

I don't understand this point. 

You seem to think that writing Ada code in Emacs is somehow
significantly different than writing Ada code in GPS; I don't find it to
be so. Except that the eye candy in GPS is distracting, but I suspect
I'll get used to it.

Writing documents in LaTeX is significantly different than writing
documents in OpenOffice; markup vs WYSIWYG. But that's not what _this_
thread is about.

> I prefer to concentrate my weak mental powers solely on typing and
> gazing Ada.

What else does Emacs require you to do?

You don't _have_ to write elisp to use Emacs, just as you don't _have_
to write Python and XML to use GPS. 

>>> 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.
>
> That is because you use Emacs as a programming language. 

No, I use elisp as a programming language, to customize Emacs.

> GPS is an IDE, it is not a language. 

Correct. But I can customize it by writing Python and XML, so I want
adequate documentation to help me do that.

> It presumes and encourages an amateurish, casual usage, which is good.

Nothing prevents you from using Emacs in that way.

I'll agree the default settings in Emacs are not as friendly as the
default settings in GPS, so it helps if someone gives you a better set.
That's what I do for my team at work.

>> 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.
>
> Modern-time systems became too complex for a comprehensive up-front dry
> training.

It did not say anything about "training"; manuals can be read straight
thru, but mostly they are searched for information on a particular
topic, as that topic comes up.

>> 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.
>
> In my GtkAda programs I hook Glib.Messages, which causes an error window to
> pop up with the source code location trace.
>
> The problem is that for GTK the actual error location is never the point
> where the error was detected. This is a problem of any event-driven
> framework.

Yes. In Emacs, you can also run elisp in debug mode, step by step, and
watch what happens, examine variables.

-- 
-- Stephe