Re: address@hidden: C-k must be repeated in shell to kill a line that has a prompt]

[Stefan Monnier]

> Richard Stallman <address@hidden> writes:
> > I see now that the input fields to not have this property.
> > But I think they should.  Users are already complaining that C-a
> > does not move to the real beginning of the line.
> 
> Which users are complaining?  I've seen one complaint (compared to the
> presumably large number of people who use shell mode, and who either
> like the current behavior, or who haven't noticed).
> 
> Historically, C-a in a shell-buffer ignored the prompt.

My memory is getting abit fuzzy around the adge, but I seem to
distinctly remember the behavior of C-a in comint-buffer
changing from `comint-bol' to `beginning-of-line'.  So historically,
C-a in a shell buffer has been changed from "go to end of prompt"
to "go to beginning of line".
Ah, yes, I found it in lisp/ChangeLog.5:

1994-07-16  Richard Stallman  <address@hidden>

        * comint.el (comint-mode-map): Move comint-bol to C-c C-a.

According to ONEWS, it was part of the "User Editing Changes in Emacs 19.26":

** In Shell mode and other comint modes, C-a has now returned to
its ordinary meaning: move to the beginning of the line.
Use C-c C-a to move to the end of the prompt.

> But I think that is a mis-feature, not a feature; consider --

The historical change I mention above must have been justified
somehow, so it would be interesting to know what were the reasons.

>   (1) Most command-line systems with emacs-like keybindings have `C-a'
>       stop after the prompt (the minibuffer, bash, etc).  [the old
>       behavior of] comint is the odd man out.

I have changed it in my .emacs, indeed:

(defun sm-comint-mode-hook ()
  (add-hook 'comint-output-filter-functions 'comint-truncate-buffer)
  (local-set-key "\C-a" 'comint-bol))
(add-hook 'comint-mode-hook 'sm-comint-mode-hook)

> I suspect this is the reason why some people who are used to the old
> behavior see the new behavior as a misfeature -- they've trained
> themselves to never use C-a except in the rare case of copying part of
> their session, so they only notice the drawbacks of the current
> behavior.

I think a more significant reason is that it's difficult for the
user to get the old behavior back.  Making C-a jump to the end of
the prompt can be done in many ways, and using fields can be considered
a bit heavy handed since it changes the behavior of other commands
as well.

> > The reason fields are used is so that comint can figure out
> > what is a prompt, not to affect cursor motion.
> 
> Both are valuable.

But we can still have both by using a different (i.e. non-special)
text-property like `comint-field', make comint-bol use that property,
and bind C-a back to comint-bol.

The different between the two approaches is the impact it has
on other "unrelated" commands.  I personally don't know enough
to decide which of the two approaches is better.

I know that the `comint-bol' approach is safer because it does not
impact other commands.  But maybe we do want other commands to
magically know about the prompt ?  If so, which other commands should
know about the prompt ?  I.e. which commands beside C-a benefit from
the use of `field' ?


        Stefan