Re: Documentation of nnoo.el

[Eric Abrahamsen]

Lars Ingebrigtsen <address@hidden> writes:

> Eric Abrahamsen <address@hidden> writes:
>
>>> Groups from primary servers aren't prefixed, while groups from
>>> non-primary servers are...
>>
>> Ah, right. I guess I still don't see why it would be so terrible to lose
>> that distinction, though...
>
> It's not terrible -- it's just incompatible.  :-)

Fair enough.

>> Taking a step back, there are two general structural alterations I'd
>> like to suggest. The first is splitting up the .newsrc.eld file a bit:
>> right now it's sort of kitchen-sink, and feels fragile.
>
> Actually, I think it's too transparent.  :-)  It almost looks
> user-editable, which makes people edit it, and things blow up.  It's
> also a cop-out, because we can say "well, just edit the file" instead of
> providing proper interfaces to the data.
>
> It's not like Firefox users open Firefox data files in an editor and
> start typing away...

Well I don't think we disagree here -- .newsrc.eld is a bit dangerous,
for multiple reasons. If marks were stored in a separate file, we could
tell users the file was binary and scare them away from opening it :)

There are already proper interfaces to editing the data, and an EIEIO
version wouldn't change that. It would even add (ugh) a customize
interface for doing the editing, if that's your thing. But at the same
time, the server/group definitions file would be much more
human-readable, if people insisted on looking at it, and much harder to
break in mysterious ways.

>> The other proposal is the agent. I'm imagining the agent as a mix-in
>> class for server backends. It would have many of the same methods as the
>> servers, and would wait in the background until a server signaled a
>> denied/no-connection/I'm-broken error. The agent would then set the
>> server's "status" slot to closed or denied, and the agent's methods
>> would check for that status and take over the action. That would allow
>> the agent to potentially usurp any server functionality that the server
>> itself was unable to perform.
>
> I think you've pretty much described how the Agent works now.  :-)

That's the point! I don't want to change how anything works, just how
it's implemented. All I was saying is that the Agent lends itself very
nicely to generic functions and method composition.

Anyhow, it's maybe not worth trying to have an extended discussion about
this now, when it's all sort of nebulous, and I'm so unlikely to produce
any code right away. Maybe in the next few months, if I come up with a
basic "code sketch", I can post it here or on gnus.general and people
can see what they think?

Yrs,
Eric