Gnus v5.4.62 is released

Gnus v5.4.62 is released

[Lars Magne Ingebrigtsen]

Bug fixes.

Get it from <URL:http://www.gnus.org/gnus.tar.gz> or 
"ftp.gnus.org:/pub/emacs/gnus/".  The patch is available as
<URL:http://www.gnus.org/patches/gnus-5.4.61-5.4.62.diff.gz>

ChangeLog since last release:

Sun Jul  6 17:22:47 1997  Lars Magne Ingebrigtsen  <larsi@menja.ifi.uio.no>

	* gnus.el: Gnus v5.4.62 is released.

Sun Jul  6 12:38:56 1997  Lars Magne Ingebrigtsen  <larsi@ifi.uio.no>

	* nngateway.el (nngateway-request-post): Call sendmail function.

	* message.el (message-send-news): Supply the method to the post
	function.

	* gnus.el (gnus-group-auto-expirable-p): Dox fox.

	* message.el (message-clone-locals): Only clone Gnus variables. 

	* gnus-nocem.el (gnus-nocem-enter-article): Use real group name. 

Fri Jul  4 13:00:39 1997  enami tsugutomo  <enami@but-b.or.jp>

	* gnus-group.el (gnus-group-set-mode-line): Use new, shorter
	format. 

Fri Jul  4 12:31:18 1997  Lars Magne Ingebrigtsen  <larsi@ifi.uio.no>

	* gnus-score.el (gnus-score-headers): Let the score buffer inherit
	variables from the summary buffer.

	* message.el (message-clone-locals): Made into own function.

	* gnus.el (gnus-select-method): Changed default.

	* gnus-start.el (gnus-read-active-file): Changed default to
	`some'. 



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

Re: Gnus v5.4.62 is released

[Hrvoje Niksic]

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

> 	* gnus-start.el (gnus-read-active-file): Changed default to
> 	`some'.

Maybe you should change some other settings when this one is change?
`gnus-check-new-newsgroups' and `gnus-save-killed-list' come to mind.

