gnus: link annoyance

gnus: link annoyance

[François Pinard]

Hi, Org people.

Still playing with one of my little tools (called org-grep), I added the
capability of searching Unix mailbox (producing "rmail:" links) and Gnus
mailgroups (producing "gnus:" links).  This resurrected an old "gnus:"
annoyance I once reported on this mailing list, yet without being able
to convince anybody there was a problem.  I dare trying again! :-)

Whenever I visit a "gnus:" type link from Org, it has the side effect of
"reading" the article in Gnus parlance, forcing me to "unread" it each
time afterwards.  If I forget to unread it, which is a likely error, the
article will not be shown if I later visit its mailgroup using Gnus in a
regular way.  So in practice, it is kind of forever lost.

This is a sad side-effect of "gnus:" links.  In this area, Org should
immediately unread any "gnus:" link it follows, or else and maybe even
better, leave the reached article with the flags it already has.  If the
user explicitly saved the article in an Org file using "org-store-link",
(s)he surely though of it as kind of permanent, and Org should then not
"read" it, even the user did not "bang" it.  If the link is dynamically
created like with org-grep, and the user happens to follow one of these
links among many others, the user should not be "punished" by loosing
the article because (s)he forgot to explicitly unread it :-).

François

P.S. Who also has a question about "rmail:" and "gnus:" links.  Is there
a way in the link syntax allowing a precise line positioning within the
article?  It would be wonderful for org-grep, that would then make great
use of such a possibility.

Re: gnus: link annoyance

[Nick Dokos]

François Pinard <pinard@iro.umontreal.ca> writes:

> Whenever I visit a "gnus:" type link from Org, it has the side effect of
> "reading" the article in Gnus parlance, forcing me to "unread" it each
> time afterwards.  If I forget to unread it, which is a likely error, the
> article will not be shown if I later visit its mailgroup using Gnus in a
> regular way.  So in practice, it is kind of forever lost.
>

Maybe I'm misunderstanding (not deliberately, I assure you) what you
mean but it's certainly not lost: the link continues to work, even if it
points to a read article; and visiting the group with C-u <SPACE>
in gnus also allows you to see previously read articles. It's only
expired articles that can never be gotten back after their expiration
period runs out.

But maybe that's what you are alluding to when you say "visiting the
group in a regular way"?

Nick

Re: gnus: link annoyance

[François Pinard]

Nick Dokos <ndokos@gmail.com> writes:

> François Pinard <pinard@iro.umontreal.ca> writes:

>> Whenever I visit a "gnus:" type link from Org, it has the side effect of
>> "reading" the article in Gnus parlance, forcing me to "unread" it each
>> time afterwards.

> it's certainly not lost: the link continues to work, even if it points
> to a read article; and visiting the group with C-u <SPACE> in gnus
> also allows you to see previously read articles.

Hi, Nick.

Of course, you are fully right in that the article is still there, and
likely unexpired.  But in practice, from my viewpoint, it is not there
anymore: I do not usually enter groups by C-u SPC.  While possible, it
is unusual that I want to find and read again an article which I once
decided has been read for good.

If I search all mailgroups for a certain string, and randomly check
hits, I do not want these articles I check to later have disappeared
from sight in practice.  I was not really in the process of reading
articles, but merely checking on them.  It would not make sense that Org
removes lines that I visit after a grep, and when grepping through many
files, would they be Org, non-Org, mailboxes or articles in mailgroups,
I am in a mode where I do not expect any kind of altering behaviour.

François

Re: gnus: link annoyance

[Nick Dokos]

François Pinard <pinard@iro.umontreal.ca> writes:

