Picking Nits (sgnus v0.79/tm7.52)

Picking Nits (sgnus v0.79/tm7.52)

[Steven L Baur]

For the most part, I like very much how September Gnus is shaping up.

1.  Setting gnus-auto-center-summary to t (the default) produces bogus
    behavior on XEmacs 19.14 -- it warps the cursor off of the last
    article in the *Summary* buffer all too often.

2.  I don't care for the sequence of events when one selects a mail
    response function.  The subject prompt comes first, and the text
    is poorly worded -- it should just ask for a Subject:.  The
    currently selected article then disappears.  Very often I end up
    splitting the frame and putting the *Article ... buffer in the
    other window.  This is what Gnus used to do, and I guess I miss
    it.  The least you could do would be to make the *Article* buffer
    be the default target for C-X 4 b or C-X 5 b ...

3.  The technique of manually splitting digest articles into another
    group would be O.K. but the defaults don't work right.  Example: I
    have a group nnml:lnx-announce-digest, that gets filled with
    digests from the comp.os.linux.announce newsgroup.  To use this
    group I C-d each digest, mark all the articles and then B c them
    into another group ``nnml:linux-announce''.  The default
    destination for B c doesn't work at all the way I like.  I don't
    mind having to type in a destination the first time, but I think
    Gnus should remember what I've typed the next time this operation
    is done.  It's a nit, but it is starting to get on my nerves.

