Re: Retrieve thread URL from Gnus
On Wed, Mar 23 2022, Adam Sjøgren wrote: > The equivalent is: > > a) Open the news.gmane.io server: in the Group buffer press B RET (for > nntp) and enter news.gmane.io > b) Find the group gmane.lisp.clisp.devel and enter it (press RET with > point on the line) > c) Jump to article number: press j and enter the article number > > If you want to see the entire thread, you can press A T to have the > other articles in the thread inserted into the *Summary* buffer. > > If you find it convenient to read news (i.e. mailing lists) via gmane, > you can set it up as a permanent server in your Gnus configuration > (gnus-secondary-methods) and subscribe to the groups you like to read. Thanks, yes, I just realized that yesterday I fooled myself. I am already reading news via gnus, but yesterday I messed up from which group I was looking for an old article. Then I got confused that gnus article numbers did not match what I was expecting to get and what I did get as expected in the telnet session. Entirely my fault! But you are right: sometimes it is fun to go back to the basics and live like a caveman!
Re: Retrieve thread URL from Gnus
On Tue, Mar 22 2022, Adam Sjøgren wrote: > You're welcome. With Gnus you can skip all the telnetting-like-a-caveman > stuff, of course :-) I am fairly new to Gnus and your caveman-like approach came very handy when yesterday I needed to look at an old message for which I only knew the article number on the gmane server (the line "article 20429" in your example telnet session). What is the equivalent command in Gnus? Thanks!
Re: gnus-posting-styles with different addresses
On Fri, Feb 25 2022, Greg Farough wrote:
> I take this approach:
>
> (setq gf/gnus-avoid-address-list
> '("f...@foo.net" "gr...@gnu.org"))
> (setq message-dont-reply-to-names (regexp-opt
> gf/gnus-avoid-address-list))
Thanks!
gnus-posting-styles with different addresses
I may be missing something: I am using gnus-posting-styles with different addresses. Then it happens often (I have not yet figured out the details) that a wide reply also puts my address (same as in the From field) into the Cc header. Is this intentional? Can I suppress my address in the Cc header? How? Thanks, Roland
Re: mail splitting with mime-encoded headers
On Mon, Jan 17 2022, Adam Sjøgren wrote: > Roland writes: >> What is the recommended way for dealing with mime-encoded headers when >> splitting mail? > > I use this: > > ; Decode headers before splitting on them: > (setq nnmail-mail-splitting-decodes t) Thanks, that was exactly what I was looking for.
mail splitting with mime-encoded headers
What is the recommended way for dealing with mime-encoded headers when splitting mail? If I understand things correctly, Gnus looks at the raw mails when splitting mail. So it may see mime-encoded headers (from:, to:, subject:, etc.) which makes things like regexp-matching a less straightfoward exercise. I may be missing something. (Of course, it gets more expensive to split a large number of mail messages if first lots of mime-encoded headers need to be decoded. I guess that's the price one needs to pay for using mime encoding.) Thanks, Roland
Re: synchronizing gnus sessions on multiple computers
On Sun, Sep 12 2021, James Thomas wrote: >> - How can I tell gnus (in a running emacs session) that I've rsync'ed >> all local user directories and gnus should update itself accordingly >> when, for example, articles are marked as read or expired. > > Perhaps you can look into the Gnus Cloud code. I haven't ever used that > feature myself, though. Thanks, it took me a while to get back to this. It seems that Gnus Cloud is a very different thing using an IMAP server to synchronize marks and general files and data across multiple machines. I want my mail local, but synchronized among different machines.
Re: synchronizing gnus sessions on multiple computers
On Fri, Sep 10 2021, Eric Abrahamsen wrote:
> Yes, the .newsrc.eld file only gets written when you save Gnus ("s" in
> the *Group* buffer), and I would absolutely not try to update files for
> a Gnus that's still running, it will not handle that gracefully. It
> should, however, be enough to shut Gnus down first (you can see the
> `gnus-clear-system' function to see what happens then), rsync, then
> restart Gnus.
Thanks, it took me a while to get back to this. It seems that
`gnus-clear-system' / quitting gnus is missing
`gnus-save-newsrc-file-last-timestamp'. Quitting gnus, then rsync'ing
gnus followed by a restart of gnus will use .newsrc.eld file from the
other machine. But when this .newsrc.eld file is saved again, the
timestamp of the file on disk is compared against the old timestamp of
the old file that's already gone.
I submitted a bug report (bug#51052).
Re: synchronizing gnus sessions on multiple computers
On Fri, Sep 10 2021, Eric Abrahamsen wrote:
> "Roland Winkler" writes:
>> -- I realized that testing all this does not require two different
>> machines. But two instances of emacs running on one computer
>> effectively give the same situation to play with. It seems that a
>> running gnus session does not warn the user that another emacs instance
>> has fiddled with files such as .newsrc.eld. Is this true?
>
> Yes, the .newsrc.eld file only gets written when you save Gnus ("s" in
> the *Group* buffer), and I would absolutely not try to update files for
> a Gnus that's still running, it will not handle that gracefully. It
> should, however, be enough to shut Gnus down first (you can see the
> `gnus-clear-system' function to see what happens then), rsync, then
> restart Gnus.
...It seems that the command gnus-group-exit (bound to q in the group
buffer) is really doing the complete job. This command also calls
gnus-clear-system, besides other things.
The gnus info pages note repeatedly
Gnus gives you all the opportunity you could possibly want for
shooting yourself in the foot.
So I'll have to set up things such that a careless rsync cannot do too
much damage. I guess when switching from machine A to machine B it is
always machine A (i.e., the source for rsync) where I should run
gnus-group-exit which will also flush everything to disk that needs to
be rsync'ed to machine B. When rsync has done its job (A -> B), I can
start working on B. Then, when I am done working on B, I can run
gnus-group-exit on B, rsync B -> A, and continue working on A...
Sounds like a plan.
Re: synchronizing gnus sessions on multiple computers
On Fri, Sep 10 2021, Bob Newell wrote: > I have rsync'd gnus for years with success. In addition to the files > already listed I sync .newsrc.eld, but that is updated infrequently. > Not strictly gnus entries, but related closely enough, I also sync > .authinfo and .msmtprc (as I use msmtp) and also .bbdb. Thanks to everyone who replied to this thread. When you are rsyncing gnus, are you doing this while emacs is running on the different machines? Or are you starting a fresh emacs session after all the files got updated on a machine? Digging through things I realized that .newsrc.eld seems to store article marks. For example it sets gnus-newsrc-alist that holds an assoc list of read articles. However, in a running emacs session the same information is stored also in gnus-newsrc-hashtb. So the question becomes: What steps are needed to fully restart gnus while emacs is running so that internal variables such as gnus-newsrc-hashtb get re-initialized, too. -- I realized that testing all this does not require two different machines. But two instances of emacs running on one computer effectively give the same situation to play with. It seems that a running gnus session does not warn the user that another emacs instance has fiddled with files such as .newsrc.eld. Is this true?
synchronizing gnus sessions on multiple computers
In my work, I am alternating between two computers where the user directories are complete mirror images (updated via rsync whenever I need to switch from one to the other computer). Somehow I am having difficulties to get this to work with gnus: - How can I tell gnus (in a running emacs session) that I've rsync'ed all local user directories and gnus should update itself accordingly when, for example, articles are marked as read or expired. - Where does gnus store the information that I have read or marked for expiration some news or mail articles in a group? (Somehow, right now when switching to the other computer, gnus appears to be becoming aware of new articles that arrived on the other computer and were subsequently rsync'ed to the local machine; only the marks regarding the status of these articles are lost when switching to the other computer, as if these marks were stored in a file that is ignored by rsync.) I hope that such a work flow is not running into fundamental difficulties. Roland
Re: Highlight process-marked files in Gnus summary?
On Mon, Jul 26 2021, Michael Heerdegen wrote: > Roland Winkler writes: > >> I found this old thread. Could it make sense to have a minor mode >> that puts the `invisible' text property on all lines without >> process-mark? > > I played with limiting since then (a concept that is a bit more advanced > than making lines invisible and already exists). > > AFAIK there is no command that lets you limit to process marked > articles, but it should be trivial to write using `gnus-summary-limit' > (limits to a given article list). Yes, thank you, limiting goes very much in the direction I want. -- I like the two-step process of first marking the messages I want, and only afterwards limiting the summary buffer because I can check whether I have identified all messages I wanted to identify before the unmarked messages become invisible. Hopefully, it will be not too difficult to teach Gnus to limit the Summary buffer based on the process-mark. > You might also want to test something like > > #+begin_src emacs-lisp > (defun my-gnus-limit-to-current-thread () Thanks! - If gnus can identify a thread correctly, the problem is pretty much solved anyway. I am concerned about the annoying cases where the discussion of a topic spreads out into multiple threads because someone continued the discussion with a new message using a different subject header and ignoring the references headers used previously. Typically, this takes me multiple iterations of hand-crafted search criteria to identify all messages that have contributed to the discussion of a topic. It just came to my mind: does Gnus allow one to add a custom header like a "topic ID" that could help me two months later when I need to revisit the discussion of a topic that was distributed over multiple apparently unrelated threads? There are all kinds of Gnus commands for article washing and manipulating article headers. Yet I have not identified anything that could be (mis-) used for such a purpose. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: fcc with nnml mail spool
On Sun, Jul 25 2021, Adam Sjøgren via info-gnus-english wrote: > Adam Sjøgren writes: > >> (I guess you could just set your archive method to be your regular >> nnml-method - I'm not sure why I split them back in ancient times.) > > I know why now - I followed the example in the manual almost to the > letter, only changing nnfolder to nnml: > > · https://www.gnus.org/manual/gnus_75.html#Archived-Messages Thank you, that's very useful! I am new to the world of Gnus, which also means that I need to learn where to look for what I want! ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
fcc with nnml mail spool
The following message is a courtesy copy of an article that has been posted to gmane.emacs.gnus.user as well. If mail is stored in mbox format, an fcc header allows to keep a local copy of an outgoing mail message, where (by default) the copy of the mail message is appended to an mbox file like any external messages. This way, everything in a thread is naturally kept together for later reference, the external mail messages plus my replies. How can one achieve the same thing with the nnml mail spool? Of course, there is the bcc header. But can one also generate local copies of outgoing mail messages that go straight into one of the nnml mail groups? I guess the syntax of the old-fashioned fcc header is not the most helpful for this. Instead of an mbox file it would be useful to specify the Gnus group the copy of the outgoing mail message should go into. Such a syntax could even work with any other Gnus mail back end. Or am I missing something? I also found the variable message-fcc-handler-function. But I am not sure how it can possibly help in the above context. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Highlight process-marked files in Gnus summary?
On Tue, May 19 2020, Lars Ingebrigtsen wrote: > Eric Abrahamsen writes: > >>> The obvious goal is to get a better overview of what is marked before I >>> e.g. delete the articles. It's too easy to make a mistake with only >>> those little # marks around. Ideally the used face would specify a >>> background color (like hl-line) so it doesn't interfere with the stuff >>> in `gnus-summary-highlight'. >> >> I haven't ever looked at the summary-highlight code, but would it be >> hard to add another entry in there, call it `process', to specifically >> target the process mark? > > I don't think that's necessary? Can't you just add highlighting based > on pretty much anything in the highlighting code? (It's been a while > since I looked at it...) I found this old thread. Could it make sense to have a minor mode that puts the `invisible' text property on all lines without process-mark? I have in mind a use case different from Michael who started this thread: Often I deal with threads that evolve (magically) such that they become recognized as multiple threads. In such a case the process-mark can help to "collect" all threads on a topic. Or are there better solutions for this? ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
