[comp.lang.ada] Gnu Emacs Ada and Dec's LSE/EDT

lrs@esl.ESL.COM (Lynn Slater) (11/11/88)

> > I have integrated a set of programs to support Ada development under
> > Gnu Emacs.
> >
> > Some who have used both set of programs report a 50% productivity gain
> > during Ada coding sessions.  This is probably over optimistic, but
> > the productivity gain can be great.
> 
> How does this compare to the facilities and productivity gains from
> using DEC's LSEDIT?  Has anyone done an objective comparison?  Even a
> subjective opinion would be helpful.  

There have been no comparisons as far as I know.  I will post any that
I receive.  Interested parties might want to subscribe to
bugs-gnu-emacs-ada@esl.com. (Send to the bugs-gnu-emacs-ada-request@esl.com.)

A vendor supported development environment with special hooks and
undocumented ties into the compiler/debugger/linker has more potential
than one that uses only the interface that the vendor makes public.
However, this potential is often not achieved.

On the other hand. the Gnu Emacs interface will probably gain more
widespread acceptance than Dec's environment because it is/will be
multi-vendor.  Users of the Emacs Ada interface will be able to switch
from one vendor to another with the minimum of disruption.  The
widespread acceptance of Gnu Emacs Ada editing could even lead to more
standardization across vendors.

Gnu Emacs Ada editing also has more supporters and incorporates ideas
from more places than a vendor's in house team is likely to
accomplish. In one sense, I am not really the author of the Ada
support. Instead, I am the integrator and expander of about six
different really good ideas into one unified editing environment.
Other good ideas, such as the LEIF incremental parser, will probably
be integrated in the future.  There is no "not invented here"
syndrome. (For that matter, there is no "here".)

Send a good idea in to me and I can have it incorporated, tested, and
distributed within a week, for FREE.  Send a bug report into
bugs-gnu-emacs-ada@esl.com and you will most likely get same day
turn around of a fix, not just an acknowledgment.  Better yet, I
never tell you to upgrade your support contract.  

Even if I do not chose to address your concern, you are not stuck.
Everybody has the whole and complete source code, and many of the Ada
mode users are also Gnurus who are likely to respond to any requests.
Often, Gnurus will even compete to field the first and best solution.
If no Gnuru wants to deal with you (which might happen if your request
is complicated and not of general interest), you can select from over
25 support vendors who charge from $15 to $150 per hour. If your
demand is high you can hire Gnurus out of school or develop them in
house.  (Most shops quickly develop expertise in house. Like
mushrooms, Gnurus grow uninvited especially when the fertilizer is
deep. :->)

>                                       I know that these have the benefit
> of being in the public domain, but as a non-EMACS user, I would be
> interested to know if the benefit of learning it would offset the
> increase in confusion I already experience when switching between vi and
> LSE/EDT.

The Ada support IS NOT IN THE PUBLIC DOMAIN, it is copyrighted and
distributed for free.  The copyright is owned by the Free Software
Foundation. This means that charging vendors such as Dec, Verdix,
Telesoft, Alysis, Unipress, etc cannot take the best parts of it, add
window dressing, and effectively sell it back to you.  They can do
this and they can sell it, but because of the "copyleft", the first
one who buys it can give it away to the world.

Most Emacs users feel that the benefits of Emacs merit the steep
learning curve.  However, this seems to be a "religious" issue with
dogma on both sides.

You may have hit upon the core advantage of Gnu Emacs when you mention
"confusion I already experience when switching between vi and
LSE/EDT".  It sounds like LSE/EDT is good only for Ada.  Once in
Emacs, YOU NEVER SWITCH.  You can edit, compile, make, load, run,
debug, read the Ada LRM, read the man pages, read mail or news, grep,
c compile, format LaTex or Scribe documents, run shells (with
editing), ispell, check in and out of scs or rccs, look up things in a
rolodex, run lisp or scheme, and much more while editing any number of
files in any number of windows.  It is nice to have multiple buffers
and split screens even on "dumb" terminals such as the wyse50/75 or
the Decs.
				 -*-

I am sorry that I do not know more about LSE/EDT and cannot give a
more definitive answer.  If LSE/EDT is really super wonderful, it will
will probably be the best choice.  If you are having confusions, Emacs
may be the best choice.

The Gnu Emacs Ada support does not currently include Dec.  This means
that you can edit programs and compile them with the generalized shell
interfaces, but you cannot do this with simple key sequences.
Depending upon Dec's output format, you may or may not be able to use
'next-error, tags, or the debugger interface.  The intention is that
support of other vendors should be easy to add, but somebody who uses
that vendor's environment needs to do it.  I will integrate any such
support into the general package. I will gladly assist, provided that 
the support will be distributed free.

  Good Luck,
-- Lynn
===============================================================
Lynn Slater -- lrs@esl.com
ESL/TRW 495 Java Drive, Box 3510, Sunnyvale, Ca 94088-3510
Office (408) 738-2888 x 4482; Home (415) 796-4149 
===============================================================

leake@cme-durer.ARPA (Stephe Leake) (11/16/88)

I have been using DEC's  LSE for a couple years now, and Gnuemacs
almost as long. Currently, I find LSE better (for Ada development),
but in general, I agree with Lynn Slater's comments on the openness
and community support available in gnuemacs.

The main reason I like LSE is that it supports true language
syntax expansions. You can enter "if^E", and the editor inserts:

if {boolean_expression}
then
	{statement}...
[else_part]
end if;

The things in brackets and braces are "placeholders", which can be
further expanded by placing the cursor in them and typing ^E. This is
a _great_ way to learn the syntax of a new language, or to remind an
expert of something she doesn't use often. LSE lets the user
modify the language syntax for formatting, or even add a new language.

LSE  is also extensible: I have added file name completion, an
interface to mail, a DCL interface, etc. I wish there was a DEC news
group I could access from my LSE machine as easily as this newsgroup
from my gnuemacs machine.

So, maybe someday I'll add true syntax expansion to gnu, and then say
goodby to LSE.

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899

lrs@esl.ESL.COM (Lynn Slater) (11/18/88)

> I have been using DEC's  LSE for a couple years now, and Gnuemacs
> almost as long. Currently, I find LSE better (for Ada development),
> but in general, I agree with Lynn Slater's comments on the openness
> and community support available in gnuemacs.

Thanks for the plug, but I notice that you are not using the new Ada
support. (Or at least, you are not a subscriber to the users mailing list.)

The Ada support I distribute can and does do the following. (Thanks to
Rich Hilliard of the Mitre Corp.)

> The main reason I like LSE is that it supports true language
> syntax expansions. You can enter "if^E", and the editor inserts:
> 
> if {boolean_expression}
> then
> 	{statement}...
> [else_part]
> end if;

>So, maybe someday I'll add true syntax expansion to gnu, and then say
>goodby to LSE.

Maybe the time has come.  

For more info, write bugs-gnu-emacs-ada-request@esl.com.

P.S. I suspect that these template expansion capabilities might seem
rather primitive once somebody integrated Leif (an incrimental
compiler) into the Gnu Ada package,

  -- Lynn
===============================================================
Lynn Slater -- lrs@esl.com
ESL/TRW 495 Java Drive, Box 3510, Sunnyvale, Ca 94088-3510
Office (408) 738-2888 x 4482; Home (415) 796-4149 
===============================================================