bug#24035: 25.1.50; Eww breaks on images?

bug#24035: 25.1.50; Eww breaks on images?

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 5378 bytes --]

When I run, in emacs -Q, `M-x eww http://www.gnu.org/emacs`, I get this:

Debugger entered--Lisp error: (void-function \(setf\ image-property\))
  \(setf\ image-property\)(100 (image :type svg :data "<svg width=\"100\" height=\"100\" version=\"1.1\" xmlns=\"http://www.w3.org/2000/svg\"> <defs> <linearGradient id=\"background\" x1=\"0\" x2=\"0\" y1=\"0\" y2=\"1\"> <stop offset=\"0%\" stop-color=\"#b0b0b0\"></stop> <stop offset=\"100%\" stop-color=\"#808080\"></stop></linearGradient></defs> <rect width=\"100\" height=\"100\" x=\"0\" y=\"0\" x1=\"0\" x2=\"0\" y1=\"0\" y2=\"1\" fill=\"url(#background)\" stroke=\"black\" stroke-width=\"2\"></rect></svg>" :scale 1) :ascent)
  shr-make-placeholder-image((img ((src . "/graphics/heckert_gnu.small.png") (alt . " [A GNU head] "))))
  shr-tag-img((img ((src . "/graphics/heckert_gnu.small.png") (alt . " [A GNU head] "))))
  shr-descend((img ((src . "/graphics/heckert_gnu.small.png") (alt . " [A GNU head] "))))
  shr-tag-a((a ((href . "/")) "\n " (img ((src . "/graphics/heckert_gnu.small.png") (alt . " [A GNU head] "))) (strong nil "GNU") " Operating System"))
  eww-tag-a((a ((href . "/")) "\n " (img ((src . "/graphics/heckert_gnu.small.png") (alt . " [A GNU head] "))) (strong nil "GNU") " Operating System"))
  shr-descend((a ((href . "/")) "\n " (img ((src . "/graphics/heckert_gnu.small.png") (alt . " [A GNU head] "))) (strong nil "GNU") " Operating System"))
  shr-tag-div ...
  shr-descend ...
  shr-tag-div ...
  shr-descend ...
  shr-tag-div ...
  shr-descend ...
  shr-tag-body ...
  shr-descend ...
  shr-tag-html ...
  shr-descend ...
  shr-tag-base ...
  shr-descend ...
  shr-insert-document ...
  eww-display-html(utf-8 "http://www.gnu.org/emacs" nil nil #<buffer *eww*> nil)
  eww-render((:error (error http 404)) "http://www.gnu.org/emacs" nil #<buffer *eww*>)
  apply(eww-render ((:error (error http 404)) "http://www.gnu.org/emacs" nil #<buffer *eww*>))
  url-http-activate-callback()
  url-http-chunked-encoding-after-change-function(11098 11663 565)
  url-http-generic-filter(#<process www.gnu.org> " under a <a rel=\"license\"\nhref=\"http://creativecommons.org/licenses/by-nd/4.0/\">Creative\nCommons Attribution-NoDerivatives 4.0 International License</a>.</p>\n\n
\nb5
\n<!-- start of server/bottom-notes.html -->\n<div id=\"bottom-notes\" class=\"unprintable\">\n<p><a href=\"http://www.fsf.org/about/dmca-notice\">Copyright Infringement Notification</a></p>\n
\n1
\n\n
\n31
\n\n</div>\n<!-- end of server/bottom-notes.html -->\n
\n91
\n\n\n<p class=\"unprintable\">Updated:\n<!-- timestamp start -->\n$Date: 2016/04/11 07:42:02 $\n<!-- timestamp end --></p>\n</div>\n</div>\n</body>\n</html>\n
\n0
\n
\n")
  read-event(nil t 2)
  sit-for(2)
  execute-extended-command(nil "eww" nil)
  funcall-interactively(execute-extended-command nil "eww" nil)
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

In GNU Emacs 25.1.50.4 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2016-07-20 built on clem-w50-mint
Repository revision: 34903335d00387fb3dbeab4cdec189fbf07705a0
Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
System Description:	Linux Mint 18 Sarah

Major mode: eww

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired dired-loaddefs rfc822 mml
mml-sec epa derived epg epg-config mm-decode mm-bodies mm-encode
mailabbrev gmm-utils mailheader sendmail debug network-stream starttls
url-http tls gnutls mail-parse rfc2231 url-gw nsm url-cache url-auth eww
puny mm-url gnus nnheader gnus-util rmail rmail-loaddefs rfc2047 rfc2045
ietf-drums mail-utils wid-edit mm-util mail-prsvr url-queue url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util url-parse auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache url-vars mailcap shr svg xml seq
byte-opt gv bytecomp byte-compile cl-extra help-mode easymenu cconv dom
cl-loaddefs cl-lib subr-x pcase browse-url format-spec cus-start
cus-load time-date mule-util tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev
obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face
macroexp files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
dbusbind inotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 150118 6079)
 (symbols 48 25620 0)
 (miscs 40 868 215)
 (strings 32 34984 6494)
 (string-bytes 1 1279456)
 (vectors 16 18084)
 (vector-slots 8 524888 8692)
 (floats 8 254 94)
 (intervals 56 528 0)
 (buffers 976 15)
 (heap 1024 40757 1476))


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#24035: 25.1.50; Eww breaks on images?

[Lars Ingebrigtsen]

Clément Pit--Claudel <clement.pitclaudel@live.com> writes:

> When I run, in emacs -Q, `M-x eww http://www.gnu.org/emacs`, I get this:
>
> Debugger entered--Lisp error: (void-function \(setf\ image-property\))
>   \(setf\ image-property\)(100 (image :type svg :data "<svg width=\"100\" height=\"100\" version=\"1.1\" xmlns=\"http://www.w3.org/2000/svg\"> <defs> <linearGradient id=\"background\" x1=\"0\" x2=\"0\" y1=\"0\" y2=\"1\"> <stop offset=\"0%\" stop-color=\"#b0b0b0\"></stop> <stop offset=\"100%\" stop-color=\"#808080\"></stop></linearGradient></defs> <rect width=\"100\" height=\"100\" x=\"0\" y=\"0\" x1=\"0\" x2=\"0\" y1=\"0\" y2=\"1\" fill=\"url(#background)\" stroke=\"black\" stroke-width=\"2\"></rect></svg>" :scale 1) :ascent)
>   shr-make-placeholder-image((img ((src . "/graphics/heckert_gnu.small.png") (alt . " [A GNU head] "))))
>   shr-tag-img((img ((src . "/graphics/heckert_gnu.small.png") (alt . " [A GNU head] "))))

Hm...  That's odd.  (setf (image-property ...)) is defined in image.el,
and isn't image.el dumped with Emacs?

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

bug#24035: 25.1.50; Eww breaks on images?

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1275 bytes --]

On 2016-07-20 09:58, Lars Ingebrigtsen wrote:
> Clément Pit--Claudel <clement.pitclaudel@live.com> writes:
> 
>> When I run, in emacs -Q, `M-x eww http://www.gnu.org/emacs`, I get this:
>>
>> Debugger entered--Lisp error: (void-function \(setf\ image-property\))
>>   \(setf\ image-property\)(100 (image :type svg :data "<svg width=\"100\" height=\"100\" version=\"1.1\" xmlns=\"http://www.w3.org/2000/svg\"> <defs> <linearGradient id=\"background\" x1=\"0\" x2=\"0\" y1=\"0\" y2=\"1\"> <stop offset=\"0%\" stop-color=\"#b0b0b0\"></stop> <stop offset=\"100%\" stop-color=\"#808080\"></stop></linearGradient></defs> <rect width=\"100\" height=\"100\" x=\"0\" y=\"0\" x1=\"0\" x2=\"0\" y1=\"0\" y2=\"1\" fill=\"url(#background)\" stroke=\"black\" stroke-width=\"2\"></rect></svg>" :scale 1) :ascent)
>>   shr-make-placeholder-image((img ((src . "/graphics/heckert_gnu.small.png") (alt . " [A GNU head] "))))
>>   shr-tag-img((img ((src . "/graphics/heckert_gnu.small.png") (alt . " [A GNU head] "))))
> 
> Hm...  That's odd.  (setf (image-property ...)) is defined in image.el,
> and isn't image.el dumped with Emacs?

I'm not sure. Opening shr.el and running M-x eval-buffer before calling eww fixes the problem.
Shouldn't shr (require 'image)?

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#24035: 25.1.50; Eww breaks on images?

[Lars Ingebrigtsen]

Clément Pit--Claudel <clement.pit@gmail.com> writes:

> I'm not sure. Opening shr.el and running M-x eval-buffer before
> calling eww fixes the problem.
> Shouldn't shr (require 'image)?

