bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gnus summary buffer downloading gets stuck with process marked articles


From: Daniel Ortmann
Subject: gnus summary buffer downloading gets stuck with process marked articles
Date: 28 Nov 2001 19:13:45 -0600

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the address@hidden mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.1.2 (i386--freebsd, X toolkit, Xaw3d scroll bars)
 of 2001-11-19 on pyrl.eye
configured using `configure  --prefix=/usr/local i386--freebsd'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Steps:

- enter emacs and gnus
- enter any group with at least several articles
- M P b to mark the whole buffer, or hit # several times
- press o to download the marked articles
- after one article finishes downloading and the next starts up, press
  C-g to interrupt the download
- then press o to restart the download

Results:

About 30-50% of the time the download of the next article seems to
procede but gets stuck at (apparently) about the size of the old
interrupted article + the size of the new article.

If you don't see the behavior then just retry a few times.

Workaround:

After it gets stuck, pressing C-g a second time and then o a second time
virtually always restarts the download of the process-marked articles.

Expected:

I expected that the C-g would be caught in some event handler and gnus
consistently put into a useable download state.  The need to do a second
C-g and o seems bad, especially since emacs handles bad events so well.

This behavior also occurred in previous emacs/gnus versions.

Recent input:
M-x r e p o r TAB RET

Recent messages:
Loading image...done
Loading time...done
Loading /usr/local/libexec/emacs/21.1/i386--freebsd/fns-21.1.2.el 
(source)...done
Loading font-lock...
Loading regexp-opt...done
Loading font-lock...done
Loading jka-compr...done
Loading server...done
Loading hscroll...done
Loading emacsbug...done

-- 
Daniel Ortmann, 2414 30 Av NW, #D, Rochester, MN 55901
address@hidden (h)   / 507.288.7732 (h)
address@hidden (w) / 507.529.3887 (w)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]