Addition to emacsbug.el

Addition to emacsbug.el

[Jan D.]

Hello.

I'm working on the GTK scroll bars again, trying to get overscrolling to work 
as in the native scroll bars.  But I see that depending on what GTK version and 
what X server version I run on (specifically with DAMAGE extension or not), I 
sometimes get different behaviour.  Therefore I would like to have this 
information inserted by report-emacs-bug.  The GTK version is already in 
emacs-version, so I propose this patch to emacsbug.el:

*** emacsbug.el.~1.61.~ 2003-10-05 15:51:43.000000000 +0200
--- emacsbug.el 2004-10-27 11:34:54.000000000 +0200
***************
*** 128,133 ****
--- 128,136 ----
       (insert "\n\n\n")

       (insert "In " (emacs-version) "\n")
+     (if (fboundp 'x-server-vendor)
+       (insert "X vendor `" (x-server-vendor) "', vendor version "
+               (format "%d" (nth 2 (x-server-version))) "\n"))
       (if (and system-configuration-options
              (not (equal system-configuration-options "")))
         (insert "configured using `configure "


Is this OK?

	Jan D.

Re: Addition to emacsbug.el

[Stefan Monnier]

> I'm working on the GTK scroll bars again, trying to get overscrolling to
> work as in the native scroll bars.  But I see that depending on what GTK
> version and what X server version I run on (specifically with DAMAGE
> extension or not), I sometimes get different behaviour.  Therefore I would
> like to have this information inserted by report-emacs-bug.  The GTK version
> is already in emacs-version, so I propose this patch to emacsbug.el:

BTW, with the Xaw3d scrollbars (which had/have the same problem), I've been
using the following trick very happily:
- use the "normal" thumb position and size (the same as was used for the
  non-toolkit scroll bars).
- at the beginning of a thumb-drag, set the thumb size to 0.
- at the end of a thumb-drag reset the thumb-size to its real value.

I find this to be the best solution to the problem: from the code's point of
view, it's clean and simple (much cleaner and simpler than the hacks that
are currently used in xterm.c).  From the user's point of view, it makes
dragging a bit strange at first because the thumb almost disappears under
the mouse cursor, but to make up for it, the actual behavior during dragging
is now flawless and so is the rest of the behavior.
Since we can't have a perfect behavior I find this trade off to be much
better than anything I've seen so far.

And also I suggest to merge xg_set_toolkit_scroll_bar_thumb back into
x_set_toolkit_scroll_bar_thumb.

Here is my current patch to xterm.c (barely tested under Gtk, tho).


        Stefan


*** orig/src/xterm.c
--- mod/src/xterm.c
***************
*** 4019,4030 ****
  
  static Boolean xaw3d_arrow_scroll;
  
- /* Whether the drag scrolling maintains the mouse at the top of the
-    thumb.  If not, resizing the thumb needs to be done more carefully
-    to avoid jerkyness.  */
- 
- static Boolean xaw3d_pick_top;
- 
  extern void set_vertical_scroll_bar P_ ((struct window *));
  
  /* Action hook installed via XtAppAddActionHook when toolkit scroll
--- 4019,4024 ----
***************
*** 4183,4193 ****
  }
  
  
! #ifdef USE_MOTIF
  
! /* Minimum and maximum values used for Motif scroll bars.  */
  
! #define XM_SB_MAX 10000000
  
  
  /* Scroll bar callback for Motif scroll bars.  WIDGET is the scroll
--- 4177,4187 ----
  }
  
  
! /* Maximum size value used for some scroll bars.  */
  
! #define SB_MAX 10000000
  
! #ifdef USE_MOTIF
  
  
  /* Scroll bar callback for Motif scroll bars.  WIDGET is the scroll
***************
*** 4244,4250 ****
  	XtVaGetValues (widget, XmNsliderSize, &slider_size, NULL);
  	UNBLOCK_INPUT;
  
! 	whole = XM_SB_MAX - slider_size;
  	portion = min (cs->value, whole);
  	part = scroll_bar_handle;
  	bar->dragging = make_number (cs->value);
--- 4238,4244 ----
  	XtVaGetValues (widget, XmNsliderSize, &slider_size, NULL);
  	UNBLOCK_INPUT;
  
! 	whole = SB_MAX - slider_size;
  	portion = min (cs->value, whole);
  	part = scroll_bar_handle;
  	bar->dragging = make_number (cs->value);
***************
*** 4263,4271 ****
      }
  }
  
  
- #else /* !USE_MOTIF, i.e. Xaw or GTK */
- #ifdef USE_GTK
  /* Scroll bar callback for GTK scroll bars.  WIDGET is the scroll
     bar widget.  DATA is a pointer to the scroll_bar structure. */
  
--- 4257,4264 ----
      }
  }
  
+ #elif defined USE_GTK
  
  /* Scroll bar callback for GTK scroll bars.  WIDGET is the scroll
     bar widget.  DATA is a pointer to the scroll_bar structure. */
  
***************
*** 4336,4342 ****
      }
  }
  
! #else /* not USE_GTK */
  
  /* Xaw scroll bar callback.  Invoked when the thumb is dragged.
     WIDGET is the scroll bar widget.  CLIENT_DATA is a pointer to the
--- 4329,4335 ----
      }
  }
  
! #else /* not USE_GTK and not USE_MOTIF */
  
  /* Xaw scroll bar callback.  Invoked when the thumb is dragged.
     WIDGET is the scroll bar widget.  CLIENT_DATA is a pointer to the
***************
*** 4350,4376 ****
  {
    struct scroll_bar *bar = (struct scroll_bar *) client_data;
    float top = *(float *) call_data;
!   float shown;
!   int whole, portion, height;
    int part;
  
!   /* Get the size of the thumb, a value between 0 and 1.  */
!   BLOCK_INPUT;
!   XtVaGetValues (widget, XtNshown, &shown, XtNheight, &height, NULL);
!   UNBLOCK_INPUT;
! 
!   whole = 10000000;
!   portion = shown < 1 ? top * whole : 0;
! 
!   if (shown < 1 && (abs (top + shown - 1) < 1.0/height))
!     /* Some derivatives of Xaw refuse to shrink the thumb when you reach
!        the bottom, so we force the scrolling whenever we see that we're
!        too close to the bottom (in x_set_toolkit_scroll_bar_thumb
!        we try to ensure that we always stay two pixels away from the
!        bottom).  */
!     part = scroll_bar_down_arrow;
!   else
!     part = scroll_bar_handle;
  
    window_being_scrolled = bar->window;
    bar->dragging = make_number (portion);
