bug#18990: 25.0.50; Scroll bar display problems

bug#18990: 25.0.50; Scroll bar display problems

[Stephen Berman]

[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]

Starting Emacs like this:

emacs -Q --eval "(progn (modify-all-frames-parameters '((scroll-bar-width . 7))) (custom-set-variables '(scroll-bar-mode (quote left))))"

the scroll bar is correctly display on the left, but its width is the
default, not the customized value, and it overlays the left fringe,
which is hence hidden.

If another X window is moved over the Emacs frame (at least the left
side including the scroll bar), the left fringe becomes visible (only
partly if the other X window is not moved across the whole height of the
fringe) and the scroll bar width is correspondingly narrower (I didn't
measure but it looks like the width specified above); see the attached
screen shot, which also shows the incorrect scroll bar width and hidden
left fringe in the top Emacs frame.  As soon as the lower Emacs frame
regains focus, the scroll bar returns to full width and overlays the
left fringe again.

Another display glitch conditioned by the above settings is that typing
until point or eol enters the right fringe causes the left fringe in
just the current line to become visible (and the scroll bar
correspondingly narrowed/truncated in that line); I have not succeeded
in getting a screen shot of this glitch.

These display problems do not happen when the scroll bar is either on
the right or has its default width.  They also don't happen with the
non-toolkit-scroll-bar build.  They do happen with 24.3, the earliest
version I currently have (I don't have a non-toolkit-scroll-bar build of
24.4 at hand but I guess it also has the problems).  (I haven't noticed
these problems before, since I've been using non-toolkit-scroll-bar
builds for a long time, and only since the 24.4 release have switched to
the toolkit scroll bar on the trunk to be able to test the horizontal
scroll bar.)

In GNU Emacs 25.0.50.3 (x86_64-suse-linux-gnu, GTK+ Version 3.10.9)
 of 2014-11-07 on rosalinde
Repository revision: 118312 monnier@iro.umontreal.ca-20141107162535-aiv2ipzik768ih1t
Windowing system distributor `The X.Org Foundation', version 11.0.11403901
System Description:	openSUSE 13.1 (Bottle) (x86_64)

Configured using:
 `configure 'CFLAGS=-g3 -O0''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS NOTIFY
GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB


[-- Attachment #2: Scroll bar display problems --]
[-- Type: image/png, Size: 62063 bytes --]

bug#18990: 25.0.50; Scroll bar display problems

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Sat, 08 Nov 2014 00:00:20 +0100
> 
> Starting Emacs like this:
> 
> emacs -Q --eval "(progn (modify-all-frames-parameters '((scroll-bar-width . 7))) (custom-set-variables '(scroll-bar-mode (quote left))))"
> 
> the scroll bar is correctly display on the left, but its width is the
> default, not the customized value, and it overlays the left fringe,
> which is hence hidden.
> 
> If another X window is moved over the Emacs frame (at least the left
> side including the scroll bar), the left fringe becomes visible (only
> partly if the other X window is not moved across the whole height of the
> fringe) and the scroll bar width is correspondingly narrower (I didn't
> measure but it looks like the width specified above); see the attached
> screen shot, which also shows the incorrect scroll bar width and hidden
> left fringe in the top Emacs frame.  As soon as the lower Emacs frame
> regains focus, the scroll bar returns to full width and overlays the
> left fringe again.
> 
> Another display glitch conditioned by the above settings is that typing
> until point or eol enters the right fringe causes the left fringe in
> just the current line to become visible (and the scroll bar
> correspondingly narrowed/truncated in that line); I have not succeeded
> in getting a screen shot of this glitch.
> 
> These display problems do not happen when the scroll bar is either on
> the right or has its default width.  They also don't happen with the
> non-toolkit-scroll-bar build.  They do happen with 24.3, the earliest
> version I currently have (I don't have a non-toolkit-scroll-bar build of
> 24.4 at hand but I guess it also has the problems).  (I haven't noticed
> these problems before, since I've been using non-toolkit-scroll-bar
> builds for a long time, and only since the 24.4 release have switched to
> the toolkit scroll bar on the trunk to be able to test the horizontal
> scroll bar.)

Sounds like a GTK thing to me.  Does this happen if you use a
different toolkit, like lucid or athena?

bug#18990: 25.0.50; Scroll bar display problems

[Jan D.]

Hi.

> 8 nov 2014 kl. 08:54 skrev Eli Zaretskii <eliz@gnu.org>:
> 
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Sat, 08 Nov 2014 00:00:20 +0100
>> 
>> Starting Emacs like this:
>> 
>> emacs -Q --eval "(progn (modify-all-frames-parameters '((scroll-bar-width . 7))) (custom-set-variables '(scroll-bar-mode (quote left))))"
>> 
>> the scroll bar is correctly display on the left, but its width is the
>> default, not the customized value, and it overlays the left fringe,
>> which is hence hidden.
>> 
>> If another X window is moved over the Emacs frame (at least the left
>> side including the scroll bar), the left fringe becomes visible (only
>> partly if the other X window is not moved across the whole height of the
>> fringe) and the scroll bar width is correspondingly narrower (I didn't
>> measure but it looks like the width specified above); see the attached
>> screen shot, which also shows the incorrect scroll bar width and hidden
>> left fringe in the top Emacs frame.  As soon as the lower Emacs frame
>> regains focus, the scroll bar returns to full width and overlays the
>> left fringe again.
>> 
>> Another display glitch conditioned by the above settings is that typing
>> until point or eol enters the right fringe causes the left fringe in
>> just the current line to become visible (and the scroll bar
>> correspondingly narrowed/truncated in that line); I have not succeeded
>> in getting a screen shot of this glitch.
>> 
>> These display problems do not happen when the scroll bar is either on
>> the right or has its default width.  They also don't happen with the
>> non-toolkit-scroll-bar build.  They do happen with 24.3, the earliest
>> version I currently have (I don't have a non-toolkit-scroll-bar build of
>> 24.4 at hand but I guess it also has the problems).  (I haven't noticed
>> these problems before, since I've been using non-toolkit-scroll-bar
>> builds for a long time, and only since the 24.4 release have switched to
>> the toolkit scroll bar on the trunk to be able to test the horizontal
>> scroll bar.)
> 
> Sounds like a GTK thing to me.  Does this happen if you use a
> different toolkit, like lucid or athena?

Some Gtk+ themes force a fixed width scrollbar, because they use bitmaps.
Emacs can set scroll bar width all it wants, it wont matter to the Gtk+ scroll bar.
It is difficult to solve. 

	Jan D.

bug#18990: 25.0.50; Scroll bar display problems

[Stephen Berman]

[-- Attachment #1: Type: text/plain, Size: 3767 bytes --]

On Sat, 8 Nov 2014 09:57:59 +0100 "Jan D." <jan.h.d@swipnet.se> wrote:

> Hi.
>
>> 8 nov 2014 kl. 08:54 skrev Eli Zaretskii <eliz@gnu.org>:
>> 
>>> From: Stephen Berman <stephen.berman@gmx.net>
>>> Date: Sat, 08 Nov 2014 00:00:20 +0100
>>> 
>>> Starting Emacs like this:
>>> 
>>> emacs -Q --eval "(progn (modify-all-frames-parameters '((scroll-bar-width
>>> . 7))) (custom-set-variables '(scroll-bar-mode (quote left))))"
>>> 
>>> the scroll bar is correctly display on the left, but its width is the
>>> default, not the customized value, and it overlays the left fringe,
>>> which is hence hidden.
[...]
>> 
>> Sounds like a GTK thing to me.  Does this happen if you use a
>> different toolkit, like lucid or athena?

Trying to build with the Lucid toolkit errors out when trying to link
with libpng16, which I think is required here for the Gtk3 build to
succeed (at least I remember having this problem in the past, but I
haven't pursued it since I generally prefer the Gtk build anyway).

> Some Gtk+ themes force a fixed width scrollbar, because they use bitmaps.
> Emacs can set scroll bar width all it wants, it wont matter to the Gtk+ scroll bar.
> It is difficult to solve. 

The problem occurs with both Gtk+ themes I currently have on my system;
however, it is evidently not due to the scroll bar's width being fixed
(at least for Emacs), see below.

On Sat, 08 Nov 2014 09:54:27 +0100 martin rudalics <rudalics@gmx.at> wrote:

> There are two ways to change the width or height of a scroll bar with
> GTK: Either by choosing an appropriate theme or by setting the
> slider-width in a configuration file.  You can't change the size
> individually from within Emacs and IMO we should prevent users from
> trying to do so.  What happens currently is that Emacs internally uses
> the height you specified and GTK continues to draw the scroolbar in its
> default size over it.

This is not what I observe: I have no setting for the scroll bar in a
Gtk config file, but when I start emacs with -Q --eval
"(modify-all-frames-parameters '((scroll-bar-width . 7)))", then the
scroll bar is displayed thin on the right, unlike when I make it be on
the left, and the right fringe is not overlaid by the scroll bar like the
left fringe is; see the attached screen shot.  The thin scroll bar looks
crappy and clearly is not being properly modified as a toolkit widget,
but just as clearly Emacs is able to modify it.  I guess the easiest
solution would be to make modifying the Gtk scroll bar a noop.

>> These display problems do not happen when the scroll bar is either on
>> the right or has its default width.
>
> There are similar problems, for example, with side-by-side windows.

I hadn't noticed this before, but the attached screen shot confirms it.
Interestingly, the right fringe of the left window is not hidden.

>> They also don't happen with the
>> non-toolkit-scroll-bar build.  They do happen with 24.3, the earliest
>> version I currently have (I don't have a non-toolkit-scroll-bar build of
>> 24.4 at hand but I guess it also has the problems).
>
> Non-GTK scroll bars should not have any such problems.
>
>> (I haven't noticed
>> these problems before, since I've been using non-toolkit-scroll-bar
>> builds for a long time, and only since the 24.4 release have switched to
>> the toolkit scroll bar on the trunk to be able to test the horizontal
>> scroll bar.)
>
> The GTK horizontal scroll bar has similar problems.

Do you mean that the above invocation should also make the horizontal
scroll bar thinner? (Does it with the Lucid build?)  If so, then I can
confirm that it isn't thinner for me; but I haven't seen any display
glitches either with the horizontal scroll bar like I have with the
vertical scroll bar on the left.

Steve Berman


[-- Attachment #2: Scroll bar bug --]
[-- Type: image/png, Size: 40549 bytes --]

bug#18990: 25.0.50; Scroll bar display problems

[martin rudalics]

 > This is not what I observe: I have no setting for the scroll bar in a
 > Gtk config file, but when I start emacs with -Q --eval
 > "(modify-all-frames-parameters '((scroll-bar-width . 7)))", then the
 > scroll bar is displayed thin on the right, unlike when I make it be on
 > the left, and the right fringe is not overlaid by the scroll bar like the
 > left fringe is; see the attached screen shot.  The thin scroll bar looks
 > crappy and clearly is not being properly modified as a toolkit widget,

In the attached screenshot the left scroll bar is displayed in its
default width (you didn't tell us that value so far) partially
overlaying the left fringe of the window on the right.  The right scroll
bar is cropped at the external border (by the window manager).

 > but just as clearly Emacs is able to modify it.

You mean that Emacs can move the slider?

 > I guess the easiest
 > solution would be to make modifying the Gtk scroll bar a noop.

The width and the height, yes.  The position can be modified without
problems.

 > I hadn't noticed this before, but the attached screen shot confirms it.
 > Interestingly, the right fringe of the left window is not hidden.

Emacs tells Gtk where to put it.  Make `scroll-bar-width' very wide and
you should be able to see how Gtk reacts.

 > Do you mean that the above invocation should also make the horizontal
 > scroll bar thinner?

No.  The corresponding frame parameter is called `scroll-bar-height'.
Some systems allow different values for height and width of scroll bars.

 >(Does it with the Lucid build?)  If so, then I can
 > confirm that it isn't thinner for me; but I haven't seen any display
 > glitches either with the horizontal scroll bar like I have with the
 > vertical scroll bar on the left.

I think you need Xaw3d support for Lucid scroll bars.  Both Lucid and
Motif scroll bars can be arbitrarily resized here.

martin

bug#18990: 25.0.50; Scroll bar display problems

[Stephen Berman]

On Sat, 08 Nov 2014 16:14:31 +0100 martin rudalics <rudalics@gmx.at> wrote:

>> This is not what I observe: I have no setting for the scroll bar in a
>> Gtk config file, but when I start emacs with -Q --eval
>> "(modify-all-frames-parameters '((scroll-bar-width . 7)))", then the
>> scroll bar is displayed thin on the right, unlike when I make it be on
>> the left, and the right fringe is not overlaid by the scroll bar like the
>> left fringe is; see the attached screen shot.  The thin scroll bar looks
>> crappy and clearly is not being properly modified as a toolkit widget,
>
> In the attached screenshot the left scroll bar is displayed in its
> default width (you didn't tell us that value so far)

With -Q (frame-parameters) includes this: (scroll-bar-width . 16).  With
the above invocation (frame-parameters) instead has (scroll-bar-width . 7).

>                                                      partially
> overlaying the left fringe of the window on the right.

Ah, indeed.  I hadn't noticed that, only that the right fringe of the
left window is not hidden.

>                                                         The right scroll
> bar is cropped at the external border (by the window manager).

That possibility didn't occur to me.  Is there some command I can call,
or some other way to convince myself that this is what is happening (not
that I don't believe you, I'd just like to understand it).  And why does
it happen on the right but not on the left (nor on the right side of a
non-right window)?

>> but just as clearly Emacs is able to modify it.
>
> You mean that Emacs can move the slider?

I meant Emacs can make it thinner, since it didn't occur to me that the
appearance of the right scroll bar could be due to the WM.

>> I guess the easiest
>> solution would be to make modifying the Gtk scroll bar a noop.
>
> The width and the height, yes.  The position can be modified without
> problems.

Of course, I only meant the width (also the height of the horizontal
scroll bar).

>> I hadn't noticed this before, but the attached screen shot confirms it.
>> Interestingly, the right fringe of the left window is not hidden.
>
> Emacs tells Gtk where to put it.  Make `scroll-bar-width' very wide and
> you should be able to see how Gtk reacts.

Indeed: with (modify-all-frames-parameters '((scroll-bar-width . 32)))
the scroll bar still has the default width but there are nearly equally
wide spaces on both sides of it (between the scroll and the fringe to
the left and between the scroll bar and the frame border to the right).
Ok, this convinces me that Emacs is not modifying the width.

>> Do you mean that the above invocation should also make the horizontal
>> scroll bar thinner?
>
> No.  The corresponding frame parameter is called `scroll-bar-height'.
> Some systems allow different values for height and width of scroll bars.

Ah, ok. With -Q and the horizontal scroll bar enabled,
(frame-parameters) shows (scroll-bar-height . 16), and with -Q --eval
"(modify-all-frames-parameters '((scroll-bar-height . 7)))"
(frame-parameters) shows (scroll-bar-height . 7), but the horizontal
scroll bar is not thinner than with -Q, however, it partially obscures
the mode line, which is even worse than the display problem with the
vertical scroll bar on the left.

>>(Does it with the Lucid build?)  If so, then I can
>> confirm that it isn't thinner for me; but I haven't seen any display
>> glitches either with the horizontal scroll bar like I have with the
>> vertical scroll bar on the left.
>
> I think you need Xaw3d support for Lucid scroll bars.  Both Lucid and
> Motif scroll bars can be arbitrarily resized here.

As I mentioned, I can't simply build both the Lucid and the Gtk builds
on my system, apparently due to incompatible libpng requirements.

Anyway, it seems that the appropriate fix for this bug it to make
modifying the scroll-bar-width and scroll-bar-height frame parameters
noops in Gtk builds.

Steve Berman

bug#18990: 25.0.50; Scroll bar display problems

[martin rudalics]

 > That possibility didn't occur to me.  Is there some command I can call,
 > or some other way to convince myself that this is what is happening (not
 > that I don't believe you, I'd just like to understand it).

I suppose the window manager simply crops everything that doesn't fit
within its external borders.  You should be able to convince yourself
for a single window frame by removing modeline and echo area and
decreasing the height of the horizontal scroll bar.

 > And why does
 > it happen on the right but not on the left (nor on the right side of a
 > non-right window)?

It doesn't happen on the left or for non-right windows because in this
case the (default sized) scroll bar gets drawn into Emacs' client area
and the window manager assumes that Emacs knows how to deal with it.

 > I meant Emacs can make it thinner, since it didn't occur to me that the
 > appearance of the right scroll bar could be due to the WM.

We must discriminate: Emacs reserves the area as you specify it.  Gtk
draws its slider into that area alas with a width determined by the
theme or a resource file.

 > Indeed: with (modify-all-frames-parameters '((scroll-bar-width . 32)))
 > the scroll bar

... more precisely, the slider ...

 > still has the default width but there are nearly equally
 > wide spaces on both sides of it (between the scroll and the fringe to
 > the left and between the scroll bar and the frame border to the right).
 > Ok, this convinces me that Emacs is not modifying the width.

... the width of the slider.

 > As I mentioned, I can't simply build both the Lucid and the Gtk builds
 > on my system, apparently due to incompatible libpng requirements.

Maybe Jan has an idea.

 > Anyway, it seems that the appropriate fix for this bug it to make
 > modifying the scroll-bar-width and scroll-bar-height frame parameters
 > noops in Gtk builds.

Another problem is that currently we prescribe a minimum width for
scroll bars which has parts of the scroll bar background change
appearance when the Gtk slider is narrower.

martin

bug#18990: 25.0.50; Scroll bar display problems

[Jan D.]

Hi.

> 8 nov 2014 kl. 18:00 skrev martin rudalics <rudalics@gmx.at>:
> 
> > As I mentioned, I can't simply build both the Lucid and the Gtk builds
> > on my system, apparently due to incompatible libpng requirements.
> 
> Maybe Jan has an idea.

No, I build both no X, no toolkit, Lucid, Motif, Gtk2+ and Gtk3+ all the time.  I have never had any libpng-problem.  Why not build Lucid --without-png?

	Jan D.

bug#18990: 25.0.50; Scroll bar display problems

[Stephen Berman]

On Sat, 8 Nov 2014 18:21:42 +0100 "Jan D." <jan.h.d@swipnet.se> wrote:

> Hi.
>
>> 8 nov 2014 kl. 18:00 skrev martin rudalics <rudalics@gmx.at>:
>> 
>> > As I mentioned, I can't simply build both the Lucid and the Gtk builds
>> > on my system, apparently due to incompatible libpng requirements.
>> 
>> Maybe Jan has an idea.
>
> No, I build both no X, no toolkit, Lucid, Motif, Gtk2+ and Gtk3+ all the time.
> I have never had any libpng-problem.  Why not build Lucid --without-png?

That did the trick; thanks for the suggestion.  (Silly of me for not
thinking of it myself.)  So I can now confirm that the problem is indeed
only with the Gtk build.

Steve Berman

bug#18990: 25.0.50; Scroll bar display problems

[Stephen Berman]

On Sat, 08 Nov 2014 18:00:43 +0100 martin rudalics <rudalics@gmx.at> wrote:

>> That possibility didn't occur to me.  Is there some command I can call,
>> or some other way to convince myself that this is what is happening (not
>> that I don't believe you, I'd just like to understand it).
>
> I suppose the window manager simply crops everything that doesn't fit
> within its external borders.  You should be able to convince yourself
> for a single window frame by removing modeline and echo area and
> decreasing the height of the horizontal scroll bar.

As I mentioned (quoted below), I was already convinced by seeing the
horizontal scroll bar partially cover the mode line.  But by using a
separate minibuffer frame (I suppose that's what you mean by removing
the echo area), I do indeed see the analog with the horizontal scroll
bar of what I see with the narrowed vertical scroll bar on the right: it
is at the very bottom of the frame and cut off.  Quite convincing,
indeed.  Thanks for the suggestion.

>> And why does
>> it happen on the right but not on the left (nor on the right side of a
>> non-right window)?
>
> It doesn't happen on the left or for non-right windows because in this
> case the (default sized) scroll bar gets drawn into Emacs' client area
> and the window manager assumes that Emacs knows how to deal with it.

Ok.

>> I meant Emacs can make it thinner, since it didn't occur to me that the
>> appearance of the right scroll bar could be due to the WM.
>
> We must discriminate: Emacs reserves the area as you specify it.  Gtk
> draws its slider into that area alas with a width determined by the
> theme or a resource file.

>> Indeed: with (modify-all-frames-parameters '((scroll-bar-width . 32)))
>> the scroll bar
>
> ... more precisely, the slider ...
>
>> still has the default width but there are nearly equally
>> wide spaces on both sides of it (between the scroll and the fringe to
>> the left and between the scroll bar and the frame border to the right).
>> Ok, this convinces me that Emacs is not modifying the width.
>
> ... the width of the slider.

I'm not sure I understand the distinction you're making.  By "slider" do
you mean what is sometimes called the "thumb" of the scroll bar?
(According to Wikipedia, a slider is a different kind of widget from a
scroll bar, but I didn't try checking other sources.)  If so, are you
saying that Gtk only controls the width (or height) of the slider
(thumb), while Emacs controls the size of its container, which I guess
is the scroll bar taken as a whole?

>> As I mentioned, I can't simply build both the Lucid and the Gtk builds
>> on my system, apparently due to incompatible libpng requirements.
>
> Maybe Jan has an idea.

He did :)

>> Anyway, it seems that the appropriate fix for this bug it to make
>> modifying the scroll-bar-width and scroll-bar-height frame parameters
>> noops in Gtk builds.
>
> Another problem is that currently we prescribe a minimum width for
> scroll bars which has parts of the scroll bar background change
> appearance when the Gtk slider is narrower.

Not sure I understand; can you elaborate or tell me how I can see what
you mean?

Steve Berman

bug#18990: 25.0.50; Scroll bar display problems

[martin rudalics]

 > As I mentioned (quoted below), I was already convinced by seeing the
 > horizontal scroll bar partially cover the mode line.  But by using a
 > separate minibuffer frame (I suppose that's what you mean by removing
 > the echo area),

That's what I meant, indeed.

 > I do indeed see the analog with the horizontal scroll
 > bar of what I see with the narrowed vertical scroll bar on the right: it
 > is at the very bottom of the frame and cut off.  Quite convincing,
 > indeed.  Thanks for the suggestion.
[...]
 > I'm not sure I understand the distinction you're making.  By "slider" do
 > you mean what is sometimes called the "thumb" of the scroll bar?

IIRC GTK uses the term "slider" for "thumb".

 > (According to Wikipedia, a slider is a different kind of widget from a
 > scroll bar, but I didn't try checking other sources.)  If so, are you
 > saying that Gtk only controls the width (or height) of the slider
 > (thumb), while Emacs controls the size of its container, which I guess
 > is the scroll bar taken as a whole?

I think so.  Depending on the toolkit Emacs can control size, background
and borders of the container.  The GTK slider is controlled by the theme
though.  Jan will correct me.

 >> Another problem is that currently we prescribe a minimum width for
 >> scroll bars which has parts of the scroll bar background change
 >> appearance when the Gtk slider is narrower.
 >
 > Not sure I understand; can you elaborate or tell me how I can see what
 > you mean?

I once posted a screenshot here

http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg02228.html

It might be related to the fact that we prescribe a minimum width of the
scroll bar in update_theme_scrollbar_width but I've not yet found a
reliable fix yet.  See also bug#17982.

martin

bug#18990: 25.0.50; Scroll bar display problems

[Jan D.]

martin rudalics skrev den 2014-11-09 12:56:

> IIRC GTK uses the term "slider" for "thumb".
>
>  > (According to Wikipedia, a slider is a different kind of widget from a
>  > scroll bar, but I didn't try checking other sources.)  If so, are you
>  > saying that Gtk only controls the width (or height) of the slider
>  > (thumb), while Emacs controls the size of its container, which I guess
>  > is the scroll bar taken as a whole?
>
> I think so.  Depending on the toolkit Emacs can control size, background
> and borders of the container.  The GTK slider is controlled by the theme
> though.  Jan will correct me.
>

We also control the size of the thumb/slider.
Some Gtk+ themes have a minimum size for the thumb though (bitmap).
The width of the slider is beyond Emacs control.

	Jan D.

bug#18990: 25.0.50; Scroll bar display problems

[martin rudalics]

 > Starting Emacs like this:
 >
 > emacs -Q --eval "(progn (modify-all-frames-parameters '((scroll-bar-width . 7))) (custom-set-variables '(scroll-bar-mode (quote left))))"
 >
 > the scroll bar is correctly display on the left, but its width is the
 > default, not the customized value, and it overlays the left fringe,
 > which is hence hidden.

There are two ways to change the width or height of a scroll bar with
GTK: Either by choosing an appropriate theme or by setting the
slider-width in a configuration file.  You can't change the size
individually from within Emacs and IMO we should prevent users from
trying to do so.  What happens currently is that Emacs internally uses
the height you specified and GTK continues to draw the scroolbar in its
default size over it.

 > These display problems do not happen when the scroll bar is either on
 > the right or has its default width.

There are similar problems, for example, with side-by-side windows.

 > They also don't happen with the
 > non-toolkit-scroll-bar build.  They do happen with 24.3, the earliest
 > version I currently have (I don't have a non-toolkit-scroll-bar build of
 > 24.4 at hand but I guess it also has the problems).

Non-GTK scroll bars should not have any such problems.

 > (I haven't noticed
 > these problems before, since I've been using non-toolkit-scroll-bar
 > builds for a long time, and only since the 24.4 release have switched to
 > the toolkit scroll bar on the trunk to be able to test the horizontal
 > scroll bar.)

The GTK horizontal scroll bar has similar problems.

martin