You can start background processes with start-process, which shouldn't pop up a buffer:
(start-process "process-name" "buffer-name" "program")
Process names are modified to avoid duplication as necessary, so don't worry about that. Just give it a name useful for debugging in the future!
If you give a "buffer-name", a buffer will be created but not shown ...
First of all, you shouldn't be using accept-process-output if you want asynchronous processing. Emacs will accept output every time when it is waiting for user input.
The proper way to go is to use filter functions to intercept the output. You don't need to create or delete the filter(s) depending on whether you still have lines to send. Rather, you will ...
Since mention that the command is running asynchronously I am assuming you mean the command async-shell-command bound to M-&. You can follow the advice in documentation of async-shell-command (you can read it by doing C-hfasync-shell-commandRET) customize display-buffer-alist as follows
(add-to-list 'display-buffer-alist (cons "\\*Async Shell Command\\*....
Like Tikhon mentioned, (start-process) is the way to go. In case you don't want to create a buffer but would still like to react to the background process status, you can also employ (set-process-sentinel). Here's a modified example I'm taking from my projector package:
(set-process-sentinel (start-process "process-name" nil "command") #'output-message-...
You can specify the output buffer for async-shell-command.
The shell runs as a process of the output buffer.
You can get that process with get-buffer-process.
Define your own process sentinel for the shell and set it with set-process-sentinel.
It is wise to run shell-command-sentinel from your sentinel
since that is the sentinel actually set by async-shell-...
You can use https://github.com/redguardtoo/counsel-etags/blob/master/counsel-etags.el which originally called aysnc-shell-command to run shell command ctags -e -R.
Or else write your own implementation. Just three lines:
(let* ((async-shell-command-buffer 'new-buffer)
(display-buffer-alist '(("Async Shell Command" display-buffer-no-window))))
Here's my configuration. It should work great if you're on Linux.
(defun dired-start-process (cmd &optional file-list)
(let ((files (dired-get-marked-files t current-prefix-arg)))
(dired-read-shell-command "& on %s: " current-prefix-arg files)
Emacs has a general-purpose facility to prevent any unintentional (or indeed intentional) window configuration changes from causing problems.
Add (winner-mode 1) to your init file. Then when something messes up your windows, use C-c<left> (winner-undo) to restore them. You can use it repeatedly to undo multiple window configuration changes. C-c<right> ...
The functionality used by comint mode is start-process, so I think you might like to start with that. You send data to the process with process-send-string, and the process's output is "automatically" read by Emacs and passed to the process filter, which is a function you provide via set-process-filter.
The main difficulty is that you don't get to choose ...
You may be interested in creating a new/modified function of shell-command that does not seek confirmation. You may also be interested in customizing the variable async-shell-command-buffer. For a listing of the options, type M-x describe-variable or C-h v.
To see how this variable works within the function shell-command, type M-x find-function RET shell-...
Something in this spirit should do the trick. I tried it with espeak under Ubuntu; I guess it would work with say as well.
(defun my-read-words-on-region ()
"Send the region to `espeak'."
(start-process "espeak-process" "espeak-buffer" "espeak" "-v" "en-us")
(process-send-region "espeak-process" (region-beginning) (region-end)))
I'm also a loyal emacs-nw user, and have struggled with this over the recent emacs versions. What works for me, and without any need to C-g, follows. Note that it has a safety check that is linux-specific, so in a linux environment, if there is no X-display associated, it will try to operate on the lowest-numbered available X-display instead of silently ...
This isn't an solution on how to use async features, but one which will also satisfy your needs, i think.
Basically, you can move the fetching part to an external application, and just read the mails with emacs. Therefore, emacs doesn't have to download them, which should conclude in a non-blocking gnus/emacs. After you've set up the email-retriever, you can ...
There's no need to change how you run an asynchronous command. Emacs has a generic ability to allow you to control where or whether any buffer will pop-up, by modifying a single data structure, the display-buffer-alist.
In the solution below, you can see that the action function display-buffer-no-window (ie. no pop-up) is set to be associated with any ...
Try the async package (M-x package-install, if you don't already have it).
See the functions async-start and async-inject-variables. The given example is:
(insert ,(buffer-substring-no-properties (point-min) (point-max)))
;; Pass in the variable environment for ...
You can suppress that window for a single command instead of globally using let
(cons (cons "\\*Async Shell Command\\*.*"
(cons #'display-buffer-no-window nil))
display-buffer-alist))) ;; suppress async shell command window
Does there exist some similar trick in emacs - a way to turn currently running foreground (synchronous) command into backgroundized (asynchronous) one?
I suspect no such trick exists. The problem is that the synchronous shell command (which is really call-process-region) blocks the emacs event loop. The only way to break it is to kill the process with a ...
I believe the answer is essentially that ob-async has a bug (either with how it implements this feature, or with its stated minimum supported verion of Emacs).
The user is running Emacs 25.2.2
seq-random-elt was introduced in Emacs 26
ob-async states emacs-24.4 as its minimum requirement
Most likely this will be resolved upstream in https://github.com/...
(add-to-list 'display-buffer-alist '("*Async Shell Command*" display-buffer-no-window (nil)))
The buffer is still created and it still gets the output of the command (or the error output): it is just not displayed automatically, but you can still get to it to look at what happened with the usual buffer selection mechanisms (C-x b etc).
As @xuchunyang pointed out, package-refresh-contents takes an optional argument which allows it to be called asynchronously.
Therefor one can call it programmatically like:
This works perfectly and unlike a normal call to package-refresh-contents made in your init.el, which would lock up your Emacs, you can continue as normal ...
The quoted limitation does not exist any longer. Moreover, the function tramp-adb-handle-shell-command does not exist any longer. All different implementations of shell-command in Tramp have been unified in tramp-handle-shell-command, which is able to run several asynchronous processes in parallel.
This is brand-new, it will appear with Tramp 2.4.2 (planned ...
Since you know what the output buffer is, you can hack around this issue by getting the process object from the output buffer and then waiting for it to finish.
(defun run-kinda-async-shell-command (command &optional output-buffer)
"Run `command' and send results to `output-buffer', blocking until the command finishes."
(interactive "sCommand: \...
@npostavs made this comment on the question:
"I didn't find anything on the semantics of asynchronous operations." - Emacs doesn't have asynchronous operations, hence no semantics.
That comment is important. url-retrieve uses url-http which uses sentinels for the callback. Sentinels only run when emacs is waiting for user input. See: the section ...
The final status information of the process is reported on the mode
line for 3 seconds, however if you enter some keys during the 3
seconds, it will disappear immediately, thus if you are using Emacs
actively, you might miss that easily.
You can change the default behavior via the user option
dired-async-message-function. Notes that the corresponding ...