Re: This is a simple question

[David Bolen <db3l@fitlinxx.com>]

"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     \
\-----------------------------------------------------------------------/