--- 4343,4357 ----
  {
    struct scroll_bar *bar = (struct scroll_bar *) client_data;
    float top = *(float *) call_data;
!   int whole, portion;
    int part;
  
!   whole = SB_MAX;
!   portion = min (SB_MAX * top, whole);
!   part = scroll_bar_handle;
!   /* The thumb can't be resized while dragging and could thus prevent us
!      from reaching the end: let's set it to 0 temporarily.  */
!   XawScrollbarSetThumb (widget, top, 0);
  
    window_being_scrolled = bar->window;
    bar->dragging = make_number (portion);
***************
*** 4419,4426 ****
    x_send_scroll_bar_event (bar->window, part, position, height);
  }
  
! #endif /* not USE_GTK */
! #endif /* not USE_MOTIF */
  
  #define SCROLL_BAR_NAME "verticalScrollBar"
  
--- 4400,4406 ----
    x_send_scroll_bar_event (bar->window, part, position, height);
  }
  
! #endif /* not USE_GTK and not USE_MOTIF */
  
  #define SCROLL_BAR_NAME "verticalScrollBar"
  
***************
*** 4461,4467 ****
    /* Set resources.  Create the widget.  */
    XtSetArg (av[ac], XtNmappedWhenManaged, False); ++ac;
    XtSetArg (av[ac], XmNminimum, 0); ++ac;
!   XtSetArg (av[ac], XmNmaximum, XM_SB_MAX); ++ac;
    XtSetArg (av[ac], XmNorientation, XmVERTICAL); ++ac;
    XtSetArg (av[ac], XmNprocessingDirection, XmMAX_ON_BOTTOM), ++ac;
    XtSetArg (av[ac], XmNincrement, 1); ++ac;
--- 4441,4447 ----
    /* Set resources.  Create the widget.  */
    XtSetArg (av[ac], XtNmappedWhenManaged, False); ++ac;
    XtSetArg (av[ac], XmNminimum, 0); ++ac;
!   XtSetArg (av[ac], XmNmaximum, SB_MAX); ++ac;
    XtSetArg (av[ac], XmNorientation, XmVERTICAL); ++ac;
    XtSetArg (av[ac], XmNprocessingDirection, XmMAX_ON_BOTTOM), ++ac;
    XtSetArg (av[ac], XmNincrement, 1); ++ac;
