[Top][All Lists]
[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
- Re: address@hidden: C-k must be repeated in shell to kill a line that has a prompt], (continued)
Re: address@hidden: C-k must be repeated in shell to kill a line that has a prompt], Richard Stallman, 2001/11/02
Re: address@hidden: C-k must be repeated in shell to kill a line that has a prompt], Stefan Monnier, 2001/11/02
Re: address@hidden: C-k must be repeated in shell to kill a line that has a prompt],
Miles Bader <=
Re: address@hidden: C-k must be repeated in shell to kill a line that has a prompt], Karl Eichwalder, 2001/11/05
Re: address@hidden: C-k must be repeated in shell to kill a line that has a prompt], Stefan Monnier, 2001/11/05
Re: address@hidden: C-k must be repeated in shell to kill a line that has a prompt], Robert J. Chassell, 2001/11/02
Re: address@hidden: C-k must be repeated in shell to kill a line that has a prompt], Richard Stallman, 2001/11/02
Re: address@hidden: C-k must be repeated in shell to kill a line that has a prompt], Robert J. Chassell, 2001/11/02