(they should be changed to `ask-server' and nil, respectively.)

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

Re: Gnus v5.4.62 is released

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Maybe you should change some other settings when this one is change?
> `gnus-check-new-newsgroups' and `gnus-save-killed-list' come to mind.
> 
> (they should be changed to `ask-server' and nil, respectively.)

I've now changed the first, but why should the latter be nil?

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

Re: Gnus v5.4.62 is released

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > Maybe you should change some other settings when this one is change?
> > `gnus-check-new-newsgroups' and `gnus-save-killed-list' come to mind.
> > 
> > (they should be changed to `ask-server' and nil, respectively.)
> 
> I've now changed the first, but why should the latter be nil?

Because there is no real need to save the killed list with the new
settings.  Or is there?

Besides, it might be good to have a shorter `.newsrc.eld' by default.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
I'm a Lisp variable -- bind me!

Re: Gnus v5.4.62 is released

[Jens Lautenbacher]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Hrvoje Niksic <hniksic@srce.hr> writes:
> > 
> > > Maybe you should change some other settings when this one is change?
> > > `gnus-check-new-newsgroups' and `gnus-save-killed-list' come to mind.
> > > 
> > > (they should be changed to `ask-server' and nil, respectively.)
> > 
> > I've now changed the first, but why should the latter be nil?
> 
> Because there is no real need to save the killed list with the new
> settings.  Or is there?
> 
> Besides, it might be good to have a shorter `.newsrc.eld' by default.

Hmm, I may have missed the beginning of the thread, but I assume you
talk about gnus-read-active-file 'some and
gnus-check-new-newsgroups 'ask-server; then I see no possibility to keep 
track of killed groups (and easiely list them) without having the list 
of killed groups saved.

   jtl

Re: Gnus v5.4.62 is released

[Hrvoje Niksic]

Jens Lautenbacher <jens@metrix.de> writes:

> Hmm, I may have missed the beginning of the thread, but I assume you
> talk about gnus-read-active-file 'some and gnus-check-new-newsgroups
> 'ask-server; then I see no possibility to keep track of killed
> groups (and easiely list them) without having the list of killed
> groups saved.

You are right.  What I meant is: if changes are being made, let's try
to make Gnus behave logically.

Logical behaviour includes not creating a 100K or so .newsrc.eld by
default.

-- 
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.

Re: Gnus v5.4.62 is released

[Steven L Baur]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Jens Lautenbacher <jens@metrix.de> writes:
>> Hmm, I may have missed the beginning of the thread, but I assume you
>> talk about gnus-read-active-file 'some and gnus-check-new-newsgroups
>> 'ask-server; then I see no possibility to keep track of killed
>> groups (and easiely list them) without having the list of killed
>> groups saved.

That is a minor problem, but with tens of thousands of news groups
accessible on a full feed (what is the current number now?), it makes
some sense to not keep it because maybe 1/10 of 1% are `interesting'
to any one person.

> You are right.  What I meant is: if changes are being made, let's try
> to make Gnus behave logically.

> Logical behaviour includes not creating a 100K or so .newsrc.eld by
> default.

I agree, and I also like the side effect of these options settings in
my own environment -- Gnus *really* flies ... :-)
-- 
steve@calag.com baur
Unsolicited commercial e-mail will be billed at $250/message.

Re: Gnus v5.4.62 is released

[Jens Lautenbacher]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Jens Lautenbacher <jens@metrix.de> writes:
> 
> > Hmm, I may have missed the beginning of the thread, but I assume you
> > talk about gnus-read-active-file 'some and gnus-check-new-newsgroups
> > 'ask-server; then I see no possibility to keep track of killed
> > groups (and easiely list them) without having the list of killed
> > groups saved.
> 
> You are right.  What I meant is: if changes are being made, let's try
> to make Gnus behave logically.
> 
> Logical behaviour includes not creating a 100K or so .newsrc.eld by
> default.
> 

I beg to differ. from the beginners point it's still a bit difficult
to set up a gnus environment. Looking at other news readers
(blasphemy, I know) I can simply list all the groups and enter
them. All these subtle differences between subscribed
/unsbscribed/killed and so on are very nice once I have set up my whole
environment. But it's extremely non-logical if suddenly I can't access
the whole feed anymore without explicitely reloading the active file
-- and even at a fast scientific internet access with a fast computer
it still takes damned long to load the whole active file from the
server.

Besides that a newbie will not know what to do, and will switch to tin
after 5 minutes without getting what he wants (yeah yeah, RTFM, I
know. _I_ do, but we all know our users). The thousands of different
listing/loading/browsing commands don't help either, as they are layed 
out in a totally flat way: there is no "hirarchy" build of them with
"general" commands which do the right thing most of the time and
"expert" commands, unfortunately. Even the menu doesn't suggest such a 
hirarchy. 

Conclusion: Follow the principle of least surprise, and that mean:
Selecting "List killed groups" selects the killed groups. Point. Don't 
assume all a user understand the difference between C-u A k and A k;
and hey why is there a own list active A A.... has a C-u A A a
different effect.....

all of course just IMHO

    jtl
 

Re: Gnus v5.4.62 is released

[Hrvoje Niksic]

Jens Lautenbacher <jens@metrix.de> writes:

> > Logical behaviour includes not creating a 100K or so .newsrc.eld
> > by default.
> 
> I beg to differ. from the beginners point it's still a bit difficult
> to set up a gnus environment.

Exactly.  Which is why Gnus should provide the most palatable
behaviour by default.  And I still think this category includes /not/
creating 100K+ .newsrc.eld by default.

> Looking at other news readers (blasphemy, I know) I can simply list
> all the groups and enter them.

You can do it in Gnus, too.  Commands like `10 A T' will connect to
the server, get the list of groups and list them.  I don't need the
list every day.  And a beginner certainly doesn't need it in his
.newsrc.eld -- by default.

> But it's extremely non-logical if suddenly I can't access the whole
> feed anymore (...)

Sure you can -- see above.

> -- and even at a fast scientific internet access with a fast computer
> it still takes damned long to load the whole active file from the
> server.

That's what all these others newsreaders do, in case you didn't know.

> Besides that a newbie will not know what to do, and will switch to
> tin after 5 minutes without getting what he wants (yeah yeah, RTFM,
> I know. _I_ do, but we all know our users).

And tin will do the exact same thing.

> The thousands of different listing/loading/browsing commands don't
> help either, as they are layed out in a totally flat way: there is
> no "hirarchy" build of them with "general" commands which do the
> right thing most of the time and "expert" commands,
> unfortunately. Even the menu doesn't suggest such a hirarchy.

Feel free to suggest a better layout of commands.  I am sure Lars
would be happy to make Gnus equally usable to a totall dummy-type
beginner as well as RSI-prone-10-keys-per-second-control-meta-alt
expert.

> Conclusion: Follow the principle of least surprise,

I sounds like a broken record, but I'll say it again: the principle of
least surprise includes not creating giant files by default.  If
necessary, the manual should be updated to explain the available
commands better.

If a person doesn't want to even glance at the manual, he'll be better
off with tin anyway.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Psychos _do not_ explode when sunlight hits them."

Re: Gnus v5.4.62 is released

[Sudish Joseph]

Hrvoje Niksic writes:
> Jens Lautenbacher <jens@metrix.de> writes:
>> > Logical behaviour includes not creating a 100K or so .newsrc.eld
>> > by default.
>> 
>> I beg to differ. from the beginners point it's still a bit difficult
>> to set up a gnus environment.

> Exactly.  Which is why Gnus should provide the most palatable
> behaviour by default.  And I still think this category includes /not/
> creating 100K+ .newsrc.eld by default.

FWIW, I'm totally with Jens here.  

A lot of the listing/jumping/subscribing commands work off of the
killed list, as does newsgroup name completion.  It is highly
disconcerting to request some subset of the group list only to be
presented with the few you're subscribed to.  Especially when one is
told that Gnus' startup performance is directly proportional to how
many groups have been killed.

Most commands do not have the intelligence to fetch the active file to
flesh out a slimmed down killed-list when they're invoked -- a good
thing, IMO, since the latency for a complete active file download (we
have ~30K entries in our active file, for eg.) and the accompanying
memory/cpu usage as Gnus parses it is quite daunting even on a fast
box. 

I quickly learnt to set save-killed-list to t when I left OSU with
it's small active file to a server with a reasonable number of
groups.  Downloading the active file over a 28.8 link (or even
10Mbps ethernet at work, given our active file) is simply not viable
for most operations where it's necessary.

The loss of functionality annoyed me *hugely*.  For instance, I had to
guess at and type in the names of groups I wanted to subscribe to -- a
show stopper.  And I'm not a new user and even understood why things
seemed so broken.

Finally, I do not understand why disk space is the critical resource
in this instance.  The resources we'd sacrifice to gain disk space
would be latency, bandwidth and DTRTness.  Currently, disk space is a
lot cheaper than either network latency or bandwidth -- for me,
anyway.

OTOH, the thing about save-killed-list that annoys me most is the
additional time taken to save .newsrc.eld.  We can address that in
other ways than to default to not saving killed-list.  Since it's
largest component is the list of killed groups, and since that list is 
changed infrequently, it could be split out to a separate file (which
could even be loaded only on demand, if needed).

-Sudish

Re: Gnus v5.4.62 is released

[Hrvoje Niksic]

Sudish Joseph <sj@eng.mindspring.net> writes:

> >> I beg to differ. from the beginners point it's still a bit difficult
> >> to set up a gnus environment.
> 
> > Exactly.  Which is why Gnus should provide the most palatable
> > behaviour by default.  And I still think this category includes /not/
> > creating 100K+ .newsrc.eld by default.
> 
> FWIW, I'm totally with Jens here.  
> 
> A lot of the listing/jumping/subscribing commands work off of the
> killed list, as does newsgroup name completion.
[...]
> I quickly learnt to set save-killed-list to t when I left OSU with
> it's small active file to a server with a reasonable number of
> groups.

With the new default of `gnus-read-active-file' to `some', the killed
list will never have been constructed in the first place.

> Finally, I do not understand why disk space is the critical resource
> in this instance.

I didn't say it was the "critical resource" -- it's only a matter of
well-behaving.  Programs that save such large files by default don't
look well-behaving to me.  YMMV.

A practical reason is that there are people trying to run Gnus in a
multiuser environment, where they have a quota.  The size of
.newsrc.eld can matter to them.

> OTOH, the thing about save-killed-list that annoys me most is the
> additional time taken to save .newsrc.eld.  We can address that in
> other ways than to default to not saving killed-list.

How?

> Since it's largest component is the list of killed groups, and since
> that list is changed infrequently, it could be split out to a
> separate file (which could even be loaded only on demand, if
> needed).

Here you have touched a separate issue, which is caching of
server-side data.  For instance, Gnus might be much more useful if it
cached things like newsgroups list, newsgroup descriptions, and even
XOVER info, locally (Netscape 4 newsreader caches XOVER).

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
* Vi is the God of editors.
* Emacs is the editor of Gods.

Re: Gnus v5.4.62 is released

[Sudish Joseph]

Hrvoje Niksic writes:
> With the new default of `gnus-read-active-file' to `some', the killed
> list will never have been constructed in the first place.

I guess I missed that setting.  Note that the killed-list only needs
to be setup once -- I run with g-r-a-f set to 'some and g-s-k-l set to 
t.  The newgroups check suffices to keep it in synch with the server.

> A practical reason is that there are people trying to run Gnus in a
> multiuser environment, where they have a quota.  The size of
> .newsrc.eld can matter to them.

IMO we shouldn't cripple functionality to help an unknown problem with
disk quotas.  The user is the only one who knows what she needs, let
them make the decision to forgo functionailty for disk space.

>> OTOH, the thing about save-killed-list that annoys me most is the
>> additional time taken to save .newsrc.eld.  We can address that in
>> other ways than to default to not saving killed-list.

> How?

See below.

>> Since it's largest component is the list of killed groups, and since
>> that list is changed infrequently, it could be split out to a
>> separate file (which could even be loaded only on demand, if
>> needed).

By saving it only when it's changed.

> Here you have touched a separate issue, which is caching of
> server-side data.  For instance, Gnus might be much more useful if it
> cached things like newsgroups list, newsgroup descriptions, and even
> XOVER info, locally (Netscape 4 newsreader caches XOVER).

Sure, it's a separate issue, but it's one that's relevant to the
subject here.  Of all the cacheable items, the active file is the only 
one that actually affects functionality.  The others are performance
hacks.  I'm not saying performance isn't an important consideration -- 
just that a crippled newsreader will turn away more new users.

-Sudish

Re: Gnus v5.4.62 is released

[Jens Lautenbacher]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Jens Lautenbacher <jens@metrix.de> writes:
> 
> > > Logical behaviour includes not creating a 100K or so .newsrc.eld
> > > by default.
> > 
> > I beg to differ. from the beginners point it's still a bit difficult
> > to set up a gnus environment.
> 
> Exactly.  Which is why Gnus should provide the most palatable
> behaviour by default.  And I still think this category includes /not/
> creating 100K+ .newsrc.eld by default.

Disk space? 100k+? even 300k wouldn't matter. 
 
> > Looking at other news readers (blasphemy, I know) I can simply list
> > all the groups and enter them.
> 
> You can do it in Gnus, too.  Commands like `10 A T' will connect to
> the server, get the list of groups and list them.  I don't need the
> list every day.  And a beginner certainly doesn't need it in his
> .newsrc.eld -- by default.

Ach Quatsch!

You can't be serious suggesting that it's a user friendly behaviour to
need one time something like 10 A T and some other time just use A k
or A A to list "simply all groups", depending on the setting of some
varibale and depending if some funny internal list/file is
build/retrieved.

> > But it's extremely non-logical if suddenly I can't access the whole
> > feed anymore (...)
> 
> Sure you can -- see above.

No you can't; see above. In some moon reader it's one keystroke to get 
all groups. I don't care as a user if the program caches this list or not
if it's only fast enougth. The reason that tin can just forget about
all this is that it spends almost no time with parsing, while gnus....


> > -- and even at a fast scientific internet access with a fast computer
> > it still takes damned long to load the whole active file from the
> > server.
> 
> That's what all these others newsreaders do, in case you didn't know.

I know. I'm taking about moron newsreaders, I don't state I'm one.

> > Besides that a newbie will not know what to do, and will switch to
> > tin after 5 minutes without getting what he wants (yeah yeah, RTFM,
> > I know. _I_ do, but we all know our users).
> 
> And tin will do the exact same thing.

But I don't care because it does whatever it does fast.

> > The thousands of different listing/loading/browsing commands don't
> > help either, as they are layed out in a totally flat way: there is
> > no "hirarchy" build of them with "general" commands which do the
> > right thing most of the time and "expert" commands,
> > unfortunately. Even the menu doesn't suggest such a hirarchy.
> 
> Feel free to suggest a better layout of commands.  I am sure Lars
> would be happy to make Gnus equally usable to a totall dummy-type
> beginner as well as RSI-prone-10-keys-per-second-control-meta-alt
> expert.
> 
> > Conclusion: Follow the principle of least surprise,
> 
> I sounds like a broken record, but I'll say it again: the principle of
> least surprise includes not creating giant files by default.  If
> necessary, the manual should be updated to explain the available
> commands better.
> 
> If a person doesn't want to even glance at the manual, he'll be better
> off with tin anyway.

Re: Gnus v5.4.62 is released

[Hrvoje Niksic]

Jens Lautenbacher <jens@metrix.de> writes:

> > Exactly.  Which is why Gnus should provide the most palatable
> > behaviour by default.  And I still think this category includes /not/
> > creating 100K+ .newsrc.eld by default.
> 
> Disk space? 100k+? even 300k wouldn't matter.

So we differ.

> You can't be serious suggesting that it's a user friendly behaviour to
> need one time something like 10 A T

I didn't say that.  I just implied that you /can/ get the listing,
even with `gnus-read-active-file' so `some'.

> > > But it's extremely non-logical if suddenly I can't access the whole
> > > feed anymore (...)
> > 
> > Sure you can -- see above.
> 
> No you can't; see above.

What is this?  A word game?

> In some moon reader it's one keystroke to get all groups.

Then we should make it so in Gnus, if you consider it important.  Or
back out this change -- because it's already been done, you know.

> I don't care as a user if the program caches this list or not if
> it's only fast enougth. The reason that tin can just forget about
> all this is that it spends almost no time with parsing, while
> gnus....

Well, there you have it -- and that was the exact reason to change for 
`gnus-read-active-file' to default to `some'.

Maybe Gnus should read the whole active file the first time it starts
up, and save the killed list for future usage?  The obnoxious disk
space usage still remains, but I guess noone really cares these days.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

Re: Gnus v5.4.62 is released

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Maybe Gnus should read the whole active file the first time it starts
> up, and save the killed list for future usage?

Yes, I think that might be reasonable behavior.

> The obnoxious disk space usage still remains, but I guess noone
> really cares these days.

Nobody does, much.  My home account is 120Mb du tells me.  300k
ekstra?  Pff.  Buy more disks.  :-)

Reading the 300k file is quite fast, but writing it isn't.  I think
that's something that the user can tweak if it's a problem, though.
It's more important to be able to say `j alt.bi<TAB>pi<TAB>furnit<TAB>'.

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

Re: Gnus v5.4.62 is released

[Steven L Baur]

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

> Fri Jul  4 13:00:39 1997  enami tsugutomo  <enami@but-b.or.jp>

> 	* gnus-group.el (gnus-group-set-mode-line): Use new, shorter
> 	format. 

> diff -u -r1.17 -r1.18
> --- gnus-group.el       1997/06/29 23:12:30     1.17
> +++ gnus-group.el       1997/07/07 00:52:41     1.18
> @@ -1213,8 +1213,7 @@
>                      (not (zerop (buffer-size))))))
>             (mode-string (eval gformat)))
>        ;; Say whether the dribble buffer has been modified.
> -       (setq mode-line-modified
> -             (if modified "--**- " "----- "))
> +       (setq mode-line-modified (if modified "**" "--"))
>         ;; If the line is too long, we chop it off.
>        (when (> (length mode-string) max-len)
>          (setq mode-string (substring mode-string 0 (- max-len 4))))

