Wrong type argument: integer-or-marker-p, nil

[tareefdev]

Recently I'm getting this error message org-web-tools--url-as-readable-org: Wrong type argument: integer-or-marker-p, nil with a lot of articles (here is an example).

This happens with Emacs 26.1 on both Arch Linux and Debian.

[alphapapa]

Please provide a backtrace.

[tareefdev]

Here is the backtrace:

Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
  org-web-tools--get-url("https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction")
  org-web-tools--url-as-readable-org("https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction")
  org-web-tools-read-url-as-org("https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction")
  funcall-interactively(org-web-tools-read-url-as-org "https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction")
  call-interactively(org-web-tools-read-url-as-org record nil)
  command-execute(org-web-tools-read-url-as-org record)
  #f(compiled-function (cmd) #<bytecode 0x18019f5>)("org-web-tools-read-url-as-org")
  ivy-call()
  ivy-read("M-x " ("set-variable" "use-package-report" "emacs-init-time" "global-hl-line-mode" "prettier-js" "js2r-kill" "list-packages" "package-install" "rename-file-and-buffer" "load-theme" "eval-buffer" "org-web-tools-insert-web-page-as-entry" "flyspell-mode" "browse-url-of-file" "rgrep" "count-words" "git-link" "mu4e" "customize-themes" "tide-restart-server" "magit-clone" "calendar" "deadgrep" "flyspell-buffer" "dired-do-query-replace-regexp" "display-line-numbers-mode" "yas-global-mode" "lisp-mode" "magit-log-buffer-file" "eshell" "yas-visit-snippet-file" "ispell-change-dictionary" "org-mode" "ibuffer" "markdown-export" "man" "package-list-packages" "timeclock-in" "delete-region" "flycheck-mode" "revert-buffer" "yas-insert-snippet" "browse-url-of-buffer" "zeal-at-point" "mml-secure-message-encrypt-pgp" "shell" "menu-bar-mode" "web-mode" "edit-file-sudo" "writeroom-mode" ...) :predicate nil :require-match t :history counsel-M-x-history :action #f(compiled-function (cmd) #<bytecode 0x18019f5>) :sort nil :keymap (keymap (67108908 . counsel--info-lookup-symbol) (67108910 . counsel-find-symbol)) :initial-input nil :caller counsel-M-x)
  counsel-M-x()
  funcall-interactively(counsel-M-x)
  call-interactively(counsel-M-x nil nil)
  command-execute(counsel-M-x)

[alphapapa]

I copied that URL to my clipboard and ran org-web-tools-read-url-as-org, and it loaded without any errors. Are you using the latest version of the package?

[tareefdev]

I have this version org-web-tools-20190709.1124, did you compile Emacs yourself?

[alphapapa]

Yes, why?

[tareefdev]

Because I tried to use org-web-tools with an empty init file and got the same error. So the only possibility here is your build is different than Debian / Arch one.

[alphapapa]

Other users haven't reported the problem, so it's working for users other than myself. And those other users aren't using my Emacs package, so it's very unlikely that the issue is caused by my Emacs installation (which is built from Emacs 26.1 using Kevin Kelley's packaging, which doesn't mess with any defaults).

The problem at the moment is that the backtrace doesn't show exactly where the error is occurring. The only place I can see where a (wrong-type-argument integer-or-marker-p nil) error could occur in org-web-tools--get-url is in the sexp (delete-region (point-min) url-http-end-of-headers), which suggests that url-http-end-of-headers is nil. If so, that would suggest that url-retrieve-synchronously did not work properly, and that probably means that the error is caused by a TLS problem.

Unfortunately, when I try to access http://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction, the server redirects to the HTTPS URL, which makes it difficult to test without TLS. But I suggest trying it anyway; if it works, we'll know the problem is TLS-related.

If the problem is TLS-related, it's probably related to the recently reported issues with the GNU ELPA repository's server's TLS support not allowing connections for some Emacs users.

If all of that is true, the problem lies not with org-web-tools. I would hope that url-retrieve-synchronously would raise an error if a TLS error occurs, but maybe it doesn't. In that case, I could add some checking to raise an error from this package, but it wouldn't fix the TLS problem.

So, my suggestions:

1. Try accessing the URLs that have been failing for you without TLS.
2. Try accessing them over TLS using other platforms (e.g. Mac or Windows) and/or Emacs versions.
3. See if your Emacs can access GNU ELPA over TLS.
4. Try using some of the TLS testing sites on the URLs that are failing for you, and see if they indicate any errors in the servers' TLS configurations.

[tareefdev]

I really appreciate such a great answer. Thanks for your time. I tried org-web-tools on Ubuntu 18.04 (Emacs 26.1), and it works with the same link! After that, I tried to update packages on my machine and got this error

 (file-error https://elpa.gnu.org/packages/let-alist-1.0.6.el Bad Request)

Using --debug-init or debug-on-error doesn't give me more information, also, setting (setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3") didn't solve the bad request problem, so I'm not sure is those two problems are related or not.

[alphapapa]

I see you found the discussion on Reddit. :) Sorry to hear that that setting doesn't fix the problem, but at least we know that it is probably related to TLS and not a problem in this package.

To investigate further, maybe you can inspect the HTTP headers from url and find out why it's a bad request.

Since this isn't a bug in this package, I'm going to close the issue, but feel free to continue sharing what you find out, in case it helps someone in the future. You also might consider discussing it on Reddit or emacs-devel; if you do, please link it here.

Thanks.

[tareefdev]

Thanks for your help. I'm going to discuss the issue more on Reddit and IRC channels.

[tareefdev]

The solution here solved my issue.