From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: kai.grossjohann@gmx.net (=?iso-8859-1?q?Kai_Gro=DFjohann?=) Newsgroups: gmane.emacs.help Subject: Re: multithreading in Elisp? Date: Fri, 06 Jun 2003 14:10:10 +0200 Organization: University of Duisburg, Germany Sender: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <848ysfz9st.fsf@lucy.is.informatik.uni-duisburg.de> References: <844r38vqlk.fsf@lucy.is.informatik.uni-duisburg.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1054901634 8904 80.91.224.249 (6 Jun 2003 12:13:54 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 6 Jun 2003 12:13:54 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Fri Jun 06 14:13:52 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19OG6S-0002JJ-00 for ; Fri, 06 Jun 2003 14:13:52 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19OG7y-00072y-UB for gnu-help-gnu-emacs@m.gmane.org; Fri, 06 Jun 2003 08:15:26 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!syros.belnet.be!news.belnet.be!news.tele.dk!news.tele.dk!small.news.tele.dk!fu-berlin.de!uni-berlin.de!lucy.is.informatik.uni-duisburg.DE!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 49 Original-NNTP-Posting-Host: lucy.is.informatik.uni-duisburg.de (134.91.35.216) Original-X-Trace: fu-berlin.de 1054901441 12674985 134.91.35.216 (16 [73968]) Mail-Copies-To: never User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:kK76L9Vt8EQZRfnGX6gDjKYjXdk= Original-Xref: shelby.stanford.edu gnu.emacs.help:114213 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:10707 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:10707 Florian von Savigny writes: > kai.grossjohann@gmx.net (Kai Großjohann) writes: > >> You can do cooperative multitasking, MacOS-style, by using timers or >> process filters or the like. (MacOS means before X.) > > Do you have an (arbitrary) code example at hand? My imagination does > not reach far enough to implement commands that run in parallel by > means of a process filter (maybe you mean "outsourcing" the task that > is to run in the background with start-process?). I have no idea, on > the other hand, what a timer is (it doesn't have to do with the diary, > does it ... ?). I think it's not necessary to use a lot of imagination. Timers are part of Emacs. For example, the following is good for Brits: (defun tea-time () (message "It's time for tea!")) (run-at-time "5:00pm" nil 'tea-time) In addition to run-at-time, also see run-with-timer and run-with-idle-timer. Also note that run-at-time allows you to run the function repeatedly, every second, say. Process filters are indeed used when you want to communicate with a process. When the process creates some output, your process filter function will be called with a string arg, the arg contains the output from the process. You can then do whatever you like and return. > I would not really care whether the multitasking is preemptive or > cooperative, as long as the possibility is there at all. What I would > like to achieve is to have emacs retrieve some text from an external > program and write it in a different buffer, while it still allows the > user to edit his text. This is really easy: you can start a process with start-process. Then, from time to time, you can call accept-process-output to read output from that process, or you can use a process filter which just appends the output to the end of the buffer. Or you run the process via comint, as has been suggested before in this thread. I think that's not a bad solution; it's a fairly high-level facility. -- This line is not blank.