> Nick Dokos <ndokos@gmail.com> writes:
>
>> François Pinard <pinard@iro.umontreal.ca> writes:
>
>>> Whenever I visit a "gnus:" type link from Org, it has the side effect of
>>> "reading" the article in Gnus parlance, forcing me to "unread" it each
>>> time afterwards.
>
>> it's certainly not lost: the link continues to work, even if it points
>> to a read article; and visiting the group with C-u <SPACE> in gnus
>> also allows you to see previously read articles.
>
> Hi, Nick.
>
> Of course, you are fully right in that the article is still there, and
> likely unexpired.  But in practice, from my viewpoint, it is not there
> anymore: I do not usually enter groups by C-u SPC.  While possible, it
> is unusual that I want to find and read again an article which I once
> decided has been read for good.
>

The question is how one deals with those unusual cases where you do want
to revisit an article (or a mail message: to gnus they are the same thing).

> If I search all mailgroups for a certain string, and randomly check
> hits, I do not want these articles I check to later have disappeared
> from sight in practice.  I was not really in the process of reading
> articles, but merely checking on them.

You call it checking but you are really reading them: how exactly is org
or gnus to know that even though you are reading the articles, you are
not really reading them?

>  It would not make sense that Org removes lines that I visit after a
> grep, and when grepping through many files, would they be Org,
> non-Org, mailboxes or articles in mailgroups, I am in a mode where I
> do not expect any kind of altering behaviour.
>

But it doesn't: the links in the org file still work. In any case,
you must have read the article in order to determine that you want to
save a link to it. Then following the link does not change the flags:
it was read before, it's still read after.

I suspect however that my arguments are going to convince you just as
much as your arguments have convinced me :-)
-- 
Nick

Re: gnus: link annoyance

[François Pinard]

Nick Dokos <ndokos@gmail.com> writes:

> I suspect however that my arguments are going to convince you just as
> much as your arguments have convinced me :-)

Hi, Nick.  You know, it always has been a pleasure corresponding with
you, and enjoying your respectful attitude.  In the case here, I'm not
so trying to convince you, than to alleviate a bit of my misery! :-)

> The question is how one deals with those unusual cases where you do
> want to revisit an article (or a mail message: to gnus they are the
> same thing).

Well, using Gnus interactively or through Emacs Lisp programming does
not have to be the same thing, programs may bend Gnus behaviour.

> You call it checking but you are really reading them: how exactly is org
> or gnus to know that even though you are reading the articles, you are
> not really reading them?

Org could tell Gnus that I am not really reading an article as if I was
using Gnus interactively.  When a user interactively created an Org link
to a Gnus article (likely using C-c l), (s)he decided at the time if the
article was to be left read, unread, ticked or otherwise.  The human
decision has been taken at the time the Org link was created.  When Org
later visits that link and triggers Gnus into displaying the article, it
could get Gnus to do nothing else then display it, keeping the prior
human decision unaltered, defeating a Gnus automatism that mainly make
sense when reading interactively from Gnus (and not from Org), leaving
the responsibility to the user to explicitly change the prior human
decision if this is then deemed appropriate.

> the links in the org file [to previously read articles] still work.

Which is wonderful, indeed.  I can read an article, leave it "read", and
still save a working Org link on a article who disappeared out of sight.

> In any case, you must have read the article in order to determine that
> you want to save a link to it. Then following the link does not change
> the flags: it was read before, it's still read after.

Exactly! :-) Your last sentence summarizes all of my desires!  But I
would complete it, just to make sure it extremely clear:

   Then following the link does not change the flags: it was read
   before, it's still read after; it was unread before, it's still
   unread after.

Hoping that you forgive my friendly tease!  Keep happy!

François

Re: gnus: link annoyance

[Achim Gratz]

François Pinard writes:
> Org could tell Gnus that I am not really reading an article as if I was
> using Gnus interactively.

You keep saying that; while clearly you could coerce Gnus into doing
something like that I'm not sure Gnus would entertain to listen to such
a request.  This is probably best asked on a Gnus mailing list, but it
seems that Gnus wants to present search results in an ephemeral group.
If you treat a link as a search that finds one article, then the problem
you're trying to solve goes away, I'd think.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: gnus: link annoyance

[François Pinard]

Achim Gratz <Stromeko@nexgo.de> writes:

> François Pinard writes:

