* 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 external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.