This is a simple question

This is a simple question

[Stephen Cole]

I am learning Ada from John Barnes book, Programming in Ada95, 2nd Edition.
Everything I've read that has confused me I've tried out using GNAT compiler
3.13p and then I understood.

However, I have two questions.

1)
If I want to make some child functions/procedures (which I understand is
allowable) rather than a child package, how do I name the file in order to
feed it into GNAT? Do I have to create a separate Specification file for
each procedure/function declaration? And then a separate Body file for each
specified function/procedure??

2)
On page 252 of the book (towards the bottom of the page) he points out
that -

    with P1.P2;    use P1;     use P2;    -- illegal

But

    with P1.P2;    use P1;    use P1.P2;    -- legal

But I have tried this with GNAT and both approaches work! Am I
miinterpreting what he is trying to say??

Thanks

Re: This is a simple question

[Florian Weimer]

"Stephen Cole" <s_k_cole@yahoo.com> writes:

> 1)
> If I want to make some child functions/procedures (which I understand is
> allowable) rather than a child package, how do I name the file in order to
> feed it into GNAT?

The usual library unit name translation rules apply.  The declarations
gets the '.ads' suffix, and the completion (if necessary) the '.adb'
suffix.

(If you are not sure, you can put your source code into an arbitrary
file and process it with gnatchop.)

> Do I have to create a separate Specification file for each
> procedure/function declaration?

This depends on the compiler flags.  It is generally a good idea to
supply these declarations.

> But I have tried this with GNAT and both approaches work!

This seems to be a defect in GNAT.

Re: This is a simple question

[Stephen Cole]

Thanks for the answer so quickly. I shall investigate gnatchop. My confusion
is really in trying to apply the naming scheme for packages to files that
only contain functions/procedures. That is, files that do not contain the
"package <name> is....end <name>;" unit declaration wording or the
"separate(<package name>)" unit declaration wording. So stand on their own.

The problem is the gnat compiler will only accept one compilation unit per
file. Because what I am playing at seems to make a single function/procedure
into a single compilation unit, I seem to be incuring the inefficient
situation of requiring a file for each function declaration and then
definition.

My real question is whether this is indeed the case, and that if you don't
use packages you will always have this situation. Is this the case with all
Ada compilers? I come from a background of 'C' and am used to the #include<>
nature of things. The idea of packages seems to adstract the native file
system to another level (packages) and allows the compiler implementation to
determine where files are on the host computer. Is this so?

As for question 2. from reading this newsgroup I get the impression that
there are quite a few "bugs" in gnat?! Is this a fair appraisal? Or is it
user problems? I know gnat is freeware so maybe this is natural. Is this the
case with more proven/certified compiler systems? I am just trying to get a
feel for how high-integrity Ada is in real life. Is Ada in real life as good
as Ada theoretical could be? Is there a grading system to Ada compiler
technologies?

I am a newbee so please forgive my aggressive questioning.

"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:87zo762rta.fsf@deneb.enyo.de...
> "Stephen Cole" <s_k_cole@yahoo.com> writes:
>
> > 1)
> > If I want to make some child functions/procedures (which I understand is
> > allowable) rather than a child package, how do I name the file in order
to
> > feed it into GNAT?
>
> The usual library unit name translation rules apply.  The declarations
> gets the '.ads' suffix, and the completion (if necessary) the '.adb'
> suffix.
>
> (If you are not sure, you can put your source code into an arbitrary
> file and process it with gnatchop.)
>
> > Do I have to create a separate Specification file for each
> > procedure/function declaration?
>
> This depends on the compiler flags.  It is generally a good idea to
> supply these declarations.
>
> > But I have tried this with GNAT and both approaches work!
>
> This seems to be a defect in GNAT.

Re: This is a simple question

[Ted Dennison]

In article <9pkc0r$m5j$1@trog.dera.gov.uk>, Stephen Cole says...
>As for question 2. from reading this newsgroup I get the impression that
>there are quite a few "bugs" in gnat?! Is this a fair appraisal? Or is it

There are quite a few bugs in pretty much *any* large program, including all
compilers. The difference with Gnat is that it has lots of users, and is Free
Software, so discussion goes on about it in the open. This has nothing at all to
do with Ada. Go check out the GCC mailing list, and you'll see that the vast
majority of the talk there is about bugs. 

Generally I find that Gnat has *less* problems compling complicated
constructions than other Ada compilers I have used. Certianly no compiler bugs
that I have encountered in it in the last 5 years are what I would consider
"serious". Versions of it have been succesfully run through the Ada validation
suite, and have passed more of its tests than any other compiler. But it does
still have some minor problems in rarely-used areas.

p.s. One piece of advice: As a beginner, you would probably be much better off
avoiding the "use packagename;" clause altogether. Its very contraversial, as it
makes your source code less explicit. I don't ever use it, and most of the
projects I've worked on had that written into the coding standards (without my
help). But many other people whose opinions I respect feel its OK in certain
circumstances. When you have learned the language better you can make the choice
for yourself as to when its appropriate, but for now don't use it. 

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: This is a simple question

[Marin David Condic]

The GNAT compiler relies on the file system to implement its "library" and
needs the time stamp information, etc, for the files to tell what is out of
date. Not all compilers work this way. Once you get used to it, it works
reasonably well. If you're using AdaGide as your development environment, it
can handle a whole bunch of separate little files reasonably well and will
invoke the compiler properly and all that good stuff, so don't worry too
much about yours specs and bodies being in separate files.

If you simply like to edit a large, single file containing lots of functions
and procedures (typical C style) you can do that too. (Although you have to
get used to the fact that you shouldn't be trying to force Ada to be C.
Learn to use it the way it is intended. However when you're starting out,
its natural to do things the way you always have, so don't agonize too much
initially. Just learn the language and over time you'll start to understand
"The Ada Way".)

Go ahead and edit everything in one file (I usually use a .CHOP extension
just ro remind me.) When you have the file the way you want it, type at the
DOS command prompt "gnatchop -w My_File.Chop" and it will automagically bust
everything up into individual files and give them the proper names. You can
then type "gnatmake My_Main_Program" and it will go figure out what needs to
be recompiled and just do it. If you keep the editor in one window and the
MS-DOS prompt available in another window, it is only slightly less
convenient than using AdaGide with everything in separate files. Just
edit/save/chop/compile as needed. (This could be an added capability of
AdaGide? Hitting the "Compile" button on a .CHOP file causes a
Save/Chop/Compile action?)

However, I think you'll discover that it is a bit easier to just work with a
directory full of relatively small files. Get used to AdaGide and you may
begin to like the way it works. That, and you get the ability to highlight
something and jump to its declaration, which can be pretty handy when
working with a large collection of units.

I'd like to see an IDE that has a representation of all the library units in
an Ada directory/library on the side - sort of like MSVC++ or CodeWright. It
would make navigation a little easier.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Stephen Cole" <s_k_cole@yahoo.com> wrote in message
news:9pkc0r$m5j$1@trog.dera.gov.uk...
> Thanks for the answer so quickly. I shall investigate gnatchop. My
confusion
> is really in trying to apply the naming scheme for packages to files that
> only contain functions/procedures. That is, files that do not contain the
> "package <name> is....end <name>;" unit declaration wording or the
> "separate(<package name>)" unit declaration wording. So stand on their
own.
>
> The problem is the gnat compiler will only accept one compilation unit per
> file. Because what I am playing at seems to make a single
function/procedure
> into a single compilation unit, I seem to be incuring the inefficient
> situation of requiring a file for each function declaration and then
> definition.
>
> My real question is whether this is indeed the case, and that if you don't
> use packages you will always have this situation. Is this the case with
all
> Ada compilers? I come from a background of 'C' and am used to the
#include<>
> nature of things. The idea of packages seems to adstract the native file
> system to another level (packages) and allows the compiler implementation
to
> determine where files are on the host computer. Is this so?
>
> As for question 2. from reading this newsgroup I get the impression that
> there are quite a few "bugs" in gnat?! Is this a fair appraisal? Or is it
> user problems? I know gnat is freeware so maybe this is natural. Is this
the
> case with more proven/certified compiler systems? I am just trying to get
a
> feel for how high-integrity Ada is in real life. Is Ada in real life as
good
> as Ada theoretical could be? Is there a grading system to Ada compiler
> technologies?
>
> I am a newbee so please forgive my aggressive questioning.

Re: This is a simple question

[David Bolen]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> I'd like to see an IDE that has a representation of all the library units in
> an Ada directory/library on the side - sort of like MSVC++ or CodeWright. It
> would make navigation a little easier.

For users of Emacs, then the speedbar can pretty much handle this,
browsing files but also parsing the files to display subprograms and
such, and a single click on an entry loads the file to the appropriate
spot.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l@fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/

Re: This is a simple question

[Marin David Condic]

I keep hearing how wonderful EMACS is. My experience with it on various Unix
systems doesn't seem to impress me with its overall wonderfulness. I keep
thinking it must be hiding its lamp under a bushel basket. I tried to
download and run a version of it on WinNT/PC. It wouldn't compile and I
didn't have time or incentive to want to mess with it. Maybe its lamp is
under a bushel basket that is burried in a cave somewhere? :-)

Quite possibly EMACS is the ultimate solution. However, AFAIK, there isn't
some sort of Ada-ized version of it available as a .exe for WinNT that can
be simply downloaded, install-shielded and executed. OTOH, you've got
AdaGide that satisfies that set of criteria. Since I'm not currently doing
Ada development for a living, its easier to use AdaGide for the handful of
things for which I *am* using Ada and it doesn't seem to involve nearly the
amount of fuss. If one of the EMACS proponents has a version that is as
automagic as AdaGide to get up and running and wants to put it on a website
somewhere, I'd be glad to take it out for a test drive. Mind you: I'll treat
it like the typical software end user who doesn't want to "understand" it -
just "use" it right out of the box. Anything more complex than unzipping and
install-shielding will be met with verbal abuse! :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"David Bolen" <db3l@fitlinxx.com> wrote in message
news:uvght96z0.fsf@ctwd0143.fitlinxx.com...
>
> For users of Emacs, then the speedbar can pretty much handle this,
> browsing files but also parsing the files to display subprograms and
> such, and a single click on an entry loads the file to the appropriate
> spot.
>

Re: This is a simple question

[Ted Dennison]