Count me as one vote against the new format.  Gnus wastes too much
valuable modeline space, it is true.  But correcting it this way
doesn't seem to me to be the Right Thing To Do.

Actually, I thought it was an XEmacs bug when I first saw it.
-- 
steve@calag.com baur
Unsolicited commercial e-mail will be billed at $250/message.

Re: Gnus v5.4.62 is released

[Lars Magne Ingebrigtsen]

Steven L Baur <steve@xemacs.org> writes:

> Count me as one vote against the new format.  Gnus wastes too much
> valuable modeline space, it is true.  But correcting it this way
> doesn't seem to me to be the Right Thing To Do.

Oh, that's the way mode lines look in Emacs 20.  So...

I think it looks kinda too squished up, but it is three junk chars
shorter, which is a plus.

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

Re: Gnus v5.4.62 is released

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Steven L Baur <steve@xemacs.org> writes:
> 
> > Count me as one vote against the new format.  Gnus wastes too much
> > valuable modeline space, it is true.  But correcting it this way
> > doesn't seem to me to be the Right Thing To Do.
> 
> Oh, that's the way mode lines look in Emacs 20.  So...

Yes I know, but it doesn't look that way in XEmacs.  Can you please
conditionalize the change, until we introduce the same outlook?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
* Vi is the God of editors.
* Emacs is the editor of Gods.

