From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!watmath!clyde!att!ucbvax!esl.ESL.COM!lrs From: lrs@esl.ESL.COM (Lynn Slater) Newsgroups: comp.lang.ada Subject: Gnu Emacs Ada and Dec's LSE/EDT Message-ID: <8811101747.AA08588@esl.ESL.COM> Date: 10 Nov 88 17:47:28 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet List-Id: > > 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 ===============================================================