In article <9pvdp5$8im$1@nh.pace.co.uk>, Marin David Condic says...
>thinking it must be hiding its lamp under a bushel basket. I tried to
>download and run a version of it on WinNT/PC. It wouldn't compile and I
>didn't have time or incentive to want to mess with it. Maybe its lamp is

Wow. If you are trying to compile it, you are certianly going off on a
goose-chase. I've done that twice (on Unix systems), and always ended up with an
incredibly slow version after a lot of work.

You should follow the NT emacs link on my page. Download one of the "bin" or
"fullbin" distributions.

It comes with Ada bindings, so you should be cool there. There are newer ones
available with more features, but the ones it comes with are just fine for
starters.

If I remember correctly, it doesn't use installshield, but you really only have
to run one small executable to set up the registry for its use (no reboot).

As far as its virtues being well-hidden, perhaps that is the case. Certianly its
basic editing features are not somehow "zippier" than anyone else's (well, there
is the "transpose" keystroke :-) ). The big issue is all the advanced stuff it
can do.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: This is a simple question

[Ehud Lamm]

Ted Dennison <dennison@telepath.com> wrote in message
news:E1Iw7.21973$ev2.30673@www.newsranger.com...
>The big issue is all the advanced stuff it
> can do.

And the fact that you can use the same editor for Ada, Scheme, LaTeX etc.

The learning curve is pretty steep, and most of the advantages are only
manifest when you are working on a complicated system (e.g., goto definition
etc.)

That's why I prefer AdaGide for occasional use, and use it with my students.
If only it had better integration with the debugger...

Ehud Lamm

Re: This is a simple question

[James Rogers]

Ehud Lamm wrote:
> 
> Ted Dennison <dennison@telepath.com> wrote in message
> news:E1Iw7.21973$ev2.30673@www.newsranger.com...
> >The big issue is all the advanced stuff it
> > can do.
> 
> And the fact that you can use the same editor for Ada, Scheme, LaTeX etc.
> 
> The learning curve is pretty steep, and most of the advantages are only
> manifest when you are working on a complicated system (e.g., goto definition
> etc.)
> 
> That's why I prefer AdaGide for occasional use, and use it with my students.
> If only it had better integration with the debugger...

That is one of the reasons I like to use GRASP from Auburn University.
(www.eng.auburn.edu/grasp).

It is as easy to learn as AdaGide. It has a decent integration with the
debugger, and it allows the user to generate Control Structure
Diagrams right on the source screen.

One other advantage is that Grasp can be used for multiple languages.
It supports Ada, C, C++, Java, and VHDL.

Jim Rogers
Colorado Springs, Colorado USA

Re: This is a simple question

[Ehud Lamm]

James Rogers <jimmaureenrogers@worldnet.att.net> wrote in message
news:3BC35E72.BB1C3188@worldnet.att.net...
> Ehud Lamm wrote:
> >
> > That's why I prefer AdaGide for occasional use, and use it with my
students.
> > If only it had better integration with the debugger...
>
> That is one of the reasons I like to use GRASP from Auburn University.
> (www.eng.auburn.edu/grasp).
>

I like to use GRASP for visualizing programs. Never really tried using it as
an IDE. I never noticed its debugger integration. I'll check it out.

Ehud

GRASP (was Re: This is a simple question)

[Simon Wright]

James Rogers <jimmaureenrogers@worldnet.att.net> writes:

> That is one of the reasons I like to use GRASP from Auburn University.
> (www.eng.auburn.edu/grasp).
> 
> It is as easy to learn as AdaGide. It has a decent integration with the
> debugger, and it allows the user to generate Control Structure
> Diagrams right on the source screen.

And it also has (well, had last time I came in contact) an
idiosyncratic view of how code should be formatted. Made it a total
pain to use for development under any sort of source code control
system, I thought ..

.. though perhaps I was just put off by the fact that my work was done
in emacs, and a potential co-worker used GRASP. It was quite
impossible to see where his changes were.

Do you find the CSDs useful? I recently wrote a 200 line procedure
with no LOOPs, two IFs and a CASE (since removed into a dispatching
operation). The loops went into closed iterators -- so they were
_there_, of course, just not at the application level.

Re: GRASP (was Re: This is a simple question)

[James Rogers]

Simon Wright wrote:
> 
> James Rogers <jimmaureenrogers@worldnet.att.net> writes:
> 
> > That is one of the reasons I like to use GRASP from Auburn University.
> > (www.eng.auburn.edu/grasp).
> >
> > It is as easy to learn as AdaGide. It has a decent integration with the
> > debugger, and it allows the user to generate Control Structure
> > Diagrams right on the source screen.
> 
> And it also has (well, had last time I came in contact) an
> idiosyncratic view of how code should be formatted. Made it a total
> pain to use for development under any sort of source code control
> system, I thought ..

This is somewhat controllable. The automatic fomatting can be
customized to an extent. Formatting only happens when you generate
CSDs. The source file is only changed if you save after reformatting.
If you do not save, you do not suffer source code control confusion.

> 
> .. though perhaps I was just put off by the fact that my work was done
> in emacs, and a potential co-worker used GRASP. It was quite
> impossible to see where his changes were.

This might have revealed a limitation of the process you used.
I have found it both reasonable and helpful to document all changes
in comments. Source code control systems may be able to 
identify many changes. They cannot identify the reasons for the
changes. The changes should be a response to a documented 
requirement.

> 
> Do you find the CSDs useful? I recently wrote a 200 line procedure
> with no LOOPs, two IFs and a CASE (since removed into a dispatching
> operation). The loops went into closed iterators -- so they were
> _there_, of course, just not at the application level.

In general, yes. Most code does contain some combination of loops,
conditionals, type definitions, variable definitions, exception
handlers, and possibly multiple return statements in a subprogram.
CSDs do help identify these features without causing you to carefully
read the code. I find CSDs helpful when preparing for code
reviews.

Jim Rogers
Colorado Springs, Colorado USA

Re: GRASP (was Re: This is a simple question)

[Simon Wright]

James Rogers <jimmaureenrogers@worldnet.att.net> writes:

> This might have revealed a limitation of the process you used.  I
> have found it both reasonable and helpful to document all changes in
> comments. Source code control systems may be able to identify many
> changes. They cannot identify the reasons for the changes. The
> changes should be a response to a documented requirement.

Some of this is so right, and some of it is so wrong!

One invaluable feature of a sccs (I use CVS) is that it can show you
_exactly_ what changed. Only after that need you check up as to why.

Suppose my potential coworker had accidentally changed a "+" to a "-"
somewhere in a 200-line file that he'd completely reformatted. My
chances of spotting that (his chances, come to that) would be close to
zero.

I completely agree that you need to document the reasons for change,
in the VC log works for me. The concept of "documented requirement"
seems just slightly foreign to that of "volunteer open-source
project", though!

-- 
Simon Wright                         Email: simon.j.wright@amsjv.com
Alenia Marconi Systems                     Voice: +44(0)23 9270 1778
Integrated Systems Division                  FAX: +44(0)23 9270 1800

Re: GRASP (was Re: This is a simple question)

[M. A. Alves]

> . . . The concept of "documented requirement"
> seems just slightly foreign to that of "volunteer open-source
> project", though!

Yes, and that is why you cannot measure the quality of an open-source
product.

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150 PORTO, Portugal        mob 351+939354002

Re: GRASP (was Re: This is a simple question)

[Simon Wright]

"M. A. Alves" <maa@liacc.up.pt> writes:

> > . . . The concept of "documented requirement"
> > seems just slightly foreign to that of "volunteer open-source
> > project", though!
> 
> Yes, and that is why you cannot measure the quality of an open-source
> product.

There is a difference between the formal "does it do what its
requirements say it should" and the informal "does it do what I need
it to", "do I trust the maintainer to keep going in a sensible
direction" etc.

Re: GRASP (was Re: This is a simple question)

[Matthew Woodcraft]

Simon Wright <simon.j.wright@amsjv.com> writes:

> James Rogers <jimmaureenrogers@worldnet.att.net> writes:
> 
> > This might have revealed a limitation of the process you used.  I
> > have found it both reasonable and helpful to document all changes in
> > comments. Source code control systems may be able to identify many
> > changes. They cannot identify the reasons for the changes. The
> > changes should be a response to a documented requirement.

[...] 
 
> I completely agree that you need to document the reasons for change,
> in the VC log works for me. The concept of "documented requirement"
> seems just slightly foreign to that of "volunteer open-source
> project", though!

I don't see why it should be. You'd have to let the volunteer
developers write their own requirements, of course, but there's
nothing to stop a project only accepting code if they do so.

-M-

Re: This is a simple question

[David Bolen]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> I keep hearing how wonderful EMACS is. My experience with it on various Unix
> systems doesn't seem to impress me with its overall wonderfulness. I keep
> thinking it must be hiding its lamp under a bushel basket. I tried to
> download and run a version of it on WinNT/PC. It wouldn't compile and I
> didn't have time or incentive to want to mess with it. Maybe its lamp is
> under a bushel basket that is burried in a cave somewhere? :-)

There are definitely binary distributions (I guess Ted pointed to one
in a separate response).  Normally you just manually unpack - it's not
a horrendous Windows application that needs to put all sorts of files
in the system directory, and the tiny (optional) tweak to the registry
is handled by a single executable, so as nice as InstallShield can be
its also overkill in this case.

Building from source is no mean feat, and definitely not to be
undertaken unless absolutely required.  Emacs may sometimes just be
called an "editor" but a small system it is not.

> Quite possibly EMACS is the ultimate solution. However, AFAIK, there isn't
> some sort of Ada-ized version of it available as a .exe for WinNT that can
> be simply downloaded, install-shielded and executed.

To Emacs, Ada is just another language binding that it supports, so
no, there isn't a specialized Ada-ized version of it.  That's not to
say that the Ada major-mode isn't as good as any other IDE at handling
Ada, only that it's just one of many to Emacs.

>                                                      OTOH, you've got
> AdaGide that satisfies that set of criteria. Since I'm not currently doing
> Ada development for a living, its easier to use AdaGide for the handful of
> things for which I *am* using Ada and it doesn't seem to involve nearly the
> amount of fuss.

I did take a look at AdaGide and it appears quite capable.
Interestingly enough, as an Emacs user, I have the opposite reaction
though - I hate using a tool that is only set up for one language.
Rather than switching to AdaGide when I'd want to do Ada, I just use
the same tool I already use for C, C++, Python, etc...  (I avoid the
VC++ IDE unless absolutely necessary too for example).

