XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop

XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop

[Paul Stodghill]

Recipe for disaster:

    milhouse$ uname -a
    CYGWIN_NT-5.0 MILHOUSE 1.3.1(0.38/3/2) 2001-04-24 20:01 i686 unknown
    milhouse$ xemacs -vanilla

    M-: (setq load-path (cons "/path/for/oort-gnus/" load-path))
    M-x load-library message
    M-x message-mail
    M-x filladapt-mode
    (insert the following in the body of the message)
    > this is some citation
    > text that needs to be filled.
    (now put the cursor on this text and press)
    M-q

XEmacs enters an infinite loop which cannot be broken with C-g.

For the ding list: Oort v0.03 and filladapt don't work together under
Cygwin XEmacs. This problem does not exist in 5.8.8.

For the xemacs-beta: It would be really nice if C-g broken out of the
loop. I realize that this may not be possible, though.


Further details

o Cygwin 1.3.1, most recent version of everything
o Oort Gnus v0.03
o xemacs-21.4.3 and xemacs-21.5-b1, up-to-date with pre-release packages.

If there are any other details that you need, please let me know.
---
Paul Stodghill <stodghil@cs.cornell.edu>
Dept. of Computer Science, Upson Hall, Ithaca, NY  14853
Phone: 607-254-8838   FAX: 607-255-4428
http://www.cs.cornell.edu/stodghil/

Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop

[Hrvoje Niksic]

Paul Stodghill <stodghil@cs.cornell.edu> writes:

> XEmacs enters an infinite loop which cannot be broken with C-g.
> 
> For the ding list: Oort v0.03 and filladapt don't work together under
> Cygwin XEmacs. This problem does not exist in 5.8.8.

I've been seeing this for some time, and it's been extremely annoying.
The infinite loop is a Gnus bug, or a filladapt bug triggered by Gnus
(but it used to work!)

However, the misfunctioning of C-g is an XEmacs bug under Cygwin.  On
Linux, C-g is able to interrupt the loop.

Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop

[Josh Huber]

Hrvoje Niksic <hniksic@arsdigita.com> writes:

> I've been seeing this for some time, and it's been extremely
> annoying.  The infinite loop is a Gnus bug, or a filladapt bug
> triggered by Gnus (but it used to work!)

Yes...

> However, the misfunctioning of C-g is an XEmacs bug under Cygwin.
> On Linux, C-g is able to interrupt the loop.

Yeah, I'm seeing this as well, and just as a side note M-q does work
if you place the point at the beginning of the block (first column).

ttyl,

-- 
Josh Huber

Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop

[Olivier Fambon]

Hrvoje Niksic wrote:
> 
...
> 
> However, the misfunctioning of C-g is an XEmacs bug under Cygwin.  On
> Linux, C-g is able to interrupt the loop.


It seems they are having troubles with signals at cygnus, at least with
blocking socket calls. Some might be fixed in the next DLL release.

See http://sources.redhat.com/ml/cygwin/2001-05/msg00570.html and 'a'
reply
    http://sources.redhat.com/ml/cygwin/2001-05/msg00752.html


In case it might avoid headaches...


A+O.

Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop

[Paul Stodghill]

> It seems they are having troubles with signals at cygnus, at least with
> blocking socket calls. Some might be fixed in the next DLL release.
> 
> See http://sources.redhat.com/ml/cygwin/2001-05/msg00570.html and 'a'
> reply
>     http://sources.redhat.com/ml/cygwin/2001-05/msg00752.html
> 
> 
> In case it might avoid headaches...

I just downloaded and tried cygwin1-20010519.dll and I am still unable to
C-g my problems away....

Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop

[Andy Piper]

At 11:15 AM 5/21/01 -0400, Paul Stodghill wrote:
> > It seems they are having troubles with signals at cygnus, at least with
> > blocking socket calls. Some might be fixed in the next DLL release.
> >
> > See http://sources.redhat.com/ml/cygwin/2001-05/msg00570.html and 'a'
> > reply
> >     http://sources.redhat.com/ml/cygwin/2001-05/msg00752.html
> >
> >
> > In case it might avoid headaches...
>
>I just downloaded and tried cygwin1-20010519.dll and I am still unable to
>C-g my problems away....

