* eww-update-header-line: Possible breakage after d39ae6f5860ecf6ebbeedc08bf3aafa5befaf510
@ 2020-09-13 14:22 T.V Raman
2020-09-13 15:08 ` Lars Ingebrigtsen
0 siblings, 1 reply; 9+ messages in thread
From: T.V Raman @ 2020-09-13 14:22 UTC (permalink / raw)
To: emacs-devel
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 🦮
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: eww-update-header-line: Possible breakage after d39ae6f5860ecf6ebbeedc08bf3aafa5befaf510
2020-09-13 14:22 eww-update-header-line: Possible breakage after d39ae6f5860ecf6ebbeedc08bf3aafa5befaf510 T.V Raman
@ 2020-09-13 15:08 ` Lars Ingebrigtsen
2020-09-13 15:27 ` T.V Raman
0 siblings, 1 reply; 9+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-13 15:08 UTC (permalink / raw)
To: T.V Raman; +Cc: emacs-devel
"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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: eww-update-header-line: Possible breakage after d39ae6f5860ecf6ebbeedc08bf3aafa5befaf510
2020-09-13 15:08 ` Lars Ingebrigtsen
@ 2020-09-13 15:27 ` T.V Raman
2020-09-13 15:47 ` T.V Raman
0 siblings, 1 reply; 9+ messages in thread
From: T.V Raman @ 2020-09-13 15:27 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
[-- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: eww-update-header-line: Possible breakage after d39ae6f5860ecf6ebbeedc08bf3aafa5befaf510
2020-09-13 15:27 ` T.V Raman
@ 2020-09-13 15:47 ` T.V Raman
2020-09-13 16:20 ` Lars Ingebrigtsen
0 siblings, 1 reply; 9+ messages in thread
From: T.V Raman @ 2020-09-13 15:47 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
[-- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: eww-update-header-line: Possible breakage after d39ae6f5860ecf6ebbeedc08bf3aafa5befaf510
2020-09-13 15:47 ` T.V Raman
@ 2020-09-13 16:20 ` Lars Ingebrigtsen
2020-09-13 16:43 ` T.V Raman
0 siblings, 1 reply; 9+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-13 16:20 UTC (permalink / raw)
To: T.V Raman; +Cc: emacs-devel
"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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: eww-update-header-line: Possible breakage after d39ae6f5860ecf6ebbeedc08bf3aafa5befaf510
2020-09-13 16:20 ` Lars Ingebrigtsen
@ 2020-09-13 16:43 ` T.V Raman
2020-09-13 16:47 ` Lars Ingebrigtsen
2020-09-13 17:48 ` T.V Raman
0 siblings, 2 replies; 9+ messages in thread
From: T.V Raman @ 2020-09-13 16:43 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
[-- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: eww-update-header-line: Possible breakage after d39ae6f5860ecf6ebbeedc08bf3aafa5befaf510
2020-09-13 16:43 ` T.V Raman
@ 2020-09-13 16:47 ` Lars Ingebrigtsen
2020-09-13 16:52 ` Lars Ingebrigtsen
2020-09-13 17:48 ` T.V Raman
1 sibling, 1 reply; 9+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-13 16:47 UTC (permalink / raw)
To: T.V Raman; +Cc: emacs-devel
"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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: eww-update-header-line: Possible breakage after d39ae6f5860ecf6ebbeedc08bf3aafa5befaf510
2020-09-13 16:47 ` Lars Ingebrigtsen
@ 2020-09-13 16:52 ` Lars Ingebrigtsen
0 siblings, 0 replies; 9+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-13 16:52 UTC (permalink / raw)
To: T.V Raman; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: eww-update-header-line: Possible breakage after d39ae6f5860ecf6ebbeedc08bf3aafa5befaf510
2020-09-13 16:43 ` T.V Raman
2020-09-13 16:47 ` Lars Ingebrigtsen
@ 2020-09-13 17:48 ` T.V Raman
1 sibling, 0 replies; 9+ messages in thread
From: T.V Raman @ 2020-09-13 17:48 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
[-- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-09-13 17:48 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-13 14:22 eww-update-header-line: Possible breakage after d39ae6f5860ecf6ebbeedc08bf3aafa5befaf510 T.V Raman
2020-09-13 15:08 ` Lars Ingebrigtsen
2020-09-13 15:27 ` T.V Raman
2020-09-13 15:47 ` T.V Raman
2020-09-13 16:20 ` Lars Ingebrigtsen
2020-09-13 16:43 ` T.V Raman
2020-09-13 16:47 ` Lars Ingebrigtsen
2020-09-13 16:52 ` Lars Ingebrigtsen
2020-09-13 17:48 ` T.V Raman
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).