I'm not necessarily suggesting you'd want to switch to it just for
this.  It does have a decidedly steep learning curve, but more than
commensurate (IMO) with its underlying capabilities.  But I figured
I'd mention that it did handle the item you were asking for - for
those who may already using it.

>                 If one of the EMACS proponents has a version that is
> as automagic as AdaGide to get up and running and wants to put it on
> a website somewhere, I'd be glad to take it out for a test
> drive. Mind you: I'll treat it like the typical software end user
> who doesn't want to "understand" it - just "use" it right out of the
> box. Anything more complex than unzipping and install-shielding will
> be met with verbal abuse! :-)

I'm not sure I'd necessarily subject it to the "not want to
'understand' it" though - it's not a simple calculator or one purpose
tool.  It's a general purpose, extensible editor, that can be a very
powerful tool for a developer, but one which requires some investment
in time to harness and grow comfortable with.  Not altogether unlike
other development tools.  So sure you want to get up and running
reasonably fast, but I'd keep an expectation of working to learn the
system as the best way to reap the most benefits.

For me, over the years, my investment in Emacs as my primary
development editor and environment has paid off handsomely.  I've been
using Emacs as my sole development editor for the last 17 years or so
(first got introduced on a Tops-20 system), across at least 3-4 major
Emacs implementations, 4-5 major system types and even more variants
of Unix, working under a dozen or so languages, and even the majority
of my current local initialization file has been with me for over 10
years.  It's been around as long or longer than many of the languages
I use, not to mention most PC operating systems and even PCs.  I think
I've "touch-typed" Emacs editing commands for a while now :-)

It's just about the first package I'll install on any new system that
I may encounter that doesn't already have it.  I don't get stuck
worrying about WYSIWYG interfaces (I rarely touch a mouse within
Emacs, although it certainly supports it) and I'm more productive
inside of Emacs than any GUI IDE I've seen to date.

It might not be as flashy as modern GUI stuff (although the XEmacs
variant works harder along those lines), but it's immensely powerful
under the covers, virtually infinitely customizeable and extendable.

Heck, I'm writing this post from GNUS running inside of NT Emacs on my
NT 4 machine.  Thus, every bit of editing support that I have
available to me for development is also available while composing the
news messages - including writing test code snippets for posting and
compiling in a buffer to check them and then include output, all with
standard editor kill and yank commands and no mouse involvement.  And
I've been using the same newsreader interface inside of Emacs for
about 10 years across many systems :-)

The above isn't said to try to convert anyone (Editor battles are just
pointless), but just to try to give a flavor of how Emacs sort of
settles into your bones as a developer over time, and thus why its
die-hard users may make such a big deal about it.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l@fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/

Re: This is a simple question

[Marin David Condic]

"David Bolen" <db3l@fitlinxx.com> wrote in message
news:uelocpilj.fsf@ctwd0143.fitlinxx.com...
>
> There are definitely binary distributions (I guess Ted pointed to one
> in a separate response).  Normally you just manually unpack - it's not
> a horrendous Windows application that needs to put all sorts of files
> in the system directory, and the tiny (optional) tweak to the registry
> is handled by a single executable, so as nice as InstallShield can be
> its also overkill in this case.
>
Found a binary & got it to run. Still not as simple as an install-shield
that puts a little icon on your desktop, etc., but not horribly painful.
(I'd *still* suggest that if someone wants to promote it on a PC, that it
ought to install and look like a PC app, but that ends up a style war.)


>
> To Emacs, Ada is just another language binding that it supports, so
> no, there isn't a specialized Ada-ized version of it.  That's not to
> say that the Ada major-mode isn't as good as any other IDE at handling
> Ada, only that it's just one of many to Emacs.

It seemed to come up with an Ada menu option when I figured out how to open
up an Ada file - why no pop-up window with a file selection screen? (We're
back to bitching about it not looking like a Windows app.) And here's the
main gripe: After pointing it at an Ada file, it quite nicely opened it up
and managed to look like Notepad or any other standard issue text editor.
Gee. That's swell. Why not just use whatever standard-issue text editor
thats already on my system?

What I'd like for something that purports to be an IDE to do is let me point
it at a directory full of Ada files and have it put all those files off on a
column on the left with little plus signs that let me click on them and see
all the procedures within the packages, etc. EMACS is supposed to do this?
Again, if it does, it doesn't do it automatically and it doesn't have a
"Open Up A Directory Full Of Ada Files And Put Them In A Pannel On The Left"
menu entry. I suppose I could RTFM, but like I tried to point out - I'm
reacting here like a garden variety PC user - I don't want to *study* it - I
just want to *use* it.

>
> I did take a look at AdaGide and it appears quite capable.
> Interestingly enough, as an Emacs user, I have the opposite reaction
> though - I hate using a tool that is only set up for one language.
> Rather than switching to AdaGide when I'd want to do Ada, I just use
> the same tool I already use for C, C++, Python, etc...  (I avoid the
> VC++ IDE unless absolutely necessary too for example).
>
I'm not holding up AdaGide as an end-all, be-all of IDEs for Ada. What it
*does* do is provide a pretty simple editor that is integrated with the
compiler & debugger and looks like a basic PC app that an average PC user
can figure out without reading a manual. (At least to do the basic things
like edit/compile/link/run) EMACS may do all of that and so much more, but
it just isn't an *obvious* IDE for Ada.


>
> I'm not sure I'd necessarily subject it to the "not want to
> 'understand' it" though - it's not a simple calculator or one purpose
> tool.  It's a general purpose, extensible editor, that can be a very
> powerful tool for a developer, but one which requires some investment
> in time to harness and grow comfortable with.  Not altogether unlike
> other development tools.  So sure you want to get up and running
> reasonably fast, but I'd keep an expectation of working to learn the
> system as the best way to reap the most benefits.
>
Well, my harangue against EMACS stems from earlier discussions about using
it as the basis for an IDE for Ada - making a "kit" for Ada development that
starts to look like other "kits" for other languages. My objection is not
that EMACS lacks power (I'm told by people I trust that it has lots of
power - maybe too much power.) My objection is that as it currently stands,
it doesn't pop-up as an Ada-oriented IDE with fairly obvious
buttons/menus/icons/whatever that do the things one would typically want to
do with a library full of Ada stuff and do it in an
intuitively-obvious-to-the-casual-PS-oriented-observer way.


> For me, over the years, my investment in Emacs as my primary
> development editor and environment has paid off handsomely.  I've been
> using Emacs as my sole development editor for the last 17 years or so
> (first got introduced on a Tops-20 system), across at least 3-4 major
> Emacs implementations, 4-5 major system types and even more variants
> of Unix, working under a dozen or so languages, and even the majority
> of my current local initialization file has been with me for over 10
> years.  It's been around as long or longer than many of the languages
> I use, not to mention most PC operating systems and even PCs.  I think
> I've "touch-typed" Emacs editing commands for a while now :-)
>
I've used EMACS (and XEMACS) in various forms on Unix platforms before in
fairly casual ways and never really wanted to learn all of the details. I've
always felt it had a fairly UNIXey feel to it and sort of thought of it as
VI on steroids. From what I've seen of it lately and what others have said
about it, it looks like its an operating-system-wannabe. (Do I *really* need
it to do e-mail for me?) I suppose it would have its share of followers and
those willing to learn all of its ins and outs will be rewarded by the power
available to them, but if I were designing an Ada IDE, I'd do it very
differently. (Create all the clever powerful features you want, but make the
*basics* stand out as obvious and simple to use.)


>
> The above isn't said to try to convert anyone (Editor battles are just
> pointless), but just to try to give a flavor of how Emacs sort of
> settles into your bones as a developer over time, and thus why its
> die-hard users may make such a big deal about it.
>
I agree. I used to be a major TPU fan when I was still using VAX/Alpha/VMS
equipmentand learned all the ins and outs of using that. You end up liking
what you're used to using and what you've bothered to spend time learning. I
don't begrudge EMACS fans their editor of choice - more power to them. I
just wouldn't try to use it as the basis for an Ada IDE if I was building
one from bottom-dead-center with the goal of making a commercially viable
development kit. I'd want something that looked more like what PC developers
are used to seeing. I don't see EMACS fitting that description. Just my
opinion......

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: This is a simple question

[Ted Dennison]

In article <9q1lrp$e1q$1@nh.pace.co.uk>, Marin David Condic says...
>
>It seemed to come up with an Ada menu option when I figured out how to open
>up an Ada file - why no pop-up window with a file selection screen? (We're
>back to bitching about it not looking like a Windows app.) And here's the

Ted's mantra #5: "Different" /= "Bad".

Perhaps it is bad, if that's all you know how to operate and care how to learn
to operate. But one can actually find the proper file to open and open it lots
quicker the way Emacs does it. Hints:

When prompted for a file, you can hit a few characters and then TAB, and it will
try to complete the filename for you. If there are name clashes, it will fill in
the common part, you can then type the next character or two and hit TAB again
to get the rest. If you are confused about what the clash could be, hit TAB a
second time, and it will list the possiblities.

You can load a directory into a buffer ("open directory" from the menu). This
then works much like your "pop up" file dialog, except that it is *way* more
powerful, as all the normal editing commands work in it too. For instance, the
search commands are available (quite helpful in directories with lots of files).
This directory list buffer also stays available until you explicitly get rid of
it, rather than going away and making you surf around for it again later.

>main gripe: After pointing it at an Ada file, it quite nicely opened it up
>and managed to look like Notepad or any other standard issue text editor.
>Gee. That's swell. Why not just use whatever standard-issue text editor
>thats already on my system?

It should have added an "Ada" menu, which includes all the sorts of options you
were talking about. Are you sure it isn't there?

