[PATCH] Search for image from the beginning of the fetched buffer

[PATCH] Search for image from the beginning of the fetched buffer

[Grégoire Jadi]

Hi,

Some background : When browsing files locally (file://) images are never
rendered right the first time by eww/shr. I have to use redisplay
(`eww-redisplay') to display the images.
In the *Message* buffer, I've the following error :
> ImageMagick error: no decode delegate for this image format `' @ error/blob.c/BlobToImage/353

After a bit of lurking, I found out that the image where correctly
restored from the cache, because it starts to parse at position 1.
However, the position in the buffer in `shr-image-fetched' is something
else >1. I haven't figured out why the position isn't right (I suspect
something in `url-file').

The fix I've found so far is to force position 1 in `shr-image-fetched'.
I've also disabled multibyte because `shr-get-image-data' does it, but
it might be unnecessary.
Patch below.

Best,

PS: I've FSF copyright assignment number #793656

* lisp/net/shr.el (shr-image-fetched): Disable multibyte and go back
  to the beginning of the buffer before trying to parse the image
  fetched.
---
 lisp/net/shr.el | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lisp/net/shr.el b/lisp/net/shr.el
index 4d4e8a809e..b4dd60cf48 100644
--- a/lisp/net/shr.el
+++ b/lisp/net/shr.el
@@ -945,6 +945,8 @@ shr-image-fetched
     (when (and (buffer-name buffer)
 	       (not (plist-get status :error)))
       (url-store-in-cache image-buffer)
+      (goto-char (point-min))
+      (mm-disable-multibyte)
       (when (or (search-forward "\n\n" nil t)
 		(search-forward "\r\n\r\n" nil t))
 	(let ((data (shr-parse-image-data)))
-- 
2.13.1

Re: [PATCH] Search for image from the beginning of the fetched buffer

[Lars Ingebrigtsen]

gjadi@omecha.info (Grégoire Jadi) writes:

> After a bit of lurking, I found out that the image where correctly
> restored from the cache, because it starts to parse at position 1.
> However, the position in the buffer in `shr-image-fetched' is something
> else >1. I haven't figured out why the position isn't right (I suspect
> something in `url-file').
>
> The fix I've found so far is to force position 1 in `shr-image-fetched'.
> I've also disabled multibyte because `shr-get-image-data' does it, but
> it might be unnecessary.
> Patch below.

Thanks; applied (but I left the multibyte stuff out -- it shouldn't be
necessary).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: [PATCH] Search for image from the beginning of the fetched buffer

[Grégoire Jadi]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> gjadi@omecha.info (Grégoire Jadi) writes:
>
>> After a bit of lurking, I found out that the image where correctly
>> restored from the cache, because it starts to parse at position 1.
>> However, the position in the buffer in `shr-image-fetched' is something
>> else >1. I haven't figured out why the position isn't right (I suspect
>> something in `url-file').
>>
>> The fix I've found so far is to force position 1 in `shr-image-fetched'.
>> I've also disabled multibyte because `shr-get-image-data' does it, but
>> it might be unnecessary.
>> Patch below.
>
> Thanks; applied (but I left the multibyte stuff out -- it shouldn't be
> necessary).

Ok, thank you.