Buffer Boundary Problem

Buffer Boundary Problem

[Vinicius Jose Latorre]

Hi,


I'm using:

(setq default-indicate-buffer-boundaries t)

And I'm liking the buffer boundaries indication.

But it has a problem, suppose you're visiting a file bigger than the 
window in
Emacs.  So, the vertical scroll bar looks like:
    _
   |^|
   | |
   | |
   | |
   | |
   | |
   |v|
    -

Now, type several C-n (next-line) until the window scrolls up.

The vertical scroll bar now looks like:
    _
   |^|
   | |
   | |
   |v|
   | |
   | |
   |v|
    -

Or, sometimes, like:
    _
   | |
   | |
   | |
   |v|
   | |
   | |
   |v|
    -

I've just downloaded Emacs (via cvs) and bootstrap it today (2004-jan-31).

Am I doing something wrong?


Vinicius

Re: Buffer Boundary Problem

[Miles Bader]

On Sat, Jan 31, 2004 at 09:14:27PM -0200, Vinicius Jose Latorre wrote:
> But it has a problem, suppose you're visiting a file bigger than the window
> in Emacs.  So, the vertical scroll bar looks like:
...
> Now, type several C-n (next-line) until the window scrolls up.
> The vertical scroll bar now looks like:

By `it' I presume you mean the scrollbars have a problem, and that you're
using GTK scrollbars.

If so, the problem is that the GTK scrollbars are missing some functionality
that emacs needs to work optimally, so as a work-around emacs scrollbars are
little funny near the end of a buffer.  Basically there's some extra space
at the end so you can use the scrollbar to scroll the last line to the top
of the window.

[While I understand the reason for this problem, I wonder if it might be
useful to have a variable which controls that behavior -- by setting it to a
different value, you could make scrollbars display `correctly' but lose the
ability to scroll the last line to the window top... is this possible?]

-Miles
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: Buffer Boundary Problem

[Jan D.]

