>>>TL;DR: It is complicated. When we pull one string out, several more
>>>get entangled.
>>
>> Might there be a solution wherein both the interactive shell buffer and Org
>> are talking to a common underlying process? I would expect such to be
>> significantly more complicated, but perhaps better factored? Not that I'm
>> offering or capable of such a re-write 😉
>
>comint buffer is doing exactly this - it is sending input (user
>comments) to the underlying shell process and receiving the output from
>that process, putting it back into the comit buffer.
>
>Unfortunately, there is no simple way to distinguish real output, shell
>echoing the submitted command, and shell prompt - shells do not provide
>any such information. The best they can provide is splitting between
>stdout and stderr. Alas.
>
>>>As a practical workaround, just do not use *shell* session names and
>>>session names that are the same as shell buffers you create manually.
>>
>> Is there perhaps another practical workaround you might suggest to me
>> involving a more intentional setting of the prompt and/or informing Org of
>> my choice of prompt (e.g. perhaps via setting a regexp to detect exactly my
>> prompt, and only when it is anchored to beginning of line)?
>
>That's also an option.
>What you need to fiddle with is `comint-prompt-regexp'.
This!
Since my (bash) shell prompt is a (more or less) constant string (e.g.
"myname@myhost> ").
So, my workaround is to:
(setq comint-prompt-regexp "myname@myhost> ")
Then the filtering works perfectly.
Of course if I change my name, this will fail. Or, more likely, connect to a
different host within the shell.
Or if I change PS1 😉
It would be useful to automate this a little.
The variable needs to be set buffer-local to the shell buffer.
And it could possibly somehow ask the process for the value of PS1.
Any more TIPS on doing this?
Or perhaps advice that I shouldn't want to ...??? 😉
Cheers,
~ Malcolm
