feature request

feature request

[David Lebel]

Hello,

	would it be nice, in Topic mode to have the ability to add
some extra spaces between certain entries?  What I would like is to
have some blank lines inserted between my mail and news groups so it
even easier to spot them when in topic mode.  Eventually, if we could
just setup the page in a way that we can exactly put what we want
where we want;  like in a page layout system.

	What do ya think?

	...David

-- 
// d a v i d  l e b e l  <lebel@socom.com>      http://www.socom.com/~lebel/
// analyst / system administrator / hacker          socom technologies, inc.
// " thoughts from above hit the people down below, people in this world, we
//   have no place to go. "                       -- new order, _temptation_

Re: feature request

[Lars Magne Ingebrigtsen]

David Lebel <lebel@socom.com> writes:

> 	would it be nice, in Topic mode to have the ability to add
> some extra spaces between certain entries?  What I would like is to
> have some blank lines inserted between my mail and news groups so it
> even easier to spot them when in topic mode.  Eventually, if we could
> just setup the page in a way that we can exactly put what we want
> where we want;  like in a page layout system.

A general page layout system?  Sounds quite complicated.  If you want
a different look, you could just write a new
`gnus-group-prepare-function' function.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Feature request

[Lars Magne Ingebrigtsen]

David Abrahams <dave@boost-consulting.com> writes:

> When Gnus fails to open a server, it's often because of some temporary
> connectivity problem that I can easily correct.  I have found that I
> always have to answer `y' to the query about whether to take the
> server offline, or Gnus (at least the nnimap backend) gets horribly
> confused.  Then I have to fix the problem, put the server back online,
> and retry.  I'd like Gnus to give me a yes/no/retry option when asking
> about taking the server offline.

I think the real bug is that nnimap gets confused here.  If answering
`n' to "go offline", the status of the nnimap server should change to
`denied'.  Which should work ok... 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Feature request

[David Abrahams]

When Gnus fails to open a server, it's often because of some temporary
connectivity problem that I can easily correct.  I have found that I
always have to answer `y' to the query about whether to take the
server offline, or Gnus (at least the nnimap backend) gets horribly
confused.  Then I have to fix the problem, put the server back online,
and retry.  I'd like Gnus to give me a yes/no/retry option when asking
about taking the server offline.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: feature request

[Fredrik Glöckner]

Rolf Marvin B|e Lindgren <roffe@tag.uio.no> writes:

| I've thougt of one solution to this which might solve the problem for
| me.  if Gnus had an option to expunge all posters or subjects that
| _don't_ have a _positive_ score, the load might just be manageable.

How about saying something like

(
 ...

 (expunge 0)
)

in the file `all.SCORE'?  I should think that this expunges all articles
with score zero or below.  You might want to use (expunge -1).

Fredrik

Re: feature request

[Lars Syrstad]

* Rolf Marvin B|e Lindgren
| 
| I've thougt of one solution to this which might solve the problem for
| me.  if Gnus had an option to expunge all posters or subjects that
| _don't_ have a _positive_ score, the load might just be manageable.
| 
| can something similar to this be done already?  what do other proles do
| about this?

Put (expunge 1) in the relevant score-file(s).

  - Lars.
-- 
Fly like a rock from the roof to the basement
The last thing to go through my mind is the pavement
(Falling out of love with life)
    -- Skyclad: Helium

feature request

[Rolf Marvin B|e Lindgren]

I have entered the work force.  consequently, I don't have time to do
nothing any more, at least not as often as before.

I've thougt of one solution to this which might solve the problem for
me.  if Gnus had an option to expunge all posters or subjects that
_don't_ have a _positive_ score, the load might just be manageable.

can something similar to this be done already?  what do other proles do
about this?

-- 

       Rolf Lindgren           |       "The opinions expressed above are
       Sofienberggt. 13b       |        not necessarily those of anyone"
       N-0551 OSLO             |               roffe@ask.uio.no 

Re: feature request

[Lars Magne Ingebrigtsen]

Colin Rafferty <craffert@spspme.ml.com> writes:

> I would prefer to have a way to only update the info in the dribble file
> without saving .newsrc.  My dribble file is only a couple of K, while my
> .newsrc.eld is 400k.

