* editing nnimap articles @ 2009-10-08 19:05 Dan Christensen 2009-10-09 14:39 ` Ted Zlatanov 0 siblings, 1 reply; 13+ messages in thread From: Dan Christensen @ 2009-10-08 19:05 UTC (permalink / raw) To: ding I receive so many attachments that I find it necessary to use gnus-mime-save-part-and-strip to delete them from my archived messages. I'm in the process of converting from nnfolder to nnimap, and so I'd like to investigate how hard it would be to extend nnimap to allow article editing. My sense is that it should not be hard, since it just requires the creation of a new article and the deletion of the old one, and both of those are operations that nnimap can perform. (In fact, I just noticed that `B I' is able to create a new empty article in an nnimap group.) In digging through the code, it looks to me like what would be needed would be an implementation of nnimap-request-replace-article. Would that just be a matter of combining nnimap-request-accept-article with something like (imap-message-flags-add (format "%d" article) "\\Seen \\Deleted") ? Would this work? Can someone help me fill in the details? Thanks, Dan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: editing nnimap articles 2009-10-08 19:05 editing nnimap articles Dan Christensen @ 2009-10-09 14:39 ` Ted Zlatanov 2009-10-09 14:48 ` David Engster 0 siblings, 1 reply; 13+ messages in thread From: Ted Zlatanov @ 2009-10-09 14:39 UTC (permalink / raw) To: ding On Thu, 08 Oct 2009 15:05:34 -0400 Dan Christensen <jdc@uwo.ca> wrote: DC> I receive so many attachments that I find it necessary to use DC> gnus-mime-save-part-and-strip to delete them from my archived messages. DC> I'm in the process of converting from nnfolder to nnimap, and so I'd DC> like to investigate how hard it would be to extend nnimap to allow DC> article editing. DC> My sense is that it should not be hard, since it just requires the DC> creation of a new article and the deletion of the old one, and both of DC> those are operations that nnimap can perform. (In fact, I just noticed DC> that `B I' is able to create a new empty article in an nnimap group.) DC> In digging through the code, it looks to me like what would be needed DC> would be an implementation of nnimap-request-replace-article. DC> Would that just be a matter of combining nnimap-request-accept-article DC> with something like DC> (imap-message-flags-add (format "%d" article) DC> "\\Seen \\Deleted") DC> ? DC> Would this work? Can someone help me fill in the details? With IMAP, you have to expunge as well, but then you may expunge other deleted articles at the wrong time. So you may just have to live with the old \\Deleted article until the next time the user or Gnus expunges the group, and it will still show up in the summary buffer. I think that's acceptable. It would be good if this edit told the registry about the changeover by getting the record for the old message ID and storing it with the new one. I can add that hook. Otherwise this looks good to me, I'm all for it. I've been doing it the roundabout way (move to nnmaildir, edit, move back) for years. Ted ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: editing nnimap articles 2009-10-09 14:39 ` Ted Zlatanov @ 2009-10-09 14:48 ` David Engster 2009-10-09 15:06 ` Ted Zlatanov 0 siblings, 1 reply; 13+ messages in thread From: David Engster @ 2009-10-09 14:48 UTC (permalink / raw) To: ding Ted Zlatanov <tzz@lifelogs.com> writes: > On Thu, 08 Oct 2009 15:05:34 -0400 Dan Christensen <jdc@uwo.ca> wrote: > DC> I receive so many attachments that I find it necessary to use > DC> gnus-mime-save-part-and-strip to delete them from my archived messages. > DC> I'm in the process of converting from nnfolder to nnimap, and so I'd > DC> like to investigate how hard it would be to extend nnimap to allow > DC> article editing. [...] > DC> In digging through the code, it looks to me like what would be needed > DC> would be an implementation of nnimap-request-replace-article. > DC> Would that just be a matter of combining nnimap-request-accept-article > DC> with something like > > DC> (imap-message-flags-add (format "%d" article) > DC> "\\Seen \\Deleted") > DC> ? > > DC> Would this work? Can someone help me fill in the details? [...] > Otherwise this looks good to me, I'm all for it. I've been doing it the > roundabout way (move to nnmaildir, edit, move back) for years. The problem is that the *-request-replace-article function is required to really *replace* the article, i.e., the article number must remain the same. This is not possible with IMAP. I would also welcome a 'strip attachments' function for IMAP, but it shouldn't be done through a nnimap-request-replace-article function. Regards, David ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: editing nnimap articles 2009-10-09 14:48 ` David Engster @ 2009-10-09 15:06 ` Ted Zlatanov 2009-10-09 15:29 ` David Engster 0 siblings, 1 reply; 13+ messages in thread From: Ted Zlatanov @ 2009-10-09 15:06 UTC (permalink / raw) To: ding On Fri, 09 Oct 2009 16:48:21 +0200 David Engster <deng@randomsample.de> wrote: DE> The problem is that the *-request-replace-article function is required DE> to really *replace* the article, i.e., the article number must remain DE> the same. This is not possible with IMAP. Looking at gnus-request-replace-article, I don't see a problem if the function returns nil. So, if nnimap-request-replace-article returns nil and (as a side effect) deletes the old article and creates the new one, that should do what the user expects. It's not ideal but I think it's better than a new special gnus-request-replace-by-appending-article function or a new flag for gnus-request-replace-article. All of this is untested, so please tell me if I'm speaking nonsense. Ted ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: editing nnimap articles 2009-10-09 15:06 ` Ted Zlatanov @ 2009-10-09 15:29 ` David Engster 2009-10-09 15:42 ` Ted Zlatanov 0 siblings, 1 reply; 13+ messages in thread From: David Engster @ 2009-10-09 15:29 UTC (permalink / raw) To: ding Ted Zlatanov <tzz@lifelogs.com> writes: > On Fri, 09 Oct 2009 16:48:21 +0200 David Engster <deng@randomsample.de> wrote: > > DE> The problem is that the *-request-replace-article function is required > DE> to really *replace* the article, i.e., the article number must remain > DE> the same. This is not possible with IMAP. > > Looking at gnus-request-replace-article, I don't see a problem if the > function returns nil. So, if nnimap-request-replace-article returns nil > and (as a side effect) deletes the old article and creates the new one, > that should do what the user expects. It's not ideal but I think it's > better than a new special gnus-request-replace-by-appending-article > function or a new flag for gnus-request-replace-article. The return value is not a problem; 'request-replace-article' is not supposed to return any data. But the docs say: `(nnchoke-request-replace-article ARTICLE GROUP BUFFER)' This function should remove ARTICLE (which is a number) from GROUP and insert BUFFER there instead. There should be no data returned. While not explicitly stated, I read this in the sense that the article number stays the same. I admit I do not know if there is any code in (or outside) Gnus which depends on that, but I'm just uncomfortable with implementing article editing for a mail protocol which simply doesn't support it (even forbids it). I think it would be better to implement this outside the back end API. Just my opinion, though. :-) Regards, David ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: editing nnimap articles 2009-10-09 15:29 ` David Engster @ 2009-10-09 15:42 ` Ted Zlatanov 2009-10-09 16:07 ` Dan Christensen 2009-10-09 18:53 ` David Engster 0 siblings, 2 replies; 13+ messages in thread From: Ted Zlatanov @ 2009-10-09 15:42 UTC (permalink / raw) To: ding On Fri, 09 Oct 2009 17:29:11 +0200 David Engster <deng@randomsample.de> wrote: DE> The return value is not a problem; 'request-replace-article' is not DE> supposed to return any data. But the docs say: DE> `(nnchoke-request-replace-article ARTICLE GROUP BUFFER)' DE> This function should remove ARTICLE (which is a number) from GROUP DE> and insert BUFFER there instead. DE> There should be no data returned. DE> While not explicitly stated, I read this in the sense that the article DE> number stays the same. ...and it does, it's just that we delete that article and the contents are not modified. That should all be OK. DE> I admit I do not know if there is any code in (or outside) Gnus DE> which depends on that, but I'm just uncomfortable with implementing DE> article editing for a mail protocol which simply doesn't support it DE> (even forbids it). I think it would be better to implement this DE> outside the back end API. Just my opinion, though. :-) Our users, myself included, have needed this functionality for years. Obviously it's available by moving the article out, editing in another backend, and moving it back, so we're just making it easier. If you think `e' in IMAP groups should do something special (that's how I understand your suggestion about "outside"), that's possible too. I'd rather have it go through the backend so the agent, registry, and any hooks have a chance to get run. But I'm easily swayed: why shouldn't it go through the backend, besides feeling hacky? Ted ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: editing nnimap articles 2009-10-09 15:42 ` Ted Zlatanov @ 2009-10-09 16:07 ` Dan Christensen 2009-10-09 18:53 ` David Engster 1 sibling, 0 replies; 13+ messages in thread From: Dan Christensen @ 2009-10-09 16:07 UTC (permalink / raw) To: ding One advantage of doing it with request-replace-article is that several things all start working: - plain editing - strip and save attachments - `B I' and related commands etc. On the other hand, we could instead create a new backend function request-replace-append, which by default just calls request-replace but is overridden by nnimap. I think only one place would need to be changed in the edit call graph in order to make all of the operations above start working for nnimap. But unless there is a specific problem with just implementing request-replace for nnimap, I would go with the more direct solution. (However, I only know the Gnus internals at a very superficial level, so don't put much weight on my opinion.) Dan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: editing nnimap articles 2009-10-09 15:42 ` Ted Zlatanov 2009-10-09 16:07 ` Dan Christensen @ 2009-10-09 18:53 ` David Engster 2009-10-09 21:19 ` Ted Zlatanov 1 sibling, 1 reply; 13+ messages in thread From: David Engster @ 2009-10-09 18:53 UTC (permalink / raw) To: ding Ted Zlatanov <tzz@lifelogs.com> writes: > On Fri, 09 Oct 2009 17:29:11 +0200 David Engster <deng@randomsample.de> wrote: > > DE> The return value is not a problem; 'request-replace-article' is not > DE> supposed to return any data. But the docs say: > > DE> `(nnchoke-request-replace-article ARTICLE GROUP BUFFER)' > DE> This function should remove ARTICLE (which is a number) from GROUP > DE> and insert BUFFER there instead. > > DE> There should be no data returned. > > DE> While not explicitly stated, I read this in the sense that the article > DE> number stays the same. > > ...and it does, it's just that we delete that article and the contents > are not modified. That should all be OK. Maybe I'm understanding something wrong here. Say you'd like to edit the mail with article number '10' in INBOX. So you hit 'e' and edit away. After committing the change, the mail number '10' will not exist anymore, but there will be a new article, containing the edited text, but with an article number whatever the IMAP server chose to use (as long as it wasn't used before). Therefore, you did not really 'edit' the article, but created a new one. Regards, David ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: editing nnimap articles 2009-10-09 18:53 ` David Engster @ 2009-10-09 21:19 ` Ted Zlatanov 2009-10-10 0:11 ` Dan Christensen 2009-10-10 8:37 ` David Engster 0 siblings, 2 replies; 13+ messages in thread From: Ted Zlatanov @ 2009-10-09 21:19 UTC (permalink / raw) To: ding On Fri, 09 Oct 2009 20:53:47 +0200 David Engster <deng@randomsample.de> wrote: DE> Maybe I'm understanding something wrong here. Say you'd like to edit the DE> mail with article number '10' in INBOX. So you hit 'e' and edit DE> away. After committing the change, the mail number '10' will not exist DE> anymore, but there will be a new article, containing the edited text, DE> but with an article number whatever the IMAP server chose to use (as DE> long as it wasn't used before). DE> Therefore, you did not really 'edit' the article, but created a new DE> one. Right. The proposal will make replacing the article fail and as a side effect create a new one and delete this one. I think it's justified; why shouldn't we do it? Does it break anything? On Fri, 09 Oct 2009 12:07:44 -0400 Dan Christensen <jdc@uwo.ca> wrote: DC> One advantage of doing it with request-replace-article is that several DC> things all start working: DC> - plain editing DC> - strip and save attachments DC> - `B I' and related commands DC> etc. DC> On the other hand, we could instead create a new backend function DC> request-replace-append, which by default just calls request-replace but DC> is overridden by nnimap. I think only one place would need to be DC> changed in the edit call graph in order to make all of the operations DC> above start working for nnimap. DC> But unless there is a specific problem with just implementing DC> request-replace for nnimap, I would go with the more direct solution. DC> (However, I only know the Gnus internals at a very superficial level, DC> so don't put much weight on my opinion.) As far as I understand the internals, I think adding a new backend function for the sake of IMAP is not worth it. It's less effort to change the docs to explain the exception as long as it's just one exception. As soon as it extends to 2 or more, it's time to refactor. We could also make the functionality more generic by indicating (as a backend nnvoo parameter) that the backend is append-only. Then we still use request-replace but it's less magical and other functions can look at that parameter. Ted ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: editing nnimap articles 2009-10-09 21:19 ` Ted Zlatanov @ 2009-10-10 0:11 ` Dan Christensen 2009-10-10 2:03 ` Dan Christensen 2009-10-10 8:37 ` David Engster 1 sibling, 1 reply; 13+ messages in thread From: Dan Christensen @ 2009-10-10 0:11 UTC (permalink / raw) To: ding I suggest we try it and see whether anything breaks. If something breaks, it'll be easy to copy the code from request-replace to a new function. So, can someone give pointers about how to proceed? I'll see what I can come up with, but having never used nnimap (or looked at the code) before a few days ago, some tips would speed things up. Thanks, Dan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: editing nnimap articles 2009-10-10 0:11 ` Dan Christensen @ 2009-10-10 2:03 ` Dan Christensen 2009-10-25 0:50 ` Dan Christensen 0 siblings, 1 reply; 13+ messages in thread From: Dan Christensen @ 2009-10-10 2:03 UTC (permalink / raw) To: ding Dan Christensen <jdc@uwo.ca> writes: > I suggest we try it and see whether anything breaks. If something > breaks, it'll be easy to copy the code from request-replace to a new > function. > > So, can someone give pointers about how to proceed? I'll see what I > can come up with, but having never used nnimap (or looked at the code) > before a few days ago, some tips would speed things up. Here's a very rough attempt, that is already useful: (deffoo nnimap-request-replace-article (article group buffer) (and (with-current-buffer buffer (nnimap-request-accept-article group)) (nnimap-possibly-change-group group) (imap-message-flags-add (imap-range-to-message-set (list article)) "\\Deleted" 'silent nnimap-server-buffer))) Some important missing things: - copying the marks - refreshing the summary buffer to exclude the Deleted article and include the new article - documentation - registry? - nov handling? - anything else? It occurred to me that what this does is very close to what `B m' (gnus-summary-move-article) does, except that we use our newly edited buffer instead of the original article. Maybe we can set a global variable such as nnimap-request-accept-buffer to the buffer containing the replacement, adjust nnimap-request-article to notice this and use that buffer instead of the current buffer, and then just call gnus-summary-move-article? It should already handle copying the marks, and most other things that needs to be done (except refreshing the summary buffer). I tried to do it this way in the enclosed patch, but I get an error I haven't been able to figure out (see below). Dan --- nnimap.orig.el 2009-09-30 12:56:46.000000000 -0400 +++ nnimap.el 2009-10-09 21:57:02.000000000 -0400 @@ -1564,6 +1563,7 @@ (nnimap-current-move-article article) (nnimap-current-move-group group) (nnimap-current-move-server nnimap-current-server) + (move-is-internal (and move-is-internal (not nnimap-request-accept-buffer))) result) (gnus-message 10 "nnimap-request-move-article: this is an %s move" (if move-is-internal @@ -1584,6 +1584,7 @@ "\\Deleted" 'silent nnimap-server-buffer)) result)))) +(setq nnimap-request-accept-buffer nil) (deffoo nnimap-request-accept-article (group &optional server last) (when (nnimap-possibly-change-server server) (let (uid) @@ -1596,7 +1597,7 @@ nnimap-current-move-article) group 'dontcreate nil nnimap-server-buffer)) - (with-current-buffer (current-buffer) + (with-current-buffer (or nnimap-request-accept-buffer (current-buffer)) (goto-char (point-min)) ;; remove any 'From blabla' lines, some IMAP servers ;; reject the entire message otherwise. @@ -1619,6 +1620,14 @@ (cons group (nth 1 uid)) (nnheader-report 'nnimap (imap-error-text nnimap-server-buffer)))))) +(deffoo nnimap-request-replace-article (article group buffer) + (let ((nnimap-request-accept-buffer buffer) + (gnusgroup (gnus-group-prefixed-name + group (gnus-server-to-method + (format "nnimap:%s" nnimap-current-server))))) + (nnimap-request-article article group) + (gnus-summary-move-article 1 gnusgroup))) + (deffoo nnimap-request-delete-group (group force &optional server) (when (nnimap-possibly-change-server server) (when (string= group (imap-current-mailbox nnimap-server-buffer)) Debugger entered--Lisp error: (wrong-type-argument consp nil) gnus-summary-move-article(1 "nnimap+jdc:test") (let ((nnimap-request-accept-buffer buffer) (gnusgroup ...)) (nnimap-request-article article group) (message "gnusgroup %s" gnusgroup) (gnus-summary-move-article 1 gnusgroup)) ad-Orig-nnimap-request-replace-article(1906 "test" #<buffer *temp*>) nnimap-request-replace-article(1906 "test" #<buffer *temp*>) gnus-request-replace-article(1906 "nnimap+jdc:test" #<buffer *temp*> t) gnus-summary-edit-article-done("" nil #<buffer *Summary nnimap+jdc:test*> nil) (let ((mail-parse-charset ...) (message-options message-options) (message-options-set-recipient) (mail-parse-ignored-charsets ...) (rfc2047-header-encoding-alist ...)) (progn (mml-to-mime) (mml-destroy-buffers) (remove-hook ... ... t) (kill-local-variable ...)) (gnus-summary-edit-article-done "" nil #<buffer *Summary nnimap+jdc:test*> no-highlight)) (lambda (no-highlight) (let (... ... ... ... ...) (progn ... ... ... ...) (gnus-summary-edit-article-done "" nil #<buffer *Summary nnimap+jdc:test*> no-highlight)))(nil) gnus-article-edit-done(nil) call-interactively(gnus-article-edit-done nil nil) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: editing nnimap articles 2009-10-10 2:03 ` Dan Christensen @ 2009-10-25 0:50 ` Dan Christensen 0 siblings, 0 replies; 13+ messages in thread From: Dan Christensen @ 2009-10-25 0:50 UTC (permalink / raw) To: ding [-- Attachment #1: Type: text/plain, Size: 8690 bytes --] Here's a slightly improved attempt to allow article editing using IMAP. I copied some code from gnus-summary-move-article to flag the deleted article with gnus-canceled-mark, and I also call gnus-summary-insert-new-articles. (deffoo nnimap-request-replace-article (article group buffer) (and (with-current-buffer buffer (nnimap-request-accept-article group)) (nnimap-possibly-change-group group) (imap-message-flags-add (imap-range-to-message-set (list article)) "\\Deleted" 'silent nnimap-server-buffer) (set-buffer gnus-summary-buffer) (gnus-summary-goto-subject article) (gnus-summary-mark-article article gnus-canceled-mark) (gnus-summary-insert-new-articles) (gnus-summary-position-point) (gnus-set-mode-line 'summary))) Some things still missing: - copy the marks - select the new article - documentation - registry? - nov handling? - dribble buffer? - anything else? But gnus-summary-move-article is 291 lines long, so I'm still thinking that since we really are moving the article, it would be better to simply call gnus-summary-move-article instead of reproducing a lot of the functionality, by having a flag indicating that a different buffer should be used for the destination article. My attempt at doing this (patch below) doesn't work, probably because of some assumptions about context when some functions are called. However I suspect it shouldn't be too hard to fix, if I understood the problem. I currently get the following backtrace: setcdr(nil 29) (progn (push (cons to-article gnus-read-mark) gnus-newsgroup-reads) (setcdr (gnus-active to-group) to-article) (setcdr gnus-newsgroup-active to-article)) (if (and (equal to-group gnus-newsgroup-name) (not ...)) (progn (push ... gnus-newsgroup-reads) (setcdr ... to-article) (setcdr gnus-newsgroup-active to-article))) (when (and (equal to-group gnus-newsgroup-name) (not ...)) (push (cons to-article gnus-read-mark) gnus-newsgroup-reads) (setcdr (gnus-active to-group) to-article) (setcdr gnus-newsgroup-active to-article)) (progn (when (and ... ...) (push ... gnus-newsgroup-reads) (setcdr ... to-article) (setcdr gnus-newsgroup-active to-article)) (while marks (when ... ...) (setq marks ...)) (when (and expirable gnus-mark-copied-or-moved-articles-as-expirable ...) (push ... to-marks) (when ... ...) (gnus-add-marked-articles to-group ... ... info)) (gnus-request-set-mark to-group (list ...))) (if gnus-preserve-marks (progn (when ... ... ... ...) (while marks ... ...) (when ... ... ... ...) (gnus-request-set-mark to-group ...))) (when gnus-preserve-marks (when (and ... ...) (push ... gnus-newsgroup-reads) (setcdr ... to-article) (setcdr gnus-newsgroup-active to-article)) (while marks (when ... ...) (setq marks ...)) (when (and expirable gnus-mark-copied-or-moved-articles-as-expirable ...) (push ... to-marks) (when ... ...) (gnus-add-marked-articles to-group ... ... info)) (gnus-request-set-mark to-group (list ...))) (let* ((expirable ...) (marks ...) (to-article ...)) (when gnus-use-cache (gnus-cache-possibly-enter-article to-group to-article ... ... ...)) (when gnus-preserve-marks (when ... ... ... ...) (while marks ... ...) (when ... ... ... ...) (gnus-request-set-mark to-group ...)) (gnus-dribble-enter (concat "(gnus-group-set-info '" ... ")"))) (progn (unless (member to-group to-groups) (push to-group to-groups)) (unless (memq article gnus-newsgroup-unreads) (push ... to-marks) (gnus-info-set-read info ...)) (let* (... ... ...) (when gnus-use-cache ...) (when gnus-preserve-marks ... ... ... ...) (gnus-dribble-enter ...))) (if (and info (memq action ...)) (progn (unless ... ...) (unless ... ... ...) (let* ... ... ... ...))) (when (and info (memq action ...)) (unless (member to-group to-groups) (push to-group to-groups)) (unless (memq article gnus-newsgroup-unreads) (push ... to-marks) (gnus-info-set-read info ...)) (let* (... ... ...) (when gnus-use-cache ...) (when gnus-preserve-marks ... ... ... ...) (gnus-dribble-enter ...))) (let* ((pto-group ...) (info ...) (to-group ...) to-marks) (when (and info ...) (unless ... ...) (unless ... ... ...) (let* ... ... ... ...)) (when (eq action ...) (with-current-buffer copy-buf ... ... ...)) (run-hook-with-args (quote gnus-summary-article-move-hook) action (gnus-data-header ...) gnus-newsgroup-name to-newsgroup select-method)) (cond ((not art-group) (gnus-message 1 "Couldn't %s article %s: %s" ... article ...)) ((eq art-group ...) (when ... ... ... ...)) (t (let* ... ... ... ...) (set-buffer gnus-summary-buffer) (gnus-summary-goto-subject article) (when ... ...))) (while articles (setq article (pop articles)) (setq art-group (cond ... ... ...)) (cond (... ...) (... ...) (t ... ... ... ...)) (push article articles-to-update-marks)) (let ((articles ...) (prefix ...) (names ...) (copy-buf ...) art-group to-method new-xref article to-groups articles-to-update-marks encoded) (unless (assq action names) (error "Unknown action %s" action)) (when (and ... ...) (if ... ...) (setq to-newsgroup ... encoded to-newsgroup to-method ...) (set ... ...)) (unless to-method (setq to-method ...)) (setq to-newsgroup (or encoded ...)) (unless (gnus-check-backend-function ... ...) (error "%s does not support article copying" ...)) (unless (gnus-check-server to-method) (error "Can't open server %s" ...)) (gnus-message 6 "%s to %s: %s..." (caddr ...) (or ... ...) articles) (while articles (setq article ...) (setq art-group ...) (cond ... ... ...) (push article articles-to-update-marks)) (apply (quote gnus-summary-remove-process-mark) arti cles-to-update-marks) (with-current-buffer gnus-group-buffer (let ... ...)) (gnus-kill-buffer copy-buf) (gnus-summary-position-point) (gnus-set-mode-line (quote summary))) gnus-summary-move-article(1 "nnimap+rocky:test") nnimap-request-replace-article(28 "test" #<buffer *temp*>) gnus-request-replace-article(28 "nnimap+rocky:test" #<buffer *temp*> t) (not (gnus-request-replace-article (cdr gnus-article-current) (car gnus-article-current) (current-buffer) t)) (and (not read-only) (not (gnus-request-replace-article ... ... ... t))) (if (and (not read-only) (not ...)) (error "Couldn't replace article") (if (and references ...) (save-excursion ...) (set-buffer ...) (gnus-summary-update-article ...) (if ... ...)) (unless no-highlight (with-current-buffer gnus-article-buffer ... ...)) (when (gnus-visual-p ... ...) (gnus-run-hooks ...))) (progn (insert-buffer-substring buf) (if (and ... ...) (error "Couldn't replace article") (if ... ... ... ... ...) (unless no-highlight ...) (when ... ...))) (unwind-protect (progn (insert-buffer-substring buf) (if ... ... ... ... ...)) (and (buffer-name temp-buffer) (kill-buffer temp-buffer))) (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn ... ...) (and ... ...))) (with-current-buffer temp-buffer (unwind-protect (progn ... ...) (and ... ...))) (let ((temp-buffer ...)) (with-current-buffer temp-buffer (unwind-protect ... ...))) (with-temp-buffer (insert-buffer-substring buf) (if (and ... ...) (error "Couldn't replace article") (if ... ... ... ... ...) (unless no-highlight ...) (when ... ...))) (let ((buf ...)) (with-temp-buffer (insert-buffer-substring buf) (if ... ... ... ... ...))) gnus-summary-edit-article-done("<20091016164135.GA24802@homotopy13.math.uwo.ca> <b0fdd0cf0910160959g684e31a6i540de7c479cb6c2e@mail.gmail.com> <87r5t0u3xs.fsf@uwo.ca> <b0fdd0cf0910190657k176a415u1d138dbe3594b262@mail.gmail.com> <87tyxvv0ne.fsf@jdc.math.uwo.ca>" nil #<buffer *Summary nnimap+rocky:test*> nil) (let ((mail-parse-charset ...) (message-options message-options) (message-options-set-recipient) (mail-parse-ignored-charsets ...) (rfc2047-header-encoding-alist ...)) (progn (mml-to-mime) (mml-destroy-buffers) (remove-hook ... ... t) (kill-local-variable ...)) (gnus-summary-edit-article-done "<20091016164135.GA24802@homotopy13.math.uwo.ca> <b0fdd0cf0910160959g684e31a6i540de7c479cb6c2e@mail.gmail.com> <87r5t0u3xs.fsf@uwo.ca> <b0fdd0cf0910190657k176a415u1d138dbe3594b262@mail.gmail.com> <87tyxvv0ne.fsf@jdc.math.uwo.ca>" nil #<buffer *Summary nnimap+rocky:test*> no-highlight)) (lambda (no-highlight) (let (... ... ... ... ...) (progn ... ... ... ...) (gnus-summary-edit-article-done "<20091016164135.GA24802@homotopy13.math.uwo.ca> <b0fdd0cf0910160959g684e31a6i540de7c479cb6c2e@mail.gmail.com> <87r5t0u3xs.fsf@uwo.ca> <b0fdd0cf0910190657k176a415u1d138dbe3594b262@mail.gmail.com> <87tyxvv0ne.fsf@jdc.math.uwo.ca>" nil #<buffer *Summary nnimap+rocky:test*> no-highlight)))(nil) gnus-article-edit-done(nil) call-interactively(gnus-article-edit-done nil nil) Thanks for any help. Dan [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: nnimap.el.diff --] [-- Type: text/x-diff, Size: 2549 bytes --] --- nnimap.orig.el 2009-09-30 12:56:46.000000000 -0400 +++ nnimap-nogood.el 2009-10-24 20:42:16.000000000 -0400 @@ -52,7 +52,6 @@ ;; o IMAP2BIS compatibility? (RFC2061) ;; o ACAP stuff (perhaps a different project, would be nice to ACAPify ;; .newsrc.eld) -;; o What about Gnus's article editing, can we support it? NO! ;; o Use \Draft to support the draft group?? ;; o Duplicate suppression ;; o Rewrite UID SEARCH UID X as UID FETCH X (UID) for those with slow servers @@ -1564,6 +1563,7 @@ (nnimap-current-move-article article) (nnimap-current-move-group group) (nnimap-current-move-server nnimap-current-server) + (move-is-internal (and move-is-internal (not nnimap-request-accept-buffer))) result) (gnus-message 10 "nnimap-request-move-article: this is an %s move" (if move-is-internal @@ -1584,6 +1584,7 @@ "\\Deleted" 'silent nnimap-server-buffer)) result)))) +(setq nnimap-request-accept-buffer nil) (deffoo nnimap-request-accept-article (group &optional server last) (when (nnimap-possibly-change-server server) (let (uid) @@ -1596,7 +1597,7 @@ nnimap-current-move-article) group 'dontcreate nil nnimap-server-buffer)) - (with-current-buffer (current-buffer) + (with-current-buffer (or nnimap-request-accept-buffer (current-buffer)) (goto-char (point-min)) ;; remove any 'From blabla' lines, some IMAP servers ;; reject the entire message otherwise. @@ -1619,6 +1620,16 @@ (cons group (nth 1 uid)) (nnheader-report 'nnimap (imap-error-text nnimap-server-buffer)))))) +(deffoo nnimap-request-replace-article (article group buffer) + (let ((nnimap-request-accept-buffer buffer) + (gnusgroup (gnus-group-prefixed-name + group (gnus-server-to-method + (format "nnimap:%s" nnimap-current-server))))) + ; With or without the next line I get a backtrace, but it changes: + ;(nnimap-request-article article group) + (message "%s" (list article group nnimap-request-accept-buffer gnusgroup)) + (gnus-summary-move-article 1 gnusgroup))) + (deffoo nnimap-request-delete-group (group force &optional server) (when (nnimap-possibly-change-server server) (when (string= group (imap-current-mailbox nnimap-server-buffer)) @@ -1789,6 +1800,7 @@ nnimap-request-expire-articles nnimap-request-move-article nnimap-request-accept-article + nnimap-request-replace-article nnimap-request-delete-group nnimap-request-rename-group gnus-group-nnimap-expunge ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: editing nnimap articles 2009-10-09 21:19 ` Ted Zlatanov 2009-10-10 0:11 ` Dan Christensen @ 2009-10-10 8:37 ` David Engster 1 sibling, 0 replies; 13+ messages in thread From: David Engster @ 2009-10-10 8:37 UTC (permalink / raw) To: ding Ted Zlatanov <tzz@lifelogs.com> writes: > On Fri, 09 Oct 2009 20:53:47 +0200 David Engster <deng@randomsample.de> wrote: > > DE> Maybe I'm understanding something wrong here. Say you'd like to edit the > DE> mail with article number '10' in INBOX. So you hit 'e' and edit > DE> away. After committing the change, the mail number '10' will not exist > DE> anymore, but there will be a new article, containing the edited text, > DE> but with an article number whatever the IMAP server chose to use (as > DE> long as it wasn't used before). > > DE> Therefore, you did not really 'edit' the article, but created a new > DE> one. > > Right. The proposal will make replacing the article fail and as a side > effect create a new one and delete this one. OK, I think I get it now. I was under the impression the delete-and-create workaround was meant to be "the replacement", but if the replacement actually fails and the creation of the edited article it's just a side effect, I think this should be OK. > I think it's justified; why shouldn't we do it? Does it break > anything? I don't know. :-) It might have some surprising consequences, e.g., if people sort 'by number', edited article will probably appear as newest. But that's a minor thing, and sorting by number with nnimap was always problematical, since it's entirely up to the server how he chooses the article IDs. As Dan already wrote: implement it, and see what happens. :-) > As far as I understand the internals, I think adding a new backend > function for the sake of IMAP is not worth it. It's less effort to > change the docs to explain the exception as long as it's just one > exception. As soon as it extends to 2 or more, it's time to refactor. I agree. Regards, David ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2009-10-25 0:50 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-10-08 19:05 editing nnimap articles Dan Christensen 2009-10-09 14:39 ` Ted Zlatanov 2009-10-09 14:48 ` David Engster 2009-10-09 15:06 ` Ted Zlatanov 2009-10-09 15:29 ` David Engster 2009-10-09 15:42 ` Ted Zlatanov 2009-10-09 16:07 ` Dan Christensen 2009-10-09 18:53 ` David Engster 2009-10-09 21:19 ` Ted Zlatanov 2009-10-10 0:11 ` Dan Christensen 2009-10-10 2:03 ` Dan Christensen 2009-10-25 0:50 ` Dan Christensen 2009-10-10 8:37 ` David Engster
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).