Re: Gnus and authinfo
Eric Abrahamsen writes: > Both encrypted and unencrypted versions are supported; maybe the > `auth-sources' option only points at the encrypted version? Or - just guessing - maybe `epg-pinentry-mode' has to be set to 'loopback'? AFAIR the default mode could lead to a behavior as described. Michael.
Re: Does Gnus read and sync the read with IMAP?
Bob Newell writes: > This goes well beyond my very limited knowledge so I did an > experiment. I went to the gmail web interface and found an > already-opened message in the All Mail folder (really a label) > that I knew for certain I had originally opened in gnus, so > therefore gnus would have known about the message. I marked > it unread (on the web) and moved it back to INBOX. > > Then I started up gnus and gnus saw the message as an unread > INBOX message. Based on this it appears the answer is yes, > gnus did update the status of this previously seen email. > However I don't know how much if any status information gnus > actually keeps (and I don't use the registry) so this may or > may not be meaningless. It certainly seems as if, when > reopening the group subsequent to shutting down gnus at some > point, gnus gets a fresh set of information. Thanks for doing this experiment. I hoped for that result. AFAIU Gnus stores such stuff in a file named ".newsrc.eld" (AFAIR ".newsrc.el" in older Emacs versions). And indeed, among other things there seems to be information about "seen" status of messages in that file, as well as saved status, ticked and dormant status, all of that Gnus specific stuff, but nothing related to the "read" (or "old") status. So I guess the "read" status is fetched every time when you open the group, along with the rest (list of existing messages etc). Thx, Michael.
Re: Does Gnus read and sync the read with IMAP?
Bob Newell writes: > The thing is, your /client/ may show them as read but may or may not > have uploaded that "being read" information to the IMAP server. Do > try deliberately closing the client on your phone and see if it helps. > You have to be sure (at least on Android) to actually exit the client > and not just switch to another app. Does Gnus update the "being read" information from the server also for messages it already knows (i.e., has seen in a prior session)? Michael.
Re: Reading the article/message in elisp
Emanuel Berg writes: > We would like an arbitrary header access function where the > header is provided as an argument, as in > > (defun gnus-article-header-value (hdr) > "Get the value of HDR for the current article." > (with-current-buffer gnus-original-article-buffer > (gnus-fetch-field hdr) )) > > only one that works from anywhere, where the article is > fetched from what article is selected (or, lacking that, where > the point is) in the summary buffer. There are quite a few functions defined in gnus-sum named "gnus-summary-article-..." (some are defsubsts, some even macros) that one can use. I don't know whether a general access function as you describe exists. It won't make a programming task much easier, though. Note that I don't know much about this, I only looked a bit at the code in "gnus-sum.el". Michael.
Re: slow saving of scores when leaving a virtual (nnml+) group
Eric S Fraga writes: > I will create a bug report. Thanks Eric. Michael.
Re: slow saving of scores when leaving a virtual (nnml+) group
Eric S Fraga writes: > > Are things significantly faster when setting this to pp-28? > > Very much so! Group exists almost immediately, back to what I used to > see. With pp-28, I'm happy! Problem solved. :-) At least avoided. Ok, good. We should nonetheless create a bug report (M-x report-emacs-bug). Could you please do that? I think we still need somebody to provide the (more or less complete) data that shows the slowdown - with other words, a recipe that doesn't involve setting up Gnus + scoring, to ease the work of the developers. TIA, Michael.
Re: Reading the article/message in elisp
Emanuel Berg writes: > Michael Heerdegen wrote: > > >> The function `mail-header-subject' works but then you don't > >> get to select the header. > > > > What does "you don't get to select the header" mean? > > You only get the Subject header. With this accessor function, yes. And with the others, you get the other struct fields. Not sure what your question is. Michael.
Re: Reading the article/message in elisp
Emanuel Berg writes: > > (gnus-data-header (gnus-data-find (gnus-summary-article-number))) > > > > It will then be the summary buffer article at point, not the > > selected one. If one is selected, it would make more sense > > to operate on that. > > Probably, but how that works I don't know, this > > (gnus-summary-article-number) > > is 20086 in the summary buffer but opening that up and doing > the same thing in that buffer (the article buffer) I get > 20085, but not point nor highlight has moved in the > summary buffer ... ? Looks like this function is useful only when called with the summary buffer current. Michael.
Re: Reading the article/message in elisp
Emanuel Berg writes: > The function `mail-header-subject' works but then you don't > get to select the header. What does "you don't get to select the header" mean? Michael.
Re: Reading the article/message in elisp
Emanuel Berg writes:
> >> However, how will you get the specific header data out of
> >> the result? Don't know ...
> >
> > I think the header object is a struct of type `mail-header'
> > ("nnheader.el").
>
> But try to extract with `mail-header', it complains about the
> data not being a list.
Did you try with the function `mail-header'? I meant the accessor
functions for the struct: `mail-header-subject', `mail-header-from',
etc.
Michael.
Re: Reading the article/message in elisp
Emanuel Berg writes:
> However, how will you get the specific header data out of
> the result? Don't know ...
I think the header object is a struct of type `mail-header'
("nnheader.el").
Michael.
Re: Reading the article/message in elisp
Husain Alshehhi writes: > I suppose that gnus-with-article-buffer works, almost. In the case that > I am in gnus summary page [...] I'm not sure what information is known by Gnus at that moment. In the summary, internally each article is identified with a number. This should be more or less (car (gnus-summary-work-articles 1)). One could try to find information using that article number, e.g. (gnus-summary-article-header (car (gnus-summary-work-articles 1))) will return an object containing the most important header data. Try with M-:. Not sure what else Gnus knows, maybe you will have to fetch the header for that article from the server. Depends on what information you need, and in what situations. But I could also only try to find the relevant functions in the source code (see "gnus-sum.el"). Michael.
Re: slow saving of scores when leaving a virtual (nnml+) group
Eric S Fraga writes: > 832,940,181 99% - command-execute > 805,535,710 96% - funcall-interactively > 540,874,166 64% - gnus-summary-exit > 537,712,423 64%- gnus-score-save > 536,634,533 64% - gnus-pp > [...] > > It could be that I am misinterpreting those profiler results. I think so, yes. These numbers cannot be interpreted directly as used memory. It's more like "time spent inside the function, measured memory-usage wise. > I tried this as well and also get results immediately. Hmm. Ok. We could try with M-x trace-function pp-to-string RET directly before `gnus-summary-exit'. A popup buffer should appear, and it would be helpful if you could again post the output (with any private data obfuscated; we are interested in the argument(s) of the function call(s)). But before that please M-x untrace-all RET. > > Have you tried to change the value of `pp-default-function' btw? > > No, it's set to pp-fill. Are things significantly faster when setting this to pp-28? Thx, Michael.
Re: Reading the article/message in elisp
Robert Pluim writes: > Husain> (defun husain--test-message-subject-yank () > Husain> (interactive) > Husain> (save-excursion > Husain> (let ((subj (message-fetch-field "Subject"))) > Husain> (if subj > Husain> (message subj) > Husain> (gnus-summary-show-article) > Husain> (gnus-summary-select-article-buffer) > Husain> (message (message-fetch-field "Subject")) > > Husain> this still doesn't work as intended because it does not > Husain> restore the window if the point is in a gnus-summary > Husain> buffer pointing to an article not open. > > Husain> Is there a gnus function that can build the message in a > Husain> temp buffer? > > In a temp buffer, no, but you can access the article buffer using eg > `gnus-with-article' or `gnus-with-article-buffer', or even > `gnus-with-article-headers' if you only care about the headers. And you want to call `message' like (message "%s" ...) here, Husain: When the ... can be arbitrary text, `message' will barf when the argument accidentally contains %-sequences, like in (message "D'Oh, didn't expect a %-sequence here") Michael.
Re: slow saving of scores when leaving a virtual (nnml+) group
Eric S Fraga writes:
> I have no idea but I would assume not as I cannot believe that pretty
> printing a file (see below) with 12 lines would take 0.5 GB of data to
> process.
>From what source of information do you have the 0.5 GB?
> > How do the contents of that file look like -can you share some of the
> > contents so that we can maybe find a recipe (you can replace any
> > private information of course)?
>
> (("subject"
> ("^xxx .*" 100 nil r))
> ("from"
> ("\"name\" " 1 nil e)
> [... elided ...]
> ("name " -1000 nil e)))
Thanks. I tried the following: I inserted this expression into a buffer
(*scratch* and a buffer in fundamental mode):
#+begin_src emacs-lisp
(("subject" ("^xxx .*" 100 nil r))
("from" ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("\"name\" " 1 nil e)
("\"name\" " 1 nil e) ("name " -1000 nil e)))
#+end_src
then I replaced all line breaks with spaces and called M-:
(pp-fill (point-min) (point-max)). But that succeeds almost
immediately... Not sure what the important different aspect in your
scenario is.
Have you tried to change the value of `pp-default-function' btw?
Thx,
Michael.
Re: slow saving of scores when leaving a virtual (nnml+) group
Eric S Fraga writes: > On Sunday, 9 Jul 2023 at 07:23, Michael Heerdegen wrote: > > And you did not just turn on `gnus-adaptive-pretty-print' by accident? > > Well, I've had this variable set to t for years now. > > In any case, I have set it to nil and it's made no difference > unfortunately. Which seems strange. Could there be another variable > that affects this as I really don't need the score files prettified? Seems the variable is only respected for adaptive score files. For all others pretty-printing is always used. I guess your score file is not an adaptive one? Michael.
Re: slow saving of scores when leaving a virtual (nnml+) group
Eric S Fraga writes: > > And - is it worth the time to pretty print this data at all? > > This is what I was wondering. The pretty printing could be saved for > when somebody wishes to edit the scores, at which point a little delay > is not intrusive (or as intrusive). Most of the time, I just want the > scores updated quickly so I can go on to the next group. And you did not just turn on `gnus-adaptive-pretty-print' by accident? Michael.
Re: slow saving of scores when leaving a virtual (nnml+) group
Eric Abrahamsen writes: > > Cpu report (partly expanded): > > > >10133 79% - command-execute > > 8519 66% - funcall-interactively > > 4767 37% - gnus-summary-exit > > 4659 36%- gnus-score-save > > 4655 36% - gnus-pp > > 4655 36% - pp > > 4655 36% - pp-to-string > > 4655 36%- pp-fill > > 4647 36% - pp--object > > 4627 36% - pp-fill > > 4615 36% - pp-fill > > 4555 35%- pp-fill > > 4263 33% - pp-fill > > 4243 33% - indent-according-to-mode > > 4243 33% - lisp-indent-line > > 4163 32%- calculate-lisp-indent > > 4163 32% - lisp-indent-function > > 4163 32%lisp--local-defform-body-p > > 48 0%+ lisp-ppss > > A few weeks ago Stefan Monnier made a change to lisp-ppss. Hmm - that report doesn't suggest that this is the culprit. `pp-fill' is also new (this function is used to find good positions for line breaks, which is the most important aspect of Lisp pretty printing). It is the new default behavior of `pp' and maybe slower (in this use case) than the old implementation. Maybe it can also be improved. Anyway, this can be controlled by binding `pp-default-function'. Maybe `gnus-pp' or `gnus-score-save' should bind that variable to a different function? And - is it worth the time to pretty print this data at all? Michael.
Re: Marking thread as read
Eric S Fraga writes: > I've had a chance to try this and you are correct: the documentation > does not match the behaviour. "T k" with no argument marks all articles > as killed which is not the same as read. After reading the Gnus manual a bit I take "killed" as a subset of "read". k for example behaves, and is documented, similarly. Internally `gnus-summary-mark-article-as-read' is used, just marking is done with `gnus-killed-mark' - probably to indicate that you have not handled the articles by hand. Michael.
Re: Multi frame setup: get frame autodeletion?
Björn Bidar writes: > Have you tested if you have the same issue when you just use > `compose-mail` C-x m RET? I think so, but I didn't test...why do you think there should not be an issue - who or what would delete the frame? Michael.
Re: Multi frame setup: get frame autodeletion?
Eric S Fraga writes: > How about making use of message-sent-hook, say? The actual message > composition and sending is not technically handled by gnus but by > message mode instead, IIUC. There seem to be different places where one could start. I got the tip to add a `message-add-action' call to `gnus-message-setup-hook'. Seems a good solution to me. Thanks, Michael.
Multi frame setup: get frame autodeletion?
Hello,
I'm experimenting with multi frame setups for Gnus. I want that
replying or mail composition is done in a fresh separate frame. My
setup below works as expected - but after sending the message the frame
stays and its only window displays a different buffer. I have do delete
the frame manually. Is there a reasonable Gnus-specific way to get rid
of such frames automatically (i.e. after sending)?
This is my current setup:
#+begin_src emacs-lisp
(defvar my-gnus-article-wconf
'(if (> (frame-width) 95)
'(vertical 1.0
(horizontal 1.0
(vertical 28 (tree 1.0))
(article 1.0))
(summary 10 point)
(when (> (frame-height) 50)
'("*BBDB*" 4)))
'(vertical 1.0
(article 1.0)
(summary 8 point
(gnus-add-configuration `(article ,my-gnus-article-wconf))
(dolist (buf '(message post reply forward reply-yank))
(gnus-add-configuration
`(,buf (frame 1.0
,my-gnus-article-wconf
;; would be cool if one could somehow get the frame
auto-deleted once
;; the message had been sent...
(vertical 1.0 (message 1.0 point frame-focus))
#+end_src
TIA,
Michael.
Re: Strip signature on reply without standard separator
Satoshi Yoshida writes: > I understand. As for me, putting ";;; -*- lexical-binding: t -*-" is > difficult. Because the file (.gnus.el or .emacs) isn't new. It consists > of my code and the other parts that already exists. If I (or someone) put > ";;; -*- lexical-binding: t -*-", the other parts will be influenced too. Most of the time this is not a problem at all. All Emacs sources were converted to lexical binding like this. There are not many parts that need special treatmeant - most of the stuff causing trouble hints at problems and errors and style issues you should fix anyway. If you care about your code you should do this conversion sooner or later. Support for dynamical binding doesn't get better, and it has advantages: you get better warnings and more efficient code. Michael.
Re: Strip signature on reply without standard separator
Emanuel Berg writes: > If you quote a lambda it is just a list with data: > > '(a b c) > > '(lambda not an anonymous function) > > Eval and you will see, there's no difference in > principle. Lists. Yes - and you want to make your lambda forms subject to evaluation, for several different reasons. They are not data. You want to use the return value, not the expression. Michael.
Re: Fetching articles by id
Michael Heerdegen writes: > How can I fetch articles with known id to be included in an existing > Summary buffer? `gnus-summary-refer-article' works but also selects an > displays the article. It doesn't seem to be based on something that > doesn't select and display, though. I do it like this for now (modulo copy-paste-errors): (1) Get processed marked articles in search group: #+begin_src emacs-lisp (setq articles (mapcar #'nnselect-article-number gnus-newsgroup-processable)) #+end_src (2) Add those to the summary buffer of the searched group after opening it: #+begin_src emacs-lisp (let (current (or (gnus-summary-article-number) gnus-newsgroup-end)) (mapc (lambda (h) (let ((article-number (mail-header-number h))) (gnus-summary-goto-subject article-number 'force))) (gnus-fetch-headers articles)) ;; Repair thread display (gnus-summary-prepare) (gnus-summary-goto-subject current) (gnus-summary-position-point) (mapc #'gnus-summary-set-process-mark articles)) #+end_src [ I don't eval that by hand every time of course. I use hacked registers to save those process marked ARTICLES in a register, and jump to that register to insert and process mark the ARTICLES later. ] Michael.
Fetching articles by id (was: G g and delete mails with Emacs)
Michael Heerdegen writes: > Seems this is not possible out of the box. I see we have "warping", but > AFAIU it's only implemented for individual articles. How can I fetch articles with known id to be included in an existing Summary buffer? `gnus-summary-refer-article' works but also selects an displays the article. It doesn't seem to be based on something that doesn't select and display, though. TIA, Michael.
Re: G g and delete mails with Emacs
Michael Heerdegen writes: > Hello, > > since threads are not a super reliable way to find all messages related > to a discussion, I decided to try to delete related messages in my > INBOX (consulted via imap) like the following: > > I use G g to create a search group, open it, process mark the messages I > want to archive, and use b to move the messages to my local archive > folder. BTW, it would be cool if one could somehow visit (request plus optionally process mark) search results in the searched group itself. Seems this is not possible out of the box. I see we have "warping", but AFAIU it's only implemented for individual articles. Or can that maybe be achieved in some other way? Michael.
Re: G g and delete mails with Emacs
Eric Abrahamsen writes: > > I use G g to create a search group, open it, process mark the messages I > > want to archive, and use b to move the messages to my local archive > > folder. > > > > But after that procedure, those messages are still available in my INBOX > > (and displayed prefixed with "O"). > > I'm not the one to make this decision, but this sounds like it might be > potentially surprising behavior to users, maybe something that should be > behind a user option similar to `nnselect-allow-ephemeral-expiry'. Somebody here who wants to decide? Or say something about the idea? Thanks, Michael.
G g and delete mails with Emacs
Hello, since threads are not a super reliable way to find all messages related to a discussion, I decided to try to delete related messages in my INBOX (consulted via imap) like the following: I use G g to create a search group, open it, process mark the messages I want to archive, and use b to move the messages to my local archive folder. But after that procedure, those messages are still available in my INBOX (and displayed prefixed with "O"). Is there a way to vary this procedure so that those messages on the imap server are deleted? TIA, Michael.
Re: question about org-link gnus message and gnus registry
Eric Abrahamsen writes: > Crap, it's in a commit I've had locally since... late 2020, but never > released. Then now it's one of the best tested commits ever ;-) I have a lot of these myself... Michael.
Re: question about org-link gnus message and gnus registry
Eric Abrahamsen writes: > I'm still just seeing a call to `cl-second', which is required at > compile time. And my, there are a lot of compiler warnings! But nothing > about second or cl-second... This is where I found it: #+begin_src emacs-lisp (defun gnorb-reply-to-gnus-link (link) "Start a reply to the linked message." (let* ((link (org-link-unescape link)) (group (car (org-split-string link "#"))) (id (gnorb-bracket-message-id (second (org-split-string link "#" (backend (car (gnus-find-method-for-group group (gnorb-follow-gnus-link group id) (call-interactively (if (eq backend 'nntp) 'gnus-summary-followup-with-original 'gnus-summary-wide-reply-with-original #+end_src Michael.
Re: question about org-link gnus message and gnus registry
Michael Heerdegen writes: > And indeed - look at `gnorb-reply-to-gnus-link'. OTOH you can also simply look at the compiler warnings... Michael.
Re: question about org-link gnus message and gnus registry
Eric Abrahamsen writes: > I honestly don't know what's going on here. There's no call to > `second' in `gnorb-org-setup-message', not even a call to > `cl-second'. Are you comfortable with stepping through functions using > edebug? Wait - the backtrace looks like it's an re-thrown error from the condition-case near the beginning. And indeed - look at `gnorb-reply-to-gnus-link'. Michael.
Re: Fat finger produces #
Colin Baxter writes: > Thanks for this. Meta+hash worked for me. Instead of panicking I > should just did "C-h c #" to find the command "gnus-topic-mark-topic"! This is called the "process mark" and is just like marking files to operate on in dired: marking articles to operate on. Marking per se is harmless and temporary. What can be done using the process mark can be discovered in the menu. Michael.
Re: Highlight process-marked files in Gnus summary?
Roland Winkler writes: > Hopefully, it will be not too difficult to teach Gnus to limit the > Summary buffer based on the process-mark. Should be as easy as #+begin_src emacs-lisp (defun my-gnus-limit-to-process-marked () (interactive) (gnus-summary-limit gnus-newsgroup-processable)) #+end_src i think. / w for `gnus-summary-pop-limit'. AFAIU limiting is stack based: each limiting pushes to the stack, and / w pops the most upper limit and thus reverses one limiting operation. Michael.
Re: Highlight process-marked files in Gnus summary?
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). You might also want to test something like #+begin_src emacs-lisp (defun my-gnus-limit-to-current-thread () (interactive) (let ((a (gnus-summary-article-number))) (gnus-summary-limit (gnus-summary-articles-in-thread (let ((a a)) (dotimes (_ (gnus-summary-thread-level)) (cl-callf gnus-summary-article-parent a)) a))) (gnus-summary-goto-subject a))) #+end_src Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: gnus-registry-marks; Any chance to search or filter for?
physiculus writes: > So i understand it correct, that is not clear, if it will be work in > the near future ? I suggest to make a bug report, please. It will definitely be cared about, in some months or so at least. Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: gnus-registry-marks; Any chance to search or filter for?
physiculus writes: > i want to search or filter with the registry-marks i set. Is this > possible? I couldn't find a function for that in the gnus documentation. I think you have to do it by hand. Something like this should give you the registry-marked messages in the current group: #+begin_src emacs-lisp (delq nil (mapcar (lambda (id) (cdr (gnus-request-head id gnus-newsgroup-name))) (cl-loop for key being the hash-keys of (oref gnus-registry-db data) using (hash-values v) when (cdr (assoc 'mark v)) collect key))) #+end_src I'm using something like this in an :around advice of `gnus-alter-articles-to-read-function' to automatically include all registry marked messages in group summaries (similarly to ticked). Michael. ___ 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?
Lars Ingebrigtsen writes: > > 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 had a quick look. You currently have to refer to a set of predefined variables in entries in `gnus-summary-highlight': score:The article's score. default: The default article score. default-high: The default score for high scored articles. default-low: The default score for low scored articles. mark: The article's mark. uncached: Non-nil if the article is uncached. though, actually, any expression is allowed I think. It would be easier if one could refer to the article number via `article'. So currently, I would have to do something like this: (add-to-list 'gnus-summary-highlight '((memq (or (gnus-summary-article-number) gnus-current-article) gnus-newsgroup-processable) . hl-line)) I would suggest to at least do the following: (1) Provide an `article' variable. Maybe also provide `processable' as suggested and/or `sec-mark' (somewhere in the code the process mark is called a "secondary mark")? (2) make the docstring of `gnus-summary-highlight' say that arbitrary expressions are allowed, and that they are evaluated with point positioned on the according article's line. For (1), AFAIU two places would need to be changed: `gnus-summary-highlight-line' and `gnus-tree-highlight-node'. Seems to be simple to do. Thanks, Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Highlight process-marked files in Gnus summary?
Hi, seems there is no built-in way to highlight (complete lines) of process-marked files in the Gnus summary, since # is not a normal mark and can't be specified in `gnus-summary-highlight'? Is there some other way (in Gnus)? 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'. Thanks in advance, Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Finding last messages in a thread
Andrew Cohen writes: > don't have time to fix it all up, blah, blah, can someone push this for > me please:): Sure. > @@ -8698,7 +8556,8 @@ gnus-summary-limit-include-thread > When called interactively, ID is the Message-ID of the current > article. If thread-only is non-nil limit the summary buffer to > these articles." > - (interactive (list (mail-header-id (gnus-summary-article-header > + (interactive (list (mail-header-id (gnus-summary-article-header)) > +current-prefix-arg)) >(let ((articles (gnus-articles-in-thread >(gnus-id-to-thread (gnus-root-id id > ;;we REALLY want the whole thread---this prevents cut-threads But I have some questions first (somewhat interdependent): (1) I wasn't able to discover this. Should there be a menu entry for this function? (2) It currently has the binding / T. But it doesn't seem to be a pure limit command, since it also shows additional articles. Do we want it like this? (3) Will people call this more often with prefix arg? If yes, should we toggle the meaning of the prefix, or split the command into two separate commands? I'm not a Gnus guru, so I don't have a strong opinion myself, but I wondered. Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Finding last messages in a thread
Andrew Cohen writes: > And...its broken (I think). Since I use "A T" I never tried "/ T". With > a prefix arg its supposed to limit the summary buffer to the articles in > the thread, but it doesn't. I believe the (interactive) expression is > wrong, so that the prefix arg is thrown away. Yes, looks like that. I wonder who has done that. Let's see: 03f6388892 Allow limiting gnus summary buffers to a thread committed by a certain "Andrew G Cohen". Hmm, never heard that name. Should we contact him? Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Finding last messages in a thread
Achilles Yuce writes: > What i usually do to get a single thread sorted with articles is; > > /n /T C-c C-s C-d ^ Is this A T? But then it works well, yes, thanks for sharing! Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Finding last messages in a thread
Eric Abrahamsen writes: > Elsewhere the gnus code does this with `gnus-root-id', but I have no > idea if that is any faster or more convenient than your version (I would > be curious to know). I wonder if you could use the > `gnus-newsgroup-dependencies' hashtable. Maybe, I didn't invest too much time. But - I didn't miss any already existing method to reach my goal (finding the chronologically last messages in a thread)? Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Finding last messages in a thread
Hello, is there a quick way to sort the messages in a thread chronologically? My goal is to find the latest articles in a thread. I guessed the quickest way could be to limit to the current thread (???), and then turn off threading (C-M-t), but the first functionality doesn't seem to exist, so I implemented it quicky: #+begin_src emacs-lisp (defun my-gnus-limit-to-current-thread () (interactive) (let ((a (gnus-summary-article-number))) (gnus-summary-limit (gnus-summary-articles-in-thread (let ((a a)) (dotimes (_ (gnus-summary-thread-level)) (cl-callf gnus-summary-article-parent a)) a))) (gnus-summary-goto-subject a))) #+end_src Do I miss something? TIA, Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Modify gnus alist in .gnus. Hook?
Brady Trainor algeb...@uw.edu writes: (add-hook 'gnus-started-hook `(add-to-list 'gnus-group-line-format-alist `(?z (gnus-short-group-name gnus-tmp-qualified-group) ?s)) ) That's wrong. Hook elements must be functions (no matter whether named or anonymous) - but you added an expression that evaluates to a list. See (info (elisp) Hooks). Some more hints (although not crucial): use normal quoting when you don't need backquote's unquoting (`,'). And there is already an entry for ?z in the association list, you try to add a second entry for it. I would do it like this: --8---cut here---start-8--- (add-hook 'gnus-started-hook (lambda () (assq-delete-all ?z gnus-group-line-format-alist) (push '(?z (gnus-short-group-name gnus-tmp-qualified-group) ?s) gnus-group-line-format-alist))) (setq gnus-group-line-format %M%S%p%P%5y:%B%(%z%)\n) --8---cut here---end---8--- In Emacs 25, there will be a setf'able `alist-get' function that will make modifying alists a bit more comfortable. Don't care about that info if you don't know what setf is. HTH, Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Threads sorting doesn't work?
Andrey Lisin andrey.li...@gmail.com writes: (setq gnus-thread-sort-functions '(gnus-thread-sort-by-subject (not gnus-thread-sort-by-total-score) gnus-thread-sort-by-most-recent-date)) According to Gnus documentation threads should be sorted by the most recent date firstly. But what I see in summary buffer is the oldest threads go on top and the most recent go down. Am I doing something wrong? For me it seems to work as expected. How do you evaluate your code? Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: .newsrc-dribble autosave
Katsumi Yamaoka yama...@jpl.org writes: Currently the change below has been installed in the Emacs trunk only. I'll install it in the Gnus Git master too when the server ups (it seems down now). Ok, thanks. Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: .newsrc-dribble autosave
Alan Smaill sma...@spaminf.ed.ac.uk writes: I don't know if this behavior is intended, but it doesn't seem very useful to me. Presumably the idea is that if you have inadvertently deleted a big chunk of the buffer, you should be warned before any previous backup gets overwritten. That's the idea behind this feature of autosave mode, and it is useful in general. The question is whether it is useful for the gnus dribble file, which the user typically doesn't edit directly. And when gnus exits, the autosave file is gone. That makes it not much useful as a tool to undo changes. autosave is mainly intended to recover stuff after a crash. And I wonder if it makes sense to disable autosave in certain situations for an automatically maintained and only internally used file. Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: .newsrc-dribble autosave
akb427 goo...@mirror.to writes: In gnus, I am now sometimes getting the message Buffer .newsrc-dribble has shrunk a lot; auto save disabled in that buffer until next real save I don't know if this behavior is intended, but it doesn't seem very useful to me. The variable `auto-save-include-big-deletions` controls whether auto-save-mode is turned off when the buffer has shrunk a lot - the default is nil (meaning: turn off). Gnus would have to set the buffer local value of this var to non-nil to fix this. Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Using things from 'custom.el'
Sharon Kimble boudic...@talktalk.net writes: I have this line in my 'custom.el' - '(gnus-fetch-old-headers 300) but how do I call it from within gnus please. For variables, in 99% of the cases, setq-default is the right thing to use - in your case, for example, just (setq-default gnus-fetch-old-headers 300) In very rare cases, custom uses a specialized setter function and using just setq-default won't work. BTW, `setq-default' is like `setq', but always sets the default (i.e. the global) binding of a variable even when it is buffer local. Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
arrayp display group parameter ignored when selecting group
Hi, I regularly read a large Gmane newsgroup. I've a lot of ticked articles that I marked for later reading in some days when I have some time left. When I select the newsgroup on a normal (busy) day, I only want to see unseen news, not those marked for later reading. I don't want to be prompted for a number of articles to show, I just want to see the unseen articles, even when there are only two. According to the manual (info (gnus) Group Parameters) this should be easily possible by using an array as display group parameter, [unseen] in my case. But this setting is just ignored. Instead, my setting of (setq gnus-parameter-large-newsgroup-initial-alist '((.* . 50))) is used and I'm queried how much articles I want to read, default 50. I stepped through the code and saw that my 'display group parameter setting is being used, I see that `gnus-newsgroup-display' is bound to a lambda respecting my setting. But `gnus-articles-to-read' does only treat gnus-newsgroup-display values that are numbers, everything else is just ignored. Is this a missing functionality, or did I misinterpret the manual? I use gnus that comes with Emacs, and my Emacs is a recent built of trunk. Please CC me in your answers. Thanks, Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: gnus-group-line-format: number of articles to look at
Hi Emanuel, I want to include the number of to be read articles in `gnus-group-line-format'. But %N is not nearly what I want. It seems to include all old articles that I didn't open - at least, it gives very large integers that can't reflect what I mean. I found this - I think it is all you can do (it is *a lot*) using the builtin format codes: http://www.gnu.org/software/emacs/manual/html_node/gnus/Group-Line-Specification.html Those you mention are described as: ‘N’ Number of unread articles and ‘U’ Number of unseen articles There is so much stuff that could be put in that string, it makes me sea sick! Are you *sure* what you seek isn't mentioned? At least, all I tried didn't work. But you made me think again, and ... I began to wonder why all relevant numbers started with digit 5. I had used 5%y instead of %5y all the time - oh my god! Feeling a bit stupid now - anyway, thanks for your help! Regards, Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Changes in emacs.el
Cecil Westerhof ce...@decebal.nl writes: I now added: (setq custom-file ~/.emacs.d/.emacs-custom.el) (load custom-file t nil t t) There is only one problem: ;; Your init file should contain only one such instance. Now there will be two. I will see if this is going to give problems. If you have a separate custom file, your init file can contain as much `custom-set-variables' or `custom-set-faces' as you want, AFAIK. The limitation only exists so that Emacs can automatically edit it and can be sure it doesn't miss anything. If you have a separate custom file, you can do what you want in your init file, because it's then not subject to automatic editing. Of course, it would be better style to avoid `custom-set-variables' in your init file and use standard Elisp instead (I mean `setq', `setq-default' etc.). Also: why does Emacs do this? I never do anything with custom. I know that some code in vanilla Emacs or third party packages use the customization file for storing settings. You need not use the customization interface for this to happen. It is arguable if this is always necessary, but I can live with it. In your case, this was the apparently the cause: Gnus supports Cancel Locks in News. This means a header `Cancel-Lock' is inserted in news posting. It is used to determine if you wrote an article or not (for canceling and superseding). Gnus generates a random password string the first time you post a message, and saves it in your `~/.emacs' using the Custom system. While the variable is called `canlock-password', it is not security sensitive data. Publishing your canlock string on the web will not allow anyone to be able to anything she could not already do. The behavior can be changed by customizing `message-insert-canlock'. Regards, Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: Changes in emacs.el
Cecil Westerhof ce...@decebal.nl writes: Sometimes I get a message that .emacs is read-only. This is true, because it is a link to an emacs.el file that is owned by root and read-only for the user. I get the question: do you want to write? If I say yes, it fails and my message/article is not send. If I say no it is also not send. I could live with it, because when I try to send it again, it succeeds. But annoying it is. When looking more closely I found that two things are changed. I have a custom-set-variables section and beside changing the sequence it adds (beside other things): ;; custom-set-variables was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(canlock-password …) '(delete-selection-mode nil) '(mark-even-if-inactive t) It also adds: (custom-set-faces ;; custom-set-faces was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. ) I do not have a custom-set-faces in the emacs.el. Why does emacs tries to change .emacs and can I circumvebt this? I think you must only set `custom-file'. From the doc: | File used for storing customization information. | The default is nil, which means to use your init file | as specified by `user-init-file'. If the value is not nil, | it should be an absolute file name. Regards, Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: nnweb+google
Hi William, I'm seeing this too. I think it's just broken. There was a discussion about this in gmane.emacs.gnus.general in March, but obviously nobody from the developers did fix it yet. It seems to be nontrivial to keep this feature working. Perhaps it would be easier to point this at some more stable search engine API, maybe DuckDuckGo or something. I'll see if I can understand nnweb well enough to send the developers a patch [...] Sounds like a good idea. I volunteer to test your code if you get around to develop something. Regards, Michael. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: gnus and parse-time.el
Important addition: Names starting with a capital letter are not ok - they don't work when entering dates in the minibuffer (e.g. for C-c .) with org. Something like this works perfectly: (eval-after-load parse-time '(progn (dolist (entry '((jan . 1) (feb . 2) (mär . 3) (apr . 4) (mai . 5) (jun . 6) (jul . 7) (aug . 8) (sep . 9) (okt . 10) (nov . 11) (dez . 12) (januar . 1) (februar . 2) (märz . 3) (april . 4) (juni . 6) (juli . 7) (august . 8) (september . 9) (oktober . 10) (november . 11) (dezember . 12))) (add-to-list 'parse-time-months entry)) (dolist (entry '((so . 0) (mo . 1) (di . 2) (mi . 3) (do . 4) (fr . 5) (sa . 6) (sonntag . 0) (montag . 1) (dienstag . 2) (mittwoch . 3) (donnerstag . 4) (freitag . 5) (sonnabend . 6) (samstag . 6))) (add-to-list 'parse-time-weekdays entry even if you enter a weekday starting with a capital letter. ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: gnus and parse-time.el
r.th...@uni-jena.de (Prof. Dr. Rainer Thiel) writes: I am configuring the variables parse-time-months and parse-time-weekdays (to use German names to insert dates in org-mode). Since I upgraded to Emacs 24 (GNU Emacs 24.0.93.1), this results in an error when starting up gnus. The error message runs: What values of `parse-time-months' and `parse-time-weekdays' do you use? Michael ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
Re: gnus and parse-time.el
Rainer Thiel r.th...@uni-jena.de writes: Am 18. März 2012 21:18 schrieb Michael Heerdegen michael_heerde...@web.de: What values of `parse-time-months' and `parse-time-weekdays' do you use? This is the configuration I am using: (defvar parse-time-months '((jan . 1) (feb . 2) (mär . 3) (apr . 4) (mai . 5) (jun . 6) (jul . 7) (aug . 8) (sep . 9) (okt . 10) (nov . 11) (dez . 12) (Januar . 1) (Februar . 2) (März . 3) (April . 4) (Juni . 6) (Juli . 7) (August . 8) (September . 9) (Oktober . 10) (November . 11) (Dezember . 12))) (defvar parse-time-weekdays '((so . 0) (mo . 1) (di . 2) (mi . 3) (do . 4) (fr . 5) (sa . 6) (Sonntag . 0) (Montag . 1) (Dienstag . 2) (Mittwoch . 3) (Donnerstag . 4) (Freitag . 5) (Sonnabend . 6))) I think it is a bad idea to overwrite the default values. parse-time.el seems to be a widely used library, it's not part of org-mode. With your settings, gnus can't parse dates in message headers which are in the English format. Can you please replace your setting with that and try if it works for you? (eval-after-load parse-time '(progn (dolist (entry '((jan . 1) (feb . 2) (mär . 3) (apr . 4) (mai . 5) (jun . 6) (jul . 7) (aug . 8) (sep . 9) (okt . 10) (nov . 11) (dez . 12) (Januar . 1) (Februar . 2) (März . 3) (April . 4) (Juni . 6) (Juli . 7) (August . 8) (September . 9) (Oktober . 10) (November . 11) (Dezember . 12))) (add-to-list 'parse-time-months entry)) (dolist (entry '((so . 0) (mo . 1) (di . 2) (mi . 3) (do . 4) (fr . 5) (sa . 6) (Sonntag . 0) (Montag . 1) (Dienstag . 2) (Mittwoch . 3) (Donnerstag . 4) (Freitag . 5) (Sonnabend . 6))) (add-to-list 'parse-time-weekdays entry It adds your entries to the variable values instead of overwriting them. Michael ___ info-gnus-english mailing list info-gnus-english@gnu.org https://lists.gnu.org/mailman/listinfo/info-gnus-english
