* how to kill a virtual group @ 2022-01-28 15:07 Uwe Brauer 2022-01-28 17:05 ` Eric Abrahamsen 0 siblings, 1 reply; 18+ messages in thread From: Uwe Brauer @ 2022-01-28 15:07 UTC (permalink / raw) To: ding Hi In my group buffer I have * 0: nnvirtual:Annu21 When I kill this group, it disappears, but when I leave gnus restart emacs and start gnus again it pops again. My server buffer shows {nnvirtual:^$\|\(^nnimap\+UCMgmail:1-Annu21$\)\|\(^nnimap\+UCMgmail:INBOX$\)} (opened) But I cannot delete that group neither. I am really puzzled. Any ideas? Regards Uwe Brauer ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: how to kill a virtual group 2022-01-28 15:07 how to kill a virtual group Uwe Brauer @ 2022-01-28 17:05 ` Eric Abrahamsen 2022-01-28 21:02 ` Uwe Brauer 0 siblings, 1 reply; 18+ messages in thread From: Eric Abrahamsen @ 2022-01-28 17:05 UTC (permalink / raw) To: ding Uwe Brauer <oub@mat.ucm.es> writes: > Hi > > In my group buffer I have > > * 0: nnvirtual:Annu21 > > When I kill this group, it disappears, but when I leave gnus restart > emacs and start gnus again it pops again. I don't know, I can't reproduce this. It's possible that you need to activate the group (just enter it) before you can "really" delete it? > My server buffer shows > > {nnvirtual:^$\|\(^nnimap\+UCMgmail:1-Annu21$\)\|\(^nnimap\+UCMgmail:INBOX$\)} (opened) > > But I cannot delete that group neither. Do you get the error "Server XYZ must be deleted from your configuration files"? That's what I see, and it's definitely a bug, as it's exactly opposite from reality. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: how to kill a virtual group 2022-01-28 17:05 ` Eric Abrahamsen @ 2022-01-28 21:02 ` Uwe Brauer 2022-01-28 22:21 ` Eric Abrahamsen 0 siblings, 1 reply; 18+ messages in thread From: Uwe Brauer @ 2022-01-28 21:02 UTC (permalink / raw) To: ding [-- Attachment #1: Type: text/plain, Size: 1107 bytes --] >>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes: > Uwe Brauer <oub@mat.ucm.es> writes: >> Hi >> >> In my group buffer I have >> >> * 0: nnvirtual:Annu21 >> >> When I kill this group, it disappears, but when I leave gnus restart >> emacs and start gnus again it pops again. > I don't know, I can't reproduce this. It's possible that you need to > activate the group (just enter it) before you can "really" delete it? I will try this again >> My server buffer shows >> >> {nnvirtual:^$\|\(^nnimap\+UCMgmail:1-Annu21$\)\|\(^nnimap\+UCMgmail:INBOX$\)} (opened) >> >> But I cannot delete that group neither. > Do you get the error "Server XYZ must be deleted from your configuration > files"? That's what I see, and it's definitely a bug, as it's exactly > opposite from reality. Precisely this is the error I see! [1] Footnotes: [1] Hm lately I found two bugs, that one and the one concerning the registry labels (restrict the summary buffer to message with those labels). Anyhow I should better fix them (if I knew how...) [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 5673 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: how to kill a virtual group 2022-01-28 21:02 ` Uwe Brauer @ 2022-01-28 22:21 ` Eric Abrahamsen 2022-01-29 0:03 ` Emanuel Berg 0 siblings, 1 reply; 18+ messages in thread From: Eric Abrahamsen @ 2022-01-28 22:21 UTC (permalink / raw) To: ding Uwe Brauer <oub@mat.ucm.es> writes: >>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes: > >> Uwe Brauer <oub@mat.ucm.es> writes: >>> Hi >>> >>> In my group buffer I have >>> >>> * 0: nnvirtual:Annu21 >>> >>> When I kill this group, it disappears, but when I leave gnus restart >>> emacs and start gnus again it pops again. > >> I don't know, I can't reproduce this. It's possible that you need to >> activate the group (just enter it) before you can "really" delete it? > > I will try this again Do let me know what happens. >>> My server buffer shows >>> >>> {nnvirtual:^$\|\(^nnimap\+UCMgmail:1-Annu21$\)\|\(^nnimap\+UCMgmail:INBOX$\)} (opened) >>> >>> But I cannot delete that group neither. > >> Do you get the error "Server XYZ must be deleted from your configuration >> files"? That's what I see, and it's definitely a bug, as it's exactly >> opposite from reality. > > Precisely this is the error I see! [1] Okay, this is something I've looked at several times over the past couple years. I am not sure how to fix it mostly because I don't understand the original intended behavior of variables like `gnus-server-alist' and `gnus-inserted-opened-servers'. I'll probably need to open a bug report and get Lars looking at it, and figure out first what the code *should* do, before actually fixing it. > Footnotes: > [1] Hm lately I found two bugs, that one and the one concerning the > registry labels (restrict the summary buffer to message with those > labels). Anyhow I should better fix them (if I knew how...) I've got some code underway for the registry marks issue, but it will probably take a little while to finish it. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: how to kill a virtual group 2022-01-28 22:21 ` Eric Abrahamsen @ 2022-01-29 0:03 ` Emanuel Berg 2022-01-29 4:18 ` Eric Abrahamsen 0 siblings, 1 reply; 18+ messages in thread From: Emanuel Berg @ 2022-01-29 0:03 UTC (permalink / raw) To: ding Eric Abrahamsen wrote: >> Precisely this is the error I see! [1] > > Okay, this is something I've looked at several times over > the past couple years. I am not sure how to fix it mostly > because I don't understand the original intended behavior of > variables like `gnus-server-alist' and > `gnus-inserted-opened-servers'. `gnus-server-alist' has the docstring Servers created by Gnus, or via the server buffer. Servers defined in the user's config files do not appear here. This variable is persisted in the user’s .newsrc.eld file. I don't like the "servers defined in the user's config files do not appear here" part, exceptions like that are a bad sign, but as for what the variable expresses, it's clear what data it holds. `gnus-inserted-opened-servers' OTOH isn't documented. It is defined in gnus-srvr.el where it is then used four times. gnus-server-alist is used a lot tho, in several files. I think the "original intended behavior" is simply that it is used whenever it is needed :) -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: how to kill a virtual group 2022-01-29 0:03 ` Emanuel Berg @ 2022-01-29 4:18 ` Eric Abrahamsen 2022-01-29 15:48 ` Emanuel Berg 0 siblings, 1 reply; 18+ messages in thread From: Eric Abrahamsen @ 2022-01-29 4:18 UTC (permalink / raw) To: ding Emanuel Berg <moasenwood@zoho.eu> writes: > Eric Abrahamsen wrote: > >>> Precisely this is the error I see! [1] >> >> Okay, this is something I've looked at several times over >> the past couple years. I am not sure how to fix it mostly >> because I don't understand the original intended behavior of >> variables like `gnus-server-alist' and >> `gnus-inserted-opened-servers'. > > `gnus-server-alist' has the docstring > > Servers created by Gnus, or via the server buffer. > Servers defined in the user's config files do not appear > here. This variable is persisted in the user’s > .newsrc.eld file. > > I don't like the "servers defined in the user's config files > do not appear here" part, exceptions like that are a bad sign, > but as for what the variable expresses, it's clear what data > it holds. > > `gnus-inserted-opened-servers' OTOH isn't documented. It is > defined in gnus-srvr.el where it is then used four times. > > gnus-server-alist is used a lot tho, in several files. I think > the "original intended behavior" is simply that it is used > whenever it is needed :) Right, I have read the docstring! And it is necessary to keep servers defined in gnus.el separate from servers defined in-Gnus, via the *Server* buffer. But my `gnus-server-alist' has only ever held the "archive" server, nothing else, so that's obviously not right. For some reason, servers created in the *Server* buffer aren't added to `gnus-server-alist'. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: how to kill a virtual group 2022-01-29 4:18 ` Eric Abrahamsen @ 2022-01-29 15:48 ` Emanuel Berg 2022-01-29 17:17 ` Eric Abrahamsen 0 siblings, 1 reply; 18+ messages in thread From: Emanuel Berg @ 2022-01-29 15:48 UTC (permalink / raw) To: ding Eric Abrahamsen wrote: > Right, I have read the docstring! And it is necessary to > keep servers defined in gnus.el separate from servers > defined in-Gnus, via the *Server* buffer. Okay, why? > But my `gnus-server-alist' has only ever held the "archive" > server, nothing else, so that's obviously not right. > For some reason, servers created in the *Server* buffer > aren't added to `gnus-server-alist'. Same here, just the archive. I didn't know on could create servers in the *Server* buffer, even ... when and why do you do that? Maybe remove the variable then, and create a new to just hold the archive stuff, if that isn't available in some gnus-archive-* already, and change references to that? -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: how to kill a virtual group 2022-01-29 15:48 ` Emanuel Berg @ 2022-01-29 17:17 ` Eric Abrahamsen 2022-01-30 22:33 ` Emanuel Berg 0 siblings, 1 reply; 18+ messages in thread From: Eric Abrahamsen @ 2022-01-29 17:17 UTC (permalink / raw) To: ding Emanuel Berg <moasenwood@zoho.eu> writes: > Eric Abrahamsen wrote: > >> Right, I have read the docstring! And it is necessary to >> keep servers defined in gnus.el separate from servers >> defined in-Gnus, via the *Server* buffer. > > Okay, why? Because the two kinds of server need to be treated separately. Gnus is not allowed to overwrite your gnus.el file, so if you want to make a change to a server defined there, Gnus can't do it via the *Server* buffer: you have to shut Gnus down, edit gnus.el, and restart. Conversely, servers defined via the *Server* buffer are saved in .newsrc.eld, which only Gnus is supposed to touch, so edits should be made via the *Server* buffer. Gnus needs to know which servers are which. >> But my `gnus-server-alist' has only ever held the "archive" >> server, nothing else, so that's obviously not right. >> For some reason, servers created in the *Server* buffer >> aren't added to `gnus-server-alist'. > > Same here, just the archive. > > I didn't know on could create servers in the *Server* buffer, > even ... when and why do you do that? Mostly by creating groups on the fly: nndoc groups to import old mail, nnvirtual groups to combine other groups, nnselect groups for searching... All of these will create their own server to hold them, and if the group is persistent the server should be added to `gnus-server-alist', and later saved in .newsrc.eld. > Maybe remove the variable then, and create a new to just hold > the archive stuff, if that isn't available in some > gnus-archive-* already, and change references > to that? No, I think the main problem is that servers created in-Gnus are not added to `gnus-server-alist'. Gnus has multiple layers of code for finding servers, so often it works out okay, but in this case it isn't. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: how to kill a virtual group 2022-01-29 17:17 ` Eric Abrahamsen @ 2022-01-30 22:33 ` Emanuel Berg 2022-01-31 19:24 ` Eric Abrahamsen 0 siblings, 1 reply; 18+ messages in thread From: Emanuel Berg @ 2022-01-30 22:33 UTC (permalink / raw) To: ding Eric Abrahamsen wrote: > Because the two kinds of server need to be treated > separately. Gnus is not allowed to overwrite your gnus.el > file, so if you want to make a change to a server defined > there, Gnus can't do it via the *Server* buffer: you have to > shut Gnus down, edit gnus.el, and restart. Conversely, > servers defined via the *Server* buffer are saved in > .newsrc.eld, which only Gnus is supposed to touch, so edits > should be made via the *Server* buffer. Gnus needs to know > which servers are which. In general, stuff that are the same, it shouldn't matter where or in what manner they are defined. If they are not the same, then if something should or shouldn't happen to them because of that, they should have something so one can check - if they by accident look the same, add some flag or something to the data structure perhaps? > No, I think the main problem is that servers created in-Gnus > are not added to `gnus-server-alist'. Gnus has multiple > layers of code for finding servers, so often it works out > okay, but in this case it isn't. But isn't it better that stuff that aren't the same are different to the point this can be determined just by inspecting the very base data? To put that in the layers above - indeed, how are those layers even supposed to find out? Ask some third instance, where and how was this defined? Just think one had to do that all the time, for example with strings and integers? -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: how to kill a virtual group 2022-01-30 22:33 ` Emanuel Berg @ 2022-01-31 19:24 ` Eric Abrahamsen 2022-01-31 21:59 ` Emanuel Berg 0 siblings, 1 reply; 18+ messages in thread From: Eric Abrahamsen @ 2022-01-31 19:24 UTC (permalink / raw) To: ding Emanuel Berg <moasenwood@zoho.eu> writes: > Eric Abrahamsen wrote: > >> Because the two kinds of server need to be treated >> separately. Gnus is not allowed to overwrite your gnus.el >> file, so if you want to make a change to a server defined >> there, Gnus can't do it via the *Server* buffer: you have to >> shut Gnus down, edit gnus.el, and restart. Conversely, >> servers defined via the *Server* buffer are saved in >> .newsrc.eld, which only Gnus is supposed to touch, so edits >> should be made via the *Server* buffer. Gnus needs to know >> which servers are which. > > In general, stuff that are the same, it shouldn't matter where > or in what manner they are defined. In principle I agree, but in this case I think it's pretty useful to have the ability to define servers in a config file, that's maybe version controlled, but then also have the ability to create and destroy servers on the fly within Gnus. > If they are not the same, then if something should or > shouldn't happen to them because of that, they should have > something so one can check - if they by accident look the > same, add some flag or something to the data > structure perhaps? In this case, I think the check is *supposed* to be whether the server is present in `gnus-(secondary-)select-method(s)', or whether it is present in `gnus-server-alist'. In theory it's a clean way to do it, because the first two variables are simply loaded from your .gnus.el and never modified, and the second variable is loaded from and saved to .newsrc.el by Gnus, which is allowed to modify the variable. It's just that something seems to not be working correctly there. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: how to kill a virtual group 2022-01-31 19:24 ` Eric Abrahamsen @ 2022-01-31 21:59 ` Emanuel Berg 2022-02-01 1:43 ` Eric Abrahamsen 0 siblings, 1 reply; 18+ messages in thread From: Emanuel Berg @ 2022-01-31 21:59 UTC (permalink / raw) To: ding Eric Abrahamsen wrote: > In principle I agree, but in this case I think it's pretty > useful to have the ability to define servers in a config > file, that's maybe version controlled, but then also have > the ability to create and destroy servers on the fly > within Gnus. Yes, but why should it matter when they are _used_? Where and how they are defined? -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: how to kill a virtual group 2022-01-31 21:59 ` Emanuel Berg @ 2022-02-01 1:43 ` Eric Abrahamsen 2022-02-01 3:10 ` Emanuel Berg 0 siblings, 1 reply; 18+ messages in thread From: Eric Abrahamsen @ 2022-02-01 1:43 UTC (permalink / raw) To: ding Emanuel Berg <moasenwood@zoho.eu> writes: > Eric Abrahamsen wrote: > >> In principle I agree, but in this case I think it's pretty >> useful to have the ability to define servers in a config >> file, that's maybe version controlled, but then also have >> the ability to create and destroy servers on the fly >> within Gnus. > > Yes, but why should it matter when they are _used_? Where and > how they are defined? It matters when they are edited or deleted, that's all. It doesn't make any sense to edit or delete servers defined in .gnus.el via the *Server* buffer, because those changes will not persist -- they'll be re-written next time you start Gnus. Uwe was trying to delete a nnvirtual server, and since that server was created in Gnus, it should be deletable in Gnus. It wasn't, hence the bug. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: how to kill a virtual group 2022-02-01 1:43 ` Eric Abrahamsen @ 2022-02-01 3:10 ` Emanuel Berg 2022-02-01 4:32 ` Eric Abrahamsen 0 siblings, 1 reply; 18+ messages in thread From: Emanuel Berg @ 2022-02-01 3:10 UTC (permalink / raw) To: ding Eric Abrahamsen wrote: >> Yes, but why should it matter when they are _used_? >> Where and how they are defined? > > It matters when they are edited or deleted, that's all. > It doesn't make any sense to edit or delete servers defined > in .gnus.el via the *Server* buffer, because those changes > will not persist -- they'll be re-written next time you > start Gnus. Not necessarily, and besides: (setq some-integer 42) M-: (cl-incf some-integer) RET M-x kill-emacs RET -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: how to kill a virtual group 2022-02-01 3:10 ` Emanuel Berg @ 2022-02-01 4:32 ` Eric Abrahamsen 2022-02-01 7:26 ` Emanuel Berg 0 siblings, 1 reply; 18+ messages in thread From: Eric Abrahamsen @ 2022-02-01 4:32 UTC (permalink / raw) To: ding Emanuel Berg <moasenwood@zoho.eu> writes: > Eric Abrahamsen wrote: > >>> Yes, but why should it matter when they are _used_? >>> Where and how they are defined? >> >> It matters when they are edited or deleted, that's all. >> It doesn't make any sense to edit or delete servers defined >> in .gnus.el via the *Server* buffer, because those changes >> will not persist -- they'll be re-written next time you >> start Gnus. > > Not necessarily, and besides: > > (setq some-integer 42) > M-: (cl-incf some-integer) RET > M-x kill-emacs RET I don't understand this. If `some-integer' is set to 42 in your init files, and you increment it, it will be back to 42 next time you start Emacs, that's the point. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: how to kill a virtual group 2022-02-01 4:32 ` Eric Abrahamsen @ 2022-02-01 7:26 ` Emanuel Berg 2022-02-01 16:10 ` Eric Abrahamsen 0 siblings, 1 reply; 18+ messages in thread From: Emanuel Berg @ 2022-02-01 7:26 UTC (permalink / raw) To: ding Eric Abrahamsen wrote: >> Not necessarily, and besides: >> >> (setq some-integer 42) >> M-: (cl-incf some-integer) RET >> M-x kill-emacs RET > > I don't understand this. If `some-integer' is set to 42 in > your init files, and you increment it, it will be back to 42 > next time you start Emacs But still that's fine and there is no special treatment anywhere that asks where it was defined, what interface was used etc. -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: how to kill a virtual group 2022-02-01 7:26 ` Emanuel Berg @ 2022-02-01 16:10 ` Eric Abrahamsen 2022-02-04 2:30 ` Emanuel Berg 0 siblings, 1 reply; 18+ messages in thread From: Eric Abrahamsen @ 2022-02-01 16:10 UTC (permalink / raw) To: ding Emanuel Berg <moasenwood@zoho.eu> writes: > Eric Abrahamsen wrote: > >>> Not necessarily, and besides: >>> >>> (setq some-integer 42) >>> M-: (cl-incf some-integer) RET >>> M-x kill-emacs RET >> >> I don't understand this. If `some-integer' is set to 42 in >> your init files, and you increment it, it will be back to 42 >> next time you start Emacs > > But still that's fine and there is no special treatment > anywhere that asks where it was defined, what interface was > used etc. I think it would be weird if Gnus let you edit a server you'd defined in your .gnus.el file, and then those edits were simply overwritten next time you restarted Gnus. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: how to kill a virtual group 2022-02-01 16:10 ` Eric Abrahamsen @ 2022-02-04 2:30 ` Emanuel Berg 2022-02-04 16:12 ` Eric Abrahamsen 0 siblings, 1 reply; 18+ messages in thread From: Emanuel Berg @ 2022-02-04 2:30 UTC (permalink / raw) To: ding Eric Abrahamsen wrote: > I think it would be weird if Gnus let you edit a server > you'd defined in your .gnus.el file, and then those edits > were simply overwritten next time you restarted Gnus. But then you get the situation now where the same stuff has to be treated differently ... which should never happen. Something like this could be used from .gnus.el and *Server*, alike since they, while different, should differ on the interface level only ... (defun gnus-edit-server (srv params &optional redefine) "Create or edit SRV with PARAMS. If REDEFINE is non-nil, overwrite existing data ..." ... ) If people then choose to ignore that and instead edit the data directly in .gnus.el then yes, that would reset any in-between session changes, be it from Lisp or *Server* or any other thinkable way for that matter - and that's completely fine, it is that way with everything, and so it should. Set the integer to something, change it to something else, if it is set again on the next init that's what it'll be - I mean, what else would one have it be and how ever would that work? So interactive interface from Emacs (buttons etc), interface from Lisp (Elisp code); they uses the same setters and functions one level below to do the actual business; and when done, no worry and no record where the data was set. -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: how to kill a virtual group 2022-02-04 2:30 ` Emanuel Berg @ 2022-02-04 16:12 ` Eric Abrahamsen 0 siblings, 0 replies; 18+ messages in thread From: Eric Abrahamsen @ 2022-02-04 16:12 UTC (permalink / raw) To: ding Emanuel Berg <moasenwood@zoho.eu> writes: > Eric Abrahamsen wrote: > >> I think it would be weird if Gnus let you edit a server >> you'd defined in your .gnus.el file, and then those edits >> were simply overwritten next time you restarted Gnus. > > But then you get the situation now where the same stuff has to > be treated differently ... which should never happen. > > Something like this could be used from .gnus.el and *Server*, > alike since they, while different, should differ on the > interface level only ... > > (defun gnus-edit-server (srv params &optional redefine) > "Create or edit SRV with PARAMS. > If REDEFINE is non-nil, overwrite existing data ..." > ... ) > > If people then choose to ignore that and instead edit the data > directly in .gnus.el then yes, that would reset any in-between > session changes, be it from Lisp or *Server* or any other > thinkable way for that matter - and that's completely fine, it > is that way with everything, and so it should. Set the integer > to something, change it to something else, if it is set again > on the next init that's what it'll be - I mean, what else > would one have it be and how ever would that work? > > So interactive interface from Emacs (buttons etc), interface > from Lisp (Elisp code); they uses the same setters and > functions one level below to do the actual business; and when > done, no worry and no record where the data was set. Well, I understand where you're coming from, but I don't think writing all this code and changing Gnus' behavior is worth it for some conceptual idea of consistency and purity. With proper messaging to the user (and non-buggy code) it's just not a huge tragedy. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2022-02-04 16:12 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-01-28 15:07 how to kill a virtual group Uwe Brauer 2022-01-28 17:05 ` Eric Abrahamsen 2022-01-28 21:02 ` Uwe Brauer 2022-01-28 22:21 ` Eric Abrahamsen 2022-01-29 0:03 ` Emanuel Berg 2022-01-29 4:18 ` Eric Abrahamsen 2022-01-29 15:48 ` Emanuel Berg 2022-01-29 17:17 ` Eric Abrahamsen 2022-01-30 22:33 ` Emanuel Berg 2022-01-31 19:24 ` Eric Abrahamsen 2022-01-31 21:59 ` Emanuel Berg 2022-02-01 1:43 ` Eric Abrahamsen 2022-02-01 3:10 ` Emanuel Berg 2022-02-01 4:32 ` Eric Abrahamsen 2022-02-01 7:26 ` Emanuel Berg 2022-02-01 16:10 ` Eric Abrahamsen 2022-02-04 2:30 ` Emanuel Berg 2022-02-04 16:12 ` Eric Abrahamsen
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).