all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* eww: call to eww-render looks incorrect
@ 2017-09-02 22:38 raman
  2017-09-03 14:56 ` Eli Zaretskii
  0 siblings, 1 reply; 5+ messages in thread
From: raman @ 2017-09-02 22:38 UTC (permalink / raw)
  To: emacs-devel

In function eww:

eww-render is the callback to url-retrieve: line 267
(url-retrieve url 'eww-render
		(list url nil (current-buffer))))
The order of arguments in that list looks wrong --- at least per
the definition of eww-render, which is (status url buffer &rest args)

-- 



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: eww: call to eww-render looks incorrect
  2017-09-02 22:38 eww: call to eww-render looks incorrect raman
@ 2017-09-03 14:56 ` Eli Zaretskii
  2017-09-03 15:52   ` raman
  0 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2017-09-03 14:56 UTC (permalink / raw)
  To: raman; +Cc: emacs-devel

> Date: Sat, 02 Sep 2017 15:38:09 -0700
> From: raman <raman@google.com>
> 
> In function eww:
> 
> eww-render is the callback to url-retrieve: line 267
> (url-retrieve url 'eww-render
> 		(list url nil (current-buffer))))
> The order of arguments in that list looks wrong --- at least per
> the definition of eww-render, which is (status url buffer &rest args)

In the current master eww-render's signature is

  (defun eww-render (status url &optional point buffer encode)

So I think the CBARGS argument of url-retrieve in that case is
correct, do you agree?



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: eww: call to eww-render looks incorrect
  2017-09-03 14:56 ` Eli Zaretskii
@ 2017-09-03 15:52   ` raman
  2017-09-03 16:27     ` Eli Zaretskii
  0 siblings, 1 reply; 5+ messages in thread
From: raman @ 2017-09-03 15:52 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

I might be confused -- reading that signature I thought status should be
 passed first, the call I see passes url first >> Date: Sat, 02 Sep 2017 15:38:09 -0700
>> From: raman <raman@google.com>
>> 
>> In function eww:
>> 
>> eww-render is the callback to url-retrieve: line 267
>> (url-retrieve url 'eww-render
>> 		(list url nil (current-buffer))))
>> The order of arguments in that list looks wrong --- at least per
>> the definition of eww-render, which is (status url buffer &rest args)
>
> In the current master eww-render's signature is
>
>   (defun eww-render (status url &optional point buffer encode)
>
> So I think the CBARGS argument of url-retrieve in that case is
> correct, do you agree?

-- 



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: eww: call to eww-render looks incorrect
  2017-09-03 15:52   ` raman
@ 2017-09-03 16:27     ` Eli Zaretskii
  2017-09-03 17:50       ` raman
  0 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2017-09-03 16:27 UTC (permalink / raw)
  To: raman; +Cc: emacs-devel

> From: raman <raman@google.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 03 Sep 2017 08:52:20 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> I might be confused -- reading that signature I thought status should be
> passed first, the call I see passes url first

No, status is not included in the list of arguments.  The doc string
says:

  (url-retrieve URL CALLBACK &optional CBARGS SILENT INHIBIT-COOKIES)

  Retrieve URL asynchronously and call CALLBACK with CBARGS when finished.
  URL is either a string or a parsed URL.  If it is a string
  containing characters that are not valid in a URI, those
  characters are percent-encoded; see ‘url-encode-url’.

  CALLBACK is called when the object has been completely retrieved, with
  the current buffer containing the object, and any MIME headers associated
  with it.  It is called as (apply CALLBACK STATUS CBARGS).
  STATUS is a plist representing what happened during the request,

As you see, only CBARGS are taken from the call to url-retrieve, the
status is added when the callback is invoked.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: eww: call to eww-render looks incorrect
  2017-09-03 16:27     ` Eli Zaretskii
@ 2017-09-03 17:50       ` raman
  0 siblings, 0 replies; 5+ messages in thread
From: raman @ 2017-09-03 17:50 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

thanks -- I was clearly confused.>> From: raman <raman@google.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sun, 03 Sep 2017 08:52:20 -0700
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> I might be confused -- reading that signature I thought status should be
>> passed first, the call I see passes url first
>
> No, status is not included in the list of arguments.  The doc string
> says:
>
>   (url-retrieve URL CALLBACK &optional CBARGS SILENT INHIBIT-COOKIES)
>
>   Retrieve URL asynchronously and call CALLBACK with CBARGS when finished.
>   URL is either a string or a parsed URL.  If it is a string
>   containing characters that are not valid in a URI, those
>   characters are percent-encoded; see ‘url-encode-url’.
>
>   CALLBACK is called when the object has been completely retrieved, with
>   the current buffer containing the object, and any MIME headers associated
>   with it.  It is called as (apply CALLBACK STATUS CBARGS).
>   STATUS is a plist representing what happened during the request,
>
> As you see, only CBARGS are taken from the call to url-retrieve, the
> status is added when the callback is invoked.

-- 



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2017-09-03 17:50 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-09-02 22:38 eww: call to eww-render looks incorrect raman
2017-09-03 14:56 ` Eli Zaretskii
2017-09-03 15:52   ` raman
2017-09-03 16:27     ` Eli Zaretskii
2017-09-03 17:50       ` raman

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.