[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
kill-whole-line and fields
From: |
Luc Teirlinck |
Subject: |
kill-whole-line and fields |
Date: |
Thu, 29 Apr 2004 22:47:01 -0500 (CDT) |
While implementing comint-kill-whole-line, the following question
occurred to me: should kill-whole-line itself respect fields as it
currently does?
Example:
Start with:
[bash2.05b.0 ~ 3 1] umask
0022
[bash2.05b.0 ~ 3 2]
With point on the `m' of umask, invoking kill-whole-line produces:
[bash2.05b.0 ~ 3 1] 0022
[bash2.05b.0 ~ 3 2]
Invoking the proposed comint-kill-whole-line produces:
0022
[bash2.05b.0 ~ 3 2]
as (I believe) it clearly should, because its entire purpose is to be
able to kill entire lines, _overriding_ the read-only-ness of prompts,
if comint-prompt-read-only is t.
But it is not completely clear what kill-whole-line itself should do.
There currently is no convenient way to kill an entire line if there
is a field at the beginning of a line and point is not in that field.
C-a gets stuck at the field boundary. This might be a motivation for
making kill-whole-line ignore fields. C-a C-k C-k (or sometimes C-a
C-k) easily produces the current kill-whole-line behavior.
Also, given the name `kill-whole-line', people might expect to get the
comint-kill-whole-line behavior, especially that, with point inside
the prompt, kill-whole-line produces the same result as
comint-kill-whole-line produces over the entire line.
Changing the behavior would be trivial: just bind inhibit-field-text-motion
to t. I could install this, if it would be considered desirable.
Sincerely,
Luc.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- kill-whole-line and fields,
Luc Teirlinck <=