bug#81251: [PATCH] 32.0.50; Missing process status in mode-line of *Python* buffer
Matthias Meulien <[email protected]>
| Newsgroups | gmane.emacs.bugs |
|---|---|
| Message-ID | <CAFEQCfDMtUChp9kCnZxUSgo1GOFZ3BfnOtgLweQJDFLZyosSeA@mail.gmail.com> |
Hi Michael, Sorry for being that long to reply, didn't saw your mail until beginning of this week. > Could you maybe try to find out whether this workaround is still > necessary at all? AFAIU, comint is even adding a newline by itself > (`comint-redirect-send-command-to-process'). Right? Or is THAT the > problem? > That's the problem. `comint-redirect-send-command-to-process' concat a newline to the command to send, so if one uses it to collect completion results in a Python interactive buffer, one would see accumulating new prompts on completion tries. Not that the sent string is inserted in the buffer as is, but the new prompt triggered by the new line is inserted in the redirection buffer after the last markup that is used by python.el to collect completion results and which triggers end of redirection. As consequence, the new line and the prompt are copied from the redirection buffer to the comint buffer... It's easy to see in action: In the let bindings of `python-shell-completion-native-get-completions', the input to send is build as `(concat new-input delete-line-command)' (where `new-input' is the user input plus a TAB character and `delete-line' is a string made of BACKSPACE characters of same length as new-input); Just append a `"\n"' to that `concat' form and you'll see completion working but the *Python* buffer accumulating prompts. > So, as the user of this code, if you have some time, maybe > you could do a short experiment? > > I just want to avoid that we are wasting time on a hack that is of > zero use... > My understanding is that it's a necessary hack. -- Matthias