Try defining BROKEN_SIGIO in your s/cygwin32.h and see how that goes. It 
will enable C-g but led to random lockups last time I tried it. But we need 
a crash test dummy ....

andy

Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop

[Paul Stodghill]

> Try defining BROKEN_SIGIO in your s/cygwin32.h and see how that goes. It will
> enable C-g but led to random lockups last time I tried it. 

I installed and tried cygwin 1.3.2 (I presume that this has the signals
changes that were mentioned before). C-g still doesn't work.

I put "#define BROKEN_SIGIO" as the very first line in s/cygwin32.h, did a
"make clean ; make". C-g _still_ doesn't work.

> But we need a crash test dummy ....

I think that I'll put this on my resume. Yow!

Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop

[Paul Stodghill]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 3395 bytes --]

I managed to get a backtrace by sending HUP to a xemacs-21.5-b1 process
that was in an infloop. Here it is,

milhouse$ xemacs-21.5-b1

[1]+  Stopped                 xemacs-21.5-b1
milhouse$ bg
[1]+ xemacs-21.5-b1 &
milhouse$ kill -1 %1
milhouse$
Fatal error (1).

Your files have been auto-saved.
Use `M-x recover-session' to recover them.

If you have access to the PROBLEMS file that came with your
version of XEmacs, please check to see if your crash is described
there, as there may be a workaround available.
Otherwise, please report this bug by running the send-pr
script included with XEmacs, or selecting `Send Bug Report'
from the help menu.
As a last resort send ordinary email to `crashes@xemacs.org'.
*MAKE SURE* to include the information in the command
M-x describe-installation.

If at all possible, *please* try to obtain a C stack backtrace;
it will help us immensely in determining what went wrong.
To do this, locate the core file that was produced as a result
of this crash (it's usually called `core' and is located in the
directory in which you started the editor, or maybe in your home
directory), and type

  gdb /usr/local/bin/xemacs-21.5-b1.exe core

