bug#18198: Gnus fails to read ~/.newsrc with group names which are not symbols

[Ivan Shmakov <ivan@siamics.net>]

Package:  emacs, gnus
Severity: minor
Tags:     patch

	As it seems, gnus-newsrc-to-gnus-format fails to correctly
	process ~/.newsrc entries with group names not being /complete/
	Emacs Lisp expressions (integers, symbols, etc.), as in:

[Hello]/World: 42
[[[This-fails: 1

	I believe that the problem is at the following point.

  2556	      (narrow-to-region
  2557	       (point)
  2558	       (progn (skip-chars-forward "^ \t!:\n") (point)))
  2559	      (goto-char (point-min))
  2560	      (setq symbol
  2561		    (and (/= (point-min) (point-max))
  2562			 (let ((obarray gnus-active-hashtb)) (read buf))))
  2563	      (widen)

	Here, the “group” field of .newsrc is read as an Emacs Lisp
	expression.  Which may result either in an error, or, in the
	case of [Hello]/World – and, similarly, (Hello)/World – in only
	the leading [Hello] or (Hello) being actually read.

	Instead, I believe that the entire string is to be read and
	interned, as in (untested):

   (setq symbol
         (let ((save (point)))
           (skip-chars-forward "^ \t!:\n")
           (and (> (point) save)
                (intern (buffer-substring-no-properties save (point))
                        gnus-active-hashtb))))

  2582	       (symbol
  2583		;; Group names can be just numbers.
  2584		(when (numberp symbol)
  2585		  (setq symbol (intern (int-to-string symbol) gnus-active-hashtb)))
  2586		(unless (boundp symbol)
  2587		  (set symbol nil))

	Naturally, the numberp check above will no longer be necessary
	after the change suggested.

	Please note that this change also prevents the boundp check here
	from raising an error should the group name be a valid Emacs
	Lisp non-symbol form (say, a vector or a list.)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A