***************
*** 4593,4600 ****
    {
      char *initial = "";
      char *val = initial;
!     XtVaGetValues (widget, XtNscrollVCursor, (XtPointer) &val,
! 		   XtNpickTop, (XtPointer) &xaw3d_pick_top, NULL);
      if (val == initial)
        {	/* ARROW_SCROLL */
  	xaw3d_arrow_scroll = True;
--- 4573,4579 ----
    {
      char *initial = "";
      char *val = initial;
!     XtVaGetValues (widget, XtNscrollVCursor, (XtPointer) &val, NULL);
      if (val == initial)
        {	/* ARROW_SCROLL */
  	xaw3d_arrow_scroll = True;
***************
*** 4631,4675 ****
  /* Set the thumb size and position of scroll bar BAR.  We are currently
     displaying PORTION out of a whole WHOLE, and our position POSITION.  */
  
- #ifdef USE_GTK
  static void
  x_set_toolkit_scroll_bar_thumb (bar, portion, position, whole)
       struct scroll_bar *bar;
       int portion, position, whole;
  {
-   xg_set_toolkit_scroll_bar_thumb (bar, portion, position, whole);
- }
- 
- #else /* not USE_GTK */
- static void
- x_set_toolkit_scroll_bar_thumb (bar, portion, position, whole)
-      struct scroll_bar *bar;
-      int portion, position, whole;
- {
-   struct frame *f = XFRAME (WINDOW_FRAME (XWINDOW (bar->window)));
-   Widget widget = SCROLL_BAR_X_WIDGET (FRAME_X_DISPLAY (f), bar);
    float top, shown;
  
-   BLOCK_INPUT;
- 
- #ifdef USE_MOTIF
- 
-   /* We use an estimate of 30 chars per line rather than the real
-      `portion' value.  This has the disadvantage that the thumb size
-      is not very representative, but it makes our life a lot easier.
-      Otherwise, we have to constantly adjust the thumb size, which
-      we can't always do quickly enough: while dragging, the size of
-      the thumb might prevent the user from dragging the thumb all the
-      way to the end.  but Motif and some versions of Xaw3d don't allow
-      updating the thumb size while dragging.  Also, even if we can update
-      its size, the update will often happen too late.
-      If you don't believe it, check out revision 1.650 of xterm.c to see
-      what hoops we were going through and the still poor behavior we got.  */
-   portion = WINDOW_TOTAL_LINES (XWINDOW (bar->window)) * 30;
-   /* When the thumb is at the bottom, position == whole.
-      So we need to increase `whole' to make space for the thumb.  */
-   whole += portion;
- 
    if (whole <= 0)
      top = 0, shown = 1;
    else
--- 4610,4622 ----
***************
*** 4678,4768 ****
        shown = (float) portion / whole;
      }
  
    if (NILP (bar->dragging))
      {
        int size, value;
  
        /* Slider size.  Must be in the range [1 .. MAX - MIN] where MAX
           is the scroll bar's maximum and MIN is the scroll bar's minimum
  	 value.  */
!       size = shown * XM_SB_MAX;
!       size = min (size, XM_SB_MAX);
        size = max (size, 1);
  
        /* Position.  Must be in the range [MIN .. MAX - SLIDER_SIZE].  */
!       value = top * XM_SB_MAX;
!       value = min (value, XM_SB_MAX - size);
  
        XmScrollBarSetValues (widget, value, size, 0, 0, False);
!     }
! #else /* !USE_MOTIF i.e. use Xaw */
  
!   if (whole == 0)
!     top = 0, shown = 1;
!   else
!     {
!       top = (float) position / whole;
!       shown = (float) portion / whole;
!     }
  
!   {
!     float old_top, old_shown;
!     Dimension height;
!     XtVaGetValues (widget,
! 		   XtNtopOfThumb, &old_top,
! 		   XtNshown, &old_shown,
! 		   XtNheight, &height,
! 		   NULL);
! 
!     /* Massage the top+shown values.  */
!     if (NILP (bar->dragging) || last_scroll_bar_part == scroll_bar_down_arrow)
!       top = max (0, min (1, top));
!     else
!       top = old_top;
!     /* Keep two pixels available for moving the thumb down.  */
!     shown = max (0, min (1 - top - (2.0 / height), shown));
! 
!     /* If the call to XawScrollbarSetThumb below doesn't seem to work,
!        check that your system's configuration file contains a define
!        for `NARROWPROTO'.  See s/freebsd.h for an example.  */
!     if (top != old_top || shown != old_shown)
!       {
! 	if (NILP (bar->dragging))
! 	  XawScrollbarSetThumb (widget, top, shown);
! 	else
  	  {
! #ifdef HAVE_XAW3D
! 	    ScrollbarWidget sb = (ScrollbarWidget) widget;
! 	    int scroll_mode = 0;
  
! 	    /* `scroll_mode' only exists with Xaw3d + ARROW_SCROLLBAR.  */
! 	    if (xaw3d_arrow_scroll)
! 	      {
! 		/* Xaw3d stupidly ignores resize requests while dragging
! 		   so we have to make it believe it's not in dragging mode.  */
! 		scroll_mode = sb->scrollbar.scroll_mode;
! 		if (scroll_mode == 2)
! 		  sb->scrollbar.scroll_mode = 0;
! 	      }
! #endif
! 	    /* Try to make the scrolling a tad smoother.  */
! 	    if (!xaw3d_pick_top)
! 	      shown = min (shown, old_shown);
! 
! 	    XawScrollbarSetThumb (widget, top, shown);
! 
! #ifdef HAVE_XAW3D
! 	    if (xaw3d_arrow_scroll && scroll_mode == 2)
! 	      sb->scrollbar.scroll_mode = scroll_mode;
! #endif
  	  }
        }
!   }
  #endif /* !USE_MOTIF */
  
    UNBLOCK_INPUT;
  }
- #endif /* not USE_GTK */
  
  #endif /* USE_TOOLKIT_SCROLL_BARS */
  
--- 4625,4709 ----
        shown = (float) portion / whole;
      }
  
+   BLOCK_INPUT;
+ 
    if (NILP (bar->dragging))
      {
+       FRAME_PTR f = XFRAME (WINDOW_FRAME (XWINDOW (bar->window)));
+ #ifdef USE_GTK
+       GtkWidget *wscroll = xg_get_widget_from_map (SCROLL_BAR_X_WINDOW (bar));
+ #else
+       Widget widget = SCROLL_BAR_X_WIDGET (FRAME_X_DISPLAY (f), bar);
+ #endif
+ 
+ #if defined USE_MOTIF || defined USE_GTK
        int size, value;
  
        /* Slider size.  Must be in the range [1 .. MAX - MIN] where MAX
           is the scroll bar's maximum and MIN is the scroll bar's minimum
  	 value.  */
!       size = shown * SB_MAX;
!       size = min (size, SB_MAX);
        size = max (size, 1);
  
        /* Position.  Must be in the range [MIN .. MAX - SLIDER_SIZE].  */
!       value = top * SB_MAX;
!       value = min (value, SB_MAX - size);
  
+ #ifdef USE_MOTIF
        XmScrollBarSetValues (widget, value, size, 0, 0, False);
! #else  /* USE_GTK */
!       {
! 	GtkAdjustment *adj;
! 	int new_step;
! 	int changed = 0;
  
! 	adj = gtk_range_get_adjustment (GTK_RANGE (wscroll));
  
! 	/* Assume all lines are of equal size.  */
! 	new_step = size / max (1, FRAME_HEIGHT (f));
! 
! 	if ((int) adj->page_size != size
! 	    || (int) adj->step_increment != new_step)
  	  {
! 	    adj->page_size = size;
! 	    adj->step_increment = new_step;
! 	    /* Assume a page increment is about 95% of the page size  */
! 	    adj->page_increment = (int) (0.95*adj->page_size);
! 	    changed = 1;
! 	  }
  
! 	if (changed || (int) gtk_range_get_value (GTK_RANGE (wscroll)) != value)
! 	  {
! 	    GtkWidget *wfixed = f->output_data.x->edit_widget;
! 	    
! 	    BLOCK_INPUT;
! 	    
! 	    /* gtk_range_set_value invokes the callback.  Set
! 	       ignore_gtk_scrollbar to make the callback do nothing  */
! 	    xg_ignore_gtk_scrollbar = 1;
! 	    
! 	    if ((int) gtk_range_get_value (GTK_RANGE (wscroll)) != value)
! 	      gtk_range_set_value (GTK_RANGE (wscroll), (gdouble)value);
! 	    else if (changed)
! 	      gtk_adjustment_changed (adj);
! 	    
! 	    xg_ignore_gtk_scrollbar = 0;
! 	    
! 	    UNBLOCK_INPUT;
  	  }
        }
! #endif
! #else /* not USE_MOTIF and not USE_GTK  i.e. use Xaw */
!       /* If the call to XawScrollbarSetThumb below doesn't seem to work,
! 	 check that your system's configuration file contains a define
! 	 for `NARROWPROTO'.  See s/freebsd.h for an example.  */
!       XawScrollbarSetThumb (widget, top, shown);
  #endif /* !USE_MOTIF */
+     }
  
    UNBLOCK_INPUT;
  }
  
  #endif /* USE_TOOLKIT_SCROLL_BARS */
  
***************
*** 4878,4883 ****
--- 4819,4826 ----
  }
  
  
+ #ifndef USE_TOOLKIT_SCROLL_BARS
+ 
  /* Draw BAR's handle in the proper position.
  
     If the handle is already drawn from START to END, don't bother
***************
*** 4891,4898 ****
     the bar's top is as far down as it goes; otherwise, there's no way
     to move to the very end of the buffer.  */
  
- #ifndef USE_TOOLKIT_SCROLL_BARS
- 
  static void
  x_scroll_bar_set_handle (bar, start, end, rebuild)
       struct scroll_bar *bar;