Also, most Ada users will probably want to turn on font-lock mode to get a
syntax-colorized buffer. (Go under "Help->Options" and select "Global Font
Lock").

There's also loads of other nifty stuff in there for even more advanced users.
You can get a list of them and their current bindings (if any) by selecting
"Help->Describe->Describe Buffer Modes" from the menu.

I don't think any of this stuff is really out of line compared to the difficulty
in figuring out how to use another full-featured development environment, like
VisualStudio.

>Well, my harangue against EMACS stems from earlier discussions about using
>it as the basis for an IDE for Ada - making a "kit" for Ada development that
>starts to look like other "kits" for other languages. My objection is not
>that EMACS lacks power (I'm told by people I trust that it has lots of
>power - maybe too much power.) My objection is that as it currently stands,
>it doesn't pop-up as an Ada-oriented IDE with fairly obvious
>buttons/menus/icons/whatever that do the things one would typically want to
>do with a library full of Ada stuff and do it in an
>intuitively-obvious-to-the-casual-PS-oriented-observer way.

Again, I don't think "looking like everyone else" is nessecarily a valid top
goal. Emacs' differences allow it to do more things. Sure, that makes it rough
on beginners. If beginners need some kind of rounded-scissors IDE, those exist
(even for Ada). 

What our point was, was that any attempt to make an environment for *serious*
users should be based on Emacs. Otherwise, you will spend loads of effort
duplicating (a small part of) what has been done before. Worse, when you are
done, you certianly won't have *all* the power of Emacs duplicated (it probably
has near a million man years invested in it), and serious users will be forced
back into Emacs as they find your features lacking. In the end, all your effort
will be wasted, as folks will just find ways to end-run your tools so they can
use Emacs. This isn't just theory, I've seen it happen on multiple projects. Its
frustrating to see good vendor tools (and all the time they spent working on
them) go to waste because they didn't bother to build around Emacs.

But it might indeed be a good idea to make some kind of Ada-specific bundle that
includes Emacs, the latest&greatest Ada mode, certian useful options changed
from their defaults (eg: colorizing), and a "getting started with Ada" buffer
that loads the first time Emacs is started. That would help out serious users
who aren't afraid to learn, but don't know where to start. I really don't think
it would take much more than that. I suppose if you really wanted to get fancy,
you could replace all the standard menus with ones of your own devising. You
could also rework Ada mode a bit to make it work more like what you are used to.
All the tools are there, you are just quibbling over their default presentation.

>don't begrudge EMACS fans their editor of choice - more power to them. I
>just wouldn't try to use it as the basis for an Ada IDE if I was building
>one from bottom-dead-center with the goal of making a commercially viable
>development kit. I'd want something that looked more like what PC developers
>are used to seeing. I don't see EMACS fitting that description. Just my

Again, that might sell copies to managers and beginners, but it would go unused
in the places I've worked, if it isn't integrated with Emacs. If some company
wants to try it, more power to them. But as a volunteer effort, we only have so
many voluteer hours available in this community. It'd be criminal to squander
them on reinventing wheels.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: This is a simple question

[Stephen Leake]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> <snip pointers to Emacs>
> Found a binary & got it to run. Still not as simple as an install-shield
> that puts a little icon on your desktop, etc., but not horribly painful.
> (I'd *still* suggest that if someone wants to promote it on a PC, that it
> ought to install and look like a PC app, but that ends up a style war.)

I think you have some valid points. It would be possible to configure
a version of Emacs that was more "Power Ada user friendly" out of the
box, and put it on AdaPower. It would mostly be a matter of turning on
the right set of features. Hmm. Actually, it could just be one elisp
file that you need to add to your .emacs.

ACT distributes a version of Emacs that supposedly has some
enhancements; I have not tried it because I have not found a
description of what those enhancements might be, and I _really_ don't
want to break my current Emacs stuff. It also comes with a DLL, so I
wonder if it works on Linux?

One problem with doing a different distribution of Emacs is you get
into arguments about what should be turned on by default. For example,
the "column of files on the side with + boxes" is provided by
speedbar. I don't use it, because I have better uses for the screen
space, and I like the other navigation mechanisms (goto body, goto
definition, regular file menu).

Hmm. I suggest anyone who is interested in this send a message to the
Emacs Ada mode mailing list (see http://www.ada-france.org/ada-mode/ ,
near the bottom of the page). That seems a more appropriate forum. If
there is enough interest, I'll volunteer to coordinate.

-- 
-- Stephe

Re: This is a simple question

[Ted Dennison]

In article <uvghn9qrq.fsf@gsfc.nasa.gov>, Stephen Leake says...
>One problem with doing a different distribution of Emacs is you get
>into arguments about what should be turned on by default. For example,
>the "column of files on the side with + boxes" is provided by
>speedbar. I don't use it, because I have better uses for the screen
>space, and I like the other navigation mechanisms (goto body, goto

Same here. I setup my system so that I can keep >80 columns of two buffers
side-by-side for reference purposes. I wouldn't have room for a speedbar, and
frankly get by fine without it. I think I could live if my emacs came with it by
default and I had to disable it, though.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: This is a simple question

[David Bolen]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> It seemed to come up with an Ada menu option when I figured out how to open
> up an Ada file - why no pop-up window with a file selection screen? (We're
> back to bitching about it not looking like a Windows app.)

Nothing wrong with wanting the GUI file selection, and I won't dispute
that if you want a GUI oriented editor, Emacs is probably the wrong base.

(In the below C- notation indicates Ctrl, and M- is Meta/ESC)

Me, I find the standard GUI file selection too intrusive during
development (and slow).  For Emacs, hit C-x, C-f, you get prompted for
a file and the current directory filled in - you can edit in the
prompt using normal Emacs editing commands.  At any point, hit ? and
you get a list of possible files in a pop-up buffer based on what
you've typed so far.  At any point hit TAB to auto-complete as much as
possible.  If you want to browse a directory, hit C-x d, select the
directory (same as for a file) and you get a buffer with a list of
files and single character commands on each file whether for editing
or even deleting.

Sure, all of this is text based - which BTW, in these days of massive
PCs and wasting modem connections just to pcAnywhere a full graphics
screen may not mean much, but boy is it faster in general and more
suitable to remote use in many cases.

>                                                            And here's the
> main gripe: After pointing it at an Ada file, it quite nicely opened it up
> and managed to look like Notepad or any other standard issue text editor.
> Gee. That's swell. Why not just use whatever standard-issue text editor
> thats already on my system?

Um, because their only similarly may be the fact that they are
displaying a text file in a similar visual way?  :-)

You're editing a text file (the Ada file), so why should it have to
look much different than a simple text display?  But compared to
Notepad there are probably over a thousand various text manipulation
and editing operations only a few keystrokes away.  Sure, basic
movement and inserting the occasional text is the same.  But once you
watch it auto-indent and format your source, get used to the higher
order movement commands that understand the program structure and so
on the others fall quickly back.  Particularly if you can learn to
forget that darn mouse that just slows things down :-)

> What I'd like for something that purports to be an IDE to do is let me point
> it at a directory full of Ada files and have it put all those files off on a
> column on the left with little plus signs that let me click on them and see
> all the procedures within the packages, etc. EMACS is supposed to do this?

Since that was my original small point, you should at least see what I
was talking about ;-)

M-x speedbar RET will present the speedbar on your current directory
as a separate frame.  The speedbar is a general purpose construct that
itself knows how to deal with a wide variety of files and language
types.  It'll list the files and you can expand to include elements
within the files and then jump right to them in the main buffer.

But for anyone still getting used to Emacs in general, I don't expect
that the Speedbar is going to change a point of view much.  It's text
too :-)

> Again, if it does, it doesn't do it automatically and it doesn't have a
> "Open Up A Directory Full Of Ada Files And Put Them In A Pannel On The Left"
> menu entry. I suppose I could RTFM, but like I tried to point out - I'm
> reacting here like a garden variety PC user - I don't want to *study* it - I
> just want to *use* it.

Yeah, I probably don't have a simple solution - I don't think anyone
will dispute that Emacs has a (potentially steep) learning curve.  And
there's no way you could come up with a single set of menu options
that would suffice.  And it's been too long from when I first used it
to be confident in judging how to learn it most efficiently.

I'd certainly start with its online tutorial (M-x help-with-tutorial
RET) and the online documentation (M-x info RET), but then it's just
use.  After a while of accustomization to basic editing commands
you'll find yourself discovering other commands and extending your use
of its capabilities a bit at a time until after a bit you'll find your
efficiency far higher than with any GUI environment I've ever tried.
But it takes time, and I would agree that a casual developer probably
isn't going to invest the necessary effort.  Nothing against that, but
its a professional tool - I don't think it would have the same payback
for casual use.

> I'm not holding up AdaGide as an end-all, be-all of IDEs for Ada. What it
> *does* do is provide a pretty simple editor that is integrated with the
> compiler & debugger and looks like a basic PC app that an average PC user
> can figure out without reading a manual. (At least to do the basic things
> like edit/compile/link/run) EMACS may do all of that and so much more, but
> it just isn't an *obvious* IDE for Ada.

I'd certainly agree.  It's not its focus.

> Well, my harangue against EMACS stems from earlier discussions about using
> it as the basis for an IDE for Ada - making a "kit" for Ada development that
> starts to look like other "kits" for other languages. My objection is not
> that EMACS lacks power (I'm told by people I trust that it has lots of
> power - maybe too much power.) My objection is that as it currently stands,
> it doesn't pop-up as an Ada-oriented IDE with fairly obvious
> buttons/menus/icons/whatever that do the things one would typically want to
> do with a library full of Ada stuff and do it in an
> intuitively-obvious-to-the-casual-PS-oriented-observer way.

Oh yeah certainly - at least not that final point.  Now true, if
someone were to really work on an Ada-oriented development mode for
Emacs it could be made to simplify pure Ada-related work to the point
of being much more accessible to a casual user (you can really control
the interface a lot from code), but it's not really the best match of
tool and purpose.

Now what might be sort of nice is if someone did an IDE that wrapped
around an optional external editor and included good support for
Emacs.  Some IDEs let you choose editing bindings that emulate Emacs,
but it's just not quite the same thing.

> I've used EMACS (and XEMACS) in various forms on Unix platforms before in
> fairly casual ways and never really wanted to learn all of the details. I've
> always felt it had a fairly UNIXey feel to it and sort of thought of it as
> VI on steroids. From what I've seen of it lately and what others have said
> about it, it looks like its an operating-system-wannabe. (Do I *really* need
> it to do e-mail for me?)

It depends - for me, I probably spend at least 60-70% of my time
composing (aka editing text) e-mail, 20-30% reading, and only a small
fraction doing management of folders and what not.  Seems fairly
natural to use an existing editing environment for that.

(To be fair, I'm stuck with Outlook at work and I hate it's lack of
editing capabilities - sometimes I cut and paste into an Emacs session
just to compose before pasting the response back.  On prior systems I
used mail packages like MM that automatically executed an external
editor for editing messages)

>                          I suppose it would have its share of followers and
> those willing to learn all of its ins and outs will be rewarded by the power
> available to them, but if I were designing an Ada IDE, I'd do it very
> differently. (Create all the clever powerful features you want, but make the
> *basics* stand out as obvious and simple to use.)

