[Emacs-ada-mode] updated ada-mode with manual

[The masked-coder known as Randux]

Hi guys,

> > I don't understand where this is going...gvd is a GUI (running on
> > top of gdb) specifically designed for source level debugging GNAT
> > Ada. Since I saw that ddd was mentioned in the doc and gvd was not
> > mentioned, I suggested we include some information on gvd 
> 
> I don't think Emacs ada-mode needs to talk about ddd or other GUI
> debugger interfaces, either. I just haven't gotten to deleting them
> yet. 

Alright.  On the other hand there is an option to "Debug" from Ada mode so if the option will remain then the user should understand how to customise it to use his preferred debugger, don't you agree?

> > as it's certainly more preferable/usable than ddd when the topic is
> > GUI debuggers for Ada. GPS is not better than gvd- GPS is the IDE,
> > gvd is just the GUI for gdb...two completely different animals. 
> 
> GPS includes the GUI from gvd; gvd was the first version of GPS. 

The gvd I'm talking about is a debugger only and could never be confused with an IDE! That's not to say that they can't rename things as they wish. Alright then, enough about that.

> >> I gather you mean typing C-c C-c in hello_a compiles A, then in
> >> hello_b compiles B, then in hellow_a compiles b again.

No, actually it was simpler than that and even worse:

C-c in helloa compiles helloa
C-c in hellob compiles helloa

> >> That's not a bug, that's a feature. It is useful in the much more
> >> common case of multiple file projects.
> >> 
> >> I proposed one change related to this:
> >> 
> >>     I'd also like to add a menu command "set main" to just set the
> >>     main file.
> >> 
> >> Would that fix the problem?
> >
> > I thought we agreed earlier that it was "unexpected behavior" and
> > you were planning to fix it. 
> 
> Yes, I did say that. But I always reserve the right to change my mind
> :). In this case, I thought one reasonable fix was user education via
> a better ada-mode manual.
> 
> > I don't think adding a requirement for the user to do something
> > extra is a fix for this- it's not very intuitive that when I'm
> > looking at a buffer and press C-c C-c that it should just build
> > anything other than what I'm looking at. 
> 
> Well, if you are used to building projects that have more than one
> file, it's _very_ intuitive! It would be completely wrong to invoke
> gnatmake on the file I happen to have edited last, rather than on the
> main file.

How could it be considered intuitive that when I'm editing a main file other than the one I built last, then when I select Build it should build anything but my new main file?  That's absolutely broken and abnormal behaviour.  If there's a precedent for this in any other IDE!

In my scenario, the file I've edited last *is* my main file. If Ada-mode is going to be "intelligent" then why should I have to tell it I'm working with a new main file?   If it doesn't handle this automagically then I'm back to having one Emacs session per project (or in the case of standalone programmes one Emacs per programme) or playing games figuring how to tell "the IDE" which is my latest main file.  I hope you'll reconsider this position.

> > If this isn't a usability flaw of the highest order, then I can't
> > think of a better example!
> 
> Again, I see it as a case of incorrect user expectations, which
> requires education.

I don't agree at all.  I've edited main program A and built it, now I start editing program B and when I ask ada-mode to build (after all, C-c C-c is "Build" is it not?) it builds the previous programme?  That's unprecented behaviour and a broken IDE.  

If ada-mode is to function as a true IDE (and this is not my preference) then I believe it should function as a true IDE.  We should see the project name clearly shown on the screen at all times, and the user should be required to do some action to add his source file to the project.  This is how other IDEs work, is it not?  But because project associations are not managed fully or properly by ada-mode, but rather by manual editing of project files, we've created artificial usability problems that shouldn't exist (and don't, in other IDEs.)

I feel we should have a fresh look at this and decide how things really should work from beginning to end- and then do something organised and proper- instead of patching or building on top of something which seems more and more broken.  I've said I'm very much opposed to the idea turning Ada-mode into an IDE. But if that's the group's decision I'll support everyone fully.  In that event everything should be done very simply so that people can go from any established IDE to Ada-mode without having to be "educated" on using Ada mode. 

I can use Code::Blocks or DevC++ or CodeWarrior without building the wrong module, so I don't think it's just me ;)

> >> If not, what, specifically, would you like to change in the Emacs
> >> ada-mode menu? And how would it impact compiling multiple-file projects?
> >
> > As I've mentioned, not only am I not qualified to speak on the topic
> > of multi-file Ada projects, 
> 
> Ok, you'll have to leave that to the rest of us. But you are asking me
> to break ada-mode for multi-file projects; that isn't going to happen.

I am certainly not asking for that. It seems obvious from the outside that the current project file scheme of doing things manually is unworkable and very unlike any other IDE, but that somehow we've decided that this structure has to be maintained whether or not it makes sense.

Either Ada-mode is smart enough to figure out when a new main is being edited/created, etc. and caters for the necessary bits; if things are not automatic, then the programmer expects that Ada-mode does what he tells it (build *this* module).  It seems to me that we're standing on how things were in the past...if we've an opportunity to revisit the issue I should think it would be better to think how it really should work instead of allowing what was perhaps not a fully thought-out design to constrain the future.  I'm sure doing this is a grand undertaking but it certainly never pays to build on anything but a proper foundation.

> >> > Also uncomment seems broken (but was also broken in the ada-mode
> >> > supplied in Emacs 21.4). 
> >> 
> >> Yes, it does not delete the correct number of spaces.
> >
> > For me it's totally broken.  It does nothing at all except produce this error message:
> >
> > Wrong type argument: number-or-marker-p, (-1)
> 
> That's some installation problem, or a bug in your .emacs.
> 
> Can you start with emacs -q, then open an Ada buffer, and try it? that
> will be with the Emacs distribution version of ada-mode. If that
> works, try commenting out stuff in your .emacs to see if you can
> isolate it.

Yes I'll do this and report back.

Cheers,
Rand