* expand style `suffix' option
@ 2001-10-02 11:41 Peter Stephenson
2001-10-02 14:52 ` Bart Schaefer
2001-10-04 13:10 ` Sven Wischnowsky
0 siblings, 2 replies; 9+ messages in thread
From: Peter Stephenson @ 2001-10-02 11:41 UTC (permalink / raw)
To: Zsh hackers list
I've been meaning to try to get this to work for some time. Have I
misunderstood?
expand
This style is used when completing strings consisting
of multiple parts, such as path names. If its value
contains the string `prefix', the partially typed word
from the line will be expanded as far as possible even
if trailing parts cannot be completed. If it contains
the string `suffix' and normal (non-menu-) completion
is used, matching names for components after the first
ambiguous one will also be added. This means that the
resulting string is the longest unambiguous string pos-
sible, but if menu completion is started on the list of
matches generated this way (e.g. due to the option
AUTO_MENU being set), this will also cycle through the
names of the files in pathname components after the
first ambiguous one.
First off, I assumed I could do
zstyle ':completion:*' expand 'prefix suffix'
but a look at the code reveals this has to be
zstyle ':completion:*' expand prefix suffix
so `contains the string' could be made a little clearer.
When it does seem to be on, I would expect
~/b/b<TAB>
to list or cycle through all files ~/b*/b* when menu completion is in use,
but it doesn't. Is this assumption wrong? The manual entry doesn't
actually say what happens when you have menu completion on from the start,
as opposed to started automatically, but I turned it off and still only get
the first subdirectory completed when automenu is activated. If this isn't
what it does, what does it do? Or does it conflict with some other style
or option? But I get the same behaviour with zsh -f.
I was looking at adding the `expand' style to compinstall, but I'd like to
find out what it does first.
--
Peter Stephenson <pws@csr.com> Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK Tel: +44 (0)1223 392070
**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential
and/or privileged material.
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by
persons or entities other than the intended recipient is
prohibited.
If you received this in error, please contact the sender and
delete the material from any computer.
**********************************************************************
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: expand style `suffix' option
2001-10-02 11:41 expand style `suffix' option Peter Stephenson
@ 2001-10-02 14:52 ` Bart Schaefer
2001-10-04 13:10 ` Sven Wischnowsky
1 sibling, 0 replies; 9+ messages in thread
From: Bart Schaefer @ 2001-10-02 14:52 UTC (permalink / raw)
To: Zsh hackers list
On Oct 2, 12:41pm, Peter Stephenson wrote:
}
} zstyle ':completion:*' expand prefix suffix
}
} When it does seem to be on, I would expect
} ~/b/b<TAB>
} to list or cycle through all files ~/b*/b* when menu completion is in use,
} but it doesn't. Is this assumption wrong?
I get the exact same behavior out of that no matter what `expand' is set
to. E.g. I happen to have two files
~/netmanage/record
~/newmail/record
but no matter what the setting of the expand style, I always get:
schaefer<512> ls ~/n/r<TAB>
schaefer<512> ls ~/ne/r
(with cursor on the second `/'). Using menucomplete instead of automenu,
I get the menu:
schaefer<514> ls ~/n/r<TAB>
schaefer<515> ls ~/netmanage/r
Completing files
netmanage/ newmail/
but once again the `expand' style has no effect on this.
It looks like _path_files applies the `expand prefix' style only if the
number of matches generated is the same as the number that existed at
the time _path_files was called (line 655, nm -eq compstate[nmatches]).
But that never seems to be true.
Also, _path_files only checks that `expand suffix' is NOT set, and then
as part of a larger test to decide whether to clear compstate[to_end]
(lines 508-515), and I can't figure out what circumstances cause all the
other ||'d conditions to be false so that `expand suffix' will matter.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: expand style `suffix' option
2001-10-02 11:41 expand style `suffix' option Peter Stephenson
2001-10-02 14:52 ` Bart Schaefer
@ 2001-10-04 13:10 ` Sven Wischnowsky
2001-10-04 13:33 ` Peter Stephenson
1 sibling, 1 reply; 9+ messages in thread
From: Sven Wischnowsky @ 2001-10-04 13:10 UTC (permalink / raw)
To: zsh-workers
Peter Stephenson wrote:
> ...
>
> First off, I assumed I could do
> zstyle ':completion:*' expand 'prefix suffix'
> but a look at the code reveals this has to be
> zstyle ':completion:*' expand prefix suffix
> so `contains the string' could be made a little clearer.
Yes.
> When it does seem to be on, I would expect
> ~/b/b<TAB>
> to list or cycle through all files ~/b*/b* when menu completion is in use,
> but it doesn't.
Well, it says (or tries to say) that this suff-behaviour is only done
when not using menu-completion. I think we either had a discussion or
I thought that people using menu-completion wouldn't want to be
bothered with looong lists.
But anyway, that style appears to be broken (both prefix and
suffix). I seem to have a fix for the suffix thing now (it was broken
when list-suffixes was added, I think) and I know what's the problem
for the prefix part (compfiles building the pattern, so that
_path_files doesn't have the original anymore and doesn't add it to
$exppaths). I'll look into this tomorrow or next week.
Restoring those things would still not make it work with menu
completion, though (the suffix thing), but that could be added. Should
we?
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: expand style `suffix' option
2001-10-04 13:10 ` Sven Wischnowsky
@ 2001-10-04 13:33 ` Peter Stephenson
2001-10-05 11:17 ` Sven Wischnowsky
0 siblings, 1 reply; 9+ messages in thread
From: Peter Stephenson @ 2001-10-04 13:33 UTC (permalink / raw)
To: zsh-workers
Sven Wischnowsky wrote:
> > When it does seem to be on, I would expect
> > ~/b/b<TAB>
> > to list or cycle through all files ~/b*/b* when menu completion is in use,
> > but it doesn't.
>
> Well, it says (or tries to say) that this suff-behaviour is only done
> when not using menu-completion. I think we either had a discussion or
> I thought that people using menu-completion wouldn't want to be
> bothered with looong lists.
>...
> Restoring those things would still not make it work with menu
> completion, though (the suffix thing), but that could be added. Should
> we?
OK, I suppose the manual is saying it works if menu completion is started
afterwards, but not if it's already in effect.
Since the `suffix' behaviour is selectable completely separately from
anything else, I can't think of a good reason why the setting shouldn't
simply be respected. If you don't want it with menu completion you can
simply not turn it on.
Tying settings together is really another problem entirely. If we want
some more general way of grouping --- set a whole load of styles all
together - we can probably write a function suite that does it, e.g.
% zselect -v my_menu_styles
Turning on option `menuselect'
Changing style `expand' from `prefix suffix' to `prefix'
However, it's not that trivial when you take contexts into account
(compinstall has basically side-stepped this issue and while it handles
contexts, you have to select them by hand).
--
Peter Stephenson <pws@csr.com> Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK Tel: +44 (0)1223 392070
**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential
and/or privileged material.
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by
persons or entities other than the intended recipient is
prohibited.
If you received this in error, please contact the sender and
delete the material from any computer.
**********************************************************************
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: expand style `suffix' option
2001-10-04 13:33 ` Peter Stephenson
@ 2001-10-05 11:17 ` Sven Wischnowsky
2001-10-05 16:10 ` PATCH: " Peter Stephenson
0 siblings, 1 reply; 9+ messages in thread
From: Sven Wischnowsky @ 2001-10-05 11:17 UTC (permalink / raw)
To: zsh-workers
Peter Stephenson wrote:
> ...
>
> OK, I suppose the manual is saying it works if menu completion is started
> afterwards, but not if it's already in effect.
>
> Since the `suffix' behaviour is selectable completely separately from
> anything else, I can't think of a good reason why the setting shouldn't
> simply be respected. If you don't want it with menu completion you can
> simply not turn it on.
Right. The patch below tries to make this style work again and it
also removes the dependency on not using menu completion (that part of
the code is pretty hairy, so there might be things which now work
differently with menu-completion -- I'd like to hear about them so
that we can fix them).
> Tying settings together is really another problem entirely. If we want
> some more general way of grouping --- set a whole load of styles all
> together - we can probably write a function suite that does it, e.g.
> % zselect -v my_menu_styles
> Turning on option `menuselect'
> Changing style `expand' from `prefix suffix' to `prefix'
> However, it's not that trivial when you take contexts into account
> (compinstall has basically side-stepped this issue and while it handles
> contexts, you have to select them by hand).
Yes, I've been thinking about things like this, too, and haven't come
to a conclusion either.
The patch also tries to make the docs clearer on how the style has to
be set, because I haven't changed the code to look for sub-strings.
Bye
Sven
Index: Completion/Unix/Type/_path_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_path_files,v
retrieving revision 1.11
diff -u -r1.11 _path_files
--- Completion/Unix/Type/_path_files 2001/08/17 09:25:22 1.11
+++ Completion/Unix/Type/_path_files 2001/10/05 11:11:15
@@ -332,6 +332,8 @@
# Get the matching files by globbing.
+ tmp2=( "$tmp1[@]" )
+
if [[ "$tpre$tsuf" = */* ]]; then
compfiles -P$cfopt tmp1 accex "$skipped" "$_matcher" "$sdirs" fake
elif [[ "$sopt" = *[/f]* ]]; then
@@ -344,7 +346,9 @@
if [[ -n "$PREFIX$SUFFIX" ]]; then
# See which of them match what's on the line.
- if [[ "$tmp1[1]" = */* ]]; then
+ if (( ! $#tmp1 )); then
+ tmp2=( ${^tmp2}/$PREFIX$SUFFIX )
+ elif [[ "$tmp1[1]" = */* ]]; then
if [[ -n "$_comp_correct" ]]; then
tmp2=( "$tmp1[@]" )
builtin compadd -D tmp1 -F _comp_ignore "$matcher[@]" - "${(@)tmp1:t}"
@@ -504,13 +508,16 @@
PREFIX="$opre"
SUFFIX="$osuf"
fi
+
+ # This once tested `-n $menu ||' but our menu-completion expert says
+ # that's not what we want.
- if [[ -n $menu || -z "$compstate[insert]" ]] ||
- ! zstyle -t ":completion:${curcontext}:paths" expand suffix ||
+ if [[ -z "$compstate[insert]" ]] ||
+ { ! zstyle -t ":completion:${curcontext}:paths" expand suffix &&
[[ -z "$listsfx" &&
( -n "$_comp_correct" ||
-z "$compstate[pattern_match]" || "$SUFFIX" != */* ||
- "${SUFFIX#*/}" = (|*[^\\])[][*?#~^\|\<\>]* ) ]]; then
+ "${SUFFIX#*/}" = (|*[^\\])[][*?#~^\|\<\>]* ) ]] }; then
(( tmp4 )) && zstyle -t ":completion:${curcontext}:paths" ambiguous &&
compstate[to_end]=
if [[ "$tmp3" = */* ]]; then
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.134
diff -u -r1.134 compsys.yo
--- Doc/Zsh/compsys.yo 2001/08/15 13:50:03 1.134
+++ Doc/Zsh/compsys.yo 2001/10/05 11:11:16
@@ -1070,15 +1070,15 @@
kindex(expand, completion style)
item(tt(expand))(
This style is used when completing strings consisting of multiple
-parts, such as path names. If its
-value contains the string `tt(prefix)', the partially typed word from
+parts, such as path names. If one of its values is
+the string `tt(prefix)', the partially typed word from
the line will be expanded as far as possible even if trailing parts
-cannot be completed. If it contains the string `tt(suffix)'
-and normal (non-menu-) completion is used, matching names for
+cannot be completed. If one of its values is the string `tt(suffix)',
+matching names for
components after the first ambiguous one will also be added. This
means that the resulting string is the longest unambiguous string
possible, but if menu completion is started on the list of matches
-generated this way (e.g. due to the option tt(AUTO_MENU) being set),
+generated this way,
this will also cycle through the names of the files in pathname
components after the first ambiguous one.
)
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 9+ messages in thread
* PATCH: Re: expand style `suffix' option
2001-10-05 11:17 ` Sven Wischnowsky
@ 2001-10-05 16:10 ` Peter Stephenson
2001-10-08 12:33 ` Sven Wischnowsky
2001-10-09 9:48 ` Sven Wischnowsky
0 siblings, 2 replies; 9+ messages in thread
From: Peter Stephenson @ 2001-10-05 16:10 UTC (permalink / raw)
To: Zsh hackers list
Sven Wischnowsky wrote:
> Right. The patch below tries to make this style work again and it
> also removes the dependency on not using menu completion (that part of
> the code is pretty hairy, so there might be things which now work
> differently with menu-completion -- I'd like to hear about them so
> that we can fix them).
Working fine so far.
The only glitch I've come across is that you only get the top level
directory in the list even you are completing to multiple levels,
e.g. ~/b/b<TAB> shows up a whole load of `bin/'s in the listing. One can,
of course, argue that this is perfectly reasonable: menu completion will
show the full set. One could wish for an extra directory level to be shown
to resolve conflicts, but then one could wish for free chocolate.
Here's the compinstall stuff for the expand style.
There's a glaring hole in the `styles for particular completions' in the
top menu. The only entry is for file completions. I was hoping for people
to add configuration for their own favourite types of completion. I
haven't thought of anything that useful.
Index: Completion/compinstall
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/compinstall,v
retrieving revision 1.4
diff -u -r1.4 compinstall
--- Completion/compinstall 2001/06/13 09:26:15 1.4
+++ Completion/compinstall 2001/10/05 15:57:42
@@ -1529,11 +1529,13 @@
# squeeze-slashes,
__ci_do_file_styles() {
local key files cursor expand speciald ignorep squeezes select
+ local prefon suffon
__ci_get_this_style file-sort files
__ci_get_this_style ignore-parents ignorep
__ci_get_this_style special-dirs speciald
__ci_get_this_style squeeze-slashes squeezes
+ __ci_get_this_style expand expand
while true; do
clear
@@ -1548,6 +1550,8 @@
4. When expanding paths, \`foo//bar' is treated as \`foo/bar'.
+5. Configure how multiple paths are expanded, e.g. /f/b -> /foo/bar
+
q. Return without saving.
0. Done setting options for filename completion.
"
@@ -1655,6 +1659,52 @@
([nN]) squeezes=;;
esac
;;
+ (5) if [[ $expand = *prefix* ]]; then
+ prefon=prefix
+ else
+ prefon=
+ fi
+ if [[ $expand = *suffix* ]]; then
+ suffon=suffix
+ else
+ suffon=
+ fi
+ print "
+When expanding /f/b, the shell will attempt to match /f*/b* (e.g. /foo/bar),
+and so on to any depth. If the first part of the expansion fails, by default
+the shell will not expand the remainder. However, you can force it always
+to expand the first part. Currently this feature is ${${prefon:+on}:-off}.
+Do you want it on ([y]es, [n]o, [k]eep current setting)?
+"
+ while true; do
+ read -k key'?--- Hit selection --- '
+ [[ $key = [yYnNkK] ]] && break
+ print "Type one of y, n or k."
+ done
+ case $key in
+ ([yY]) prefon=prefix;;
+ ([nN]) prefon=prefix;;
+ esac
+ print "
+Further, if /f*/b* is ambiguous, the shell will usually only expand
+as far as the part that is unambiguous; for example, if /foo/bar and
+/food/basket exist, it will wait for you to choose either /foo or /food,
+and not attempt to expand the rest of the match. However, you can force
+it to add all possible completions for you to resolve conflicts in the
+normal way. Currently this feature is ${${suffon:+on}:-off}.
+Do you want it on ([y]es, [n]o, [k]eep current settign)?
+"
+ while true; do
+ read -k key'?--- Hit selection --- '
+ [[ $key = [yYnNkK] ]] && break
+ print "Type one of y, n or k."
+ done
+ case $key in
+ ([yY]) suffon=suffix;;
+ ([nN]) suffon=suffix;;
+ esac
+ expand=${prefon:+$prefon${suffon:+ }}${suffon}
+ ;;
(q) return 1
;;
esac
@@ -1665,6 +1715,7 @@
__ci_set_this_style ignore-parents ignorep
__ci_set_this_style special-dirs speciald
__ci_set_this_style squeeze-slashes squeezes
+ __ci_set_this_style expand expand
return 0
}
--
Peter Stephenson <pws@csr.com> Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK Tel: +44 (0)1223 392070
**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential
and/or privileged material.
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by
persons or entities other than the intended recipient is
prohibited.
If you received this in error, please contact the sender and
delete the material from any computer.
**********************************************************************
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PATCH: Re: expand style `suffix' option
2001-10-05 16:10 ` PATCH: " Peter Stephenson
@ 2001-10-08 12:33 ` Sven Wischnowsky
2001-10-09 9:48 ` Sven Wischnowsky
1 sibling, 0 replies; 9+ messages in thread
From: Sven Wischnowsky @ 2001-10-08 12:33 UTC (permalink / raw)
To: zsh-workers
Peter Stephenson wrote:
> ...
>
> The only glitch I've come across is that you only get the top level
> directory in the list even you are completing to multiple levels,
> e.g. ~/b/b<TAB> shows up a whole load of `bin/'s in the listing. One can,
> of course, argue that this is perfectly reasonable: menu completion will
> show the full set. One could wish for an extra directory level to be shown
> to resolve conflicts, but then one could wish for free chocolate.
Ah, with the file-sort style set, right? I'll have a look when I find
the time.
> There's a glaring hole in the `styles for particular completions' in the
> top menu. The only entry is for file completions. I was hoping for people
> to add configuration for their own favourite types of completion. I
> haven't thought of anything that useful.
Uh, oh. (Most of the time, I just forget to remember compinstall. So
to say.)
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PATCH: Re: expand style `suffix' option
2001-10-05 16:10 ` PATCH: " Peter Stephenson
2001-10-08 12:33 ` Sven Wischnowsky
@ 2001-10-09 9:48 ` Sven Wischnowsky
2001-10-09 10:35 ` Peter Stephenson
1 sibling, 1 reply; 9+ messages in thread
From: Sven Wischnowsky @ 2001-10-09 9:48 UTC (permalink / raw)
To: zsh-workers
Peter Stephenson wrote:
> ...
>
> The only glitch I've come across is that you only get the top level
> directory in the list even you are completing to multiple levels,
> e.g. ~/b/b<TAB> shows up a whole load of `bin/'s in the listing. One can,
> of course, argue that this is perfectly reasonable: menu completion will
> show the full set.
That bug was in a different place than I first suspected. With
unsorted groups (and neither -1 nor -2) duplicate matches were removed
but it didn't make sure to hide matches showing the same string in the
list. I'm pretty sure this wasn't done on purpose.
> One could wish for an extra directory level to be shown
> to resolve conflicts, but then one could wish for free chocolate.
No change here, one can always set the list-sufffixes style to get
that behaviour (although it would probably be sensible to do that
automatically with menu-completion).
Bye
Sven
Index: Src/Zle/compcore.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compcore.c,v
retrieving revision 1.50
diff -u -r1.50 compcore.c
--- Src/Zle/compcore.c 2001/08/20 13:13:50 1.50
+++ Src/Zle/compcore.c 2001/10/09 09:43:15
@@ -2654,6 +2654,8 @@
}
} else {
if (!(flags & CGF_UNIQALL) && !(flags & CGF_UNIQCON)) {
+ int dup;
+
for (ap = rp; *ap; ap++) {
for (bp = cp = ap + 1; *bp; bp++) {
if (!matcheq(*ap, *bp))
@@ -2662,6 +2664,17 @@
n--;
}
*cp = NULL;
+ if (!(*ap)->disp) {
+ for (dup = 0, bp = ap + 1; *bp; bp++)
+ if (!(*bp)->disp &&
+ !((*bp)->flags & CMF_MULT) &&
+ !strcmp((*ap)->str, (*bp)->str)) {
+ (*bp)->flags |= CMF_MULT;
+ dup = 1;
+ }
+ if (dup)
+ (*ap)->flags |= CMF_FMULT;
+ }
}
} else if (!(flags & CGF_UNIQCON)) {
int dup;
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PATCH: Re: expand style `suffix' option
2001-10-09 9:48 ` Sven Wischnowsky
@ 2001-10-09 10:35 ` Peter Stephenson
0 siblings, 0 replies; 9+ messages in thread
From: Peter Stephenson @ 2001-10-09 10:35 UTC (permalink / raw)
To: Zsh hackers list
Sven Wischnowsky wrote:
> > The only glitch I've come across is that you only get the top level
> > directory in the list even you are completing to multiple levels,
> > e.g. ~/b/b<TAB> shows up a whole load of `bin/'s in the listing. One can,
> > of course, argue that this is perfectly reasonable: menu completion will
> > show the full set.
>
> That bug was in a different place than I first suspected. With
> unsorted groups (and neither -1 nor -2) duplicate matches were removed
> but it didn't make sure to hide matches showing the same string in the
> list. I'm pretty sure this wasn't done on purpose.
I'm still getting the behaviour, but I don't believe it's really a bug:
with menu completion and menu selection, you need different entries in the
displayed menu to cycle through.
> > One could wish for an extra directory level to be shown
> > to resolve conflicts, but then one could wish for free chocolate.
>
> No change here, one can always set the list-sufffixes style to get
> that behaviour (although it would probably be sensible to do that
> automatically with menu-completion).
Yes, this does what I want.
--
Peter Stephenson <pws@csr.com> Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK Tel: +44 (0)1223 392070
**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential
and/or privileged material.
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by
persons or entities other than the intended recipient is
prohibited.
If you received this in error, please contact the sender and
delete the material from any computer.
**********************************************************************
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2001-10-09 10:36 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-10-02 11:41 expand style `suffix' option Peter Stephenson
2001-10-02 14:52 ` Bart Schaefer
2001-10-04 13:10 ` Sven Wischnowsky
2001-10-04 13:33 ` Peter Stephenson
2001-10-05 11:17 ` Sven Wischnowsky
2001-10-05 16:10 ` PATCH: " Peter Stephenson
2001-10-08 12:33 ` Sven Wischnowsky
2001-10-09 9:48 ` Sven Wischnowsky
2001-10-09 10:35 ` Peter Stephenson
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
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).