I'd agree with the goal.  I've just found that in my experience more
often than not an IDE designed to present itself as simple and obvious
rarely has the underlying depth to become more than simple and obvious
when you acclimate to that.  That's fine for occasional and casual
use, but it begins to fall down quickly for serious development, where
you quickly find yourself wanting to bypass all the friendly interface
stuff and just get the job done.

> (...)
> I just wouldn't try to use it as the basis for an Ada IDE if I was building
> one from bottom-dead-center with the goal of making a commercially viable
> development kit. I'd want something that looked more like what PC developers
> are used to seeing. I don't see EMACS fitting that description. Just my
> opinion......

I'd say that was fair, particularly for that goal.  My co-workers are
a good example.  Most of them use the VC++ IDE directly.  One who uses
an external editor uses CodeWright (nice GUI interface).  I may think
Emacs would be more efficient than eitherz, but it's not something I'm
going to try to put up against a GUI IDE or editor simply because it
doesn't fit the model of what PC developers want today.  Then we have
a casual operations guy who also does some code and is working on some
of our Python scripts - he's using the PythonWin IDE that comes with
Python, and there's no way I'd bother trying to get him up to speed on
Emacs instead - its benefits to him for the sort of work he does would
be limited.

It's important to apply the right sort of tool to the job (or goal).
But for a serious professional developer willing to invest time in
learning a tool, I think Emacs can more than pay it back over time.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l@fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/

Re: This is a simple question

[Florian Weimer]

David Bolen <db3l@fitlinxx.com> writes:

> Now true, if someone were to really work on an Ada-oriented
> development mode for Emacs it could be made to simplify pure
> Ada-related work to the point of being much more accessible to a
> casual user (you can really control the interface a lot from code),
> but it's not really the best match of tool and purpose.

I think GLIDE is a step into this direction.  At least after I
installed it, my Emacs look so different that I got rid of it
immediately. ;-)

Re: This is a simple question

[Stephen Leake]

David Bolen <db3l@fitlinxx.com> writes:

> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> <snip>
> I suppose I could RTFM, but like I tried to point out - I'm
> > reacting here like a garden variety PC user - I don't want to *study* it - I
> > just want to *use* it.
> 
> Yeah, I probably don't have a simple solution - I don't think anyone
> will dispute that Emacs has a (potentially steep) learning curve.  And
> there's no way you could come up with a single set of menu options
> that would suffice.  And it's been too long from when I first used it
> to be confident in judging how to learn it most efficiently.

One thing I find useful is subscribing to a newsgroup/mailing list,
where Emacs is discussed. I continue to learn new stuff all the time.

comp.emacs is overwhelmed with traffic; I suggest you use the Emacs
ada-mode mailing list instead. It currently has zero traffic, but I
promise to read it and respond as best I can! One of my missions in
life is to spread the word about Ada and Emacs :).

<snip>

-- 
-- Stephe

Re: This is a simple question

[Marin David Condic]

I really cannot understand that observation. There are applications programs
that have simple, graphical & menu doohickies to do simple things. There are
applications programs that have all kinds of powerful features if only you
want to memorize hundreds of ctrl-shift-alt-caps-lock-tab key sequences and
tricky command line interpreters. Explain to me why you can't build an
editor that has a "Compile"/Build"/"Link"/"Run" set of buttons and *also*
interprets ctrl-shift-alt-caps-lock-tab key sequences and a tricky command
line? You like being an editor power-user? Great! RTFM. You just want to
build a hello-world app and hit the "Run" button? Great! Here's your
cut-n-paste mousey editor with a "Run" button at the top. Why are the two
incompatible?