I've now changed the `gnus-summary-save-newsrc' command to only update
the dribble buffer.  If given a prefix, the .newsrc file(s) will be
saved. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: feature request

[Colin Rafferty]

Lars Magne Ingebrigtsen writes:
> Colin Rafferty <craffert@spspme.ml.com> writes:

>> 2. This could be disastrous `gnus-summary-exit-no-update'.  At least, it
>> would be a little difficult.  It would mean that gnus would have to
>> remember what the original info of the group was, and append that to
>> the dribble on `Q'.

> Well, that is a bit complicated.  If the user wants to save the
> .newsrc, then the .newsrc file(s) should be saved.  

I agree with you here.  I was just pointing out that the behavior that
we are asking for will modify the behavior of an existing command.

> I've now added a new command (`Z s') that will update the info and
> save the .newsrc files.  If the user wants to `Q' after that, I think
> they'll just have to `q' and undo.

I would prefer to have a way to only update the info in the dribble file
without saving .newsrc.  My dribble file is only a couple of K, while my
.newsrc.eld is 400k.

I really want to hook this command to `gnus-article-display-hook', so it
needs to be fast.  Especially now that I am beta testing 19.15. :-)

-- 
Colin

Re: feature request

[Lars Magne Ingebrigtsen]

Colin Rafferty <craffert@spspme.ml.com> writes:

> 2. This could be disastrous `gnus-summary-exit-no-update'.  At least, it
>    would be a little difficult.  It would mean that gnus would have to
>    remember what the original info of the group was, and append that to
>    the dribble on `Q'.

Well, that is a bit complicated.  If the user wants to save the
.newsrc, then the .newsrc file(s) should be saved.  

I've now added a new command (`Z s') that will update the info and
save the .newsrc files.  If the user wants to `Q' after that, I think
they'll just have to `q' and undo.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: feature request

[David Moore]

Hunter Kelly <retnuh@corona.pixar.com> writes:

> This may be a dumb idea, I don't really know the internals at all, but
> it seems like you could have dribble buffers/files for each summary
> group.  Then, when you exit the group, you merge/append in the
> information to the master dribble file, or in the case of no-update,
> you don't merge it.

	That's a good idea.  Just gotta find a volunteer, now.

-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | Solo Furnace Creek 508 -- 1996!

Re: feature request

[Hunter Kelly]

David Moore <dmoore@UCSD.EDU> writes:

> Colin Rafferty <craffert@spspme.ml.com> writes:
> 
> > 1. I like the idea.  In fact, given a function to save to the dribble, I
> >    would probably add it to `gnus-select-article-hook'.
> 
> 	Yeah, this is a good idea.
> 
> > 2. This could be disastrous `gnus-summary-exit-no-update'.  At least, it
> >    would be a little difficult.  It would mean that gnus would have to
> >    remember what the original info of the group was, and append that to
> >    the dribble on `Q'.
> 
> 	What do you do if gnus crashes just before you are about to hit
> 'Q'?  Or is this information only being used to regenerate the same
> summary buffer the next time you start (rather than actually updating
> the group info)?

This may be a dumb idea, I don't really know the internals at all, but
it seems like you could have dribble buffers/files for each summary
group.  Then, when you exit the group, you merge/append in the
information to the master dribble file, or in the case of no-update,
you don't merge it.

Or, if that is to inefficient or undesirable for some reason, you
could put some kind of marker in the dribble buffer when you enter a
summary buffer.  Then you could just back out everything after
(before)? the marker.

Hunter

> -- 
> David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
> UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
> La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
> <URL:http://oj.egbt.org/dmoore/>    | Solo Furnace Creek 508 -- 1996!

Re: feature request

[Colin Rafferty]

Steven L Baur writes:
>>>>>> "David" == David Moore <dmoore@UCSD.EDU> writes:
>> Colin Rafferty <craffert@spspme.ml.com> writes:

Colin> 2. This could be disastrous `gnus-summary-exit-no-update'.  At
Colin> least, it would be a little difficult.  It would mean that gnus
Colin> would have to remember what the original info of the group was,
Colin> and append that to the dribble on `Q'.

David> What do you do if gnus crashes just before you are about to hit
David> 'Q'?

> If the data is being added to the dribble file (my second suggestion),
> then choose not to read it when you bring Gnus back up.  I'm paranoid
> and run experimental software nearly all of the time, so I save
> .newsrc in the *Topics* buffer early and often. :-)

I prefer not to even think about saving:

(add-hook 'gnus-summary-exit-hook 'gnus-dribble-save)

I really would probably add `gnus-summary-update-info' to my
`gnus-article-prepare-hook', since I rarely `Q'.

