From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Richard M. Stallman" Newsgroups: gmane.emacs.devel Subject: Re: Fwd: HTTP redirects make url-retrieve-synchronously asynchronous Date: Sat, 21 Jan 2006 22:59:07 -0500 Message-ID: References: <87y81ep6wf.fsf-monnier+emacs@gnu.org> <87wtgu8trl.fsf-monnier+emacs@gnu.org> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1137902686 18698 80.91.229.2 (22 Jan 2006 04:04:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 22 Jan 2006 04:04:46 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 22 05:04:45 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F0WT0-0006hI-5F for ged-emacs-devel@m.gmane.org; Sun, 22 Jan 2006 05:04:38 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F0WVZ-0002eQ-Gh for ged-emacs-devel@m.gmane.org; Sat, 21 Jan 2006 23:07:17 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F0WTa-00011p-Bx for emacs-devel@gnu.org; Sat, 21 Jan 2006 23:05:14 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F0WTY-00010N-Ot for emacs-devel@gnu.org; Sat, 21 Jan 2006 23:05:13 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F0WTX-0000zz-DI for emacs-devel@gnu.org; Sat, 21 Jan 2006 23:05:11 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1F0WY2-0005Mz-5G for emacs-devel@gnu.org; Sat, 21 Jan 2006 23:09:50 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1F0WNf-0006gY-NW; Sat, 21 Jan 2006 22:59:07 -0500 Original-To: Stefan Monnier In-reply-to: <87wtgu8trl.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Fri, 20 Jan 2006 16:56:55 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:49387 Archived-At: 3. some backends (at least url-http, maybe others) sometimes decide not to call the callback, presumably as a way to signal an error (the operation can't be completed so the callback can't be called, basically). This is a bug, but I don't know of anyone who's tried to tackle it yet. What exactly is the bug? It isn't clear to me. Are you saying that they should also call the callback function to report failure? That seems like a good idea on general principles. I don't know how much of a change it would be. Is the calling convention easy to extend for this? 2. sometimes the callback gets called in another buffer than the one returned by url-retrieve. One solution would be to give the first buffer a local variable that would, in this case, point to the second buffer. Then url-retrieve-synchronously could check the local variable, which would tell it to check the process in the other buffer. That solution would be safe, since it would not involve changing general calling conventions. They (and url-retrieve) should either take an optional destination buffer as parameter or they should simply not return any buffer at all and the destination buffer should only be made known when the callback is called. I don't much like the idea of that big a change in calling conventions.