And I still don't see how you say to EMACS: "See that directory over there
full of Ada files? That's my project. Go open up my *project* and display
all the files on the left for me. Make sure I can click on the file of
interest and have it expand to show me all of the
functions/procedures/types/objects/whatever that are in it. Make sure I can
click on any one of those thingies and be put right in the text where its
at." That's the kind of thing that a few other IDEs I've used provide.
(Possibly, as Ted suggested, an IDE could be built that does this & then
gives you a choice of text editors to invoke on the file in question. But
that's not the same as saying "EMACS can be your IDE...")

I am not saying that EMACS can't edit Ada files and do spiffy Ada things.
What I'm saying is that it doesn't look like a standard PC application and
that it doesn't provide simple, obvious ways of getting simple, obvious
things done. As such I would think it would take too much work to make it
into an Ada IDE and/or the end result would likely be an attrocity that
would be very off-putting to many PC developers used to seeing looking a
certain way.

Sure. There will always be "power users" who will want millions of features
and be willing to read reams of documentation to become familiar with a
given tool. However, I think you can point at a much larger body of people
who just want to point and click and get a few simple things done. (Notepad
gets used by a *lot* of people even though it doesn't do much. What it
*does* do is obvious to any PC user - something EMACS lacks but might
possibly be able to have, had that been a design goal.) IMHO, EMACS suffers
from satisfying the power-user at the expense of failing to satisfy the
casual user. The two are not incompatible.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"David Bolen" <db3l@fitlinxx.com> wrote in message
news:uy9mj2do3.fsf@ctwd0143.fitlinxx.com...
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
>
> I'd agree with the goal.  I've just found that in my experience more
> often than not an IDE designed to present itself as simple and obvious
> rarely has the underlying depth to become more than simple and obvious
> when you acclimate to that.  That's fine for occasional and casual
> use, but it begins to fall down quickly for serious development, where
> you quickly find yourself wanting to bypass all the friendly interface
> stuff and just get the job done.
>

Re: This is a simple question

[Pat Rogers]

If the class browser for VisualSlickedit knew Ada better (it does somewhat)
you would have the best of both worlds -- it has emacs emulation, for
example.  I really like it.  I have the compilers integrated with the
buttons you mention, as well as integrated configuration management of my
choice and a host of other tools too.

If enough Ada people asked for better support they would work on it more.  I
just haven't had time to provide the feedback to them about the browser.

www.slickedit.com

Free demos for most operating systems are available.

(I am in no way affiliated with them.)


"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9q4bv3$okv$1@nh.pace.co.uk...
> I really cannot understand that observation. There are applications
programs
> that have simple, graphical & menu doohickies to do simple things. There
are
> applications programs that have all kinds of powerful features if only you
> want to memorize hundreds of ctrl-shift-alt-caps-lock-tab key sequences
and
> tricky command line interpreters. Explain to me why you can't build an
> editor that has a "Compile"/Build"/"Link"/"Run" set of buttons and *also*
> interprets ctrl-shift-alt-caps-lock-tab key sequences and a tricky command
> line? You like being an editor power-user? Great! RTFM. You just want to
> build a hello-world app and hit the "Run" button? Great! Here's your
> cut-n-paste mousey editor with a "Run" button at the top. Why are the two
> incompatible?
>
> And I still don't see how you say to EMACS: "See that directory over there
> full of Ada files? That's my project. Go open up my *project* and display
> all the files on the left for me. Make sure I can click on the file of
> interest and have it expand to show me all of the
> functions/procedures/types/objects/whatever that are in it. Make sure I
can
> click on any one of those thingies and be put right in the text where its
> at." That's the kind of thing that a few other IDEs I've used provide.
> (Possibly, as Ted suggested, an IDE could be built that does this & then
> gives you a choice of text editors to invoke on the file in question. But
> that's not the same as saying "EMACS can be your IDE...")
>
> I am not saying that EMACS can't edit Ada files and do spiffy Ada things.
> What I'm saying is that it doesn't look like a standard PC application and
> that it doesn't provide simple, obvious ways of getting simple, obvious
> things done. As such I would think it would take too much work to make it
> into an Ada IDE and/or the end result would likely be an attrocity that
> would be very off-putting to many PC developers used to seeing looking a
> certain way.
>
> Sure. There will always be "power users" who will want millions of
features
> and be willing to read reams of documentation to become familiar with a
> given tool. However, I think you can point at a much larger body of people
> who just want to point and click and get a few simple things done.
(Notepad
> gets used by a *lot* of people even though it doesn't do much. What it
> *does* do is obvious to any PC user - something EMACS lacks but might
> possibly be able to have, had that been a design goal.) IMHO, EMACS
suffers
> from satisfying the power-user at the expense of failing to satisfy the
> casual user. The two are not incompatible.
>
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
>
>
> "David Bolen" <db3l@fitlinxx.com> wrote in message
> news:uy9mj2do3.fsf@ctwd0143.fitlinxx.com...
> > "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> >
> > I'd agree with the goal.  I've just found that in my experience more
> > often than not an IDE designed to present itself as simple and obvious
> > rarely has the underlying depth to become more than simple and obvious
> > when you acclimate to that.  That's fine for occasional and casual
> > use, but it begins to fall down quickly for serious development, where
> > you quickly find yourself wanting to bypass all the friendly interface
> > stuff and just get the job done.
> >
>
>
>

Re: This is a simple question

[Georg Bauhaus]

In fact, you can use Ada/Emacs without ever touching the control key.
Say you are on Windows or OS/2, you may use drag and drop.
Of course you would have to know what folder icons on your
desktop are for and that you can drag things into applications,
which is not wide spread knowledge/usage AFAICT. There is a
quite comprehensive Ada menu for your mouse.

Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
: Explain to me why you can't build an
: editor that has a "Compile"/Build"/"Link"/"Run" set of buttons and *also*
: interprets ctrl-shift-alt-caps-lock-tab key sequences and a tricky command
: line?

With upcoming increased support of graphics facilities in GNU-Emacs (like
those present in X-Emacs), you should not only have graphical menus, but
also one-click "Run" buttons.

: And I still don't see how you say to EMACS: "See that directory over there
: full of Ada files? That's my project. Go open up my *project* and display
: all the files on the left for me. Make sure I can click on the file of
: interest and have it expand to show me all of the
: functions/procedures/types/objects/whatever that are in it.

That's the whole point of speedbar+ada-mode project files!
That it doesn not have Smalltalk capabilities yet is another
matter, but one can see this combination improving.
Then there is outline-minor-mode, too much forgotten I think!

: the end result would likely be an attrocity that
: would be very off-putting to many PC developers used to seeing looking a
: certain way.

I am still angry having to get used to these down-cut UI habits
transported to us from the MS "workability labs", myself coming from OS/2,
Oberon, and Plan 9. "It just works the simple ways we have recently
grown used to" will bring us back from houses to huts, as an
analogy :-) (I find hurs O.K. in times, but...
(Of course that goes for uninspired KDE tendencies as well.)

(There was actual software for a document centered approach.
Imagine that. Ada source code not restricted to plain monospaced
documentation comments...(That has been tried (e.g. noweb), but
you need a multi-syntax Editor... or some advanced document
construction facility that allows integration of differently
encoded programming project data (text, drawings, math, ...)
Does such a beast exist?)

: (Notepad
: gets used by a *lot* of people even though it doesn't do much. What it
: *does* do is obvious to any PC user - something EMACS lacks but might
: possibly be able to have, had that been a design goal.)

The only confusing thing in Emacs, if you look at it _without_ prior
sympathy or disgrace or even knowledge, is, I think, that  the File menu
is not where it is on your average Win box. (On OS/2 I do get
a system file open window, if I want one.)

There is _sooo_ much consulting money you can make just on the grounds
of users knowing things only by buttons. Sadly, this is observation,
not a joke ... (I can provide details, if you wish)

Georg

Re: This is a simple question

[Barry Kelly]

In article <9q4k5e$m9u$1@a1-hrz.uni-duisburg.de>
	Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:

> (There was actual software for a document centered approach.
> Imagine that. Ada source code not restricted to plain monospaced
> documentation comments...(That has been tried (e.g. noweb), but
> you need a multi-syntax Editor... or some advanced document
> construction facility that allows integration of differently
> encoded programming project data (text, drawings, math, ...)
> Does such a beast exist?)

Yes. The Delphi IDE with CodeRush.

-- Barry

Re: This is a simple question

[Florian Weimer]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> (There was actual software for a document centered approach.
> Imagine that. Ada source code not restricted to plain monospaced
> documentation comments...(That has been tried (e.g. noweb), but
> you need a multi-syntax Editor... or some advanced document
> construction facility that allows integration of differently
> encoded programming project data (text, drawings, math, ...)
> Does such a beast exist?)

There are Emacs meta-modes for use with literate programming tools.
These modes switch from one mode to another, depending on the position
of the point.

Re: This is a simple question

[Jean-Marc Bourguet]

Marin David Condic wrote:
[...]
> And I still don't see how you say to EMACS: "See that directory over there
> full of Ada files? That's my project. Go open up my *project* and display
> all the files on the left for me.

Does

M-x speedbar

do what you want?  I don't like this so I never use it.

>  Make sure I can click on the file of
> interest and have it expand to show me all of the
> functions/procedures/types/objects/whatever that are in it.

I don't known if it does that.  But Shift and the right mouse button
does
allow you to choose this kind of things in a menu.

> Make sure I can
> click on any one of those thingies and be put right in the text where its
> at." That's the kind of thing that a few other IDEs I've used provide.
> (Possibly, as Ted suggested, an IDE could be built that does this & then
> gives you a choice of text editors to invoke on the file in question. But
> that's not the same as saying "EMACS can be your IDE...")
> 
> I am not saying that EMACS can't edit Ada files and do spiffy Ada things.
> What I'm saying is that it doesn't look like a standard PC application and
> that it doesn't provide simple, obvious ways of getting simple, obvious
> things done. 

Simple and obvious are often synonymous of "what I'm used to".  I tend
to
get upset when C-A does not go to the start of the line (I'm typing this
into Netscape and C-A move the cursor to the start of the line and M-f
goes a word forward, ...)

> As such I would think it would take too much work to make it
> into an Ada IDE and/or the end result would likely be an attrocity that
> would be very off-putting to many PC developers used to seeing looking a
> certain way.

Emacs 21  goes probably in the direction you want about the look.

About the functionnality, it is probably not too much work for someone
who already know well emacs, the numerous modes available outside the
distribution and what you want.

> Sure. There will always be "power users" who will want millions of features
> and be willing to read reams of documentation to become familiar with a
> given tool. However, I think you can point at a much larger body of people
> who just want to point and click and get a few simple things done. (Notepad
> gets used by a *lot* of people even though it doesn't do much. What it
> *does* do is obvious to any PC user - something EMACS lacks but might
> possibly be able to have, had that been a design goal.) IMHO, EMACS suffers
> from satisfying the power-user at the expense of failing to satisfy the
> casual user. The two are not incompatible.

The first time I've used it was on VT100 connected to a PDP-10 and it
has
been mostly upward compatible since then (C-A, M-F worked like now). It
has
always paid more attention to satisfy its current user base than target
users
which did not use it yet. Not something I'll complain about.

Yours,

-- Jean-Marc

Re: This is a simple question

[Stephen Leake]

David Bolen <db3l@fitlinxx.com> writes:

> <snip long description of Emacs>

Me too. Good to hear from someone else who has Emacs in his bones :).

-- 
-- Stephe

Re: This is a simple question

[Florian Weimer]

David Bolen <db3l@fitlinxx.com> writes:

> Heck, I'm writing this post from GNUS running inside of NT Emacs on my
> NT 4 machine.

You are really using GNUS?  The old GNUS?  Wow.  Fortunately, when I
had Emacs and Usenet on the same system for the first time, Gnus was
already there, I think.  I remember using RMAIL for quite a long time
before switching to Gnus for mail, though.

Re: This is a simple question

[David Bolen]

Florian Weimer <fw@deneb.enyo.de> writes:

> David Bolen <db3l@fitlinxx.com> writes:
> 
> > Heck, I'm writing this post from GNUS running inside of NT Emacs on my
> > NT 4 machine.
> 
> You are really using GNUS?  The old GNUS?  Wow.  Fortunately, when I
> had Emacs and Usenet on the same system for the first time, Gnus was
> already there, I think.  I remember using RMAIL for quite a long time
> before switching to Gnus for mail, though.

Nah, I guess it's Gnus at this point.  But I'm pretty sure it was GNUS
when I first used it (news only, none of those other "backends") :-)

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l@fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/

Re: This is a simple question

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> I keep hearing how wonderful EMACS is. My experience with it on various Unix
> systems doesn't seem to impress me with its overall wonderfulness. I keep
> thinking it must be hiding its lamp under a bushel basket. I tried to
> download and run a version of it on WinNT/PC. It wouldn't compile and I
> didn't have time or incentive to want to mess with it. Maybe its lamp is
> under a bushel basket that is burried in a cave somewhere? :-)


I have been an avid EMACS user since the 80's. IMHO the GNU-Emacs does not
do EMACS justice. On the Prime 50 Series, EMACS was written in a subset
of PL/I (as much of Prime's software was), and in my mind at least, they
had the best implementation of EMACS on the planet. Too bad that GNU-Emacs
was not inspired more from it.

GNU-Emacs could be vastly improved by make one single change:
that is, support the ^C function that Prime's EMACS provided. ^C was
a "repeat last function" binding. It would repeat the last keystroke,
last macro, or last "whatever was done". When set up this way, you
could do something like "execute macro" once, and then just ^C as often
as required to repeat the function a few more times (there are better
ways to repeat hundreds+ of times however).  If you've never used this,
you don't know what a convenience you are missing (which is why I don't
use GNU-Emacs). I never had the time myself to investigate the effort
that would be needed to fit this feature into GNU-Emacs.

[BTW, if someone knows that this feature exists in GNU-Emacs, then all
that I would need is to re-bind the keys to my own tastes. However, AFAIK,
this capability is absent in GNU-Emacs, and probably requires considerable
effort to track the "last whatever was done" in order to repeat it upon
demand Note this also gets into how to handle getting user input and
how to handle cut and paste from the kill buffer]

What I have used is a heavily customized version of Micro-EMACS (with
some bugs added in ;-) ). I have a few Ada customized "scripts", but
nothing along the lines of what you are looking for.  I keep thinking
about doing a Micro-EMACS rewrite in Ada.. but time is not my friend
these days. The good thing about this old Micro-EMACS thing is that it
compiles just about anywhere, and fits one one 3.5" diskette.


> Quite possibly EMACS is the ultimate solution. However, AFAIK, there isn't
> some sort of Ada-ized version of it available as a .exe for WinNT that can
> be simply downloaded, install-shielded and executed. 


Yes, sadly true  :-(  AFAIK

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: This is a simple question

[Pascal Obry]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:

> GNU-Emacs could be vastly improved by make one single change:
> that is, support the ^C function that Prime's EMACS provided. ^C was
> a "repeat last function" binding. It would repeat the last keystroke,
> last macro, or last "whatever was done". When set up this way, you
> could do something like "execute macro" once, and then just ^C as often
> as required to repeat the function a few more times (there are better
> ways to repeat hundreds+ of times however).  If you've never used this,
> you don't know what a convenience you are missing (which is why I don't
> use GNU-Emacs). I never had the time myself to investigate the effort
> that would be needed to fit this feature into GNU-Emacs.

Not exactly what you want but:

        C-x (                             (start macro)
        <do whatever you want>
        C-x )                             (end macro)

        C-x e                             (repeat 1 time)

        C-u 100 C-x e                     (repeat 100 times).

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: This is a simple question

[Stephen Leake]

Pascal Obry <p.obry@wanadoo.fr> writes:

> "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
> 
> > GNU-Emacs could be vastly improved by make one single change:
> > that is, support the ^C function that Prime's EMACS provided. ^C was
> > a "repeat last function" binding. It would repeat the last keystroke,
> > last macro, or last "whatever was done". When set up this way, you
> > could do something like "execute macro" once, and then just ^C as often
> > as required to repeat the function a few more times (there are better
> > ways to repeat hundreds+ of times however).  If you've never used this,
> > you don't know what a convenience you are missing (which is why I don't
> > use GNU-Emacs). I never had the time myself to investigate the effort
> > that would be needed to fit this feature into GNU-Emacs.
> 
> Not exactly what you want but:
> 
>         C-x (                             (start macro)
>         <do whatever you want>
>         C-x )                             (end macro)
> 
>         C-x e                             (repeat 1 time)
> 
>         C-u 100 C-x e                     (repeat 100 times).

Note that this precisely defines "whatever was last done". It can be
one command, or several. I find that more Ada-like (just to bring this
vaguely back on topic :).

-- 
-- Stephe

Re: This is a simple question

[Warren W. Gay VE3WWG]

Pascal Obry wrote:

> "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
>>GNU-Emacs could be vastly improved by make one single change:
>>that is, support the ^C function that Prime's EMACS provided. ^C was
>>a "repeat last function" binding. It would repeat the last keystroke,
>>last macro, or last "whatever was done". When set up this way, you
>>could do something like "execute macro" once, and then just ^C as often
>>as required to repeat the function a few more times (there are better
>>ways to repeat hundreds+ of times however).  If you've never used this,
>>you don't know what a convenience you are missing (which is why I don't
>>use GNU-Emacs). I never had the time myself to investigate the effort
>>that would be needed to fit this feature into GNU-Emacs.
> 
> Not exactly what you want but:
> 
>         C-x (                             (start macro)
>         <do whatever you want>
>         C-x )                             (end macro)
> 
>         C-x e                             (repeat 1 time)
> 
>         C-u 100 C-x e                     (repeat 100 times).
> 
> Pascal.