Perhaps the problem is that Emacs hasn't required image.el when shr is
being compiled because you've built an Emacs without X support or
something?

I'll put a `require' in shr, which should fix it...

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

bug#24035: 25.1.50; Eww breaks on images?

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 417 bytes --]

On 2016-07-20 10:46, Lars Ingebrigtsen wrote:
> Perhaps the problem is that Emacs hasn't required image.el when shr
> is being compiled

I guess so.

> because you've built an Emacs without X support or something?

I build Emacs with the default config, plus (recently) x-widgets.

> I'll put a `require' in shr, which should fix it...

Neat, thanks! (Does this mean that you couldn't reproduce this?)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#24035: 25.1.50; Eww breaks on images?

[Lars Ingebrigtsen]

Clément Pit--Claudel <clement.pit@gmail.com> writes:

>> I'll put a `require' in shr, which should fix it...
>
> Neat, thanks! (Does this mean that you couldn't reproduce this?)

Yes.  But can you check whether this works for you now?

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

bug#24035: 25.1.50; Eww breaks on images?

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 360 bytes --]

On 2016-07-20 10:57, Lars Ingebrigtsen wrote:
> Clément Pit--Claudel <clement.pit@gmail.com> writes:
> 
>>> I'll put a `require' in shr, which should fix it...
>>
>> Neat, thanks! (Does this mean that you couldn't reproduce this?)
> 
> Yes.  But can you check whether this works for you now?

Yup, works great now. (How do I mark a bug as fixed?)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#24035: 25.1.50; Eww breaks on images?

[Lars Ingebrigtsen]

Clément Pit--Claudel <clement.pit@gmail.com> writes:

> Yup, works great now. (How do I mark a bug as fixed?)

Oh, it's been so long since I've done that manually...  I just used
debbugs-gnu.  But I think perhaps you just say "closed" at the start of
the start of the email?

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

bug#24035: 25.1.50; Eww breaks on images?

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]

Hi Clément,

In my master branch build, doing (featurep 'image) after emacs -Q returns
t. So does that return nil for you?

Here is my emacs build info:

You can evaluate the below and reply with what you get on M-x
emacs-version-dev? Doing that will save the output to kill-ring.

I get this:


Emacs version: GNU Emacs 25.1.50.6 (x86_64-unknown-linux-gnu, GTK+ Version
2.24.23)
 of 2016-07-20, built using commit 30b3a842ec87d27cfe003b6d4323689d48b3fcd2.

./configure options:
  --with-modules --prefix=/home/kmodi/usr_local/apps/6/emacs/master
'CPPFLAGS=-fgnu89-inline -I/home/kmodi/usr_local/6/include
-I/usr/include/freetype2 -I/usr/include' 'CFLAGS=-ggdb3 -O0'
'CXXFLAGS=-ggdb3 -O0' 'LDFLAGS=-L/home/kmodi/usr_local/6/lib
-L/home/kmodi/usr_local/6/lib64 -ggdb3'

Features:
  XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK2 X11 MODULES

PS: Why is your bug report missing the configure options and Features?

===
(defun emacs-version-dev (here)
  "Display emacs build info and also save it to the kill-ring.
If HERE is non-nil, also insert the string at point."
  (interactive "P")
  (let ((emacs-build-info
         (concat "Emacs version: " (emacs-version) ","
                 " built using commit " emacs-repository-version ".\n\n"
                 "./configure options:\n  " system-configuration-options
"\n\n"
                 "Features:\n  " system-configuration-features "\n")))
    (kill-new emacs-build-info)
    (message "%s" emacs-build-info)
    (when here
      (insert emacs-build-info))
    emacs-build-info))


-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 2436 bytes --]

bug#24035: 25.1.50; Eww breaks on images?

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

Lars said:
> Oh, it's been so long since I've done that manually...  I just used
debbugs-gnu.  But I think perhaps you just say "closed" at the start of
the start of the email?

To close out bug # NNNNN, simply send an email to NNNNN-done@debbugs.gnu.org
.

But do you think this fix is the right fix? Because image is loaded fine at
emacs -Q startup for me.

> --

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 866 bytes --]

