Gnus development mailing list
 help / color / mirror / Atom feed
* 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).