* Gnus v5.4.62 is released @ 1997-07-06 15:24 Lars Magne Ingebrigtsen 1997-07-06 16:05 ` Hrvoje Niksic 1997-07-07 8:51 ` Steven L Baur 0 siblings, 2 replies; 22+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-07-06 15:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-06 15:24 Gnus v5.4.62 is released Lars Magne Ingebrigtsen @ 1997-07-06 16:05 ` Hrvoje Niksic 1997-07-07 9:08 ` Lars Magne Ingebrigtsen 1997-07-07 8:51 ` Steven L Baur 1 sibling, 1 reply; 22+ messages in thread From: Hrvoje Niksic @ 1997-07-06 16:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-06 16:05 ` Hrvoje Niksic @ 1997-07-07 9:08 ` Lars Magne Ingebrigtsen 1997-07-07 21:14 ` Hrvoje Niksic 0 siblings, 1 reply; 22+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-07-07 9:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-07 9:08 ` Lars Magne Ingebrigtsen @ 1997-07-07 21:14 ` Hrvoje Niksic 1997-07-07 23:15 ` Jens Lautenbacher 0 siblings, 1 reply; 22+ messages in thread From: Hrvoje Niksic @ 1997-07-07 21:14 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-07 21:14 ` Hrvoje Niksic @ 1997-07-07 23:15 ` Jens Lautenbacher 1997-07-07 23:52 ` Hrvoje Niksic 0 siblings, 1 reply; 22+ messages in thread From: Jens Lautenbacher @ 1997-07-07 23:15 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-07 23:15 ` Jens Lautenbacher @ 1997-07-07 23:52 ` Hrvoje Niksic 1997-07-08 1:28 ` Steven L Baur 1997-07-08 2:39 ` Jens Lautenbacher 0 siblings, 2 replies; 22+ messages in thread From: Hrvoje Niksic @ 1997-07-07 23:52 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-07 23:52 ` Hrvoje Niksic @ 1997-07-08 1:28 ` Steven L Baur 1997-07-08 2:39 ` Jens Lautenbacher 1 sibling, 0 replies; 22+ messages in thread From: Steven L Baur @ 1997-07-08 1:28 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-07 23:52 ` Hrvoje Niksic 1997-07-08 1:28 ` Steven L Baur @ 1997-07-08 2:39 ` Jens Lautenbacher 1997-07-08 4:01 ` Hrvoje Niksic 1 sibling, 1 reply; 22+ messages in thread From: Jens Lautenbacher @ 1997-07-08 2:39 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-08 2:39 ` Jens Lautenbacher @ 1997-07-08 4:01 ` Hrvoje Niksic 1997-07-08 5:28 ` Sudish Joseph 1997-07-08 18:30 ` Jens Lautenbacher 0 siblings, 2 replies; 22+ messages in thread From: Hrvoje Niksic @ 1997-07-08 4:01 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-08 4:01 ` Hrvoje Niksic @ 1997-07-08 5:28 ` Sudish Joseph 1997-07-08 7:34 ` Hrvoje Niksic 1997-07-08 18:30 ` Jens Lautenbacher 1 sibling, 1 reply; 22+ messages in thread From: Sudish Joseph @ 1997-07-08 5:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-08 5:28 ` Sudish Joseph @ 1997-07-08 7:34 ` Hrvoje Niksic 1997-07-08 16:56 ` Sudish Joseph 0 siblings, 1 reply; 22+ messages in thread From: Hrvoje Niksic @ 1997-07-08 7:34 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-08 7:34 ` Hrvoje Niksic @ 1997-07-08 16:56 ` Sudish Joseph 0 siblings, 0 replies; 22+ messages in thread From: Sudish Joseph @ 1997-07-08 16:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-08 4:01 ` Hrvoje Niksic 1997-07-08 5:28 ` Sudish Joseph @ 1997-07-08 18:30 ` Jens Lautenbacher 1997-07-08 20:49 ` Hrvoje Niksic 1 sibling, 1 reply; 22+ messages in thread From: Jens Lautenbacher @ 1997-07-08 18:30 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-08 18:30 ` Jens Lautenbacher @ 1997-07-08 20:49 ` Hrvoje Niksic 1997-07-10 18:16 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 22+ messages in thread From: Hrvoje Niksic @ 1997-07-08 20:49 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-08 20:49 ` Hrvoje Niksic @ 1997-07-10 18:16 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 22+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-07-10 18:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-06 15:24 Gnus v5.4.62 is released Lars Magne Ingebrigtsen 1997-07-06 16:05 ` Hrvoje Niksic @ 1997-07-07 8:51 ` Steven L Baur 1997-07-07 11:36 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 22+ messages in thread From: Steven L Baur @ 1997-07-07 8:51 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-07 8:51 ` Steven L Baur @ 1997-07-07 11:36 ` Lars Magne Ingebrigtsen 1997-07-07 21:13 ` Hrvoje Niksic 0 siblings, 1 reply; 22+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-07-07 11:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-07 11:36 ` Lars Magne Ingebrigtsen @ 1997-07-07 21:13 ` Hrvoje Niksic 1997-07-07 23:56 ` Steven L Baur 0 siblings, 1 reply; 22+ messages in thread From: Hrvoje Niksic @ 1997-07-07 21:13 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-07 21:13 ` Hrvoje Niksic @ 1997-07-07 23:56 ` Steven L Baur 1997-07-10 18:08 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 22+ messages in thread From: Steven L Baur @ 1997-07-07 23:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-07 23:56 ` Steven L Baur @ 1997-07-10 18:08 ` Lars Magne Ingebrigtsen 1997-07-13 23:25 ` Hrvoje Niksic 0 siblings, 1 reply; 22+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-07-10 18:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-10 18:08 ` Lars Magne Ingebrigtsen @ 1997-07-13 23:25 ` Hrvoje Niksic 1997-07-18 3:12 ` Steven L Baur 0 siblings, 1 reply; 22+ messages in thread From: Hrvoje Niksic @ 1997-07-13 23:25 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Gnus v5.4.62 is released 1997-07-13 23:25 ` Hrvoje Niksic @ 1997-07-18 3:12 ` Steven L Baur 0 siblings, 0 replies; 22+ messages in thread From: Steven L Baur @ 1997-07-18 3:12 UTC (permalink / raw) 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)) '("--**-" . "-----") '("**" "--"))) ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~1997-07-18 3:12 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-07-06 15:24 Gnus v5.4.62 is released Lars Magne Ingebrigtsen 1997-07-06 16:05 ` Hrvoje Niksic 1997-07-07 9:08 ` Lars Magne Ingebrigtsen 1997-07-07 21:14 ` Hrvoje Niksic 1997-07-07 23:15 ` Jens Lautenbacher 1997-07-07 23:52 ` Hrvoje Niksic 1997-07-08 1:28 ` Steven L Baur 1997-07-08 2:39 ` Jens Lautenbacher 1997-07-08 4:01 ` Hrvoje Niksic 1997-07-08 5:28 ` Sudish Joseph 1997-07-08 7:34 ` Hrvoje Niksic 1997-07-08 16:56 ` Sudish Joseph 1997-07-08 18:30 ` Jens Lautenbacher 1997-07-08 20:49 ` Hrvoje Niksic 1997-07-10 18:16 ` Lars Magne Ingebrigtsen 1997-07-07 8:51 ` Steven L Baur 1997-07-07 11:36 ` Lars Magne Ingebrigtsen 1997-07-07 21:13 ` Hrvoje Niksic 1997-07-07 23:56 ` Steven L Baur 1997-07-10 18:08 ` Lars Magne Ingebrigtsen 1997-07-13 23:25 ` Hrvoje Niksic 1997-07-18 3:12 ` Steven L Baur
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).