Re: eww-update-header-line: Possible breakage after d39ae6f5860ecf6ebbeedc08bf3aafa5befaf510

["T.V Raman" <raman@google.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1731 bytes --]

"T.V Raman" <raman@google.com> writes:
Could be a possible bug in propertize?

With the epub rendered in EWW buffer as current buffer:

In addition to the minibuffer eval results shown earlier,

(propertize (plist-get eww-data :title) 'face 'variable-pitch)
thorws the
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
which is the same error that eww-update-header-line threw,
while
(plist-get eww-data :title)
returns a string,

Both of the above evaluated in the relevant stack frame via "e"

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> eww-update-header-line was seeing the title as nil which is what
> surprized me.
>
> So: with the rendered buffer as current buffer, evaluating these in the
> minibuffer:
>
> (plist-get eww-data :title) returned the title I had set, but evaluating
>  (eww-update-header-line) in the minibuffer threw an error, with the
>  debugger showing that propertize had been  called with a null string > "T.V Raman" <raman@google.com> writes:
>>
>>> I'm setting eww-data correctly, and plist-get shows that :title is set
>>> correctly in eww-data when I go to the buffer where the ebook is
>>> rendered. However eww-update-header-line throws an error on this line:
>>>
>>> +	     (let ((title (propertize (plist-get eww-data :title)
>>>
>>>   appears that  plist-get in the above call returns nil within
>>>        eww-update-header-line --not sure why 
>>
>> If that bugs out, then :title in eww-data can't be a string, I think?
>>
>> But I see that the old code supported a nil value for title, so I've now
>> tweaked the code a bit to avoid bugging out in this case.  Pushed to the
>> trunk now.

-- 
7©4 Id: kg:/m/0285kf1  •0Ü8