* Feature request: strip banners from all groups matching a regexp @ 2000-12-22 16:54 Christopher Splinter 2000-12-22 18:19 ` Jeff Senn ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Christopher Splinter @ 2000-12-22 16:54 UTC (permalink / raw) Hi, IWBNI there were some functionality which would allow the user to strip banners from messages in groups which match a certain regexp using something like (setq gnus-strip-banners-from-groups '(("nnml:lists\\.debian\\..*" . signature))) ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Feature request: strip banners from all groups matching a regexp 2000-12-22 16:54 Feature request: strip banners from all groups matching a regexp Christopher Splinter @ 2000-12-22 18:19 ` Jeff Senn 2000-12-22 20:41 ` Christopher Splinter 2000-12-22 18:27 ` Charles Sebold 2000-12-23 2:08 ` Feature request: strip banners from all groups matching a regexp ShengHuo ZHU 2 siblings, 1 reply; 26+ messages in thread From: Jeff Senn @ 2000-12-22 18:19 UTC (permalink / raw) Cc: ding Christopher Splinter <chris@splinter.inka.de> writes: > Hi, > > IWBNI there were some functionality which would allow the user to > strip banners from messages in groups which match a certain regexp > using something like > > (setq gnus-strip-banners-from-groups > '(("nnml:lists\\.debian\\..*" . signature))) M-x apropos \r banner \r :-) Or did you mean you specifically wanted a regex for the group(s) rather than a group parameter that specifies a regex for the banner? Aside: Is the 'banner' parameter documented in the Group Parameters Info? I don't see it... -- -Jas ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Feature request: strip banners from all groups matching a regexp 2000-12-22 18:19 ` Jeff Senn @ 2000-12-22 20:41 ` Christopher Splinter 0 siblings, 0 replies; 26+ messages in thread From: Christopher Splinter @ 2000-12-22 20:41 UTC (permalink / raw) * Jeff Senn <senn@maya.com>: >> IWBNI there were some functionality which would allow the user to >> strip banners from messages in groups which match a certain regexp >> using something like >> >> (setq gnus-strip-banners-from-groups >> '(("nnml:lists\\.debian\\..*" . signature))) > Or did you mean you specifically wanted a regex for the > group(s) rather than a group parameter that specifies a regex > for the banner? Yes. > Aside: Is the 'banner' parameter documented in the Group > Parameters Info? I don't see it... No, but it's in the 'Article Hiding' node. I just sent a patch with documentation for this group parameter to bugs@gnus.org. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Feature request: strip banners from all groups matching a regexp 2000-12-22 16:54 Feature request: strip banners from all groups matching a regexp Christopher Splinter 2000-12-22 18:19 ` Jeff Senn @ 2000-12-22 18:27 ` Charles Sebold 2000-12-22 20:21 ` Christopher Splinter 2000-12-23 2:08 ` Feature request: strip banners from all groups matching a regexp ShengHuo ZHU 2 siblings, 1 reply; 26+ messages in thread From: Charles Sebold @ 2000-12-22 18:27 UTC (permalink / raw) On 25 Kislev 5761, Christopher Splinter wrote: > IWBNI there were some functionality which would allow the user to > strip banners from messages in groups which match a certain regexp > using something like > > (setq gnus-strip-banners-from-groups > '(("nnml:lists\\.debian\\..*" . signature))) Note: I'm running Gnus from CVS, earlier versions may or may not do this. Does this help? If you have the Gnus manual in your info, put your cursor after the next line and hit C-x C-e (Info-goto-node "(gnus)Article Hiding") ,---- | `W W B' | Strip the banner specified by the `banner' group parameter | (`gnus-article-strip-banner'). This is mainly used to hide those | annoying banners and/or signatures that some mailing lists and | moderated groups adds to all the messages. The way to use this | function is to add the `banner' group parameter (*note Group | Parameters::.) to the group you want banners stripped from. The | parameter either be a string, which will be interpreted as a | regular expression matching text to be removed, or the symbol | `signature', meaning that the (last) signature should be removed, | or other symbol, meaning that the corresponding regular expression | in `gnus-article-banner-alist' is used. `---- -- Charles Sebold Random Answer to an Emacs Very Frequently Asked Question: Eshell or ansi-color.el solves problems with garbage GCC or ls output. -- 25th of Kislev, 5761 -- Power is danger. -- The Centurion, "Balance of Terror", stardate 1709.2 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Feature request: strip banners from all groups matching a regexp 2000-12-22 18:27 ` Charles Sebold @ 2000-12-22 20:21 ` Christopher Splinter 2000-12-23 12:38 ` Kai Großjohann 0 siblings, 1 reply; 26+ messages in thread From: Christopher Splinter @ 2000-12-22 20:21 UTC (permalink / raw) * Charles Sebold <csebold@ezl.com>: > (Info-goto-node "(gnus)Article Hiding") > > ,---- > | `W W B' > | Strip the banner specified by the `banner' group parameter > | (`gnus-article-strip-banner'). This uses group parameters (which is very annoying if you read lots of groups that have the same banner). ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Feature request: strip banners from all groups matching a regexp 2000-12-22 20:21 ` Christopher Splinter @ 2000-12-23 12:38 ` Kai Großjohann 2000-12-23 12:59 ` NAGY Andras 0 siblings, 1 reply; 26+ messages in thread From: Kai Großjohann @ 2000-12-23 12:38 UTC (permalink / raw) Cc: ding On 22 Dec 2000, Christopher Splinter wrote: > This uses group parameters (which is very annoying if you read > lots of groups that have the same banner). Maybe topic parameters are your friends. Though you then have to group all the groups with the same banner in the same topic. Hm. kai -- ~/.signature ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Feature request: strip banners from all groups matching a regexp 2000-12-23 12:38 ` Kai Großjohann @ 2000-12-23 12:59 ` NAGY Andras 2000-12-23 13:11 ` Kai Großjohann 2001-02-23 16:41 ` regexp-based group parameters NAGY Andras 0 siblings, 2 replies; 26+ messages in thread From: NAGY Andras @ 2000-12-23 12:59 UTC (permalink / raw) Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes: > > This uses group parameters (which is very annoying if you read > > lots of groups that have the same banner). > > Maybe topic parameters are your friends. Though you then have to > group all the groups with the same banner in the same topic. Hm. Some of the group options can be set based on group and topic parameters as well as on group regexps (say, total-expiry). Others only based on parameters (banner). And perhaps some only based on regexps. :) Shouldn't there be a unified way for doing stuff like this? Andras ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Feature request: strip banners from all groups matching a regexp 2000-12-23 12:59 ` NAGY Andras @ 2000-12-23 13:11 ` Kai Großjohann 2001-02-23 16:41 ` regexp-based group parameters NAGY Andras 1 sibling, 0 replies; 26+ messages in thread From: Kai Großjohann @ 2000-12-23 13:11 UTC (permalink / raw) Cc: ding On 23 Dec 2000, NAGY Andras wrote: > Shouldn't there be a unified way for doing stuff like this? Yes. I wish there was. kai -- ~/.signature ^ permalink raw reply [flat|nested] 26+ messages in thread
* regexp-based group parameters 2000-12-23 12:59 ` NAGY Andras 2000-12-23 13:11 ` Kai Großjohann @ 2001-02-23 16:41 ` NAGY Andras 2001-02-23 18:57 ` Toby Speight ` (2 more replies) 1 sibling, 3 replies; 26+ messages in thread From: NAGY Andras @ 2001-02-23 16:41 UTC (permalink / raw) NAGY Andras <nagya@inf.elte.hu> writes: > Some of the group options can be set based on group and topic > parameters as well as on group regexps (say, total-expiry). Others > only based on parameters (banner). And perhaps some only based on > regexps. :) > > Shouldn't there be a unified way for doing stuff like this? Let's summarize once more: many functions in Gnus behave differently, depending on which group they operate on. There is (was?) a tendency among these functions to introduce a custom variable, containing a regexp, to be matched against group names, to decide which groups they are supposed to deal width. (Examples include gnus-total-expirable-newsgroups, gnus-mailing-list-groups, gnus-permanently-visible-groups etc). Generally, a group matching or not one of these regexps defines a boolean parameter for that group. There are other type of such variables, regexp->something alists (e.g. gnus-posting-styles) which assign a parameter to a group, based on its name. Besides this, there is the group/topic parameters mechanism, where parameters can be assigned directly, or based on the groups place in the topic hierarchy. Furthermore, this info is stored in the newsrc file instead of being customizable by the user through a config file. Many (but not all, and even if yes, see below) Gnus functions (posting styles, expiry, etc) allow the user to specify group parameters via the gnus-group-find-parameter API as well as the "non-standard" custom regexp way. Extending the find-parameter implementation to treat not only group/topic parameters found in newsrc, but also those found in a newly introduced regexp->param-list alist, would have the following advantages: * Gnus functions could use a single interface to fetch group parameters based on both methods, without having to deal with regexp matching and stuff. * Users would be able to define every group parameter based on regexps as well, in addition to the group/topic method. * The latter would allow storing group parameters in a static config file, suitable for using on several hosts, instead of the host-dependent, ever-changing newsrc.eld. While writing this, I have found gnus-define-group-parameter which is close to what I am talking about. This defines a function (gnus-parameter-%s group) for fetching a parameter's value, and this function makes use of gnus-parameter-%s-alist, which maps group regexps to parameter values. However, there are several problems with this: * For now, only 7 group parameters are defined this way. * For this reason, the rest of Gnus does not make use of these functions, but uses gnus-group-find-parameter, which ignores the contents of gnus-parameter-%s-alist. * Group/topic parameters allow setting arbitrary variables, not only `strict' parameters. * There is still no way to assign multiple parameters to a set of groups at once. To demonstrate this: I cannot (but would like to) write the following in my .gnus: (setq gnus-parameters '(("mail\..*" (gnus-show-threads . nil) (gnus-use-scoring . nil) (gnus-summary-line-format . "%U%R%z%I%(%[%d:%ub%-20,20f%]%) %s\n") (gcc-self . t) (dispaly . all)) ("list\..*" (total-expire . t) (broken-reply-to . t)))) I think the example speaks for itself. (Setting everything in one place, independetly of newsrc.eld and topic topology.) Anyone willing to implement this? Introducing the new variable (named gnus-parameters above) and modifying gnus-group-find-parameter would do the trick, I believe. Andras ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: regexp-based group parameters 2001-02-23 16:41 ` regexp-based group parameters NAGY Andras @ 2001-02-23 18:57 ` Toby Speight 2001-02-23 20:54 ` Paul Jarc 2001-02-23 22:35 ` ShengHuo ZHU 2 siblings, 0 replies; 26+ messages in thread From: Toby Speight @ 2001-02-23 18:57 UTC (permalink / raw) 0> In article <dzc1ysps66o.fsf_-_@pandora.inf.elte.hu>, 0> NAGY Andras <URL:mailto:nagya@inf.elte.hu> ("Nagy") wrote: Nagy> There is (was?) a tendency among these functions to introduce a Nagy> custom variable, containing a regexp, to be matched against Nagy> group names, to decide which groups they are supposed to deal Nagy> width. Nagy> Nagy> There are other type of such variables, regexp->something alists Nagy> (e.g. gnus-posting-styles) which assign a parameter to a group, Nagy> based on its name. Nagy> Nagy> Besides this, there is the group/topic parameters mechanism, Nagy> where parameters can be assigned directly, or based on the Nagy> groups place in the topic hierarchy. Furthermore, this info is Nagy> stored in the newsrc file instead of being customizable by the Nagy> user through a config file. There's also the possibility of setting group-local variables via score files. It would be nice to have these things consistent, and with a clear statement about when they are applied, and what the precedence order is. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: regexp-based group parameters 2001-02-23 16:41 ` regexp-based group parameters NAGY Andras 2001-02-23 18:57 ` Toby Speight @ 2001-02-23 20:54 ` Paul Jarc 2001-02-23 21:35 ` Kai Großjohann 2001-02-23 22:38 ` ShengHuo ZHU 2001-02-23 22:35 ` ShengHuo ZHU 2 siblings, 2 replies; 26+ messages in thread From: Paul Jarc @ 2001-02-23 20:54 UTC (permalink / raw) NAGY Andras <nagya@inf.elte.hu> writes: > * Gnus functions could use a single interface to fetch group > parameters based on both methods, without having to deal with regexp > matching and stuff. This is an important goal. > * Users would be able to define every group parameter based on regexps > as well, in addition to the group/topic method. I'm not sure what you mean here. But see below for my suggestion. > * Group/topic parameters allow setting arbitrary variables, not only > `strict' parameters. I'm not sure this is a problem. Your gnus-parameters doesn't seem to address it, either. > To demonstrate this: I cannot (but would like to) write the following > in my .gnus: ... > I think the example speaks for itself. (Setting everything in one > place, independetly of newsrc.eld and topic topology.) Not bad, but I'm not especially fond of the regexp matching; my naming scheme for my groups should not be determined by whether they have similar parameters, any more than my topic hierarchy should be so determined. I'd like it if parameters were (or could be) stored in backends. Backends can already use -request-update-info to correct Gnus's parameters, so we just need a way for Gnus to notify the backend when the user modifies the parameters. (Then once all backends do this, Gnus could stop redundantly storing parameters in newsrc.eld.) Also, to provide for hierarchical inheritance, we could have a parameter called, say, parameter-parent, whose value is a group. Then when trying to find the value of parameter foo, if the group doesn't have a value for foo, you check the parent group, recursively, stopping when you find a group that has foo, or one that has no parent. Dummy groups could be used to hold sets of parameters; real groups would use the dummy as their parent. Your suggestion (like mine) fails to cover the capability we have now of putting a group into multiple topics, and using the parameters of whichever topic the user entered through, but this seems like more trouble than it's worth, especially in situations where there is no "current" topic. Thoughts? paul ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: regexp-based group parameters 2001-02-23 20:54 ` Paul Jarc @ 2001-02-23 21:35 ` Kai Großjohann 2001-02-23 21:57 ` Paul Jarc 2001-02-24 15:49 ` Randal L. Schwartz 2001-02-23 22:38 ` ShengHuo ZHU 1 sibling, 2 replies; 26+ messages in thread From: Kai Großjohann @ 2001-02-23 21:35 UTC (permalink / raw) On 23 Feb 2001, Paul Jarc wrote: > Not bad, but I'm not especially fond of the regexp matching; my > naming scheme for my groups should not be determined by whether they > have similar parameters, any more than my topic hierarchy should be > so determined. I like to be able to say that all nnml:auto.* groups are auto-expirable. This way, I can put auto-expirable groups in various topics and I don't have to worry about setting the parameter on each and every new group (where I think it's appriate). Just to provide a counter-opinion to yours. Maybe regexp matching is useful to some people and thus shouldn't be removed. kai -- Be indiscrete. Do it continuously. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: regexp-based group parameters 2001-02-23 21:35 ` Kai Großjohann @ 2001-02-23 21:57 ` Paul Jarc 2001-02-23 22:29 ` Kai Großjohann 2001-02-24 15:49 ` Randal L. Schwartz 1 sibling, 1 reply; 26+ messages in thread From: Paul Jarc @ 2001-02-23 21:57 UTC (permalink / raw) Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes: > I like to be able to say that all nnml:auto.* groups are > auto-expirable. This way, I can put auto-expirable groups in various > topics and I don't have to worry about setting the parameter on each > and every new group (where I think it's appriate). Note that the hierarchy I suggested for parameters would be orthogonal to the hierarchy for UI (topics). Is using an "auto.*" name for a group any easier than adding a "parameter-parent" parameter? Hmm... I can imagine it would be useful for a group to have an ordered list of parents. Then groups g1 and g2 could share one set of attributes via a common parent p1, while g1 shares another set of attributes with group g3 via another parent p2; g2 wouldn't need to be a descendent of p2, and g3 wouldn't need to be a descendent of p1. > Just to provide a counter-opinion to yours. Maybe regexp matching is > useful to some people and thus shouldn't be removed. It's certainly useful. But if we can provide a single unified way of doing things that's at least *as useful* as any existing scheme, then that would seem like a good thing to do. paul ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: regexp-based group parameters 2001-02-23 21:57 ` Paul Jarc @ 2001-02-23 22:29 ` Kai Großjohann 0 siblings, 0 replies; 26+ messages in thread From: Kai Großjohann @ 2001-02-23 22:29 UTC (permalink / raw) On 23 Feb 2001, Paul Jarc wrote: > Note that the hierarchy I suggested for parameters would be > orthogonal to the hierarchy for UI (topics). Is using an "auto.*" > name for a group any easier than adding a "parameter-parent" > parameter? Oh, I completely missed the orthogonality. Of course, adding a `this is a ML group' parameter is just as simple. kai -- Be indiscrete. Do it continuously. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: regexp-based group parameters 2001-02-23 21:35 ` Kai Großjohann 2001-02-23 21:57 ` Paul Jarc @ 2001-02-24 15:49 ` Randal L. Schwartz 1 sibling, 0 replies; 26+ messages in thread From: Randal L. Schwartz @ 2001-02-24 15:49 UTC (permalink / raw) Cc: ding >>>>> "Kai" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes: Kai> On 23 Feb 2001, Paul Jarc wrote: >> Not bad, but I'm not especially fond of the regexp matching; my >> naming scheme for my groups should not be determined by whether they >> have similar parameters, any more than my topic hierarchy should be >> so determined. Kai> I like to be able to say that all nnml:auto.* groups are Kai> auto-expirable. This way, I can put auto-expirable groups in various Kai> topics and I don't have to worry about setting the parameter on each Kai> and every new group (where I think it's appriate). I do this already in my .gnus.el -- (setq gnus-total-expirable-newsgroups "^nnml:list\\.") -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: regexp-based group parameters 2001-02-23 20:54 ` Paul Jarc 2001-02-23 21:35 ` Kai Großjohann @ 2001-02-23 22:38 ` ShengHuo ZHU 2001-02-23 22:55 ` Paul Jarc 1 sibling, 1 reply; 26+ messages in thread From: ShengHuo ZHU @ 2001-02-23 22:38 UTC (permalink / raw) prj@po.cwru.edu (Paul Jarc) writes: [...] > > * Group/topic parameters allow setting arbitrary variables, not only > > `strict' parameters. > > I'm not sure this is a problem. Your gnus-parameters doesn't seem to > address it, either. As to group variables, it is. [...] > I'd like it if parameters were (or could be) stored in backends. > Backends can already use -request-update-info to correct Gnus's > parameters, so we just need a way for Gnus to notify the backend when > the user modifies the parameters. (Then once all backends do this, > Gnus could stop redundantly storing parameters in newsrc.eld.) Using -request-update-info is another issue. > Also, to provide for hierarchical inheritance, we could have a > parameter called, say, parameter-parent, whose value is a group. Then > when trying to find the value of parameter foo, if the group doesn't > have a value for foo, you check the parent group, recursively, > stopping when you find a group that has foo, or one that has no > parent. Dummy groups could be used to hold sets of parameters; real > groups would use the dummy as their parent. I don't like this idea. Regexp scheme is much clearer and easier to maintain. > Your suggestion (like mine) fails to cover the capability we have now > of putting a group into multiple topics, and using the parameters of > whichever topic the user entered through, but this seems like more > trouble than it's worth, especially in situations where there is no > "current" topic. This is the weakness of topics implementation. ShengHuo ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: regexp-based group parameters 2001-02-23 22:38 ` ShengHuo ZHU @ 2001-02-23 22:55 ` Paul Jarc 2001-02-23 23:22 ` ShengHuo ZHU 2001-02-24 12:04 ` Kai Großjohann 0 siblings, 2 replies; 26+ messages in thread From: Paul Jarc @ 2001-02-23 22:55 UTC (permalink / raw) ShengHuo ZHU <zsh@cs.rochester.edu> writes: > prj@po.cwru.edu (Paul Jarc) writes: > > > * Group/topic parameters allow setting arbitrary variables, not only > > > `strict' parameters. > > > > I'm not sure this is a problem. Your gnus-parameters doesn't seem to > > address it, either. > > As to group variables, it is. How so? > > I'd like it if parameters were (or could be) stored in backends. > > Backends can already use -request-update-info to correct Gnus's > > parameters, so we just need a way for Gnus to notify the backend when > > the user modifies the parameters. (Then once all backends do this, > > Gnus could stop redundantly storing parameters in newsrc.eld.) > > Using -request-update-info is another issue. What do you mean? > > Also, to provide for hierarchical inheritance, we could have a > > parameter called, say, parameter-parent, whose value is a group. [...] > > I don't like this idea. Regexp scheme is much clearer and easier to > maintain. But it also means that I can't deal with group names and parameters as the separate entities they are. If I want two groups to share a set of parameters, I'm *forced* to either name them similarly, or else use an ugly, *less* maintainable regexp to identify them. > > Your suggestion (like mine) fails to cover the capability we have now > > of putting a group into multiple topics, and using the parameters of > > whichever topic the user entered through, but this seems like more > > trouble than it's worth, especially in situations where there is no > > "current" topic. > > This is the weakness of topics implementation. Right. But parameter-parents would be an *ordered* list of parents, and unrelated to topics, so there'd be no ambiguity. paul ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: regexp-based group parameters 2001-02-23 22:55 ` Paul Jarc @ 2001-02-23 23:22 ` ShengHuo ZHU 2001-02-23 23:56 ` Paul Jarc 2001-02-24 12:04 ` Kai Großjohann 1 sibling, 1 reply; 26+ messages in thread From: ShengHuo ZHU @ 2001-02-23 23:22 UTC (permalink / raw) prj@po.cwru.edu (Paul Jarc) writes: > ShengHuo ZHU <zsh@cs.rochester.edu> writes: > > prj@po.cwru.edu (Paul Jarc) writes: > > > > * Group/topic parameters allow setting arbitrary variables, not only > > > > `strict' parameters. > > > > > > I'm not sure this is a problem. Your gnus-parameters doesn't seem to > > > address it, either. > > > > As to group variables, it is. > > How so? NAGY Andras means that regexp scheme was not able to configure group variables. In this sense, gnus-parameters can do this. > > > I'd like it if parameters were (or could be) stored in backends. > > > Backends can already use -request-update-info to correct Gnus's > > > parameters, so we just need a way for Gnus to notify the backend when > > > the user modifies the parameters. (Then once all backends do this, > > > Gnus could stop redundantly storing parameters in newsrc.eld.) > > > > Using -request-update-info is another issue. > > What do you mean? Unfortunately, we can not implement this for some backends without some extra helps (e.g. local files). It could also be a problem for shared or readonly groups. > > > Also, to provide for hierarchical inheritance, we could have a > > > parameter called, say, parameter-parent, whose value is a group. [...] > > > > I don't like this idea. Regexp scheme is much clearer and easier to > > maintain. > > But it also means that I can't deal with group names and parameters as > the separate entities they are. If I want two groups to share a set > of parameters, I'm *forced* to either name them similarly, or else use > an ugly, *less* maintainable regexp to identify them. You don't have to. mapconcat and regexp-quote are your friends. > > > Your suggestion (like mine) fails to cover the capability we have now > > > of putting a group into multiple topics, and using the parameters of > > > whichever topic the user entered through, but this seems like more > > > trouble than it's worth, especially in situations where there is no > > > "current" topic. > > > > This is the weakness of topics implementation. > > Right. But parameter-parents would be an *ordered* list of parents, > and unrelated to topics, so there'd be no ambiguity. It is difficult to avoid loop links in your parameter-parents scheme. ShengHuo ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: regexp-based group parameters 2001-02-23 23:22 ` ShengHuo ZHU @ 2001-02-23 23:56 ` Paul Jarc 0 siblings, 0 replies; 26+ messages in thread From: Paul Jarc @ 2001-02-23 23:56 UTC (permalink / raw) ShengHuo ZHU <zsh@cs.rochester.edu> writes: > prj@po.cwru.edu (Paul Jarc) writes: > > ShengHuo ZHU <zsh@cs.rochester.edu> writes: > > > prj@po.cwru.edu (Paul Jarc) writes: > > > > > * Group/topic parameters allow setting arbitrary variables, not only > > > > > `strict' parameters. > > > > > > > > I'm not sure this is a problem. Your gnus-parameters doesn't seem to > > > > address it, either. > > > > > > As to group variables, it is. > > > > How so? > > NAGY Andras means that regexp scheme was not able to configure group > variables. In this sense, gnus-parameters can do this. I don't think I understand. > Unfortunately, we can not implement [storing parameters in backends] > for some backends without some extra helps (e.g. local files). It > could also be a problem for shared or readonly groups. It would indeed require more work from backends, but it could be done. I'm implementing read-only groups for nnmaildir, but marks will still be stored in the backend; only the messages themselves are read-only, and only the messages themselves need to be. > > But it also means that I can't deal with group names and parameters as > > the separate entities they are. If I want two groups to share a set > > of parameters, I'm *forced* to either name them similarly, or else use > > an ugly, *less* maintainable regexp to identify them. > > You don't have to. mapconcat and regexp-quote are your friends. That seems rather more like a workaround than a solution. > It is difficult to avoid loop links in your parameter-parents scheme. Difficult for the code to detect tham, maybe, but not so difficult for humans to prevent them, I think. Must the more capable users be hindered by a feature designed to prevent mistakes by novices? paul ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: regexp-based group parameters 2001-02-23 22:55 ` Paul Jarc 2001-02-23 23:22 ` ShengHuo ZHU @ 2001-02-24 12:04 ` Kai Großjohann 2001-02-24 17:34 ` Paul Jarc 1 sibling, 1 reply; 26+ messages in thread From: Kai Großjohann @ 2001-02-24 12:04 UTC (permalink / raw) On 23 Feb 2001, Paul Jarc wrote: > But it also means that I can't deal with group names and parameters > as the separate entities they are. If I want two groups to share a > set of parameters, I'm *forced* to either name them similarly, or > else use an ugly, *less* maintainable regexp to identify them. There are topics, you know. kai -- Be indiscrete. Do it continuously. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: regexp-based group parameters 2001-02-24 12:04 ` Kai Großjohann @ 2001-02-24 17:34 ` Paul Jarc 2001-02-24 21:45 ` Kai Großjohann 0 siblings, 1 reply; 26+ messages in thread From: Paul Jarc @ 2001-02-24 17:34 UTC (permalink / raw) Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes: > On 23 Feb 2001, Paul Jarc wrote: > > But it also means that I can't deal with group names and parameters > > as the separate entities they are. If I want two groups to share a > > set of parameters, I'm *forced* to either name them similarly, or > > else use an ugly, *less* maintainable regexp to identify them. > > There are topics, you know. I know; I was talking about the hypothetical future where gnus-parameters is the One True (only?) way to set group parameters. Mind you, I'm not *entirely* happy with my suggestion either... does anyone else have any ideas? paul ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: regexp-based group parameters 2001-02-24 17:34 ` Paul Jarc @ 2001-02-24 21:45 ` Kai Großjohann 0 siblings, 0 replies; 26+ messages in thread From: Kai Großjohann @ 2001-02-24 21:45 UTC (permalink / raw) On 24 Feb 2001, Paul Jarc wrote: > Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes: >> >> There are topics, you know. > > I know; I was talking about the hypothetical future where > gnus-parameters is the One True (only?) way to set group parameters. Andras never wanted to _replace_ the existing group/topic parameter mechanism: /----[ from Andras' original post ] | Extending the find-parameter implementation to treat not only | group/topic parameters found in newsrc, but also those found in a | newly introduced regexp->param-list alist, would have the following | advantages: \---- At least that's the way I read his `not only... but also'. kai -- Be indiscrete. Do it continuously. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: regexp-based group parameters 2001-02-23 16:41 ` regexp-based group parameters NAGY Andras 2001-02-23 18:57 ` Toby Speight 2001-02-23 20:54 ` Paul Jarc @ 2001-02-23 22:35 ` ShengHuo ZHU 2001-02-25 1:55 ` NAGY Andras 2 siblings, 1 reply; 26+ messages in thread From: ShengHuo ZHU @ 2001-02-23 22:35 UTC (permalink / raw) NAGY Andras <nagya@inf.elte.hu> writes: [...] > To demonstrate this: I cannot (but would like to) write the following > in my .gnus: > > (setq gnus-parameters > '(("mail\..*" (gnus-show-threads . nil) > (gnus-use-scoring . nil) > (gnus-summary-line-format . > "%U%R%z%I%(%[%d:%ub%-20,20f%]%) %s\n") > (gcc-self . t) > (dispaly . all)) > > ("list\..*" (total-expire . t) > (broken-reply-to . t)))) > > > I think the example speaks for itself. (Setting everything in one > place, independetly of newsrc.eld and topic topology.) > > Anyone willing to implement this? Introducing the new variable (named > gnus-parameters above) and modifying gnus-group-find-parameter would > do the trick, I believe. OK. It is in oGnus. Please notice that there is no "." in group variables. ShengHuo ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: regexp-based group parameters 2001-02-23 22:35 ` ShengHuo ZHU @ 2001-02-25 1:55 ` NAGY Andras 2001-02-25 15:07 ` ShengHuo ZHU 0 siblings, 1 reply; 26+ messages in thread From: NAGY Andras @ 2001-02-25 1:55 UTC (permalink / raw) ShengHuo ZHU <zsh@cs.rochester.edu> writes: > > To demonstrate this: I cannot (but would like to) write the following > > in my .gnus: > > > > (setq gnus-parameters [...] > > (dispaly . all)) [...] > OK. It is in oGnus. Thanks a lot, this is really useful. Please correct the typo at gnus.el:860. A note about the variable name. I picked this almost randomly, for demonstration purposes, without thinking about whether it conforms with the Gnus Naming Scheme. (Is there such a thing?) Other possibilities include: gnus-group-parameters and gnus-group-parameters-alist, indicating this has something to do with groups, and the value type, respectively. Andras ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: regexp-based group parameters 2001-02-25 1:55 ` NAGY Andras @ 2001-02-25 15:07 ` ShengHuo ZHU 0 siblings, 0 replies; 26+ messages in thread From: ShengHuo ZHU @ 2001-02-25 15:07 UTC (permalink / raw) NAGY Andras <nagya@inf.elte.hu> writes: > Please correct the typo at gnus.el:860. Thanks. Fixed. > A note about the variable name. I picked this almost randomly, for > demonstration purposes, without thinking about whether it conforms > with the Gnus Naming Scheme. (Is there such a thing?) I guess there is an implicit one. > Other possibilities include: gnus-group-parameters and > gnus-group-parameters-alist, indicating this has something to do > with groups, and the value type, respectively. The name is OK. It is in gnus.el. ShengHuo ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Feature request: strip banners from all groups matching a regexp 2000-12-22 16:54 Feature request: strip banners from all groups matching a regexp Christopher Splinter 2000-12-22 18:19 ` Jeff Senn 2000-12-22 18:27 ` Charles Sebold @ 2000-12-23 2:08 ` ShengHuo ZHU 2 siblings, 0 replies; 26+ messages in thread From: ShengHuo ZHU @ 2000-12-23 2:08 UTC (permalink / raw) Christopher Splinter <chris@splinter.inka.de> writes: > Hi, > > IWBNI there were some functionality which would allow the user to > strip banners from messages in groups which match a certain regexp > using something like > > (setq gnus-strip-banners-from-groups > '(("nnml:lists\\.debian\\..*" . signature))) Implemented. A variable called gnus-parameter-banner-alist. ShengHuo ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2001-02-25 15:07 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-12-22 16:54 Feature request: strip banners from all groups matching a regexp Christopher Splinter 2000-12-22 18:19 ` Jeff Senn 2000-12-22 20:41 ` Christopher Splinter 2000-12-22 18:27 ` Charles Sebold 2000-12-22 20:21 ` Christopher Splinter 2000-12-23 12:38 ` Kai Großjohann 2000-12-23 12:59 ` NAGY Andras 2000-12-23 13:11 ` Kai Großjohann 2001-02-23 16:41 ` regexp-based group parameters NAGY Andras 2001-02-23 18:57 ` Toby Speight 2001-02-23 20:54 ` Paul Jarc 2001-02-23 21:35 ` Kai Großjohann 2001-02-23 21:57 ` Paul Jarc 2001-02-23 22:29 ` Kai Großjohann 2001-02-24 15:49 ` Randal L. Schwartz 2001-02-23 22:38 ` ShengHuo ZHU 2001-02-23 22:55 ` Paul Jarc 2001-02-23 23:22 ` ShengHuo ZHU 2001-02-23 23:56 ` Paul Jarc 2001-02-24 12:04 ` Kai Großjohann 2001-02-24 17:34 ` Paul Jarc 2001-02-24 21:45 ` Kai Großjohann 2001-02-23 22:35 ` ShengHuo ZHU 2001-02-25 1:55 ` NAGY Andras 2001-02-25 15:07 ` ShengHuo ZHU 2000-12-23 2:08 ` Feature request: strip banners from all groups matching a regexp ShengHuo ZHU
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).