driving Gnus via a "gnuclient" sort of program

driving Gnus via a "gnuclient" sort of program

[Karl Kleinpaste]

--text follows this line-- 
This is a wide open, "blue sky", vaguely WIBNI sort of question.
From: Karl Kleinpaste <karl@charcoal.com>
Date: Mon, 30 Jul 2001 15:55:18 -0400
Message-ID: <vxkae1m2nvd.fsf@cinnamon.vanillaknot.com>
Lines: 25
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.4 (Artificial
 Intelligence)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Let us assume that I've somewhat lost my mind, and I'm curious about
and interested in the possibility of driving XEmacs+Gnus via a socket,
the way that gnuclient works.

This is part of a more general question about driving XEmacs remotely,
but Gnus is the 900-pound gorilla example-at-hand, and so will serve
nicely to break the back of this idea if it's not reasonable or possible.

I would like to be able to shovel Gnus function calls over the socket
with (gnuserv-eval (progn (...))) (such as starting Gnus, entering
groups, and reading articles), get function return values back, and
then evaluate further functions to tell XEmacs to hand me back the
entire contents of the various buffers that are normally displayed.
Ideally, I'd like to do this with "xemacs -unmapped -f gnuserv-start"
so that XEmacs isn't even visually present on the window system,
thereby being effectively totally hidden from the user.  When
requesting buffer contents back, I will need to get full detail on
buffers' textual content, fontification (UBI), colorization (headers
and quotation depth), overlays (e.g. smileys and whatnot), possibly
even image content though that may be addressable elsehow.

Exactly how far off the deep end have I stepped by pondering this?
What are the ramifications of attempting to (mis)use Gnus in this way?

--karl

Re: driving Gnus via a "gnuclient" sort of program

[Paul Jarc]

Karl Kleinpaste <karl@charcoal.com> writes:
> Let us assume that I've somewhat lost my mind, and I'm curious about
> and interested in the possibility of driving XEmacs+Gnus via a socket,
> the way that gnuclient works.
...
> Ideally, I'd like to do this with "xemacs -unmapped -f gnuserv-start"
> so that XEmacs isn't even visually present on the window system,
> thereby being effectively totally hidden from the user.

Why not just send make-frame-on-{display,tty} to the server?  Then
everything else can go through the frame instead of the socket.


paul

Re: driving Gnus via a "gnuclient" sort of program

[Karl Kleinpaste]

prj@po.cwru.edu (Paul Jarc) writes:
> Why not just send make-frame-on-{display,tty} to the server?  Then
> everything else can go through the frame instead of the socket.

No, you misunderstand.  I do not want XEmacs to be visible to the user
at all.  I want to post-process every resulting buffer produced by
Gnus in a separate program, which I might or might not let the user
eventually see.

Re: driving Gnus via a "gnuclient" sort of program

[Kai Großjohann]

On Mon, 30 Jul 2001, Karl Kleinpaste wrote:

> prj@po.cwru.edu (Paul Jarc) writes:
>> Why not just send make-frame-on-{display,tty} to the server?  Then
>> everything else can go through the frame instead of the socket.
> 
> No, you misunderstand.  I do not want XEmacs to be visible to the
> user at all.  I want to post-process every resulting buffer produced
> by Gnus in a separate program, which I might or might not let the
> user eventually see.

You could just *pretend* to be an X server, but never display
anything.  But your pretense X server gets all the info it wants...

That's really sick, that is.

kai
-- 
~/.signature: No such file or directory

OT: fake X server (was: driving Gnus via a "gnuclient" sort of program)

[Andreas Fuchs]

[-- Attachment #1.1: Type: text/plain, Size: 730 bytes --]

Today, Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> wrote:
> You could just *pretend* to be an X server, but never display
> anything.  But your pretense X server gets all the info it wants...
> 
> That's really sick, that is.

Absolutely. I actually wanted to write a lib that does this to make it
easier to run one or more X programs inside another's frame (say, two
xpdfs for page-to-page reading of a book).

Aside from being extremely sick, the fake X server would have to provide
an improbably large window size for the emacs, so that all of the
message fits on a screen, which I imagine is not so good for memory
requirements, either. (-:

-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: OT: fake X server (was: driving Gnus via a "gnuclient" sort of program)

[Kai Großjohann]

On Tue, 31 Jul 2001, Andreas Fuchs wrote:

> Aside from being extremely sick, the fake X server would have to
> provide an improbably large window size for the emacs, so that all
> of the message fits on a screen, which I imagine is not so good for
> memory requirements, either. (-:

Hm?  Emacs has a *Messages* buffer...

kai
-- 
~/.signature: No such file or directory

Re: OT: fake X server

[Andreas Fuchs]

[-- Attachment #1.1: Type: text/plain, Size: 524 bytes --]

Today, Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> wrote:
>> Aside from being extremely sick, the fake X server would have to
>> provide an improbably large window size for the emacs, so that all
>> of the message fits on a screen, which I imagine is not so good for
>> memory requirements, either. (-:
> Hm?  Emacs has a *Messages* buffer...

Argh, I meant "Article", not "Message".

Thanks to Kai for a very good (in the evil sense) idea, (-:
-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: OT: fake X server (was: driving Gnus via a "gnuclient" sort of program)

[Nuutti Kotivuori]

Andreas Fuchs wrote:
> Today, Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> wrote:
>> You could just *pretend* to be an X server, but never display
>> anything.  But your pretense X server gets all the info it wants...
>> 
>> That's really sick, that is.
> 
> Absolutely. I actually wanted to write a lib that does this to make
> it easier to run one or more X programs inside another's frame (say,
> two xpdfs for page-to-page reading of a book).

xnest :P

-- Naked