> [While I understand the reason for this problem, I wonder if it might 
> be
> useful to have a variable which controls that behavior -- by setting 
> it to a
> different value, you could make scrollbars display `correctly' but 
> lose the
> ability to scroll the last line to the window top... is this possible?]

Yes, in fact it is trivial, since it is the normal behaviour that GTK
expects.  Wan't me to implement that?

	Jan D.

Re: Buffer Boundary Problem

[Vinicius Jose Latorre]

Miles Bader wrote:

 >On Sat, Jan 31, 2004 at 09:14:27PM -0200, Vinicius Jose Latorre wrote:
 >
 >>But it has a problem, suppose you're visiting a file bigger than the 
window
 >>in Emacs.  So, the vertical scroll bar looks like:
 >
 >...
 >
 >>Now, type several C-n (next-line) until the window scrolls up.
 >>The vertical scroll bar now looks like:
 >
 >
 >By `it' I presume you mean the scrollbars have a problem, and that you're
 >using GTK scrollbars.

Yes, the vertical scrollbar.  And, also, I'm using GTK.


Vinicius

Re: Buffer Boundary Problem

[Vinicius Jose Latorre]

 > > [While I understand the reason for this problem, I wonder if it 
might be
 > > useful to have a variable which controls that behavior -- by 
setting it to a
 > > different value, you could make scrollbars display `correctly' but 
lose the
 > > ability to scroll the last line to the window top... is this possible?]
 >
 >
 > Yes, in fact it is trivial, since it is the normal behaviour that GTK
 > expects.  Wan't me to implement that?

Well, I'll be pleased if you could implement it.

Thanks,

Vinicius

Re: Buffer Boundary Problem

[Matt Hodges]

>>>>> Vinicius Jose Latorre writes:

 > >By `it' I presume you mean the scrollbars have a problem, and that
 > >you're using GTK scrollbars.

 > Yes, the vertical scrollbar. And, also, I'm using GTK.

I tried what you described in your original post, and thought you were
talking about the glyphs in the fringe. I also see either two down
arrows, or sometimes two down and one up; this changes to one up arrow
and one down arrow with C-l, which is what I expect to see.

This seems to be the case with or without scrollbars, at least for a
GTK build.

Matt

Re: Buffer Boundary Problem

[Jan D.]

Hello.

Please send some more information about your setup, are you using GTK, Motif, 
or whatever, native scrollbars or not, if you are using GTK, what theme, does 
the problem only show with default-indicate-buffer-boundaries set to t.

I can not reproduce this.

	Jan D.

Vinicius Jose Latorre wrote:

> I'm using:
> 
> (setq default-indicate-buffer-boundaries t)
> 
> And I'm liking the buffer boundaries indication.
> 
> But it has a problem, suppose you're visiting a file bigger than the 
> window in
> Emacs.  So, the vertical scroll bar looks like:
>    _
>   |^|
>   | |
>   | |
>   | |
>   | |
>   | |
>   |v|
>    -
> 
> Now, type several C-n (next-line) until the window scrolls up.
> 
> The vertical scroll bar now looks like:
>    _
>   |^|
>   | |
>   | |
>   |v|
>   | |
>   | |
>   |v|
>    -
> 
> Or, sometimes, like:
>    _
>   | |
>   | |
>   | |
>   |v|
>   | |
>   | |
>   |v|
>    -
> 
> I've just downloaded Emacs (via cvs) and bootstrap it today (2004-jan-31).
> 
> Am I doing something wrong?
> 
> 
> Vinicius
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Buffer Boundary Problem

[Jan D.]

Matt Hodges wrote:
>>>>>>Vinicius Jose Latorre writes:
> 
> 
>  > >By `it' I presume you mean the scrollbars have a problem, and that
>  > >you're using GTK scrollbars.
> 
>  > Yes, the vertical scrollbar. And, also, I'm using GTK.
> 
> I tried what you described in your original post, and thought you were
> talking about the glyphs in the fringe. I also see either two down
> arrows, or sometimes two down and one up; this changes to one up arrow
> and one down arrow with C-l, which is what I expect to see.
> 
> This seems to be the case with or without scrollbars, at least for a
> GTK build.

Can you elaborate?  What are those arrows if it also happens without 
scrollbars?  Not scrollbar arrows, but what?

	Jan D.

Re: Buffer Boundary Problem

[Jan D.]

Jan D. wrote:
> Matt Hodges wrote:
> 
>>>>>>> Vinicius Jose Latorre writes:
>>
>>
>>
>>  > >By `it' I presume you mean the scrollbars have a problem, and that
>>  > >you're using GTK scrollbars.
>>
>>  > Yes, the vertical scrollbar. And, also, I'm using GTK.
>>
>> I tried what you described in your original post, and thought you were
>> talking about the glyphs in the fringe. I also see either two down
>> arrows, or sometimes two down and one up; this changes to one up arrow
>> and one down arrow with C-l, which is what I expect to see.
>>
>> This seems to be the case with or without scrollbars, at least for a
>> GTK build.
> 
> 
> Can you elaborate?  What are those arrows if it also happens without 
> scrollbars?  Not scrollbar arrows, but what?


Oh, now I get it.  Its the arrows in the fringes.  I didn't even see them 
first.  Anyway, it is unrelated to scrollbars, I see the same effect for Motif, 
Lesstif, Lucid and Xaw(3d) scroll bars.   However, I can not find any code that 
clear the fringes, just draws, so it is not surprising that you get an arrow in 
the middle sometimes.  It is the arrow that was at the bottom that has been 
moved up, and since fringes are not cleared before redrawn, it stays.

BTW, how come you can do C-h v default-indicate-buffer-boundaries, but not M-x 
set-variable default-indicate-buffer-boundaries?

	Jan D.

Re: Buffer Boundary Problem

[Vinicius Jose Latorre]

 >  > >By `it' I presume you mean the scrollbars have a problem, and that
 >  > >you're using GTK scrollbars.
 >
 >  > Yes, the vertical scrollbar. And, also, I'm using GTK.
 >
 > I tried what you described in your original post, and thought you were
 > talking about the glyphs in the fringe. I also see either two down
 > arrows, or sometimes two down and one up; this changes to one up arrow
 > and one down arrow with C-l, which is what I expect to see.

The problem seems to happen only with C-n, with C-l, C-v, M-v and C-p the
glyphs are ok.


Vinicius

Re: Buffer Boundary Problem

[Kim F. Storm]

Matt Hodges <matt@tc.bham.ac.uk> writes:

> >>>>> Vinicius Jose Latorre writes:
> 
>  > >By `it' I presume you mean the scrollbars have a problem, and that
>  > >you're using GTK scrollbars.
> 
>  > Yes, the vertical scrollbar. And, also, I'm using GTK.
> 
> I tried what you described in your original post, and thought you were
> talking about the glyphs in the fringe. I also see either two down
> arrows, or sometimes two down and one up; this changes to one up arrow
> and one down arrow with C-l, which is what I expect to see.
> 

I'm working on a fix for the "duplicate up/down arrow problem".

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Buffer Boundary Problem

[Kim F. Storm]

"Jan D." <jan.h.d@swipnet.se> writes:

> Oh, now I get it.  Its the arrows in the fringes.  I didn't even see
> them first.  Anyway, it is unrelated to scrollbars, I see the same
> effect for Motif, Lesstif, Lucid and Xaw(3d) scroll bars.   However, I
> can not find any code that clear the fringes, just draws, so it is not
> surprising that you get an arrow in the middle sometimes.  It is the
> arrow that was at the bottom that has been moved up, and since fringes
> are not cleared before redrawn, it stays.

It is true that fringes are not cleared before they are redrawn, as
the redisplay code tries to minimize the amount of redrawing -- so it
actually tries to remember which bitmaps are currently in the fringe
and only delete them if they are no longer needed at a certain
position.

The problem with the extra arrows is that some scrolling operations
work directly on the existing glyph matrix, so extra care is needed to
clean-up the fringe bitmaps that are scrolled with the text.

Since there are several such optimizations in the redisplay code, the
fringe redisplay code also need to be aware of those optimizations.
Currently there are some corner cases which it fails to handle.

++kfs