--- 4834,4839 ----
***************
*** 10840,10846 ****
  #ifdef USE_TOOLKIT_SCROLL_BARS
  #ifndef USE_GTK
    xaw3d_arrow_scroll = False;
-   xaw3d_pick_top = True;
  #endif
  #endif
  
--- 10780,10785 ----

Re: Addition to emacsbug.el

[Jan D.]

Stefan Monnier wrote:
>>I'm working on the GTK scroll bars again, trying to get overscrolling to
>>work as in the native scroll bars.  But I see that depending on what GTK
>>version and what X server version I run on (specifically with DAMAGE
>>extension or not), I sometimes get different behaviour.  Therefore I would
>>like to have this information inserted by report-emacs-bug.  The GTK version
>>is already in emacs-version, so I propose this patch to emacsbug.el:
> 
> 
> BTW, with the Xaw3d scrollbars (which had/have the same problem), I've been
> using the following trick very happily:
> - use the "normal" thumb position and size (the same as was used for the
>   non-toolkit scroll bars).
> - at the beginning of a thumb-drag, set the thumb size to 0.
> - at the end of a thumb-drag reset the thumb-size to its real value.
> 
> I find this to be the best solution to the problem: from the code's point of
> view, it's clean and simple (much cleaner and simpler than the hacks that
> are currently used in xterm.c).  From the user's point of view, it makes
> dragging a bit strange at first because the thumb almost disappears under
> the mouse cursor, but to make up for it, the actual behavior during dragging
> is now flawless and so is the rest of the behavior.

Hmm, I don't like it.  First of all, it is during a thumb-drag that you 
actually look at the thumb and the feedback you get from the size of the thumb 
(how much of the whole we are viewing, and where we currently are) is most 
useful.  Also, the thumb does not always show up under the mouse pointer, but 
often quite a bit from it.  If I continue to drag, the thumb jumps to the 
pointer.  I'd rather keep the current GTK behaviour, with a thumb size that 
includes the empty virtual page, but others may feel different.

Secondly it does not work at all for GTK.  The event from the scroll bar stops 
when the thumb hits the bottom, so overscrolling for a window where the whole 
contents is shown does not happen.  Also, GTK thumbs can not be resized with 
ease like the Xaw and Motif ones, it involves setting the page size and the max 
and min just right.

> Since we can't have a perfect behavior I find this trade off to be much
> better than anything I've seen so far.

It depends on what we consider the perfect behaviour.  My idea (and I thought 
the other versions of Emacs behaved like this already, I don't use scroll bars 
much) is that when the thumb hits the bottom we enter overscrolling mode.  In 
that mode the thumb smoothly shrinks if dragged down further, and grows again 
if dragged up.

Say you have a buffer with two pages, and if one page is visible the thumb is 
half the size of the window.  You drag down the thumb to the bottom, so that 
the top of page two is at the top of the window.  If you drag down further, the 
thumb shrinks until the bottom of page two is at the top of the window.  The 
thumb in this case shrinks to a minimum of a third of the window height (2 real 
pages and one virtual).

I am not sure if there is a general way to do this (resizing of thumbs and 
event handling differ between toolkits), or if it must be done individually for 
each toolkit.  Perhaps if this is done for two toolkits we can then rewrite it 
in a general way.  That would be 22.0 stuff I think.  But as GTK is just one 
toolkit and the scroll code to modify is either all in gtkutils.c or #ifdef:ed 
USE_GTK in xterm, the risc is low.

I have a test program that does just this for GTK, but it is one thing to write 
a pure GTK program and another to get the same behaviour in Emacs.  I hope it 
can be done.  Also, I haven't tested with complicated themes yet.

	Jan D.

Re: Addition to emacsbug.el

[Stefan Monnier]

> Hmm, I don't like it.  First of all, it is during a thumb-drag that you
> actually look at the thumb and the feedback you get from the size of the
> thumb (how much of the whole we are viewing, and where we currently are) is
> most useful.  Also, the thumb does not always show up under the mouse
> pointer, but often quite a bit from it.  If I continue to drag, the thumb
> jumps to the pointer.  I'd rather keep the current GTK behaviour, with
> a thumb size that includes the empty virtual page, but others may
> feel different.

Well, it's a question of taste, obviously.  I myself introduced the idea of
"empty virtual page" in the Xaw3d code (so if you're looking at a 25 lines
buffer in a 25-lines window, the thumb is only covering half of the
scrollbar).  But after using it for a while I decided I didn't like it
because I was never sure whether there was still something left in the
buffer (typically when reading Gnus messages).  There are various ways to
provide some other visual feedback, but experience showed that the scrollbar
is the feedback that I use.

> Secondly it does not work at all for GTK.  The event from the scroll bar
> stops when the thumb hits the bottom, so overscrolling for a window where
> the whole contents is shown does not happen.

I don't understand what you mean by "it doesn't work".  In the above case,
the thumb would start covering the whole scrollbar, but as soon as the drag
starts you make it size 0, so the user can drag at will and the thumb will
only hit the bottom of the scrollbar when the beginning of the thumb is at
the bottom (i.e. when the last char of the buffer is at the top of the
window).

The problem of not being able to move past the bottom is just the same
in Xaw3d.  Well, was, since AFAIK Xaw3g version 1.5g fixes it (it can be
argued that it was a bug since it didn't follow the Xaw behavior).

> Also, GTK thumbs can not be resized with ease like the Xaw and Motif ones,
> it involves setting the page size and the max and min just right.

Isn't that a small matter of programming (I mean, Emacs does change the size
of the thumb, already, right?).

> It depends on what we consider the perfect behaviour.  My idea (and
> I thought the other versions of Emacs behaved like this already, I don't use
> scroll bars much) is that when the thumb hits the bottom we enter
> overscrolling mode.  In that mode the thumb smoothly shrinks if dragged down
> further, and grows again if dragged up.

Yes, that's exactly what I mean by "perfect behavior", except that your
description only focuses on the scrollbar, whereas one key aspect is how it
relates to the actual buffer text displayed: when the thumb hits the bottom
is when the EOB is displayed.

> I am not sure if there is a general way to do this (resizing of thumbs and
> event handling differ between toolkits), or if it must be done individually
> for each toolkit.  Perhaps if this is done for two toolkits we can then
> rewrite it in a general way.  That would be 22.0 stuff I think.  But as GTK
> is just one toolkit and the scroll code to modify is either all in
> gtkutils.c or #ifdef:ed USE_GTK in xterm, the risc is low.

Currently a fair bit of code is shared, but not all of it.  the current
imperfect solution uses different tricks for different toolkits.

My suggested new imperfect solution is less dependent on details of the
toolkits so it reduces the among of toolkit-specific tweaks.
Check the patch I sent.

BTW, what about the other part of my patch:
merge xg_set_toolkit_scroll_bar_thumb back into
x_set_toolkit_scroll_bar_thumb ?


        Stefan

Re: Addition to emacsbug.el

[Jan D.]

>> Hmm, I don't like it.  First of all, it is during a thumb-drag that 
>> you
>> actually look at the thumb and the feedback you get from the size of 
>> the
>> thumb (how much of the whole we are viewing, and where we currently 
>> are) is
>> most useful.  Also, the thumb does not always show up under the mouse
>> pointer, but often quite a bit from it.  If I continue to drag, the 
>> thumb
>> jumps to the pointer.  I'd rather keep the current GTK behaviour, with
>> a thumb size that includes the empty virtual page, but others may
>> feel different.
>
> Well, it's a question of taste, obviously.  I myself introduced the 
> idea of
> "empty virtual page" in the Xaw3d code (so if you're looking at a 25 
> lines
> buffer in a 25-lines window, the thumb is only covering half of the
> scrollbar).  But after using it for a while I decided I didn't like it
> because I was never sure whether there was still something left in the
> buffer (typically when reading Gnus messages).  There are various ways 
> to
> provide some other visual feedback, but experience showed that the 
> scrollbar
> is the feedback that I use.

For GTK at least some compromise is needed.  Some themes have a minimum
size for the thumb.  So if the thumb is at its minimum size
the overscrolling with the thumb shrinking can't happen.  If the shown
portion of the buffer is small compared to the total size of the buffer,
I think the virtual page behaviour is OK.  After all, can you see the
difference between a thumb who has a height that is 1/30 of the window
height, or 1/31?
Otherwise we should do something else, be it your solution or the thumb
shrinking one.

>
>> Secondly it does not work at all for GTK.  The event from the scroll 
>> bar
>> stops when the thumb hits the bottom, so overscrolling for a window 
>> where
>> the whole contents is shown does not happen.
>
> I don't understand what you mean by "it doesn't work".  In the above 
> case,
> the thumb would start covering the whole scrollbar, but as soon as the 
> drag
> starts you make it size 0, so the user can drag at will and the thumb 
> will
> only hit the bottom of the scrollbar when the beginning of the thumb 
> is at
> the bottom (i.e. when the last char of the buffer is at the top of the
> window).

To change the thumb size means fiddling with the page size and the 
maximum
values for the scroll bar.  Relating values back to a buffer position 
then
becomes so much harder.  Not impossible, but certainly a lot of testing
needs to be done.


>
> The problem of not being able to move past the bottom is just the same
> in Xaw3d.  Well, was, since AFAIK Xaw3g version 1.5g fixes it (it can 
> be
> argued that it was a bug since it didn't follow the Xaw behavior).
>
>> Also, GTK thumbs can not be resized with ease like the Xaw and Motif 
>> ones,
>> it involves setting the page size and the max and min just right.
>
> Isn't that a small matter of programming (I mean, Emacs does change 
> the size
> of the thumb, already, right?).

Yes, in principle that is correct.

>
>> It depends on what we consider the perfect behaviour.  My idea (and
>> I thought the other versions of Emacs behaved like this already, I 
>> don't use
>> scroll bars much) is that when the thumb hits the bottom we enter
>> overscrolling mode.  In that mode the thumb smoothly shrinks if 
>> dragged down
>> further, and grows again if dragged up.
>
> Yes, that's exactly what I mean by "perfect behavior", except that your
> description only focuses on the scrollbar, whereas one key aspect is 
> how it
> relates to the actual buffer text displayed: when the thumb hits the 
> bottom
> is when the EOB is displayed.

There is another thing I noticed about your patch.  If the buffer 
contains
three lines and the window is 34 lines, the thumb covers the whole 
window.
Now, if I start to scroll down putting the pointer somewhere at the top
of the thumb, I'll have to move down to half the window before one line
is actually scrolled.  Then down to 3/4 before the second line is 
scrolled
and finally to the bottom to get the third line to scroll.

Now, if I start with the pointer near the bottom of the thumb, the two
first lines are scrolled just by moving the pointer one pixel.

I think the amount you move the pointer should determine how many lines
are scrolled, not where you happen to put the pointer when you start.
Also, the amount to move for scrolling one line should be the same
regardless of the size of the buffer or the amount show.

>
>> I am not sure if there is a general way to do this (resizing of 
>> thumbs and
>> event handling differ between toolkits), or if it must be done 
>> individually
>> for each toolkit.  Perhaps if this is done for two toolkits we can 
>> then
>> rewrite it in a general way.  That would be 22.0 stuff I think.  But 
>> as GTK
>> is just one toolkit and the scroll code to modify is either all in
>> gtkutils.c or #ifdef:ed USE_GTK in xterm, the risc is low.
>
> Currently a fair bit of code is shared, but not all of it.  the current
> imperfect solution uses different tricks for different toolkits.
>
> My suggested new imperfect solution is less dependent on details of the
> toolkits so it reduces the among of toolkit-specific tweaks.
> Check the patch I sent.
>
> BTW, what about the other part of my patch:
> merge xg_set_toolkit_scroll_bar_thumb back into
> x_set_toolkit_scroll_bar_thumb ?

The code shared is smaller than the code that differs, so I really don't
see the point.  But if the shared code could go into a function of its
own that would make sense.  For GTK it was convinient to have all code
that modifies the scroll bars in one file when changes had to be done.

	Jan D.

Re: Addition to emacsbug.el

[Stefan]

>> Well, it's a question of taste, obviously.  I myself introduced the idea
>> of "empty virtual page" in the Xaw3d code (so if you're looking at a 25
>> lines buffer in a 25-lines window, the thumb is only covering half of the
>> scrollbar).  But after using it for a while I decided I didn't like it
>> because I was never sure whether there was still something left in the
>> buffer (typically when reading Gnus messages).  There are various ways to
>> provide some other visual feedback, but experience showed that the
>> scrollbar is the feedback that I use.

> For GTK at least some compromise is needed.  Some themes have a minimum
> size for the thumb.  So if the thumb is at its minimum size
> the overscrolling with the thumb shrinking can't happen.

Huh?  Are you sure?  I'd expect that the display-size of the thumb is
"unrelated" to the size as specified by the C code.  What if your document
is made of 10 pages and your scrollbar is 40 pixels and your minimum thumb
size is 20 pixels, is GTK going to prevent you from seeing more than
2 pages?

> If the shown portion of the buffer is small compared to the total size of
> the buffer, I think the virtual page behaviour is OK.  After all, can you
> see the difference between a thumb who has a height that is 1/30 of the
> window height, or 1/31?

Agreed: the exact size of the thumb doesn't matter that much.

But I can usually still see whether the thumb is "at the bottom" or whether
there's still one or 2 pixels left, so as long as 1 pixels represents about
20 lines the difference is "relevant" (i.e. 20 lines =~ 500 chars =>
a buffer of about 500B * 1000 pixels = 500KB for my typical frames).

By "relevant" I don't mean important, but just that it's not 100%
negligeable.  I could probably happily live with the "virtual extra page"
for buffers as small as 50KB.

> Otherwise we should do something else, be it your solution or the thumb
> shrinking one.

I don't know what is the "thumb shrinking" solution.

> To change the thumb size means fiddling with the page size and the maximum
> values for the scroll bar.  Relating values back to a buffer position then
> becomes so much harder.  Not impossible, but certainly a lot of testing
> needs to be done.

Hmm... I'll trust you on that one because I obviously don't understand
the difficulty: the way the xterm.c code uses SB_MAX or equivalent as the
"maximum value" it would work exactly the same whether SB_MAX is a constant
or not.

> There is another thing I noticed about your patch.  If the buffer contains
> three lines and the window is 34 lines, the thumb covers the whole window.
> Now, if I start to scroll down putting the pointer somewhere at the top
> of the thumb, I'll have to move down to half the window before one line
> is actually scrolled.  Then down to 3/4 before the second line is scrolled
> and finally to the bottom to get the third line to scroll.

> Now, if I start with the pointer near the bottom of the thumb, the two
> first lines are scrolled just by moving the pointer one pixel.

> I think the amount you move the pointer should determine how many lines
> are scrolled, not where you happen to put the pointer when you start.
> Also, the amount to move for scrolling one line should be the same
> regardless of the size of the buffer or the amount show.

Well, obviously this actually depends on the toolkit in use (in Xaw3d, the
thumb is always moved to the mouse pointer during grab, so the position of
the mouse pointer is what matters, rather than the distance you move it).
What toolkit were you using in the above described case?
My patch is only really tested with Xaw3d.

> The code shared is smaller than the code that differs, so I really don't
> see the point.  But if the shared code could go into a function of its
> own that would make sense.  For GTK it was convinient to have all code
> that modifies the scroll bars in one file when changes had to be done.

Well, I was hoping the code that differs could be reduced further (I didn't
have GTK installed when I did the merge, so I didn't get to check whether
it compiled, and I haven't tried to change the code to adapt to the "squash
thumb to 0-size during drag" to GTK: this change has reduced the
code-difference between Xaw3d and Motif (and non-toolkit) to one or two
lines only, so I'm hoping something similar can happen with GTK).


        Stefan

Re: Addition to emacsbug.el

[Jan D.]

>> For GTK at least some compromise is needed.  Some themes have a 
>> minimum
>> size for the thumb.  So if the thumb is at its minimum size
>> the overscrolling with the thumb shrinking can't happen.
>
> Huh?  Are you sure?  I'd expect that the display-size of the thumb is
> "unrelated" to the size as specified by the C code.  What if your 
> document
> is made of 10 pages and your scrollbar is 40 pixels and your minimum 
> thumb
> size is 20 pixels, is GTK going to prevent you from seeing more than
> 2 pages?

No, but the 9 pages will be scrolled in 20 pixels.  So no precision 
scrolling is possible if you have many pages and a small window.  It is 
the same for any scroll bar, the minimum size is at least 1 pixel.  And 
if you have a window that is 40 pixels and the buffer is 1000 pages, 
you have to scroll through 999 pages in 39 pixels.  Basically the 
scroll bar is useless in this situation.

>
>> If the shown portion of the buffer is small compared to the total 
>> size of
>> the buffer, I think the virtual page behaviour is OK.  After all, can 
>> you
>> see the difference between a thumb who has a height that is 1/30 of 
>> the
>> window height, or 1/31?
>
> Agreed: the exact size of the thumb doesn't matter that much.
>
> But I can usually still see whether the thumb is "at the bottom" or 
> whether
> there's still one or 2 pixels left, so as long as 1 pixels represents 
> about
> 20 lines the difference is "relevant" (i.e. 20 lines =~ 500 chars =>
> a buffer of about 500B * 1000 pixels = 500KB for my typical frames).
>
> By "relevant" I don't mean important, but just that it's not 100%
> negligeable.  I could probably happily live with the "virtual extra 
> page"
> for buffers as small as 50KB.

I haven't really tested to see where the threshold is for me, but I 
think
that sounds reasonable.

>
>> Otherwise we should do something else, be it your solution or the 
>> thumb
>> shrinking one.
>
> I don't know what is the "thumb shrinking" solution.

I described previously in
http://lists.gnu.org/archive/html/emacs-devel/2004-10/msg01300.html

>
>> To change the thumb size means fiddling with the page size and the 
>> maximum
>> values for the scroll bar.  Relating values back to a buffer position 
>> then
>> becomes so much harder.  Not impossible, but certainly a lot of 
>> testing
>> needs to be done.
>
> Hmm... I'll trust you on that one because I obviously don't understand
> the difficulty: the way the xterm.c code uses SB_MAX or equivalent as 
> the
> "maximum value" it would work exactly the same whether SB_MAX is a 
> constant
> or not.

If I change the maximum value, the thumb size changes.  I then also 
have to
adjust the value otherwise the thumb changes position.  Also, page_size
page_increment and step_increment has to be changed.  Obviously this
is no more than to find a suitable algorithm, but the bad thing is that
the thumb almost always jump a bit when these values are changed.


>
>> There is another thing I noticed about your patch.  If the buffer 
>> contains
>> three lines and the window is 34 lines, the thumb covers the whole 
>> window.
>> Now, if I start to scroll down putting the pointer somewhere at the 
>> top
>> of the thumb, I'll have to move down to half the window before one 
>> line
>> is actually scrolled.  Then down to 3/4 before the second line is 
>> scrolled
>> and finally to the bottom to get the third line to scroll.
>
>> Now, if I start with the pointer near the bottom of the thumb, the two
>> first lines are scrolled just by moving the pointer one pixel.
>
>> I think the amount you move the pointer should determine how many 
>> lines
>> are scrolled, not where you happen to put the pointer when you start.
>> Also, the amount to move for scrolling one line should be the same
>> regardless of the size of the buffer or the amount show.
>
> Well, obviously this actually depends on the toolkit in use (in Xaw3d, 
> the
> thumb is always moved to the mouse pointer during grab, so the 
> position of
> the mouse pointer is what matters, rather than the distance you move 
> it).
> What toolkit were you using in the above described case?
> My patch is only really tested with Xaw3d.

I used Xaw3d.  The point that bothered me is if I have to pages in a 
buffer,
scrolling three lines involves a small mouse movement.  If I have three
lines in the buffer, scrolling three lines involves a very big mouse
movement, even if I start with the mouse pointer in the same place in
both cases.

>
>> The code shared is smaller than the code that differs, so I really 
>> don't
>> see the point.  But if the shared code could go into a function of its
>> own that would make sense.  For GTK it was convinient to have all code
>> that modifies the scroll bars in one file when changes had to be done.
>
> Well, I was hoping the code that differs could be reduced further (I 
> didn't
> have GTK installed when I did the merge, so I didn't get to check 
> whether
> it compiled, and I haven't tried to change the code to adapt to the 
> "squash
> thumb to 0-size during drag" to GTK: this change has reduced the
> code-difference between Xaw3d and Motif (and non-toolkit) to one or two
> lines only, so I'm hoping something similar can happen with GTK).

Actually it didn't compile, but there where minor tweaks (I think
it was that you called a static function in gtkutil.c from xterm.c).

Anyway, the GTK code section in your part is basically the functional 
equivalent what motif calls XmScrollBarSetValues.  Unfortunately, GTK 
has nothing similar.  So we could still keep that part in gtkutils.c 
and call it xg_scroll_bar_set_values or something.


	Jan D.

Re: Addition to emacsbug.el

[Jan D.]

>>> If the shown portion of the buffer is small compared to the total 
>>> size of
>>> the buffer, I think the virtual page behaviour is OK.  After all, 
>>> can you
>>> see the difference between a thumb who has a height that is 1/30 of 
>>> the
>>> window height, or 1/31?
>>
>> Agreed: the exact size of the thumb doesn't matter that much.
>>
>> But I can usually still see whether the thumb is "at the bottom" or 
>> whether
>> there's still one or 2 pixels left, so as long as 1 pixels represents 
>> about
>> 20 lines the difference is "relevant" (i.e. 20 lines =~ 500 chars =>
>> a buffer of about 500B * 1000 pixels = 500KB for my typical frames).
>>
>> By "relevant" I don't mean important, but just that it's not 100%
>> negligeable.  I could probably happily live with the "virtual extra 
>> page"
>> for buffers as small as 50KB.
>
> I haven't really tested to see where the threshold is for me, but I 
> think
> that sounds reasonable.
>
>>
>>> Otherwise we should do something else, be it your solution or the 
>>> thumb
>>> shrinking one.
>>>

Actually, after thinking a bit, how about this approach:

If the buffer is large enough (for some definition of enough), use the 
virtual page scrolling (as GTK uses today).

If the scroll thumb is not at the bottom (i.e. no overscrolling), 
scroll as normal (i.e. no shrinking thumb to 0).

If the scroll thumb is at the bottom, shrink the thumb to 0.

That way it is easier for a user to see that you can actually 
overscroll, it is not apparent otherwise.

	Jan D.

Re: Addition to emacsbug.el

[Stefan]

>>> For GTK at least some compromise is needed.  Some themes have a minimum
>>> size for the thumb.  So if the thumb is at its minimum size
>>> the overscrolling with the thumb shrinking can't happen.
>> 
>> Huh?  Are you sure?  I'd expect that the display-size of the thumb is
>> "unrelated" to the size as specified by the C code.  What if your document
>> is made of 10 pages and your scrollbar is 40 pixels and your minimum thumb
>> size is 20 pixels, is GTK going to prevent you from seeing more than
>> 2 pages?

> No, but the 9 pages will be scrolled in 20 pixels.  So no precision
> scrolling is possible if you have many pages and a small window.  It is the
> same for any scroll bar, the minimum size is at least 1 pixel.  And if you
> have a window that is 40 pixels and the buffer is 1000 pages, you have to
> scroll through 999 pages in 39 pixels.  Basically the scroll bar is useless
> in this situation.

Yup.  So you agree it's actually not specific to the fact that some themes
have a minimum size for the thumb.  The problem is simply that Gtk makes
overscrolling "impossible", just like Xaw3d and Motif (used to) do.

>>> Otherwise we should do something else, be it your solution or the thumb
>>> shrinking one.
>> I don't know what is the "thumb shrinking" solution.

> I described previously in
> http://lists.gnu.org/archive/html/emacs-devel/2004-10/msg01300.html

Oh, I see.  That's more or less what Xaw3d used to use.
The problem with it was that the thumb was shrunk too late:
- the user moves the mouse past the bottom.
- the thumb is moved by Xaw3d to the bottom (and no further).
- the callback is called and Emacs finally gets a chance to change the thumb
  size (but it doesn't know how far the mouse has moved: it only knows that
  it's at least gotton to the bottom, so it doesn't know how much to shrink
  it).
- unless the user moves the mouse again, the position of the thumb
  is not updated to take into account the original "past the bottom"
  mouse movement.

So what often happened is that you'd move the mouse past the bottom and then
you'd have to wiggle it to get the callback to shrink the thumb little
by little.  Your suggestion to shrink it to 0 as soon as you hit the bottom
would indeed help: you'd only have to move the mouse once after
hitting bottom.

In the case of Xaw3d an additional problem is that the Xaw3d code ignore(d|s)
requests to change the size of the thumb while dragging (the xterm.c code
has/had some really ugly hacks that accessed internal variables of Xaw3d to
try and fool it into thinking it's not dragging).

>>> To change the thumb size means fiddling with the page size and the
>>> maximum values for the scroll bar.  Relating values back to a buffer
>>> position then becomes so much harder.  Not impossible, but certainly
>>> a lot of testing needs to be done.
>> 
>> Hmm... I'll trust you on that one because I obviously don't understand
>> the difficulty: the way the xterm.c code uses SB_MAX or equivalent as the
>> "maximum value" it would work exactly the same whether SB_MAX is
>> a constant
>> or not.

> If I change the maximum value, the thumb size changes.  I then also have to
> adjust the value otherwise the thumb changes position.  Also, page_size
> page_increment and step_increment has to be changed.  Obviously this
> is no more than to find a suitable algorithm, but the bad thing is that
> the thumb almost always jump a bit when these values are changed.

I'd think this algorithm is already written (to update the size and position
of the thumb after point movement or buffer modifications).  But as I said,
I don't actually know what I'm talking about, so please ignore me here.

> I used Xaw3d.  The point that bothered me is if I have to pages in
> a buffer, scrolling three lines involves a small mouse movement.
> If I have three lines in the buffer, scrolling three lines involves a very
> big mouse movement, even if I start with the mouse pointer in the same
> place in both cases.

If that's the only thing that bothered you with my Xaw3d code, I'm
flattered ;-).  After all, it's the desired behavior (and AFAICT this part
of the behavior is common to all scrollbar implementations, even for other
programs).


        Stefan

