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:

> address@hidden (Kim F. Storm) writes:
> > 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.
> 
> This is not a problem.  The only important case is where one of these
> commands would from `outside' to `inside' in a way that's counter-intuitive.

I don't understand.  How does emacs know when it's currently in an important
case...

> 
> > > 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.
> 
> Why?

I said 'indicates' -- as the major example of using this feature doesn't
work, and need to be reworked using more machinery (rather than less).

> 
> > But we already handle the minibuffer correctly, so this
> > will continue to work
> 
> No, the minibuffer suffers from the same `problem' that comint does.
> It's just not commonly enountered by users, because they usually don't
> move into the prompt.

Ok, but it sometimes does make sense to navigate inside the prompt.
C-e -> goto end of prompt (= start of input), another C-e -> go to
end of input.  Isn't that how it's working now?

> 
> > if we don't start messing up the existing movement & killing
> > functions!!!
> 
> What are you talking about?

I thought you were proposing to change, end-of-line and other
commands to behave differently if point is "inside" a field.  I
referred to that as "messy" (compared to doing it through
command remapping).


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