then type `where' when the debugger prompt comes up.
(If you don't have GDB on your system, you might have DBX,
or XDB, or SDB.  A similar procedure should work for all of
these.  Ask your system administrator if you need more help.)

Lisp backtrace follows:

  looking-at("--text follows this line--$\\|[   ]*$\\|-- $\\|---+$\\|^?$\\|.*wro
te:$\\|\\(\\([  ]*\\(\\w\\|[-_.]\\)+>+\\|[      ]*[]>»|:}+]\\)+\\)[     ]*$")
  # bind (quoted point beg end leading-space bolp not-break arg)
  message-newline-and-reformat(nil t)
  # bind (arg)
  message-fill-paragraph(nil)
  # bind (function fill-paragraph-function arg)
  #<compiled-function (arg) "...(54)" [function before end start arg fill-paragr
aph-function nil forward-paragraph newline 1 backward-paragraph fill-region fill
-region-as-paragraph use-hard-newlines] 5 1025528 (list (if current-prefix-arg .
..))>(nil)
  apply(#<compiled-function (arg) "...(54)" [function before end start arg fill-
paragraph-function nil forward-paragraph newline 1 backward-paragraph fill-regio
n fill-region-as-paragraph use-hard-newlines] 5 1025528 (list (if current-prefix
-arg ...))> nil)
  # bind (args function)
  filladapt-funcall(fill-paragraph nil)
  # bind (paragraph-ignore-fill-prefix adaptive-fill-mode adaptive-fill-regexp c
omment-multi-line fill-prefix retval)
  # (unwind-protect ...)
  byte-code("..." [function done retval sign delta fill-column nil t filladapt-a
dapt 1 0 filladapt-funcall filladapt-paragraph-within-fill-tolerance success run
-hooks filladapt-fill-paragraph-post-hook throw arg low high lim fill-prefix old
-fill-column filladapt-mode comment-multi-line adaptive-fill-regexp adaptive-fil
l-mode paragraph-ignore-fill-prefix filladapt-fill-column-tolerance filladapt-fi
ll-column-backward-fuzz filladapt-fill-column-forward-fuzz] 7)
  # (catch done ...)
  # bind (arg function)
  filladapt-fill-paragraph(fill-paragraph nil)
  # bind (filladapt-inside-filladapt arg)
  fill-paragraph(nil)
  # bind (command-debug-status)
  call-interactively(fill-paragraph)
  # bind (arg)
  fill-paragraph-or-region(nil)
  # bind (command-debug-status)
  call-interactively(fill-paragraph-or-region)
  # (condition-case ... . error)
  # (catch top-level ...)

critical quit Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop

[Ben Wing]

Paul Stodghill wrote:
> 
> Recipe for disaster:
> 
>     milhouse$ uname -a
>     CYGWIN_NT-5.0 MILHOUSE 1.3.1(0.38/3/2) 2001-04-24 20:01 i686 unknown
>     milhouse$ xemacs -vanilla
> 
>     M-: (setq load-path (cons "/path/for/oort-gnus/" load-path))
>     M-x load-library message
>     M-x message-mail
>     M-x filladapt-mode
>     (insert the following in the body of the message)
>     > this is some citation
>     > text that needs to be filled.
>     (now put the cursor on this text and press)
>     M-q
> 
> XEmacs enters an infinite loop which cannot be broken with C-g.
> 
> For the ding list: Oort v0.03 and filladapt don't work together under
> Cygwin XEmacs. This problem does not exist in 5.8.8.
> 
> For the xemacs-beta: It would be really nice if C-g broken out of the
> loop. I realize that this may not be possible, though.
> 
> Further details
> 
> o Cygwin 1.3.1, most recent version of everything
> o Oort Gnus v0.03
> o xemacs-21.4.3 and xemacs-21.5-b1, up-to-date with pre-release packages.
> 
> If there are any other details that you need, please let me know.

[1] i just reenabled BROKEN_SIGIO on cygwin and checked it in. [testing revealed
no lockups; last reported lockups were b21, which was ages ago.]
[2] "critical quit" C-Sh-g is supposed to break out of all loops, even those
where inhibit-quit is set; furthermore, it should give you an immediate
backtrace in all circumstances. [it's possible that someone broke this on unix. 
it was broken on windows until very recently.  can someone please verify whether
it works on unix?]
[3] if you can, please update to the latest xemacs 21.5 cvs on cygwin, and check
whether C-g works for you by typing (while t) in a scratch buffer, hitting C-j,
then C-g and/or C-Sh-g.

> ---
> Paul Stodghill <stodghil@cs.cornell.edu>
> Dept. of Computer Science, Upson Hall, Ithaca, NY  14853
> Phone: 607-254-8838   FAX: 607-255-4428
> http://www.cs.cornell.edu/stodghil/

-- 
ben

I'm sometimes slow in getting around to reading my mail, so if you
want to reach me faster, call 520-661-6661.

See http://www.666.com/ben/chronic-pain/ for the hell I've been
through.

Re: critical quit Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop

[Paul Stodghill]

Ben wrote,
> [3] if you can, please update to the latest xemacs 21.5 cvs on cygwin,
> and check whether C-g works for you by typing (while t) in a scratch
> buffer, hitting C-j, then C-g and/or C-Sh-g.

Partial success.

(while t) - C-g and C-Sh-g both work.

M-q in a "*message* buffer - C-g and C-Sh-g both work.

(let ((inhibit-quite t)) (while t) - Neither C-g now C-Sh-g work.

Ben, your changes are certainly an improvement. Thanks.

fill bug still there [Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop]

[Paul Stodghill]

The XEmacs people have made the changes so that C-g breaks out of the
infloop that happens as I have described in previous messages.

However, I never heard from any of the Gnus developers about what is
causing the infloop in the first place. Below is a backtrace that I was
able to obtain by killing an infloop'ing XEmacs.

I can't isolate the particular piece of code that is causing this bug.

Could people who know more than I please look at this.

Thank you.

> I managed to get a backtrace by sending HUP to a xemacs-21.5-b1 process
> that was in an infloop. Here it is,
> 
> milhouse$ xemacs-21.5-b1
> 
> [1]+  Stopped                 xemacs-21.5-b1
> milhouse$ bg
> [1]+ xemacs-21.5-b1 &
> milhouse$ kill -1 %1
> milhouse$
> Fatal error (1).
> 
> Your files have been auto-saved.
> Use `M-x recover-session' to recover them.
> 
> If you have access to the PROBLEMS file that came with your
> version of XEmacs, please check to see if your crash is described
> there, as there may be a workaround available.
> Otherwise, please report this bug by running the send-pr
> script included with XEmacs, or selecting `Send Bug Report'
> from the help menu.
> As a last resort send ordinary email to `crashes@xemacs.org'.
> *MAKE SURE* to include the information in the command
> M-x describe-installation.
> 
> If at all possible, *please* try to obtain a C stack backtrace;
> it will help us immensely in determining what went wrong.
> To do this, locate the core file that was produced as a result
> of this crash (it's usually called `core' and is located in the
> directory in which you started the editor, or maybe in your home
> directory), and type
> 
>   gdb /usr/local/bin/xemacs-21.5-b1.exe core
> 
> then type `where' when the debugger prompt comes up.
> (If you don't have GDB on your system, you might have DBX,
> or XDB, or SDB.  A similar procedure should work for all of
> these.  Ask your system administrator if you need more help.)
> 
> Lisp backtrace follows:
> 
>   looking-at("--text follows this line--$\\|[   ]*$\\|-- $\\|---+$\\|^?$\\|.*wro
> te:$\\|\\(\\([  ]*\\(\\w\\|[-_.]\\)+>+\\|[      ]*[]>>|:}+]\\)+\\)[     ]*$")
>   # bind (quoted point beg end leading-space bolp not-break arg)
>   message-newline-and-reformat(nil t)
>   # bind (arg)
>   message-fill-paragraph(nil)
>   # bind (function fill-paragraph-function arg)
>   #<compiled-function (arg) "...(54)" [function before end start arg fill-paragr
> aph-function nil forward-paragraph newline 1 backward-paragraph fill-region fill
> -region-as-paragraph use-hard-newlines] 5 1025528 (list (if current-prefix-arg .
> ..))>(nil)
>   apply(#<compiled-function (arg) "...(54)" [function before end start arg fill-
> paragraph-function nil forward-paragraph newline 1 backward-paragraph fill-regio
> n fill-region-as-paragraph use-hard-newlines] 5 1025528 (list (if current-prefix
> -arg ...))> nil)
>   # bind (args function)
>   filladapt-funcall(fill-paragraph nil)
>   # bind (paragraph-ignore-fill-prefix adaptive-fill-mode adaptive-fill-regexp c
> omment-multi-line fill-prefix retval)
>   # (unwind-protect ...)
>   byte-code("..." [function done retval sign delta fill-column nil t filladapt-a
> dapt 1 0 filladapt-funcall filladapt-paragraph-within-fill-tolerance success run
> -hooks filladapt-fill-paragraph-post-hook throw arg low high lim fill-prefix old
> -fill-column filladapt-mode comment-multi-line adaptive-fill-regexp adaptive-fil
> l-mode paragraph-ignore-fill-prefix filladapt-fill-column-tolerance filladapt-fi
> ll-column-backward-fuzz filladapt-fill-column-forward-fuzz] 7)
>   # (catch done ...)
>   # bind (arg function)
>   filladapt-fill-paragraph(fill-paragraph nil)
>   # bind (filladapt-inside-filladapt arg)
>   fill-paragraph(nil)
>   # bind (command-debug-status)
>   call-interactively(fill-paragraph)
>   # bind (arg)
>   fill-paragraph-or-region(nil)
>   # bind (command-debug-status)
>   call-interactively(fill-paragraph-or-region)
>   # (condition-case ... . error)
>   # (catch top-level ...)

Re: fill bug still there [Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop]

[Simon Josefsson]

Paul Stodghill <stodghil@cs.cornell.edu> writes:

> The XEmacs people have made the changes so that C-g breaks out of the
> infloop that happens as I have described in previous messages.
> 
> However, I never heard from any of the Gnus developers about what is
> causing the infloop in the first place. Below is a backtrace that I was
> able to obtain by killing an infloop'ing XEmacs.
> 
> I can't isolate the particular piece of code that is causing this bug.

If C-g works, could you M-x toggle-debug-on-quit RET before the
infloop, and get a better backtrace where this happens?  What are you
doing when it happens?  (Composing an article in message-mode?)

Re: fill bug still there [Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop]

[Kai Großjohann]

On 28 May 2001, Paul Stodghill wrote:

>>   looking-at("--text follows this line--$\\|[ ]*$\\|--
>>   $\\|---+$\\|^?$\\|.*wro
>> te:$\\|\\(\\([  ]*\\(\\w\\|[-_.]\\)+>+\\|[      ]*[]>>|:}+]\\)+\\)[     ]*$")
>>   # bind (quoted point beg end leading-space bolp not-break arg)
>>   message-newline-and-reformat(nil t)
>>   # bind (arg)
>>   message-fill-paragraph(nil)
>>   # bind (function fill-paragraph-function arg)
>>   #<compiled-function (arg) "...(54)" [function before end start arg fill-paragr
>> aph-function nil forward-paragraph newline 1 backward-paragraph fill-region fill
>> -region-as-paragraph use-hard-newlines] 5 1025528 (list (if current-prefix-arg .
>> ..))>(nil)
>>   apply(#<compiled-function (arg) "...(54)" [function before end start arg fill-
>> paragraph-function nil forward-paragraph newline 1 backward-paragraph fill-regio
>> n fill-region-as-paragraph use-hard-newlines] 5 1025528 (list (if current-prefix
>> -arg ...))> nil)
>>   # bind (args function)
>>   filladapt-funcall(fill-paragraph nil)

It seems that the lockup is caused by filladapt.  Does it go away when
you disable filladapt?  Or is filladapt always enabled in XEmacs?

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

Re: fill bug still there [Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop]

[Paul Stodghill]

> If C-g works, could you M-x toggle-debug-on-quit RET before the
> infloop, and get a better backtrace where this happens?  

A backtrace starting from looking-at is in a previous message from me.

> What are you doing when it happens? (Composing an article in
> message-mode?)

Yes.

Re: fill bug still there [Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop]

[Paul Stodghill]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 430 bytes --]

>>>>> "Kai" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

    Kai> It seems that the lockup is caused by filladapt. Does it go away
    Kai> when you disable filladapt? Or is filladapt always enabled in
    Kai> XEmacs?


It is filladapt related. Turning filladapt off in message mode fixes the
problem. 

HOWEVER, I have not that filladapt infloops in any other mode AND this
problem did not exist in v5.8.8.

Re: fill bug still there [Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop]

[Kai Großjohann]

On 29 May 2001, Paul Stodghill wrote:

> It is filladapt related. Turning filladapt off in message mode fixes
> the problem.

Ah, now we know where it is.

> HOWEVER, I have not that filladapt infloops in any other mode AND
> this problem did not exist in v5.8.8.

Well, on 2001-03-17 there was a change:

2001-03-17 10:00:00  ShengHuo ZHU  <zsh@cs.rochester.edu>

	* message.el (message-setup-fill-variables): Use
	fill-paragraph-function.
	(message-fill-paragraph): Take an argument.
	(message-newline-and-reformat): Take another argument.

I guess this was it, though I haven't tried.  Hm.  Ah.

(defun message-setup-fill-variables ()
  "Setup message fill variables."
  (set (make-local-variable 'fill-paragraph-function)
       'message-fill-paragraph)
  (make-local-variable 'paragraph-separate)
  ...)

What happens if you comment out the `set' statement at the beginning
of that function?  Does that help?

