Drafts feature-request/bug.

Drafts feature-request/bug.

[Scott A Crosby]

Hello... Thanks everyone to your help.. I'm still getting used to
gnus... And using a meat axe where subtlety is enough.. Anyways, I've
got a couple comments on drafts..

I like to use drafts a lot. Many times I'll sleep on an email and send
it a day later. Or, I'll check a different message then go back to
editing my current composition. I used to use PINE, and comparing it
to gnus doesn't complement GNUS very much.

First, can I make my drafts group be an ordinary group in the NNML
backend, or must it be in the nndraft backend?

Second, for NNML groups, if I move a message into an NNML group, I
don't have to refresh by pushing 'g' in the group buffer for them to
appear in their new summary buffers. I can go there directly and they
appear. However, for drafts, if I suspend writing a moment 'C-c C-d',
I must refresh the group buffer before I can continue see the message
in the draft group, before I can continue editing that message. This
is slow and annoying.

Third, drafts seem to have a fixed date on them. Usually December
31. It'd be nice if they got updated with the date of the last edit to
them. (IE, just before being edited or sent, update the date header.)

From reading the gnus-agent backend, apparently drafts does
double-duty and also is used to hold the outgoing messages. Thats
incompatible with using them to hold suspended messages. Is there any
easy way of splitting it into the 2 groups?

Thanks.... Scott

Re: Drafts feature-request/bug.

[Kai Großjohann]

Scott A Crosby <scrosby@cs.rice.edu> writes:

> First, can I make my drafts group be an ordinary group in the NNML
> backend, or must it be in the nndraft backend?

It's difficult to use nnml because your messages are also auto-saved
into a file in the drafts group.  Using nnml means you have to frob
the auto-saving mechanism to update the NOV data and stuff.

> Second, for NNML groups, if I move a message into an NNML group, I
> don't have to refresh by pushing 'g' in the group buffer for them to
> appear in their new summary buffers. I can go there directly and they
> appear. However, for drafts, if I suspend writing a moment 'C-c C-d',
> I must refresh the group buffer before I can continue see the message
> in the draft group, before I can continue editing that message. This
> is slow and annoying.

Seems to be a bug.  I also see it.  I wonder if somebody can fix it.

> Third, drafts seem to have a fixed date on them. Usually December
> 31. It'd be nice if they got updated with the date of the last edit to
> them. (IE, just before being edited or sent, update the date header.)

Hm.  It's an idea.

> From reading the gnus-agent backend, apparently drafts does
> double-duty and also is used to hold the outgoing messages. Thats
> incompatible with using them to hold suspended messages. Is there any
> easy way of splitting it into the 2 groups?

Gnus already uses nndraft:drafts for the C-c C-d'd messages and
nndraft:queue for the Agent.  (<self-advertisement> And then, there
is nndraft:delayed or somesuch for delayed
articles. </self-advertisement>)

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Drafts feature-request/bug.

[Scott A Crosby]

On Wed, 11 Sep 2002 12:06:52 +0200, Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Scott A Crosby <scrosby@cs.rice.edu> writes:
> 
> > First, can I make my drafts group be an ordinary group in the NNML
> > backend, or must it be in the nndraft backend?
> 
> It's difficult to use nnml because your messages are also auto-saved
> into a file in the drafts group.  Using nnml means you have to frob
> the auto-saving mechanism to update the NOV data and stuff.
> 

Ok.. Then again, having NOV for there doesn't matter much. I guess if
the other stuff got fixed, its not *that* big a deal.

> > Second, for NNML groups, if I move a message into an NNML group, I
> > don't have to refresh by pushing 'g' in the group buffer for them to
> > appear in their new summary buffers. I can go there directly and they
> > appear. However, for drafts, if I suspend writing a moment 'C-c C-d',
> > I must refresh the group buffer before I can continue see the message
> > in the draft group, before I can continue editing that message. This
> > is slow and annoying.
> 
> Seems to be a bug.  I also see it.  I wonder if somebody can fix it.
> 

PLEASE!  For bonus points, how about putting a key on the Group and
Summary buffers that called 'Edit last draft', so that you can suspend
the current message, look at some other messages, then go back to
editing it quickly.