4.  The major/minor modes in the status line need some cleaning up.  I
    am seeing them start off with ``(Message MIME-Edit 7bit Filladapt
    ...'', and by the time the clickable (new XEmacs feature) minor
    modes are reached, they are truncated and unreachable :-(.  I'm
    not sure what can be done, but MIME, auto fill and filladapt are
    strict necessities.  Truncation doesn't really matter when the
    Status bar is only informational (Emacs, XEmacs 19.13), but it
    does matter when the minor modes become clickable buttons as in
    XEmacs 19.14.

5.  Message mode definitely needs a customized toolbar.  The default
    XEmacs one with buttons for Mail (pointing to vm) and News
    (pointing to Gnus) is mostly pointless and distracting.

6.  Marking articles and then running X u has a conflict with Tm and
    inline image display that I haven't figured out how to defeat yet.
    I only want to see inline images if I select a single article for
    viewing.  In mass operations off the X keymap, I just want the
    decoding to occur and nothing else.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

Re: Picking Nits (sgnus v0.79/tm7.52)

[Mark Borges]

>> On 25 Apr 1996 15:32:13 -0700,
>> Steven L Baur(sb) wrote:
sb> 1.  Setting gnus-auto-center-summary to t (the default) produces bogus
sb>     behavior on XEmacs 19.14 -- it warps the cursor off of the last
sb>     article in the *Summary* buffer all too often.

I'm not certain this is a sgnus problem. If I recall, it's only shown
up in the last few betas of XEmacs-19.14.
(setq scroll-on-clipped-lines nil) helps, but of course it won't
center anymore. Then again, you can actually read the last article,
which is difficult with the present warping.

sb> 5.  Message mode definitely needs a customized toolbar.  The default
sb>     XEmacs one with buttons for Mail (pointing to vm) and News
sb>     (pointing to Gnus) is mostly pointless and distracting.
Agreed.
-- 
  -mb-

Re: Picking Nits (sgnus v0.79/tm7.52)

[Steinar Bang]

>>>>> Steven L Baur <steve@miranova.com>:

> 4.  The major/minor modes in the status line need some cleaning up.  I
>     am seeing them start off with ``(Message MIME-Edit 7bit Filladapt
>     ...'', and by the time the clickable (new XEmacs feature) minor
>     modes are reached, they are truncated and unreachable :-(.  I'm
>     not sure what can be done, but MIME, auto fill and filladapt are
>     strict necessities.

Well... I'm the one to blame for tm's 7bit/8bit flag.  The reason I
introduced it, is that I keep toggling between 7bit and 8bit transfer
mode and I wanted some feedback on where I was at any given time.

But for people who stay in one of the transfer modes this feedback may
never be needed.  Maybe this flag should be made optional?

Or you might write a small elisp snippet to remove it from the alist
used by the status line (the name of the alist escapes me).

- Steinar

Re: Picking Nits (sgnus v0.79/tm7.52)

[Per Abrahamsen]

>>>>> "SLB" == Steven L Baur <steve@miranova.com> writes:

SLB> 3.  The technique of manually splitting digest articles into another
SLB>     group would be O.K. but the defaults don't work right.  Example: I
SLB>     have a group nnml:lnx-announce-digest, that gets filled with
SLB>     digests from the comp.os.linux.announce newsgroup.  To use this
SLB>     group I C-d each digest, mark all the articles and then B c them
SLB>     into another group ``nnml:linux-announce''.  The default
SLB>     destination for B c doesn't work at all the way I like.  I don't
SLB>     mind having to type in a destination the first time, but I think
SLB>     Gnus should remember what I've typed the next time this operation
SLB>     is done.  It's a nit, but it is starting to get on my nerves.

Try pressing arrow up (or M-p), that should give you the last group
name.

Re: Picking Nits (sgnus v0.79/tm7.52)

[Joe Hildebrand]

> "Steven" == Steven L Baur <steve@miranova.com> writes:

   Steven> 4.  The major/minor modes in the status line need some
   Steven> cleaning up.  I am seeing them start off with ``(Message
   Steven> MIME-Edit 7bit Filladapt ...'', and by the time the
   Steven> clickable (new XEmacs feature) minor modes are reached,
   Steven> they are truncated and unreachable :-(.  I'm not sure what
   Steven> can be done, but MIME, auto fill and filladapt are strict
   Steven> necessities.  Truncation doesn't really matter when the
   Steven> Status bar is only informational (Emacs, XEmacs 19.13), but
   Steven> it does matter when the minor modes become clickable
   Steven> buttons as in XEmacs 19.14.

(setq filladapt-mode-line-string " FA") may help, here.

-- 
Joe Hildebrand                  Fuentez Systems Concepts
hildjj@fuentez.com              Lead Software Engineer
	"Breakfast recapitulates phylogeny" - Spider Robinson

Re: Picking Nits (sgnus v0.79/tm7.52)

[Lars Magne Ingebrigtsen]

Steven L Baur <steve@miranova.com> writes:

> 2.  I don't care for the sequence of events when one selects a mail
>     response function.  The subject prompt comes first, and the text
>     is poorly worded -- it should just ask for a Subject:.  The
>     currently selected article then disappears.  Very often I end up
>     splitting the frame and putting the *Article ... buffer in the
>     other window.  This is what Gnus used to do, and I guess I miss
>     it.  The least you could do would be to make the *Article* buffer
>     be the default target for C-X 4 b or C-X 5 b ...

Uhm...  Are you ever prompted for anything when using message.el?  I
thought those prompts had gone the ways of the dinosaurs.  What
commands prompt?

>     The default destination for B c doesn't work at all the way I
>     like.  I don't mind having to type in a destination the first
>     time, but I think Gnus should remember what I've typed the next
>     time this operation is done.

Yup.  It used the wrong variable to store the default in.  Fix in
0.80. 

> 5.  Message mode definitely needs a customized toolbar.  

Definitely.  Luis?  Whoo-hoo!  :-)

> 6.  Marking articles and then running X u has a conflict with Tm and
>     inline image display that I haven't figured out how to defeat yet.
>     I only want to see inline images if I select a single article for
>     viewing.  In mass operations off the X keymap, I just want the
>     decoding to occur and nothing else.

I think the `gnus-summary-display-article-function' variable is what's
used to trigger the tm-ish things, so perhaps the gnus-uu function
could just bind that variable to bypass tm when decoding?  Yes, I
think that should work.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Picking Nits (sgnus v0.79/tm7.52)

[Steven L Baur]

>>>>> "lmi" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

lmi> Steven L Baur <steve@miranova.com> writes:
>> 2.  I don't care for the sequence of events when one selects a mail
>> response function.  The subject prompt comes first, and the text
>> is poorly worded -- it should just ask for a Subject:.  The
>> currently selected article then disappears.  Very often I end up
>> splitting the frame and putting the *Article ... buffer in the
>> other window.  This is what Gnus used to do, and I guess I miss
>> it.  The least you could do would be to make the *Article* buffer
>> be the default target for C-X 4 b or C-X 5 b ...

This is poorly worded, let me rephrase the first part.

lmi> Uhm...  Are you ever prompted for anything when using message.el?  I
lmi> thought those prompts had gone the ways of the dinosaurs.  What
lmi> commands prompt?

Type ``m'' while in the summary buffer.  I then get a prompt ``Empty
Subject enter value'', then get plopped in the message-mode buffer
sitting on the To: line.  This goes exactly backwards to what I've
been accustomed to.  I would expect a prompt for To: first, then
Subject:.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

Re: Picking Nits (sgnus v0.79/tm7.52)

[Lars Magne Ingebrigtsen]

Steven L Baur <steve@miranova.com> writes:

> Type ``m'' while in the summary buffer.  I then get a prompt ``Empty
> Subject enter value'', then get plopped in the message-mode buffer
> sitting on the To: line.  This goes exactly backwards to what I've
> been accustomed to.  I would expect a prompt for To: first, then
> Subject:.

Oh, right -- this is the result of setting
`message-generate-headers-first' to t.  Subject is a required header,
and is normally empty when you `m', while To isn't a required header.
Which means that you'll be prompted for a Subject.

Perhaps it should suppress the Subject header inclusion when
generating the headers first.  Yup.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."