jtr@exsb.cs.exeter.ac.uk (Jason Trenouth) (05/31/88)
Walter Maner writes: > We have the happy dilemma of deciding whether to use the excellent Unipress > EMACS which come bundled with Quintus Prolog or integrating the GNU EMACS, > already installed, with Quintus Prolog. Any observations of experiences > would be welcome. I suppose our preference is to interface with GNU if that > is easily accomplished without loss of functionality. and Martin Carroll replies: >> GNU GNU GNU GNU GNU GNU GNU >> >> I hate unipress. I've been through five stages of editor with Quintus Prolog. Initially I used the UNIPRESS Emacs that QP came with. Gradually I discovered that this was not the same as the GNU Emacs that the rest of the department used. The differences were mostly little irritations, but they were all with UNIPRESS. For a short while I used GNU Emacs, but I became frustrated by the lack of a handy rodent. Then I turned to the SPY editor (UK mouse-based editor). However, its impossible to run a Prolog subprocess through it sensibly, and I moved on to the Sun's own "textedit". This had the added advantage of having the same interface as the "mailtool" and "cmdtool" (for those who know what I'm talking about). Then the department began using the Sun-interfaced GNU Emacs and my troubles were over. Yessiree, I'm a BORN AGAIN GNU lover. CONS: No compile option. Quintus Prolog doesn't get tricked into believing the buffer is the original file (i.e. multifile warnings if you switch between buffer consults and normal consults). No help file interface. Some unsupported libraries effected (e.g. big_text). No find definition power (Ouch this hurts!), and not linked to debugger. Not supported. PROS GNU Emacs has an all-round better feel than UNIPRESS. Better integrated with a Sun workstation (if you got one!). If GNU Emacs is already widely used within your organisation, then so much the better for the Prolog user who doesn't need to change his editor to read any mail etc. (OK UNIPRESS can do other things but see below.) To keep two comparably full versions of Emacs around is an enourmous waste of disk space! What could happen (i.e. happened here) is that it was only possible to use a stunted version of UNIPRESS Emacs - thus making GNU Emacs infinitely better in any feature comparison. I gather that GNU is more powerful anyway (unconfirmed). Certainly, some hardware manufacturers (e.g. Pyramid) started supplying GNU in addition to UNIPRESS because their user-base prefers it. The only feature that I wished for was "find-definition". GNU Emacs has a more general/powerful "find-tag" feature. However, it relies on an associated program called ETAGS which currently only understands C, FORTRAN, LISP, and LATEX (text formatter). Rather than waiting for Richard Stallman's (Ohmmme) merry men to correct this deficiency I recently wrote PTAGS. This creates a TAG FILE from a Prolog file(s) that GNU Emacs can use to implement "find-tag" for Prolog. PTAGS is written in Prolog (~10K) and is sort of available after I check with our system admin about the proper place to post it. Ciaou (see I can spell it now), JT. "If the feel is against you then argue the features. If the features are against you then argue the feel. If they are both against you, call the other Emacs names." | Jason Trenouth, | JANET: jtr@uk.ac.exeter.cs | | Computer Science Department, | UUCP: jtr@expya.uucp | | University of Exeter, | BITNET: jtr%uk.ac.exeter.cs@ukacrl| | Devon, EX4 4PT, United Kingdom. | |
bs30@bunny.UUCP (Bernard Silver) (06/08/88)
In article <500@expya.UUCP> jtr@exsb.cs.exeter.ac.uk (Jason Trenouth) writes: >Then the department began using the Sun-interfaced GNU Emacs and my troubles >were over. Yessiree, I'm a BORN AGAIN GNU lover. > >CONS: > > > No find definition power (Ouch this hurts!), and not linked to > debugger. It is fairly easy to make a find_definition function for emacs. You have to load an extra predicate into your prolog code but thats OK. Note that find_pred(Pred,Arity) :- current_predicate(Pred,Skel), functor(Skel,Pred,Arity), !, source_file(Skel,FileName) <Stuff ommited here> locates the file that pred is in (if it exists). The rest of the definition writes out the relevant commands for gnu to find that file and search for the predicate. These commands are written in a temp file that GNU automatically loads when the find definition command is issued. It works fine. If current_predicate fails, a GNU error message is written to the temp file. Compiling regions does have the problem that you mentioned (that GNU believes it comes from a different file) but this really isn't too much of a hassle. ( I turn the error detection off automatically when compiling regions. If Prolog complains when I load in the file (predicate previously defined in user) I can safely ignore this) Bernard
dowding@macbeth.PRC.Unisys.COM (John Dowding) (06/13/88)
In article <114@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >*we* have changed. (The whole point of an editor interface like this is >to produce the illusion of a single program, after all.) There are a lot Although I would normally hate to nit-pick a (parenthetical) comment, I have to make an exception in this case. I dont think that you want the emacs interface to produce the illusion of a single program at all. In the name of this illusion, the Quintus Prolog emacs interface has the following "features": - You cannot start Prolog w/ interface if you are already in emacs. Prolog can only be called from the (in our case) unix prompt. - Many nice, handy emacs features have either been deformed or destroyed. These include delete-window (why *cant* I take the prolog buffer off the screen for a while. I know how to get it back), and shell (in our version, you couldnt run any other subprocess besides prolog, not even a clock). Besides this, because the prolog/emacs interface was a separate environment, Quintus felt free to make arbitrary changes to the default key bindings that had nothing to do with prolog. These include the kill-ring commands, and incremental search. Thats all for now. Now back to your regularly scheduled programming. John Dowding dowding@prc.unisys.com
ok@quintus.uucp (Richard A. O'Keefe) (06/14/88)
In article <6604@burdvax.PRC.Unisys.COM> dowding@macbeth.PRC.Unisys.COM (John Dowding) writes: >In article <114@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>(The whole point of an editor interface like this is >>to produce the illusion of a single program, after all.) > >Although I would normally hate to nit-pick a (parenthetical) comment, >I have to make an exception in this case. I dont think that you want the >emacs interface to produce the illusion of a single program at all. >In the name of this illusion, the Quintus Prolog emacs interface has >the following "features": [specific criticisms deleted] There are two separate and distinct questions: (1) whether an editor interface should present the illusion of a single program (2) what changes to an editor are permissible/desirable in the name of simplifying a particular interface. The points that Dowding criticised are all related to question (2), not to question (1). The changed key bindings are not at all "in the name of this illusion", they are all things that the designers of that part of the system thought were desirable whatever the interface looked like. With respect to question (1), does anyone think it would be a _good_ thing for Prolog and Emacs to have a different notion of what the current directory is? Or of what the current state of a file is? By the way, if you are using Quintus Prolog and have comments about our editor interface (or anything else), **please** send them to our Technical Support people. The editor interface is not cast in concrete, but if nobody complains to us we think it doesn't need changing.