Re: [O] gnus: link annoyance
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: [O] gnus: link annoyance
Achim Gratz 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: [O] gnus: link annoyance
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: [O] gnus: link annoyance
Joseph Vidal-Rosset writes: > 2014/1/7 François Pinard > > 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
Re: [O] gnus: link annoyance
2014/1/7 François Pinard > 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
Re: [O] gnus: link annoyance
Nick Dokos 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: [O] gnus: link annoyance
Joseph Vidal-Rosset 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: [O] gnus: link annoyance
Rasmus 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: [O] gnus: link annoyance
Bastien 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: [O] gnus: link annoyance
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 a envoyé ce message: > Rasmus 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: [O] gnus: link annoyance
Hi François,
François Pinard 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: [O] gnus: link annoyance
François Pinard writes: > Nick Dokos writes: > >> François Pinard 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 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: [O] gnus: link annoyance
Hi François, François Pinard 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! 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" -- Bastien
Re: [O] gnus: link annoyance
Rasmus 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: [O] gnus: link annoyance
Nick Dokos writes: > François Pinard 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 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: [O] gnus: link annoyance
Hi François, Thanks for working on org-grep. It looks interesting. Excuse me if I misunderstood something below. François Pinard 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: [O] gnus: link annoyance
François Pinard 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 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
[O] gnus: link annoyance
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.