If that was it, then somebody else who really knows what's going on
ought to have a look at it.  I have no idea about filladapt.

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

Re: fill bug still there [Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop]

[Paul Stodghill]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 242 bytes --]

>>>>> "Kai" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

    Kai> What happens if you comment out the `set' statement at the
    Kai> beginning of that function? Does that help?

Bingo! The infloop'ing goes away. Thanks.

Re: critical quit Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop

[Ben Wing]

Paul Stodghill wrote:
> 
> Ben wrote,
> > [3] if you can, please update to the latest xemacs 21.5 cvs on cygwin,
> > and check whether C-g works for you by typing (while t) in a scratch
> > buffer, hitting C-j, then C-g and/or C-Sh-g.
> 
> Partial success.
> 
> (while t) - C-g and C-Sh-g both work.
> 
> M-q in a "*message* buffer - C-g and C-Sh-g both work.
> 
> (let ((inhibit-quite t)) (while t) - Neither C-g now C-Sh-g work.
> 
> Ben, your changes are certainly an improvement. Thanks.

actually, i also found this bug, and i'll soon be posting a patch.

[in the meantime, try holding down C-Sh-g, and you might get a break after
awhile]


-- 
ben

I'm sometimes slow in getting around to reading my mail, so if you
want to reach me faster, call 520-661-6661.

See http://www.666.com/ben/chronic-pain/ for the hell I've been
through.

Wow.

[Ken McGlothlen]

I've been using Gnu Emacs 19.34.1 and Gnus 5.6 for a long time now.  Years, at
least.

Well, I finally upgraded to XEmacs 21.1.14 and Gnus 5.8.8.

Cripes, this is cool.  Lars et al.:  Well done!

The only unfortunate thing is that I had to lose most of my .newsrc.eld file.
I couldn't get it started until I'd stripped down gnus-newsrc-alist,
gnus-killed-list and gnus-topic-alist down to a bare minimum of groups.  I'm
not sure why.  *And* xemacs is still taking up most of the memory on the
system.  "top" reports that xemacs-21.1.14 has SIZE = 93300K and RES = 54740K.
(Quite a shock, really; even Mozilla 0.9 has SIZE = 60384K and RES = 13988K.)

A plain ol' xemacs process takes up about 9MB, not 90MB.  So is Gnus really
sucking up this much memory?

And finally:  I'd like to resubscribe to newsgroups, but I'd like to do it,
say, 40 at a time or so rather than trying to plug in the entire active list.
Is there a convenient way of doing that?  I'm Lisp-literate, if that helps.

Re: Wow.

[Kai Großjohann]

On 30 May 2001, Ken McGlothlen wrote:

> And finally: I'd like to resubscribe to newsgroups, but I'd like to
> do it, say, 40 at a time or so rather than trying to plug in the
> entire active list.  Is there a convenient way of doing that?  I'm
> Lisp-literate, if that helps.

You could do `A z', `A k', and `A A' in that order until you see the
newsgroups you want.  Then, hit `u' on the ones you like and `C-k' on
the ones you don't like.  You can do this several times, each time for
a small number of groups.