But this is too inconvenient. I often want to repeat, not only

C-x e on a one off basis, but I may C-k or any other editing
command on an as needed basis. Repeating 100 times is fine if
you *know* that it is 100 times. But with much of the content
on successive (or prior) pages, this count requires extra effort
to identify (and sometimes requires mental calculations -- ugh).

Being able to repeat as you need it, while automatically paging
forward (or backwards) is too convenient for me to give it up.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: This is a simple question

[Larry Kilgallen]

In article <3BC48598.80703@home.com>, "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:

> GNU-Emacs could be vastly improved by make one single change:
> that is, support the ^C function that Prime's EMACS provided. ^C was
> a "repeat last function" binding.

In TECO I follow a command with *M to store that command in Q-register M
and then MM$$ to execute the command in Q-register M.

The original EMACS was written in TECO -- did they lose that along the
way, or was it added to TECO after EMACS split off ?

Re: This is a simple question

[Warren W. Gay VE3WWG]

Larry Kilgallen wrote:

> In article <3BC48598.80703@home.com>, "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
>>GNU-Emacs could be vastly improved by make one single change:
>>that is, support the ^C function that Prime's EMACS provided. ^C was
>>a "repeat last function" binding.
> 
> In TECO I follow a command with *M to store that command in Q-register M
> and then MM$$ to execute the command in Q-register M.
> 
> The original EMACS was written in TECO -- did they lose that along the
> way, or was it added to TECO after EMACS split off ?


When I used EMACS under PRIMOS (don't recall the version(s)),

AFAIK, it was all written in what they called SPL (System Programming
Language, which was simply a subset PL/I without the builtin I/O etc.)
I don't think I ever got around to using TECO.. I was too impressed
by EMACS, me-thinks. ;-)
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: This is a simple question

[Florian Weimer]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:

> GNU-Emacs could be vastly improved by make one single change:
> that is, support the ^C function that Prime's EMACS provided. ^C was
> a "repeat last function" binding. It would repeat the last keystroke,
> last macro, or last "whatever was done".

On GNU Emacs, the command is called 'repeat', and it's bound to 
'C-x z' by default, and for subsequent invocations of this command, 
'z' is sufficient.

> If you've never used this, you don't know what a convenience you are
> missing (which is why I don't use GNU-Emacs).

I find it hard to believe, but most vi users don't know the '.'
command, either.

Re: This is a simple question

[Pascal Obry]

Florian Weimer <fw@deneb.enyo.de> writes:

> "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
> 
> > GNU-Emacs could be vastly improved by make one single change:
> > that is, support the ^C function that Prime's EMACS provided. ^C was
> > a "repeat last function" binding. It would repeat the last keystroke,
> > last macro, or last "whatever was done".
> 
> On GNU Emacs, the command is called 'repeat', and it's bound to 
> 'C-x z' by default, and for subsequent invocations of this command, 
> 'z' is sufficient.

I did not know that ! Thanks :)

I know that this is not an Emacs NG...

Pascal.

PS: I do use GNUS too and VM for the e-mail.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: This is a simple question

[Ted Dennison]

In article <uvghns5b7.fsf@wanadoo.fr>, Pascal Obry says...
>I did not know that ! Thanks :)
>
>I know that this is not an Emacs NG...

It is a bit off-topic. But *any* newsgroup where software developers hang out is
an Emacs newsgroup. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: This is a simple question

[Warren W. Gay VE3WWG]

Pascal Obry wrote:

> Florian Weimer <fw@deneb.enyo.de> writes:
>>"Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
>>>GNU-Emacs could be vastly improved by make one single change:
>>>that is, support the ^C function that Prime's EMACS provided. ^C was
>>>a "repeat last function" binding. It would repeat the last keystroke,
>>>last macro, or last "whatever was done".
>>>
>>On GNU Emacs, the command is called 'repeat', and it's bound to 
>>'C-x z' by default, and for subsequent invocations of this command, 
>>'z' is sufficient.
> 
> I did not know that ! Thanks :)
> 
> I know that this is not an Emacs NG...
> 
> Pascal.


Really!?!? That's great. I'll install it and check this out. It

would be a simple matter for me to change the key bindings to
match my own tastes. Although, I might also get used to a new
keybinding... naw.. its been too many years! ;-)  Thanks!
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: This is a simple question

[Warren W. Gay VE3WWG]

Warren W. Gay VE3WWG wrote:

> Pascal Obry wrote:
>> Florian Weimer <fw@deneb.enyo.de> writes:
>>> "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
>>>
>>>> GNU-Emacs could be vastly improved by make one single change:
>>>> that is, support the ^C function that Prime's EMACS provided. ^C was
>>>> a "repeat last function" binding. It would repeat the last keystroke,
>>>> last macro, or last "whatever was done".
>>>>
>>> On GNU Emacs, the command is called 'repeat', and it's bound to 'C-x 
>>> z' by default, and for subsequent invocations of this command, 'z' is 
>>> sufficient.

Well, I tried it and its functionality is either broken, or left
wanting. What I found was that while it works good for simple things
(even their "complex repeat"), it did not work well for repeating
the last executed macro. The first time was OK, but (the broken part is)
then the "z" to repeat it subsequently would only execute the last
function performed within the keyboard macro. I think this is because
GNU emacs expands the macro (C-x e) and then plays it out as if it were
then typed in (ie. a "buffer trick".)

What I had hoped for was that the
same action would be completely repeated (C-x e). Instead,
what it repeated was
the last action within the macro that was played back.

So close, and yet so far... I won't discard MicroEMACS yet. :<
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: This is a simple question

[Georg Bauhaus]

Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:

:>>> On GNU Emacs, the command is called 'repeat', and it's bound to 'C-x 
:>>> z' by default, and for subsequent invocations of this command, 'z' is 
:>>> sufficient.
: 
: Well, I tried it and its functionality is either broken, or left
: wanting. What I found was that while it works good for simple things
: (even their "complex repeat"), it did not work well for repeating
: the last executed macro.

I'm not sure if I understand this. If it is the last keyboard
macro you want to call, then C-x e does this, repeatedly if you
want...

Georg

Re: This is a simple question

[Warren W. Gay VE3WWG]

Georg Bauhaus wrote:

> Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
> 
> :>>> On GNU Emacs, the command is called 'repeat', and it's bound to 'C-x 
> :>>> z' by default, and for subsequent invocations of this command, 'z' is 
> :>>> sufficient.
> : 
> : Well, I tried it and its functionality is either broken, or left
> : wanting. What I found was that while it works good for simple things
> : (even their "complex repeat"), it did not work well for repeating
> : the last executed macro.
> 
> I'm not sure if I understand this. If it is the last keyboard
> macro you want to call, then C-x e does this, repeatedly if you
> want...


Let me explain:  If you collect a macro with 3 steps in it, and

you execute it with C-x e, then this executes the 3 steps of the
macro (so far, so good). You then do C-x z, and it again executes
the equivalent of C-x e, which performs the 3 steps again. This
part is OK also. If you then now just do "z" (to further "repeat"),
only the last step of the 3-step macro is executed.  This is
where it falls down.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: This is a simple question

[Stephen Leake]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:

> Georg Bauhaus wrote:
> 
> > Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
> > :>>> On GNU Emacs, the command is called 'repeat', and it's bound to
> > 'C-x
> > :>>> z' by default, and for subsequent invocations of this command,
> > 'z' is :>>> sufficient.
> > : : Well, I tried it and its functionality is either broken, or left
> > : wanting. What I found was that while it works good for simple things
> > : (even their "complex repeat"), it did not work well for repeating
> > : the last executed macro.
> > I'm not sure if I understand this. If it is the last keyboard
> > macro you want to call, then C-x e does this, repeatedly if you
> > want...
> 
> 
> Let me explain:  If you collect a macro with 3 steps in it, and
> 
> you execute it with C-x e, then this executes the 3 steps of the
> macro (so far, so good). You then do C-x z, and it again executes
> the equivalent of C-x e, which performs the 3 steps again. This
> part is OK also. If you then now just do "z" (to further "repeat"),
> only the last step of the 3-step macro is executed.  This is
> where it falls down.

Ok. So keep doing C-x e. Or do C-u 5 C-x e to repeat it 5 times. Or
bind call-last-kbd-macro to a function key, say F3. Then you have a
single keystroke for repeating the last macro.

You seem to be saying "since I can't repeat a macro with a single
keystroke, I won't use Emacs". That seems a very narrow view!

-- 
-- Stephe

Re: This is a simple question

[Warren W. Gay VE3WWG]

Stephen Leake wrote:

> "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
>>Georg Bauhaus wrote:
>>>Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
>>>:>>> On GNU Emacs, the command is called 'repeat', and it's bound to
>>>'C-x
>>>:>>> z' by default, and for subsequent invocations of this command,
>>>'z' is :>>> sufficient.
>>>: : Well, I tried it and its functionality is either broken, or left
>>>: wanting. What I found was that while it works good for simple things
>>>: (even their "complex repeat"), it did not work well for repeating
>>>: the last executed macro.
>>>I'm not sure if I understand this. If it is the last keyboard
>>>macro you want to call, then C-x e does this, repeatedly if you
>>>want...
>>
>>Let me explain:  If you collect a macro with 3 steps in it, and
>>you execute it with C-x e, then this executes the 3 steps of the
>>macro (so far, so good). You then do C-x z, and it again executes
>>the equivalent of C-x e, which performs the 3 steps again. This
>>part is OK also. If you then now just do "z" (to further "repeat"),
>>only the last step of the 3-step macro is executed.  This is
>>where it falls down.
> 
> Ok. So keep doing C-x e. Or do C-u 5 C-x e to repeat it 5 times. Or
> bind call-last-kbd-macro to a function key, say F3. Then you have a
> single keystroke for repeating the last macro.
> 
> You seem to be saying "since I can't repeat a macro with a single
> keystroke, I won't use Emacs". That seems a very narrow view!

