From: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Fwd: HTTP redirects make url-retrieve-synchronously asynchronous
Date: Mon, 23 Jan 2006 11:40:33 -0500 [thread overview]
Message-ID: <jwvzmlmnbos.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <E1F0WNf-0006gY-NW@fencepost.gnu.org> (Richard M. Stallman's message of "Sat, 21 Jan 2006 22:59:07 -0500")
> 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?
Yes.
> 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?
Not directly. The most natural way to do that is to pass the
success/failure information as a parameter to the callback function, but if
we don't want to break existing code, we could pass the info via a local
variable in the destination buffer.
> 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.
Yes, sounds like a good quick-fix.
> 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.
Neither do I, especially not that close to a release. OTOH we haven't
released URL yet so it's the last opportunity to clean up the API.
Stefan
next prev parent reply other threads:[~2006-01-23 16:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-17 19:59 [happy@mcplaksin.org: HTTP redirects make url-retrieve-synchronously asynchronous] Richard Stallman
2006-01-18 3:13 ` Fwd: HTTP redirects make url-retrieve-synchronously asynchronous Stefan Monnier
2006-01-19 17:44 ` Richard M. Stallman
2006-01-20 21:56 ` Stefan Monnier
2006-01-22 3:59 ` Richard M. Stallman
2006-01-23 16:40 ` Stefan Monnier [this message]
2006-01-23 20:38 ` Stefan Monnier
2006-02-19 20:15 ` Mark Plaksin
2006-01-24 16:47 ` Richard M. Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvzmlmnbos.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.