Or is this not what you are after?

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

Re: Wow.

[Ken McGlothlen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

| You could do `A z', `A k', and `A A' in that order until you see the
| newsgroups you want.  Then, hit `u' on the ones you like and `C-k' on the
| ones you don't like.  You can do this several times, each time for a small
| number of groups.

Cool.  I never knew about the `A' commands before.  Very nice.  Thanks!

Now, does anyone know why `just-one-space' doesn't work when I'm composing a
message?  Or how I can get messages to display in their *raw* form?

Re: Wow.

[Kai Großjohann]

On 30 May 2001, Ken McGlothlen wrote:

> Now, does anyone know why `just-one-space' doesn't work when I'm
> composing a message?  Or how I can get messages to display in their
> *raw* form?

M-SPC works for me.  Use `C-u g' to display the raw msg.

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

Re: Wow.

[Steinar Bang]

>>>>> Ken McGlothlen <mcglk@artlogix.com>:

> The only unfortunate thing is that I had to lose most of my
> .newsrc.eld file.  I couldn't get it started until I'd stripped down
> gnus-newsrc-alist, gnus-killed-list and gnus-topic-alist down to a
> bare minimum of groups.  I'm not sure why.  *And* xemacs is still
> taking up most of the memory on the system.  "top" reports that
> xemacs-21.1.14 has SIZE = 93300K and RES = 54740K.  (Quite a shock,
> really; even Mozilla 0.9 has SIZE = 60384K and RES = 13988K.)

> A plain ol' xemacs process takes up about 9MB, not 90MB.  So is Gnus
> really sucking up this much memory?

Do you have any old nnml groups with sparse article numbers?  I saw
someone write something about the fact that expanding ranges in emacs,
cost a lot of memory.  It is very slow, at least.

Re: Wow.

[Ken McGlothlen]

Steinar Bang <sb@metis.no> writes:

| >>>>> Ken McGlothlen <mcglk@artlogix.com>:
| 
| > A plain ol' xemacs process takes up about 9MB, not 90MB.  So is Gnus
| > really sucking up this much memory?
| 
| Do you have any old nnml groups with sparse article numbers?  I saw
| someone write something about the fact that expanding ranges in emacs,
| cost a lot of memory.  It is very slow, at least.

Yeah, I think I do.  But would old nntp groups with sparse article numbers do
the same thing?  And is there a way to easily correct for that without having
to forward them though the mail system again?