-- 
Colin

Re: feature request

[Steven L Baur]

>>>>> "David" == David Moore <dmoore@UCSD.EDU> writes:

> Colin Rafferty <craffert@spspme.ml.com> writes:

Colin> 2. This could be disastrous `gnus-summary-exit-no-update'.  At
Colin> least, it would be a little difficult.  It would mean that gnus
Colin> would have to remember what the original info of the group was,
Colin> and append that to the dribble on `Q'.

David> 	What do you do if gnus crashes just before you are about to hit
David> 'Q'?

If the data is being added to the dribble file (my second suggestion),
then choose not to read it when you bring Gnus back up.  I'm paranoid
and run experimental software nearly all of the time, so I save
.newsrc in the *Topics* buffer early and often. :-)
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

Re: feature request

[Colin Rafferty]

David Moore <dmoore@ucsd.edu> writes:
> Colin Rafferty <craffert@spspme.ml.com> writes:

>> 2. This could be disastrous `gnus-summary-exit-no-update'.  At least, it
>> would be a little difficult.  It would mean that gnus would have to
>> remember what the original info of the group was, and append that to
>> the dribble on `Q'.

> 	What do you do if gnus crashes just before you are about to hit
> 'Q'?  Or is this information only being used to regenerate the same
> summary buffer the next time you start (rather than actually updating
> the group info)?