>> Org could tell Gnus that I am not really reading an article as if I was
>> using Gnus interactively.

> You keep saying that; while clearly you could coerce Gnus into doing
> something like that I'm not sure Gnus would entertain to listen to
> such a request.  This is probably best asked on a Gnus mailing list,
> but it seems that Gnus wants to present search results in an ephemeral
> group.  If you treat a link as a search that finds one article, then
> the problem you're trying to solve goes away, I'd think.

The whole discussion is about how Org mode should best follow "gnus:"
links.  I surely do not mind if Org uses ephemeral groups or any other
kind of machinery.  My only suggestion is that, whatever the mechanics,
Org following a "gnus:" link should manage so Gnus does not change the
article flags.  If Org asks Gnus to perform a search to locate a given
article, it seems like overkill to me, but I may well be wrong and not
see the advantages.

François

Re: gnus: link annoyance

[Bastien]

If the patch I sent in this thread does not raise problems, I
suggest we simply offer an option to let the user decide whether
he wants the flags to be changed or not.

Please continue testing the patch and report any problem,
I'll do so myself.

-- 
 Bastien

Re: gnus: link annoyance

[Rasmus]

Hi François,

Thanks for working on org-grep.  It looks interesting.

Excuse me if I misunderstood something below.

François Pinard <pinard@iro.umontreal.ca> writes:

> Whenever I visit a "gnus:" type link from Org, it has the side effect of
> "reading" the article in Gnus parlance, forcing me to "unread" it each
> time afterwards.  If I forget to unread it, which is a likely error, the
> article will not be shown if I later visit its mailgroup using Gnus in a
> regular way.  So in practice, it is kind of forever lost.
> [...]
> This is a sad side-effect of "gnus:" links.  In this area, Org should
> immediately unread any "gnus:" link it follows, or else and maybe even
> better, leave the reached article with the flags it already has.

You read it, no?  How can it not be marked read when you read it?

Perhaps you would like to the following on mailgroups you care about
(from the *Groups* buffer):

    G c C-s Display S-TAB RET TAB RET 1 TAB 100 M-< TAB TAB RET

Also, you can search with nnir using GG or C-u GG (but links probably
won't work from a nnir buffer).
    
> If the user explicitly saved the article in an Org file using
> "org-store-link", (s)he surely though of it as kind of permanent,
> and Org should then not "read" it, even the user did not "bang" it.

I cannot reproduce using the following receipt: 

  1. Mark an article as important with '!',
     (gnus-summary-tick-article-forward N)
  1. (org-store-link)
  2. org-insert-link with the above link in org-buffer
  3. Open link.  My tick is preserved.

I can also change the mark to gnus-summary-mark-as-expirable and
preserve the link.  I cannot preserve an unread mark when I read it,
but it shouldn't 'cause I read the article. . .

Cheers,
Rasmus

--
When the facts change, I change my mind. What do you do, sir?

Re: gnus: link annoyance

[François Pinard]

Rasmus <rasmus@gmx.us> writes:

> Thanks for working on org-grep.  It looks interesting.

Thanks for thanking! :-) But deep down, I'm really doing this tool for
myself, and only then share it with others.  Given the amount of notes I
handle, such a tool is inescapable, it is a question of survival :-).

>> Whenever I visit a "gnus:" type link from Org, it has the side effect of
>> "reading" the article in Gnus parlance, forcing me to "unread" it each
>> time afterwards.

> Excuse me if I misunderstood something below.  You read it, no?  How
> can it not be marked read when you read it?

The list gnus-mark-article-hook, which is there for customization, has
the function gnus-summary-mark-read-and-unread-as-read by default.  I
guess that if the hook list was empty, articles would be displayed and
not automatically marked as read.

> Perhaps you would like to the following on mailgroups you care about
> (from the *Groups* buffer):

>     G c C-s Display S-TAB RET TAB RET 1 TAB 100 M-< TAB TAB RET

