* Marking new unread articles differently? @ 1998-08-15 19:37 Matt Simmons 1998-08-15 20:43 ` Lars Magne Ingebrigtsen ` (2 more replies) 0 siblings, 3 replies; 115+ messages in thread From: Matt Simmons @ 1998-08-15 19:37 UTC (permalink / raw) I can't be the only one who has obscene numbers of unread messages rotting away in my mailbox. This causes me to lose new messages, especially when the appear as part of a thread headed by previously unread messages. Is there any way to have the messages that have appeared since the last time the spool was inc'd displayed in a different face in the Summary Buffer? This would make it easier to differentiate between old and new unread messages. Thanks Matt -- Matt Simmons - simmonmt@acm.org - http://www.netcom.com/~simmonmt Everyone has a photographic memory. Some just don't have film. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Marking new unread articles differently? 1998-08-15 19:37 Marking new unread articles differently? Matt Simmons @ 1998-08-15 20:43 ` Lars Magne Ingebrigtsen 1998-08-15 21:03 ` SL Baur ` (2 more replies) 1998-08-15 21:20 ` Eze Ogwuma 1998-08-16 6:05 ` Mike McEwan 2 siblings, 3 replies; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-08-15 20:43 UTC (permalink / raw) Matt Simmons <simmonmt@acm.org> writes: > I can't be the only one who has obscene numbers of unread messages > rotting away in my mailbox. This causes me to lose new messages, > especially when the appear as part of a thread headed by previously > unread messages. Well -- don't you want to read messages earlier in the thread before messages later in the thread? > Is there any way to have the messages that have appeared since the > last time the spool was inc'd displayed in a different face in the > Summary Buffer? This would make it easier to differentiate between > old and new unread messages. I think it sounds like you really want an unthreaded mail group summary display. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Marking new unread articles differently? 1998-08-15 20:43 ` Lars Magne Ingebrigtsen @ 1998-08-15 21:03 ` SL Baur 1998-08-15 22:40 ` Lars Magne Ingebrigtsen 1998-08-15 21:14 ` Harry Putnam 1998-08-25 6:23 ` Matt Simmons 2 siblings, 1 reply; 115+ messages in thread From: SL Baur @ 1998-08-15 21:03 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes in ding@gnus.org: > Matt Simmons <simmonmt@acm.org> writes: ... >> Is there any way to have the messages that have appeared since the >> last time the spool was inc'd displayed in a different face in the >> Summary Buffer? This would make it easier to differentiate between >> old and new unread messages. > I think it sounds like you really want an unthreaded mail group > summary display. Can this be done with proper fiddling to `gnus-summary-highlight'? Is it possible to have group-specific `gnus-summary-highlight' specs? ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Marking new unread articles differently? 1998-08-15 21:03 ` SL Baur @ 1998-08-15 22:40 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-08-15 22:40 UTC (permalink / raw) SL Baur <steve@xemacs.org> writes: > Can this be done with proper fiddling to `gnus-summary-highlight'? Well, now that I think of it, `nnmail-split-history' has a record of newly arrived articles, which could be used. > Is it possible to have group-specific `gnus-summary-highlight' specs? Sure; no problem. Can be set in group params or gnus-summary-mode-hook. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Marking new unread articles differently? 1998-08-15 20:43 ` Lars Magne Ingebrigtsen 1998-08-15 21:03 ` SL Baur @ 1998-08-15 21:14 ` Harry Putnam 1998-08-25 6:23 ` Matt Simmons 2 siblings, 0 replies; 115+ messages in thread From: Harry Putnam @ 1998-08-15 21:14 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Matt Simmons <simmonmt@acm.org> writes: > > > I can't be the only one who has obscene numbers of unread messages > > rotting away in my mailbox. This causes me to lose new messages, > > especially when the appear as part of a thread headed by previously > > unread messages. > > Well -- don't you want to read messages earlier in the thread before > messages later in the thread? > > > Is there any way to have the messages that have appeared since the > > last time the spool was inc'd displayed in a different face in the > > Summary Buffer? This would make it easier to differentiate between > > old and new unread messages. > > I think it sounds like you really want an unthreaded mail group > summary display. Something along this same vein: I like to have the summary displayed with hidden threads, and have set up the `gnus-summary-line-format' to show the number of messages in a thread. To me, this makes it easier to get a quick overview of the summary. Scroll down to something interesting and start using 'n' which will open the threads and find the new articles. If you have the default view of only new articles, but have a number of 'ticked' articles also in the display then a new message can hide behind a ticked message. I'd like to be able to notice any new articles with out opening the threads with 'T S' and with out using 'n' till I want it. So how would it work to have any thread containing a new message, show the 'unread face' even if some messages in the thread are already read but ticked then when the thread is opened the ticked ones show 'ticked face' and the unread show unread normally. -- Harry Putnam reader@newsguy.com ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Marking new unread articles differently? 1998-08-15 20:43 ` Lars Magne Ingebrigtsen 1998-08-15 21:03 ` SL Baur 1998-08-15 21:14 ` Harry Putnam @ 1998-08-25 6:23 ` Matt Simmons 2 siblings, 0 replies; 115+ messages in thread From: Matt Simmons @ 1998-08-25 6:23 UTC (permalink / raw) >>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes: Matt> I can't be the only one who has obscene numbers of unread messages Matt> rotting away in my mailbox. This causes me to lose new messages, Matt> especially when the appear as part of a thread headed by previously Matt> unread messages. Lars> Well -- don't you want to read messages earlier in the thread before Lars> messages later in the thread? I do. I just want the messages that have appeared since the last inc to show up in a way that calls attention to them (a different face, preferably, but a mark would do in a pinch). When you have large numbers of unread messages, it's difficult to find the one new one that just added itself to a thread. Matt> Is there any way to have the messages that have appeared since the Matt> last time the spool was inc'd displayed in a different face in the Matt> Summary Buffer? This would make it easier to differentiate between Matt> old and new unread messages. Lars> I think it sounds like you really want an unthreaded mail group Lars> summary display. No.. I need the threaded display. I'd like to be able to find, at a glance, the stealth replies that have attached themselves to old threads. Matt -- Matt Simmons - simmonmt@acm.org - http://www.netcom.com/~simmonmt The more times you run over a dead cat, the flatter it gets. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Marking new unread articles differently? 1998-08-15 19:37 Marking new unread articles differently? Matt Simmons 1998-08-15 20:43 ` Lars Magne Ingebrigtsen @ 1998-08-15 21:20 ` Eze Ogwuma 1998-08-16 6:05 ` Mike McEwan 2 siblings, 0 replies; 115+ messages in thread From: Eze Ogwuma @ 1998-08-15 21:20 UTC (permalink / raw) Cc: ding Matt Simmons <simmonmt@acm.org> writes: > I can't be the only one who has obscene numbers of unread messages > rotting away in my mailbox. You're not the only one. [...] > Is there any way to have the messages that have appeared since the > last time the spool was inc'd displayed in a different face in the > Summary Buffer? Or perhaps the "%" mark could be used. > This would make it easier to differentiate between old and new > unread messages. I'd like to see a feature like this too. -- Eze Ogwuma ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Marking new unread articles differently? 1998-08-15 19:37 Marking new unread articles differently? Matt Simmons 1998-08-15 20:43 ` Lars Magne Ingebrigtsen 1998-08-15 21:20 ` Eze Ogwuma @ 1998-08-16 6:05 ` Mike McEwan 1998-08-16 18:30 ` Jari Aalto+list.ding 2 siblings, 1 reply; 115+ messages in thread From: Mike McEwan @ 1998-08-16 6:05 UTC (permalink / raw) Matt Simmons <simmonmt@acm.org> writes: > I can't be the only one who has obscene numbers of unread messages > rotting away in my mailbox. This causes me to lose new messages, > especially when the appear as part of a thread headed by previously > unread messages. > > Is there any way to have the messages that have appeared since the > last time the spool was inc'd displayed in a different face in the > Summary Buffer? This would make it easier to differentiate between > old and new unread messages. > I've been hacking a bit at the gnus source and now have all newly downloaded headers in all my groups flagged with a secondary mark "?N" when I enter the summary buffer. This mark can be used by all the usual summary limiting commands. I've also got some group selection functions that allow me to show only threads with `new' headers or only `new' headers when entering a group. Optionally, the number of newly downloaded headers for a group can be displayed in the group buffer, although I don't know how much sense this makes for those who read their news online. Another function I find useful is having my `agent' groups flagged with a "?>" whenever articles have been downloaded via the use of `%' (gnus-downloadable-mark). I keep marking articles for download and then never reading them having forgotten. As with `new' articles I can select these articles when entering a group and use summary limiting commands on them. If anyone's interested I'll post my current patches to this list. Although the code seems fairly stable, it'd be good if some others could give it the once over and help me remove the `kludge factor' :-). As intimated above, I read my news *offline* via the `agent' and so I've yet to verify what potential damage my code can do in an *online* situation. -- Mike. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Marking new unread articles differently? 1998-08-16 6:05 ` Mike McEwan @ 1998-08-16 18:30 ` Jari Aalto+list.ding 0 siblings, 0 replies; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-08-16 18:30 UTC (permalink / raw) | 1998-08-16 Mike McEwan <mike@lotusland.demon.co.uk> list.ding [exellent features, flagged messages ] | If anyone's interested I'll post my current patches to this | list. Although the code seems fairly stable, it'd be good if some | others could give it the once over and help me remove the `kludge | factor' :-). As intimated above, I read my news *offline* via the | `agent' and so I've yet to verify what potential damage my code can | do in an *online* situation. Oh, please do. Sounds like a *very* usefull features. jari ^ permalink raw reply [flat|nested] 115+ messages in thread
* Feature req: import/export Group parameter or Server data @ 1998-11-05 16:52 Jari Aalto+list.ding 0 siblings, 0 replies; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-11-05 16:52 UTC (permalink / raw) I'd like to see a function that steps through all Groups and Topics and which would dump the Group parameter (And server) data in so that I could save that periodically to separate backup disk. So if my .newsrc* is sometimes gone or if I killed some groups by accident, I could cut'n paste or Import the Group Parameter back to the group So a simple Write/Read Group parameter data to a file would be fine for now. A Map-through-groups toplevel function would be next step. I also move data between several Emasc/Gnus in different sites, so exporting, importing Group/Server data would be nice. jari ^ permalink raw reply [flat|nested] 115+ messages in thread
* Pterodactyl Gnus v0.36 is released @ 1998-10-20 18:26 Lars Magne Ingebrigtsen 1998-10-20 19:27 ` *Group* buffer disappearance (Re: Pterodactyl Gnus v0.36 is released) Lloyd Zusman 0 siblings, 1 reply; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-10-20 18:26 UTC (permalink / raw) Bug fixes and nested multipart stuff. Get it from <URL:http://www.gnus.org/pgnus.tar.gz> or "/ftp@ftp.gnus.org:/pub/emacs/gnus/". The patch is available as <URL:http://www.gnus.org/patches/pgnus-0.35-0.36.diff.gz>. ChangeLog since last release: Tue Oct 20 20:25:03 1998 Lars Magne Ingebrigtsen <larsi@menja.ifi.uio.no> * gnus.el: Pterodactyl Gnus v0.36 is released. 1998-10-20 18:13:08 Lars Magne Ingebrigtsen <larsi@gnus.org> * gnus-art.el (article-translate-strings): (gnus-article-dumbquotes-map): Don't dot. * pop3.el (pop3-open-server): Set point right. * mm-decode.el (mm-dissect-multipart): Dissect hierarchically. (mm-dissect-buffer): Ditto. (mm-destroy-part): Ignore non-handles. (mm-remove-part): Ditto. (mm-destroy-parts): New function. (mm-remove-parts): Ditto. * gnus-art.el (gnus-mm-display-part): Don't move point. Tue Oct 20 02:16:36 1998 Shenghuo ZHU <zsh@cs.rochester.edu> * mm-uu.el : New file. * gnus-art.el (gnus-display-mime): Dissect uu stuffs. * mm-bodies.el (mm-decode-content-transfer-encoding): Encoding as a function. 1998-10-20 00:35:05 Lars Magne Ingebrigtsen <larsi@gnus.org> * mm-decode.el (mm-display-external): Check before selecting. -- (domestic pets only, the antidote for overdose, milk.) larsi@ifi.uio.no * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* *Group* buffer disappearance (Re: Pterodactyl Gnus v0.36 is released) 1998-10-20 18:26 Pterodactyl Gnus v0.36 is released Lars Magne Ingebrigtsen @ 1998-10-20 19:27 ` Lloyd Zusman 1998-10-21 2:58 ` I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) Lloyd Zusman 0 siblings, 1 reply; 115+ messages in thread From: Lloyd Zusman @ 1998-10-20 19:27 UTC (permalink / raw) There's a bug that exists both in v0.35 and v0.36 whereby the *Group* buffer seems to mysteriously disappear under certain circumstances. I don't think that this particular problem existed in versions <= v0.34. I'm not sure what could be causing this. Here's the scenario: (1) View a message that has at least one `application/octet-stream' MIME attachment. (2) [Suppose that this is attachment number 2] Enter the following command: `2 b' (3) Prompt appears in the mini-buffer asking where to save the attachment. Enter a file name. (4) Attachment gets nicely saved. (5) Type `q' to leave summary mode and go back to *Group* buffer. (6) The *Group* buffer seems to have disappeared, thereby signaling the following error: Signaling: (error "Selecting deleted or non-existent buffer") #<compiled-function (from "gnus-sum.elc") (&optional temporary) "...(402)" [gnus-set-global-variables gnus-kill-save-kill-buffer gnus-async-halt-prefetch gnus-newsgroup-name group gnus-group-quit-config quit-config major-mode mode nil group-point buf gnus-run-hooks gnus-summary-prepare-exit-hook gnus-single-article-buffer gnus-original-article-buffer buffer get-buffer buffer-name kill-buffer gnus-article-current gnus-use-cache gnus-cache-possibly-remove-articles gnus-cache-save-buffers gnus-async-prefetch-remove-group gnus-suppress-duplicates gnus-dup-enter-articles gnus-use-trees gnus-tree-close nnmail-purge-split-history gname string-match "^[^:]+:" 0 gnus-exit-group-hook gnus-summary-update-info gnus-newsgroup-adaptive gnus-score-adaptive gnus-use-scoring gnus-score-save gnus-close-group gnus-group-buffer gnus-group-jump-to-group gnus-summary-exit-hook gnus-group-group-name gnus-group-next-unread-group 1 temporary gnus-article-buffer mapcar ...] 5 ("/usr/lib/xemacs/site-lisp/pgnus-0.36/lisp/gnus-sum.elc" . 139872) nil>() call-interactively(gnus-summary-exit) Any ideas? -- Lloyd Zusman ljz@asfast.com ^ permalink raw reply [flat|nested] 115+ messages in thread
* I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) 1998-10-20 19:27 ` *Group* buffer disappearance (Re: Pterodactyl Gnus v0.36 is released) Lloyd Zusman @ 1998-10-21 2:58 ` Lloyd Zusman 1998-10-21 12:40 ` Hrvoje Niksic 0 siblings, 1 reply; 115+ messages in thread From: Lloyd Zusman @ 1998-10-21 2:58 UTC (permalink / raw) Cc: larsi Lloyd Zusman <ljz@asfast.com> writes: > There's a bug that exists both in v0.35 and v0.36 whereby the *Group* > buffer seems to mysteriously disappear under certain circumstances. > [ ... ] Well, I fixed the problem, but what a complex tangle of function calls I had to go through to find it! Also, I'm not sure if my fix is actually the best way to solve this problem. Lars, could you review my solution here to see if I've made the correct assumptions in fixing it? First of all, here's the patch which fixes the problem: *** mm-decode.el.orig Tue Oct 20 22:36:04 1998 --- mm-decode.el Tue Oct 20 22:36:29 1998 *************** *** 221,227 **** (mm-set-buffer-file-coding-system 'no-conversion) (insert-buffer-substring cur) (funcall method) ! (mm-handle-set-undisplayer handle (current-buffer))) (let* ((dir (make-temp-name (expand-file-name "emm." mm-tmp-directory))) (filename (mail-content-type-get (mm-handle-disposition handle) 'filename)) --- 221,227 ---- (mm-set-buffer-file-coding-system 'no-conversion) (insert-buffer-substring cur) (funcall method) ! (mm-handle-set-undisplayer handle cur)) (let* ((dir (make-temp-name (expand-file-name "emm." mm-tmp-directory))) (filename (mail-content-type-get (mm-handle-disposition handle) 'filename)) Note that the problem had to do with the `(current-buffer)' call immediately following `(funcall method)'. When the method is `mailcap-save-binary-file', this method causes the current buffer to change (see below for a listing of `mailcap-save-binary-file'). Therefore, we need to use `cur' here instead of `(current-buffer)', just like in the rest of this routine (`mm-display-external'). So far so good. But does my solution just mask a more subtle problem? Consider the `mailcap-save-binary-file' routine (in `mailcap.el'): (defun mailcap-save-binary-file () (goto-char (point-min)) (let ((file (read-file-name "Filename to save as: " (or mailcap-download-directory "~/"))) (require-final-newline nil)) (write-region (point-min) (point-max) file) (kill-buffer (current-buffer)))) Note that the final line of this routine kills the current buffer, However, when this routine is being called from within `mm-display-external', the current buffer is one of the ` *mm*' buffers. Do we really want this ` *mm*' buffer to be killed as part of the routine which saves the binary file? If we do, then my patch is the proper fix. However, if this ` *mm*' buffer needs to stick around a while longer for some reason, then we really shouldn't be using `mailcap-save-binary-file' in its current form as the method call. What do you think, Lars? -- Lloyd Zusman ljz@asfast.com ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) 1998-10-21 2:58 ` I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) Lloyd Zusman @ 1998-10-21 12:40 ` Hrvoje Niksic 1998-10-21 13:54 ` Lloyd Zusman 0 siblings, 1 reply; 115+ messages in thread From: Hrvoje Niksic @ 1998-10-21 12:40 UTC (permalink / raw) Lloyd Zusman <ljz@asfast.com> writes: > Note that the problem had to do with the `(current-buffer)' call > immediately following `(funcall method)'. When the method is > `mailcap-save-binary-file', this method causes the current buffer to > change (see below for a listing of `mailcap-save-binary-file'). > Therefore, we need to use `cur' here instead of `(current-buffer)', > just like in the rest of this routine (`mm-display-external'). Killing `cur' doesn't look right. The buffer you really want to kill is the "*mm*" buffer, not the current buffer before that. How about this: --- mm-decode.el.orig Wed Oct 21 14:32:26 1998 +++ mm-decode.el Wed Oct 21 14:35:45 1998 @@ -220,8 +220,10 @@ (buffer-disable-undo) (mm-set-buffer-file-coding-system 'no-conversion) (insert-buffer-substring cur) - (funcall method) - (mm-handle-set-undisplayer handle (current-buffer))) + (let ((mm (current-buffer))) + (unwind-protect + (funcall method) + (mm-handle-set-undisplayer handle mm)))) (let* ((dir (make-temp-name (expand-file-name "emm." mm-tmp-directory))) (filename (mail-content-type-get (mm-handle-disposition handle) 'filename)) I used `unwind-protect' so that if a signal occurs during the method, the undisplayer still gets set. (What I don't understand is why the undisplayer method still doesn't get *called* when I press C-g.) > Note that the final line of this routine kills the current buffer, > However, when this routine is being called from within > `mm-display-external', the current buffer is one of the ` *mm*' > buffers. Do we really want this ` *mm*' buffer to be killed as part > of the routine which saves the binary file? Yes. The *mm* buffer is temporary stuff used for decoding MIME. We don't want buffers with random binary contents to stick around, I think. -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "Psychos _do not_ explode when sunlight hits them." ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) 1998-10-21 12:40 ` Hrvoje Niksic @ 1998-10-21 13:54 ` Lloyd Zusman 1998-10-21 14:22 ` Hrvoje Niksic 0 siblings, 1 reply; 115+ messages in thread From: Lloyd Zusman @ 1998-10-21 13:54 UTC (permalink / raw) Cc: Hrvoje Niksic Hrvoje Niksic <hniksic@srce.hr> writes: > Lloyd Zusman <ljz@asfast.com> writes: > > > Note that the problem had to do with the `(current-buffer)' call > > immediately following `(funcall method)'. When the method is > > `mailcap-save-binary-file', this method causes the current buffer to > > change (see below for a listing of `mailcap-save-binary-file'). > > Therefore, we need to use `cur' here instead of `(current-buffer)', > > just like in the rest of this routine (`mm-display-external'). > > Killing `cur' doesn't look right. The buffer you really want to kill > is the "*mm*" buffer, not the current buffer before that. Yes. This seems correct, and it works under my test scenario. > [ ... correct patch that appears elsewhere snipped ... ] > I used `unwind-protect' so that if a signal occurs during the method, > the undisplayer still gets set. > > (What I don't understand is why the undisplayer method still doesn't > get *called* when I press C-g.) `unwind-protect' alone doesn't trap `C-g' signals. I believe that you have to make use of `condition-case' if you want to trap `C-g'. I have to run to a meeting in a few minutes. When I come back, I'll redo your patch using `condition-case' and post it here. > > Note that the final line of this routine kills the current buffer, > > However, when this routine is being called from within > > `mm-display-external', the current buffer is one of the ` *mm*' > > buffers. Do we really want this ` *mm*' buffer to be killed as part > > of the routine which saves the binary file? > > Yes. The *mm* buffer is temporary stuff used for decoding MIME. We > don't want buffers with random binary contents to stick around, I > think. But by storing the name of the ` *mm*' buffer in the data structure managed by `mm-handle-set-undisplayer', we're assuring that this ` *mm*' buffer gets deleted later. Prior to this, should the buffer get killed within the `mailcap-save-binary-file' method? Would this somehow cause problems later? -- Lloyd Zusman ljz@asfast.com ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) 1998-10-21 13:54 ` Lloyd Zusman @ 1998-10-21 14:22 ` Hrvoje Niksic 1998-10-21 14:55 ` Lloyd Zusman 0 siblings, 1 reply; 115+ messages in thread From: Hrvoje Niksic @ 1998-10-21 14:22 UTC (permalink / raw) Cc: ding Lloyd Zusman <ljz@asfast.com> writes: > > (What I don't understand is why the undisplayer method still doesn't > > get *called* when I press C-g.) > > `unwind-protect' alone doesn't trap `C-g' signals. I'm not talking about "trapping", but about evaluating the cleanup code. Try this: (unwind-protect (sleep-for 5) (setq a (current-time-string))) The point of this form is that `a' will end up being assigned even if you exit from `sleep-for' nonlocally, such as with C-g. > I have to run to a meeting in a few minutes. When I come back, I'll > redo your patch using `condition-case' and post it here. Don't do that. -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Call CIA and tell them that you have placed a bomb in a 7-11 shop! Be sure to let them trace you. Spend 10 years in jail and then regret it. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) 1998-10-21 14:22 ` Hrvoje Niksic @ 1998-10-21 14:55 ` Lloyd Zusman 1998-10-21 14:59 ` Hrvoje Niksic 0 siblings, 1 reply; 115+ messages in thread From: Lloyd Zusman @ 1998-10-21 14:55 UTC (permalink / raw) Cc: Hrvoje Niksic Hrvoje Niksic <hniksic@srce.hr> writes: > Lloyd Zusman <ljz@asfast.com> writes: > > > > (What I don't understand is why the undisplayer method still doesn't > > > get *called* when I press C-g.) > > > > `unwind-protect' alone doesn't trap `C-g' signals. > > I'm not talking about "trapping", but about evaluating the cleanup > code. OK. The call to `mm-handle-set-undisplayer' is indeed being made in your `unwind-protect' version, even if `C-g' has been invoked. However, the `mm-handle-set-undisplayer' routine merely queues up the ` *mm*' buffer for later undisplaying. This undisplaying doesn't actually occur until `gnus-summary-exit' gets invoked. Here's the code fragment within `gnus-summary-exit' which takes care of this: (when (gnus-buffer-live-p gnus-article-buffer) (save-excursion (set-buffer gnus-article-buffer) (mapcar 'mm-destroy-part gnus-article-mime-handles))) Actually, this fragment exists within `gnus-summary-exit-no-update', but that routine is normally defalias-ed to `gnus-summary-exit'. There's also another place where this is also invoked ... I believe its within the default `gnus-group-exit-hook'. If we want to clean this up at the moment when someone hits `C-g', then we may have to use `condition-case' after all. > [ ... ] -- Lloyd Zusman ljz@asfast.com ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) 1998-10-21 14:55 ` Lloyd Zusman @ 1998-10-21 14:59 ` Hrvoje Niksic 1998-10-21 15:07 ` Lloyd Zusman 0 siblings, 1 reply; 115+ messages in thread From: Hrvoje Niksic @ 1998-10-21 14:59 UTC (permalink / raw) Cc: ding Lloyd Zusman <ljz@asfast.com> writes: > If we want to clean this up at the moment when someone hits `C-g', > then we may have to use `condition-case' after all. Argh! :-) We don't. We just add the same kind of cleanup code at the place where the buffer normally gets deleted. See my later patch. -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- A jury consists of 12 persons chosen to decide who has the better lawyer. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) 1998-10-21 14:59 ` Hrvoje Niksic @ 1998-10-21 15:07 ` Lloyd Zusman 1998-10-21 15:10 ` Hrvoje Niksic 0 siblings, 1 reply; 115+ messages in thread From: Lloyd Zusman @ 1998-10-21 15:07 UTC (permalink / raw) Cc: Hrvoje Niksic Hrvoje Niksic <hniksic@srce.hr> writes: > Lloyd Zusman <ljz@asfast.com> writes: > > > If we want to clean this up at the moment when someone hits `C-g', > > then we may have to use `condition-case' after all. > > Argh! :-) We don't. We just add the same kind of cleanup code at > the place where the buffer normally gets deleted. See my later patch. I await with bated breath! :) I accept your point about not wanting to do the cleanup at the moment `C-g' is invoked, but solely for my own education and edification (and that of anyone else who might be interested), could you explain why an immediate `C-g' trap is so undesirable at this point? -- Lloyd Zusman ljz@asfast.com ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) 1998-10-21 15:07 ` Lloyd Zusman @ 1998-10-21 15:10 ` Hrvoje Niksic 1998-10-21 15:17 ` Lloyd Zusman 1998-10-22 13:10 ` Jari Aalto+list.ding 0 siblings, 2 replies; 115+ messages in thread From: Hrvoje Niksic @ 1998-10-21 15:10 UTC (permalink / raw) Cc: ding Lloyd Zusman <ljz@asfast.com> writes: > I accept your point about not wanting to do the cleanup at the > moment `C-g' is invoked, but solely for my own education and > edification (and that of anyone else who might be interested), could > you explain why an immediate `C-g' trap is so undesirable at this > point? C-g trap is not undesirable; it's just that you're confusing condition-case and unwind-protect. condition-case should be used when you want to selectively trap errors and do cleanup code. What we need here is the cleanup code that evaluates no matter what way we exit from the function -- including C-g. This is exactly what unwind-protect is for. So, my patch adds unwind protection twice: once for the undisplayer to be set, and once for the buffer to be killed after it is saved (or not). I hope this makes sense. -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Do not meddle in the affairs of troff, for it is subtle and quick to anger. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) 1998-10-21 15:10 ` Hrvoje Niksic @ 1998-10-21 15:17 ` Lloyd Zusman 1998-10-21 15:24 ` Hrvoje Niksic 1998-10-22 13:10 ` Jari Aalto+list.ding 1 sibling, 1 reply; 115+ messages in thread From: Lloyd Zusman @ 1998-10-21 15:17 UTC (permalink / raw) Cc: Hrvoje Niksic Hrvoje Niksic <hniksic@srce.hr> writes: > [ ... ] > > C-g trap is not undesirable; it's just that you're confusing > condition-case and unwind-protect. > > condition-case should be used when you want to selectively trap errors > and do cleanup code. What we need here is the cleanup code that > evaluates no matter what way we exit from the function -- including > C-g. This is exactly what unwind-protect is for. > > So, my patch adds unwind protection twice: once for the undisplayer to > be set, and once for the buffer to be killed after it is saved (or > not). I hope this makes sense. It's clear to me now. I had thought that the only time we would want to clean up prior to `gnus-summary-exit' is if an error or an abort occurred during the method call. If we're supposed to be cleaning up prior to `gnus-summary-exit' even in the case where the method succeeds, then I understand why you're proceeding as you are. ... or at least I *think* I understand. :) -- Lloyd Zusman ljz@asfast.com ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) 1998-10-21 15:17 ` Lloyd Zusman @ 1998-10-21 15:24 ` Hrvoje Niksic 1998-10-21 15:39 ` Lloyd Zusman 0 siblings, 1 reply; 115+ messages in thread From: Hrvoje Niksic @ 1998-10-21 15:24 UTC (permalink / raw) Lloyd Zusman <ljz@asfast.com> writes: > It's clear to me now. I had thought that the only time we would > want to clean up prior to `gnus-summary-exit' is if an error or an > abort occurred during the method call. If we're supposed to be > cleaning up prior to `gnus-summary-exit' even in the case where the > method succeeds, then I understand why you're proceeding as you are. Well, that's what the code did before we started meddling, innit? :-) -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- 4. Thou shalt not warlorde a sig if it bee the sig of Kibo, nor if it bee the sig of the Inner Circle. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) 1998-10-21 15:24 ` Hrvoje Niksic @ 1998-10-21 15:39 ` Lloyd Zusman 1998-10-21 15:48 ` Hrvoje Niksic 0 siblings, 1 reply; 115+ messages in thread From: Lloyd Zusman @ 1998-10-21 15:39 UTC (permalink / raw) Cc: Hrvoje Niksic Hrvoje Niksic <hniksic@srce.hr> writes: > Lloyd Zusman <ljz@asfast.com> writes: > > > It's clear to me now. I had thought that the only time we would > > want to clean up prior to `gnus-summary-exit' is if an error or an > > abort occurred during the method call. If we're supposed to be > > cleaning up prior to `gnus-summary-exit' even in the case where the > > method succeeds, then I understand why you're proceeding as you are. > > Well, that's what the code did before we started meddling, innit? :-) I must be missing something, then. The only places I have discovered this cleanup being done in the pre-meddling version of the code is during `gnus-summary-exit' and `gnus-group-exit-hook'. Therefore, I fully understand the need for putting an `unwind-protect' around `(funcall method)' ... but I don't understand the need for the other `unwind-protect' that you mentioned in your previous message. -- Lloyd Zusman ljz@asfast.com ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) 1998-10-21 15:39 ` Lloyd Zusman @ 1998-10-21 15:48 ` Hrvoje Niksic 1998-10-21 15:56 ` Lee Willis 0 siblings, 1 reply; 115+ messages in thread From: Hrvoje Niksic @ 1998-10-21 15:48 UTC (permalink / raw) Cc: ding Lloyd Zusman <ljz@asfast.com> writes: > I must be missing something, then. The only places I have > discovered this cleanup being done in the pre-meddling version of > the code is during `gnus-summary-exit' and `gnus-group-exit-hook'. > Therefore, I fully understand the need for putting an > `unwind-protect' around `(funcall method)' ... but I don't > understand the need for the other `unwind-protect' that you > mentioned in your previous message. Think about it this way: again, that's what the code did before I meddled. The only thing I added is to make it do the same thing when the user presses C-g at the save prompt. The unwind-protect around (funcall method) is, I think, needed in case method is something other than save-file. -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Depression is merely anger without enthusiasm. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) 1998-10-21 15:48 ` Hrvoje Niksic @ 1998-10-21 15:56 ` Lee Willis 0 siblings, 0 replies; 115+ messages in thread From: Lee Willis @ 1998-10-21 15:56 UTC (permalink / raw) Hrvoje Niksic <hniksic@srce.hr> writes: > Lloyd Zusman <ljz@asfast.com> writes: > > Think about it this way: again, that's what the code did before I > meddled. The only thing I added is to make it do the same thing when > the user presses C-g at the save prompt. > > The unwind-protect around (funcall method) is, I think, needed in case > method is something other than save-file. Hmm, well the bug can also be reproduced when you have a multi-part/alternative message. E.g. I received a message with a text/plain and text/html alternative part. Clicking (Or in my case RET-ing) on the text/html part brings up a save prompt at which I give a filename, gnus saves it OK, but my *Group* buffer has now taken a trip to /dev/null :( Lee. -- I was doing object-oriented assembly at 1 year old ... For some reason my mom insists on calling it "Playing with blocks" ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) 1998-10-21 15:10 ` Hrvoje Niksic 1998-10-21 15:17 ` Lloyd Zusman @ 1998-10-22 13:10 ` Jari Aalto+list.ding 1 sibling, 0 replies; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-10-22 13:10 UTC (permalink / raw) | 1998-10-21 Hrvoje Niksic <hniksic@srce.hr> list.ding | | ...the cleanup code that evaluates no matter what way we exit from the | function -- including C-g. This is exactly what unwind-protect is for. This was something I wondered an hour ago in my own code. What does "nonlocal" exist mean? And is it corect that cleanup is not done if debug is on? (setq debug-on-error t) (unwind-protect (error) (insert "cleanup ok")) The doc string of debug-on-error doesn't mention that the behavior depends on debug-on-error setting... jari ^ permalink raw reply [flat|nested] 115+ messages in thread
* compatibility request -- `q' in *Article* buffer shouldn't quit group @ 1998-10-11 6:48 SL Baur 1998-10-11 15:29 ` Lars Magne Ingebrigtsen [not found] ` <6f7ly7i16q.fsf@dna.lth.se> 0 siblings, 2 replies; 115+ messages in thread From: SL Baur @ 1998-10-11 6:48 UTC (permalink / raw) Could `q' from inside the *Article* buffer please return to the *Summary* buffer the same way it did with TM? ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 6:48 compatibility request -- `q' in *Article* buffer shouldn't quit group SL Baur @ 1998-10-11 15:29 ` Lars Magne Ingebrigtsen 1998-10-11 17:11 ` Matt Simmons [not found] ` <6f7ly7i16q.fsf@dna.lth.se> 1 sibling, 1 reply; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-10-11 15:29 UTC (permalink / raw) SL Baur <steve@xemacs.org> writes: > Could `q' from inside the *Article* buffer please return to the > *Summary* buffer the same way it did with TM? Er... I don't know. `h' is the traditional way of skipping between the article and summary buffers. `q' has always meant `quit', in one form or another. (Except in TM, that is.) -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 15:29 ` Lars Magne Ingebrigtsen @ 1998-10-11 17:11 ` Matt Simmons 1998-10-11 17:23 ` Hrvoje Niksic 0 siblings, 1 reply; 115+ messages in thread From: Matt Simmons @ 1998-10-11 17:11 UTC (permalink / raw) >>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes: sb> Could `q' from inside the *Article* buffer please return to the sb> *Summary* buffer the same way it did with TM? Lars> Er... I don't know. `h' is the traditional way of skipping between Lars> the article and summary buffers. `q' has always meant `quit', in one Lars> form or another. (Except in TM, that is.) Well, if you think of it as a hierarchy (group, summary, article), then using `q' to return to the summary buffer makes sense. You're using `q' to quit the article buffer, thus returning to the summary buffer, just as you use `q' to quit the summary buffer, returning you to the group buffer. Matt -- Matt Simmons - simmonmt@acm.org - http://www.netcom.com/~simmonmt "No animal should ever jump up on the dining-room furniture unless absolutely certain that he can hold his own in the conversation." -- Fran Lebowitz ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 17:11 ` Matt Simmons @ 1998-10-11 17:23 ` Hrvoje Niksic 1998-10-11 19:05 ` SL Baur 0 siblings, 1 reply; 115+ messages in thread From: Hrvoje Niksic @ 1998-10-11 17:23 UTC (permalink / raw) Matt Simmons <simmonmt@acm.org> writes: > >>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > > sb> Could `q' from inside the *Article* buffer please return to the > sb> *Summary* buffer the same way it did with TM? > > Lars> Er... I don't know. `h' is the traditional way of > Lars> skipping between the article and summary buffers. `q' has > Lars> always meant `quit', in one form or another. (Except in > Lars> TM, that is.) > > Well, if you think of it as a hierarchy (group, summary, article), > then using `q' to return to the summary buffer makes sense. Article buffer is not a part of that hierarchy. For example, pressing RET or SPC doesn't get you to the Article buffer. A while ago, someone has asked Lars to make `q' in Summary buffer perform `/ w' if there are any limits available. Lars refused because he thought that `q' shouldn't change its meaning. I agree. -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- * Q: What is an experienced Emacs user? * A: A person who wishes that the terminal had pedals. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 17:23 ` Hrvoje Niksic @ 1998-10-11 19:05 ` SL Baur 1998-10-11 19:11 ` Hrvoje Niksic 1998-10-11 22:13 ` Kai Grossjohann 0 siblings, 2 replies; 115+ messages in thread From: SL Baur @ 1998-10-11 19:05 UTC (permalink / raw) Hrvoje Niksic <hniksic@srce.hr> writes in ding@gnus.org: Lars> Er... I don't know. `h' is the traditional way of Lars> skipping between the article and summary buffers. `q' has Lars> always meant `quit', in one form or another. (Except in Lars> TM, that is.) I lost count of the number it times it bit me when I was experimenting with pgnus yesterday. If group (re)entry weren't so bloody slow on large groups it might not be much of an issue. A lot of people use TM with Gnus and we're going to be in a world of unnecessary pain. >> Well, if you think of it as a hierarchy (group, summary, article), >> then using `q' to return to the summary buffer makes sense. Yes, it does make sense. > Article buffer is not a part of that hierarchy. For example, pressing > RET or SPC doesn't get you to the Article buffer. ? SPC should probably do a page forward, or move to the next MIME multipart. > A while ago, someone has asked Lars to make `q' in Summary buffer > perform `/ w' if there are any limits available. Lars refused because > he thought that `q' shouldn't change its meaning. I agree. Hmm. Widening would make more sense. I haven't checked recently, but the last time I entered a digest, hitting a `q' (in the *Summary* buffer not *Article* buffer) popped the digest but didn't exit the group. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 19:05 ` SL Baur @ 1998-10-11 19:11 ` Hrvoje Niksic 1998-10-11 20:40 ` SL Baur 1998-10-11 22:13 ` Kai Grossjohann 1 sibling, 1 reply; 115+ messages in thread From: Hrvoje Niksic @ 1998-10-11 19:11 UTC (permalink / raw) SL Baur <steve@xemacs.org> writes: > I lost count of the number it times it bit me when I was experimenting > with pgnus yesterday. Yes, but that's because you are accustomed to TM. If it weren't for this TM's design decision, you would probably not do that. > > Article buffer is not a part of that hierarchy. For example, > > pressing RET or SPC doesn't get you to the Article buffer. > > ? SPC should probably do a page forward, or move to the next MIME > multipart. What I mean is: pressing SPC in the Group buffer switches you to Summary. But pressing SPC in the Summary buffer doesn't switch you to Article buffer. This is why I think there is no good reason to make `q' in Article buffer switch to Summary. Especially when we already have two commands to do that (`h' and `s'). Adding a fourth one looks like a real waste to me. -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- If we get involved in a nuclear war, will the electromagnetic pulses from exploding bombs damage my videotapes? ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 19:11 ` Hrvoje Niksic @ 1998-10-11 20:40 ` SL Baur 1998-10-11 20:44 ` Hrvoje Niksic 0 siblings, 1 reply; 115+ messages in thread From: SL Baur @ 1998-10-11 20:40 UTC (permalink / raw) Hrvoje Niksic <hniksic@srce.hr> writes in ding@gnus.org: > SL Baur <steve@xemacs.org> writes: >> I lost count of the number it times it bit me when I was experimenting >> with pgnus yesterday. > Yes, but that's because you are accustomed to TM. If it weren't for > this TM's design decision, you would probably not do that. That's exactly the point. TM has been around for a *long* time -- as long as Gnus 5 has been in existence. The Gnus FAQ recommended it practically from day 1. It has been the default MIME package in XEmacs since XEmacs 19.15. Gnus is now taking over that area itself and it really should preserve backwards compatibility particularly with respect to user interface. This isn't any different than the way message mode preserves the same keybindings of the ancient mail-mode. ... > What I mean is: pressing SPC in the Group buffer switches you to > Summary. But pressing SPC in the Summary buffer doesn't switch you to > Article buffer. This is why I think there is no good reason to make > `q' in Article buffer switch to Summary. > Especially when we already have two commands to do that (`h' and `s'). > Adding a fourth one looks like a real waste to me. Gnus is *changing* the binding of `q' which formerly meant quit the MIME viewer and return to the *Summary* buffer to exit the group. This is dead wrong IMO. There's similar braindamage in BBDB 2 -- the M-TAB fuckage it introduced has got to go. That key belongs to ispell. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 20:40 ` SL Baur @ 1998-10-11 20:44 ` Hrvoje Niksic 1998-10-11 21:24 ` Karl Kleinpaste 1998-10-12 14:01 ` Jari Aalto+list.ding 0 siblings, 2 replies; 115+ messages in thread From: Hrvoje Niksic @ 1998-10-11 20:44 UTC (permalink / raw) SL Baur <steve@xemacs.org> writes: > > Yes, but that's because you are accustomed to TM. If it weren't for > > this TM's design decision, you would probably not do that. > > That's exactly the point. TM has been around for a *long* time -- > as long as Gnus 5 has been in existence. The Gnus FAQ recommended > it practically from day 1. It has been the default MIME package in > XEmacs since XEmacs 19.15. Gnus is now taking over that area itself > and it really should preserve backwards compatibility particularly > with respect to user (...) The phrase "backward compatibility" cannot apply here because TM has never been a part of Gnus. People who used TM did so "on their own responsibility". Incompatibly changing Gnus to satisfy former TM users would IMHO be plain wrong. > > What I mean is: pressing SPC in the Group buffer switches you to > > Summary. But pressing SPC in the Summary buffer doesn't switch > > you to Article buffer. This is why I think there is no good > > reason to make `q' in Article buffer switch to Summary. > > > Especially when we already have two commands to do that (`h' and > > `s'). Adding a fourth one looks like a real waste to me. > > Gnus is *changing* the binding of `q' which formerly meant quit the > MIME viewer There never was any MIME viewer in Gnus. > There's similar braindamage in BBDB 2 -- the M-TAB fuckage it > introduced has got to go. That key belongs to ispell. M-TAB was bound to `lisp-complete-symbol' until recently. The ispell binding is IMHO useless because there are too many possibilities for the completion attempt to be useful. But this is a totally different issue. -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Ask not for whom the <CONTROL-G> tolls. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 20:44 ` Hrvoje Niksic @ 1998-10-11 21:24 ` Karl Kleinpaste 1998-10-11 21:41 ` Hrvoje Niksic ` (2 more replies) 1998-10-12 14:01 ` Jari Aalto+list.ding 1 sibling, 3 replies; 115+ messages in thread From: Karl Kleinpaste @ 1998-10-11 21:24 UTC (permalink / raw) You're splitting semantic hairs that are already exceptionally fine. While technically not distributed as part of Gnus, TM has been "part of Gnus" insofar as Gnus explicitly referred everyone to TM. The exercise of "their own responsibility" necessary to use TM consists of a single load directive, nothing more. People have been using TM, and *only* TM, as "Gnus' MIME viewer" for years. Breaking those habits should be done with care. You might as well stop telling people to adjust their mail addresses with user-mail-address, because the definition of user-mail-address "isn't part of Gnus." Personally, I *do* think of group/summary/article as a hierarchy, for increasing precision: I get a big overview in *Group*, I see per-group specifics in *Summary*, and I get down and dirty with a particular piece of text by hitting buttonized content in *Article*. I think having `q' go back to *Summary* is a dandy idea...and I wasn't even aware until this discussion that TM did so. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 21:24 ` Karl Kleinpaste @ 1998-10-11 21:41 ` Hrvoje Niksic 1998-10-11 22:18 ` Kai Grossjohann 1998-10-12 10:08 ` Lloyd Zusman 1998-10-12 13:39 ` Per Abrahamsen 2 siblings, 1 reply; 115+ messages in thread From: Hrvoje Niksic @ 1998-10-11 21:41 UTC (permalink / raw) Karl Kleinpaste <karl@jprc.com> writes: > While technically not distributed as part of Gnus, TM has been "part > of Gnus" insofar as Gnus explicitly referred everyone to TM. I cannot find such a reference in the manual, except for an FAQ entry. > The exercise of "their own responsibility" necessary to use TM > consists of a single load directive, nothing more. I agree that it was easy to load TM. It says nothing about it being a part of Gnus. It's always been an extension package. > People have been using TM, and *only* TM, as "Gnus' MIME viewer" for > years. Breaking those habits should be done with care. This is patently false. People have also been using rmime. I didn't want to have anything to do with TM because of its extremely ugly user-interface. As for breaking habits, many habits were broken by introducing message-mode instead of mail and news modes, and yet the users adapted. > You might as well stop telling people to adjust their mail addresses > with user-mail-address, because the definition of user-mail-address > "isn't part of Gnus." ? -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Ask not for whom the <CONTROL-G> tolls. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 21:41 ` Hrvoje Niksic @ 1998-10-11 22:18 ` Kai Grossjohann 0 siblings, 0 replies; 115+ messages in thread From: Kai Grossjohann @ 1998-10-11 22:18 UTC (permalink / raw) I'm not sure about all this. OT1H, there was metamail.el and rmime.el, both of which did the MIME thing alright. So one can't really say that everybody who wanted a MIMEy Gnus has used TM. OTOH, the article buffer is getting to be more like a group, what with multipart messages, so it seems that the group-summary-article hierarchy is a valid thing. I'm sure that we can't satisfy everybody's need. In the end, all we can do is toss a coin. And then, why don't we all just accept Lars' wishes, he's got a certain right to have Gnus working the way he wants it, after all :-) It would be nice, though, to have an easily-customizable variable `gnus-mime-be-like-tm' or something. Hm. But that would be ugly. kai -- OOP: object oriented programming; OOPS: object oriented mistakes ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 21:24 ` Karl Kleinpaste 1998-10-11 21:41 ` Hrvoje Niksic @ 1998-10-12 10:08 ` Lloyd Zusman 1998-10-12 13:12 ` Lars Magne Ingebrigtsen 1998-10-12 13:39 ` Per Abrahamsen 2 siblings, 1 reply; 115+ messages in thread From: Lloyd Zusman @ 1998-10-12 10:08 UTC (permalink / raw) Karl Kleinpaste <karl@jprc.com> writes: > You're splitting semantic hairs that are already exceptionally fine. > > While technically not distributed as part of Gnus, TM has been "part > of Gnus" insofar as Gnus explicitly referred everyone to TM. The > exercise of "their own responsibility" necessary to use TM consists of > a single load directive, nothing more. People have been using TM, and > *only* TM, as "Gnus' MIME viewer" for years. Breaking those habits > should be done with care. > > [ ... ] How about something like this: In `gnus.el' ... (defvar gnus-tm-compatibility nil "*TM compatibility.") In `gnus-art.el' ... (when gnus-tm-compatibility (gnus-define-keys gnus-article-mode-map "q" gnus-article-show-summary)) ... or at least something similar. Would this solution be a "win-win situation", or does this just shift the flame w^H^H^H^H^H^H^Hdebate to the question of whether to use `nil' or `t' in the `defvar' above? :) > [ ... ] -- Lloyd Zusman ljz@asfast.com ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-12 10:08 ` Lloyd Zusman @ 1998-10-12 13:12 ` Lars Magne Ingebrigtsen 1998-10-12 22:17 ` Lloyd Zusman 0 siblings, 1 reply; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-10-12 13:12 UTC (permalink / raw) Lloyd Zusman <ljz@asfast.com> writes: > How about something like this: > > In `gnus.el' ... > > (defvar gnus-tm-compatibility nil > "*TM compatibility.") No. Keymaps that change according to variables like this is very confusing, both to me and to users. ("And then I press 'q', and flargbnoze happens." "Er. Which 'q'?") -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-12 13:12 ` Lars Magne Ingebrigtsen @ 1998-10-12 22:17 ` Lloyd Zusman 1998-10-17 19:21 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 115+ messages in thread From: Lloyd Zusman @ 1998-10-12 22:17 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Lloyd Zusman <ljz@asfast.com> writes: > > > How about something like this: > > > > In `gnus.el' ... > > > > (defvar gnus-tm-compatibility nil > > "*TM compatibility.") > > No. Keymaps that change according to variables like this is very > confusing, both to me and to users. ("And then I press 'q', and > flargbnoze happens." "Er. Which 'q'?") Well, so much for diplomacy. :) And once we reach the letter `f' for the leading initial of the newest Gnus release (i.e., `fgnus'), I have the perfect name: Flargbnoze Gnus It has a certain ring to it, especially if none of the letters are silent ... So anyway ... how about this second attempt at diplomacy: Somewhere amidst the Gnus documentation (and perhaps on one of the www.gnus.org pages, as well), place this code snippet for easy copy-and-paste-ing ... ;; Insert this optional piece of code into your .gnus.el file for ;; TM compatibility. (add-hook 'gnus-article-mode-hook '(lambda () (gnus-define-keys gnus-article-mode-map "q" gnus-article-show-summary))) -- Lloyd Zusman ljz@asfast.com ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-12 22:17 ` Lloyd Zusman @ 1998-10-17 19:21 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-10-17 19:21 UTC (permalink / raw) Lloyd Zusman <ljz@asfast.com> writes: > Somewhere amidst the Gnus documentation (and perhaps on one of the > www.gnus.org pages, as well), place this code snippet for easy > copy-and-paste-ing ... > > ;; Insert this optional piece of code into your .gnus.el file for > ;; TM compatibility. > (add-hook 'gnus-article-mode-hook > '(lambda () > (gnus-define-keys gnus-article-mode-map > "q" gnus-article-show-summary))) It's still the same thing, only said in a different way. Some people do not use a summary buffer. For these people, having the `q' command really mean "quit" is essential. Having `q' skip back to the summary buffer (that holds no interest for them) is not a good idea. The people who really want `q' to do `h' (and know that they don't need the normal `q' meaning in the article buffer) can `local-set-key' this themselves in `gnus-article-mode-map'. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 21:24 ` Karl Kleinpaste 1998-10-11 21:41 ` Hrvoje Niksic 1998-10-12 10:08 ` Lloyd Zusman @ 1998-10-12 13:39 ` Per Abrahamsen 2 siblings, 0 replies; 115+ messages in thread From: Per Abrahamsen @ 1998-10-12 13:39 UTC (permalink / raw) Karl Kleinpaste <karl@jprc.com> writes: > People have been using TM, and > *only* TM, as "Gnus' MIME viewer" for years. Uh, I'm using metamail.el, and am quite happy with it. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 20:44 ` Hrvoje Niksic 1998-10-11 21:24 ` Karl Kleinpaste @ 1998-10-12 14:01 ` Jari Aalto+list.ding 1 sibling, 0 replies; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-10-12 14:01 UTC (permalink / raw) | 1998-10-11 Hrvoje Niksic <hniksic@srce.hr> list.ding | SL Baur <steve@xemacs.org> writes: | > | > That's exactly the point. TM has been around for a *long* time -- | > as long as Gnus 5 has been in existence. | | The phrase "backward compatibility" cannot apply here because TM has | never been a part of Gnus. People who used TM did so "on their own | responsibility". Incompatibly changing Gnus to satisfy former TM | users would IMHO be plain wrong. C'mon. You're splitting hairs here. TM has been practically the de facto standard for MIME since day 1 when it come in picture. Just like Gnus is the de facto standard for News reading. TM has supported every major MUA platform and it should be treated as respectfully as GNUS in spite of the decisions of not integrating TM into Gnus. There are lot of people that use TM with gnus and continue to do so as long as it works. I also agree with steve, that SPC/BACKSPACE should go to next/prev mime section. jari ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 19:05 ` SL Baur 1998-10-11 19:11 ` Hrvoje Niksic @ 1998-10-11 22:13 ` Kai Grossjohann 1 sibling, 0 replies; 115+ messages in thread From: Kai Grossjohann @ 1998-10-11 22:13 UTC (permalink / raw) >>>>> SL Baur <steve@xemacs.org> writes: > Hmm. Widening would make more sense. I haven't checked recently, but > the last time I entered a digest, hitting a `q' (in the *Summary* > buffer not *Article* buffer) popped the digest but didn't exit the > group. `q' exited the digest group. At least that's what `q' has done for me in a digest group, for a long time now. kai -- OOP: object oriented programming; OOPS: object oriented mistakes ^ permalink raw reply [flat|nested] 115+ messages in thread
[parent not found: <6f7ly7i16q.fsf@dna.lth.se>]
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group [not found] ` <6f7ly7i16q.fsf@dna.lth.se> @ 1998-10-11 15:41 ` Michael Harnois 1998-10-11 15:50 ` Hrvoje Niksic ` (2 more replies) 0 siblings, 3 replies; 115+ messages in thread From: Michael Harnois @ 1998-10-11 15:41 UTC (permalink / raw) Kurt Swanson <ksw@dna.lth.se> writes: > SL Baur <steve@xemacs.org> writes: > > Could `q' from inside the *Article* buffer please return to the > > *Summary* buffer the same way it did with TM? > > No. Use `h' or `='. `q' is for quitting the group. Excuse me? And who died and made you God? -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois@sbt.net aa0bt@aa0bt.ampr.org Sed quis custodiet ipsos custodes? -- Juvenal ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 15:41 ` Michael Harnois @ 1998-10-11 15:50 ` Hrvoje Niksic 1998-10-11 16:34 ` Michael Harnois [not found] ` <6fiuhrgkq1.fsf@dna.lth.se> 1998-10-11 18:28 ` Julian Assange 2 siblings, 1 reply; 115+ messages in thread From: Hrvoje Niksic @ 1998-10-11 15:50 UTC (permalink / raw) Michael Harnois <mharnois@sbt.net> writes: > Kurt Swanson <ksw@dna.lth.se> writes: > > > SL Baur <steve@xemacs.org> writes: > > > Could `q' from inside the *Article* buffer please return to the > > > *Summary* buffer the same way it did with TM? > > > > No. Use `h' or `='. `q' is for quitting the group. > > Excuse me? And who died and made you God? I will, if needs be. `q' has always exited to Group buffer, and some of us haven't even seen TM. Compatibility with Gnus should be much more important than compatibility with TM. `h' has always been there to switch to Summary. -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Try to use "ad nauseam" at least once per flame. It doesn't mean anything; but it gives that polished feel to your postings. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 15:50 ` Hrvoje Niksic @ 1998-10-11 16:34 ` Michael Harnois 0 siblings, 0 replies; 115+ messages in thread From: Michael Harnois @ 1998-10-11 16:34 UTC (permalink / raw) Cc: ding Hrvoje Niksic <hniksic@srce.hr> writes: > I will, if needs be. God? Or dead? <g> -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois@sbt.net aa0bt@aa0bt.ampr.org Sed quis custodiet ipsos custodes? -- Juvenal ^ permalink raw reply [flat|nested] 115+ messages in thread
[parent not found: <6fiuhrgkq1.fsf@dna.lth.se>]
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group [not found] ` <6fiuhrgkq1.fsf@dna.lth.se> @ 1998-10-11 16:36 ` Michael Harnois 1998-10-11 17:08 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 115+ messages in thread From: Michael Harnois @ 1998-10-11 16:36 UTC (permalink / raw) Kurt Swanson <ksw@dna.lth.se> writes: > Your asinine behaviour cannot be excused. I'm afraid you have the shoe on the wrong foot. You're the one who acted like an ass. I merely pointed it out. I'm sure that's uncomfortable for you, but the cure would be not to do it. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois@sbt.net aa0bt@aa0bt.ampr.org Sed quis custodiet ipsos custodes? -- Juvenal ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 16:36 ` Michael Harnois @ 1998-10-11 17:08 ` Lars Magne Ingebrigtsen 1998-10-11 17:35 ` Hrvoje Niksic 0 siblings, 1 reply; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-10-11 17:08 UTC (permalink / raw) Michael Harnois <mharnois@sbt.net> writes: > You're the one who acted like an ass. I'm all for flame fests -- any time, any where -- but can't it be about something a bit more important than keymaps? Like -- choice of highlighting in the Tree buffer? *Now* we're talking religious issues! -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 17:08 ` Lars Magne Ingebrigtsen @ 1998-10-11 17:35 ` Hrvoje Niksic 1998-10-11 17:57 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 115+ messages in thread From: Hrvoje Niksic @ 1998-10-11 17:35 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Michael Harnois <mharnois@sbt.net> writes: > > > You're the one who acted like an ass. > > I'm all for flame fests -- any time, any where -- but can't it be > about something a bit more important than keymaps? Like -- choice > of highlighting in the Tree buffer? *Now* we're talking religious > issues! Huh?! -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 17:35 ` Hrvoje Niksic @ 1998-10-11 17:57 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-10-11 17:57 UTC (permalink / raw) Hrvoje Niksic <hniksic@srce.hr> writes: > Huh?! S'a joke. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-11 15:41 ` Michael Harnois 1998-10-11 15:50 ` Hrvoje Niksic [not found] ` <6fiuhrgkq1.fsf@dna.lth.se> @ 1998-10-11 18:28 ` Julian Assange 2 siblings, 0 replies; 115+ messages in thread From: Julian Assange @ 1998-10-11 18:28 UTC (permalink / raw) Cc: ding Michael Harnois <mharnois@sbt.net> writes: > Kurt Swanson <ksw@dna.lth.se> writes: > > > SL Baur <steve@xemacs.org> writes: > > > Could `q' from inside the *Article* buffer please return to the > > > *Summary* buffer the same way it did with TM? > > > > No. Use `h' or `='. `q' is for quitting the group. > > Excuse me? And who died and made you God? Nietzsche? Julian. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Patch: be verbose if POP3 setup is not ok @ 1998-09-08 16:08 Jari Aalto+list.ding 0 siblings, 0 replies; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-09-08 16:08 UTC (permalink / raw) Hi, I'm currently trying to get my 2 POP3 acocunts integrated with gnus and in the process I thought this would be nicer message to user than just an cryptic error. Patch is against pgnus 0.13 jari --- nnmail.el.orig-p0.13 Tue Sep 8 18:51:35 1998 +++ nnmail.el Tue Sep 8 19:04:48 1998 @@ -629,6 +629,17 @@ (set-buffer errors) (insert (prin1-to-string err)) (setq result 255)))) + ;; expand-file-name below breaks if we don't check this. + (unless (stringp nnmail-movemail-program) + (with-output-to-temp-buffer "*Gnus Error*" + (princ + (message + (concat "Your nnmail-movemail-program must be string " + "or callable lisp function. \nPlease check " + "your setup. Value was [%s]") + (prin1-to-string nnmail-movemail-program)))) + (error "Gnus: Error, Check nnmail-movemail-program")) (let ((default-directory "/")) (setq result (apply ^ permalink raw reply [flat|nested] 115+ messages in thread
* Suggestion: to problem nndraft "Can't select group" @ 1998-09-03 15:57 Jari Aalto+list.ding 1998-09-03 17:10 ` David S. Goldberg 0 siblings, 1 reply; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-09-03 15:57 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 623 bytes --] Hi, I posted before question why I couldn't select nndraft group which did contain articles if I looked into directory. The server was open, the path was okay, but still I got message Can't select group After lot of Edebugging, i found out that I was missing entry (display . all) from the Group parameters. After I put it there, the articles were read and I could access nndraft. I think it would be good idea to add that group parameter by default in the nndraft groups so that user don't get confused about the misleding "Can't select group" message. jari [-- Attachment #2: Type: text/plain, Size: 1885 bytes --] THE INITIAL SITUATION (gnus-select-newsgroup "nndraft:drafts" t) gnus-articles-to-read --> Can't select group gnus-select-newsgroup called gnus-articles-to-read but it didn't find anything. cond statement in gnus-articles-to-read triggered 0, thus returning nil back, and hence error message (defun gnus-select-newsgroup (group &optional read-all select-articles) ;; Adjust and set lists of article marks. (when info (gnus-adjust-marked-articles info)) info --> ("nndraft:drafts" 1 nil nil (nndraft "") ((timestamp 13711 39412) (expiry-wait . 5) (total-expire . t) (gnus-dummy (gnus-draft-mode)))) (if (setq articles select-articles) (setq gnus-newsgroup-unselected (gnus-sorted-intersection gnus-newsgroup-unreads (gnus-sorted-complement gnus-newsgroup-unreads articles))) (setq articles (gnus-articles-to-read group read-all))) (if (setq articles select-articles) --> nil (setq articles (gnus-articles-to-read group read-all))) --> 0 and later the cond statement in gnus-select-newsgroup ((eq articles 0) nil) (defun gnus-articles-to-read (group &optional read-all) ;; Find out what articles the user wants to read. (let* ((articles ;; Select all articles if `read-all' is non-nil, or if there ;; are no unread articles. (if (or read-all (and (zerop (length gnus-newsgroup-marked)) --> '(19) (zerop (length gnus-newsgroup-unreads))) --> nil articles --> nil AFTER I PUT (display . all) TO GROUP PARAMETER info --> ("nndraft:drafts" 1 ((1 . 133) 135 (137 . 140) (142 . 143) (145 . 155) (157 . 163) (165 . 170)) nil (nndraft "") ((timestamp 13806 46863) (expiry-wait . 5) (total-expire . t) (gnus-dummy (gnus-draft-mode)))) ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Suggestion: to problem nndraft "Can't select group" 1998-09-03 15:57 Suggestion: to problem nndraft "Can't select group" Jari Aalto+list.ding @ 1998-09-03 17:10 ` David S. Goldberg 1998-09-03 17:31 ` Jari Aalto+list.ding 0 siblings, 1 reply; 115+ messages in thread From: David S. Goldberg @ 1998-09-03 17:10 UTC (permalink / raw) Cc: Ding mailing list I have no idea what you may be doing wrong, but (display . all) isn't it. I do not have (display . all) set for my nndraft group and have no trouble with it whatsoever. I even tested it by saving this message with message-dont-send, going into the draft group (there it was as expected), then doing a catchup and selecting it again from the *Group* buffer. I got into the group as expected and ran D e and in a couple of seconds I will send it out. -- Dave Goldberg Post: The Mitre Corporation\MS B305\202 Burlington Rd.\Bedford, MA 01730 Phone: 781-271-3887 Email: dsg@mitre.org ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Suggestion: to problem nndraft "Can't select group" 1998-09-03 17:10 ` David S. Goldberg @ 1998-09-03 17:31 ` Jari Aalto+list.ding 0 siblings, 0 replies; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-09-03 17:31 UTC (permalink / raw) | 1998-09-03 dsg@mitre.org (David S. Goldberg) list.ding | I have no idea what you may be doing wrong, but (display . all) isn't | it. I do not have (display . all) set for my nndraft group and have | no trouble with it whatsoever. I even tested it by saving this | message with message-dont-send, going into the draft group (there it | was as expected), then doing a catchup and selecting it again from the | *Group* buffer. I got into the group as expected and ran D e and in a | couple of seconds I will send it out. I can't be absolutely positive what was the problem, because I ran Edebug 2 hours and added lot of test code inside functions it it used. All just suddendly working after I added (display . all), because then it triggered following function to find my lost nndraft afticles. I think adding that parameter by default in nndraft is goo idea to prevent any similar event happening. My situation was different than yours: I hadn't have working nndraft for months, so I couldn't just "remove" or "add" that display property to see if it changed anything. (defun gnus-articles-to-read (group &optional read-all) ;; Find out what articles the user wants to read. (let* ((articles ;; Select all articles if `read-all' is non-nil, or if there ;; are no unread articles. (if (or read-all (and (zerop (length gnus-newsgroup-marked)) (zerop (length gnus-newsgroup-unreads))) (eq (gnus-group-find-parameter group 'display) 'all)) | | This Side note: (do not be concerned, I'll investigate this first) I'm wondering why nndraft-request-group keeps at value 'ignore, due to statement: (eval-when-compile (require 'cl) ;; This is just to shut up the byte-compiler. (fset 'nndraft-request-group 'ignore)) While the nnoo-import at the end of nndraft.el should wipe it away. It doesn't do that for me for some very mysterious reason. I'll take a look at it next time I boot Gnus down and up. jari ^ permalink raw reply [flat|nested] 115+ messages in thread
* Hallvard's gnus-e20/19.34/Pgnus 0.13 emulation (backtrace included)
@ 1998-09-02 13:26 Jari Aalto+list.ding
0 siblings, 0 replies; 115+ messages in thread
From: Jari Aalto+list.ding @ 1998-09-02 13:26 UTC (permalink / raw)
I'm having great success running Pgnus with 19.34, but then I hit this.
(Thanks Hallvard's for gnus-e20.el)
(gnus-version)"Pterodactyl Gnus v0.13
Does string-to-number take new parameter in Emacs 20.x ? Anyone
care to post the emulation function?
jari
qp.el
(defun quoted-printable-decode-region (from to)
"Decode quoted-printable in the region between FROM and TO."
(interactive "r")
(save-excursion
(goto-char from)
(while (search-forward "=" to t)
(cond ((eq (following-char) ?\n)
(delete-char -1)
(delete-char 1))
((and
(memq (following-char) quoted-printable-encoding-characters)
(memq (char-after (1+ (point)))
quoted-printable-encoding-characters))
(subst-char-in-region
(1- (point)) (point) ?=
(string-to-number
(buffer-substring (point) (+ 2 (point)))
>> 16))
(delete-char 2))
((looking-at "=")
(delete-char 1))
((message "Malformed MIME quoted-printable message"))))))
Signaling: (wrong-number-of-arguments #<subr string-to-number> 2)
(string-to-number (buffer-substring (point) (+ 2 ...)) 16)
(subst-char-in-region (1- (point)) (point) 61 (string-to-number (buffer-substring ... ...) 16))
(cond ((eq ... 10) (delete-char -1) (delete-char 1)) ((and ... ...) (subst-char-in-region ... ... 61 ...) (delete-char 2)) ((looking-at "=") (delete-char 1)) ((message "Malformed MIME quoted-printable message")))
(while (search-forward "=" to t) (cond (... ... ...) (... ... ...) (... ...) (...)))
(save-excursion (goto-char from) (while (search-forward "=" to t) (cond ... ... ... ...)))
quoted-printable-decode-region(2316 2573)
(progn (goto-char (point-min)) (search-forward "\n\n" nil (quote move)) (quoted-printable-decode-region (point) (point-max)))
(if (or force (and type ...)) (progn (goto-char ...) (search-forward "\n\n" nil ...) (quoted-printable-decode-region ... ...)))
(when (or force (and type ...)) (goto-char (point-min)) (search-forward "\n\n" nil (quote move)) (quoted-printable-decode-region (point) (point-max)))
(let ((buffer-read-only nil) (type ...)) (gnus-article-decode-rfc1522) (when (or force ...) (goto-char ...) (search-forward "\n\n" nil ...) (quoted-printable-decode-region ... ...)))
(save-excursion (let (... ...) (gnus-article-decode-rfc1522) (when ... ... ... ...)))
article-de-quoted-unreadable()
apply(article-de-quoted-unreadable nil)
(if interactive (call-interactively (quote article-de-quoted-unreadable)) (apply (quote article-de-quoted-unreadable) args))
(save-excursion (set-buffer gnus-article-buffer) (if interactive (call-interactively ...) (apply ... args)))
gnus-article-de-quoted-unreadable()
(progn (when (boundp ...) (cond ... ...)) (gnus-article-de-quoted-unreadable) (if (fboundp ...) (gnus-article-strip-multiple-blank-lines)) (gnus-article-hide-citation-maybe nil) (gnus-article-hide-signature nil) (when (string-match "nntp" gnus-newsgroup-name) (gnus-article-hide-headers nil)) (when (re-search-check "PGP ") (if ... ... ...)) (my-gnus-article-url) (when (fboundp ...) (gnus-article-date-user)) (when my-:window-system) (when (string-match "XEmacs" emacs-version)) (when (fboundp ...)) (when (and ... ...) (let ... ...)))
(if (buffer-live-p (get-buffer gnus-article-buffer)) (progn (when ... ...) (gnus-article-de-quoted-unreadable) (if ... ...) (gnus-article-hide-citation-maybe nil) (gnus-article-hide-signature nil) (when ... ...) (when ... ...) (my-gnus-article-url) (when ... ...) (when my-:window-system) (when ...) (when ...) (when ... ...)))
(when (buffer-live-p (get-buffer gnus-article-buffer)) (when (boundp ...) (cond ... ...)) (gnus-article-de-quoted-unreadable) (if (fboundp ...) (gnus-article-strip-multiple-blank-lines)) (gnus-article-hide-citation-maybe nil) (gnus-article-hide-signature nil) (when (string-match "nntp" gnus-newsgroup-name) (gnus-article-hide-headers nil)) (when (re-search-check "PGP ") (if ... ... ...)) (my-gnus-article-url) (when (fboundp ...) (gnus-article-date-user)) (when my-:window-system) (when (string-match "XEmacs" emacs-version)) (when (fboundp ...)) (when (and ... ...) (let ... ...)))
my-gnus-article-display-hook-list()
run-hooks(gnus-article-display-hook)
apply(run-hooks gnus-article-display-hook)
(unwind-protect (apply (quote run-hooks) funcs) (set-buffer buf))
(let ((buf ...)) (unwind-protect (apply ... funcs) (set-buffer buf)))
gnus-run-hooks(gnus-article-display-hook)
(let (buffer-read-only) (gnus-run-hooks (quote gnus-tmp-internal-hook)) (gnus-run-hooks (quote gnus-article-prepare-hook)) (when gnus-show-mime (if ... ... ...)) (gnus-run-hooks (quote gnus-article-display-hook)))
(progn (let (buffer-read-only) (gnus-run-hooks ...) (gnus-run-hooks ...) (when gnus-show-mime ...) (gnus-run-hooks ...)) (goto-char (point-min)) (setq gnus-page-broken (when gnus-break-pages ... t)))
(if (or (numberp article) (stringp article)) (progn (let ... ... ... ... ...) (goto-char ...) (setq gnus-page-broken ...)))
(when (or (numberp article) (stringp article)) (let (buffer-read-only) (gnus-run-hooks ...) (gnus-run-hooks ...) (when gnus-show-mime ...) (gnus-run-hooks ...)) (goto-char (point-min)) (setq gnus-page-broken (when gnus-break-pages ... t)))
(if (or (eq result ...) (eq result ...)) (progn (save-excursion ... ... ... ... ...) (gnus-set-mode-line ...)) (when (and ... ...) (save-excursion ... ... ... ... ... ... ... ... ... ... ...)) (when (or ... ...) (let ... ... ... ... ...) (goto-char ...) (setq gnus-page-broken ...)) (gnus-set-mode-line (quote article)) (gnus-configure-windows (quote article)) (goto-char (point-min)) (search-forward "\n\n" nil t) (set-window-point (get-buffer-window ...) (point)) t)
(if (not (setq result ...)) (save-excursion (when ... ... ... ... ...)) (if (or ... ...) (progn ... ...) (when ... ...) (when ... ... ... ...) (gnus-set-mode-line ...) (gnus-configure-windows ...) (goto-char ...) (search-forward "\n\n" nil t) (set-window-point ... ...) t))
(save-excursion (gnus-article-setup-buffer) (set-buffer gnus-article-buffer) (when (and ... transient-mark-mode) (setq mark-active nil)) (if (not ...) (save-excursion ...) (if ... ... ... ... ... ... ... ... ... t)))
(let* ((gnus-article ...) (summary-buffer ...) (gnus-tmp-internal-hook gnus-article-internal-prepare-hook) (group gnus-newsgroup-name) result) (save-excursion (gnus-article-setup-buffer) (set-buffer gnus-article-buffer) (when ... ...) (if ... ... ...)))
(save-excursion (unless (eq major-mode ...) (set-buffer gnus-summary-buffer)) (setq gnus-summary-buffer (current-buffer)) (let* (... ... ... ... result) (save-excursion ... ... ... ...)))
gnus-article-prepare(5592 nil)
(if gnus-summary-display-article-function (funcall gnus-summary-display-article-function article all-header) (gnus-article-prepare article all-header))
(prog1 (if gnus-summary-display-article-function (funcall gnus-summary-display-article-function article all-header) (gnus-article-prepare article all-header)) (gnus-run-hooks (quote gnus-select-article-hook)) (when (and gnus-current-article ...) (gnus-summary-goto-subject gnus-current-article)) (gnus-summary-recenter) (when (and gnus-use-trees gnus-show-threads) (gnus-possibly-generate-tree article) (gnus-highlight-selected-tree article)) (gnus-article-set-window-start (cdr ...)))
(if (null article) nil (prog1 (if gnus-summary-display-article-function ... ...) (gnus-run-hooks ...) (when ... ...) (gnus-summary-recenter) (when ... ... ...) (gnus-article-set-window-start ...)))
gnus-summary-display-article(5592)
(or (gnus-summary-display-article (gnus-summary-article-number)) (eq (gnus-summary-article-mark) gnus-canceled-mark))
(and (gnus-summary-search-forward unread subject backward) (or (gnus-summary-display-article ...) (eq ... gnus-canceled-mark)))
(cond ((and ... ...) (gnus-summary-position-point)) ((and subject gnus-auto-select-same ...) (gnus-summary-position-point) (gnus-message 6 "Wrapped")) ((and gnus-auto-extend-newsgroup ... ...) (gnus-summary-goto-article ... nil ...)) (t (unless ... ...) (let ... ... ...)))
gnus-summary-next-article(nil)
* call-interactively(gnus-summary-next-article)
^ permalink raw reply [flat|nested] 115+ messages in thread
* Suggestion: Topic mode get news and topic group indentation level @ 1998-08-24 22:12 Jari Aalto+list.ding 0 siblings, 0 replies; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-08-24 22:12 UTC (permalink / raw) I know that topics don't actually "nest", but would it be possible. I would find it neat to Hit M-g at topmost topic level and get all subtopics read in. Main-Topic <-- Hit M-g and get Topic1, Topic2 read? Sub-Topic1 Sub-Topic2 I guess that would be matter of looping through topics that have indentation level ++ compared to current topic indentation level. jari ^ permalink raw reply [flat|nested] 115+ messages in thread
* patch: 5.6.38 gnus-uu, new regexp marking commands @ 1998-08-22 15:12 Jari Aalto+list.ding 0 siblings, 0 replies; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-08-22 15:12 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 830 bytes --] Hi, A day ago I subscribed to handfull of new mailing lists and when I was away last night my procmail recipes sorted them to wrong folders. so I had to move lot of mail from group to another. The first command that come into my mind was gnus-uu-mark-by-regexp But it only matched subjects. I assumed it would match the visible Summary line, but it didn't :-). There was nothing in common in the subject lines that come from eg liserv XXX. However If I matched against From field, then I could tag all the messages coming from particular list and move then all to right group. Here is the new functions that do that: They un/mark articles that match From field. The patch is against 5.6.38. Feel free to move the new keybinds to somewhere more appropriate. jari [-- Attachment #2: Type: text/plain, Size: 639 bytes --] Sat Aug 22 17:56:04 1998 Jari Aalto <jari.aalto@poboxes.com> * gnus-uu.el ((gnus-uu-mark-map "P" gnus-summary-mark-map)): Added commands "f" gnus-uu-mark-by-from-regexp "F" gnus-uu-unmark-by-from-regexp (gnus-uu-mark-by-from-regexp): New user function. (gnus-uu-find-articles-matching): Added anew arg `data-flag' Which may have other uses in the future. Curretly if flag is set to non-nil, the matching list is generated by looking at `from' fields. If flag is nil, then list is generated by looking at `subject'. (gnus-uu-find-articles-matching): variable changes `list-of-subjects' --> `list' and `subject' --> `string' [-- Attachment #3: gnus-uu.el.diff --] [-- Type: text/plain, Size: 3108 bytes --] Prereq: 1.1 =================================================================== RCS file: RCS/gnus-uu.el,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- 1.1 1998/08/22 14:53:26 +++ 1.2 1998/08/22 15:01:27 @@ -356,6 +356,8 @@ "g" gnus-uu-unmark-region "R" gnus-uu-mark-by-regexp "G" gnus-uu-unmark-by-regexp + "f" gnus-uu-mark-by-from-regexp + "F" gnus-uu-unmark-by-from-regexp "t" gnus-uu-mark-thread "T" gnus-uu-unmark-thread "a" gnus-uu-mark-all @@ -578,6 +580,25 @@ (interactive (list (read-from-minibuffer "Mark (regexp): "))) (gnus-uu-mark-by-regexp regexp t)) + +(defun gnus-uu-mark-by-from-regexp (regexp &optional unmark) + "Ask for a regular expression and set the process mark on all articles that match `From'." + (interactive (list (read-from-minibuffer "Mark (From regexp): "))) + (let ((articles (gnus-uu-find-articles-matching regexp nil nil 'from))) + (while articles + (if unmark + (gnus-summary-remove-process-mark (pop articles)) + (gnus-summary-set-process-mark (pop articles)))) + (message "")) + (gnus-summary-position-point)) + + +(defun gnus-uu-unmark-by-from-regexp (regexp &optional unmark) + "Ask for a regular expression and remove the process mark on all articles that match `from' ." + (interactive (list (read-from-minibuffer "Mark (regexp): "))) + (gnus-uu-mark-by-from-regexp regexp t)) + + (defun gnus-uu-mark-series () "Mark the current series with the process mark." (interactive) @@ -1081,14 +1102,19 @@ (string< (car l1) (car l2))) (defun gnus-uu-find-articles-matching - (&optional subject only-unread do-not-translate) + (&optional subject only-unread do-not-translate data-flag) ;; Finds all articles that matches the regexp SUBJECT. If it is ;; nil, the current article name will be used. If ONLY-UNREAD is ;; non-nil, only unread articles are chosen. If DO-NOT-TRANSLATE is ;; non-nil, article names are not equalized before sorting. + ;; + ;; If DATA-FLAG is non-nil, match `from' gnus-data instead of `subject' (let ((subject (or subject (gnus-uu-reginize-string (gnus-summary-article-subject)))) - list-of-subjects) + list + from + string + ) (save-excursion (if (not subject) () @@ -1104,16 +1130,21 @@ gnus-unread-mark) (= mark gnus-ticked-mark) (= mark gnus-dormant-mark)) - (setq subj (mail-header-subject (gnus-data-header d))) - (string-match subject subj) - (push (cons subj (gnus-data-number d)) - list-of-subjects)))) + (cond + ((null data-flag) + (setq string (mail-header-subject (gnus-data-header d))) + (string-match subject string)) + (t + (setq string (mail-header-from (gnus-data-header d))) + (string-match subject string))) + (push (cons string (gnus-data-number d)) + list)))) ;; Expand numbers, sort, and return the list of article ;; numbers. (mapcar (lambda (sub) (cdr sub)) (sort (gnus-uu-expand-numbers - list-of-subjects + list (not do-not-translate)) 'gnus-uu-string<)))))) ^ permalink raw reply [flat|nested] 115+ messages in thread
* Suggestion: *Group* SPC to show only new articles? @ 1998-08-21 15:49 Jari Aalto+list.ding 0 siblings, 0 replies; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-08-21 15:49 UTC (permalink / raw) Would it be possible to add eg. new symbolic prefix argument to SPC key that is used to enter a group (I'm using topic mode) gnus-topic-read-group So that gnus would show only newly arrived articles. Now I manually Hit the count of the arrived articles to see what's new in there: Eg. if 2 messages has arrived, I can browse the group lighting fast with: M-2 gnus-topic-read-group But it's pain to enter different number for each group. jari ^ permalink raw reply [flat|nested] 115+ messages in thread
* pop3 reading with gnus? @ 1998-08-21 9:35 jari.aalto 1998-08-21 9:56 ` Jean-Yves Perrier 0 siblings, 1 reply; 115+ messages in thread From: jari.aalto @ 1998-08-21 9:35 UTC (permalink / raw) Hi, Does anyone have pointers to set up Gnus for POP3 mailboxes in remoe sites? jari ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: pop3 reading with gnus? 1998-08-21 9:35 pop3 reading with gnus? jari.aalto @ 1998-08-21 9:56 ` Jean-Yves Perrier 1998-08-21 10:09 ` Jari Aalto+list.ding 0 siblings, 1 reply; 115+ messages in thread From: Jean-Yves Perrier @ 1998-08-21 9:56 UTC (permalink / raw) Cc: jari.aalto <jari.aalto@poboxes.com> writes: > Hi, > > Does anyone have pointers to set up Gnus for POP3 mailboxes > in remoe sites? > > jari This is what I have in .gnus: ;; Needed for sending mail (message-mode): use SMTP (load-library "message") (setq message-send-mail-function 'smtpmail-send-it) (require 'messcompat) ;; Read mail from popserver (setenv "MAILHOST" "mailhost.mycompany.ch") ;; my remote pop mail serveur: configure it.... (setq nnmail-spool-file "po:perrier") ;; my account po:<username> (setq nnmail-movemail-program 'nnmail-pop3-movemail) ;; Use gnus to read mail, too (setq gnus-secondary-select-methods '((nnml ""))) More info can be found in the gnus FAQ and nt-emacs FAQ. Regards, -- Jean-Yves Perrier ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: pop3 reading with gnus? 1998-08-21 9:56 ` Jean-Yves Perrier @ 1998-08-21 10:09 ` Jari Aalto+list.ding 0 siblings, 0 replies; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-08-21 10:09 UTC (permalink / raw) | 1998-08-21 Jean-Yves Perrier <perrier@nagra-kudelski.ch> list.ding | <jari.aalto@poboxes.com> writes: | | > Hi, | > | > Does anyone have pointers to set up Gnus for POP3 mailboxes | > in remoe sites? | > | > jari | | This is what I have in .gnus: | | ;; Needed for sending mail (message-mode): use SMTP | (load-library "message") | (setq message-send-mail-function 'smtpmail-send-it) | (require 'messcompat) | | ;; Read mail from popserver | (setenv "MAILHOST" "mailhost.mycompany.ch") ;; my remote pop mail serveur: configure it.... | (setq nnmail-spool-file "po:perrier") ;; my account po:<username> | (setq nnmail-movemail-program 'nnmail-pop3-movemail) | | ;; Use gnus to read mail, too | (setq gnus-secondary-select-methods | '((nnml ""))) Thank you, but I assume this is for one POP3 mailbox reading only. I have 2 remote pop3 mailboxes in different servers and one local mailbox where I'm 99% of the time. so I'd like to add those remote fileboxes behind a gnus pop3 server, but I'm not quite sure how it is done. My first impression after looking at the pop3 varaibles in the manual was that I create nnml server:tpu Which has entries (nnml "tpu" (nnmail-pop-password "cencored") (nnmail-pop-password-required t) (pop3-mailhost "mail.cs.tpu.fi") (nnmail-spool-file "po:jaalto")) Then I created Gnus group nnml "tpu" by using that server, but somehow the movemail program want to look under local disk 'po:jaalto' What's the correct way to define multiple pop3 servers and use them? My primary local mail delivery method is procmail nnmail-use-procmail t nnmail-procmail-directory (concat nnfolder-directory "/spool") nnmail-spool-file 'procmail gnus-secondary-select-methods's value is ((nnml "")) gnus-secondary-servers's value is nil jari ^ permalink raw reply [flat|nested] 115+ messages in thread
* 5.6.38 Can't read drafts server? @ 1998-08-20 20:29 Jari Aalto+list.ding 0 siblings, 0 replies; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-08-20 20:29 UTC (permalink / raw) Gnus denies access to drafts grou when I press SPC. What should I check? jari Group buffer: [1] 0 *: nndraft:queue 0 [1] 0 *: nndraft:drafts 0 Messages when pressing SPC: nndraft:queue error: Opened server using directory /users/jaalto/News/drafts/ nndraft:drafts error: Opened server using directory /users/jaalto/News/drafts/ Directory: creator gnus ls -la /users/jaalto/News/drafts/ total 10 drwxr-xr-x 4 jaalto nms 96 May 7 15:27 . drwxr-xr-x 6 jaalto nms 4096 May 26 19:10 .. drwxr-xr-x 2 jaalto nms 1024 Aug 20 23:26 drafts drwxr-xr-x 2 jaalto nms 96 May 7 15:27 queue creator gnus ls -la /users/jaalto/News/drafts/drafts/ total 134 -rw-r--r-- 1 jaalto nms 9083 Aug 19 21:03 #68# -rw-r--r-- 1 jaalto nms 727 Aug 20 23:28 #87# drwxr-xr-x 2 jaalto nms 1024 Aug 20 23:26 . drwxr-xr-x 4 jaalto nms 96 May 7 15:27 .. -rw-r--r-- 1 jaalto nms 964 May 7 15:27 10~ -rw-r--r-- 1 jaalto nms 14507 Jun 23 15:05 50 -rw-r--r-- 1 jaalto nms 11171 Jun 24 16:29 52 -rw-r--r-- 1 jaalto nms 10793 Jun 24 16:29 53 -rw-r--r-- 1 jaalto nms 9077 Aug 19 21:04 68 -rw-r--r-- 1 jaalto nms 7597 Aug 19 22:22 77 -rw-r--r-- 1 jaalto nms 71 Aug 20 23:16 86 creator gnus ls -la /users/jaalto/News/drafts/queue/ total 0 drwxr-xr-x 2 jaalto nms 96 May 7 15:27 . drwxr-xr-x 4 jaalto nms 96 May 7 15:27 .. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Suggestion: Command to rename all Subejcts in thread @ 1998-08-19 15:57 Jari Aalto+list.ding 0 siblings, 0 replies; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-08-19 15:57 UTC (permalink / raw) Hi, As email is the primary communication channel to customers, our support persons and to lab people, it's very usual that people send Subjects that don't tell much. Eg: Subject: Process won't stay up Then several people take into part the discussion, but the subject stays the same. I would like to see a command in Summary buffer where I could stand at the top of thread and appply "Change ann messages' Subject in this theread to...." So that I can write something that better describes the problem beeing discussed, like adding system version, customer code, process name etc. It also happens that I move several messages under one thread, because they are talking about the same thing, so the Subject rename command would be of assis here too. No I see different subjects under same thread where I have moved them. Pretty, Please Lars, Any chance to see that command in near future? jari ^ permalink raw reply [flat|nested] 115+ messages in thread
* Master or slave?? @ 1998-08-17 9:04 Andy Eskilsson [not found] ` <6flnooezsi.fsf@bavur.dna.lth.se> 0 siblings, 1 reply; 115+ messages in thread From: Andy Eskilsson @ 1998-08-17 9:04 UTC (permalink / raw) As the careful person I am I want to know if it is the 'master' GNUS I am getting in touch with, or the slave.. I am afraid of the whips and leather.. Are there any good way to determine which of the gnusae that are running in my emacs? /andy ^ permalink raw reply [flat|nested] 115+ messages in thread
[parent not found: <6flnooezsi.fsf@bavur.dna.lth.se>]
* Re: Master or slave?? [not found] ` <6flnooezsi.fsf@bavur.dna.lth.se> @ 1998-08-17 11:27 ` Jari Aalto+list.ding 1998-08-17 14:44 ` Andy Eskilsson 0 siblings, 1 reply; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-08-17 11:27 UTC (permalink / raw) |Mon 1998-08-17 Kurt Swanson <ksw@dna.lth.se> list.ding | Andy Eskilsson <andy.eskilsson@telelogic.se> writes: | > As the careful person I am I want to know if it is the 'master' GNUS I | > am getting in touch with, or the slave.. I am afraid of the whips and | > leather.. | | > Are there any good way to determine which of the gnusae that are | > running in my emacs? | | C-h v gnus-slave RET Could we get this displayed in the Group modeline by default? Eg. string "Slave" after "Plugged" jari ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Master or slave?? 1998-08-17 11:27 ` Jari Aalto+list.ding @ 1998-08-17 14:44 ` Andy Eskilsson 0 siblings, 0 replies; 115+ messages in thread From: Andy Eskilsson @ 1998-08-17 14:44 UTC (permalink / raw) / <jari.aalto@poboxes.com> (Jari Aalto+list.ding) wrote: | | Could we get this displayed in the Group modeline by default? | Eg. string "Slave" after "Plugged" I am still waiting for the 'Master' gnus-splash screen containing a Gnu with a whip, and the 'Slave' splash-screen with a Gnu in chains.. or something similar.. /andy ^ permalink raw reply [flat|nested] 115+ messages in thread
* request: commands for subsribe/unsubsribe from/to mailing lists @ 1998-08-13 14:39 Jari Aalto+list.ding [not found] ` <jari.aalto@poboxes.com> 0 siblings, 1 reply; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-08-13 14:39 UTC (permalink / raw) Hi, I just got back from vacation and noticed that my forwarding service had had troubles. I'm subsribed to several lists and most of the MLM managers that run the lists had sent me probes to determine that my address was not alive any more and terminated the list subsribtion. It was kinda annoying to recall from old messages what were the exact conditions and addresses to re-subscribe back to the lists. Would if be possible to have 2 new commands to summary buffer which would: - unsubsribe from mailing list (eg. when taking a long leave) - subsribe to mailing list I'm assuming that Group parameter had entry defining how to subsribe to the list by telling what are the header/body values and to which address the request should be sent. Something like (subscribe (from . "<jari.aalto@poboxes.com>") (to . "<LISTSERV@peach.ease.lsoft.com>") (body "subscribe SPAM-L Jari Aalto")) And something similar for unsubscribe. jari ^ permalink raw reply [flat|nested] 115+ messages in thread
[parent not found: <jari.aalto@poboxes.com>]
* Re: request: commands for subsribe/unsubsribe from/to mailing lists [not found] ` <jari.aalto@poboxes.com> @ 1998-08-13 16:35 ` Jason L Tibbitts III 1998-08-13 16:56 ` Lars Magne Ingebrigtsen 1998-08-13 16:41 ` Lars Magne Ingebrigtsen ` (22 subsequent siblings) 23 siblings, 1 reply; 115+ messages in thread From: Jason L Tibbitts III @ 1998-08-13 16:35 UTC (permalink / raw) >>>>> "JA" == <jari.aalto@poboxes.com> writes: JA> I'm assuming that Group parameter had entry defining how to zubsribe to JA> the list by telling what are the header/body values and to which JA> address the request should be sent. Actually there is an RFC detailing a set of headers used to communicate this information. That would be RFC2369. What it comes down to is that all/some/periodic messages from a list can include headers with instructions on dealing with the list server, and messages can include a unique identifier that designates messages from the list even if the server moves. The MUA is supposed to save the instructions in the headers and use them when presenting the user with some list manipulation functionality. Note that this RFC is pretty new and I'm pretty lame, so this list does not yet implement these headers. If someone feels like working on this stuff in Gnus, I'll be happy to set the list server up to give you something to test. - J< ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: request: commands for subsribe/unsubsribe from/to mailing lists 1998-08-13 16:35 ` Jason L Tibbitts III @ 1998-08-13 16:56 ` Lars Magne Ingebrigtsen 1998-08-13 18:27 ` William M. Perry 0 siblings, 1 reply; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-08-13 16:56 UTC (permalink / raw) Jason L Tibbitts III <tibbs@hpc.uh.edu> writes: > Actually there is an RFC detailing a set of headers used to communicate > this information. That would be RFC2369. Hm. Well, RFC2369 would work, I guess. What they do is define a slew of new headers that contains URL(s). Like: List-Subscribe: <mailto:list@host.com?subject=subscribe> Eh. Well, why not? Doesn't everyone read mail with a web browser? Huh? Anyway. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: request: commands for subsribe/unsubsribe from/to mailing lists 1998-08-13 16:56 ` Lars Magne Ingebrigtsen @ 1998-08-13 18:27 ` William M. Perry 1998-08-19 17:30 ` Christopher Davis 0 siblings, 1 reply; 115+ messages in thread From: William M. Perry @ 1998-08-13 18:27 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Jason L Tibbitts III <tibbs@hpc.uh.edu> writes: > > > Actually there is an RFC detailing a set of headers used to communicate > > this information. That would be RFC2369. > > Hm. Well, RFC2369 would work, I guess. What they do is define a slew > of new headers that contains URL(s). Like: > > List-Subscribe: <mailto:list@host.com?subject=subscribe> > > Eh. Well, why not? Doesn't everyone read mail with a web browser? > Huh? > > Anyway. how absolutely #!%@!ing worthless. I really yearn for the good old days. I remember when chris wilson and I were floored in July '94 by the fact that some airplane flying around seattle's big fourth of july pary area had a URL on it. We laughed that nobody would know what it was... Ahhh, if only. :) -Bill P. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: request: commands for subsribe/unsubsribe from/to mailing lists 1998-08-13 18:27 ` William M. Perry @ 1998-08-19 17:30 ` Christopher Davis 0 siblings, 0 replies; 115+ messages in thread From: Christopher Davis @ 1998-08-19 17:30 UTC (permalink / raw) WMP> == William M Perry <wmperry@aventail.com> WMP> how absolutely #!%@!ing worthless. I really yearn for the good WMP> old days. I remember when chris wilson and I were floored in July WMP> '94 by the fact that some airplane flying around seattle's big WMP> fourth of july pary area had a URL on it. We laughed that nobody WMP> would know what it was... I walked to work this morning past a construction site. They had one of those portable chemical toilets (you know, plastic, looks sort of like a really cheap TARDIS) next to the gate. The sign on the side of the toilet gave the name of the company it was rented from, their 800 number, AND THEIR URL. I kid you not. Naturally I visited their web site <URL:http://www.handyhouse.com/>. They provided service for Pope John Paul II's visit to New England! They have a FAQ! They have pictures of their product line! We're doomed, doomed I say. (Obding: so, maybe that's an idea for the next Gnus promotional item?) ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: request: commands for subsribe/unsubsribe from/to mailing lists [not found] ` <jari.aalto@poboxes.com> 1998-08-13 16:35 ` Jason L Tibbitts III @ 1998-08-13 16:41 ` Lars Magne Ingebrigtsen 1998-08-13 17:21 ` Bud Rogers 1998-08-17 13:06 ` Master or slave?? Lars Magne Ingebrigtsen ` (21 subsequent siblings) 23 siblings, 1 reply; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-08-13 16:41 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > Would if be possible to have 2 new commands to summary buffer which would: > > - unsubsribe from mailing list (eg. when taking a long leave) > - subsribe to mailing list > > I'm assuming that Group parameter had entry defining how to > subsribe to the list by telling what are the header/body values and > to which address the request should be sent. Something like > > (subscribe > (from . "<jari.aalto@poboxes.com>") > (to . "<LISTSERV@peach.ease.lsoft.com>") > (body "subscribe SPAM-L Jari Aalto")) > > And something similar for unsubscribe. I've added this to the todo list. But there should be commands to create these group params automatically. I envision putting point over the address of the list and typing `M-x gnus-add-mailing-list', which would then ask (and/or guess) what type of mailing list it is (LISTSERV, Majordomo, etc.) and then prompt away, giving reasonable defaults, and then adding this to the params. Anyone want to implement this? You'd have to know the un/subscription rules for most major mailing list software. Hm. Perhaps commands for un/suspending lists would also be nice? -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: request: commands for subsribe/unsubsribe from/to mailing lists 1998-08-13 16:41 ` Lars Magne Ingebrigtsen @ 1998-08-13 17:21 ` Bud Rogers 0 siblings, 0 replies; 115+ messages in thread From: Bud Rogers @ 1998-08-13 17:21 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > I've added this to the todo list. But there should be commands to > create these group params automatically. > > I envision putting point over the address of the list and typing `M-x > gnus-add-mailing-list', which would then ask (and/or guess) what type > of mailing list it is (LISTSERV, Majordomo, etc.) and then prompt > away, giving reasonable defaults, and then adding this to the params. Oh, that would be so nice. I'm just going through the great change of address battle. Some of list software is positively obtuse. Moderately easy to subscribe to, moderately difficult to unsubscribe from, and totally frustrating to change to a new address, especially when you've already moved. There's a pizza in this, my treat. -- Bud Rogers <budr@sirinet.net> formerly <budr@tanet.net> ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Master or slave?? [not found] ` <jari.aalto@poboxes.com> 1998-08-13 16:35 ` Jason L Tibbitts III 1998-08-13 16:41 ` Lars Magne Ingebrigtsen @ 1998-08-17 13:06 ` Lars Magne Ingebrigtsen 1998-08-19 0:52 ` Marking new unread articles differently? Mike McEwan ` (20 subsequent siblings) 23 siblings, 0 replies; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-08-17 13:06 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > Could we get this displayed in the Group modeline by default? > Eg. string "Slave" after "Plugged" Ooh. That's kinda indecent, isn't it? I've added this to Gnus v5.6.38. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Marking new unread articles differently? [not found] ` <jari.aalto@poboxes.com> ` (2 preceding siblings ...) 1998-08-17 13:06 ` Master or slave?? Lars Magne Ingebrigtsen @ 1998-08-19 0:52 ` Mike McEwan 1998-08-20 21:23 ` Lars Magne Ingebrigtsen 1998-08-20 1:26 ` Suggestion: Command to rename all Subejcts in thread Lars Magne Ingebrigtsen ` (19 subsequent siblings) 23 siblings, 1 reply; 115+ messages in thread From: Mike McEwan @ 1998-08-19 0:52 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > Oh, please do. Sounds like a *very* usefull features. > jari Wow, one interested person :-) Well here's the patch (against gnus-5.6.37). Sorry, I reckon it's got quite big now. Anyways, if you apply it and you're `agentized' (I don't think it's of much benefit to those who read online all the time), just add: (setq gnus-mark-new-headers 't) (setq gnus-mark-downloaded 't) to your ~/.gnus or whatever and a `%a' somewhere in your `gnus-group-line-format' - probably best at the end - it's a ten character-width field. To view only threads with new/downloaded headers do a `C-M-n', only new/downloaded do `C-u C-M-n'. All new/downloaded marks are removed when exiting a group, optionally they can be removed with `G n' (remove marks from this group), or `G N' (remove marks from all groups). See the minimal doc in the patch text for clues. `new' marks will be present for *all* unread articles the *first* time with `gnus-mark-new-headers, I think. A couple of little things not covered in my previous mail to this list are the group parameter `dont-copy-marks' which when added to a group does exactly what it implies in respect of articles copied from other groups - no marks, apart from a `new' mark, are copied across. Also, sometimes when I've had articles queued in my `drafts' group ready for sending, I forget to send them because the `nndraft' group line doesn't show in the group buffer until I do a `g'. There's a couple of little kludges in here to make these groups show when there's something in them. I've probably gone a little wild here. You know how it is - start with a little function here, a tweak there :-). My functions aren't prefixed with `my-gnus..' either, but there just weren't enough hooks! Please note I haven't really used this with offline news reading, it's still a little rough I think. I'd appreciate hearing what folks think. I'll provide some more doc if folks are confused.Lars d'you think we (the off-liners anyway) could have something like this? -- Mike. diff -ur gnus-orig/lisp/gnus-agent.el gnus/lisp/gnus-agent.el --- gnus-orig/lisp/gnus-agent.el Sun Aug 16 17:59:43 1998 +++ gnus/lisp/gnus-agent.el Sun Aug 16 21:27:47 1998 @@ -333,7 +333,13 @@ (concat "^" (regexp-quote mail-header-separator) "\n")) (replace-match "\n") (gnus-agent-insert-meta-information 'mail) - (gnus-request-accept-article "nndraft:queue"))) + (gnus-request-accept-article "nndraft:queue") + (save-excursion + (set-buffer gnus-group-buffer) + (gnus-group-update-group "nndraft:queue") + (save-excursion + (gnus-group-goto-group "nndraft:queue" t) + (gnus-group-get-new-news-this-group 1 t))))) (defun gnus-agent-insert-meta-information (type &optional method) "Insert meta-information into the message that says how it's to be posted. @@ -782,7 +788,7 @@ (gnus-agent-enter-history "last-header-fetched-for-session" (list (cons group (nth (- (length articles) 1) articles))) (gnus-time-to-day (current-time))) - t))))) + t))))) (defsubst gnus-agent-copy-nov-line (article) (let (b e) @@ -801,7 +807,7 @@ (set-buffer nntp-server-buffer) (erase-buffer) (insert-file-contents file) - (goto-char (point-min)) + (goto-char (point-max)) (if (or (= (point-min) (point-max)) (progn (forward-line -1) @@ -892,7 +898,7 @@ gnus-newsgroup-dependencies gnus-newsgroup-headers gnus-newsgroup-scored gnus-headers gnus-score gnus-use-cache articles score arts - category predicate info marks score-param) + category predicate info marks score-param downloaded) ;; Fetch headers. (when (and (or (gnus-active group) (gnus-activate-group group)) (setq articles (gnus-list-of-unread-articles group)) @@ -925,13 +931,25 @@ (when arts (gnus-agent-fetch-articles group arts))) ;; Perhaps we have some additional articles to fetch. - (setq arts (assq 'download (gnus-info-marks - (setq info (gnus-get-info group))))) + (setq info (gnus-get-info group)) + (setq arts (assq 'download (gnus-info-marks info))) (when (cdr arts) (gnus-agent-fetch-articles group (gnus-uncompress-range (cdr arts))) - (setq marks (delq arts (gnus-info-marks info))) - (gnus-info-set-marks info marks)))) + (if gnus-mark-downloaded + (if (setq downloaded (assq 'downloaded + (gnus-info-marks info))) + (progn + (setq downloaded (cons 'downloaded + (gnus-add-to-range + (cdr downloaded) (cdr arts)))) + (setq marks (delq arts (gnus-info-marks info)))) + (setcar arts 'downloaded)) + (gnus-info-set-marks info marks))) + ;; Update group line to indicate the actual number (minus cancellations) + ;; of headers downloaded and whether any articles marked with + ;; `gnus-downloadable-mark' were downloaded. + (gnus-group-update-group group t))) ;;; ;;; Agent Category Mode diff -ur gnus-orig/lisp/gnus-group.el gnus/lisp/gnus-group.el --- gnus-orig/lisp/gnus-group.el Sun Aug 16 17:59:44 1998 +++ gnus/lisp/gnus-group.el Tue Aug 18 23:56:48 1998 @@ -160,6 +160,7 @@ %n Select from where (string) %z A string that look like `<%s:%n>' if a foreign select method is used %d The date the group was last entered. +%a The number of newly arrived headers since the group was last selected. %u User defined specifier. The next character in the format string should be a letter. Gnus will call the function gnus-user-format-function-X, where X is the letter following %u. The function will be passed the @@ -347,6 +348,12 @@ :group 'gnus-group-visual :type 'character) +(defcustom gnus-downloaded-mark ?* + "Mark used for articles that have been newly +downloaded via `gnus-downloadable-mark' - `%'." + :group 'gnus-summary-marks + :type 'character) + ;;; Internal variables (defvar gnus-group-sort-alist-function 'gnus-group-sort-flat @@ -395,6 +402,7 @@ (?z gnus-tmp-news-method-string ?s) (?m (gnus-group-new-mail gnus-tmp-group) ?c) (?d (gnus-group-timestamp-string gnus-tmp-group) ?s) + (?a (gnus-new-headers-string gnus-tmp-group) ?s) (?u gnus-tmp-user-defined ?s))) (defvar gnus-group-mode-line-format-alist @@ -426,6 +434,7 @@ "\r" gnus-group-select-group "\M-\r" gnus-group-quick-select-group [(meta control return)] gnus-group-select-group-ephemerally + "\M-\C-n" gnus-group-select-group-new "j" gnus-group-jump-to-group "n" gnus-group-next-unread-group "p" gnus-group-prev-unread-group @@ -512,6 +521,8 @@ "w" gnus-group-make-web-group "r" gnus-group-rename-group "c" gnus-group-customize + "n" gnus-group-clear-new-marks + "N" gnus-group-clear-new-marks-all "\177" gnus-group-delete-group [delete] gnus-group-delete-group) @@ -584,6 +595,10 @@ ["Catch up" gnus-group-catchup-current (gnus-group-group-name)] ["Catch up all articles" gnus-group-catchup-current-all (gnus-group-group-name)] + ["Remove new article marks" gnus-group-clear-new-marks + (when gnus-mark-new-headers (gnus-group-group-name))] + ["Remove *all* new marks" gnus-group-clear-new-marks-all + (when gnus-mark-new-headers t)] ["Check for new articles" gnus-group-get-new-news-this-group (gnus-group-group-name)] ["Toggle subscription" gnus-group-unsubscribe-current-group @@ -1253,8 +1268,15 @@ (get-text-property (gnus-point-at-bol) 'gnus-unread)) (defun gnus-group-new-mail (group) - (if (nnmail-new-mail-p (gnus-group-real-name group)) - gnus-new-mail-mark + (if (not (gnus-news-group-p group)) + (if (nnmail-new-mail-p (gnus-group-real-name group)) + gnus-new-mail-mark + ? ) + (gnus-group-downloaded group))) + +(defun gnus-group-downloaded (group) + (if (assq 'downloaded (gnus-info-marks (gnus-get-info group))) + gnus-downloaded-mark ? )) (defun gnus-group-level (group) @@ -3369,6 +3391,112 @@ (if (not time) "" (gnus-time-iso8601 time)))) + +;;; +;;; `new' header mark functions +;;; + +(defun gnus-new-headers-string (group) + "Return a space padded string of numerics of the form `nnnn(nnnn)' +where the digits preceding the `(' indicate the number of `new' +headers that have arrived in the group since the last time it was +selected. The suffixing space padded `(nnnn)' should only be returned +for genuine newsgroups, and indicates the number of potentially +downloadable headers still on the news-server (e.g. after a `g' in the +group buffer). + `n/a' is returned for `nndraft' groups as indicating `new' headers +doesn't make much sense. Perhaps there are a few other non-applicable +backends?" + (if (eq (car (gnus-find-method-for-group group)) + 'nndraft) + " n/a" + (let* ((info (gnus-get-info group)) + (marks (gnus-info-marks info)) + (max (cdr (gnus-active group))) + (last (gnus-group-get-parameter group 'last)) + (new (gnus-uncompress-range (cdr (assq 'new marks))))) + ;; Group is perhaps not `active'. + (when (not max) (setq max 0)) + (if (and new last) + (if (gnus-news-group-p group) + (format "%4s(%4s)" (length new) (- max last)) + (format "%4s" (length new))) + (progn + (if (and last (gnus-news-group-p group)) + ;; No new headers, so just indicate those potentially + ;; downloadable. + (format "%4s(%4s)" "0" (- max last)) + (if (gnus-news-group-p group) + (format "%4s(%4s)" "0" "0") + ;; Non newsgroup with no new headers. + " 0"))))))) + +(defun gnus-group-clear-new-marks-all () + "Clear `new' marks from all groups in `gnus-newsrc-alist'." + (interactive) + (gnus-group-clear-new-marks t)) + +(defun gnus-group-clear-new-marks (&optional n) + "Nullify all `new' header marks in the current newsgroup. +If N is numeric, marks will be removed from the next N groups. +If N is non-nil and non-numeric, clear marks from all groups." + (interactive "P") + (if (or (numberp n) (null n)) + (let ((groups (gnus-group-process-prefix n))) + (unless groups (error "No groups selected")) + (while groups + (let* + ((info (gnus-get-info (car groups))) + (marks (gnus-info-marks info))) + (gnus-group-remove-mark (car groups)) + (if (>= (gnus-group-group-level) gnus-level-zombie) + (gnus-message 2 "Dead groups can't be cleared of marks") + (progn + (setq marks (delq (assq 'new marks) marks)) + (gnus-info-set-marks info marks t)) + (gnus-group-update-group-line)) + (setq groups (cdr groups)))) + (gnus-group-next-unread-group 1) + (gnus-message 4 "\"new\" marks cleared")) + (let ((groups (mapcar 'car (cdr gnus-newsrc-alist)))) + (while groups + (unless (eq (car (gnus-find-method-for-group (car groups))) + 'nndraft) + (let* + ((info (gnus-get-info (car groups))) + (marks (gnus-info-marks info))) + (setq marks (delq (assq 'new marks) marks)) + (gnus-info-set-marks info marks t)) + (gnus-group-update-group (car groups) t)) + (setq groups (cdr groups))) + (gnus-message 4 "\"new\" marks cleared for all groups")))) + +(defun gnus-group-select-group-new (&optional no-threads) + "Select this newsgroup asking for threads with new +headers and/or articles that have been newly downloaded via +`gnus-downloadable-mark'. If NO-THREADS is non-nil, only +`new' and/or `downloaded' articles will be displayed." + (interactive "P") + (let* + ((group (gnus-group-group-name)) + (info (gnus-get-info group)) + (marks (gnus-info-marks info)) + (gnus-fetch-old-headers (if no-threads nil t)) + (new (gnus-uncompress-range (cdr (assq 'new marks)))) + (downloaded (gnus-uncompress-range (cdr (assq 'downloaded marks))))) +; (num (+ (length new) (length downloaded)))) + (when (not gnus-agent) + (setq new (gnus-uncompress-range + (cons + (1+ (gnus-group-get-parameter group 'last)) + (cdr (gnus-active group)))))) + (if (or new downloaded) + (progn + (when downloaded + (setq new (append downloaded new))) + (gnus-group-read-group nil t nil new)) + (error "No new messages in group")))) + (provide 'gnus-group) diff -ur gnus-orig/lisp/gnus-int.el gnus/lisp/gnus-int.el --- gnus-orig/lisp/gnus-int.el Tue Aug 11 18:53:51 1998 +++ gnus/lisp/gnus-int.el Mon Aug 17 20:57:18 1998 @@ -278,11 +278,46 @@ "Request headers for ARTICLES in GROUP. If FETCH-OLD, retrieve all headers (or some subset thereof) in the group." (let ((gnus-command-method (gnus-find-method-for-group group))) - (if (and gnus-use-cache (numberp (car articles))) - (gnus-cache-retrieve-headers articles group fetch-old) - (funcall (gnus-get-function gnus-command-method 'retrieve-headers) - articles (gnus-group-real-name group) - (nth 1 gnus-command-method) fetch-old)))) + ;; Need to preserve the return value of `nov' or `headers' + ;; from the `retrieve-headers' function before optionally + ;; counting in `new' headers. + (prog1 + (if (and gnus-use-cache (numberp (car articles))) + (gnus-cache-retrieve-headers articles group fetch-old) + (funcall (gnus-get-function gnus-command-method 'retrieve-headers) + articles (gnus-group-real-name group) + (nth 1 gnus-command-method) fetch-old)) + (when (and gnus-mark-new-headers (eq (car gnus-command-method) 'nntp) + (if gnus-agent gnus-plugged t)) + (save-excursion + (set-buffer nntp-server-buffer) + (goto-char (point-max)) + (let* ((info (gnus-get-info group)) + (marks (gnus-info-marks info)) + (last (gnus-group-get-parameter group 'last)) + new art) + ;; Set `last' if it's not in the group parameters yet. + ;; Everything's new, first time through. + (when (not last) + (setq last + (gnus-group-set-parameter group 'last + (car (gnus-active group))))) + (while (and + (= (forward-line -1) 0) + (> (setq art (read (current-buffer))) last)) + (setq new (append new (list art)))) + (when new + ;; Allow new header numbers to accumulate if group + ;; has not been selected since the last time headers + ;; were retrieved. + (progn + (setq new (gnus-range-add (cdr (assq 'new marks)) + (gnus-compress-sequence (nreverse new)))) + (setq marks (delq (assq 'new marks) marks)) + (setq marks (append (list (cons 'new new)) marks)) + (gnus-info-set-marks info marks t)) + ;; `last' can now be made ready for next time. + (gnus-group-set-parameter group 'last (cdr (gnus-active group)))))))))) (defun gnus-retrieve-articles (articles group) "Request ARTICLES in GROUP." diff -ur gnus-orig/lisp/gnus-msg.el gnus/lisp/gnus-msg.el --- gnus-orig/lisp/gnus-msg.el Sun Aug 16 17:59:45 1998 +++ gnus/lisp/gnus-msg.el Sun Aug 16 21:27:48 1998 @@ -962,11 +962,31 @@ (concat "^" (regexp-quote mail-header-separator) "$") nil t) (replace-match "" t t )) - (unless (gnus-request-accept-article group method t) - (gnus-message 1 "Couldn't store article in group %s: %s" - group (gnus-status-message method)) - (sit-for 2)) - (kill-buffer (current-buffer)))))))))) + (let (group-art) + (if (setq group-art (gnus-request-accept-article group method t)) + (when gnus-mark-new-headers + (let* ((info (gnus-get-info group)) + (marks (gnus-info-marks info)) + (new (cdr (assq 'new marks)))) + (if new + (setq new (gnus-add-to-range new (list (cdr group-art)))) + (setq new (list (cdr group-art)))) + (setq marks (delq (assq 'new marks) marks)) + (setq marks (append (list (cons 'new new)) marks)) + (gnus-info-set-marks info marks t)) + (save-excursion + (set-buffer gnus-group-buffer) + (gnus-group-update-group group) + (save-excursion + (gnus-group-goto-group group t) + (gnus-group-get-new-news-this-group 1 t))) + ;; `last' can now be made ready for next time. + (gnus-group-set-parameter group 'last + (cdr (gnus-active group)))) + (gnus-message 1 "Couldn't store article in group %s: %s" + group (gnus-status-message method)) + (sit-for 2)) + (kill-buffer (current-buffer))))))))))) (defun gnus-inews-insert-gcc () "Insert Gcc headers based on `gnus-outgoing-message-group'." diff -ur gnus-orig/lisp/gnus-sum.el gnus/lisp/gnus-sum.el --- gnus-orig/lisp/gnus-sum.el Sun Aug 16 17:59:46 1998 +++ gnus/lisp/gnus-sum.el Tue Aug 18 01:19:48 1998 @@ -443,6 +443,11 @@ :group 'gnus-summary-marks :type 'character) +(defcustom gnus-new-mark ?N + "*Mark used for articles that are new." + :group 'gnus-summary-marks + :type 'character) + (defcustom gnus-unsendable-mark ?= "*Mark used for articles that won't be sent." :group 'gnus-summary-marks @@ -744,12 +749,17 @@ ((= mark gnus-unread-mark) . gnus-summary-normal-unread-face) ((and (> score default) (memq mark (list gnus-downloadable-mark - gnus-undownloaded-mark))) + gnus-undownloaded-mark + gnus-downloaded-mark + gnus-new-mark))) . gnus-summary-high-unread-face) ((and (< score default) (memq mark (list gnus-downloadable-mark - gnus-undownloaded-mark))) + gnus-undownloaded-mark + gnus-downloaded-mark + gnus-new-mark))) . gnus-summary-low-unread-face) - ((memq mark (list gnus-downloadable-mark gnus-undownloaded-mark)) + ((memq mark (list gnus-downloadable-mark gnus-undownloaded-mark + gnus-downloaded-mark gnus-new-mark)) . gnus-summary-normal-unread-face) ((> score default) . gnus-summary-high-read-face) @@ -779,6 +789,16 @@ The function is called with one parameter, the article header vector, which it may alter in any way.") +(defcustom gnus-mark-new-headers nil + "*If non-nil, mark `new' headers in summary mode with `gnus-new-mark'." + :group 'gnus-summary + :type 'boolean) + +(defcustom gnus-mark-downloaded nil + "*If non-nil, mark `new' headers in summary mode with `gnus-new-mark'." + :group 'gnus-summary + :type 'boolean) + ;;; Internal variables (defvar gnus-scores-exclude-files nil) @@ -930,7 +950,14 @@ "List of articles in the current newsgroup that can be processed.") (defvar gnus-newsgroup-undownloaded nil - "List of articles in the current newsgroup that haven't been downloaded..") + "List of articles in the current newsgroup that haven't been downloaded.") + +(defvar gnus-newsgroup-downloaded nil + "List of articles in the current newsgroup that have been newly downloaded +via `gnus-downloadable-mark' - `%'.") + +(defvar gnus-newsgroup-new nil + "List of articles in the current newsgroup that are new.") (defvar gnus-newsgroup-unsendable nil "List of articles in the current newsgroup that won't be sent.") @@ -975,7 +1002,8 @@ gnus-newsgroup-replied gnus-newsgroup-expirable gnus-newsgroup-processable gnus-newsgroup-killed gnus-newsgroup-downloadable gnus-newsgroup-undownloaded - gnus-newsgroup-unsendable + gnus-newsgroup-downloaded + gnus-newsgroup-new gnus-newsgroup-unsendable gnus-newsgroup-bookmarks gnus-newsgroup-dormant gnus-newsgroup-headers gnus-newsgroup-threads gnus-newsgroup-prepared gnus-summary-highlight-line-function @@ -2350,6 +2378,8 @@ (when (gnus-buffer-exists-p gnus-summary-buffer) (set-buffer gnus-summary-buffer)) (let ((gnus-replied-mark 129) + (gnus-new-mark 129) + (gnus-downloaded-mark 129) (gnus-score-below-mark 130) (gnus-score-over-mark 130) (gnus-download-mark 131) @@ -2407,6 +2437,10 @@ (gnus-tmp-replied gnus-replied-mark) ((memq gnus-tmp-current gnus-newsgroup-saved) gnus-saved-mark) + ((memq gnus-tmp-current gnus-newsgroup-new) + gnus-new-mark) + ((memq gnus-tmp-current gnus-newsgroup-downloaded) + gnus-downloaded-mark) (t gnus-unread-mark))) (gnus-tmp-from (mail-header-from gnus-tmp-header)) (gnus-tmp-name @@ -3755,6 +3789,10 @@ gnus-replied-mark) ((memq number gnus-newsgroup-saved) gnus-saved-mark) + ((memq number gnus-newsgroup-new) + gnus-new-mark) + ((memq number gnus-newsgroup-downloaded) + gnus-downloaded-mark) (t gnus-unread-mark)) gnus-tmp-from (mail-header-from gnus-tmp-header) gnus-tmp-name @@ -3917,6 +3955,12 @@ (gnus-get-newsgroup-headers))) (gnus-message 5 "Fetching headers for %s...done" gnus-newsgroup-name) + ;; Workaround to re-appraise the `new' header situation if gnus is + ;; not `agentized'. + (when (not gnus-agent) + (setq gnus-newsgroup-new (gnus-uncompress-range + (cdr (assq 'new (gnus-info-marks info)))))) + ;; Kludge to avoid having cached articles nixed out in virtual groups. (when cached (setq gnus-newsgroup-cached cached)) @@ -4320,6 +4364,8 @@ (entry (gnus-gethash group gnus-newsrc-hashtb)) (info (nth 2 entry)) (active (gnus-active group)) + (marks (gnus-info-marks info)) + (new (cdr (assq 'new marks))) range) (when entry (setq range (gnus-compute-read-articles group articles)) @@ -4327,12 +4373,24 @@ (set-buffer gnus-group-buffer) (gnus-undo-register `(progn - (gnus-info-set-marks ',info ',(gnus-info-marks info) t) + (gnus-info-set-marks ',info ',marks t) (gnus-info-set-read ',info ',(gnus-info-read info)) (gnus-get-unread-articles-in-group ',info (gnus-active ,group)) (gnus-group-update-group ,group t)))) ;; Add the read articles to the range. (gnus-info-set-read info range) + ;; Remove Xref'd read articles from + ;; `new' ranges. + (when new + (let ((new (gnus-uncompress-range new))) + (while articles + (setq new (delq (car articles) new)) + (setq articles (cdr articles))) + (setq marks (delq (assq 'new marks) marks)) + (setq marks (append (list + (cons 'new (gnus-compress-sequence new))) + marks)) + (gnus-info-set-marks info marks))) ;; Then we have to re-compute how many unread ;; articles there are in this group. (when active @@ -5070,6 +5128,10 @@ ;; Make all changes in this group permanent. (unless quit-config (gnus-run-hooks 'gnus-exit-group-hook) + (when gnus-mark-new-headers + (setq gnus-newsgroup-new nil)) + (when gnus-mark-downloaded + (setq gnus-newsgroup-downloaded nil)) (gnus-summary-update-info) ;; Do adaptive scoring, and possibly save score files. (when gnus-newsgroup-adaptive @@ -5992,10 +6054,62 @@ (let ((data gnus-newsgroup-data) (marks (if (listp marks) marks (append marks nil))) ; Transform to list. - articles) + articles switch) (while data - (when (if reverse (not (memq (gnus-data-mark (car data)) marks)) - (memq (gnus-data-mark (car data)) marks)) + (when (if reverse (and (not (memq (gnus-data-mark (car data)) marks)) + (progn + (setq switch t) + (when (memq '?N marks) + (setq switch + (not (memq + (gnus-data-number (car data)) + gnus-newsgroup-new)))) + (when (memq '?> marks) + (setq switch + (not (memq + (gnus-data-number (car data)) + gnus-newsgroup-downloaded)))) + (when (and switch (memq '?# marks)) + (setq switch + (not (memq + (gnus-data-number (car data)) + gnus-newsgroup-processable)))) + (when (and switch (memq '?* marks)) + (setq switch + (not (memq + (gnus-data-number (car data)) + gnus-newsgroup-cached)))) + (when (and switch (memq '?A marks)) + (setq switch + (not (memq + (gnus-data-number (car data)) + gnus-newsgroup-replied)))) + (when (and switch (memq '?S marks)) + (setq switch + (not (memq (gnus-data-number (car data)) + gnus-newsgroup-saved)))) + switch)) + (or (memq (gnus-data-mark (car data)) marks) + (progn + (or + (when (memq '?N marks) + (memq (gnus-data-number (car data)) + gnus-newsgroup-new)) + (when (memq '?> marks) + (memq (gnus-data-number (car data)) + gnus-newsgroup-downloaded)) + (when (memq '?# marks) + (memq (gnus-data-number (car data)) + gnus-newsgroup-processable)) + (when (memq '?* marks) + (memq (gnus-data-number (car data)) + gnus-newsgroup-cached)) + (when (memq '?A marks) + (memq (gnus-data-number (car data)) + gnus-newsgroup-replied)) + (when (memq '?S marks) + (memq (gnus-data-number (car data)) + gnus-newsgroup-saved)))))) (push (gnus-data-number (car data)) articles)) (setq data (cdr data))) (gnus-summary-limit articles)) @@ -6998,34 +7112,41 @@ (gnus-find-method-for-group to-newsgroup))) gnus-newsrc-hashtb))) (info (nth 2 entry)) - (to-group (gnus-info-group info))) + (to-group (gnus-info-group info)) + (dont-copy-marks + (gnus-group-get-parameter to-group 'dont-copy-marks))) ;; Update the group that has been moved to. (when (and info (memq action '(move copy))) (unless (member to-group to-groups) (push to-group to-groups)) - - (unless (memq article gnus-newsgroup-unreads) + + (unless (or (memq article gnus-newsgroup-unreads) dont-copy-marks) (gnus-info-set-read info (gnus-add-to-range (gnus-info-read info) (list (cdr art-group))))) ;; Copy any marks over to the new group. - (let ((marks gnus-article-mark-lists) - (to-article (cdr art-group))) - - ;; See whether the article is to be put in the cache. - (when gnus-use-cache - (gnus-cache-possibly-enter-article - to-group to-article - (let ((header (copy-sequence - (gnus-summary-article-header article)))) - (mail-header-set-number header to-article) - header) - (memq article gnus-newsgroup-marked) - (memq article gnus-newsgroup-dormant) - (memq article gnus-newsgroup-unreads))) - + (let ((marks (if dont-copy-marks '((new . new)) + gnus-article-mark-lists)) + (to-article (cdr art-group)) + (gnus-newsgroup-new + (if (or (memq article gnus-newsgroup-unreads) + dont-copy-marks) (list article) nil))) + + (unless dont-copy-marks + ;; See whether the article is to be put in the cache. + (when gnus-use-cache + (gnus-cache-possibly-enter-article + to-group to-article + (let ((header (copy-sequence + (gnus-summary-article-header article)))) + (mail-header-set-number header to-article) + header) + (memq article gnus-newsgroup-marked) + (memq article gnus-newsgroup-dormant) + (memq article gnus-newsgroup-unreads)))) + (when (and (equal to-group gnus-newsgroup-name) (not (memq article gnus-newsgroup-unreads))) ;; Mark this article as read in this group. @@ -7078,8 +7199,12 @@ (set-buffer gnus-group-buffer) (when (gnus-group-goto-group (car to-groups) t) (gnus-group-get-new-news-this-group 1 t)) + (when gnus-mark-new-headers + ;; Reset `last' regardless, in readiness for next time. + (gnus-group-set-parameter (car to-groups) 'last + (cdr (gnus-active (car to-groups))))) (pop to-groups))) - + (gnus-kill-buffer copy-buf) (gnus-summary-position-point) (gnus-set-mode-line 'summary))) @@ -7153,7 +7278,7 @@ (interactive "fImport file: ") (let ((group gnus-newsgroup-name) (now (current-time)) - atts lines) + atts lines group-art) (unless (gnus-check-backend-function 'request-accept-article group) (error "%s does not support article importing" group)) (or (file-readable-p file) @@ -7179,7 +7304,26 @@ "Message-ID: " (message-make-message-id) "\n" "Lines: " (int-to-string lines) "\n" "Chars: " (int-to-string (nth 7 atts)) "\n\n")) - (gnus-request-accept-article group nil t) + (setq group-art (gnus-request-accept-article group nil t)) + (when gnus-mark-new-headers + (let* ((info (gnus-get-info group)) + (marks (gnus-info-marks info)) + (new (cdr (assq 'new marks)))) + (if new + (setq new (gnus-add-to-range new (list (cdr group-art)))) + (setq new (list (cdr group-art)))) + (setq marks (delq (assq 'new marks) marks)) + (setq marks (append (list (cons 'new new)) marks)) + (gnus-info-set-marks info marks t)) + (save-excursion + (set-buffer gnus-group-buffer) + (gnus-group-update-group group) + (save-excursion + (gnus-group-goto-group group t) + (gnus-group-get-new-news-this-group 1 t))) + ;; `last' can now be made ready for next time. + (gnus-group-set-parameter group 'last + (cdr (gnus-active group)))) (kill-buffer (current-buffer))))) (defun gnus-summary-article-posted-p () @@ -7757,6 +7901,10 @@ gnus-replied-mark) ((memq article gnus-newsgroup-saved) gnus-saved-mark) + ((memq article gnus-newsgroup-new) + gnus-new-mark) + ((memq article gnus-newsgroup-downloaded) + gnus-downloaded-mark) (t gnus-unread-mark)) 'replied) (when (gnus-visual-p 'summary-highlight 'highlight) diff -ur gnus-orig/lisp/gnus.el gnus/lisp/gnus.el --- gnus-orig/lisp/gnus.el Sun Aug 16 17:59:46 1998 +++ gnus/lisp/gnus.el Sun Aug 16 21:27:48 1998 @@ -1463,7 +1463,7 @@ (bookmarks . bookmark) (dormant . dormant) (scored . score) (saved . save) (cached . cache) (downloadable . download) - (unsendable . unsend))) + (unsendable . unsend) (new . new) (downloaded . downloaded))) (defvar gnus-headers-retrieved-by nil) (defvar gnus-article-reply nil) diff -ur gnus-orig/lisp/nnagent.el gnus/lisp/nnagent.el --- gnus-orig/lisp/nnagent.el Sat Jul 25 01:41:38 1998 +++ gnus/lisp/nnagent.el Sun Aug 16 20:03:12 1998 @@ -110,7 +110,13 @@ (deffoo nnagent-request-post (&optional server) (gnus-agent-insert-meta-information 'news gnus-command-method) - (gnus-request-accept-article "nndraft:queue")) + (gnus-request-accept-article "nndraft:queue") + (save-excursion + (set-buffer gnus-group-buffer) + (gnus-group-update-group "nndraft:queue") + (save-excursion + (gnus-group-goto-group "nndraft:queue" t) + (gnus-group-get-new-news-this-group 1 t)))) ;; Use nnml functions for just about everything. (nnoo-import nnagent diff -ur gnus-orig/lisp/nnmail.el gnus/lisp/nnmail.el --- gnus-orig/lisp/nnmail.el Fri Aug 14 20:42:16 1998 +++ gnus/lisp/nnmail.el Mon Aug 17 01:22:05 1998 @@ -1637,6 +1637,8 @@ (nnmail-get-value "%s-active-file" method)) (when exit-func (funcall exit-func)) + (when gnus-mark-new-headers + (nnmail-update-new-marks)) (run-hooks 'nnmail-read-incoming-hook) (nnheader-message 3 "%s: Reading incoming mail...done" method)) ;; Close the message-id cache. @@ -1650,6 +1652,29 @@ (file-exists-p incoming) (file-writable-p incoming) (delete-file incoming)))))) + +(defun nnmail-update-new-marks () + "Update `new' marks in mail groups." + (let ((alist (nnmail-get-value "%s-group-alist" (car gnus-command-method))) + group) + (while (setq group (pop alist)) + (let* + ((max (cdadr group)) + (group (gnus-group-prefixed-name (car group) gnus-command-method)) + (info (gnus-get-info group)) + (marks (gnus-info-marks info)) + (last (gnus-group-get-parameter group 'last)) + new-arts new) + (when (and max last) + (if (> max last) + (progn + (setq new-arts (cons (1+ last) max)) + (setq new (gnus-range-add (cdr (assq 'new marks)) + new-arts)) + (setq marks (delq (assq 'new marks) marks)) + (setq marks (append (list (cons 'new new)) marks)) + (gnus-info-set-marks info marks t) + (gnus-group-set-parameter group 'last max)))))))) (defun nnmail-expired-article-p (group time force &optional inhibit) "Say whether an article that is TIME old in GROUP should be expired." ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Marking new unread articles differently? 1998-08-19 0:52 ` Marking new unread articles differently? Mike McEwan @ 1998-08-20 21:23 ` Lars Magne Ingebrigtsen 1998-08-21 17:11 ` Mike McEwan 0 siblings, 1 reply; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-08-20 21:23 UTC (permalink / raw) Mike McEwan <mike@lotusland.demon.co.uk> writes: > I've probably gone a little wild here. You know how it is - start > with a little function here, a tweak there :-). My functions aren't > prefixed with `my-gnus..' either, but there just weren't enough > hooks! Please note I haven't really used this with offline news > reading, it's still a little rough I think. I'd appreciate hearing > what folks think. I'll provide some more doc if folks are > confused.Lars d'you think we (the off-liners anyway) could have > something like this? Looks OK to me, but I'll be holding off on this stuff until pgnus. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Marking new unread articles differently? 1998-08-20 21:23 ` Lars Magne Ingebrigtsen @ 1998-08-21 17:11 ` Mike McEwan 1998-08-21 19:15 ` Lars Magne Ingebrigtsen 1998-08-25 6:25 ` Matt Simmons 0 siblings, 2 replies; 115+ messages in thread From: Mike McEwan @ 1998-08-21 17:11 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Looks OK to me, but I'll be holding off on this stuff until pgnus. Great. Would it be OK if I re-mail my patches when we're into the pgnus cycle - I'm still tweaking? -- Mike. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Marking new unread articles differently? 1998-08-21 17:11 ` Mike McEwan @ 1998-08-21 19:15 ` Lars Magne Ingebrigtsen 1998-08-25 6:25 ` Matt Simmons 1 sibling, 0 replies; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-08-21 19:15 UTC (permalink / raw) Mike McEwan <mike@lotusland.demon.co.uk> writes: > > Looks OK to me, but I'll be holding off on this stuff until pgnus. > > Great. Would it be OK if I re-mail my patches when we're into the > pgnus cycle - I'm still tweaking? Yes; I'd prefer that, in fact. :-) -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Marking new unread articles differently? 1998-08-21 17:11 ` Mike McEwan 1998-08-21 19:15 ` Lars Magne Ingebrigtsen @ 1998-08-25 6:25 ` Matt Simmons 1998-08-26 3:46 ` Mike McEwan 1 sibling, 1 reply; 115+ messages in thread From: Matt Simmons @ 1998-08-25 6:25 UTC (permalink / raw) >>>>> "Mike" == Mike McEwan <mike@lotusland.demon.co.uk> writes: Lars> Looks OK to me, but I'll be holding off on this stuff until pgnus. Mike> Great. Would it be OK if I re-mail my patches when we're into the Mike> pgnus cycle - I'm still tweaking? Would it be difficult to tweak it such that a different face was used for the new messages? It's much easier to spot a message when it's entire line is distinctive. Thanks Matt -- Matt Simmons - simmonmt@acm.org - http://www.netcom.com/~simmonmt The world is full of willing people; some willing to work, the rest willing to let them. --Robert Frost ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Marking new unread articles differently? 1998-08-25 6:25 ` Matt Simmons @ 1998-08-26 3:46 ` Mike McEwan 0 siblings, 0 replies; 115+ messages in thread From: Mike McEwan @ 1998-08-26 3:46 UTC (permalink / raw) Matt Simmons <simmonmt@acm.org> writes: > Would it be difficult to tweak it such that a different face was used > for the new messages? It's much easier to spot a message when it's > entire line is distinctive. Well, it was a little tricky, but I think I've got it sussed. It's so damned hard picking what colours to have :-). If you'd like me to mail you what I've got so far, drop me a note. My current patch is against gnus-5.6.39. You probably need something like CVS if you like to update your gnusae (is that the right word?) as fast as Lars throws them at you and wish to re-apply local updates. -- Mike. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Suggestion: Command to rename all Subejcts in thread [not found] ` <jari.aalto@poboxes.com> ` (3 preceding siblings ...) 1998-08-19 0:52 ` Marking new unread articles differently? Mike McEwan @ 1998-08-20 1:26 ` Lars Magne Ingebrigtsen 1998-08-20 8:46 ` Jari Aalto+list.ding 1998-08-20 19:41 ` Lars Magne Ingebrigtsen ` (18 subsequent siblings) 23 siblings, 1 reply; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-08-20 1:26 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > I would like to see a command in Summary buffer where I could > stand at the top of thread and appply > > "Change ann messages' Subject in this theread to...." [...] > Pretty, Please Lars, Any chance to see that command in near future? I don't think this would be very useful, so I'm not going to write it. I'll apply the patches if someone does, though. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Suggestion: Command to rename all Subejcts in thread 1998-08-20 1:26 ` Suggestion: Command to rename all Subejcts in thread Lars Magne Ingebrigtsen @ 1998-08-20 8:46 ` Jari Aalto+list.ding 0 siblings, 0 replies; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-08-20 8:46 UTC (permalink / raw) | 1998-08-20 Lars Magne Ingebrigtsen <larsi@gnus.org> list.ding | > | > "Change ann messages' Subject in this theread to...." | | I don't think this would be very useful, so I'm not going to write | it. I'll apply the patches if someone does, though. I would desperately need it, so I could try wtiting the code, would you tell me how: - I go to the top of a thread (to get beginning point) - I get all message numbers of the thread below the current article. jari ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Suggestion: Command to rename all Subejcts in thread [not found] ` <jari.aalto@poboxes.com> ` (4 preceding siblings ...) 1998-08-20 1:26 ` Suggestion: Command to rename all Subejcts in thread Lars Magne Ingebrigtsen @ 1998-08-20 19:41 ` Lars Magne Ingebrigtsen 1998-08-20 21:19 ` 5.6.38 Can't read drafts server? Lars Magne Ingebrigtsen ` (17 subsequent siblings) 23 siblings, 0 replies; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-08-20 19:41 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > I would desperately need it, so I could try wtiting the code, would > you tell me how: > > - I go to the top of a thread (to get beginning point) `gnus-summary-top-thread' > - I get all message numbers of the thread below the current article. `gnus-uu-mark-thread' and then `gnus-summary-work-articles'. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: 5.6.38 Can't read drafts server? [not found] ` <jari.aalto@poboxes.com> ` (5 preceding siblings ...) 1998-08-20 19:41 ` Lars Magne Ingebrigtsen @ 1998-08-20 21:19 ` Lars Magne Ingebrigtsen 1998-08-21 6:38 ` Jari Aalto+list.ding 1998-08-21 11:52 ` Karl Kleinpaste 1998-08-21 19:09 ` Lars Magne Ingebrigtsen ` (16 subsequent siblings) 23 siblings, 2 replies; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-08-20 21:19 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > Gnus denies access to drafts grou when I press SPC. > What should I check? When did this start happening? -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: 5.6.38 Can't read drafts server? 1998-08-20 21:19 ` 5.6.38 Can't read drafts server? Lars Magne Ingebrigtsen @ 1998-08-21 6:38 ` Jari Aalto+list.ding 1998-08-21 11:52 ` Karl Kleinpaste 1 sibling, 0 replies; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-08-21 6:38 UTC (permalink / raw) | 1998-08-20 Lars Magne Ingebrigtsen <larsi@gnus.org> list.ding | <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: | | > Gnus denies access to drafts grou when I press SPC. | > What should I check? | | When did this start happening? I have no idea. I haven't accesd the dtaft group for ages, but recently our newserver had reported "no space left on device" so I saved unposted articles with C-x C-s. Next day (when I reported the problem) I tried to access draft group and was suprised that I could get inside. Is there some function you want me to edebug? jari ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: 5.6.38 Can't read drafts server? 1998-08-20 21:19 ` 5.6.38 Can't read drafts server? Lars Magne Ingebrigtsen 1998-08-21 6:38 ` Jari Aalto+list.ding @ 1998-08-21 11:52 ` Karl Kleinpaste 1 sibling, 0 replies; 115+ messages in thread From: Karl Kleinpaste @ 1998-08-21 11:52 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: >> Gnus denies access to drafts grou when I press SPC. Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > When did this start happening? Drafts have been working fine for me in both .37 and .38. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: 5.6.38 Can't read drafts server? [not found] ` <jari.aalto@poboxes.com> ` (6 preceding siblings ...) 1998-08-20 21:19 ` 5.6.38 Can't read drafts server? Lars Magne Ingebrigtsen @ 1998-08-21 19:09 ` Lars Magne Ingebrigtsen 1998-08-23 21:20 ` Jari Aalto+list.ding 1998-08-21 19:10 ` pop3 reading with gnus? Lars Magne Ingebrigtsen ` (15 subsequent siblings) 23 siblings, 1 reply; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-08-21 19:09 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > Next day (when I reported the problem) I tried to access draft group > and was suprised that I could get inside. > > Is there some function you want me to edebug? nnmh-request-group, for instance. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: 5.6.38 Can't read drafts server? 1998-08-21 19:09 ` Lars Magne Ingebrigtsen @ 1998-08-23 21:20 ` Jari Aalto+list.ding 0 siblings, 0 replies; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-08-23 21:20 UTC (permalink / raw) | 1998-08-21 Lars Magne Ingebrigtsen <larsi@gnus.org> list.ding | <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: | | > Next day (when I reported the problem) I tried to access draft group | > and was suprised that I could get inside. | > | > Is there some function you want me to edebug? | | nnmh-request-group, for instance. I didn't reach that far, I was able to go to point gnus-request-group, but then it called function nndraft-request-group which I couldn't find anywhere to instrument it for Edebug. How do I continue tracing? jari (defun gnus-activate-group (group &optional scan dont-check method) ;; Check whether a group has been activated or not. ;; If SCAN, request a scan of that group as well. (let ((method (or method (inline (gnus-find-method-for-group group)))) active) (and (inline (gnus-check-server method)) ;; We escape all bugs and quit here to make it possible to ;; continue if a group is so out-there that it reports bugs ;; and stuff. (progn (and scan (gnus-check-backend-function 'request-scan (car method)) (gnus-request-scan group method)) t) (condition-case () ==> (inline (gnus-request-group group dont-check method)) (error nil) (quit nil)) (setq active (gnus-parse-active)) (defun gnus-request-group (group &optional dont-check gnus-command-method) "Request GROUP. If DONT-CHECK, no information is required." (let ((gnus-command-method (or gnus-command-method (inline (gnus-find-method-for-group group))))) (when (stringp gnus-command-method) (setq gnus-command-method (inline (gnus-server-to-method gnus-command-method)))) --> nndraft-request-group (funcall (inline (gnus-get-function gnus-command-method 'request-group)) (gnus-group-real-name group) (nth 1 gnus-command-method) dont-check))) ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: pop3 reading with gnus? [not found] ` <jari.aalto@poboxes.com> ` (7 preceding siblings ...) 1998-08-21 19:09 ` Lars Magne Ingebrigtsen @ 1998-08-21 19:10 ` Lars Magne Ingebrigtsen 1998-08-21 20:05 ` William M. Perry 1998-08-21 19:13 ` Suggestion: *Group* SPC to show only new articles? Lars Magne Ingebrigtsen ` (14 subsequent siblings) 23 siblings, 1 reply; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-08-21 19:10 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > What's the correct way to define multiple pop3 servers and use them? There is no pre-defined functionality in Gnus for doing this. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: pop3 reading with gnus? 1998-08-21 19:10 ` pop3 reading with gnus? Lars Magne Ingebrigtsen @ 1998-08-21 20:05 ` William M. Perry 0 siblings, 0 replies; 115+ messages in thread From: William M. Perry @ 1998-08-21 20:05 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > > > What's the correct way to define multiple pop3 servers and use them? > > There is no pre-defined functionality in Gnus for doing this. I use VM's pop support to do this. Try: (defun my-movemail (inbox crashbox) (require 'vm) (vm-spool-move-mail (getenv "MAIL") crashbox) (vm-pop-move-mail "milo.in.aventail.com:110:pass:wmperry:YYYYYYYY" crashbox) (vm-pop-move-mail "mail.cntwk.net:110:pass:wmperry:YYYYYYYY" crashbox) (vm-pop-move-mail "moose.cs.indiana.edu:110:pass:wmperry:ZZZZZZZZZZZ" crashbox)) (setq nnmail-movemail-program 'my-movemail) -Bill P. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Suggestion: *Group* SPC to show only new articles? [not found] ` <jari.aalto@poboxes.com> ` (8 preceding siblings ...) 1998-08-21 19:10 ` pop3 reading with gnus? Lars Magne Ingebrigtsen @ 1998-08-21 19:13 ` Lars Magne Ingebrigtsen 1998-08-22 20:57 ` patch: 5.6.38 gnus-uu, new regexp marking commands Lars Magne Ingebrigtsen ` (13 subsequent siblings) 23 siblings, 0 replies; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-08-21 19:13 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > Now I manually > Hit the count of the arrived articles to see what's new in there: > Eg. if 2 messages has arrived, I can browse the group lighting fast > with: > > M-2 gnus-topic-read-group > > But it's pain to enter different number for each group. I'd suggest writing a function do to this. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: patch: 5.6.38 gnus-uu, new regexp marking commands [not found] ` <jari.aalto@poboxes.com> ` (9 preceding siblings ...) 1998-08-21 19:13 ` Suggestion: *Group* SPC to show only new articles? Lars Magne Ingebrigtsen @ 1998-08-22 20:57 ` Lars Magne Ingebrigtsen 1998-08-24 7:30 ` Suggestion: *Group* SPC to show only new articles? Kai Grossjohann ` (12 subsequent siblings) 23 siblings, 0 replies; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-08-22 20:57 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > Here is the new functions that do that: They un/mark articles > that match From field. I don't think adding more specialized functions for setting the process mark on other headers is a good idea. The limiting commands already allow you to limit on an arbitrary header, which is what should be used instead. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Suggestion: *Group* SPC to show only new articles? [not found] ` <jari.aalto@poboxes.com> ` (10 preceding siblings ...) 1998-08-22 20:57 ` patch: 5.6.38 gnus-uu, new regexp marking commands Lars Magne Ingebrigtsen @ 1998-08-24 7:30 ` Kai Grossjohann 1998-08-24 8:37 ` Jari Aalto+list.ding 1998-08-24 8:48 ` Kai Grossjohann ` (11 subsequent siblings) 23 siblings, 1 reply; 115+ messages in thread From: Kai Grossjohann @ 1998-08-24 7:30 UTC (permalink / raw) Cc: Ding mailing list >>>>> <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > Eg. if 2 messages has arrived, I can browse the group lighting fast > with: > > M-2 gnus-topic-read-group Doesn't just SPC do this? It might fetch a bit more if gnus-fetch-old-headers is non-nil, but you can easily fix that. kai -- OOP: object oriented programming; OOPS: object oriented mistakes ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Suggestion: *Group* SPC to show only new articles? 1998-08-24 7:30 ` Suggestion: *Group* SPC to show only new articles? Kai Grossjohann @ 1998-08-24 8:37 ` Jari Aalto+list.ding 0 siblings, 0 replies; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-08-24 8:37 UTC (permalink / raw) | 1998-08-24 Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> list.ding | | > M-2 gnus-topic-read-group [fast way to access group] | | Doesn't just SPC do this? It might fetch a bit more if | gnus-fetch-old-headers is non-nil, but you can easily fix that. Exellent suggestion, but SPC also shows ticked articles. I would like to see only new articles when I enter a group. It seems that giving a number still doesn't give /only/ the new articles. Would anyone have more suggestions? I'd love to see Prefix or function to show only arrived articles. jari ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Suggestion: *Group* SPC to show only new articles? [not found] ` <jari.aalto@poboxes.com> ` (11 preceding siblings ...) 1998-08-24 7:30 ` Suggestion: *Group* SPC to show only new articles? Kai Grossjohann @ 1998-08-24 8:48 ` Kai Grossjohann 1998-08-24 10:10 ` Jari Aalto+list.ding 1998-08-24 11:41 ` Kai Grossjohann ` (10 subsequent siblings) 23 siblings, 1 reply; 115+ messages in thread From: Kai Grossjohann @ 1998-08-24 8:48 UTC (permalink / raw) Cc: Ding mailing list >>>>> <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > Exellent suggestion, but SPC also shows ticked articles. I would > like to see only new articles when I enter a group. It seems that > giving a number still doesn't give /only/ the new articles. Hm. Well, ticked articles are made so that they are always shown. Dormant articles are similar to ticked ones, except that they're only shown when there is a followup or an explicit request from the user. You might want to use `/ m SPC RET' to only show the unmarked messages after entering a group. It should be simple to write a function which uses RET or SPC to enter a group then the above command to unshow the ticked articles. kai -- OOP: object oriented programming; OOPS: object oriented mistakes ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Suggestion: *Group* SPC to show only new articles? 1998-08-24 8:48 ` Kai Grossjohann @ 1998-08-24 10:10 ` Jari Aalto+list.ding 0 siblings, 0 replies; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-08-24 10:10 UTC (permalink / raw) | 1998-08-24 Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> list.ding | >>>>> <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: | | > like to see only new articles when I enter a group. It seems that | > giving a number still doesn't give /only/ the new articles. | | Hm. Well, ticked articles are made so that they are always shown. | You might want to use `/ m SPC RET' to only show the unmarked messages | after entering a group. It should be simple to write a function which | uses RET or SPC to enter a group then the above command to unshow the | ticked articles. All that of course works, but I would like to avoid the phase or Creating Large Summary buffer altogether. I'm looking for speed here. Many of my groups have 10's of ticked (in work groups, hundreads) articles and this mean lot of extra work for Gnus, and it slows down Getting the Summary displayed. Limiting is another step still. Gnus must know which articles are new, so building summary based on them only should be trivial. And when combined with (gnus-fetch-old-headers nil) that'd be the fast access to new articles. What gnus functions variables is needed here? jari ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Suggestion: *Group* SPC to show only new articles? [not found] ` <jari.aalto@poboxes.com> ` (12 preceding siblings ...) 1998-08-24 8:48 ` Kai Grossjohann @ 1998-08-24 11:41 ` Kai Grossjohann 1998-08-24 12:20 ` Francisco Solsona 1998-08-24 14:38 ` Mike McEwan ` (9 subsequent siblings) 23 siblings, 1 reply; 115+ messages in thread From: Kai Grossjohann @ 1998-08-24 11:41 UTC (permalink / raw) Cc: Ding mailing list >>>>> <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > Gnus must know which articles are new, so building summary based on > them only should be trivial. And when combined with > > (gnus-fetch-old-headers nil) > > that'd be the fast access to new articles. > What gnus functions variables is needed here? Well, in recent Gnusae, you can give a parameter to the internal group reading function which gives the list of articles to display. See nnir.el for an example. And I think there's a variable or function which gives you the unread messages. kai -- OOP: object oriented programming; OOPS: object oriented mistakes ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Suggestion: *Group* SPC to show only new articles? 1998-08-24 11:41 ` Kai Grossjohann @ 1998-08-24 12:20 ` Francisco Solsona 0 siblings, 0 replies; 115+ messages in thread From: Francisco Solsona @ 1998-08-24 12:20 UTC (permalink / raw) Cc: Jari Aalto+list.ding, Ding mailing list Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes: > >>>>> <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > > > Gnus must know which articles are new, so building summary based on > > them only should be trivial. And when combined with > > > > (gnus-fetch-old-headers nil) > > > > that'd be the fast access to new articles. > > What gnus functions variables is needed here? > > Well, in recent Gnusae, you can give a parameter to the internal group > reading function which gives the list of articles to display. See > nnir.el for an example. And I think there's a variable or function > which gives you the unread messages. Actually, seeing only the unread articles seems a very useful functionality. What about binding something like this: (defun my-gnus-topic-read-group () (interactive) (gnus-topic-read-group (gnus-group-group-unread))) to SPC in the *group* buff ?, this --I believe-- should be the fastest way of doing it. Francisco -- Real computer scientists like having a computer on their desk, else how could they read their mail? ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Suggestion: *Group* SPC to show only new articles? [not found] ` <jari.aalto@poboxes.com> ` (13 preceding siblings ...) 1998-08-24 11:41 ` Kai Grossjohann @ 1998-08-24 14:38 ` Mike McEwan 1998-08-25 5:55 ` 5.6.38 Can't read drafts server? Lars Magne Ingebrigtsen ` (8 subsequent siblings) 23 siblings, 0 replies; 115+ messages in thread From: Mike McEwan @ 1998-08-24 14:38 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > Gnus must know which articles are new, so building summary based on > them only should be trivial. And when combined with > > (gnus-fetch-old-headers nil) > > that'd be the fast access to new articles. > What gnus functions variables is needed here? Well, maybe you didn't see my followup mailing to yours in an earlier thread "Marking new unread articles differently?", or maybe you did, but didn't like what you saw :-). Gnus does *not* know which headers/articles are `new' (here I am taking `new' to mean headers/articles that have arrived since the last time a given group was selected). It only knows which articles are `unread'. This may suffice for folks that mark everything as `read' each time they select a group, but this is not the case with me, particularly where large groups are concerned. In order to ascertain what is genuinely `new' since a group was last selected, you have to have some mechanism of knowing what the last header/article retrieved for a group was. `new' headers/articles *only* can then be selected via use of the SELECT-ARTICLES argument to `gnus-group-read-group'. Just selecting a number of `new' headers/articles does not always do it where real newsgroups are concerned as some articles may have been cancelled and you get `old' non-new articles in their place. I'm still tweaking with the patch I mailed on the above-mentioned thread, but generally everything works just fine. Lars has said he will not consider such new function until we're into the `pgnus' cycle, at which time I'll re-mail what I have to this group. In the meantime I'm using CVS to re-merge my patch with each release of gnus (I like that CVS), there aren't enough hooks to keep the code isolated. If you really did miss my previous mailing, and want, I'll mail my current patch to you. If not, and you don't, I'll understand :-). -- Mike. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: 5.6.38 Can't read drafts server? [not found] ` <jari.aalto@poboxes.com> ` (14 preceding siblings ...) 1998-08-24 14:38 ` Mike McEwan @ 1998-08-25 5:55 ` Lars Magne Ingebrigtsen 1998-08-25 13:05 ` Jari Aalto+list.ding 1998-08-25 6:11 ` Suggestion: Topic mode get news and topic group indentation level Lars Magne Ingebrigtsen ` (7 subsequent siblings) 23 siblings, 1 reply; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-08-25 5:55 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > | nnmh-request-group, for instance. > > I didn't reach that far, I was able to go to point > gnus-request-group, but then it called function > nndraft-request-group which I couldn't find anywhere to instrument > it for Edebug. `nnmh-request-group' is the function to instrument. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: 5.6.38 Can't read drafts server? 1998-08-25 5:55 ` 5.6.38 Can't read drafts server? Lars Magne Ingebrigtsen @ 1998-08-25 13:05 ` Jari Aalto+list.ding 0 siblings, 0 replies; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-08-25 13:05 UTC (permalink / raw) | 1998-08-25 Lars Magne Ingebrigtsen <larsi@gnus.org> list.ding | <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: | | > | nnmh-request-group, for instance. | > | > I didn't reach that far, I was able to go to point | > gnus-request-group, but then it called function | > nndraft-request-group which I couldn't find anywhere to instrument | > it for Edebug. | | `nnmh-request-group' is the function to instrument. I did that, but It never stops there...When I instrumented the nnmh-request-group' it said: Mark saved where search started [2 times] Edebug: edebug-anon0 Edebug: nnmh-request-group I'm currently stuck at this point: (defun gnus-request-group (group &optional dont-check gnus-command-method) "Request GROUP. If DONT-CHECK, no information is required." (let ((gnus-command-method (or gnus-command-method (inline (gnus-find-method-for-group group))))) (when (stringp gnus-command-method) (setq gnus-command-method (inline (gnus-server-to-method gnus-command-method)))) => (funcall (inline (gnus-get-function gnus-command-method 'request-group)) (gnus-group-real-name group) (nth 1 gnus-command-method) dont-check))) (gnus-get-function gnus-command-method (quote request-group)) --> nndraft-request-group The "i" is hopeless here, since I get Signaling: (error "Don't know where gnus-get-function is defined") apply(debug error(error "Don't know where gnus-get-function is defined")) edebug(error (error "Don't know where gnus-get-function is defined")) signal(error ("Don't know where gnus-get-function is defined")) The call seems to be: (nndraft-request-group "drafts" "" nil) And I called it directly to find out it it would trigger edebug and nnmh-request-group...no joy. How do I get past and land to nnmh-request-group? jari ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Suggestion: Topic mode get news and topic group indentation level [not found] ` <jari.aalto@poboxes.com> ` (15 preceding siblings ...) 1998-08-25 5:55 ` 5.6.38 Can't read drafts server? Lars Magne Ingebrigtsen @ 1998-08-25 6:11 ` Lars Magne Ingebrigtsen 1998-09-02 14:34 ` Hallvard's gnus-e20/19.34/Pgnus 0.13 emulation (backtrace included) Hrvoje Niksic ` (6 subsequent siblings) 23 siblings, 0 replies; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-08-25 6:11 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > I would find it neat to Hit M-g at topmost topic level and get all > subtopics read in. Well, I considered doing it that way, but I decided against it for some reason. And I don't want to change it now. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Hallvard's gnus-e20/19.34/Pgnus 0.13 emulation (backtrace included) [not found] ` <jari.aalto@poboxes.com> ` (16 preceding siblings ...) 1998-08-25 6:11 ` Suggestion: Topic mode get news and topic group indentation level Lars Magne Ingebrigtsen @ 1998-09-02 14:34 ` Hrvoje Niksic 1998-09-02 14:35 ` Lars Magne Ingebrigtsen ` (5 subsequent siblings) 23 siblings, 0 replies; 115+ messages in thread From: Hrvoje Niksic @ 1998-09-02 14:34 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > > I'm having great success running Pgnus with 19.34, but then I hit this. > (Thanks Hallvard's for gnus-e20.el) > > (gnus-version)"Pterodactyl Gnus v0.13 > > Does string-to-number take new parameter in Emacs 20.x ? As a matter of fact, yes. It supports an optional BASE argument. -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- A jury consists of 12 persons chosen to decide who has the better lawyer. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Hallvard's gnus-e20/19.34/Pgnus 0.13 emulation (backtrace included) [not found] ` <jari.aalto@poboxes.com> ` (17 preceding siblings ...) 1998-09-02 14:34 ` Hallvard's gnus-e20/19.34/Pgnus 0.13 emulation (backtrace included) Hrvoje Niksic @ 1998-09-02 14:35 ` Lars Magne Ingebrigtsen 1998-09-03 21:03 ` Suggestion: to problem nndraft "Can't select group" Lars Magne Ingebrigtsen ` (4 subsequent siblings) 23 siblings, 0 replies; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-09-02 14:35 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > Does string-to-number take new parameter in Emacs 20.x ? Yes; the radix. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Suggestion: to problem nndraft "Can't select group" [not found] ` <jari.aalto@poboxes.com> ` (18 preceding siblings ...) 1998-09-02 14:35 ` Lars Magne Ingebrigtsen @ 1998-09-03 21:03 ` Lars Magne Ingebrigtsen 1998-09-08 19:38 ` Patch: be verbose if POP3 setup is not ok Lars Magne Ingebrigtsen ` (3 subsequent siblings) 23 siblings, 0 replies; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-09-03 21:03 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > I posted before question why I couldn't select nndraft group which did > contain articles if I looked into directory. The server was open, the > path was okay, but still I got message > > Can't select group `M-g' the group. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Patch: be verbose if POP3 setup is not ok [not found] ` <jari.aalto@poboxes.com> ` (19 preceding siblings ...) 1998-09-03 21:03 ` Suggestion: to problem nndraft "Can't select group" Lars Magne Ingebrigtsen @ 1998-09-08 19:38 ` Lars Magne Ingebrigtsen 1998-09-08 21:04 ` Jari Aalto+list.ding 1998-10-12 14:07 ` compatibility request -- `q' in *Article* buffer shouldn't quit group Hrvoje Niksic ` (2 subsequent siblings) 23 siblings, 1 reply; 115+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-09-08 19:38 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > I'm currently trying to get my 2 POP3 acocunts integrated with gnus > and in the process I thought this would be nicer message to > user than just an cryptic error. [...] > + ;; expand-file-name below breaks if we don't check this. > + (unless (stringp nnmail-movemail-program) > + (with-output-to-temp-buffer "*Gnus Error*" > + (princ > + (message > + (concat "Your nnmail-movemail-program must be string " > + "or callable lisp function. \nPlease check " > + "your setup. Value was [%s]") > + (prin1-to-string nnmail-movemail-program)))) > + (error "Gnus: Error, Check nnmail-movemail-program")) There are a gazillion variables that can be strings, symbols, list or numbers, and if I were to add error messages like these to them all, Gnus would swell to several gazillion megabytes. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Patch: be verbose if POP3 setup is not ok 1998-09-08 19:38 ` Patch: be verbose if POP3 setup is not ok Lars Magne Ingebrigtsen @ 1998-09-08 21:04 ` Jari Aalto+list.ding 1998-09-09 11:35 ` Per Abrahamsen 0 siblings, 1 reply; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-09-08 21:04 UTC (permalink / raw) | 1998-09-08 Lars Magne Ingebrigtsen <larsi@gnus.org> list.ding | <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: | | > + ;; expand-file-name below breaks if we don't check this. | > + (unless (stringp nnmail-movemail-program) | > + (with-output-to-temp-buffer "*Gnus Error*" | > + (princ | > + (message | > + (concat "Your nnmail-movemail-program must be string " | > + "or callable lisp function. \nPlease check " | > + "your setup. Value was [%s]") | > + (prin1-to-string nnmail-movemail-program)))) | > + (error "Gnus: Error, Check nnmail-movemail-program")) | | There are a gazillion variables that can be strings, symbols, list or | numbers, and if I were to add error messages like these to them all, | Gnus would swell to several gazillion megabytes. Hoabout just adding the last `error' command in this case? The movemail setup is quite curcial if one starts to play with it (eg pop3 in my case) jari ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Patch: be verbose if POP3 setup is not ok 1998-09-08 21:04 ` Jari Aalto+list.ding @ 1998-09-09 11:35 ` Per Abrahamsen 1998-09-09 13:07 ` Jari Aalto+list.ding 0 siblings, 1 reply; 115+ messages in thread From: Per Abrahamsen @ 1998-09-09 11:35 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > The movemail setup is quite curcial if one starts to play with it > (eg pop3 in my case) Users who can't figure out the Lisp types should use the custom interface to set options. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Patch: be verbose if POP3 setup is not ok 1998-09-09 11:35 ` Per Abrahamsen @ 1998-09-09 13:07 ` Jari Aalto+list.ding 0 siblings, 0 replies; 115+ messages in thread From: Jari Aalto+list.ding @ 1998-09-09 13:07 UTC (permalink / raw) | 1998-09-09 Per Abrahamsen <abraham@dina.kvl.dk> list.ding | <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: | | > The movemail setup is quite curcial if one starts to play with it | > (eg pop3 in my case) | | Users who can't figure out the Lisp types should use the custom | interface to set options. I see nothing wrong in improving the error checking in selected parts of the code. Mistakes do happen and this time the type was correct when I set it. it was a lisp function symbol, but it wasn't fbound (I forgot to add autoload) so the Gnus went ahead to used it as shell command. Yes, It was my mistake, but it would have been good to test stringp/error before doing expand-file-name. That would have been more informative error. jari ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group [not found] ` <jari.aalto@poboxes.com> ` (20 preceding siblings ...) 1998-09-08 19:38 ` Patch: be verbose if POP3 setup is not ok Lars Magne Ingebrigtsen @ 1998-10-12 14:07 ` Hrvoje Niksic 1998-10-13 12:54 ` Robert Pluim 1998-10-22 13:16 ` I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) Hrvoje Niksic 1998-11-05 18:27 ` Feature req: import/export Group parameter or Server data Simon Josefsson 23 siblings, 1 reply; 115+ messages in thread From: Hrvoje Niksic @ 1998-10-12 14:07 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > | The phrase "backward compatibility" cannot apply here because TM has > | never been a part of Gnus. People who used TM did so "on their own > | responsibility". Incompatibly changing Gnus to satisfy former TM > | users would IMHO be plain wrong. > > C'mon. You're splitting hairs here. TM has been practically the de > facto standard for MIME since day 1 when it come in picture. Assert this many times won't make it less false than it was the first time around: many people haven't used TM. Many haven't even seen it. -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- * Q: What is an experienced Emacs user? * A: A person who wishes that the terminal had pedals. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: compatibility request -- `q' in *Article* buffer shouldn't quit group 1998-10-12 14:07 ` compatibility request -- `q' in *Article* buffer shouldn't quit group Hrvoje Niksic @ 1998-10-13 12:54 ` Robert Pluim 0 siblings, 0 replies; 115+ messages in thread From: Robert Pluim @ 1998-10-13 12:54 UTC (permalink / raw) >>>>> "Hrvoje" == Hrvoje Niksic <hniksic@srce.hr> writes: Hrvoje> <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: >> | The phrase "backward compatibility" cannot apply here because >> TM has | never been a part of Gnus. People who used TM did so >> "on their own | responsibility". Incompatibly changing Gnus to >> satisfy former TM | users would IMHO be plain wrong. >> >> C'mon. You're splitting hairs here. TM has been practically the >> de facto standard for MIME since day 1 when it come in picture. Hrvoje> Assert this many times won't make it less false than it Hrvoje> was the first time around: many people haven't used TM. Hrvoje> Many haven't even seen it. TM? Mime? What's that? If a news article contains stuff that a human can't decode easily, I skip it :-) [1][2] Robert Footnotes: [1] yes, I know about W m [2] I don't want no steenking HTML in postings -- Robert Pluim Tel: +33 4 92 96 17 43 Systems Development Engineer Fax: +33 4 92 96 15 32 <URL: mailto:rpluim@baynetworks.com> Bay Networks EMEA, 25 Allee Pierre Ziller, 06560 Valbonne, France ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) [not found] ` <jari.aalto@poboxes.com> ` (21 preceding siblings ...) 1998-10-12 14:07 ` compatibility request -- `q' in *Article* buffer shouldn't quit group Hrvoje Niksic @ 1998-10-22 13:16 ` Hrvoje Niksic 1998-11-05 18:27 ` Feature req: import/export Group parameter or Server data Simon Josefsson 23 siblings, 0 replies; 115+ messages in thread From: Hrvoje Niksic @ 1998-10-22 13:16 UTC (permalink / raw) <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > | 1998-10-21 Hrvoje Niksic <hniksic@srce.hr> list.ding > | > | ...the cleanup code that evaluates no matter what way we exit from the > | function -- including C-g. This is exactly what unwind-protect is for. > > This was something I wondered an hour ago in my own code. What > does "nonlocal" exist mean? Nonlocal exit means an exit via signal or throw. In the ``C'' terminology, it's longjmp. > And is it corect that cleanup is not done if debug is on? Cleanup is done either way. -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- If it's tourist season, why can't we shoot them? ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: Feature req: import/export Group parameter or Server data [not found] ` <jari.aalto@poboxes.com> ` (22 preceding siblings ...) 1998-10-22 13:16 ` I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) Hrvoje Niksic @ 1998-11-05 18:27 ` Simon Josefsson 23 siblings, 0 replies; 115+ messages in thread From: Simon Josefsson @ 1998-11-05 18:27 UTC (permalink / raw) Cc: Ding mailing list <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes: > So a simple Write/Read Group parameter data to a file would > be fine for now. A Map-through-groups toplevel function would > be next step. > > I also move data between several Emasc/Gnus in different sites, so > exporting, importing Group/Server data would be nice. I think a cleaner way to keep several Gnus configurations synchronized (it seems as this is the problem you're trying to solve) would be to use ACAP. This wouldn't synchronize localy stored mail of course, but you could use IMAP instead. http://andrew2.andrew.cmu.edu/cyrus/acap/ The ACAP protocol is much like the IMAP protocol, most of the code can be shared between them. ^ permalink raw reply [flat|nested] 115+ messages in thread
end of thread, other threads:[~1998-11-05 18:27 UTC | newest] Thread overview: 115+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-08-15 19:37 Marking new unread articles differently? Matt Simmons 1998-08-15 20:43 ` Lars Magne Ingebrigtsen 1998-08-15 21:03 ` SL Baur 1998-08-15 22:40 ` Lars Magne Ingebrigtsen 1998-08-15 21:14 ` Harry Putnam 1998-08-25 6:23 ` Matt Simmons 1998-08-15 21:20 ` Eze Ogwuma 1998-08-16 6:05 ` Mike McEwan 1998-08-16 18:30 ` Jari Aalto+list.ding -- strict thread matches above, loose matches on Subject: below -- 1998-11-05 16:52 Feature req: import/export Group parameter or Server data Jari Aalto+list.ding 1998-10-20 18:26 Pterodactyl Gnus v0.36 is released Lars Magne Ingebrigtsen 1998-10-20 19:27 ` *Group* buffer disappearance (Re: Pterodactyl Gnus v0.36 is released) Lloyd Zusman 1998-10-21 2:58 ` I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) Lloyd Zusman 1998-10-21 12:40 ` Hrvoje Niksic 1998-10-21 13:54 ` Lloyd Zusman 1998-10-21 14:22 ` Hrvoje Niksic 1998-10-21 14:55 ` Lloyd Zusman 1998-10-21 14:59 ` Hrvoje Niksic 1998-10-21 15:07 ` Lloyd Zusman 1998-10-21 15:10 ` Hrvoje Niksic 1998-10-21 15:17 ` Lloyd Zusman 1998-10-21 15:24 ` Hrvoje Niksic 1998-10-21 15:39 ` Lloyd Zusman 1998-10-21 15:48 ` Hrvoje Niksic 1998-10-21 15:56 ` Lee Willis 1998-10-22 13:10 ` Jari Aalto+list.ding 1998-10-11 6:48 compatibility request -- `q' in *Article* buffer shouldn't quit group SL Baur 1998-10-11 15:29 ` Lars Magne Ingebrigtsen 1998-10-11 17:11 ` Matt Simmons 1998-10-11 17:23 ` Hrvoje Niksic 1998-10-11 19:05 ` SL Baur 1998-10-11 19:11 ` Hrvoje Niksic 1998-10-11 20:40 ` SL Baur 1998-10-11 20:44 ` Hrvoje Niksic 1998-10-11 21:24 ` Karl Kleinpaste 1998-10-11 21:41 ` Hrvoje Niksic 1998-10-11 22:18 ` Kai Grossjohann 1998-10-12 10:08 ` Lloyd Zusman 1998-10-12 13:12 ` Lars Magne Ingebrigtsen 1998-10-12 22:17 ` Lloyd Zusman 1998-10-17 19:21 ` Lars Magne Ingebrigtsen 1998-10-12 13:39 ` Per Abrahamsen 1998-10-12 14:01 ` Jari Aalto+list.ding 1998-10-11 22:13 ` Kai Grossjohann [not found] ` <6f7ly7i16q.fsf@dna.lth.se> 1998-10-11 15:41 ` Michael Harnois 1998-10-11 15:50 ` Hrvoje Niksic 1998-10-11 16:34 ` Michael Harnois [not found] ` <6fiuhrgkq1.fsf@dna.lth.se> 1998-10-11 16:36 ` Michael Harnois 1998-10-11 17:08 ` Lars Magne Ingebrigtsen 1998-10-11 17:35 ` Hrvoje Niksic 1998-10-11 17:57 ` Lars Magne Ingebrigtsen 1998-10-11 18:28 ` Julian Assange 1998-09-08 16:08 Patch: be verbose if POP3 setup is not ok Jari Aalto+list.ding 1998-09-03 15:57 Suggestion: to problem nndraft "Can't select group" Jari Aalto+list.ding 1998-09-03 17:10 ` David S. Goldberg 1998-09-03 17:31 ` Jari Aalto+list.ding 1998-09-02 13:26 Hallvard's gnus-e20/19.34/Pgnus 0.13 emulation (backtrace included) Jari Aalto+list.ding 1998-08-24 22:12 Suggestion: Topic mode get news and topic group indentation level Jari Aalto+list.ding 1998-08-22 15:12 patch: 5.6.38 gnus-uu, new regexp marking commands Jari Aalto+list.ding 1998-08-21 15:49 Suggestion: *Group* SPC to show only new articles? Jari Aalto+list.ding 1998-08-21 9:35 pop3 reading with gnus? jari.aalto 1998-08-21 9:56 ` Jean-Yves Perrier 1998-08-21 10:09 ` Jari Aalto+list.ding 1998-08-20 20:29 5.6.38 Can't read drafts server? Jari Aalto+list.ding 1998-08-19 15:57 Suggestion: Command to rename all Subejcts in thread Jari Aalto+list.ding 1998-08-17 9:04 Master or slave?? Andy Eskilsson [not found] ` <6flnooezsi.fsf@bavur.dna.lth.se> 1998-08-17 11:27 ` Jari Aalto+list.ding 1998-08-17 14:44 ` Andy Eskilsson 1998-08-13 14:39 request: commands for subsribe/unsubsribe from/to mailing lists Jari Aalto+list.ding [not found] ` <jari.aalto@poboxes.com> 1998-08-13 16:35 ` Jason L Tibbitts III 1998-08-13 16:56 ` Lars Magne Ingebrigtsen 1998-08-13 18:27 ` William M. Perry 1998-08-19 17:30 ` Christopher Davis 1998-08-13 16:41 ` Lars Magne Ingebrigtsen 1998-08-13 17:21 ` Bud Rogers 1998-08-17 13:06 ` Master or slave?? Lars Magne Ingebrigtsen 1998-08-19 0:52 ` Marking new unread articles differently? Mike McEwan 1998-08-20 21:23 ` Lars Magne Ingebrigtsen 1998-08-21 17:11 ` Mike McEwan 1998-08-21 19:15 ` Lars Magne Ingebrigtsen 1998-08-25 6:25 ` Matt Simmons 1998-08-26 3:46 ` Mike McEwan 1998-08-20 1:26 ` Suggestion: Command to rename all Subejcts in thread Lars Magne Ingebrigtsen 1998-08-20 8:46 ` Jari Aalto+list.ding 1998-08-20 19:41 ` Lars Magne Ingebrigtsen 1998-08-20 21:19 ` 5.6.38 Can't read drafts server? Lars Magne Ingebrigtsen 1998-08-21 6:38 ` Jari Aalto+list.ding 1998-08-21 11:52 ` Karl Kleinpaste 1998-08-21 19:09 ` Lars Magne Ingebrigtsen 1998-08-23 21:20 ` Jari Aalto+list.ding 1998-08-21 19:10 ` pop3 reading with gnus? Lars Magne Ingebrigtsen 1998-08-21 20:05 ` William M. Perry 1998-08-21 19:13 ` Suggestion: *Group* SPC to show only new articles? Lars Magne Ingebrigtsen 1998-08-22 20:57 ` patch: 5.6.38 gnus-uu, new regexp marking commands Lars Magne Ingebrigtsen 1998-08-24 7:30 ` Suggestion: *Group* SPC to show only new articles? Kai Grossjohann 1998-08-24 8:37 ` Jari Aalto+list.ding 1998-08-24 8:48 ` Kai Grossjohann 1998-08-24 10:10 ` Jari Aalto+list.ding 1998-08-24 11:41 ` Kai Grossjohann 1998-08-24 12:20 ` Francisco Solsona 1998-08-24 14:38 ` Mike McEwan 1998-08-25 5:55 ` 5.6.38 Can't read drafts server? Lars Magne Ingebrigtsen 1998-08-25 13:05 ` Jari Aalto+list.ding 1998-08-25 6:11 ` Suggestion: Topic mode get news and topic group indentation level Lars Magne Ingebrigtsen 1998-09-02 14:34 ` Hallvard's gnus-e20/19.34/Pgnus 0.13 emulation (backtrace included) Hrvoje Niksic 1998-09-02 14:35 ` Lars Magne Ingebrigtsen 1998-09-03 21:03 ` Suggestion: to problem nndraft "Can't select group" Lars Magne Ingebrigtsen 1998-09-08 19:38 ` Patch: be verbose if POP3 setup is not ok Lars Magne Ingebrigtsen 1998-09-08 21:04 ` Jari Aalto+list.ding 1998-09-09 11:35 ` Per Abrahamsen 1998-09-09 13:07 ` Jari Aalto+list.ding 1998-10-12 14:07 ` compatibility request -- `q' in *Article* buffer shouldn't quit group Hrvoje Niksic 1998-10-13 12:54 ` Robert Pluim 1998-10-22 13:16 ` I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) Hrvoje Niksic 1998-11-05 18:27 ` Feature req: import/export Group parameter or Server data Simon Josefsson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).