Re: Gnus v5.4.62 is released

[Steven L Baur]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> Steven L Baur <steve@xemacs.org> writes:
>> 
>> > Count me as one vote against the new format.  Gnus wastes too much
>> > valuable modeline space, it is true.  But correcting it this way
>> > doesn't seem to me to be the Right Thing To Do.
>> 
>> Oh, that's the way mode lines look in Emacs 20.  So...

> Yes I know, but it doesn't look that way in XEmacs.  Can you please
> conditionalize the change, until we introduce the same outlook?

A conditionalized change would be good.  One possible method would be
to test against `modeline-modified' and if it's '("--%1*%1+-") use the 
longer format.

This text is a pushable button in XEmacs that calls
`vc-toggle-read-only', so I'm not sure I wish to reduce it this much.
-- 
steve@calag.com baur
Unsolicited commercial e-mail will be billed at $250/message.

Re: Gnus v5.4.62 is released

[Lars Magne Ingebrigtsen]

Steven L Baur <steve@xemacs.org> writes:

> A conditionalized change would be good.  One possible method would be
> to test against `modeline-modified' and if it's '("--%1*%1+-") use the 
> longer format.

I've now coditionalized it.  I've simply made is be long under XEmacs
19 and 20 and Emacs 19 and short under everything else.

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

Re: Gnus v5.4.62 is released

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Steven L Baur <steve@xemacs.org> writes:
> 
> > A conditionalized change would be good.  One possible method would be
> > to test against `modeline-modified' and if it's '("--%1*%1+-") use the 
> > longer format.
> 
> I've now coditionalized it.  I've simply made is be long under XEmacs
> 19 and 20 and Emacs 19 and short under everything else.

