Re: [ortmann@isl.net: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line]

Re: [ortmann@isl.net: 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

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [ortmann@isl.net: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line]

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> 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 <storm@cua.dk> http://www.cua.dk


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [ortmann@isl.net: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line]

[Miles Bader]

storm@cua.dk (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.

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

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

> if we don't start messing up the existing movement & killing
> functions!!!

What are you talking about?

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [ortmann@isl.net: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line]

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> storm@cua.dk (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 <storm@cua.dk> http://www.cua.dk


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [ortmann@isl.net: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line]

[Richard Stallman]

    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.

That part bothers me.  Can we assign a coherent meaning to a field
property on an empty overlay?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [ortmann@isl.net: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line]

[Miles Bader]

no-spam@cua.dk (Kim F. Storm) writes:
> I don't understand.  How does emacs know when it's currently in an important
> case...

What are you talking about?  I mean _I've_ thought about how things
work, and considered the important cases when the current mechanism is
confusing in this way, and decided that this is a good solution.

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

Of course it works.  The reason why it's a bit wierd is because the
input field is at the of the buffer, and _everything_ involving
text properties works a bit oddly at the end of the buffer.  [your
proposed `solution' would have exactly the same problem!]

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

Yes, but people apparently don't like it (I don't really care).  They
want C-e to go to the `end of something', not `the beginning'.  Even
though the `background' is a field too by definition, people think of
the input field as being distinguished from the background, and I
suppose emacs ought to respect that.

> I thought you were proposing to change, end-of-line and other
> commands to behave differently if point is "inside" a field.

I'm proposing changing the way the field-restriction functions work
(which are called by anyone that cares about a field) to not act like
it's a field when the field property is nil.

> I referred to that as "messy" (compared to doing it through command
> remapping).

I suspect trying to do it through command remapping would actually be a
lot messier -- because you're only changing things at a surface level,
you have a lot more special cases to worry about.

[and in any case, the current mechanism (1) exists, and (2) works quite well]

-Miles
-- 
I'd rather be consing.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [ortmann@isl.net: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line]

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     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.
> 
> That part bothers me.  Can we assign a coherent meaning to a field
> property on an empty overlay?

Well, input fields can be zero-width, so it sems like emacs has to be
able to do _something_ for that case.  It could do so using the same rules
it uses for field boundaries (which are also ambiguous, because you have
to decide whether a movement should be treated as being at the end of
the first field or at the beginning of the second field), by looking at
the stickyness of any overlay.

If you don't like this, then the only thing I can think of is that you
have to say `empty fields can only exist at the end of the buffer.'
[Then, of course, some other way has to be found to distinguish `inside'
from `outside'.]

-Miles
-- 
Would you like fries with that?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [ortmann@isl.net: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line]

[Richard Stallman]

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

You could experiment with this and see how well it works.
I tend to think it won't be easy to get this to work,
so I don't think we should count on it.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [ortmann@isl.net: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line]

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> no-spam@cua.dk (Kim F. Storm) writes:
> > I don't understand.  How does emacs know when it's currently in an important
> > case...
> 
> What are you talking about?  I mean _I've_ thought about how things
> work, and considered the important cases when the current mechanism is
> confusing in this way, and decided that this is a good solution.

Ok, but why do you ask people what they think and whether there are
other ways to fix this? 

I took the time to think about this, and told you what I thought -
and I'm sorry that I didn't understand what you were proposing to
change.  

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


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [ortmann@isl.net: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line]

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> > What are you talking about?  I mean _I've_ thought about how things
> > work, and considered the important cases when the current mechanism is
> > confusing in this way, and decided that this is a good solution.
> 
> Ok, but why do you ask people what they think and whether there are
> other ways to fix this? 

Because some people may have good ideas, or point out problems.

You asked the odd question `How does emacs know when it's currently in
an important case,' and I was pointing out that `important case' merely
referred the way I had thought about the problem.  [That's why I
emphasized `I've' -- not as some sort of claim of authority, but to
contrast with `emacs'.]

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [ortmann@isl.net: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line]

[Richard Stallman]

    > That part bothers me.  Can we assign a coherent meaning to a field
    > property on an empty overlay?

    Well, input fields can be zero-width, so it sems like emacs has to be
    able to do _something_ for that case.  It could do so using the same rules
    it uses for field boundaries (which are also ambiguous, because you have

You may as well give it a try if you want.  However, I think that this
is likely to result in very little improvement for a lot of work.
With the same amount of work you could do one of the highest priority
tasks in the task list.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [ortmann@isl.net: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line]

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     Well, input fields can be zero-width, so it sems like emacs has to
>     be able to do _something_ for that case.  It could do so using the
>     same rules it uses for field boundaries (which are also ambiguous,
>     because you have
> 
> You may as well give it a try if you want.  However, I think that this
> is likely to result in very little improvement for a lot of work.
> With the same amount of work you could do one of the highest priority
> tasks in the task list.

Offhand, I don't think it would be all that much work.  However, I don't
really care about the problem (C-e/C-k acting `unintuitively' inside
prompts) very much, so I'm quite content to not fix it; keep it in mind
if you receive any more bug reports about it, though.

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [ortmann@isl.net: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line]

[Eli Zaretskii]

On 20 Mar 2002, Miles Bader wrote:

> > You may as well give it a try if you want.  However, I think that this
> > is likely to result in very little improvement for a lot of work.
> > With the same amount of work you could do one of the highest priority
> > tasks in the task list.
> 
> Offhand, I don't think it would be all that much work.  However, I don't
> really care about the problem (C-e/C-k acting `unintuitively' inside
> prompts) very much, so I'm quite content to not fix it; keep it in mind
> if you receive any more bug reports about it, though.

If we decide that this won't be fixed, at least for a while, we could 
have an entry in PROBLEMS that suggests work-arounds, or at least 
acknowledges the existence of the problem.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [ortmann@isl.net: asymmetries and contradictions in shell navigation using C-a and C-e on a prompt line]

[Miles Bader]

Eli Zaretskii <eliz@is.elta.co.il> writes:
> > However, I don't really care about the problem (C-e/C-k acting
> > `unintuitively' inside prompts) very much, so I'm quite content to
> > not fix it.
> 
> If we decide that this won't be fixed, at least for a while, we could 
> have an entry in PROBLEMS that suggests work-arounds, or at least 
> acknowledges the existence of the problem.

I suspect most people figure out the `workaround' (hit the key twice
instead of once) by themselves pretty quickly.

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel