Fixes it for me. Thanks!
Markus
Yoshiki Hayashi <yoshiki(a)xemacs.org> on 02/10/2000 06:28:23 AM
Please respond to Yoshiki Hayashi <yoshiki(a)xemacs.org>
To: XEmacs Beta List <xemacs-beta(a)xemacs.org>
cc: xemacs-patches(a)xemacs.org, ueno(a)ueda.info.waseda.ac.jp (bcc: Markus
Alt/Germany/IBM)
Subject: Re: clipped scrollbar in 21.2.27
Daniel Pittman <daniel(a)danann.net> writes:
> > Interesting. I noticed the very same thing, only I attributed it to
> > the new WM I'm using. So yes, I can see it too.
>
> As do I. Running with the toolbar on the right hand side of the screen,
> the scrollbar is drawn a couple of pixels to the right, running on to
> the left of the toolbar buttons.
>
> So, I don't think this is a window manager issue, rather an off-by-some
> bug in the scrollbar positioning code...
I bet that behavior is introduced by this patch:
2000-02-03 Daiki Ueno <ueno(a)ueda.info.waseda.ac.jp>
* frame.c (change_frame_size_1): Take f->internal_border_width
into consideration when calculating the width of the frame.
Undoing that patch, scrollbar appears at the usual place.
shrink-window-if-larger-than-buffer works fine with his lisp
patch only, though I had to remove window.elc and run make again.
Usual disclaimer applies to this patch: I DO NOT UNDERSTAND
THIS CODE.
2000-02-09 Yoshiki Hayashi <yoshiki(a)xemacs.org>
* frame.c (change_frame_size_1): Undo 2000-02-03 change.
Index: frame.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/frame.c,v
retrieving revision 1.37.2.20
diff -u -r1.37.2.20 frame.c
--- frame.c 2000/02/07 08:00:05 1.37.2.20
+++ frame.c 2000/02/10 05:24:55
@@ -2851,8 +2851,6 @@
- FRAME_REAL_RIGHT_TOOLBAR_WIDTH (f)
- 2 * FRAME_REAL_RIGHT_TOOLBAR_BORDER_WIDTH (f);
- new_pixwidth += 2 * f->internal_border_width;
-
/* Adjust the width for the end glyph which may be a different width
than the default character width. */
{
--
Yoshiki Hayashi