I've been fooling around with comint-mode lately and I'm noticing some weird behaviors. Its very poorly documented, so I'm wondering if anyone has any insight on this.
In some modes, comint-send-string causes whatever is sent to be inserted into the comint buffer and then sent to the associated process, whereas in others, the input is send directly to the process without being placed into the buffer. For example, do run-python with the new (24.3) python.el and then do (comint-send-string "*Python*" "x=3\n"), the string x=3 is inserted into the buffer and then executed. If you do M-x shell, however, and then (comint-send-string "*shell*" "x=3\n"), no text is inserted into the buffer, the input is simply sent to the shell process directly to be executed.
Does anyone know why this difference in behavior exists or how I can change it?
I observe identical behavior on linux (emacs-version == "24.3.50.7", both GUI and emacs -Q -nw): neither
(comint-send-string "*Python*" "x=3\n")
nor
(comint-send-string "*shell*" "x=3\n")
insert anything in the comint buffer (i.e., the next prompt appears
right after the previous prompt - without even a newline between them).
I eventually figured it out. For some reason the system python on OSX causes this behavior, installing python from homebrew fixed it.
Related
The delete-region command in Emacs doesn't behave as expected. It sends the region to the kill-ring, even though it shouldn't.
While deleting one character at a time with delete-backward-char works as expected, i.e. it doesn't send the character to the kill-ring. delete-region sends the highlighted text to the kill-ring. Note that delete-forward-char also works fine. I have identified the problematic behavior by directly calling the command, using M-x delete-region.
I simply wish to delete a region without sending the content of that region to the kill-ring. This follows a litany of queries of a similar flavor. I have already consulted several posts on this topic, including
136581,
637351,
17914475, and
1257365, but none of the proposed solutions work because they tend to solve the problem by referring to using the delete-region command. I have also checked the relevant entry in the emacswiki, but this is not addressing the issue, either.
Here is the description of the command within Emacs:
delete-region is an interactive built-in function in ‘C source code’.
(delete-region START END)
Delete the text between START and END.
If called interactively, delete the region between point and mark.
This command deletes buffer text without modifying the kill ring.
My experience is that this description is incorrect. I'm using Emacs 25.2.2 on Ubuntu 18.04.
Any help would be very much appreciated.
In fact, it was pretty straightforward. I just needed to retain the default values for the following two commands.
x-select-enable-primary
x-select-enable-clipboard
In an effort to obtain a better behavior of the yank command outside of Emacs, I ended up compromising the behavior of the yank command inside Emacs. I would advise newbies not to mess up with these particular commands, and to keep the default values.
I have a Python program which uses rlcompleter to provide custom Tab-completion. The completion works when it is run under a bash terminal. However, it does not work under emacs, in shell mode, nor in eshell mode.
I noticed that Tab is really bound to completion-at-point, eshell-pcomplete, and so on, so I tried an (insert "\t"), supposing that this would trigger the completion, which I understand happens when the child process reads a "\t" character. But this does not work either. Perhaps input is buffered until a "RET"?
Completion for commands like service, which define their own candidates, does not work as expected either.
How can I access these candidates within Emacs?
Try using M-x ansi-term. I find it behaves a bit more like what I have come to expect from a *nix terminal.
I have a small GTK python application that imports a package (Twisted) that may not be loaded twice.
If I run my application in emacs with python-mode.el and press C-c C-c, the application gets executed in a python shell window.
If I now close the application, the python shell stays up and running. If I now press C-c C-c again, emacs "reuses" the old python process and thus I run into problems because I'm installing a Twisted reactor twice.
Is it possible to have python-mode.el open a new shell window each time I execute a buffer?
python-mode.el comes with a command py-execute-buffer-dedicated,
opening a new and reserved process for it
In python.el, a new inferior process is launched in a new buffer if the python-buffer variable is set to nil. Therefore, it's possible to advise the python-send-buffer function to reset that variable to nil after every invocation, thereby forcing a new Python process to be executed for every subsequent python-send-buffer command. Something like the following should work:
(defadvice
python-send-buffer
(after python-send-buffer-new-proc activate)
(setq python-buffer nil))
(ad-activate python-send-buffer)
I know that your post was asking for help with python-mode.el, but I thought it might be helpful to mention this anyway, as I'd surprised if python-mode.el doesn't use a similar mechanism. If I have time, I'll try to look into it.
Edit: the python-mode.el package uses the command py-shell to initiate a new inferior Python process. I found a mailing list posting in which a user provides an ad hoc function that appears to do what you need.
By the way, it might be worth considering that trying to alter the default behavior of python-mode isn't the best approach to this problem. I don't know what your code does, and I'm not particularly familiar with Twisted, but it seems to me that experiencing major errors when evaluating your code a second time within the same session could be a sign of a more fundamental design problem. I fail to see how it could be a matter of multiple imports of the same module being the issue, as Python modules are only loaded once, with successive import statements having no effect (for that, an explicit reload or execfile() is required). If I'm completely off-base here, I apologize, but I felt this possibility might merit mention.
I installed ClojureBox and the REPL is not working.
If I type (+ 1 2) into the *slime-repl clojure* buffer and press enter, the expression text becomes bold as if it has been evaluated, but there is no result of the evaluation printed on the screen.
Can anyone help me figure out why my REPL is not printing the evaluation results?
Thanks.
Try looking in *inferior-lisp* and failing that all other buffers.
The binding of clojure's *out* plus emacs slime-swank based capture and redirection of output streams can occasionally make it seem like emacs is swallowing output. (This can get really confusing when output comes from multiple threads - definitely one of the few warts of developing clojure with the slime-swank environment.)
Have you ever tried emacs before using clojurebox? Any left behind .emacs configuration or library paths etc. can interact badly with clojurebox which, in my experience, assumes it is the only installation of emacs going onto a clean system.
I often have several comint buffers open at once, for example I'll have a SQLi buffer open to a database and a set of shell buffers open in various places. Sometimes, for no reason I can detect, all of these buffers start to share a common buffer command history, such that M-p will pull up my last SQL command in a shell-mode buffer, and so on.
How can I fix this? What on earth is causing it?
Have you exited from any of the shells or SQL sessions? Long time since I used emacs but I seem to remember when a shell terminated the commands would be part of a 'global-command-history-list'.
note - A shell can quit, but the buffer will still be there in emacs.
It sounds like there is something else going on in your system that you are not aware of. One possibility may be something in your .emacs is mixing between buffers without your knowledge. Another possibility is that you are inadvertently moving data through your copy-and-paste system.