bug#24035: 25.1.50; Eww breaks on images?

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 219 bytes --]

On 2016-07-20 11:25, Kaushal Modi wrote:
> But do you think this fix is the right fix? Because image is loaded fine at emacs -Q startup for me.

So is it for me; the problem was that shr was incorrectly compiled.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#24035: 25.1.50; Eww breaks on images?

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

OK, cool!

How did you figure that out? Also how did shr get incorrectly compiled? I
am fairly ignorant about the build process. So I am asking this just for my
knowledge.

As long as make does not end in an error, I will assume that everything
went alright.

So then, this commit (
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=90fb0b2d13d0f44ecb9606587681cb4d8a6f0225
)
should not be needed.

On Wed, Jul 20, 2016 at 11:32 AM Clément Pit--Claudel <clement.pit@gmail.com>
wrote:

> On 2016-07-20 11:25, Kaushal Modi wrote:
> > But do you think this fix is the right fix? Because image is loaded fine
> at emacs -Q startup for me.
>
> So is it for me; the problem was that shr was incorrectly compiled.
>
> --

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1286 bytes --]

bug#24035: 25.1.50; Eww breaks on images?

[Lars Ingebrigtsen]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> But do you think this fix is the right fix? Because image is loaded
> fine at emacs -Q startup for me.

I think it's the right fix, anyway.  shr can be used on non-X builds and
shouldn't break just because a non-X Emacs has been used to compile it.
So requiring image is correct.

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

bug#24035: 25.1.50; Eww breaks on images?

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 291 bytes --]

On Wed, Jul 20, 2016 at 11:56 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> I think it's the right fix, anyway.  shr can be used on non-X builds and
> shouldn't break just because a non-X Emacs has been used to compile it.
> So requiring image is correct.
>

OK, thanks.
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 671 bytes --]

bug#24035: 25.1.50; Eww breaks on images?

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 710 bytes --]

On 2016-07-20 11:35, Kaushal Modi wrote:
> OK, cool!
> 
> How did you figure that out? Also how did shr get incorrectly compiled? 

shr calls setf on (image-property). That will only work if there's a setter defined for image-property; otherwise, the setf macro will be expanded incorrectly at compile time. That setter is only available if image has been loaded.

> So then, this commit ( http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=90fb0b2d13d0f44ecb9606587681cb4d8a6f0225 ) should not be needed.

I think this is the right fix. shr does require image to be loaded for the setf to compile properly. Thus the dependency explicit is the right thing to do (I think).

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]