Don Hopkins <don@donhopkins.com> writes:

> Thanks for looking into this! 
>
> I can’t reproduce the problem through that recipe, but weird things still happen in other situations. 
>
> Try putting “ -la” in the kill buffer and then yanking it instead of typing it at the end of the output of “echo ls”. 
>
> It totally ignores the whole line, as if you entered an empty line.
>
> But the thing that usually happens to me is that it enters the text that I yanked, but I’m not sure what the exact conditions to trigger it are. 
>
> But at any rate, yanking “ -la” and hitting return should have the exact same behavior as typing “ -la” and hitting return, so it’s probably caused by the same underlying problem.
>
> I’ll let you know if I figure out other test cases that get it to enter the text you yanked but not the text before that. It usually has something to do with yanking text, possibly at the end or also in the middle of the line.

Reproducer:

- copy " -la" into kill ring
- type "echo ls" into M-x shell
- (Shell gives output line "ls".)
- Go up to output line "ls" (C-p).
- yank " -la"
- press C-b
- the line now "ls -la" with point after "l"
- press RET

Only " -la" is sent to the process instead of "ls -la"

This is because the 'field' text property of "ls" is 'output' but the
" -la" is inserted with insert-for-yank and doesn't have a 'field' text
property.

A similar thing happens if we insert a space using M-SPC
(just-one-space) in the middle of process output. The space is inserted
with 'insert' and doesn't inherit the 'field' text property of the
surrounding text.

This didn't cause a problem in older Emacs because the field text
property wasn't used yet at that time in comint.

I am willing to write up a patch to fix this. I'm thinking of having
comint-mode register a function in after-change-functions to mark text
inserted in the 'output' field as 'output'. Would this be okay or are
there any obvious flaws with this approach?