But.. but, I _am_ using Emacs. Just not the same flavour as you. The
other thing that this does say, is that this particular function is
extremely useful to me. This was something that was well recognized
by Prime's Emacs, which goes back to my first post on this subject.

Doing C-x e to repeat is much too slow. Binding it to F3 to compensate
for the weakness is not only a hack, its also inconvenient to reach,
and is a form of editor "modality". It works, but seems more like a
last resort to me.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: This is a simple question

[Matthew Woodcraft]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:

> Doing C-x e to repeat is much too slow. Binding it to F3 to compensate
> for the weakness is not only a hack, its also inconvenient to reach,
> and is a form of editor "modality". It works, but seems more like a
> last resort to me.

Indeed, this behaviour of repeat-on-final-keystroke after
call-last-kbd-macro is clearly just an emacs bug. I have reported it to
bug-gnu-emacs@gnu.org.

-M-

Re: This is a simple question

[Warren W. Gay VE3WWG]

Matthew Woodcraft wrote:

> "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
>>Doing C-x e to repeat is much too slow. Binding it to F3 to compensate
>>for the weakness is not only a hack, its also inconvenient to reach,
>>and is a form of editor "modality". It works, but seems more like a
>>last resort to me.
> 
> Indeed, this behaviour of repeat-on-final-keystroke after
> call-last-kbd-macro is clearly just an emacs bug. I have reported it to
> bug-gnu-emacs@gnu.org.
> 
> -M-


Thank you. I really do look forward to switching to GNU emacs someday,

but this "feature" is important to me. Is there an easy way/URL where I can
monitor the resolution of this "bug"? TIA.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: This is a simple question

[Matthew Woodcraft]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:

> Matthew Woodcraft wrote:
> > Indeed, this behaviour of repeat-on-final-keystroke after
> > call-last-kbd-macro is clearly just an emacs bug. I have reported it to
> > bug-gnu-emacs@gnu.org.
> > -M-
 
> Thank you. I really do look forward to switching to GNU emacs someday,
> 
> but this "feature" is important to me. Is there an easy way/URL where I can
> monitor the resolution of this "bug"? TIA.

They don't seem to have a proper bug-tracking system. You can see the
message in their mail archive at

http://mail.gnu.org/pipermail/bug-gnu-emacs/2001-October/007167.html

-M-

[OT] emacs

[Matthew Woodcraft]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:

> you execute it with C-x e, then this executes the 3 steps of the
> macro (so far, so good). You then do C-x z, and it again executes
> the equivalent of C-x e, which performs the 3 steps again. This
> part is OK also. If you then now just do "z" (to further "repeat"),
> only the last step of the 3-step macro is executed.  This is
> where it falls down.

[...]
 
> I really do look forward to switching to GNU emacs someday,

This is working properly now in Emacs 21.1.

-M-

Re: This is a simple question

[Georg Bauhaus]

Florian Weimer <fw@deneb.enyo.de> wrote:
 
: On GNU Emacs, the command is called 'repeat', and it's bound to 
: 'C-x z' by default, and for subsequent invocations of this command, 
: 'z' is sufficient.

Add to that (repeat-complex-command ARG), 'C-x ESC ESC', which allows
a selection from mini buffer commands.

(The first chapters of the Emacs manual were the first positive reading
experience of manuals for me. Not just because there is so many much needed
information in there :-)

Georg

Re: This is a simple question

[Pat Rogers]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9pkddm$afh$1@nh.pace.co.uk...
<snip>
> I'd like to see an IDE that has a representation of all the library units
in
> an Ada directory/library on the side - sort of like MSVC++ or CodeWright.
It
> would make navigation a little easier.

VisualSlick has that, although the Ada 95 support in the browser isn't
nearly as good as it is for C++, Java, etc...

www.slickedit.com

They have demo versions available for Windows and Un*x.


--
---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Re: This is a simple question

[Jacob Sparre Andersen]

Stephen:

> The problem is the gnat compiler will only accept one compilation unit per
> file. Because what I am playing at seems to make a single function/procedure
> into a single compilation unit, I seem to be incuring the inefficient
> situation of requiring a file for each function declaration and then
> definition.

I am not sure it is an inefficient solution. But it is
definitely a very Unix-like solution.

> My real question is whether this is indeed the case, and that if you don't
> use packages you will always have this situation. Is this the case with all
> Ada compilers?

No.

> I come from a background of 'C' and am used to the #include<>
> nature of things. The idea of packages seems to adstract the native file
> system to another level (packages) and allows the compiler implementation to
> determine where files are on the host computer. Is this so?

The package/procedure/function-file relation is a GNAT
specific thing.

If I remember correctly GNAT has a pragma, you can use to
specify that a compilation unit is in a file with another
name than the one GNAT derives from the name of the
compilation unit.

> As for question 2. from reading this newsgroup I get the impression that
> there are quite a few "bugs" in gnat?!

I am only aware of two apparent defects in the current
public version of GNAT. And only one of these is related to
actual compilation of Ada programs. The other one is a
_potential_ security hole in the compiler, when compiling on
multi-user systems.

This is actually quite close to a perfect system.

You should appreciate that there is openness about the few
remaining defects in GNAT.

> Is Ada in real life as good as Ada theoretical could be?

No - but that goes for any language whose formal definition
isn't a specific implementation of the language (and
probably also for some of those whose formal definition _is_
a specific implementation).

GNAT is for example not always as agressive in its
optimisation as it is theoretically and practically
possible.

> Is there a grading system to Ada compiler technologies?

There is an official "validation suite", which is supposed
to test if an Ada compiler is actually an Ada compiler, but
it is not exhaustive.

Jacob
-- 
"It is very easy to get ridiculously confused about the
 tenses of time travel, but most things can be resolved
 by a sufficiently large ego."

Re: This is a simple question

[Florian Weimer]

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> I am only aware of two apparent defects in the current
> public version of GNAT. And only one of these is related to
> actual compilation of Ada programs. The other one is a
> _potential_ security hole in the compiler, when compiling on
> multi-user systems.

There is also a security problem when using the standard Ada library
to create temporary files.  The version in the GCC CVS contains a fix
(for GNU/Linux) which should not be too hard to backport.

Re: This is a simple question

[Stephen Cole]

Thanks for those answers. And believe me I do appreciate the openness of
GNAT. Its far easier to deal with the "real-world" when you are dealing with
technology that is covered less in glitz and more in people picking at it
and exposing its trueness.

Is there a table of all the bugs discovered for any particular version of
GNAT? Is there anything like MSDN in existence? MSDN is not the most easily
navigable repository of information but at least it exists. Is there
anything equivalent in existence for GNAT?

Re: This is a simple question

[Florian Weimer]

"Stephen Cole" <s_k_cole@yahoo.com> writes:

> Is there a table of all the bugs discovered for any particular version of
> GNAT? Is there anything like MSDN in existence? MSDN is not the most easily
> navigable repository of information but at least it exists. Is there
> anything equivalent in existence for GNAT?

I think you have to ask the people behind sales@gnat.com these
questions.  These resources are not available to the public at the
moment, and only ACT can tell you which would be part of your support
contract.

Re: This is a simple question

[Ted Dennison]

In article <9q16bg$8lq$1@trog.dera.gov.uk>, Stephen Cole says...
>
>Thanks for those answers. And believe me I do appreciate the openness of
>GNAT. Its far easier to deal with the "real-world" when you are dealing with
>technology that is covered less in glitz and more in people picking at it
>and exposing its trueness.
>
>Is there a table of all the bugs discovered for any particular version of
>GNAT? Is there anything like MSDN in existence? MSDN is not the most easily
>navigable repository of information but at least it exists. Is there
>anything equivalent in existence for GNAT?

It comes with a reference manual, user manual, LRM, and Win32Ada bindings help.
It doesn't have anything that totally covers Win32 programming, but it would be
silly to duplicate MSDN when people can just use MSDN.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: This is a simple question

[Florian Weimer]

"Stephen Cole" <s_k_cole@yahoo.com> writes:

> My real question is whether this is indeed the case, and that if you don't
> use packages you will always have this situation. Is this the case with all
> Ada compilers?

No, other compilers use a source repository, but I doubt this is more
efficient than the GNAT approach.

Nowadays, file systems have no problems in dealing with a large number
of small files anyway.

> I come from a background of 'C' and am used to the #include<>
> nature of things. The idea of packages seems to adstract the native file
> system to another level (packages) and allows the compiler implementation to
> determine where files are on the host computer. Is this so?

No, the Ada language is not concerned with the mapping of compilation
units to actual source code files.

Packages are about more than just separate compilation, they structure
the source code, control visibility, are used in OO and generic
programming, and for probably a few other things.

> As for question 2. from reading this newsgroup I get the impression that
> there are quite a few "bugs" in gnat?!

GNAT does have some defects, but most of them relatively minor or
resulting from problems of the OS environment (for example, tasking
problems on GNU/Linux).

I don't have any experience with other Ada compilers, but the number
of bugs is certainly comparable to the number of bugs in the GNU C
toolchain.  (I still have to hunt down a nasty code generation bug in
the GCC 2.95 C compiler...)

> Or is it user problems?

Not in your case, but of course, some people tend to blame the
compiler although it correctly implements the Ada language.

> I know gnat is freeware so maybe this is natural. 

GNAT is not "freeware", it is Free Software released under the GPL.
(Proprietary software you get for free is usually called "freeware".)

> Is this the case with more proven/certified compiler systems?

Compilers with more bugs than the current GNAT version have been
officially validated. ;-)

Re: This is a simple question

[Jeffrey Carter]

Stephen Cole wrote:
> 
> If I want to make some child functions/procedures (which I understand is
> allowable) rather than a child package, how do I name the file in order to
> feed it into GNAT? Do I have to create a separate Specification file for
> each procedure/function declaration? And then a separate Body file for each
> specified function/procedure??

Every major construct in Ada has a specification and body. This is true
for packages, subprograms, protected units, and tasks.

Packages and subprograms may also be library units.

A special case allows a subprogram body to serve as its own
specification, so you could create only a body for a child subprogram.
However, for library units it is probably best to have an explicit
specification for every library unit.

The GNAT default naming rules use .ads for specification and .adb for
bodies and subunits.

-- 
Jeffrey Carter