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

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

[T.V Raman]

eww-update-header-line has changed to apply variable-pitch to the
header as of d39ae6f5860ecf6ebbeedc08bf3aafa5befaf510.

This seems to work correctly when browsing Web sites, but it's
breaking in my ebook handler.

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 
-- 
♉ Id: kg:/m/0285kf1  🦮

--
♉ Id: kg:/m/0285kf1  🦮

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

[Lars Ingebrigtsen]

"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.

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

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

[T.V Raman]

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

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

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

[T.V Raman]

[-- 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

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

[Lars Ingebrigtsen]

"T.V Raman" <raman@google.com> writes:

> 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"

If it's a bug somewhere, it sounds like a bug in the `e' command?

In any case, I did push a fix for the title thing, so the bug should no
longer be present in Emacs 28 now.

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

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

[T.V Raman]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:
After pulling
dc01b992e2 * Make the eww header work again even if the title is nil
and building, I still find eww-update-header-line to be broken, stack
trace attached. The issue doesn't repro if I load eww.el from emacs-27.1

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  (propertize nil face variable-pitch)
  (eww-update-header-line-format)
  (eval (eww-update-header-line-format) t)
  (#f(compiled-function (exp &optional insert-value no-truncate char-print-limit) "Evaluate EXP and print value in the echo area.\nWhen called interactively, read an Emacs Lisp expression and\nevaluate it.  Value is also consed on to front of the variable\n`values'.  Optional argument INSERT-VALUE non-nil (interactively,\nwith a non `-' prefix argument) means insert the result into the\ncurrent buffer instead of printing it in the echo area.\n\nNormally, this function truncates long output according to the\nvalue of the variables `eval-expression-print-length' and\n`eval-expression-print-level'.  When NO-TRUNCATE is\nnon-nil (interactively, with a prefix argument of zero), however,\nthere is no such truncation.\n\nIf the resulting value is an integer, and CHAR-PRINT-LIMIT is\nnon-nil (interactively, unless given a non-zero prefix argument)\nit will be printed in several additional formats (octal,\nhexadecimal, and character).  The character format is used only\nif the value is below CHAR-PRINT-LIMIT (interactively, if the\nprefix argument is -1 or the value doesn't exceed\n`eval-expression-print-maximum-character').\n\nRuns the hook `eval-expression-minibuffer-setup-hook' on entering the\nminibuffer.\n\nIf `eval-expression-debug-on-error' is non-nil, which is the default,\nthis command arranges for all errors to enter the debugger." (interactive #f(compiled-function () #<bytecode 0xbfa038de222893f>)) #<bytecode 0xf1a46df5f463156>) (eww-update-header-line-format) nil nil 127)
  (ad-Advice-eval-expression #f(compiled-function (exp &optional insert-value no-truncate char-print-limit) "Evaluate EXP and print value in the echo area.\nWhen called interactively, read an Emacs Lisp expression and\nevaluate it.  Value is also consed on to front of the variable\n`values'.  Optional argument INSERT-VALUE non-nil (interactively,\nwith a non `-' prefix argument) means insert the result into the\ncurrent buffer instead of printing it in the echo area.\n\nNormally, this function truncates long output according to the\nvalue of the variables `eval-expression-print-length' and\n`eval-expression-print-level'.  When NO-TRUNCATE is\nnon-nil (interactively, with a prefix argument of zero), however,\nthere is no such truncation.\n\nIf the resulting value is an integer, and CHAR-PRINT-LIMIT is\nnon-nil (interactively, unless given a non-zero prefix argument)\nit will be printed in several additional formats (octal,\nhexadecimal, and character).  The character format is used only\nif the value is below CHAR-PRINT-LIMIT (interactively, if the\nprefix argument is -1 or the value doesn't exceed\n`eval-expression-print-maximum-character').\n\nRuns the hook `eval-expression-minibuffer-setup-hook' on entering the\nminibuffer.\n\nIf `eval-expression-debug-on-error' is non-nil, which is the default,\nthis command arranges for all errors to enter the debugger." (interactive #f(compiled-function () #<bytecode 0xbfa038de222893f>)) #<bytecode 0xf1a46df5f463156>) (eww-update-header-line-format) nil nil 127)
  (apply ad-Advice-eval-expression #f(compiled-function (exp &optional insert-value no-truncate char-print-limit) "Evaluate EXP and print value in the echo area.\nWhen called interactively, read an Emacs Lisp expression and\nevaluate it.  Value is also consed on to front of the variable\n`values'.  Optional argument INSERT-VALUE non-nil (interactively,\nwith a non `-' prefix argument) means insert the result into the\ncurrent buffer instead of printing it in the echo area.\n\nNormally, this function truncates long output according to the\nvalue of the variables `eval-expression-print-length' and\n`eval-expression-print-level'.  When NO-TRUNCATE is\nnon-nil (interactively, with a prefix argument of zero), however,\nthere is no such truncation.\n\nIf the resulting value is an integer, and CHAR-PRINT-LIMIT is\nnon-nil (interactively, unless given a non-zero prefix argument)\nit will be printed in several additional formats (octal,\nhexadecimal, and character).  The character format is used only\nif the value is below CHAR-PRINT-LIMIT (interactively, if the\nprefix argument is -1 or the value doesn't exceed\n`eval-expression-print-maximum-character').\n\nRuns the hook `eval-expression-minibuffer-setup-hook' on entering the\nminibuffer.\n\nIf `eval-expression-debug-on-error' is non-nil, which is the default,\nthis command arranges for all errors to enter the debugger." (interactive #f(compiled-function () #<bytecode 0xbfa038de222893f>)) #<bytecode 0xf1a46df5f463156>) ((eww-update-header-line-format) nil nil 127))
  (eval-expression (eww-update-header-line-format) nil nil 127)
  (#<subr funcall-interactively> eval-expression (eww-update-header-line-format) nil nil 127)
  (apply #<subr funcall-interactively> eval-expression ((eww-update-header-line-format) nil nil 127))
  (ad-Advice-funcall-interactively #<subr funcall-interactively> eval-expression (eww-update-header-line-format) nil nil 127)
  (apply ad-Advice-funcall-interactively #<subr funcall-interactively> (eval-expression (eww-update-header-line-format) nil nil 127))
  (funcall-interactively eval-expression (eww-update-header-line-format) nil nil 127)
  (#<subr call-interactively> eval-expression nil nil)
  (ad-Advice-call-interactively #<subr call-interactively> eval-expression nil nil)
  (apply ad-Advice-call-interactively #<subr call-interactively> (eval-expression nil nil))
  (call-interactively eval-expression nil nil)
  (command-execute eval-expression)

> "T.V Raman" <raman@google.com> writes:
>
>> 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"
>
> If it's a bug somewhere, it sounds like a bug in the `e' command?
>
> In any case, I did push a fix for the title thing, so the bug should no
> longer be present in Emacs 28 now.

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

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

[Lars Ingebrigtsen]

"T.V Raman" <raman@google.com> writes:

> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   (propertize nil face variable-pitch)
>   (eww-update-header-line-format)

Ah, it's the same problem with

  (propertize (plist-get eww-data :url) ...)

I'll fix...

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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I'll fix...

Pushed.  Can you try again now?  :-/

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

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

[T.V Raman]

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

Works now -- though I still dont understand why it was complaining about
the propertize call on title.

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