Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Allegro/Emacs C-a fix

8 views
Skip to first unread message

David Bakhash

unread,
May 30, 1998, 3:00:00 AM5/30/98
to

If anyone out there is using the Allegro CL Emacs interface, you'll
know that it really kicks some butt. However, when you're in the
*common-lisp* buffer, like at the top-level, you'll notice that C-a
brings you to the beginning of the line, and that isn't nice when the
prompt is there. No one wants to edit the prompt!

So here's the fix. Just put this in your .emacs or wherever. You can
even put it inside your fi-keys.el file, if you want. It'll fix the
problem, or at least it did for me:

(defvar acl-prompt-regexp "\\[[0-9]+\\] \\w+([0-9]+): *")

(defun fi:bol ()
"Newline, but skip passed the prompt, if there is one"
(interactive)
(beginning-of-line)
(when (looking-at acl-prompt-regexp)
(re-search-forward acl-prompt-regexp)))

(define-key fi:inferior-common-lisp-mode-map [(control a)] 'fi:bol)

dave

Erik Naggum

unread,
May 31, 1998, 3:00:00 AM5/31/98
to

* David Bakhash

| If anyone out there is using the Allegro CL Emacs interface, you'll
| know that it really kicks some butt. However, when you're in the
| *common-lisp* buffer, like at the top-level, you'll notice that C-a
| brings you to the beginning of the line, and that isn't nice when the
| prompt is there. No one wants to edit the prompt!

this is the official Emacs design policy. C-a should not guess a prompt,
it should move to the beginning of the line in the buffer. if you want
to move to the beginning of the text after a prompt, use C-c C-a. (if
you want to use the C-c prefix for a number of control characters, set
the variable FI:SUBPROCESS-ENABLE-SUPERKEYS to true before starting a any
subprocesses. see the documentation for the details.)

#:Erik
--
"Where do you want to go to jail today?"
-- U.S. Department of Justice Windows 98 slogan

David Bakhash

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

Erik Naggum <c...@naggum.no> writes:

> * David Bakhash
> | If anyone out there is using the Allegro CL Emacs interface, you'll
> | know that it really kicks some butt. However, when you're in the
> | *common-lisp* buffer, like at the top-level, you'll notice that C-a
> | brings you to the beginning of the line, and that isn't nice when the
> | prompt is there. No one wants to edit the prompt!
>
> this is the official Emacs design policy. C-a should not guess a prompt,
> it should move to the beginning of the line in the buffer. if you want
> to move to the beginning of the text after a prompt, use C-c C-a. (if
> you want to use the C-c prefix for a number of control characters, set
> the variable FI:SUBPROCESS-ENABLE-SUPERKEYS to true before starting a any
> subprocesses. see the documentation for the details.)

didn't know about C-c C-a.

thanks!

dave

Marco Antoniotti

unread,
Jun 2, 1998, 3:00:00 AM6/2/98
to

Erik Naggum <c...@naggum.no> writes:

Yep. This is so. ILISP does not do this one right and it has been on
the fix list forever (my fault :{ ).

--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 80 79 23, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it

Jeffrey Mark Siskind

unread,
Jun 2, 1998, 3:00:00 AM6/2/98
to

> > this is the official Emacs design policy. C-a should not guess a prompt,
> > it should move to the beginning of the line in the buffer. if you want
> > to move to the beginning of the text after a prompt, use C-c C-a.

> Yep. This is so. ILISP does not do this one right and it has been on


> the fix list forever (my fault :{ ).

I could never understand the logic behind this. Both a prompt-sensitive and a
prompt-insensitive move-to-beginning-of-line are useful behaviours. However,
in my experience, the prompt-sensitive version is used far more often than the
prompt-insensitive version. Isn't it desirable to have the more-often-used
command bound to a shorter keystroke sequence. I.e. bind C-c C-a to the
prompt-insensitive version and bind C-a to the prompt-sensitive version? So I
believe that that ILisp got this right and the official Emacs policy got this
wrong. Cam someone please enlighten me with the compelling reasons that
motivate the official Emacs policy?

Jeff (http://www.neci.nj.nec.com/homepages/qobi)

Raymond Toy

unread,
Jun 3, 1998, 3:00:00 AM6/3/98
to

I agree with you. I've never had the desire to edit the prompt, so I
like that fact that C-a ignores the prompt. One of the first things I
did with Ilisp was to make it recognize the prompts for the Lisps that
I was using.

I note that in a shell buffer, C-a ignores the prompt. So this
violates Emacs policy. (Umm, I only tested this on XEmacs. I don't
have Emacs anymore.)

Ray

Erik Naggum

unread,
Jun 3, 1998, 3:00:00 AM6/3/98
to

* Jeffrey Mark Siskind

| I could never understand the logic behind this. Both a prompt-sensitive
| and a prompt-insensitive move-to-beginning-of-line are useful behaviours.
| However, in my experience, the prompt-sensitive version is used far more
| often than the prompt-insensitive version. Isn't it desirable to have
| the more-often-used command bound to a shorter keystroke sequence. I.e.,

| bind C-c C-a to the prompt-insensitive version and bind C-a to the
| prompt-sensitive version? So I believe that that ILisp got this right
| and the official Emacs policy got this wrong. Cam someone please
| enlighten me with the compelling reasons that motivate the official Emacs
| policy?

well, there was a vote on this some time ago, quite obviously because
this is a question of taste and an application of the principle of least
astonishment, which I think is subjectivity at its best, and thus an
arbitrary decision with both good "arguments" and people failing to see
the logic of the arguments for any given viewpoint. nonetheless, people
voted overwhelmingly in favor of C-a retaining its usual semantics.

now, I don't know whether this is rationalization after the fact or
actually a good argument in favor of the status quo, but the same can be
said to apply to other Emacs editing commands that have dual meaning in
various special modes, like C-c, C-d, C-w, C-z, etc.

0 new messages