emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect art


From: Jens Schmidt
Subject: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]
Date: Sat, 22 Jul 2023 11:06:29 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

Tags: patch

`org-store-link' has a number of related issues when storing links from
article buffers related to nnvirtual, nnselect, or nnir groups.  I
describe them here in prose without providing a full repro case, which
would be somewhat difficult to set up.  Just let me know if you think
you need more information, I have the data available.

The most obvious symptom is this:

- Create an nnselect group and open an article from that.  In the
  article buffer, do M-x org-store-link RET, then paste the link with
  C-c C-l in some Org mode buffer.  The resulting link looks like

    gnus:#E18xcfu-0004HT-00@fencepost.gnu.org

  That is, it lacks the group name before the hash sign.  Correct would
  have been:

    gnus:nnml+archive:test01#E18xcfu-0004HT-00@fencepost.gnu.org

  Starting with Emacs 30, you even more obviously get an error:

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
      nnselect-article-group(nil)
      org-gnus-store-link()
      org-store-link(nil 1)
      funcall-interactively(org-store-link nil 1)
      call-interactively(org-store-link record nil)
      command-execute(org-store-link record)
      execute-extended-command(nil "org-store-link" nil)
funcall-interactively(execute-extended-command nil "org-store-link" nil)
      call-interactively(execute-extended-command nil nil)
      command-execute(execute-extended-command)

Less obvious, occuring for nnvirtual groups:

- Create an nnvirtual group and open an article from that.  In the
  article buffer, do M-x org-store-link RET.  Observe the "current
  article arrow" in the fringe being set in the article header, even
  though that arrow should be used only in a summary buffer.

The root cause is that some of the Gnus functions used in
`org-gnus-store-link' must be called only in summary buffers, and not in
article buffers.  These are:

  gnus-summary-article-number
  nnselect-article-group

Not sure about these, but it is probably also better to call these in
summary buffers only:

  nnvirtual-map-article
  nnir-article-group

The remedy for these issues is simple: When calling above functions just
temporarily and unconditionally switch to the summary buffer with

  (with-current-buffer gnus-summary-buffer ...)

where buffer-local variable `gnus-summary-buffer' in an article buffer
points to the summary buffer where the articles comes from.  (And for
a summary buffer the variable points to the summary buffer itself.)

Finally, there is a related inefficiency when determining the article
header structure in function `org-gnus-store-link': Here the authors
indeed switch to the summary buffer when currently in the article
buffer, but using "user-land" interactive function
`gnus-article-show-summary' to do so where a simple

  (with-current-buffer gnus-summary-buffer ...)

would suffice.

Emacs : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2023-07-20
Package: Org mode version 9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)

Attachment: 0001-ol-gnus.el-Fix-issue-when-storing-links-from-Gnus-ar.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]