BTW, it seems to work for NNML, so maybe get an idea from the code there?

> > Third, drafts seem to have a fixed date on them. Usually December
> > 31. It'd be nice if they got updated with the date of the last edit to
> > them. (IE, just before being edited or sent, update the date header.)
> 
> Hm.  It's an idea.
> 

I have a habit of occasionally leavig unsent drafts there for months
or occasionally years.. Having them dated would keep me from sending
out an ancient draft thats no longer relevant.

> > From reading the gnus-agent backend, apparently drafts does
> > double-duty and also is used to hold the outgoing messages. Thats
> > incompatible with using them to hold suspended messages. Is there any
> > easy way of splitting it into the 2 groups?
> 
> Gnus already uses nndraft:drafts for the C-c C-d'd messages and
> nndraft:queue for the Agent.  (<self-advertisement> And then, there
> is nndraft:delayed or somesuch for delayed
> articles. </self-advertisement>)

Ah, cool.. The docs on Gnus Agent are a little misleading. I was
looking for if it would be possible to use Agent to read an NNML spool
on one machine from a different machine, and read a paragraph that
implied the above.

From reading the gnus agent, I guess I can't do the above, without
creating some sort of client-server backend.

As a quick question.. Can someone explain why composing a new message
seems to be sluggish? When I do an 'm' it usually takes a second or so
for it to pop up the message edit buffer.

Scott

Re: Drafts feature-request/bug.

[Kai Großjohann]

Scott A Crosby <scrosby@cs.rice.edu> writes:

> As a quick question.. Can someone explain why composing a new message
> seems to be sluggish? When I do an 'm' it usually takes a second or so
> for it to pop up the message edit buffer.

Dunno.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: Drafts feature-request/bug.

[Reiner Steib]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1855 bytes --]

--=-=-=
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

On Wed, Sep 11 2002, Kai Großjohann wrote:

> (<self-advertisement> And then, there is nndraft:delayed or somesuch
> for delayed articles. </self-advertisement>)

Kai, you should advertise this more often. I missed this up to now. ;-)

