In emacsclient, is there a way to open a file from the command line such that its buffer will remain open on the server after I close the client?
Alternatively, is there a command I can run from in a client to tell it to effectively detach from a buffer, so that the buffer does not get killed when the client exits?
Normally when closing emacsclient either with C-x C-c or C-x #, the buffer(s) associated with that client get killed, which is usually convenient behavior, but sometimes I would like for buffers to stay alive after closing. So far the only way I have found to accomplish this is to run the client without specifying any files, then visit them with C-x C-f, but I'm wondering if there's a better way to do this.
You should be able to do this by using the -n option. That means that it won't wait for you to "finish" the buffer and it'll just stay in the buffer list. I use this with emacsclient myself.
So, one option is to use emacsclient's eval command line option to run a lisp command to find the file you want.
emacsclient -c -e '(find-file "my_file")'
Obviously this is a lot more to type than the command sequence emacsclient -c, C-x C-f, my_file, but it could pretty easily be wrapped in a script that takes an extra argument to tell it whether to just choose the file or use find-file.
Someone more well versed in elisp than I could probably just add the option directly into emacs.
According the info manual, if you never want to kill emacsclient buffers, when you're done with them, you can customise the server-kill-new-buffers variable (more information at C-h v server-kill-new-buffers).
For you use-case, depending on how often you want the buffers killed or not, you could set the above variable to nil and then manually kill the buffers that you do want killed.
Related
I would like to, after switching to the buffer where I usually run commands, navigate the history by searching it, rather than navigate one-command-at-a-time at the end of the buffer (e.g. C-p).
Basically I would like to "Reverse I-search" the command history at the end of the buffer, rather than search the buffer.
Did anyone code a working solution? Note that I noticed there is a Command History buffer available, but here it is just a bunch of text and it is not grouped well enough I think to use.
As in a terminal, you can use M-r to search backward. It works in comint-mode, but it also work elsewhere, like in M-x (M-xM-rpatternRET).
Yes, with Icicles.
In Icicle mode, command icicle-comint-search is bound to C-c ` in shell buffers. It gives you the behavior you are looking for. It is described here.
It uses only stuff that is in the currently visible history as candidates, however. If you want to access stuff from your history from previous sessions then use command comint-input-ring, bound to C-c TAB, instead. (This is explained in the same doc.)
I'm starting to use shell-mode more often in emacs and what I'd really like is for grep output and other grep-like-output (gcc, etc) to recognize source code line references and allow me to jump to source lines in the output. Is there a way to apply grep-mode to a single Output Group?
No, emacs modes are whole-buffer.
However, you can narrow to the last output, turn on grep-mode, and widen and restore comint-mode when done.
Nevertheless, the grep command (and compile for gcc) are more than adequate; use them instead of running gcc and grep in the *shell* buffer.
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.
Say I have long debugging session in Perl with perldb on Emacs (M-x perldb). The output piles up, and at some point it becomes difficult to navigate through it.
I can restart the debugger with R, but that doesn't clear up the previous output. Is there a command to clear up the output of the buffer of the Perl debugger without having to kill the debugger and starting a new session?
You can run comint-truncate-buffer. This will remove all but the last 1024 lines from the buffer. The size can be customized by changing comint-buffer-maximum-size.
If you'd like to have the buffer truncated automatically, run this snippet of elisp:
(add-hook 'comint-output-filter-functions 'comint-truncate-buffer)
Debugger input and output is buffer contents like any other — if you want to delete it, just do it. For example, C-x h C-w (mark-whole-buffer followed by kill-region) works in perldb buffers just fine, and is the closest equivalent to a "clear screen" command in a text terminal.
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.