shivers@a.gp.cs.cmu.edu (Olin Shivers) (08/18/89)
For those requesting a Prolog interface for Emacs, I might suggest building a
derived mode on top of my general command-interpreter-in-a-buffer package,
comint mode. Comint.el floats around the net and is available in some of the
standard network archives. Additionally, I would be happy to mail someone a
copy if they wish to undertake this task. You could get guidance from
examining the shell, lisp and Scheme process modes that are built on top of
comint mode. The source file, comint.el, also has massive internal
documentation on implementing derived modes.
Of course, you'd have to do the Prolog specific stuff all yourself (e.g.,
teaching Emacs Prolog syntax and so forth).
A brief introduction to comint mode is reproduced below from the original
announcement for interested parties. Since the package has been released
to the net, the FSF has expressed interest in using comint et al., and
I have assigned the copyright to them for that purpose.
I will also add that RMS has seen the light wrt the input history
design wrangle referred to in the following notes, and I believe he
currently endorses the history list mechanism which is the default in
comint.
I speak only for myself, of course. Any statements about RMS, the FSF and their
positions or future plans are unofficial.
Happy hacking.
-Olin
------
I have written new gnu-emacs packages that provide shell, inferior lisp,
inferior scheme, and inferior T modes. These packages have the following
advantages over the standard released gnu packages:
- Input history is kept in all modes, traversed with M-p and M-n, just
like on LispM's and various fancy shells.
- Filename completion and query is available in all modes.
- Keybindings are cross-compatible among all modes.
- Keybindings are compatible with Zwei and Hemlock.
- Directory tracking is more robust in shell mode, and is *only* active in
shell mode. (Try entering "cd /" to an inferior lisp in the old package:
Lisp barfs, but the inferior lisp mode goes ahead and changes the
buffer's directory.)
- Non-echoed text entry (for entering passwords) is available in all modes.
- Shell and inferior Lisp modes are backwards compatible with the standard
gnu modes.
- One source for the inferior Lisp mode works in both emacs releases 18.4x and
18.5x. This has been the cause of confusing bugs for users who unwittingly
tried to use an 18.4x version inferior Lisp mode in an 18.5x version emacs,
and vice-versa.
- A full set of eval/compile-region/defun commands for the inferior Lisp,
Scheme, and T modes.
- New modes are easily created for new types of processes.
===============================================================================
GENERALIA:
The implementation strategy was to factor common process functionality
into a general command interpreter mode -- comint mode -- and then to
build all the specific modes on top. This provides uniform, integrated
functionality and interface across all the derived modes. Comint mode
provides the input history, filename completion and query,
non-echoed text entry, input editing, and process signalling
(e.g., ^z, ^c, ...) commands. *Any* mode built on comint mode gets
all this stuff automatically. Additionally, comint mode has general
hooks for customising it to specific command interpreters, such as
Lisp, Scheme, csh, ML, etc..
This release includes the following files:
- comint.el comint mode
- cmushell.el cmushell and cmulisp modes, built on comint mode.
- cmuscheme.el inferior Scheme mode, built on comint mode.
- tea.el inferior T mode, built on comint mode.
- tea2.el Variant of tea.el
- cmutex.el tex-mode.el with rewritten process interaction code.
Some bugs also fixed.
These packages have been in daily use by a user community of about 10-20
at CMU since August; most bugs have been shaken out. cmutex.el is less
tested. Please notify me of bugs.
The files are *extensively* commented; this should serve as sufficient
documentation. Each file includes suggestions for your .emacs file
in comments at the top. On-line documentation (C-h C-m, C-h C-f, C-h C-v)
is available for modes, commands, and variables.
This source is available on an FSF-style basis: use it any way you like
as long as you don't charge money for it or change the basis of its
availability; I assume no liability for its use.
===============================================================================
INPUT HISTORY:
There are actually two different ways to retrieve old commands for
resubmission to a process. The standard way is to use the input history
mechanism. An internal list is kept in each process buffer of the last n
inputs (default: 30). The commands M-p and M-n move through this list. This
is similar in functionality to the input history mechanisms provided by the
LispM, Hemlock, and various fancy shells (tcsh, cmucsh, ksh,...). There is
also a command, bound to C-c r, which searches backwards through the input
history looking for a substring match.
RMS doesn't like this mechanism. He has suggested an input history mechanism
that operates by searching backwards (and forwards) through the buffer for
occurrences of the prompt. The user can then resubmit the input by hitting
return.
I do not like this mechanism. If the prompt changes dynamically, you can miss
a command. False positives are also annoying. The screen jumps around a lot as
you scroll through your history. If you run a subprogram that has a null
prompt (like dc), prompt search will miss all its inputs. Etc.
However, you may try either of these mechanisms, and go with the style you
prefer. The RMS-style prompt-search stuff is available on M-N and M-P
(meta-shift-n and meta-shift-P); C-c R is bound to a command that searches for
specific commands (analogous to C-c r). If you use this stuff, you will
probably want to sharpen up the regular expression used to match the prompt in
each mode to match your particular prompt -- the default, general regexp used
in shell mode generates too many annoying false positives. (It's local
variable comint-prompt-regexp -- you should set it in a hook).
===============================================================================pierson@xenna (Dan Pierson) (08/22/89)
In article <5901@pt.cs.cmu.edu>, shivers@a.gp (Olin Shivers) writes: >For those requesting a Prolog interface for Emacs, I might suggest building a >derived mode on top of my general command-interpreter-in-a-buffer package, >comint mode. I'd like to endorse this. The number of extended shell modes and inferior-foo modes floating around the net is a pretty convincing existence proof that the standard shell mode is inadequate. Since comint is the most complete and polished replacement I've seen, it should be a leading candidate for the new base. Then all of our other modes can simply and fluidly coexist (and new mode writers won't have to continually reinvent command history, etc.). Now if Olin could just be convinced to fix the bug in the default behaviour of ^M :-) -- dan In real life: Dan Pierson, Encore Computer Corporation, Research UUCP: {talcott,linus,necis,decvax}!encore!pierson Internet: pierson@encore.com