Re: 'g' in the group buffer still very slow

[kai.grossjohann@uni-duisburg.de (Kai Großjohann)]

Martin Rohde <martin.rohde@gmx.de> writes:

> Well, nntp-send-command looks, if there's an echo, and then deletes
> it. I don't understand most of the code in nntp-open-connection, so
> I don't know if anything of this patch makes sense. And I don't know
> how to test it, because i don't know how to force such a local echo.

If nobody steps forward to test it (I don't have the time, sadly),
then you'll need to find a way to do it yourself.  I'm not sure, but
you might be successful with using telnet to open a connection.

You could create a new server definition that uses telnet instead of
connecting directly.  See the variable nntp-open-connection-function
and the function nntp-open-telnet-stream, referenced from the
variable.  Maybe you can twiddle the telnet args such that echoing is
used?  You might wish to manually send stuff to the server in the
server buffer (" *server foo *nntpd*" or somesuch, mind the leading
space) using process-send-string.  Then you can see whether the
server echoes commands.  (I hope that the echo removal isn't done in
a process filter.)

> What this code does, is to send a "MODE READER" as a No-Op command,
> when the connection is established (I think ;), and then it looks,
> just like in nntp-send-command, if the command is echoed in the
> server-buffer. If so, it deletes it and sets nntp-delete-echo to t
> for future reference (I hope).

I'm afraid that spot is too early.  Some servers might require
authentication to log in.  Thinking...  Hm...  Oh!  It doesn't matter:
if the server requires authentication, then it just sends an error
message which is just as good for your purposes as a success message.

But "mode reader" is not a no-op, could that be a problem?
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)