Suddenly can't subscribe to nnslashdot groups with 'F' ?

Suddenly can't subscribe to nnslashdot groups with 'F' ?

[Anssi Saari]

Hi,

I've been happily reading slashdot with Gnus all year, but since yesterday
I can't subscribe the nnslashdot groups any more with 'F'. I just get
Wrong type argument: stringp, ("nnslashdot") or with debug-on-error
set to t the dump below. Manual subscribing through the server buffer
works though.  I upgraded to last night's snapshot, but no change.

Signaling: (wrong-type-argument stringp ("nnslashdot"))
  string-match(("nnslashdot") "erinet.esoe.apps.financial-economy")
  byte-code("..." [nil gnus-group-change-level-function match gnus-topic-list topic --dolist-temp--68849 subscribe gnus-topic-parameters string-match newsgroup gnus-subscribe-alphabetically assoc gnus-topic-alist throw end t] 4)
  gnus-subscribe-topics("erinet.esoe.apps.financial-economy")
  #<compiled-function (group-sym) "...(167)" [symbol-name group-sym group boundp intern-soft gnus-newsrc-hashtb gnus-zombie-list gnus-killed-list intern gnus-active-hashtb gnus-matches-options-n do-sub subscribe groups gnus-killed-hashtb gnus-subscribe-options-newsgroup-method ignore nil gnus-subscribe-hierarchical-interactive new-newsgroups gnus-subscribe-newsgroup-method] 4>(erinet\.esoe\.apps\.financial-economy)
  mapatoms(#<compiled-function (group-sym) "...(167)" [symbol-name group-sym group boundp intern-soft gnus-newsrc-hashtb gnus-zombie-list gnus-killed-list intern gnus-active-hashtb gnus-matches-options-n do-sub subscribe groups gnus-killed-hashtb gnus-subscribe-options-newsgroup-method ignore nil gnus-subscribe-hierarchical-interactive new-newsgroups gnus-subscribe-newsgroup-method] 4> [0 0 0 erinet\.esoe\.apps\.logistics erinet\.multicast 0 0 erinet\.esoe\.apps\.marketing-sales-advertising 0 sfnet\.atk\.x-ikkunointi 0 0 0 0 0 0 0 erinet\.esoe\.apps\.multimedia 0 0 erinet\.era\.rosert 0 0 0 0 0 0 0 erinet\.esoe\.apps\.communication-mail 0 0 0 0 0 0 erinet\.project\.axm3\.projects-subprojects 0 erinet\.hardware\.competence 0 0 erinet\.org\.hwdevtech 0 0 0 0 0 0 0 erinet\.developement\.wap 0 ...])
  gnus-ask-server-for-new-groups()
  gnus-find-new-newsgroups(1)
  gnus-group-find-new-groups(1)
  call-interactively(gnus-group-find-new-groups)

Re: Suddenly can't subscribe to nnslashdot groups with 'F' ?

[ShengHuo ZHU]

Anssi Saari <as@sci.fi> writes:

> Hi,
> 
> I've been happily reading slashdot with Gnus all year, but since yesterday
> I can't subscribe the nnslashdot groups any more with 'F'. I just get
> Wrong type argument: stringp, ("nnslashdot") or with debug-on-error
> set to t the dump below. Manual subscribing through the server buffer
> works though.  I upgraded to last night's snapshot, but no change.
> 
> Signaling: (wrong-type-argument stringp ("nnslashdot"))

Type `G p' on the topic line.  You should see something like
((subscribe . "nnslashdot")).  The problem is that you might miss the
dot between subscribe and "nnslashdot".

ShengHuo

Re: Suddenly can't subscribe to nnslashdot groups with 'F' ?

[Anssi Saari]

 
> Type `G p' on the topic line.  You should see something like
> ((subscribe . "nnslashdot")).  The problem is that you might miss the
> dot between subscribe and "nnslashdot".

Yes, that turns out to be the problem, sort of. The topic parameters for
my Slashdot topic were correct, but I had ((subscribe "nnslashdot")) in
my highest level topic. I don't know where that came from though.

Old bug reappearing in 5.8.8

[Colin Marquardt]

Hi,

did anyone notice that the old bug from 5.8.3 (AFAIR, fixed in 5.8.4)
which moved point in the summary buffer after you selected a message
reappeared in the released 5.8.8 (and thus in Oort too I suppose)? It
was still fine with my snapshot from 20001122.

It is really annoying since when you want to reply to the current
message, you are actually replying to the message the point is on
which is a totally different one.

Cheers,
  Colin

Re: Old bug reappearing in 5.8.8

[ShengHuo ZHU]

Colin Marquardt <colin.marquardt@usa.alcatel.com> writes:

> Hi,
> 
> did anyone notice that the old bug from 5.8.3 (AFAIR, fixed in 5.8.4)
> which moved point in the summary buffer after you selected a message
> reappeared in the released 5.8.8 (and thus in Oort too I suppose)? It
> was still fine with my snapshot from 20001122.

Could you try the latest snapshot?  I guess it was introduced in
20001204, and fixed in 20010112.

ShengHuo

Re: Old bug reappearing in 5.8.8

[Colin Marquardt]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> Colin Marquardt <colin.marquardt@usa.alcatel.com> writes:
> 
> > did anyone notice that the old bug from 5.8.3 (AFAIR, fixed in 5.8.4)
> > which moved point in the summary buffer after you selected a message
> > reappeared in the released 5.8.8 (and thus in Oort too I suppose)? It
> > was still fine with my snapshot from 20001122.
> 
> Could you try the latest snapshot?  I guess it was introduced in
> 20001204, and fixed in 20010112.

Thanks, that seems to fix it indeed.

While I'm at it, here are some issues I encountered while installing
that snapshot (--with-xemacs):

-------

The file with the most errors:

| While compiling rfc2047-encode-message-header in file /home/sw/cmarquar/emacs/gnus-CURRENT-20010116/lisp/rfc2047.el:
|   ** reference to free variable enable-multibyte-characters
| While compiling rfc2047-encode:
|   ** reference to free variable enable-multibyte-characters
| While compiling rfc2047-b-encode-region:
|   ** base64-encode-region called with 3 arguments, but accepts only 2
| While compiling rfc2047-decode-region:
|   ** reference to free variable enable-multibyte-characters
| While compiling rfc2047-decode-string:
|   ** reference to free variable enable-multibyte-characters
| While compiling rfc2047-decode:
|   ** reference to free variable enable-multibyte-characters
| While compiling the end of the data:
|   ** the function charsetp is not known to be defined.

enable-multibyte-characters occurs in a lot of files.

There are some more assignments to free variables, do you want me to
report them all?

--------

I don't have makeinfo installed on this Solaris box, so it is
running:


|   xemacs -batch -q -no-site-file -eval '(find-file "gnus.texi")' -eval '(while (re-search-forward "@\\(end \\)?ifnottex" nil t) (replace-match ""))' -l texinfmt -f texinfo-every-node-update -f texinfo-format-buffer -f save-buffer; \
| fi
| Making info file `gnus' from `gnus.texi'.
| gnus.texi:8: Unknown info command `dircategory'.
| gnus.texi:9: Unknown info command `direntry'.
| gnus.texi:11: Unmatched `@end'.
| gnus.texi:300: Unknown info command `ifnottex'.
| gnus.texi:322: Unmatched `@end'.
| gnus.texi:413: Unknown info command `detailmenu'.
| gnus.texi:869: Bad argument to `end', `detailmenu', using `menu'.
| gnus.texi:869: Unmatched `@end'.
| gnus.texi:10782: Unknown info command `uref'.
| gnus.texi:10782: Misplaced `{'.
| gnus.texi:10782: Misplaced `}'.
| gnus.texi:12920: Unknown info command `uref'.
| gnus.texi:12920: Misplaced `{'.
| gnus.texi:12920: Misplaced `}'.
| [...repeating several times...]
| ./gnus.texi:23454: Node `Key Index''s Next field not pointed back to.
| ./gnus.texi:908: This node (`Finding the News') is the one with the bad `Prev'.
| *** Error code 2
| make: Fatal error: Command failed for target `gnus'
| Current working directory /home/sw/cmarquar/emacs/gnus-CURRENT-20010116/texi
| *** Error code 1
| make: Fatal error: Command failed for target `info'

--------

It puts an "X-Draft-From:" header to my reply, but on top of all the
headers, before the "To:" even. Could this be moved a bit further
down?

--------

I second that the older "In-Reply-To:" format was nicer. I can get
the information from the current format from the "References:" header
already.


Thanks,
  Colin

Re: Old bug reappearing in 5.8.8

[ShengHuo ZHU]

Colin Marquardt <colin.marquardt@usa.alcatel.com> writes:

> The file with the most errors:
> 
> | While compiling rfc2047-encode-message-header in file /home/sw/cmarquar/emacs/gnus-CURRENT-20010116/lisp/rfc2047.el:
> |   ** reference to free variable enable-multibyte-characters
> | While compiling rfc2047-encode:
> |   ** reference to free variable enable-multibyte-characters

Are you sure you compile them from a clean copy?

> | While compiling rfc2047-b-encode-region:
> |   ** base64-encode-region called with 3 arguments, but accepts only 2

For XEmacs 21.1, you'd better copy base64.el from contrib directory to
lisp directory, the do the compilation.

[...]

> I don't have makeinfo installed on this Solaris box, so it is
> running:

[...]

Perhaps, you need to update XEmacs elisp packages.

> It puts an "X-Draft-From:" header to my reply, but on top of all the
> headers, before the "To:" even. Could this be moved a bit further
> down?

For any particular reason?

> I second that the older "In-Reply-To:" format was nicer. I can get
> the information from the current format from the "References:" header
> already.

Simon said he fixed it.

ShengHuo

Re: Old bug reapqpearing in 5.8.8

[Colin Marquardt]

Hi,

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> Colin Marquardt <colin.marquardt@usa.alcatel.com> writes:
> 
> > The file with the most errors:
> > 
> > | While compiling rfc2047-encode-message-header in file /home/sw/cmarquar/emacs/gnus-CURRENT-20010116/lisp/rfc2047.el:
> > |   ** reference to free variable enable-multibyte-characters
> > | While compiling rfc2047-encode:
> > |   ** reference to free variable enable-multibyte-characters
> 
> Are you sure you compile them from a clean copy?

Pretty sure, yes. I just unpacked it today. I am running configure
with the options

--with-xemacs --prefix=/home/sw/cmarquar/emacs/gnus-CURRENT-20010116

where --prefix is the same directory where I unpacked it (I do not
have write access to the system directory). Is this dangerous in any
way?

I probably should also mention that this is a non-Mule XEmacs, 21.1.9.

> > | While compiling rfc2047-b-encode-region:
> > |   ** base64-encode-region called with 3 arguments, but accepts only 2
> 
> For XEmacs 21.1, you'd better copy base64.el from contrib directory to
> lisp directory, the do the compilation.

That fixed it, thanks.

> > I don't have makeinfo installed on this Solaris box, so it is
> > running:
> 
> [...]
> 
> Perhaps, you need to update XEmacs elisp packages.

Might be, I do not have the latest XEmacs. It's not really a problem
now, the texi file is fine.

> > It puts an "X-Draft-From:" header to my reply, but on top of all the
> > headers, before the "To:" even. Could this be moved a bit further
> > down?
> 
> For any particular reason?

For the only reason that I mentally connect importance with order,
and so an X-Header gets more importance than it needs.
User interface only, but for the same reason that we have
message-header-to-face and message-header-subject-face stand out
optically.

Cheers,
  Colin