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

[Miles Bader]

[ 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):

      1xxxxxxxxxxx[FFFFFFFFFFFFFFFFFFFF]yyyyyyyyyyyyyyyyy2

  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?

Thanks,

-Miles
-- 
80% of success is just showing up.  --Woody Allen