[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: address@hidden: asymmetries and contradictions in shell navigation u
Re: address@hidden: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line]
18 Mar 2002 11:39:35 +0900
[ This is in reply to an old message complainging that commands like C-e
or C-k, when invoked inside a comint prompt, would jump-to/kill-to
the end of the prompt, instead of the end of the line. ]
It seems to me that the right answer to this problem is to augment the
field handling to distinguish between the `inside' and the `outside' of
a field (currently there is no such distinction). Then some commands
(such as `end-of-line' or `kill-line') would only use the field-
sensitive behavior when invoked inside a field, and would act normally
when invoked outside a field.
[ There is one twist, which I'm not sure the right answer too (but which
doesn't effect the comint case). If there's a field inside a line,
like this ([ and ] demark the field):
Currently, if you type `C-e' while point is at position `1' in such a
line, it will jump to the beginning of the field, at `[', which is
clearly wrong (though I find that it's sometimes convenient :-).
However, is the right behavior for C-e at position `1' to jump to (a)
the real end of the line (position `2'), or the end of the field at
position `]'? Both behaviors seem fairly sane, and both would be
useful in some cases. ]
The question is, what's a good interface to distinguish the inside of a
field from the outside?
I suggest saying that a field property of `nil' is always `outside', and
any non-nil value is `inside'. This is very easy to understand and
implement, and would be convenient for most user code (since the bulk of
text would automatically be considered `outside').
Unfortunately, the most common use of fields currently is in the
minibuffer, and it uses a `nil' field property as the `inside'
(and puts a non-nil field property on the prompt, to distinguish it).
The reason it does this is because the minibuffer input field is at the
end of the buffer, and can have a size of zero. Thus any inserted
characters will have nil values for their properties, including the
`field' property. Also, it's important that the field code recognize
that there's an empty field there, so that commands such as C-a don't
act wierdly when nothing's been typed into the minibuffer.
However, I think this can be handled by making the minibuffer input use
an overlay for the input field, instead of relying on the nil-properties
inserted at the end of the buffer. [The field code doesn't seem to
always handle this properly, but I think that's an implementation bug.]
So, that's what I propose to do. Any objections, or better ideas?
80% of success is just showing up. --Woody Allen
Re: address@hidden: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line], Richard Stallman, 2002/03/19
Re: address@hidden: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line], Richard Stallman, 2002/03/18
- Re: address@hidden: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line],
Miles Bader <=