I would say that you lose.  I guess that there would need to be another
interactive function called `gnus-summary-forget-update-info' that you
could call if, after having called `gnus-summary-update-info' some
number of times, you realize that you haven't been paying attention, and
you want to start over reading from scratch (without having to `Q' and
re-enter the group).

I am sorry about that last sentence, but I had two large Diet Cokes with
lunch.

-- 
Colin Rafferty
``You Unix-heads are all about to be crushed
  under the heel of the Windows juggernaut''   -- jwz

Re: feature request

[Colin Rafferty]

About an hour ago, I wrote:
> Not ten minutes ago, I wrote:
>> Anyway, I like the idea.  I think that I should look at the code to
>> `gnus-summary-exit' now so that I can write it.

> Quick and dirty solution:

> (defun gnus-summary-checkpoint-info
>   "Checkpoint information for current summary.
> Note that this breaks `gnus-summary-exit-no-update'."
>   (interactive)
>   (gnus-summary-update-info))

> Slower but cleaner (but still dirty) is to add an (interactive) to
> `gnus-summary-update-info'.

There is another potential flaw with this.  `gnus-summary-update-info'
does the scoring and runs `gnus-exit-group-hook'.  Calling this while
not actually exiting a group will cause all sorts of things that should
only happen once to happen any number of times.  This is probably not a
good thing.

Anyway, I think that we just need to split `gnus-summary-update-info'
into two pieces: the part that saves marks, and the part that increments
calculations.

-- 
Colin

Re: feature request

[David Moore]

Colin Rafferty <craffert@spspme.ml.com> writes:

> 1. I like the idea.  In fact, given a function to save to the dribble, I
>    would probably add it to `gnus-select-article-hook'.

	Yeah, this is a good idea.

> 2. This could be disastrous `gnus-summary-exit-no-update'.  At least, it
>    would be a little difficult.  It would mean that gnus would have to
>    remember what the original info of the group was, and append that to
>    the dribble on `Q'.

	What do you do if gnus crashes just before you are about to hit
'Q'?  Or is this information only being used to regenerate the same
summary buffer the next time you start (rather than actually updating
the group info)?

> Anyway, I like the idea.  I think that I should look at the code to
> `gnus-summary-exit' now so that I can write it.

	Be warned that it looks like something in gnus-summary-exit is
acting strange which has been causing some problems with catching up of
virtual groups.  But perhaps it's just a problem with
gnus-summary-catchup-and-exit leaving things in a strange state before
gnus-summary-exit does its thing.

-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | Solo Furnace Creek 508 -- 1996!

Re: feature request

[Colin Rafferty]

Not ten minutes ago, I wrote:

> Anyway, I like the idea.  I think that I should look at the code to
> `gnus-summary-exit' now so that I can write it.

Quick and dirty solution:

(defun gnus-summary-checkpoint-info
  "Checkpoint information for current summary.
Note that this breaks `gnus-summary-exit-no-update'."
  (interactive)
  (gnus-summary-update-info))

Slower but cleaner (but still dirty) is to add an (interactive) to
`gnus-summary-update-info'.

> 2. This could be disastrous `gnus-summary-exit-no-update'.  At least, it
>    would be a little difficult.  It would mean that gnus would have to
>    remember what the original info of the group was, and append that to
>    the dribble on `Q'.

Therein lies the rub.

-- 
Colin

Re: feature request

[Colin Rafferty]

>>>>>> "sb" == Steven L Baur <steve@miranova.com> writes:
>>>>>> "St" == St Suika Roberts <wrobert2@mailhost.tcs.tulane.edu> writes:

St> IWBNI one could save the status of the current newsgroup and
St> the rest of the changes to the .newsrc.eld file from the summary
St> buffer.

sb> FWIW, I second this.  It's most annoying when it happens.  Just being
sb> able to checkpoint the save of the dribble file with updates would be
sb> an acceptable alternative.

I have two comments about this.

1. I like the idea.  In fact, given a function to save to the dribble, I
   would probably add it to `gnus-select-article-hook'.

2. This could be disastrous `gnus-summary-exit-no-update'.  At least, it
   would be a little difficult.  It would mean that gnus would have to
   remember what the original info of the group was, and append that to
   the dribble on `Q'.

Anyway, I like the idea.  I think that I should look at the code to
`gnus-summary-exit' now so that I can write it.

-- 
Colin

Re: feature request

[Steven L Baur]

>>>>> "St" == St Suika Roberts <wrobert2@mailhost.tcs.tulane.edu> writes:

St> 	IWBNI one could save the status of the current newsgroup and
St> the rest of the changes to the .newsrc.eld file from the summary
St> buffer.

FWIW, I second this.  It's most annoying when it happens.  Just being
able to checkpoint the save of the dribble file with updates would be
an acceptable alternative.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore.  He doesn't have a creative bone in his
body."  -- David Brinkley

feature request

[St. Suika Roberts]

	IWBNI one could save the status of the current newsgroup and
the rest of the changes to the .newsrc.eld file from the summary
buffer.

Basically the same thing as `gnus-group-save-newsrc' only it saves the
current status of the current group as well.

I personally would really like this because a lot of the time I spend
four or fifteen minutes generating a summary buffer, kill off/read a
lot of things, then have either the server, the host I run emacs off
of, or the terminal itself go non-funtional.  If there was a
`gnus-summary-save-newsrc' command, I would be able to either remember
to run it every now and again when things are getting flakey, or call
it when things start failing.  Won't prevent the anoyance of reading
300 articles, then having things crash before I exit the group, but it
should lessen it's frequency.

Thank you for your time,
      Suika
-- 
		wrobert2@mailhost.tcs.tulane.edu
"The dew fell with a particularly sickening thud this morning." 
								-Rhonda Rubin
   <a href="http://studentweb.tulane.edu/~wrobert2/">Suika no homepage</a>

Re: feature request

[Steven L Baur]

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

Lars> Well, this is a MIME issue, and Gnus isn't MIME aware at all.
Lars> (This'll probably change in the future, though.)  I'm just
Lars> waiting for TM to be included in Emacs.

I don't know what the schedule is for adding tm to GNU Emacs, but
Chuck has consented to adding it to XEmacs 19.15.  :-)  I think it's a
safe assumption that Gnus 5.4/5.5 will have emacsen with native tm.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
What are the last two letters of "doesn't" and "can't"?
Coincidence?  I think not.

Re: feature request

[Lars Magne Ingebrigtsen]

David Lebel <lebel@socom.com> writes:

> 	When forwarding a message (using C-c C-f), it would be nice,
> if the original encoding scheme would be including in the
> message/rfc882 enclosure.  That's because, since I'm french speaking,
> I use ISO-8859-1 character set all day long, and I forward quite often
> mails to other people, and they are getting quoted-printable encoded
> enclosure.  In fact, maybe make it configurable, since some viewers
> doesn't understand message/rfc882, maybe let the user configure it to
> text/plain might be a good idea.

Well, this is a MIME issue, and Gnus isn't MIME aware at all.
(This'll probably change in the future, though.)  I'm just waiting for
TM to be included in Emacs.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

feature request

[David Lebel]

Hello,
	When forwarding a message (using C-c C-f), it would be nice,
if the original encoding scheme would be including in the
message/rfc882 enclosure.  That's because, since I'm french speaking,
I use ISO-8859-1 character set all day long, and I forward quite often
mails to other people, and they are getting quoted-printable encoded
enclosure.  In fact, maybe make it configurable, since some viewers
doesn't understand message/rfc882, maybe let the user configure it to
text/plain might be a good idea.

	I know I already asked for this, but it seems to me like a
very important feature.  Steven Baur suggested a while back that it
might also be good to include the encoding scheme when bursting
digests (that keeps them).  While it be included in the TODO? :-)
Please! :-)

	Ciao,
	...David

-- 
// d a v i d  l e b e l  <lebel@socom.com>       http://superdave.socom.com/
// analyst / system administrator / hacker          socom technologies, inc.

Re: Feature request

[Lars Magne Ingebrigtsen]

Richard Taylor <rjt@rivers.dra.hmg.gb> writes:

> How about adding a group parameter that allows articles over a certain
> age to be compressed. Then I could set limits that first compressed
> articles and then later expired them.

It sounds kinda complicated.  I'd just set up a cron job to do it if I
were you.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Feature request

[Richard Taylor]

How about adding a group parameter that allows articles over a certain
age to be compressed. Then I could set limits that first compressed
articles and then later expired them.

Just a thought.

Richard

-- 

			------------------------------
Richard Taylor, N129, DRA Malvern, St Andrews Rd, Malvern, Worcs. WR14 3PS. UK.
   Tel: +44 1684 896028; Fax: +44 1684 894303; Email: rjt@rivers.dra.hmg.gb

Re: feature request

[Lars Magne Ingebrigtsen]

hardaker@ece.ucdavis.edu (Wes Hardaker) writes:

> I'm tired of getting mail messages that look like:
> 
> From: "Fred van Dijk" <FRED@scintilla.utwente.nl>
> Subject:       sub/unsub requests unprocessed by listserver
> Date:          Fri, 8 Mar 1996 22:10:21 +0100
> 
> (note the extra spaces in the Subject line)

You could just write a function to remove leading spaces from all
Subject (and Date and From?) headers and put it in
`nnmail-prepare-incoming-hook'...

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

feature request

[Wes Hardaker]

I'm tired of getting mail messages that look like:

From: "Fred van Dijk" <FRED@scintilla.utwente.nl>
Subject:       sub/unsub requests unprocessed by listserver
Date:          Fri, 8 Mar 1996 22:10:21 +0100

(note the extra spaces in the Subject line)

These generate summary buffers like:

E     0 [  21: Fred van Dijk       ] 1       sub/unsub requests unprocessed by listserver
      0 [  33: SmartList           ] 1 accept2 and rc.custom
      0 [  25: Andy Rowan          ] 1 Re: HT trigger digest by time? (not size)
!*    0 [  92: Stephen R. van den B] 1 Re: moderated lists?
      0 [  26: Tony Bowden         ] 1 Re: Silly Question... 

It might be a good idea to look for and chop leading spaces in
necessary headers (are there any besides the subject?)...

Thanks,
Wes

Feature request

[Corny de Souza]

I did not see this on the todo list, and I dio not know if it made it
to sgnus......


Is there any way to get the head thread makrked/highlighted if an
article in its sub thread is scored highly and sub threads are hidden?


Solution suggested by Vladimir Alexiev <vladimir@cs.ualberta.ca>

%z (zcore, which is +- indication of score) is good enough; let's not
create separate versions for "article score" and "thread score". The
default (or selectable behavior) should be that when threads are hidden,
the root displays the thread score instead of its own (as already
suggested). When the thread is shown, the root should display its own
score.