Re: Addition to emacsbug.el

[Jan D.]

>> I used Xaw3d.  The point that bothered me is if I have to pages in
>> a buffer, scrolling three lines involves a small mouse movement.
>> If I have three lines in the buffer, scrolling three lines involves a 
>> very
>> big mouse movement, even if I start with the mouse pointer in the same
>> place in both cases.
>
> If that's the only thing that bothered you with my Xaw3d code, I'm
> flattered ;-).  After all, it's the desired behavior (and AFAICT this 
> part
> of the behavior is common to all scrollbar implementations, even for 
> other
> programs).

Well, it is not all.  I don't like that the thumb shrinks for "normal" 
scrolling, i.e. not overscrolling.  As far as I know, no other program 
has overscrolling, so the common behaviour is undefined.  I do not 
agree that it is the desired behaviour.  If the window size and the 
buffer size are the same, and if the mouse pointer starts the scroll in 
the same position, then the same amount of movement should give the 
same amount of lines scrolled regardless if this is a normalscroll or 
an overscroll.  But as I said, there are no programs I know of that has 
overscrolling, so this is just an opinion.

	Jan D.

Re: Addition to emacsbug.el

[Stefan]

>>> I used Xaw3d.  The point that bothered me is if I have two pages in
>>> a buffer, scrolling three lines involves a small mouse movement.
>>> If I have three lines in the buffer, scrolling three lines involves
>>> a very big mouse movement, even if I start with the mouse pointer in the
>>> same place in both cases.
>> 
>> If that's the only thing that bothered you with my Xaw3d code, I'm
>> flattered ;-).  After all, it's the desired behavior (and AFAICT this part
>> of the behavior is common to all scrollbar implementations, even for other
>> programs).

> Well, it is not all.  I don't like that the thumb shrinks for "normal"
> scrolling, i.e. not overscrolling.  As far as I know, no other program has
> overscrolling, so the common behaviour is undefined.  I do not agree that it
> is the desired behaviour.  If the window size and the buffer size are the
> same, and if the mouse pointer starts the scroll in the same position, then
> the same amount of movement should give the same amount of lines scrolled
> regardless if this is a normalscroll or an overscroll.  But as I said, there
> are no programs I know of that has overscrolling, so this is just
> an opinion.

Hmm... there's obviously something I do not understand here.
Your example had two buffers with *different sizes* (one with 2 pages, the
other with 3 lines).  I myself have never noticed a difference between
"overscroll" and "normallscroll" behavior in Emacs, and indeed the code
makes no such distinction so the behavior should be exactly the same.


        Stefan

Re: Addition to emacsbug.el

[Jan D.]

> Hmm... there's obviously something I do not understand here.
> Your example had two buffers with *different sizes* (one with 2 pages, 
> the
> other with 3 lines).  I myself have never noticed a difference between
> "overscroll" and "normallscroll" behavior in Emacs, and indeed the code
> makes no such distinction so the behavior should be exactly the same.

Maybe I remember things wrong, I'll recompile with your patch and see 
if I can reproduce the bad effect.  BTW, overscrolling with shrinking 
thumb works well on Mac OSX.

	Jan D.

Re: Addition to emacsbug.el

[Richard Stallman]

    +     (if (fboundp 'x-server-vendor)
    +       (insert "X vendor `" (x-server-vendor) "', vendor version "
    +               (format "%d" (nth 2 (x-server-version))) "\n"))

This uses the term "vendor" which we disparage.  (In fact, I just got
through editing the doc strings and the Lisp manual to say so.)
Please say "distributor" instead of "vendor".

For the same reasons, please say "X server distributor", not just "X
distributor".

Maybe this Emacs function should be renamed.

Re: Addition to emacsbug.el

[Jan D.]

Richard Stallman wrote:
>     +     (if (fboundp 'x-server-vendor)
>     +       (insert "X vendor `" (x-server-vendor) "', vendor version "
>     +               (format "%d" (nth 2 (x-server-version))) "\n"))
> 
> This uses the term "vendor" which we disparage.  (In fact, I just got
> through editing the doc strings and the Lisp manual to say so.)
> Please say "distributor" instead of "vendor".
 >
 > For the same reasons, please say "X server distributor", not just "X
 > distributor".

OK, I used "Distributor" and "version".  That makes more sense on Mac OSX as 
there it is not about X.

	Jan D.