Excuse this cross-posting. The reasons will become clear rightaway.
When playing with the MIT-CADR lispmachine emulator, one of the first
things everyone notices is that it is enough to press the closing
parenthesis to have a sexp evaluated, i.e. no need to press Return.
It is possible to achieve the same behavior inside emacs inferior lisp
buffer. A working code which you can insert in your .emacs file to do
so can be found at
http://www.eurogaran.com/downloads/lisp/emacs/lispmstyle.el
My question is... Is this really desireable ?
Please put AFFIRMATIVE as the first content word in your answers to
this post should you favor it, and anything else otherwise. Maybe if
enough positive answers are received the *emacs developers would
consider to add the feature.
Thank you for replying.
On Thu, 15 Nov 2007, ·······@eurogaran.com wrote:
> Excuse this cross-posting. The reasons will become clear rightaway.
> When playing with the MIT-CADR lispmachine emulator, one of the first
> things everyone notices is that it is enough to press the closing
> parenthesis to have a sexp evaluated, i.e. no need to press Return.
> It is possible to achieve the same behavior inside emacs inferior lisp
> buffer. A working code which you can insert in your .emacs file to do
> so can be found at
> http://www.eurogaran.com/downloads/lisp/emacs/lispmstyle.el
> My question is... Is this really desireable ?
Interesting. I would like to try it, but I get (void-variable
inferior-lisp-mode-map) when trying your code. I'm using emacs
23.0.0.1.
On Thu, 15 Nov 2007 18:29:04 +0100 Kjetil S. Matheussen wrote:
> On Thu, 15 Nov 2007, ·······@eurogaran.com wrote:
>
>> Excuse this cross-posting. The reasons will become clear rightaway.
>> When playing with the MIT-CADR lispmachine emulator, one of the first
>> things everyone notices is that it is enough to press the closing
>> parenthesis to have a sexp evaluated, i.e. no need to press Return.
>> It is possible to achieve the same behavior inside emacs inferior lisp
>> buffer. A working code which you can insert in your .emacs file to do
>> so can be found at
>> http://www.eurogaran.com/downloads/lisp/emacs/lispmstyle.el
>> My question is... Is this really desireable ?
Not for me, here emacs inserts the closing paren automatically when I
enter the opening one.
> Interesting. I would like to try it, but I get (void-variable
> inferior-lisp-mode-map) when trying your code. I'm using emacs
> 23.0.0.1.
(require 'inf-lisp) should help. But most probably you want to use
slime-repl-mode instead of inferior-lisp-mode.
David
[ comp.lang.lisp only; http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
David Hansen <············@gmx.net> writes:
> On Thu, 15 Nov 2007 18:29:04 +0100 Kjetil S. Matheussen wrote:
>
> > On Thu, 15 Nov 2007, ·······@eurogaran.com wrote:
> >
> >> Excuse this cross-posting.
> >> The reasons will become clear rightaway.
I usually don't elaborate, but since the fact of the cross-posting is
explicitly part of the discussion and not just an artifact of the header,
I will indulge a point of clarification.
My key point: A discussion of the historical reason for it is distinct
from any discussion of the desirability of it for a particular tool,
and discussions by the cross-posted communities are likely to work at
crossed-purposes.
Your reasons for doing this were clear, I just don't agree with them,
nor with the likely result.
I'd be happier having several separate discussions, getting to be part
of the entire discussion for any I selected to join, than having to be
the one to cut off others from discussions I feel it inappropriate for
me to join, and having to worry that if I participate in the
conversation as a whole I am either annoying or confusing or just not
presenting well for people in other parts of the discussion.
As it is, it's like a discussion about "good food ways to feel fed"
cross-posted to fourth-graders in kansas and to people planning to be
on the Survivor TV show, figuring both are interested in tips about
finding food. They may be. But a unified discussion will not be
properly coherent because the individual remarks made will be all over
the map (literally and figuratively).
For more detail on my feelings about that, see the URL at top.
> >> When playing with the MIT-CADR lispmachine emulator, one of the first
> >> things everyone notices is that it is enough to press the closing
> >> parenthesis to have a sexp evaluated, i.e. no need to press Return.
> >> It is possible to achieve the same behavior inside emacs inferior lisp
> >> buffer. A working code which you can insert in your .emacs file to do
> >> so can be found at
> >> http://www.eurogaran.com/downloads/lisp/emacs/lispmstyle.el
> >> My question is... Is this really desireable ?
>
> Not for me, here emacs inserts the closing paren automatically when I
> enter the opening one.
It was highly desirable by a great many in the LispM community. We used
to regard line-at-a-time input as hugely unsophisticated.
And yet, in an editing context, it's probably not appropriate. On the
LispM, this behavior did not happen in the editor--it happened only in
a Listener.
Some reasons that it was good were:
* By using this technique in a Listener, you got multi-line input
with rubout up across lines. Most of the competing tools used
line-at-a-time prescan without semantic understanding of whether
the line contained a completed text ready for execution, so if
you typed
(defun foo (x)
on a line followed by return, you either got:
- an error saying the expression was unbalanced, OR
- committed to this line, moved into editing of next line, with
the inability to rub back into the first line
* By using this technique, you got not only end-of-line activation
on balance, but also semantic error checking all the way along
the way, while still in rubout handling. So if you used a , in the
wrong place in a backquoted expression or if you left out a close
quote on double-quotes, you knew it before, not after, activation.
You could also get command-completion in context in a more convenient
and modular fashion.
* In file I/O, one doesn't need activation characters, but in
line-at-a-time systems, one needs a return. This makes it hard to
interactively test code that is doing character-at-a-time I/O because
interactively you insert characters that will not be seen in a file.
On the LispM, if you can type the same sequence (even if it involves
returns) as you would type in a file, so you can feed a file as user
input using force-kbd-input calls to test something.
* In line-at-a-time systems, if you wanted to do:
(defun foo () (print '>) (read) 'done)
and then do (foo) and put in some data, you'd have to do:
(foo)(bar)
since on some they would not like it if you did (bar) on a
separate line (they'd complain of no input), etc. or you'd see effects
like
Command: (foo)(bar)
>
DONE
where the prompt follows uselessly because you had to pre-type the
form to be read. There were myriad little synchronization problems in
the UI on line-at-a-time systems that the LispM did not confront.
This list may not be exhaustive--it's just what occurred to me at the
moment, and I offer it mostly for color, not for any claim of completeness.
Most of these things are not especially relevant in an editor-toplevel.
They are relevant only to non-editing Listeners. An editor-based listener
like in LispWorks is a kind of mixed beast which overcomes some of these
but not all, as happens with hybrid systems.
Two footnotes:
* For more information on the mechanism of LispM style input editing, see
http://www.nhplace.com/kent/PS/Ambitious.html
Alas, this will not at all give you the look and feel of it, because I
stripped all of that out in order to make the paper something people could
approach on portable systems. But if you modify the examples using
non-portable cursor motion and erasure operations, you can reconstruct
some of it from this.
* There is an issue of finding the "outer bound" of an input unit, similar
to the problem of WITH-COMPILATION-UNIT, but for finding the surrounding
context for READ and READ-CHAR (rather than, as WITH-COMPILATION-UNIT,
for LOAD and/or COMPILE-FILE). It's not per se relevant to the issues
raised, but it's "interesting" as a concept that was highly relevant to
the above concepts, all of which are better understood as a consistent
part of an overall ecology, not as an isolated feature.
On Nov 16, 6:06 pm, Kent M Pitman <······@nhplace.com> wrote:
>
> My key point: A discussion of the historical reason for it is distinct
> from any discussion of the desirability of it for a particular tool,
> and discussions by the cross-posted communities are likely to work at
> crossed-purposes.
>
> Your reasons for doing this were clear, I just don't agree with them,
> nor with the likely result.
>
I apologize. I'm clearly not enough experienced in using these type of
forums.
> It was highly desirable by a great many in the LispM community. We used
> to regard line-at-a-time input as hugely unsophisticated.
>
Me too.
> ...And yet, in an editing context, it's probably not appropriate. On the
> LispM, this behavior did not happen in the editor--it happened only in
> a Listener.
>
That is correct.
In emacs, it is supposed to happen only in the *inferior-lisp* buffer,
which is nothing but a listener.
I thank you for your very interesting historical comments.
On Fri, 16 Nov 2007, David Hansen wrote:
> On Thu, 15 Nov 2007 18:29:04 +0100 Kjetil S. Matheussen wrote:
>
>> On Thu, 15 Nov 2007, ·······@eurogaran.com wrote:
>>
>>> Excuse this cross-posting. The reasons will become clear rightaway.
>>> When playing with the MIT-CADR lispmachine emulator, one of the first
>>> things everyone notices is that it is enough to press the closing
>>> parenthesis to have a sexp evaluated, i.e. no need to press Return.
>>> It is possible to achieve the same behavior inside emacs inferior lisp
>>> buffer. A working code which you can insert in your .emacs file to do
>>> so can be found at
>>> http://www.eurogaran.com/downloads/lisp/emacs/lispmstyle.el
>>> My question is... Is this really desireable ?
>
> Not for me, here emacs inserts the closing paren automatically when I
> enter the opening one.
>
>> Interesting. I would like to try it, but I get (void-variable
>> inferior-lisp-mode-map) when trying your code. I'm using emacs
>> 23.0.0.1.
>
> (require 'inf-lisp) should help.
Thanks, that defined inferior-lisp-mode-map. But closing paren
doesn't automatically evaluate the sexpr. I still have to
c-M-x to evaluate.
> But most probably you want to use
> slime-repl-mode instead of inferior-lisp-mode.
>
Well, I'm not too fund of slime (although I know how to use it),
and I don't know what inferior-lisp-mode is. But thanks for the
info, I'll google inferior-lisp-mode.
[following up only to CLL]
* David Hansen <··············@localhorst.mine.nu> :
| (require 'inf-lisp) should help. But most probably you want to use
| slime-repl-mode instead of inferior-lisp-mode.
SLIME has C-RET (slime-repl-closing-return) in its REPL bindings which
is also pretty nifty.
;; Cargoed against CVS slime
(defun slime-lispmstyle-close-paren (&optional N)
(interactive "P")
(if (not N) (setq N 1))
(self-insert-command N)
(if (slime-input-complete-p
slime-repl-input-start-mark
(ecase slime-repl-return-behaviour
(:send-only-if-after-complete
(min (point) slime-repl-input-end-mark))
(:send-if-complete slime-repl-input-end-mark)))
(slime-repl-send-input t)))
(define-key slime-repl-mode-map ")" 'slime-lispmstyle-close-paren)
--
Madhu
While implementing it for the inferior-lisp mode, I found I had to re-
define the return key as well. Pressing for instance return before
completing a sexp caused a disaster.
Don't you have to do it in slime?