unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Romain Francoise <romain@orebokech.com>
Subject: Re: scroll-conservatively overflow
Date: Fri, 16 Apr 2004 16:03:59 +0200	[thread overview]
Message-ID: <87vfk0auk0.fsf@orebokech.com> (raw)
In-Reply-To: m3smf46ozn.fsf@kfs-l.imdomain.dk

no-spam@cua.dk (Kim F. Storm) writes:

> I changed some things related to scroll a few days ago which may have
> made this more visible -- I don't know.

About scrolling: I've been bitten by a bug for some weeks now, I
originally thought it was specific to the multi-tty code but I
discovered this morning that it's not.  (A fresh checkout from CVS HEAD
this morning exhibited the same issues.)

I see it in two different situations:

 1. In Gnus, when I scroll a long article buffer (several pages) by
    repeatedly hitting RET to scroll one line at a time, scrolling stops
    on truncated lines.  For example, when I read an article that
    contains one very long line (e.g. a URL), it scrolls okay until the
    long line is the first line in the Article buffer.  I hit RET again
    and the first part of the line scrolls away.  I still see in the
    buffer the continuation part of the long (truncated) line, and if I
    hit RET again, nothing happens, it doesn't scroll more.  I have
    traced the call back in the Lisp code and it shows that the
    `scroll-up' builtin function returns nil as usual but doesn't have
    any effect on the buffer.  I can keep hitting RET to no avail.

    Scrolling works fine until the "End of buffer" message as usual when
    the article does not contain long lines; it also works fine if I
    resize the window so that lines don't get truncated.  It also works
    fine if I scroll past long lines in the article with SPC, then use
    RET to scroll one line at a time.

    This bug is reproducible in all instances of Emacs, at once.

 2. In Dired, I get "End of buffer" errors when moving over truncated
    lines, from the top to the bottom of a buffer (with `n').  For
    example, if my Dired buffer contains, in the middle of a long
    listing:

    -rw-r--r--    1 romain   romain       2047 Feb 26  2003 bpf_dump.c
    lrwxr-xr-x    1 romain   romain         22 Nov 11 12:26 bpf_filter.c -> ./bpf/net/bpf_filter.c
    -rw-r--r--    1 romain   romain       4966 Feb 26  2003 bpf_image.c

    (The middle line is truncated after "-> ./bp", I see:

     bpf_filter.c -> ./bp\
f/net/bpf_filter.c

    which might not be the case for you depending on your window width.)

    I move the cursor down to the `b' in "bpf_dump.c".  I then use `n'
    which moves the point to the `b' in "bpf_filter.c".  If I then use
    `n' to move down to the next line over the symlink line, the bell is
    rung, and I get a "End of buffer" message in the minibuffer, which
    is obviously wrong since the buffer continues..  After the error,
    the point is on the last `c' in "bpf_image.c", instead of being on
    the `b', but I think this is because of some Dired magic which gets
    confused by the error.

    The fun part is that it does not only happen in Dired buffers: in
    this very Message buffer where I'm composing this post, I can move up
    to the top with C-p, but when I move down to the bottom with C-n, I
    get an "End of buffer" error over the pasted Dired line.

    This bug does not appear in a fresh Emacs session just after I
    launch it, it appears only after I've used Emacs a bit.

This only happens in console frames, in X frames I never managed to
reproduce these bugs.  They are _very_ annoying since it makes the
display flash the bell every once in a while even though no error
occurred...

I can provide more information if needed.

-- 
Romain Francoise <romain@orebokech.com> | You know that old saying,
it's a miracle -- http://orebokech.com/ | that you always hurt the ones
                                        | you love? Well it works both
                                        | ways.

  reply	other threads:[~2004-04-16 14:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-16 10:00 scroll-conservatively overflow Juanma Barranquero
2004-04-16 13:17 ` Kim F. Storm
2004-04-16 14:03   ` Romain Francoise [this message]
2004-04-30 11:35     ` Romain Francoise
2004-04-30 16:38       ` Kim F. Storm
2004-05-01 17:50       ` Richard Stallman
2004-05-02 12:37         ` Romain Francoise
2004-05-02 16:58           ` Stefan Monnier
2004-05-03 14:03           ` Richard Stallman
2004-04-17 19:42   ` Richard Stallman
2004-04-17 20:52     ` Juanma Barranquero
2004-04-18 21:31       ` Kim F. Storm
2004-04-19 11:37       ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87vfk0auk0.fsf@orebokech.com \
    --to=romain@orebokech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).