The modeline is still short in XEmacs, at least in Group buffer.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Idle RAM is the Devil's playground.

Re: Gnus v5.4.62 is released

[Steven L Baur]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> Steven L Baur <steve@xemacs.org> writes:
>> 
>> > A conditionalized change would be good.  One possible method would be
>> > to test against `modeline-modified' and if it's '("--%1*%1+-") use the 
>> > longer format.
>> 
>> I've now coditionalized it.  I've simply made is be long under XEmacs
>> 19 and 20 and Emacs 19 and short under everything else.

> The modeline is still short in XEmacs, at least in Group buffer.

Ack!  I fixed the initialization in gnus-ems.el and it's still wrong.

Other culprits appear to be in gnus-salt.el and gnus.el:

(defun gnus-carpal-mode ()
 ...
  (setq mode-line-modified "-- ")
 ...

(defun gnus-simplify-mode-line ()
  "Make mode lines a bit simpler."
  (setq mode-line-modified "-- ")
 ...

[I previously sent this patch to gnus-bug]

1997-07-17  Steven L Baur  <steve@altair.xemacs.org>

	* gnus-ems.el (gnus-mode-line-modified): Refine detection on
	whether narrow indicators should be used.

Index: gnus-ems.el
===================================================================
RCS file: /usr/local/xemacs/xemacs-20.0/lisp/gnus/gnus-ems.el,v
retrieving revision 1.9
diff -u -r1.9 gnus-ems.el
--- gnus-ems.el	1997/07/13 22:41:17	1.9
+++ gnus-ems.el	1997/07/17 08:31:45
@@ -35,8 +35,8 @@
 (defvar gnus-mouse-2 [mouse-2])
 (defvar gnus-down-mouse-2 [down-mouse-2])
 (defvar gnus-mode-line-modified
-  (if (and (not gnus-xemacs)
-	   (< emacs-major-version 20))
+  (if (or gnus-xemacs
+	  (< emacs-major-version 20))
       '("--**-" . "-----")
     '("**" "--")))