Info: (gnus) NNTP

gnus: NNTP

 
 6.2.1 NNTP
 ----------
 
 Subscribing to a foreign group from an NNTP server is rather easy.  You
 just specify ‘nntp’ as method and the address of the NNTP server as the,
 uhm, address.
 
    If the NNTP server is located at a non-standard port, setting the
 third element of the select method to this port number should allow you
 to connect to the right port.  You’ll have to edit the group info for
 that (Foreign Groups).
 
    The name of the foreign group can be the same as a native group.  In
 fact, you can subscribe to the same group from as many different servers
 you feel like.  There will be no name collisions.
 
    The following variables can be used to create a virtual ‘nntp’
 server:
 
 ‘nntp-server-opened-hook’
      is run after a connection has been made.  It can be used to send
      commands to the NNTP server after it has been contacted.  By
      default it sends the command ‘MODE READER’ to the server with the
      ‘nntp-send-mode-reader’ function.  This function should always be
      present in this hook.
 
 ‘nntp-authinfo-function’
      This function will be used to send ‘AUTHINFO’ to the NNTP server.
      The default function is ‘nntp-send-authinfo’, which looks through
      your ‘~/.authinfo’ (or whatever you’ve set the ‘nntp-authinfo-file’
      variable to) for applicable entries.  If none are found, it will
      prompt you for a login name and a password.  The format of the
      ‘~/.authinfo’ file is (almost) the same as the ‘ftp’ ‘~/.netrc’
      file, which is defined in the ‘ftp’ manual page, but here are the
      salient facts:
 
        1. The file contains one or more line, each of which define one
           server.
 
        2. Each line may contain an arbitrary number of token/value
           pairs.
 
           The valid tokens include ‘machine’, ‘login’, ‘password’,
           ‘default’.  In addition Gnus introduces two new tokens, not
           present in the original ‘.netrc’/‘ftp’ syntax, namely ‘port’
           and ‘force’.  (This is the only way the ‘.authinfo’ file
           format deviates from the ‘.netrc’ file format.)  ‘port’ is
           used to indicate what port on the server the credentials apply
           to and ‘force’ is explained below.
 
      Here’s an example file:
 
           machine news.uio.no login larsi password geheimnis
           machine nntp.ifi.uio.no login larsi force yes
 
      The token/value pairs may appear in any order; ‘machine’ doesn’t
      have to be first, for instance.
 
      In this example, both login name and password have been supplied
      for the former server, while the latter has only the login name
      listed, and the user will be prompted for the password.  The latter
      also has the ‘force’ tag, which means that the authinfo will be
      sent to the NNTP server upon connection; the default (i.e., when
      there is not ‘force’ tag) is to not send authinfo to the NNTP
      server until the NNTP server asks for it.
 
      You can also add ‘default’ lines that will apply to all servers
      that don’t have matching ‘machine’ lines.
 
           default force yes
 
      This will force sending ‘AUTHINFO’ commands to all servers not
      previously mentioned.
 
      Remember to not leave the ‘~/.authinfo’ file world-readable.
 
 ‘nntp-server-action-alist’
      This is a list of regexps to match on server types and actions to
      be taken when matches are made.  For instance, if you want Gnus to
      beep every time you connect to innd, you could say something like:
 
           (setq nntp-server-action-alist
                 '(("innd" (ding))))
 
      You probably don’t want to do that, though.
 
      The default value is
 
           '(("nntpd 1\\.5\\.11t"
              (remove-hook 'nntp-server-opened-hook
                           'nntp-send-mode-reader)))
 
      This ensures that Gnus doesn’t send the ‘MODE READER’ command to
      nntpd 1.5.11t, since that command chokes that server, I’ve been
      told.
 
 ‘nntp-maximum-request’
      If the NNTP server doesn’t support NOV headers, this back end will
      collect headers by sending a series of ‘head’ commands.  To speed
      things up, the back end sends lots of these commands without
      waiting for reply, and then reads all the replies.  This is
      controlled by the ‘nntp-maximum-request’ variable, and is 400 by
      default.  If your network is buggy, you should set this to 1.
 
 ‘nntp-connection-timeout’
      If you have lots of foreign ‘nntp’ groups that you connect to
      regularly, you’re sure to have problems with NNTP servers not
      responding properly, or being too loaded to reply within reasonable
      time.  This is can lead to awkward problems, which can be helped
      somewhat by setting ‘nntp-connection-timeout’.  This is an integer
      that says how many seconds the ‘nntp’ back end should wait for a
      connection before giving up.  If it is ‘nil’, which is the default,
      no timeouts are done.
 
 ‘nntp-nov-is-evil’
      If the NNTP server does not support NOV, you could set this
      variable to ‘t’, but ‘nntp’ usually checks automatically whether
      NOV can be used.
 
 ‘nntp-xover-commands’
      List of strings used as commands to fetch NOV lines from a server.
      The default value of this variable is ‘("XOVER" "XOVERVIEW")’.
 
 ‘nntp-nov-gap’
      ‘nntp’ normally sends just one big request for NOV lines to the
      server.  The server responds with one huge list of lines.  However,
      if you have read articles 2–5000 in the group, and only want to
      read article 1 and 5001, that means that ‘nntp’ will fetch 4999 NOV
      lines that you will not need.  This variable says how big a gap
      between two consecutive articles is allowed to be before the
      ‘XOVER’ request is split into several request.  Note that if your
      network is fast, setting this variable to a really small number
      means that fetching will probably be slower.  If this variable is
      ‘nil’, ‘nntp’ will never split requests.  The default is 5.
 
 ‘nntp-xref-number-is-evil’
      When Gnus refers to an article having the ‘Message-ID’ that a user
      specifies or having the ‘Message-ID’ of the parent article of the
      current one (Finding the Parent), Gnus sends a ‘HEAD’
      command to the NNTP server to know where it is, and the server
      returns the data containing the pairs of a group and an article
      number in the ‘Xref’ header.  Gnus normally uses the article number
      to refer to the article if the data shows that that article is in
      the current group, while it uses the ‘Message-ID’ otherwise.
      However, some news servers, e.g., ones running Diablo, run multiple
      engines having the same articles but article numbers are not kept
      synchronized between them.  In that case, the article number that
      appears in the ‘Xref’ header varies by which engine is chosen, so
      you cannot refer to the parent article that is in the current
      group, for instance.  If you connect to such a server, set this
      variable to a non-‘nil’ value, and Gnus never uses article numbers.
      For example:
 
           (setq gnus-select-method
                 '(nntp "newszilla"
                        (nntp-address "newszilla.example.com")
                        (nntp-xref-number-is-evil t)
                        ...))
 
      The default value of this server variable is ‘nil’.
 
 ‘nntp-prepare-server-hook’
      A hook run before attempting to connect to an NNTP server.
 
 ‘nntp-record-commands’
      If non-‘nil’, ‘nntp’ will log all commands it sends to the NNTP
      server (along with a timestamp) in the ‘*nntp-log*’ buffer.  This
      is useful if you are debugging a Gnus/NNTP connection that doesn’t
      seem to work.
 
 ‘nntp-open-connection-function’
      It is possible to customize how the connection to the nntp server
      will be opened.  If you specify an ‘nntp-open-connection-function’
      parameter, Gnus will use that function to establish the connection.
      Seven pre-made functions are supplied.  These functions can be
      grouped in two categories: direct connection functions (four
      pre-made), and indirect ones (three pre-made).
 
 ‘nntp-never-echoes-commands’
      Non-‘nil’ means the nntp server never echoes commands.  It is
      reported that some nntps server doesn’t echo commands.  So, you may
      want to set this to non-‘nil’ in the method for such a server
      setting ‘nntp-open-connection-function’ to ‘nntp-open-ssl-stream’
      for example.  The default value is ‘nil’.  Note that the
      ‘nntp-open-connection-functions-never-echo-commands’ variable
      overrides the ‘nil’ value of this variable.
 
 ‘nntp-open-connection-functions-never-echo-commands’
      List of functions that never echo commands.  Add or set a function
      which you set to ‘nntp-open-connection-function’ to this list if it
      does not echo commands.  Note that a non-‘nil’ value of the
      ‘nntp-never-echoes-commands’ variable overrides this variable.  The
      default value is ‘(nntp-open-network-stream)’.
 
 ‘nntp-prepare-post-hook’
      A hook run just before posting an article.  If there is no
      ‘Message-ID’ header in the article and the news server provides the
      recommended ID, it will be added to the article before running this
      hook.  It is useful to make ‘Cancel-Lock’ headers even if you
      inhibit Gnus to add a ‘Message-ID’ header, you could say:
 
           (add-hook 'nntp-prepare-post-hook 'canlock-insert-header)
 
      Note that not all servers support the recommended ID.  This works
      for INN versions 2.3.0 and later, for instance.
 
 ‘nntp-server-list-active-group’
      If ‘nil’, then always use ‘GROUP’ instead of ‘LIST ACTIVE’.  This
      is usually slower, but on misconfigured servers that don’t update
      their active files often, this can help.
gnus: NNTP

Menu