> Also, you can search with nnir using GG or C-u GG (but links probably
> won't work from a nnir buffer).

I would not think one should modify his Gnus habits or methods merely
because Org has a tool to search in Gnus.  Org uses Gnus, but Gnus
should not be disturbed because of that.

>   1. Mark an article as important with '!',
>      (gnus-summary-tick-article-forward N)

But I do not want to tick (or bang) articles because I do Org searches.
When really in Gnus, if I want to keep an article, I unread it.  But
that does not mean I consider this article especially important.  If I
want to mark an article as important, I bang it, and as a consequence,
Gnus unread it.  Banging all articles I want to keep unread is not only
overkill, but it spoils the bang mark, which I find very useful for
other purposes than Org.

> I can also change the mark to gnus-summary-mark-as-expirable and
> preserve the link.

One possibility (untested, so I'm not sure) is that when following a
"gnus:" link, Org could use something like:

   (let ((gnus-mark-article-hook nil))
     (ACCESS-THE-gnus:-LINK))

François

Re: gnus: link annoyance

[Bastien]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

Hi François,

François Pinard <pinard@iro.umontreal.ca> writes:

> One possibility (untested, so I'm not sure) is that when following a
> "gnus:" link, Org could use something like:
>
>    (let ((gnus-mark-article-hook nil))
>      (ACCESS-THE-gnus:-LINK))

I attach a patch to see if it does what you want.

This is from a quick exploration, and while testing it,
somes links to gwene.org blog entries were throwing a
501 error message (but still display the article.)

Take it as a basis for clarifying the discussion, not
really a solution right now!


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-gnus-display-article.patch --]
[-- Type: text/x-diff, Size: 898 bytes --]

diff --git a/lisp/org-gnus.el b/lisp/org-gnus.el
index e368a14..968c556 100644
--- a/lisp/org-gnus.el
+++ b/lisp/org-gnus.el
@@ -262,7 +262,7 @@ If `org-store-link' was called with a prefix arg the meaning of
 	       (cond
 		((eq backend 'nndoc)
 		 (if (gnus-group-read-group t nil group)
-		     (gnus-summary-goto-article article nil t)
+		     (gnus-summary-display-article article)
 		   (message "Couldn't follow gnus link.  %s"
 			    "The summary couldn't be opened.")))
 		(t
@@ -283,7 +283,7 @@ If `org-store-link' was called with a prefix arg the meaning of
 					(1+ articles)
 				      (* articles 2))))
 		   (if group-opened
-		       (gnus-summary-goto-article article nil t)
+		       (gnus-summary-display-article article)
 		     (message "Couldn't follow gnus link.  %s"
 			      "The summary couldn't be opened."))))))
 	   (quit (message "Couldn't follow gnus link.  %s"

[-- Attachment #3: Type: text/plain, Size: 14 bytes --]


-- 
 Bastien

Re: gnus: link annoyance

[François Pinard]

Bastien <bzg@gnu.org> writes:

> I attach a patch to see if it does what you want.  This is from a
> quick exploration, and while testing it, somes links to gwene.org blog
> entries were throwing a 501 error message (but still display the
> article.)  Take it as a basis for clarifying the discussion, not
> really a solution right now!

Hi, Bastien.

Thanks.  I quickly tried the patch this morning, and it appears to be
usable so far.  I'll let it cook for a while, and report any
misbehaviour I would observe :-).

François

Re: gnus: link annoyance

[Rasmus]

Hi François,

François Pinard <pinard@iro.umontreal.ca> writes:

> The list gnus-mark-article-hook, which is there for customization, has
> the function gnus-summary-mark-read-and-unread-as-read by default.  I
> guess that if the hook list was empty, articles would be displayed and
> not automatically marked as read.

Yeah.  There's a bunch of other possible functions, but none of them
seem to work here (though nil might work nicely).

(apropos-documentation "gnus-mark-article-hook")

>> Perhaps you would like to the following on mailgroups you care about
>> (from the *Groups* buffer):
>
>>     G c C-s Display S-TAB RET TAB RET 1 TAB 100 M-< TAB TAB RET
>
>> Also, you can search with nnir using GG or C-u GG (but links probably
>> won't work from a nnir buffer).
>
> I would not think one should modify his Gnus habits or methods merely
> because Org has a tool to search in Gnus.  Org uses Gnus, but Gnus
> should not be disturbed because of that.

I agree.  The method is a way to make Gnus act like a 'normal' MUA in
mail groups.  Combined with expiring it would give you almost the same
work-flow, but in more 'traditionalist' manner, if e.g. TB represents
a 'traditional' MUA.

>>   1. Mark an article as important with '!',
>>      (gnus-summary-tick-article-forward N)
>
> But I do not want to tick (or bang) articles because I do Org searches.
> When really in Gnus, if I want to keep an article, I unread it.  But
> that does not mean I consider this article especially important.

It seems counter-intuitive to me, but it's not my mailbox!

Just out of curiosity, 'cause I'm still not fully appreciating your
setup; Say you have a mail X that's semi-interesting.  Do you then,
read it, mark it as unread, close the buffer, go back later, read it
again and unread it?

I used to use a similar setup in Thunderbird, though I would 'archive'
boring emails ('expire' in Gnus, I guess) and keep the remaining read
emails in my inbox together with new emails.

Cheers,
Rasmus

-- 
I hear there's rumors on the, uh, Internets. . .

Re: gnus: link annoyance

[François Pinard]

Rasmus <rasmus@gmx.us> writes:

> Say you have a mail X that's semi-interesting.  Do you then, read it,
> mark it as unread, close the buffer, go back later, read it again and
> unread it?

I once used Gnus as a reader who tremendously helped me at handling the
high email volume of email I got when I maintained many GNU packages
(the Translation Project and also "tar" were pretty generative!) and
following lots of newsgroups.  Now that I got out of maintenance, Gnus
as a mail reader is a bit of overkill, but I still use it to peruse
archives I collected on many subjects, in about a thousand of nnfolders.

Searching them all is often convenient.  Normally, I only delete
articles from one of these archives when I decide to ponder it whole and
clean it up, and then read articles one after another the normal Gnus
way.  Otherwise, I prefer them untouched even if casually consulted,
postponing the cleanup until I get motivation and a good chunk of time.

For the detail, when not in clean mode, I often unread an article just
after having read it, or when I know I am perusing a lot, just let them
read but quit by "Q" instead of "q", which reverts all the marks.

From an hits buffer generated by org-grep, I can get many hits of many
kinds (Org, non-Org, mailboxes or mailgroups), and while checking many
of these links in speedy mode, it slows me down considerably if I have
to stay alert and careful at unreading Gnus articles among the rest, and
fairly dangerous if I get tired and stop being careful.

François

Re: gnus: link annoyance

[Joseph Vidal-Rosset]

Hello François (bonjour Montréal), hello the list, 

I do  not want to  be rude  in asking a  newbie question in  this thread
about Gnus and Org. But I would be  happy to know if the thing to what I
think exists or not, and it is a possible thing or not. 

Le   mar.    07   janv.    2014   à    06:36:02   ,    François   Pinard
<pinard@iro.umontreal.ca> a envoyé ce message:
> Rasmus <rasmus@gmx.us> writes:

> I would not think one should modify his Gnus habits or methods merely
> because Org has a tool to search in Gnus.  Org uses Gnus, but Gnus
> should not be disturbed because of that.

Here is my question : if Org uses Gnus, is it possible of making uses of
Org via Gnus? 

I mean  that it would be  great to write  a letter with for  example the
letter  class in  a file  letter.org .  After that  you can  export your
letter.org to a letter.html as well as to letter.pdf via letter.tex, and with Gnus,
thanks to  the link system, you  can send your nice  letter.html to your
colleague with letter.pdf as attachment. 

Is it already  possible to do that with  Org and Gnus, or not?  If it is
not possible at the moment, would it be possible? 

If this dream is  already the reality, your advice to  learn this use of
Gnus and Org will be welcome. 

Best wishes,

Jo. 

Re: gnus: link annoyance

[François Pinard]

Joseph Vidal-Rosset <joseph.vidal.rosset@gmail.com> writes:

> Org uses Gnus, is it possible of making uses of Org via Gnus?  [...]
> Is it already possible to do that with Org and Gnus, or not?  If it is
> not possible at the moment, would it be possible?

Gnus and Org are both open source and very capable systems, both in
themselves and when it comes to extensibility.  The main problem is
acquiring enough familiarity with their internals to find out the
correct, short, compact way of doing about anything one wants. :-)

> I mean that it would be great to write a letter with for example the
> letter class in a file letter.org .  After that you can export your
> letter.org to a letter.html as well as to letter.pdf via letter.tex,
> and with Gnus, thanks to the link system, you can send your nice
> letter.html to your colleague with letter.pdf as attachment.

Many years ago, the message composition has been fairly decoupled from
Gnus and brought back into Emacs for other mailers to use.  So, I guess
you are seeking some machinery between Org and Message, more than
between Org and Gnus.

I'm far from being sure, but if I wanted to use Org as a mean to write
HTML or PDF as message attachments, I would think it could be done with
a very moderate amount of Emacs Lisp customization.  Unless mistaken,
the Org editor to HTML might yield its output in a temporary Emacs
buffer, (for PDF, maybe not) and I would be fairly surprised if message
composition does not have facilities to receive attachments from
buffers.  And even if one would have to go through an external file, the
extra overhead might be negligible in practice.  Putting all the pieces
together might require some work, but maybe not that much.

François

Re: gnus: link annoyance

[Joseph Vidal-Rosset]

[-- Attachment #1: Type: text/plain, Size: 982 bytes --]

2014/1/7 François Pinard <pinard@iro.umontreal.ca>

> I'm far from being sure, but if I wanted to use Org as a mean to write
> HTML or PDF as message attachments, I would think it could be done with
> a very moderate amount of Emacs Lisp customization.  Unless mistaken,
> the Org editor to HTML might yield its output in a temporary Emacs
> buffer, (for PDF, maybe not) and I would be fairly surprised if message
> composition does not have facilities to receive attachments from
> buffers.  And even if one would have to go through an external file, the
> extra overhead might be negligible in practice.  Putting all the pieces
> together might require some work, but maybe not that much.
>

Thanks for the reply. Unfortunately, I am  not at all able to do such a
work, and I very probably will never be able to.
But maybe this suggestion will be interesting for an emacs org-mode
developer, who knows...

Best whishes, et meilleurs voeux pour 2014.

Joseph

[-- Attachment #2: Type: text/html, Size: 1507 bytes --]

Re: gnus: link annoyance

[Nick Dokos]

Joseph Vidal-Rosset <joseph.vidal.rosset@gmail.com> writes:

> 2014/1/7 François Pinard <pinard@iro.umontreal.ca>
>
>     I'm far from being sure, but if I wanted to use Org as a mean to write
>     HTML or PDF as message attachments, I would think it could be done with
>     a very moderate amount of Emacs Lisp customization.  Unless mistaken,
>     the Org editor to HTML might yield its output in a temporary Emacs
>     buffer, (for PDF, maybe not) and I would be fairly surprised if message
>     composition does not have facilities to receive attachments from
>     buffers.  And even if one would have to go through an external file, the
>     extra overhead might be negligible in practice.  Putting all the pieces
>     together might require some work, but maybe not that much.
>
> Thanks for the reply. Unfortunately, I am  not at all able to do such a work, and I very
> probably will never be able to. 
> But maybe this suggestion will be interesting for an emacs org-mode developer, who knows...
>

Not sure how relevant this is (I haven't read this part of the thread
carefully - Some time! Some time! My kingdom for some time!!!)  but it's
at least not entirely unrelated:

    http://orgmode.org/worg/org-contrib/org-mime.html

Nick