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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public From: john@assen.demon.co.uk.nospam (John McCabe) Subject: Re: Ada mode requests (Re: Ada vs C++ vs Java) Date: 1999/01/30 Message-ID: <36b28591.8315974@news.demon.co.uk>#1/1 X-Deja-AN: 438691159 X-NNTP-Posting-Host: assen.demon.co.uk:158.152.218.101 References: <369DDDC3.FDE09999@sea.ericsson.se> <369e309a.32671759@news.demon.co.uk> <369F1D39.64A65BC1@sea.ericsson.se> <369f81a9.31040093@news.demon.co.uk> <77ommt$9bo$1@nnrp1.dejanews.com> <77vhjf$nn9$1@nnrp1.dejanews.com> <77vld9$qvg$1@nnrp1.dejanews.com> <782rp0$kn6$1@nnrp1.dejanews.com> <6Oap2.16170$MW1.4028@news2.giganews.com> <783nnb$s9c@drn.newsguy.com> <784qvi$a0a$1@nnrp1.dejanews.com> <78549k$iqv$1@nnrp1.dejanews.com> <785fo3$thj$1@nnrp1.dejanews.com> <36A6F997.CA210C39@easystreet.com> <36A775B3.666042D8@easystreet.com> <788svu$gl9@drn.newsguy.com> <78a27f$rp4$1@nnrp1.dejanews.com> <78age5$p8v@hobbes.crc.com> <78g0vt$8td$1@nnrp1.dejanews.com> <36B0FEF4.381F@gecm.com> <78scig$dbf$1@nnrp1.dejanews.com> <36B2381E.70A@gecm.com> <78tmid$knt$1@nnrp1.dejanews.com> X-Trace: news.demon.co.uk 917702917 nnrp-10:23237 NO-IDENT assen.demon.co.uk:158.152.218.101 Newsgroups: comp.lang.ada X-Complaints-To: abuse@demon.net Date: 1999-01-30T00:00:00+00:00 List-Id: robert_dewar@my-dejanews.com wrote: >Well most certainly ACT will be continuing to maintain our >version, especially as long as there is confusion as to >whether anyone else is even trying to fill this role, and >how much time they may have. That's good to know, but would it be worth changing it's name to GNAT-Mode to reduce confusion? It would then be up to whoever's using your software to make sure they have the correct setup in their .emacs to use GNAT-mode instead of ada-mode. >For us, the Ada aware version of EMACS is one of the >critical parts of our technology, since at this stage it >really begins to provide a very attractive integrated >development environment, that many of our big customers >are using. Having used Emacs with GNAT on SGI IRIX, I would agree with your views here. >So we will most certainly continue that development. We are >happy to support any indepedent efforts by contributing our >ideas and code, but just as Cygnus maintains versions of >gdb and gcc independent of EGCS to meet the needs of their >customers, we need to maintain a version that is under our >control and meets our customer needs. >From a purely language based point of view, I would expect that your customers and the Ada community at large probably hold very similar views on what is needed from ada-mode. At a tool (compiler, debugger etc) level the requirement is likely to diverge, but really the same basic requirements regarding launching compilation, linking, debugging and so on are likely to be required for any compiler, with a superset of vendor dependant stuff like handling of libaries, cross-referencing and so on. It has been mentioned here a couple of times that it would be best to keep GNAT specific code out of the ada-mode.el code base. All that is then needed then would be to use elisp's equivalent of access-to-subprogram types using (funcall...) etc to produce a type of API that could be used to call either default functions contained within ada-mode.el, or a particular vendor's implementation of those functions specific to their product. It would be nice to get more vendors involved actually so that the API ended up being as useful as possible. Personally, I can't see why any vendor really needs to develop their own editing technology with ada-mode around. I'm using ObjectAda at the moment and, to be honest, their default editor is completely clueless compared to Emacs with ada-mode. > What will be nice is if we an avoid divergence of the code bases (just > as Cygnus does, i.e. by resynchronizing every now and then), and we > should all work towards that. I agree that we should avoid divergence of the code bases which is why I believe that all vendor/tool specific code should be separate from ada-mode.el. Again, from a language point of view, I don't think there would be too much difficulty in maintaining this state, or ada-mode itself. >But one problem here is that editor related matters tend to >generate lots of diverse and strongly held ideas, so it is >not necessarily so easy to guarantee convergence. Agreed, but generally some compromise, or configurale option can be put in place that most users will be happy with. Best Regards John McCabe