Re: address@hidden: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line]

[Kim F. Storm]

Miles Bader <address@hidden> writes:

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

I think the proper way to achieve this is by using different keymap
text properties on input fields and prompt fields.

Of course, that will not happen "automatically", but it avoids
"cluttering" all the standard (and non-standard) movement and killing
commands with such "field aware" exceptions.

As a service to the lisp programmers, we could define new `standard'
functions like end-of-input-field, end-of-prompt-field, etc. for this
and add keymaps input-field-keymap and prompt-field-keymap utilizing
the "command remap" feature to remap end-of-line, beginning-of-line
and other relevant commands to those commands.  Then it would be easy
(but tedious?) to put the proper keymap property on the fields and
prompts...


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

What happens if you have two fields next to each other -- in that
case, the inside of one field is the outside the other field - and
vice versa.

> The question is, what's a good interface to distinguish the inside of a
> field from the 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).

Which indicates to me that your proposed solutions isn't the right one.

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

If there is a problem with inheriting the field/text properties at the
end of the buffer (notably the minibuffer), we need to look at that as
a separate issue.  IMO, a right-sticky property should be honoured
also at the end of the buffer, so if that doesn't happen, it's sounds
like a bug.  

Hm, the problem is that the input field is initially zero-length, so
maybe there isn't anywhere to define those properties in the first
place...  But we already handle the minibuffer correctly, so this
will continue to work if we don't start messing up the existing
movement & killing functions!!!

-- 
Kim F. Storm <address@hidden> http://www.cua.dk