Reading the manual section, I found a typo and saw that there's no
"summary line" (r.h.s. in <info://gnus/Top>):


--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline; filename=gnus.texi.gnus-delay.patch
Content-Description: Typo and missing summary for Delayed Articles

--- gnus.texi.~6.319.~	Wed Sep 11 11:51:19 2002
+++ gnus.texi	Wed Sep 11 17:08:32 2002
@@ -499,7 +499,7 @@
 * Choosing Articles::           Reading articles.
 * Paging the Article::          Scrolling the current article.
 * Reply Followup and Post::     Posting articles.
-* Delayed Articles::            
+* Delayed Articles::            Delaying the sending of a message.
 * Marking Articles::            Marking articles as read, expirable, etc.
 * Limiting::                    You can limit the summary buffer.
 * Threading::                   How threads are made.
@@ -5405,7 +5405,7 @@
 (months) and @code{Y} (years).
 
 @item
-A specific date.  Looks like @code{YYYYY-MM-DD}.  The message will be
+A specific date.  Looks like @code{YYYY-MM-DD}.  The message will be
 delayed until that day, at a specific time (eight o'clock by default).
 See also @code{gnus-delay-default-hour}.
 

--=-=-=


Concerning the argument `no-keymap' in `gnus-delay-initialize': the
description in the manual doesn't match the doc-string and
implementation in `gnus-delay.el'

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

--=-=-=--

Re: Drafts feature-request/bug.

[Kai Großjohann]

Reiner Steib <4uce.02.r.steib@gmx.net> writes:

> Reading the manual section, I found a typo and saw that there's no
> "summary line" (r.h.s. in <info://gnus/Top>):

Done.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

charset problems with gnus-delay (was: Drafts feature-request/bug.)

[Reiner Steib]

On Wed, Sep 11 2002, Reiner Steib wrote:
[a b0rked message]

I did some experiments with gnus-delay before sending this message. As
you can see it lead to a posting without proper MIME-headers:

| Mime-Version: 1.0
| Content-Type: text/plain; charset=utf-8

It probably should have been:

| Mime-Version: 1.0
| Content-Type: multipart/mixed; boundary="=-=-="

Maybe it was my fault, because I have edited the article in the group
nndraft:delayed. (Sorry, I don't remember for sure.)

But another delayed article (in de.comm.software.gnus) was b0rked too.
So I did some test in news.gnus.org:gnus.test, see the article
news:<sa6r8g0gzwf.fsf@theotp5.physik.uni-ulm.de> (and references
therein).

- Enter some Latin-1 characters.

- Eval:
  (require 'gnus-delay)
  (gnus-delay-initialize nil t)

- Delay the message with `C-c C-j 1m RET'

- Send it later with `M-x gnus-delay-send-queue RET' from the group
  buffer.

- Oort Gnus v0.08 with minimal configuration, see above mentioned
  article for full configuration (using `gnus-bug').

- GNU Emacs 21.1.1 with `ucs-tables':
  (require 'ucs-tables)
  (unify-8859-on-encoding-mode 1)
  (unify-8859-on-decoding-mode 1)

Any hints?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: charset problems with gnus-delay

[Reiner Steib]

On Wed, Sep 11 2002, Reiner Steib wrote:

Sorry for following up to myself again.

> So I did some test in news.gnus.org:gnus.test, see the article
> news:<sa6r8g0gzwf.fsf@theotp5.physik.uni-ulm.de> (and references
> therein).

That article seems to be okay, AFAICS. But without delaying, Gnus
would use Latin-1 instead of UTF-8.

But the following two articles seem to be wrong (both sent from the
test account):

| From: Guest Test <guest@theotp5.physik.uni-ulm.de>
| Date: Wed, 11 Sep 2002 21:01:40 +0200
| Message-ID: <sa63csgxsdn.fsf@theotp5.physik.uni-ulm.de>
| User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i586-pc-linux-gnu)

| From: Reiner Steib <4uce.02.r.steib@gmx.net>
| Date: Wed, 11 Sep 2002 21:07:27 +0200
| Message-ID: <sa6admo5or4.fsf@theotp5.physik.uni-ulm.de>
| User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.1 (i586-pc-linux-gnu)

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: charset problems with gnus-delay (was: Drafts feature-request/bug.)

[Kai Großjohann]

Reiner Steib <4uce.02.r.steib@gmx.net> writes:

> On Wed, Sep 11 2002, Reiner Steib wrote:
> [a b0rked message]
>
> I did some experiments with gnus-delay before sending this message. As
> you can see it lead to a posting without proper MIME-headers:

I see the same problem.  After the delayed article arrived, I saw the
following (received headers snipped):

/----
| X-From-Line: grossjoh@lothlorien.cs.uni-dortmund.de Thu Sep 12 11:18:41 2002
| To: Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE>
| Subject: testing delay
| From: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai
|  =?iso-8859-15?q?Gro=DFjohann?=)
| Date: Thu, 12 Sep 2002 11:18:33 +0200
| Message-ID: <vafadmnh8gm.fsf@lucy.cs.uni-dortmund.de>
| User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50
|  (i686-pc-linux-gnu)
| MIME-Version: 1.0
| Content-Type: text/plain; charset=utf-8
| Content-Transfer-Encoding: quoted-printable
| X-Content-Length: 79
| Lines: 6
| Xref: lucy.cs.uni-dortmund.de news.emacs.tramp:10755
| 
| Sch=C2=81=F6ner Test.
| 
| kai
| --=20
| ~/.signature is: umop 3p!sdn    (Frank Nobis)
| 
\----

So the utf-8 charset was used where it wasn't necessary, and the \201
appeared.

Does anyone have an idea what happened?  gnus-delay uses the
following sequence of statements to save the article:

  (set-buffer-modified-p t)
  (nndraft-request-create-group gnus-delay-group)
  (message-disassociate-draft)
  (nndraft-request-associate-buffer gnus-delay-group)
  (save-buffer 0)
  (kill-buffer (current-buffer))
  (message-do-actions message-postpone-actions))

And it uses the (gnus-draft-send article group) to send them.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)