[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: shell can't stand still
Re: shell can't stand still
Sun, 20 Mar 2005 02:31:04 +0100
Am 20.03.2005 um 01:21 schrieb Richard Stallman:
When in the *shell* buffer a running command produces output it's
impossible to scroll back using the page-up key. It seems as if the
last output lines are being subtracted from the amount of lines to
scroll up ...
In GNU Emacs 22.214.171.124 (powerpc-apple-darwin7.8.0, GTK+ Version
of 2005-03-16 on Latsche.local
That really surprises me. Once point is no longer at eob, it should
Can you provide a precise test case, starting from emacs -Q?
Yes, here is an easy example: start CVS Emacs with -Q, create a shell,
and make a new Emacs from CVS!
I did so. I waited till make's output hit the bottom and automatic
scrolling started since the cursor was kind of driven by the text
output and then I scrolled back with <prior> which is bound to
scroll-down. Text was scrolled down and the text cursor was placed on
the first (top-most) line in the first column. Then the text was by
some automatic means scrolled up, which made me scroll it down again
and so on. I could see that I came back to the place I left since it
had short lines
xrdb.c:92:1: warning: "malloc" redefined
In file included from config.h:941,
s/darwin.h:334:1: warning: this is the location of the previous
xrdb.c:93:1: warning: "realloc" redefined
s/darwin.h:335:1: warning: this is the location of the previous
xrdb.c:94:1: warning: "free" redefined
s/darwin.h:336:1: warning: this is the location of the previous
gcc -I/sw/include -L/sw/lib -c -fpascal-strings -fno-common -DMAC_OSX
-I../mac/src -I/sw/include -Demacs -DHAVE_CONFIG_H -DUSE
It was a ping-pong game between two positions. I too scrolled text up
by pressing <next> and the same effect happened: the text was scrolled
back, down. Repeatedly. Some of these scroll effects were a bit short
so that the region of short lines changed its position in the buffer
And there is another anomaly (close to a bug): I wanted by means of the
mouse (a trackpad actually, that is made by a software to work like a
mouse wheel when I hold down a key) to mark that region of short lines.
It did not work, because this marked up region scrolled up and down by
some single lines and it was quite hard to catch these movements. I
gave up when I only had one long line marked.
Something similiar to this happens when I mark a region and now come
close to the upper or lower ends of the buffer. Then the text scrolls
away, but much to fast so that I can't make a reasonable selection.
In usual Aqua applications of Mac OS X the scrolling effect is not as
big as wish, while in X it often seems to exaggerate. xset tells me
acceleration: 2/1 threshold: 4
which I can't classify since I don't remember what I else had ...
Since the compilation just ended I scrolled with my trackpad to the
end. At about 60% from top was the shell prompt. When I hit RET the
text 'jumped' to the bottom of this buffer. Is this normal? To me it
makes no sense to position the new shell prompt at the bottom -- some
text output from the launched application could happen and I wouldn't
In a world without walls and fences, who needs gates and windows?