emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Miles Bader
Subject: Re: address@hidden: C-k must be repeated in shell to kill a line that has a prompt]
Date: 05 Nov 2001 10:16:04 +0900

"Stefan Monnier" <monnier+gnu/address@hidden> writes:
> I think a more significant reason is that it's difficult for the
> user to get the old behavior back.

Do you mean permanently, or for a single use?  The former can be done
using (set (make-local-variable 'inhibit-field-text-motion) t)
[presumably with some comint wrapper around it], and the latter can be
done in many ways; I generally use `C-a C-b C-a' (sure that's annoying,
but I only do it once a day!).

> 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.

Um, that's a _good_ thing.

In any case, any binding of C-a that moves to the end of the prompt will
in fact move to the end of the prompt; whether or not it uses fields is
irrelevant to a user that dislikes that behavior.

> 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' ?

Basically anything that might jump across the prompt-input boundary in
an unexpected way.

As an example, I often use `fill-paragraph' to squash newline-delimited
lists of files onto the command line.  With the `old-style' comint,
this nicely merges all your old output and input fields into one big
mess; with the `new-style' comint, it works properly, only filling the
input.

Come to think about it, I'm not sure there's _ever_ been a complaint
about the comint field behavior except for the wierd way C-k works
before prompts, and that's been deemed a bug.  Given that fields do
have beneficial effects (or so I would claim), removing them based on
the _possibility_ of a problem seems rather wonky.

I think the bottom line is that there's a conflict between treating the
prompt as a prompt in the traditional sense, and treating it as part of
the text to be edited, and nothing discussed so far going to get rid of
that conflict.  When there's a conflict, the reasonable thing to do is
to optimize for the common case, and make sure that none of the uncommon
cases has been overly compromised.  I assert that this is what the
current behavior does.

I would be interested in hearing from someone that dislikes the
C-a-goes-to-end-of-prompt behavior, and how they view the arguments
I've been making, given their preferences.  Is there anyone here?

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I



reply via email to

[Prev in Thread] Current Thread [Next in Thread]