* Shift-Insert overwrites ZLE CUTBUFFER @ 2016-10-25 12:46 lolilolicon 2016-10-25 16:12 ` Bart Schaefer 0 siblings, 1 reply; 16+ messages in thread From: lolilolicon @ 2016-10-25 12:46 UTC (permalink / raw) To: zsh-users I use Shift-Insert to paste the X PRIMARY selection in terminal. But when I use Shift-Insert, the ZLE CUTBUFFER is also overwritten. Is there a way to disable this? Example, with cursor at the end of line, % foo ^W kills "foo" ^Y yanks "foo", as expected % foo Shift-Insert pastes "bar", content of PRIMARY selection % foobar ^Y yanks "bar", instead of "foo", unexpected! % foobarbar ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Shift-Insert overwrites ZLE CUTBUFFER 2016-10-25 12:46 Shift-Insert overwrites ZLE CUTBUFFER lolilolicon @ 2016-10-25 16:12 ` Bart Schaefer 2016-10-25 16:28 ` lolilolicon 0 siblings, 1 reply; 16+ messages in thread From: Bart Schaefer @ 2016-10-25 16:12 UTC (permalink / raw) To: zsh-users On Oct 25, 8:46pm, lolilolicon wrote: } } I use Shift-Insert to paste the X PRIMARY selection in terminal. } But when I use Shift-Insert, the ZLE CUTBUFFER is also overwritten. } Is there a way to disable this? This is a side-effect of the "bracketed paste mode" feature that was added about a year ago. The previous contents of the cutbuffer are pushed onto the kill ring, so you can retrieve it by following <^Y> with <\M-y> (or <ESC y>). There's currently no easy way to change the cutbuffer behavior without disabling the rest of the bracketed-paste behavior. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Shift-Insert overwrites ZLE CUTBUFFER 2016-10-25 16:12 ` Bart Schaefer @ 2016-10-25 16:28 ` lolilolicon 2016-10-26 16:01 ` Bart Schaefer 0 siblings, 1 reply; 16+ messages in thread From: lolilolicon @ 2016-10-25 16:28 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-users On Wed, Oct 26, 2016 at 12:12 AM, Bart Schaefer <schaefer@brasslantern.com> wrote: > On Oct 25, 8:46pm, lolilolicon wrote: > } > } I use Shift-Insert to paste the X PRIMARY selection in terminal. > } But when I use Shift-Insert, the ZLE CUTBUFFER is also overwritten. > } Is there a way to disable this? > > This is a side-effect of the "bracketed paste mode" feature that was > added about a year ago. Oh yes bracketed-paste, that is a good feature. > > The previous contents of the cutbuffer are pushed onto the kill ring, > so you can retrieve it by following <^Y> with <\M-y> (or <ESC y>). Thank you for the tip! > > There's currently no easy way to change the cutbuffer behavior without > disabling the rest of the bracketed-paste behavior. That's a shame. Is it technically difficult to do? Would there be an issue if zsh just popped the killring automatically? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Shift-Insert overwrites ZLE CUTBUFFER 2016-10-25 16:28 ` lolilolicon @ 2016-10-26 16:01 ` Bart Schaefer 2016-10-26 16:12 ` lolilolicon 2016-10-26 22:05 ` Mikael Magnusson 0 siblings, 2 replies; 16+ messages in thread From: Bart Schaefer @ 2016-10-26 16:01 UTC (permalink / raw) To: zsh-users On Oct 26, 12:28am, lolilolicon wrote: } Subject: Re: Shift-Insert overwrites ZLE CUTBUFFER } } On Wed, Oct 26, 2016 at 12:12 AM, Bart Schaefer } <schaefer@brasslantern.com> wrote: } > There's currently no easy way to change the cutbuffer behavior without } > disabling the rest of the bracketed-paste behavior. } } That's a shame. } Is it technically difficult to do? Would there be an issue if zsh just } popped the killring automatically? What I mean is that it's not easy to do from shell code. In the source code obviously the implementation is deliberately pushing the kill ring, so it wouldn't be technically difficult to *not* do so, but that would mean reversing an earlier design decision. Something like this sort of works: my-bracketed-paste { zle .bracketed-paste "$@" && { local pasted=$CUTBUFFER # Swap the top two killed items to fake out ^Y CUTBUFFER=$killring[1] killring[1]=$pasted } } zle -N bracketed-paste my-bracketed-paste But I wouldn't have called that an "easy way". Various other approaches involving saving/restoring CUTBUFFER and killring are also possible. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Shift-Insert overwrites ZLE CUTBUFFER 2016-10-26 16:01 ` Bart Schaefer @ 2016-10-26 16:12 ` lolilolicon 2016-10-26 23:51 ` Bart Schaefer [not found] ` <161026165138.ZM12130__24043.0697137073$1477525984$gmane$org@torch.brasslantern.com> 2016-10-26 22:05 ` Mikael Magnusson 1 sibling, 2 replies; 16+ messages in thread From: lolilolicon @ 2016-10-26 16:12 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-users On Thu, Oct 27, 2016 at 12:01 AM, Bart Schaefer <schaefer@brasslantern.com> wrote: > What I mean is that it's not easy to do from shell code. In the source > code obviously the implementation is deliberately pushing the kill ring, > so it wouldn't be technically difficult to *not* do so, but that would > mean reversing an earlier design decision. I assumed the kill ring was used for implementation convenience. If this was a deliberate design decision, I don't understand how this is desirable to the user. This doesn't seem to be documented, so I think it's OK to change it. > > Something like this sort of works: > > my-bracketed-paste { > zle .bracketed-paste "$@" && { > local pasted=$CUTBUFFER > # Swap the top two killed items to fake out ^Y > CUTBUFFER=$killring[1] > killring[1]=$pasted > } > } > zle -N bracketed-paste my-bracketed-paste > > But I wouldn't have called that an "easy way". Nice, thanks for showing me! > > Various other approaches involving saving/restoring CUTBUFFER and killring > are also possible. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Shift-Insert overwrites ZLE CUTBUFFER 2016-10-26 16:12 ` lolilolicon @ 2016-10-26 23:51 ` Bart Schaefer 2016-10-27 19:56 ` Greg Klanderman [not found] ` <161026165138.ZM12130__24043.0697137073$1477525984$gmane$org@torch.brasslantern.com> 1 sibling, 1 reply; 16+ messages in thread From: Bart Schaefer @ 2016-10-26 23:51 UTC (permalink / raw) To: zsh-users On Oct 27, 12:12am, lolilolicon wrote: } } I assumed the kill ring was used for implementation convenience. } If this was a deliberate design decision, I don't understand how this } is desirable to the user. It's common behavior of GUI / windowing editors, i.e., if you cut/paste text into GNU Emacs the text is placed in the cut buffer. (In fact in emacs' GUI it's in the cut buffer as soon as you cut from the source, so you can immediately yank it, but that can't happen with an app in a text terminal.) } This doesn't seem to be documented, so I think it's OK to change it. Good point that it should be documented. It's mentioned under the YANK_* variables in "man zle" but not explicitly spelled out under the description of the widget. -- Barton E. Schaefer ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Shift-Insert overwrites ZLE CUTBUFFER 2016-10-26 23:51 ` Bart Schaefer @ 2016-10-27 19:56 ` Greg Klanderman 2016-10-27 20:35 ` Bart Schaefer 0 siblings, 1 reply; 16+ messages in thread From: Greg Klanderman @ 2016-10-27 19:56 UTC (permalink / raw) To: zsh-users >>>>> On October 26, 2016 Bart Schaefer <schaefer@brasslantern.com> wrote: > It's common behavior of GUI / windowing editors, i.e., if you cut/paste > text into GNU Emacs the text is placed in the cut buffer. Really??? Neither GNU emacs nor xemacs behave that way by default for me. I have just tested GNU Emacs 24.4.1 and xemacs 24.4.22, both with the "-q" option. I tend to agree with the OP; this really seems like a mis-feature. Greg ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Shift-Insert overwrites ZLE CUTBUFFER 2016-10-27 19:56 ` Greg Klanderman @ 2016-10-27 20:35 ` Bart Schaefer 2016-10-31 15:56 ` Oliver Kiddle [not found] ` <43312.1477929414__19178.7032563754$1477929872$gmane$org@hydra.kiddle.eu> 0 siblings, 2 replies; 16+ messages in thread From: Bart Schaefer @ 2016-10-27 20:35 UTC (permalink / raw) To: zsh-users On Oct 27, 3:56pm, Greg Klanderman wrote: } Subject: Re: Shift-Insert overwrites ZLE CUTBUFFER } } >>>>> On October 26, 2016 Bart Schaefer <schaefer@brasslantern.com> wrote: } } > It's common behavior of GUI / windowing editors, i.e., if you cut/paste } > text into GNU Emacs the text is placed in the cut buffer. } } Really??? Certainly seems to work that way for me (emacs on Ubuntu / GNOME). *Not* when running emacs inside a terminal, however. } I tend to agree with the OP; this really seems like a mis-feature. I'm not particularly invested in this, because most of the time I think bracketed-paste itself is a misfeature (or at least having it active by default is). However, I didn't implement the feature, so I'm not going to un-implement it without hearing from Oliver (who did), because obviously he had another opinion. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Shift-Insert overwrites ZLE CUTBUFFER 2016-10-27 20:35 ` Bart Schaefer @ 2016-10-31 15:56 ` Oliver Kiddle 2016-10-31 16:16 ` Peter Stephenson [not found] ` <43312.1477929414__19178.7032563754$1477929872$gmane$org@hydra.kiddle.eu> 1 sibling, 1 reply; 16+ messages in thread From: Oliver Kiddle @ 2016-10-31 15:56 UTC (permalink / raw) To: zsh-users On 27 Oct, Bart wrote: > Certainly seems to work that way for me (emacs on Ubuntu / GNOME). > *Not* when running emacs inside a terminal, however. This particular feature was added in workers/35824 along with a specific request for actual Emacs users to check that it makes sense. In a wider GUI sense, there is normally a single shared clipboard though copying rather than pasting will update it. Reverting it would be a matter of changing the cuttext call back to doinsert. However, having the pasted text available in some form is useful. Does anyone have an alternative suggestion? Associating it with the existing cut/paste features at least puts it in a logical and memorable place, at least once you're aware of the feature. And if you know about things like yank-pop or vi "0 then it is not so likely to be bothersome. But I'd be open to something better. If Daniel's documentation from 22036 is applied, it should probably also mention that in vi mode, it allows a register to be specified to capture a paste. In that case, the text isn't inserted. Oliver ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Shift-Insert overwrites ZLE CUTBUFFER 2016-10-31 15:56 ` Oliver Kiddle @ 2016-10-31 16:16 ` Peter Stephenson 0 siblings, 0 replies; 16+ messages in thread From: Peter Stephenson @ 2016-10-31 16:16 UTC (permalink / raw) To: zsh-users On Mon, 31 Oct 2016 16:56:54 +0100 Oliver Kiddle <okiddle@yahoo.co.uk> wrote: > Reverting it would be a matter of changing the cuttext call back > to doinsert. However, having the pasted text available in some form > is useful. Does anyone have an alternative suggestion? I'm not particularly bothered either way, but $ZLE_PASTED suggest itself. pws ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <43312.1477929414__19178.7032563754$1477929872$gmane$org@hydra.kiddle.eu>]
* Re: Shift-Insert overwrites ZLE CUTBUFFER [not found] ` <43312.1477929414__19178.7032563754$1477929872$gmane$org@hydra.kiddle.eu> @ 2016-11-01 17:03 ` Daniel Shahaf [not found] ` <20161101170328.GA24091__43513.8293811635$1478019914$gmane$org@fujitsu.shahaf.local2> 1 sibling, 0 replies; 16+ messages in thread From: Daniel Shahaf @ 2016-11-01 17:03 UTC (permalink / raw) To: zsh-users Oliver Kiddle wrote on Mon, Oct 31, 2016 at 16:56:54 +0100: > On 27 Oct, Bart wrote: > If Daniel's documentation from 22036 is applied, it should probably > also mention that in vi mode, it allows a register to be specified > to capture a paste. In that case, the text isn't inserted. It had already been applied. Here's a shot at the new text; feel free to just discard it and commit something else (that'd be easier than doing iterations on list). It uses the term "register" as in your email and in Vim, however, that term occurs only once in zshzle(1). Cheers, Daniel diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo index 64bfcc2..63f673b 100644 --- a/Doc/Zsh/zle.yo +++ b/Doc/Zsh/zle.yo @@ -2175,9 +2175,12 @@ item(tt(bracketed-paste))( This widget is invoked when text is pasted to the terminal emulator. It is not intended to be bound to actual keys but instead to the special sequence generated by the terminal emulator when text is pasted. -The pasted text is inserted to the buffer and placed in the cutbuffer. + +When invoked interactively, the pasted text is inserted to the buffer. If a numeric argument is given, shell quoting will be applied to the pasted text before it is inserted. +The text is also placed in the cutbuffer, or in the specified register +(tt("x) in vi mode). When called from a widget function as `tt(bracketed-paste) var(name)`, the pasted text is assigned to the variable var(name) and no other processing is ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <20161101170328.GA24091__43513.8293811635$1478019914$gmane$org@fujitsu.shahaf.local2>]
* Re: Shift-Insert overwrites ZLE CUTBUFFER [not found] ` <20161101170328.GA24091__43513.8293811635$1478019914$gmane$org@fujitsu.shahaf.local2> @ 2016-11-03 19:45 ` Daniel Shahaf 0 siblings, 0 replies; 16+ messages in thread From: Daniel Shahaf @ 2016-11-03 19:45 UTC (permalink / raw) To: zsh-users Daniel Shahaf wrote on Tue, Nov 01, 2016 at 17:03:28 +0000: > Oliver Kiddle wrote on Mon, Oct 31, 2016 at 16:56:54 +0100: > > On 27 Oct, Bart wrote: > > If Daniel's documentation from 22036 is applied, it should probably > > also mention that in vi mode, it allows a register to be specified > > to capture a paste. In that case, the text isn't inserted. > > It had already been applied. Here's a shot at the new text; A bug was pointed out off-list after I committed the new text. Here's another shot for review. The last hunk is in vi-set-buffer's docs. diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo index 63f673b..b7bb23b 100644 --- a/Doc/Zsh/zle.yo +++ b/Doc/Zsh/zle.yo @@ -2176,11 +2176,13 @@ This widget is invoked when text is pasted to the terminal emulator. It is not intended to be bound to actual keys but instead to the special sequence generated by the terminal emulator when text is pasted. -When invoked interactively, the pasted text is inserted to the buffer. +When invoked interactively, the pasted text is inserted to the buffer +and placed in the cutbuffer. If a numeric argument is given, shell quoting will be applied to the pasted text before it is inserted. -The text is also placed in the cutbuffer, or in the specified register -(tt("x) in vi mode). + +When a named buffer is specified with tt(vi-set-buffer) (tt("x)), +the pasted text is stored in that named buffer but not inserted. When called from a widget function as `tt(bracketed-paste) var(name)`, the pasted text is assigned to the variable var(name) and no other processing is @@ -2410,7 +2412,7 @@ concerned replaces the previous contents of the specified buffer. If a named buffer is specified using a capital, the newly cut text is appended to the buffer instead of overwriting it. When using the tt("_) buffer, nothing happens. This can be useful for deleting text without -affecting the normal registers. +affecting any buffers. If no buffer is specified for a cut or change command, tt("1) is used, and the contents of tt("1) to tt("8) are each shifted along one buffer; ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <161026165138.ZM12130__24043.0697137073$1477525984$gmane$org@torch.brasslantern.com>]
* Re: Shift-Insert overwrites ZLE CUTBUFFER [not found] ` <161026165138.ZM12130__24043.0697137073$1477525984$gmane$org@torch.brasslantern.com> @ 2016-10-27 0:45 ` Daniel Shahaf [not found] ` <20161027004500.GA12759__18780.7835791775$1477529337$gmane$org@fujitsu.shahaf.local2> 1 sibling, 0 replies; 16+ messages in thread From: Daniel Shahaf @ 2016-10-27 0:45 UTC (permalink / raw) To: zsh-users Bart Schaefer wrote on Wed, Oct 26, 2016 at 16:51:38 -0700: > On Oct 27, 12:12am, lolilolicon wrote: > } This doesn't seem to be documented, so I think it's OK to change it. > > Good point that it should be documented. > The following documents the incumbent killring behaviour, and rearranges text to clarify that a numeric argument is ignored when a positional argument is present. diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo index 726e973..3fb7f42 100644 --- a/Doc/Zsh/zle.yo +++ b/Doc/Zsh/zle.yo @@ -2176,10 +2176,12 @@ item(tt(bracketed-paste))( This widget is invoked when text is pasted to the terminal emulator. It is not intended to be bound to actual keys but instead to the special sequence generated by the terminal emulator when text is pasted. + +If called from a widget function and a positional argument is given, +it is interpreted as a variable name to which the pasted text is assigned. +Otherwise, the pasted text is inserted to the buffer and added to the kill ring. If a numeric argument is given, shell quoting will be applied to the -pasted text before it is inserted. When called from a widget function, -an argument can be given to specify a variable to which pasted text is -assigned. +pasted text before it is inserted. See also the tt(zle_bracketed_paste) parameter. ) ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <20161027004500.GA12759__18780.7835791775$1477529337$gmane$org@fujitsu.shahaf.local2>]
* Re: Shift-Insert overwrites ZLE CUTBUFFER [not found] ` <20161027004500.GA12759__18780.7835791775$1477529337$gmane$org@fujitsu.shahaf.local2> @ 2016-10-27 12:59 ` Daniel Shahaf 0 siblings, 0 replies; 16+ messages in thread From: Daniel Shahaf @ 2016-10-27 12:59 UTC (permalink / raw) To: zsh-users Daniel Shahaf wrote on Thu, Oct 27, 2016 at 00:45:00 +0000: > Bart Schaefer wrote on Wed, Oct 26, 2016 at 16:51:38 -0700: > > On Oct 27, 12:12am, lolilolicon wrote: > > } This doesn't seem to be documented, so I think it's OK to change it. > > > > Good point that it should be documented. > > > > The following documents the incumbent killring behaviour, and rearranges > text to clarify that a numeric argument is ignored when a positional > argument is present. Alternative patch after feedback by Bart. diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo index 726e973..e82c12d 100644 --- a/Doc/Zsh/zle.yo +++ b/Doc/Zsh/zle.yo @@ -2176,10 +2176,13 @@ item(tt(bracketed-paste))( This widget is invoked when text is pasted to the terminal emulator. It is not intended to be bound to actual keys but instead to the special sequence generated by the terminal emulator when text is pasted. +The pasted text is inserted to the buffer and placed in the cutbuffer. If a numeric argument is given, shell quoting will be applied to the -pasted text before it is inserted. When called from a widget function, -an argument can be given to specify a variable to which pasted text is -assigned. +pasted text before it is inserted. + +When called from a widget function as `tt(bracketed-paste) var(name)`, the +pasted text is assigned to the variable var(name) and no other processing is +done. See also the tt(zle_bracketed_paste) parameter. ) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Shift-Insert overwrites ZLE CUTBUFFER 2016-10-26 16:01 ` Bart Schaefer 2016-10-26 16:12 ` lolilolicon @ 2016-10-26 22:05 ` Mikael Magnusson 2016-10-26 23:59 ` Bart Schaefer 1 sibling, 1 reply; 16+ messages in thread From: Mikael Magnusson @ 2016-10-26 22:05 UTC (permalink / raw) To: Bart Schaefer, lolilolicon; +Cc: Zsh Users On Wed, Oct 26, 2016 at 6:01 PM, Bart Schaefer <schaefer@brasslantern.com> wrote: > On Oct 26, 12:28am, lolilolicon wrote: > } Subject: Re: Shift-Insert overwrites ZLE CUTBUFFER > } > } On Wed, Oct 26, 2016 at 12:12 AM, Bart Schaefer > } <schaefer@brasslantern.com> wrote: > } > There's currently no easy way to change the cutbuffer behavior without > } > disabling the rest of the bracketed-paste behavior. > } > } That's a shame. > } Is it technically difficult to do? Would there be an issue if zsh just > } popped the killring automatically? > > What I mean is that it's not easy to do from shell code. In the source > code obviously the implementation is deliberately pushing the kill ring, > so it wouldn't be technically difficult to *not* do so, but that would > mean reversing an earlier design decision. Actually if you pass a parameter name to the bracketed-paste widget, it stuffs the pasted content in there and does literally nothing else. So a simple wrapper widget that doesn't mess with the yank buffer could look like this: my-bracketed-paste () { local wantquote=${NUMERIC:-0} local content zle .$WIDGET -N content if (( $wantquote == 1 )); then content=${(q-)content} fi LBUFFER+=$content } Or if you don't care about quoting the input ever, just my-bracketed-paste () { local content zle .$WIDGET -N content LBUFFER+=$content } (see also the bracketed-paste-url-magic function distributed with zsh) -- Mikael Magnusson ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Shift-Insert overwrites ZLE CUTBUFFER 2016-10-26 22:05 ` Mikael Magnusson @ 2016-10-26 23:59 ` Bart Schaefer 0 siblings, 0 replies; 16+ messages in thread From: Bart Schaefer @ 2016-10-26 23:59 UTC (permalink / raw) To: Zsh Users On Oct 27, 12:05am, Mikael Magnusson wrote: } } Actually if you pass a parameter name to the bracketed-paste widget, } it stuffs the pasted content in there and does literally nothing else. Indeed, I forgot about that. Minimally: my-bracketed-paste () { zle .bracketed-paste 'LBUFFER[CURSOR+1]' } ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2016-11-03 19:45 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-10-25 12:46 Shift-Insert overwrites ZLE CUTBUFFER lolilolicon 2016-10-25 16:12 ` Bart Schaefer 2016-10-25 16:28 ` lolilolicon 2016-10-26 16:01 ` Bart Schaefer 2016-10-26 16:12 ` lolilolicon 2016-10-26 23:51 ` Bart Schaefer 2016-10-27 19:56 ` Greg Klanderman 2016-10-27 20:35 ` Bart Schaefer 2016-10-31 15:56 ` Oliver Kiddle 2016-10-31 16:16 ` Peter Stephenson [not found] ` <43312.1477929414__19178.7032563754$1477929872$gmane$org@hydra.kiddle.eu> 2016-11-01 17:03 ` Daniel Shahaf [not found] ` <20161101170328.GA24091__43513.8293811635$1478019914$gmane$org@fujitsu.shahaf.local2> 2016-11-03 19:45 ` Daniel Shahaf [not found] ` <161026165138.ZM12130__24043.0697137073$1477525984$gmane$org@torch.brasslantern.com> 2016-10-27 0:45 ` Daniel Shahaf [not found] ` <20161027004500.GA12759__18780.7835791775$1477529337$gmane$org@fujitsu.shahaf.local2> 2016-10-27 12:59 ` Daniel Shahaf 2016-10-26 22:05 ` Mikael Magnusson 2016-10-26 23:59 ` Bart Schaefer
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).