Scrollbar thumbs (was: Customizing the mode line)

Scrollbar thumbs (was: Customizing the mode line)

[grischka]

>>         I also find the scrollbar somewhat confusing: When the end of
>>  buffer is visible in the window, I would expect the scrollbar to reach
>>  all the way to the bottom, but it does not.
>
> It does with some GUI and not with others.  In principle it should.
> The only reason for it not to is to try and work around problems when
> dragging the scrollbar thumb, where many GUI toolkits are absurdly
> dogmatic and make it pretty much impossible for Emacs to do what
> it should.

I guess it is just that these GUI toolkit people usually are trained to deliver good looking 
and pixel-precise artwork and in consequence might have some difficulties to imagine 
how it can be "pretty much impossibe" for some editor to know how many lines it is 
actually displaying (or anyway that such editor would still want to use their scrollbars).

--- grischka

Re: Scrollbar thumbs

[Miles Bader]

"grischka" <grishka@gmx.de> writes:
> I guess it is just that these GUI toolkit people usually are trained to
> deliver good looking and pixel-precise artwork and in consequence might
> have some difficulties to imagine how it can be "pretty much impossibe"
> for some editor to know how many lines it is actually displaying (or
> anyway that such editor would still want to use their scrollbars).

Emacs _does_ know how many lines it's displaying.

What it doesn't know is how many lines are in the entire file, or more
precisely, the "height" of the entire file as rendered, which
essentially requires rendering the _entire thing_ (it can't be
calculated from logical number of lines because it depends on the exact
characters rendered).  That's a pretty nasty requirement for a non-toy
editor...

-Miles

-- 
Consult, v.i. To seek another's disapproval of a course already decided on.

Re: Scrollbar thumbs

[grischka]

>> I guess it is just that these GUI toolkit people usually are trained to
>> deliver good looking and pixel-precise artwork and in consequence might
>> have some difficulties to imagine how it can be "pretty much impossibe"
>> for some editor to know how many lines it is actually displaying (or
>> anyway that such editor would still want to use their scrollbars).
> 
> Emacs _does_ know how many lines it's displaying.
> 
> What it doesn't know is how many lines are in the entire file, or more
> precisely, the "height" of the entire file as rendered, which
> essentially requires rendering the _entire thing_ (it can't be
> calculated from logical number of lines because it depends on the exact
> characters rendered).  That's a pretty nasty requirement for a non-toy
> editor...

The simple rule is:  First do it right, then do it fast.  Try to make
it work for small files and then you can still think about how to get
equally good results with larger ones.

--- grischka

Re: Scrollbar thumbs

[David Kastrup]

"grischka" <grishka@gmx.de> writes:

>>> I guess it is just that these GUI toolkit people usually are trained
>>> to deliver good looking and pixel-precise artwork and in consequence
>>> might have some difficulties to imagine how it can be "pretty much
>>> impossibe" for some editor to know how many lines it is actually
>>> displaying (or anyway that such editor would still want to use their
>>> scrollbars).
>>
>> Emacs _does_ know how many lines it's displaying.
>>
>> What it doesn't know is how many lines are in the entire file, or
>> more precisely, the "height" of the entire file as rendered, which
>> essentially requires rendering the _entire thing_ (it can't be
>> calculated from logical number of lines because it depends on the
>> exact characters rendered).  That's a pretty nasty requirement for a
>> non-toy editor...
>
> The simple rule is: First do it right, then do it fast.  Try to make
> it work for small files and then you can still think about how to get
> equally good results with larger ones.

It is not an option to make Emacs unusable on large files for the sake
of the scrollbar idiosyncrasies of some toolkit.

-- 
David Kastrup

Re: Scrollbar thumbs

[Miles Bader]

"grischka" <grishka@gmx.de> writes:
> Try to make it work for small files and then you can still think about
> how to get equally good results with larger ones.

This is very naive...

-Miles

-- 
Alliance, n. In international politics, the union of two thieves who have
their hands so deeply inserted in each other's pockets that they cannot
separately plunder a third.

Re: Scrollbar thumbs

[grischka]

>> Try to make it work for small files and then you can still think about
>> how to get equally good results with larger ones.
> 
> This is very naive...
> 
> -Miles
> 

Naive is what you currently have as scroll support in your program.

--- grischka

Re: Scrollbar thumbs

[joakim]

"grischka" <grishka@gmx.de> writes:

>>> Try to make it work for small files and then you can still think about
>>> how to get equally good results with larger ones.
>>
>> This is very naive...
>>
>> -Miles
>>
>
> Naive is what you currently have as scroll support in your program.
>
> --- grischka

Heres an attempt at bootstrapping this into a productive thread:

 - Is there a bugnumber describing the desired Emacs behaviour?
 - Can we locate a thread with the discussion of scrolling with the gtk developers?

Since I dont use scrollbars I'm not so knowledgeable about the technical
problem.
 
>
>
-- 
Joakim Verona

Re: Scrollbar thumbs

[Jan Djärv]

joakim@verona.se skrev 2009-11-04 12.18:
> "grischka"<grishka@gmx.de>  writes:
>
>>>> Try to make it work for small files and then you can still think about
>>>> how to get equally good results with larger ones.
>>>
>>> This is very naive...
>>>
>>> -Miles
>>>
>>
>> Naive is what you currently have as scroll support in your program.
>>
>> --- grischka
>
> Heres an attempt at bootstrapping this into a productive thread:
>
>   - Is there a bugnumber describing the desired Emacs behaviour?

A quick search didn't find any.

>   - Can we locate a thread with the discussion of scrolling with the gtk developers?
>

Started here AFAIK:
http://lists.gnu.org/archive/html/emacs-devel/2003-03/msg00555.html

	Jan D.

Re: Scrollbar thumbs

[Stefan Monnier]

>> - Can we locate a thread with the discussion of scrolling with the
>>   gtk developers?
> Started here AFAIK:
> http://lists.gnu.org/archive/html/emacs-devel/2003-03/msg00555.html

Note that the problem is more common than just Gtk.
So for example some of the discussion around Xaw3d (before the release
of Emacs-21) is probably relevant as well.

In any case, given how widespread the problem is, it's clear that we
can't expect the toolkit to adapt to Emacs.  And since nobody has found
a way yet to make Emacs DTRT, all we can do is provide various
workarounds, which is what we've done until now.  But what I suggest is
that instead of each toolkit backend providing its own workaround, we
should implement the workarounds in the generic code and even implement
several of them and let the user choose which one suits him best.


        Stefan

Re: Scrollbar thumbs

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 04 Nov 2009 15:57:06 -0500, Stefan Monnier <monnier@iro.umontreal.ca> said:

> In any case, given how widespread the problem is, it's clear that we
> can't expect the toolkit to adapt to Emacs.  And since nobody has
> found a way yet to make Emacs DTRT, all we can do is provide various
> workarounds, which is what we've done until now.

The Carbon port and its descendants don't let the toolkit scrollbar
process the mouse events: we can't do that (without nontrivial changes
for multithreading of the GUI part) in the first place because the
toolkit scrollbar on Mac processes them in its own modal loop (i.e.,
we can't go back to the Lisp event loop during the mouse tracking, and
that is not compatible with the current scrollbar handling in Emacs.).

What the Carbon port (and its descendants) does is to process the
whole mouse events at the Emacs side.  It includes timer processing
for repeated scrolling (e.g, pressing an arrow button for a while.)
The toolkit is used only for displaying the scrollbar with
highlighting, detecting which part of the bar is pressed, and getting
the rectangle for a specified part of the bar.

The result is like a sort of mixture of native and toolkit scrollbars
on X11: it generates Lisp events and looks like the toolkit one, but
the size of the thumb usually changes during dragging and also
overscrolling at the bottom works as in the native one.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Scrollbar thumbs

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 05 Nov 2009 10:18:07 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> What the Carbon port (and its descendants) does is to process the
> whole mouse events at the Emacs side.  It includes timer processing
> for repeated scrolling (e.g, pressing an arrow button for a while.)
> The toolkit is used only for displaying the scrollbar with
> highlighting, detecting which part of the bar is pressed, and
> getting the rectangle for a specified part of the bar.

> The result is like a sort of mixture of native and toolkit
> scrollbars on X11: it generates Lisp events and looks like the
> toolkit one, but the size of the thumb usually changes during
> dragging and also overscrolling at the bottom works as in the native
> one.

We can port this thumb handling to scroll bars on Xaw3d compiled with
ARROW_SCROLLBARS, because we can guess the rectangle of the thumb from
available widget resource values.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: src/xterm.c
===================================================================
RCS file: /sources/emacs/emacs/src/xterm.c,v
retrieving revision 1.1051
diff -c -p -r1.1051 xterm.c
*** src/xterm.c	6 Nov 2009 08:30:45 -0000	1.1051
--- src/xterm.c	9 Nov 2009 20:33:21 -0000
*************** static void x_create_toolkit_scroll_bar 
*** 4101,4107 ****
  					     struct scroll_bar *));
  static void x_set_toolkit_scroll_bar_thumb P_ ((struct scroll_bar *,
  						int, int, int));
! 
  
  /* Lisp window being scrolled.  Set when starting to interact with
     a toolkit scroll bar, reset to nil when ending the interaction.  */
--- 4101,4108 ----
  					     struct scroll_bar *));
  static void x_set_toolkit_scroll_bar_thumb P_ ((struct scroll_bar *,
  						int, int, int));
! static int x_scroll_bar_handle_thumb_event P_ ((struct scroll_bar *, XEvent *,
! 						struct input_event *));
  
  /* Lisp window being scrolled.  Set when starting to interact with
     a toolkit scroll bar, reset to nil when ending the interaction.  */
*************** x_set_toolkit_scroll_bar_thumb (bar, por
*** 4812,4817 ****
--- 4813,4851 ----
      }
  #else /* !USE_MOTIF i.e. use Xaw */
  
+   if (xaw3d_arrow_scroll)
+     {
+       float old_top, old_shown;
+       Dimension length, thickness, min_thumb, shadow_width;
+       Dimension margin, min_shown_length;
+ 
+       XtVaGetValues (widget, XtNtopOfThumb, &old_top, XtNshown, &old_shown,
+ 		     XtNlength, &length, XtNthickness, &thickness,
+ 		     XtNminimumThumb, &min_thumb,
+ 		     XtNshadowWidth, &shadow_width,
+ 		     NULL);
+       margin = thickness;
+       min_shown_length = min_thumb + 2 * shadow_width;
+       if (whole == 0 || length < 2 * margin + min_shown_length)
+ 	top = 0, shown = 1;
+       else
+ 	{
+ 	  Dimension tzl;
+ 	  float maximum, scale;
+ 
+ 	  tzl = length - margin - margin;
+ 
+ 	  maximum = tzl - min_shown_length;
+ 	  scale = maximum / whole;
+ 	  top = (position * scale) / tzl;
+ 	  shown = (portion * scale + min_shown_length) / tzl;
+ 	}
+       if (top != old_top || shown != old_shown)
+ 	XawScrollbarSetThumb (widget, top, shown);
+     }
+   else
+     {
+ 
    if (whole == 0)
      top = 0, shown = 1;
    else
*************** x_set_toolkit_scroll_bar_thumb (bar, por
*** 4854,4865 ****
--- 4888,5025 ----
  	  }
        }
    }
+ 
+     }
  #endif /* !USE_MOTIF */
  
    UNBLOCK_INPUT;
  }
  #endif /* not USE_GTK */
  
+ /* Handle an X11 event EVENT if it is for the thumb of the scroll bar
+    BAR, and store an input event to *BUFP if necessary.  Return
+    non-zero if the X11 event is handled (i.e., no further handling at
+    the toolkit side needed).  */
+ 
+ static int
+ x_scroll_bar_handle_thumb_event (bar, event, bufp)
+      struct scroll_bar *bar;
+      XEvent *event;
+      struct input_event *bufp;
+ {
+ #if !defined (USE_GTK) && !defined (USE_MOTIF)
+   if (xaw3d_arrow_scroll)
+     switch (event->type)
+       {
+       case ButtonPress:
+ 	{
+ 	  Widget widget = XtWindowToWidget (event->xbutton.display,
+ 					    event->xbutton.window);
+ 	  float top, shown;
+ 	  Dimension length, thickness;
+ 	  XtOrientation orientation;
+ 	  Dimension margin, tzl;
+ 	  Position top_loc, bottom_loc;
+ 	  int pos;
+ 
+ 	  XtVaGetValues (widget, XtNtopOfThumb, &top, XtNshown, &shown,
+ 			 XtNlength, &length, XtNthickness, &thickness,
+ 			 XtNorientation, &orientation,
+ 			 NULL);
+ 	  margin = thickness;
+ 	  if (length > 2 * margin)
+ 	    tzl = length - margin - margin;
+ 	  else
+ 	    tzl = 0;
+ 	  top_loc = margin + (int) (tzl * top);
+ 	  bottom_loc = top_loc + (int) (tzl * shown);
+ 
+ 	  pos = (orientation == XtorientHorizontal
+ 		 ? event->xbutton.x : event->xbutton.y);
+ 	  if (pos >= top_loc && pos <= bottom_loc)
+ 	    {
+ 	      bar->dragging = make_number (- (pos - top_loc) - 1);
+ 	      bar->tracking_thumb_p = 1;
+ 
+ 	      return 1;
+ 	    }
+ 	}
+ 	break;
+ 
+       case ButtonRelease:
+ 	if (bar->tracking_thumb_p)
+ 	  {
+ 	    if (INTEGERP (bar->dragging) && XINT (bar->dragging) >= 0)
+ 	      {
+ 		bufp->kind = SCROLL_BAR_CLICK_EVENT;
+ 		bufp->frame_or_window = bar->window;
+ 		bufp->arg = Qnil;
+ 		bufp->timestamp = event->xbutton.time;
+ 		bufp->part = scroll_bar_end_scroll;
+ 		bufp->code = 0;
+ 		XSETINT (bufp->x, 0);
+ 		XSETINT (bufp->y, 0);
+ 		bufp->modifiers = 0;
+ 	      }
+ 	    bar->dragging = Qnil;
+ 	    bar->tracking_thumb_p = 0;
+ 
+ 	    return 1;
+ 	  }
+ 	break;
+ 
+       case MotionNotify:
+ 	if (bar->tracking_thumb_p)
+ 	  {
+ 	    Widget widget = XtWindowToWidget (event->xmotion.display,
+ 					      event->xmotion.window);
+ 	    Dimension length, thickness, min_thumb, shadow_width;
+ 	    XtOrientation orientation;
+ 	    Dimension margin, min_shown_length, tzl;
+ 	    int pos;
+ 	    int portion, whole;
+ 
+ 	    if (INTEGERP (bar->dragging) && XINT (bar->dragging) < 0)
+ 	      bar->dragging = make_number (- (XINT (bar->dragging) + 1));
+ 
+ 	    XtVaGetValues (widget, XtNlength, &length, XtNthickness, &thickness,
+ 			   XtNminimumThumb, &min_thumb,
+ 			   XtNshadowWidth, &shadow_width,
+ 			   XtNorientation, &orientation,
+ 			   NULL);
+ 	    margin = thickness;
+ 	    min_shown_length = min_thumb + 2 * shadow_width;
+ 	    tzl = length - margin - margin;
+ 
+ 	    pos = (orientation == XtorientHorizontal
+ 		   ? event->xmotion.x : event->xmotion.y);
+ 	    portion = pos - XINT (bar->dragging) - margin;
+ 	    whole = tzl > min_shown_length ? tzl - min_shown_length : tzl;
+ 	    if (portion < 0)
+ 	      portion = 0;
+ 	    if (portion > whole)
+ 	      portion = whole;
+ 
+ 	    bufp->kind = SCROLL_BAR_CLICK_EVENT;
+ 	    bufp->frame_or_window = bar->window;
+ 	    bufp->arg = Qnil;
+ 	    bufp->timestamp = event->xmotion.time;
+ 	    bufp->part = scroll_bar_handle;
+ 	    bufp->code = 0;
+ 	    XSETINT (bufp->x, portion);
+ 	    XSETINT (bufp->y, whole);
+ 	    bufp->modifiers = 0;
+ 	  }
+ 
+ 	return 1;
+ 	break;
+ 
+       default:
+ 	abort ();
+       }
+ #endif	/* !USE_GTK && !USE_MOTIF */
+   return 0;
+ }
  #endif /* USE_TOOLKIT_SCROLL_BARS */
  
  
*************** x_scroll_bar_create (w, top, left, width
*** 4937,4942 ****
--- 5097,5103 ----
    bar->end = 0;
    bar->dragging = Qnil;
    bar->fringe_extended_p = 0;
+   bar->tracking_thumb_p = 0;
  
    /* Add bar to its frame's list of scroll bars.  */
    bar->next = FRAME_SCROLL_BARS (f);
*************** handle_one_xevent (dpyinfo, eventp, fini
*** 6729,6742 ****
            }
          else
            {
- #ifndef USE_TOOLKIT_SCROLL_BARS
              struct scroll_bar *bar
                = x_window_to_scroll_bar (event.xmotion.display,
                                          event.xmotion.window);
  
              if (bar)
                x_scroll_bar_note_movement (bar, &event);
! #endif /* USE_TOOLKIT_SCROLL_BARS */
  
              /* If we move outside the frame, then we're
                 certainly no longer on any text in the frame.  */
--- 6890,6906 ----
            }
          else
            {
              struct scroll_bar *bar
                = x_window_to_scroll_bar (event.xmotion.display,
                                          event.xmotion.window);
  
+ #ifdef USE_TOOLKIT_SCROLL_BARS
+             if (bar && x_scroll_bar_handle_thumb_event (bar, &event, &inev.ie))
+ 	      *finish = X_EVENT_DROP;
+ #else  /* !USE_TOOLKIT_SCROLL_BARS */
              if (bar)
                x_scroll_bar_note_movement (bar, &event);
! #endif	/* !USE_TOOLKIT_SCROLL_BARS */
  
              /* If we move outside the frame, then we're
                 certainly no longer on any text in the frame.  */
*************** handle_one_xevent (dpyinfo, eventp, fini
*** 6891,6896 ****
--- 7055,7063 ----
                  x_scroll_bar_handle_click (bar, &event, &inev.ie);
                  *finish = X_EVENT_DROP;
                }
+ 	    else if (bar
+ 		     && x_scroll_bar_handle_thumb_event (bar, &event, &inev.ie))
+ 	      *finish = X_EVENT_DROP;
  #else /* not USE_TOOLKIT_SCROLL_BARS */
              if (bar)
                x_scroll_bar_handle_click (bar, &event, &inev.ie);
Index: src/xterm.h
===================================================================
RCS file: /sources/emacs/emacs/src/xterm.h,v
retrieving revision 1.217
diff -c -p -r1.217 xterm.h
*** src/xterm.h	21 Oct 2009 18:29:48 -0000	1.217
--- src/xterm.h	9 Nov 2009 20:33:21 -0000
*************** struct scroll_bar
*** 776,781 ****
--- 776,785 ----
    /* 1 if the background of the fringe that is adjacent to a scroll
       bar is extended to the gap between the fringe and the bar.  */
    unsigned int fringe_extended_p : 1;
+ 
+   /* 1 if the toolkit scroll bar thumb is currently being tracked at
+      the Emacs side. */
+   unsigned int tracking_thumb_p : 1;
  };
  
  /* The number of elements a vector holding a struct scroll_bar needs.  */

Re: Scrollbar thumbs

[Jan D.]

On 2009-11-04 21:57, Stefan Monnier wrote:
>>> - Can we locate a thread with the discussion of scrolling with the
>>>    gtk developers?
>> Started here AFAIK:
>> http://lists.gnu.org/archive/html/emacs-devel/2003-03/msg00555.html
>
> Note that the problem is more common than just Gtk.
> So for example some of the discussion around Xaw3d (before the release
> of Emacs-21) is probably relevant as well.
>
> In any case, given how widespread the problem is, it's clear that we
> can't expect the toolkit to adapt to Emacs.  And since nobody has found
> a way yet to make Emacs DTRT, all we can do is provide various
> workarounds, which is what we've done until now.  But what I suggest is
> that instead of each toolkit backend providing its own workaround, we
> should implement the workarounds in the generic code and even implement
> several of them and let the user choose which one suits him best.
>

Wouldn't that imply using just the features that the least able toolkit 
provides?  The native scrollbar does things that can't be done in Gtk+ 
for example (not just overscroll, keybindings as well).

	Jan D.

Re: Scrollbar thumbs

[Stefan Monnier]

>> In any case, given how widespread the problem is, it's clear that we
>> can't expect the toolkit to adapt to Emacs.  And since nobody has found
>> a way yet to make Emacs DTRT, all we can do is provide various
>> workarounds, which is what we've done until now.  But what I suggest is
>> that instead of each toolkit backend providing its own workaround, we
>> should implement the workarounds in the generic code and even implement
>> several of them and let the user choose which one suits him best.

> Wouldn't that imply using just the features that the least able toolkit
> provides?  The native scrollbar does things that can't be done in Gtk+ for
> example (not just overscroll, keybindings as well).

I don't think so.  It just means to centralize the workarounds (which
mostly have to do with how the thumb size and position are computed and
where/when they're updated) without impacting anything else of
the functionality.


        Stefan

Re: Scrollbar thumbs

[grischka]

> In any case, given how widespread the problem is, it's clear that we
> can't expect the toolkit to adapt to Emacs.  And since nobody has found
> a way yet to make Emacs DTRT, all we can do is provide various
> workarounds, which is what we've done until now.  But what I suggest is
> that instead of each toolkit backend providing its own workaround, we
> should implement the workarounds in the generic code and even implement
> several of them and let the user choose which one suits him best.
> 
> 
>        Stefan

I guess it is a good idea. If you want to get rid of stuff, throw it 
all in one place, first.

Seen that nowadays the gui-dyslexics tend to become a more rare species 
and the generation simply tends to loose the ability to understand 
that a non-linear, moreover non-contiguous and even non-complementary 
geometrical relation between scrollbar and scrollable content can be 
anything else than an accumulation of design flaws.

--- grischka

Re: Scrollbar thumbs

[Lennart Borgman]

On Thu, Nov 5, 2009 at 4:16 PM, grischka <grishka@gmx.de> wrote:
>> In any case, given how widespread the problem is, it's clear that we
>> can't expect the toolkit to adapt to Emacs.  And since nobody has found
>> a way yet to make Emacs DTRT, all we can do is provide various
>> workarounds, which is what we've done until now.  But what I suggest is
>> that instead of each toolkit backend providing its own workaround, we
>> should implement the workarounds in the generic code and even implement
>> several of them and let the user choose which one suits him best.
>>
>>
>>       Stefan
>
> I guess it is a good idea. If you want to get rid of stuff, throw it all in
> one place, first.
>
> Seen that nowadays the gui-dyslexics tend to become a more rare species and
> the generation simply tends to loose the ability to understand that a
> non-linear, moreover non-contiguous and even non-complementary geometrical
> relation between scrollbar and scrollable content can be anything else than
> an accumulation of design flaws.


Maybe the gui-dyslexics are getting fewer, but did not Stefan in the
discussion from some years ago point to that the gui part is broken
due to the incapability of some of the scroll bar api:s?

Re: Scrollbar thumbs

[Óscar Fuentes]

"grischka" <grishka@gmx.de> writes:

> Seen that nowadays the gui-dyslexics tend to become a more rare
> species and the generation simply tends to loose the ability to
> understand that a non-linear, moreover non-contiguous and even
> non-complementary geometrical relation between scrollbar and
> scrollable content can be anything else than an accumulation of design
> flaws.

Sure, the Real World is slowly adapting to the rules stated by some
illuminated GUI toolkit designers.

:-/

-- 
Óscar

Re: Scrollbar thumbs

[David Kastrup]

"grischka" <grishka@gmx.de> writes:

> Seen that nowadays the gui-dyslexics

Could you look up complex words in the dictionary before you use them?
It might help to make your postings less inflammatory.

> tend to become a more rare species

dyslexia is not coupled to species.

> and the generation simply tends to loose the ability to understand

While you have the dictionary at hand, look up "loose".

> that a non-linear, moreover non-contiguous

And "contiguous".

> and even non-complementary

And "complementary".

> geometrical relation between scrollbar and scrollable content can be
> anything else than an accumulation of design flaws.

The "design flaw" is that Emacs has a variable line height.  An editor
is primarily supposed to deal with lines of text, not with continuous
graphical panes.  And previous to Emacs 21, Emacs only dealt with lines
of text of constant height.  Previous to Emacs 19, the lines
corresponded 1:1 to the screen lines.

None of those bear any relation to the fact that an editor can show
areas that are not part of the content (most trivially for an empty
file), and that should reflect on the scrollbar appearance.  A web
browser will just remove the scrollbar altogether.  But that is just
feasible for static content, and when the changing of the layout when a
scrollbar is added and removed is not disconcerting.

Also, defining some model of correctness and then adhering to it needs
to take interactive responsiveness into consideration.  The typical web
document does not contain millions of lines, but Emacs must be able to
deal with navigating and changing stuff in documents of that size.

Anyway: if you want to achieve something, chances are that choosing a
manner of correspondence that sports a less condescending appearance
might be beneficial.  Chances are that people working decades in a
particular area of expertise have all that time just been missing the
advice of a complete newcomer.

And if you are convinced of the opposite, common sense should tell you
that such a severe case should need rather more than less diplomacy to
deal with.

-- 
David Kastrup

Re: Scrollbar thumbs

[Jason Rumney]

David Kastrup wrote:

> The "design flaw" is that Emacs has a variable line height.  An editor
> is primarily supposed to deal with lines of text, not with continuous
> graphical panes.  And previous to Emacs 21, Emacs only dealt with lines
> of text of constant height.  Previous to Emacs 19, the lines
> corresponded 1:1 to the screen lines.
>   
Even Emacs 19 had line wrapping, so counting CR characters as the file 
is read (as some simple text editors do) has never been the solution to 
this problem.  The only solution seems to be to render the entire buffer 
offscreen in background, adjusting the scrollbar as we get more detailed 
information about the real contents of the buffer.  This is what word 
processors, web browsers and other complex applications do - you see the 
first page quite quickly, then you see the scroll bar growing as it 
renders the buffer in background.  Most applications do not even make an 
initial guess, so you cannot scroll to the bottom of the buffer until 
the background rendering is finished. The application then needs to use 
extra memory to cache the metrics it has calculated to avoid having to 
rerender the entire document on every change.

Re: Scrollbar thumbs

[Miles Bader]

Jason Rumney <jasonr@gnu.org> writes:
> Even Emacs 19 had line wrapping, so counting CR characters as the file
> is read (as some simple text editors do) has never been the solution to
> this problem.  The only solution seems to be to render the entire buffer
> offscreen in background

Yes.  In other words, a complete (and _massive_ in terms of code) change
in Emacs' internal model, to one which is more complex (lots of caching)
and hugely impractical for very large files.

The toolkit change, by contrast, is apparently quite small, and would
simply make the toolkit allow more application flexibility.  No existing
GTK apps would be affected.  AFAICT, the only reason GTK _hasn't_
changed is because of a dogmatic refusal to believe any model except
their own is valid.

Even if every Emacs author suddenly decided they _wanted_ to rewrite
Emacs to accommodate GTK, it wouldn't happen, simply because it's not
even remotely practical.  But as I understand it, GTK could easily
change given a decision to allow it.

I think GTK is in general, a pretty nice toolkit, but not every
application is exactly The Gimp, and this sort of head-in-the-sand
behavior is very disheartening.

-Miles

-- 
Year, n. A period of three hundred and sixty-five disappointments.

Re: Scrollbar thumbs

[Stephen J. Turnbull]

Jason Rumney writes:
 > David Kastrup wrote:
 > 
 > > The "design flaw" is that Emacs has a variable line height.  An editor
 > > is primarily supposed to deal with lines of text, not with continuous
 > > graphical panes.  And previous to Emacs 21, Emacs only dealt with lines
 > > of text of constant height.  Previous to Emacs 19, the lines
 > > corresponded 1:1 to the screen lines.
 > >   
 > Even Emacs 19 had line wrapping, so counting CR characters as the file 
 > is read (as some simple text editors do) has never been the solution to 
 > this problem.

AFAICT XEmacs counts *characters*, not lines.  This means that a page
with lots of empty lines gets a smaller thumb than one with almost all
lines full-width.  (It's observable that the thumbs change size.)
This would also give consistent results between long-lines support
(ie, proper wrapping of newline-delimited paragraphs) and conventional
newline-delimited lines.  Of course it's not possible to jump to a
particular page in this algorithm, but modern apps don't seem to do
this with scrollbars anymore anyway.  They provide a separate tray of
thumbnails (which gets its own scrollbar).

I don't recall seeing a question about this on XEmacs channels, nor
complaints that scrollbars function differently on different platforms.

 > The only solution seems to be to render the entire buffer offscreen
 > in background, adjusting the scrollbar as we get more detailed
 > information about the real contents of the buffer.  This is what
 > word processors, web browsers and other complex applications do -
 > you see the first page quite quickly, then you see the scroll bar
 > growing as it renders the buffer in background.  Most applications
 > do not even make an initial guess, so you cannot scroll to the
 > bottom of the buffer until the background rendering is
 > finished.

That is not acceptable on a 128MB log file, though.  Typically what
you want to look at *first* is the end of the file.

 > The application then needs to use extra memory to cache the metrics
 > it has calculated to avoid having to rerender the entire document
 > on every change.

This is a big deal?  All you need is the heights of the pages.  You
recalculate spillage into or out of the current page as you redisplay,
the previous pages don't change at all, and you approximate the later
pages as not having changed length.

Re: Scrollbar thumbs

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> AFAICT XEmacs counts *characters*, not lines.

That's what Emacs does too, and it gives good, usable results while
working naturally with Emacs rendering.  The problem, of course is that
(as you note) it _also_ results in scrollbar size varying depending on
your location, and GTK's scrollbar does not allow this, although it
could easily do so, apparently because they believe all apps should
rigidly use "vertical height" metrics for scrollbars, no exceptions
permitted.

-Miles

-- 
I'd rather be consing.

Re: Scrollbar thumbs

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup wrote:
>
>> The "design flaw" is that Emacs has a variable line height.  An editor
>> is primarily supposed to deal with lines of text, not with continuous
>> graphical panes.  And previous to Emacs 21, Emacs only dealt with lines
>> of text of constant height.  Previous to Emacs 19, the lines
>> corresponded 1:1 to the screen lines.
>>   
> Even Emacs 19 had line wrapping, so counting CR characters as the file
> is read (as some simple text editors do) has never been the solution
> to this problem.  The only solution seems to be to render the entire
> buffer offscreen in background, adjusting the scrollbar as we get more
> detailed information about the real contents of the buffer.  This is
> what word processors, web browsers and other complex applications do -
> you see the first page quite quickly, then you see the scroll bar
> growing as it renders the buffer in background.  Most applications do
> not even make an initial guess, so you cannot scroll to the bottom of
> the buffer until the background rendering is finished. The application
> then needs to use extra memory to cache the metrics it has calculated
> to avoid having to rerender the entire document on every change.

Actually, the inability to get such an application in combination with
the castrated scroll bar semantics scroll half a screen down is quite
annoying.  The only way you can scroll a half-screen (without
Athena-style scrollbar behavior) is by dragging, and particularly
dragging in large documents while the scrollbar self-updates is utterly
haphazard.  Usually you completely use your place.

I don't see that this is a useful model of behavior for an editor.

-- 
David Kastrup

Re: Scrollbar thumbs

[Eli Zaretskii]

> Date: Fri, 06 Nov 2009 07:55:51 +0800
> From: Jason Rumney <jasonr@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> The only solution seems to be to render the entire buffer offscreen
> in background, adjusting the scrollbar as we get more detailed
> information about the real contents of the buffer.  This is what
> word processors, web browsers and other complex applications do -
> you see the first page quite quickly, then you see the scroll bar
> growing as it renders the buffer in background.

Except that in Emacs, such rendering would be prohibitively expensive,
even for moderate size files, because we have display features that
those other word processors don't even dream of when displaying plain
text files, and those features are designed and implemented in a way
that is completely incompatible with rendering everything at once.

Doing the above will probably mean a complete redesign and rewrite of
the display engine.  And for what? for satisfying a few purists that
cannot live with marginally weird behavior of the scroll bar?

Re: Scrollbar thumbs

[Stefan Monnier]

> I guess it is just that these GUI toolkit people usually are trained to
> deliver good looking and pixel-precise artwork and in consequence might have
> some difficulties to imagine how it can be "pretty much impossibe" for some
> editor to know how many lines it is actually displaying (or anyway that such
> editor would still want to use their scrollbars).

No, sadly, it is really due to dogma: your above explanation would make
perfect sense, but in practice, even after showing them our problem,
they still insist that it would be wrong for them to remove the chunks
of code that enforce the "scrollbar metaphor" by preventing the client
from getting the events that indicate that the user wants to move the
thumb's bottom further down than the scrollbar's own bottom.


        Stefan

Re: Scrollbar thumbs

[grischka]

>> I guess it is just that these GUI toolkit people usually are trained to
>> deliver good looking and pixel-precise artwork and in consequence might have
>> some difficulties to imagine how it can be "pretty much impossibe" for some
>> editor to know how many lines it is actually displaying (or anyway that such
>> editor would still want to use their scrollbars).
> 
> No, sadly, it is really due to dogma: your above explanation would make
> perfect sense, but in practice, even after showing them our problem,
> they still insist that it would be wrong for them to remove the chunks
> of code that enforce the "scrollbar metaphor" by preventing the client
> from getting the events that indicate that the user wants to move the
> thumb's bottom further down than the scrollbar's own bottom.

I don't see any dogma beyond the dogma of consistent design which is not 
something a toolkit designer can be blamed for.

Also by saying "our problem" you already realized that is your problem 
and not theirs.  In a free world, why should they cripple their code 
just to save you from having to find the right solution within your own
program.  That would be two times wrong.

--- grischka

Re: Scrollbar thumbs

[Stefan Monnier]

> I don't see any dogma beyond the dogma of consistent design which is not
> something a toolkit designer can be blamed for.

It has nothing to do with consistent design.

> Also by saying "our problem" you already realized that is your problem and
> not theirs.  In a free world, why should they cripple their code just to
> save you from having to find the right solution within your own
> program.  That would be two times wrong.

We're not talking about crippling anybody's code other than ours.
They specifically add code which has no effect for 99% of the clients
and which prevents Emacs from working correctly.  Removing that code
wouldn't cripple anyone.


        Stefan

Re: Scrollbar thumbs

[grischka]

>> I don't see any dogma beyond the dogma of consistent design which is not
>> something a toolkit designer can be blamed for.
> 
> It has nothing to do with consistent design.

Surely it has.

>> Also by saying "our problem" you already realized that is your problem and
>> not theirs.  In a free world, why should they cripple their code just to
>> save you from having to find the right solution within your own
>> program.  That would be two times wrong.
> 
> We're not talking about crippling anybody's code other than ours.
> They specifically add code which has no effect for 99% of the clients
> and which prevents Emacs from working correctly.  Removing that code
> wouldn't cripple anyone.

Well, extra code that prevents clients from doing unwanted things exists 
all over the place in APIs and the point of such code is that it has no 
effect under normal usage.

And the consistency aspect of "normal usage" being defined is simply 
that widgets are there to provide a consistent look & feel across 
applications.  It seems inconsequent if on one hand you want to use 
a widget but on the other hand want to use it differently to 99% of 
the other clients.  Then you'd better invent your own.

--- grischka

Re: Scrollbar thumbs

[Stefan Monnier]

> And the consistency aspect of "normal usage" being defined is simply that
> widgets are there to provide a consistent look & feel across applications.
> It seems inconsequent if on one hand you want to use a widget but on the
> other hand want to use it differently to 99% of the other clients.

I don't want to use it differently.  I only need to implement the check
in my own code rather than in theirs because doing it in theirs makes it
impossible for me to provide the behavior they want to see.


        Stefan

Re: Scrollbar thumbs

[grischka]

>> And the consistency aspect of "normal usage" being defined is simply that
>> widgets are there to provide a consistent look & feel across applications.
>> It seems inconsequent if on one hand you want to use a widget but on the
>> other hand want to use it differently to 99% of the other clients.
> 
> I don't want to use it differently.  I only need to implement the check 
> in my own code rather than in theirs because doing it in theirs makes it 
> impossible for me to provide the behavior they want to see.

It cannot be impossible to get standard behavior (no matter what it is) 
with the standard API, because otherwise the behavior would hardly spread 
enough to become standard :)

--- grischka

Re: Scrollbar thumbs

[Stefan Monnier]

> It cannot be impossible to get standard behavior (no matter what it is) with
> the standard API, because otherwise the behavior would hardly spread enough
> to become standard :)

I'll be waiting for your patch that proves it,


        Stefan

Re: Scrollbar thumbs

[joakim]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I guess it is just that these GUI toolkit people usually are trained to
>> deliver good looking and pixel-precise artwork and in consequence might have
>> some difficulties to imagine how it can be "pretty much impossibe" for some
>> editor to know how many lines it is actually displaying (or anyway that such
>> editor would still want to use their scrollbars).
>
> No, sadly, it is really due to dogma: your above explanation would make
> perfect sense, but in practice, even after showing them our problem,
> they still insist that it would be wrong for them to remove the chunks
> of code that enforce the "scrollbar metaphor" by preventing the client
> from getting the events that indicate that the user wants to move the
> thumb's bottom further down than the scrollbar's own bottom.
>
>
>         Stefan
>

I dont use scrollbars, so I dont really know, but would it be possible
to subclass the gtk scrollbars to achive our desired behaviour?
-- 
Joakim Verona

Re: Scrollbar thumbs

[Jan D.]

On 2009-11-03 11:02, joakim@verona.se wrote:
> Stefan Monnier<monnier@iro.umontreal.ca>  writes:
>
>>> I guess it is just that these GUI toolkit people usually are trained to
>>> deliver good looking and pixel-precise artwork and in consequence might have
>>> some difficulties to imagine how it can be "pretty much impossibe" for some
>>> editor to know how many lines it is actually displaying (or anyway that such
>>> editor would still want to use their scrollbars).
>>
>> No, sadly, it is really due to dogma: your above explanation would make
>> perfect sense, but in practice, even after showing them our problem,
>> they still insist that it would be wrong for them to remove the chunks
>> of code that enforce the "scrollbar metaphor" by preventing the client
>> from getting the events that indicate that the user wants to move the
>> thumb's bottom further down than the scrollbar's own bottom.
>>
>>
>>          Stefan
>>
>
> I dont use scrollbars, so I dont really know, but would it be possible
> to subclass the gtk scrollbars to achive our desired behaviour?

I looked at it once, but no.  You can't override the basic event 
handling in scrollbars, so you still won't get any events when the thumb 
hit the bottom.

	Jan D.

Customizing the mode line

[Eli Zaretskii]

Do we have some convenient UI for customizing the mode line?  The user
manual doesn't mention any.

I frequently find myself in a situation where the information that's
important to me is pushed beyond the right edge of the mode line, and
is thus invisible.  Annoyingly, a large part of the real estate of the
mode line is taken by information that is much less important, like
the percentage of the file before the window start and the list of
minor modes in effect.  The latter, for example, is quite static in
any given buffer, so once you saw it for the first time, there's no
need to continue showing it in such a central place.  However, even in
a C buffer, the mode shown is "C/l Abbrev", which is quite long.  And
when I read mail, I see something like "RMAIL XXXX/YYYY answered,
deleted"; when replying to mail it's "Mail Fly Abbrev Fill", etc.
These are very long strings that I don't need to see all the time,
because they almost never change.  But they steal too much precious
space.

By contrast, dynamic information such as the current time, the system
load, the battery condition, the mail indicator, the current function
(when in which-func-mode), etc. -- these are banished off the edge of
the mode line, and cannot be consulted.  This effectively makes these
features unavailable, unless one is willing to make her frames
unreasonably wide or even full-screen.

I consider this a bad misfeature.  What's more, modifying what's in
the mode line is not an easy task (unless I'm missing something): it
boils down to reading bindings.el and manually setting various parts
of standard-mode-line-* variables to remove or rearrange what is
shown.

Can we make the mode line display more ergonomic, or at least more
customizable?  Should I file a "wish-list" bug for this?

Re: Customizing the mode line

[Stefan Monnier]

> Can we make the mode line display more ergonomic, or at least more
> customizable?

I hope so, although I don't know how right now.

> Should I file a "wish-list" bug for this?

Yes, please (such requests have already appeared in the past, actually,
tho it was before the bugtracker, I guess).

> information that is much less important, like
> the percentage of the file before the window start

I indeed never look at it, but I'm uneasy removing it: basically I find
it redundant when you have scrollbars, but in case you don't have
scrollbars (e.g. in a non-GUI terminal) it's not redundant (but I got
so used to using the scrollbars that it never occurs to me to look at
the modeline for that info.  Actually, I do look at the mode-line when
I need to figure out "where am I" but then I look at the line number
rather than the percentage).

What do other people think about it?

> I frequently find myself in a situation where the information that's
> important to me is pushed beyond the right edge of the mode line, and
> is thus invisible.  Annoyingly, a large part of the real estate of the
> mode line is taken by information that is much less important, like
> the percentage of the file before the window start and the list of
> minor modes in effect.  The latter, for example, is quite static in
> any given buffer, so once you saw it for the first time, there's no
> need to continue showing it in such a central place.  However, even in
> a C buffer, the mode shown is "C/l Abbrev", which is quite long.  And
> when I read mail, I see something like "RMAIL XXXX/YYYY answered,
> deleted"; when replying to mail it's "Mail Fly Abbrev Fill", etc.
> These are very long strings that I don't need to see all the time,
> because they almost never change.  But they steal too much precious
> space.

I think the major-mode/minor mode display is important, but I agree that
it often takes up a lot of space to display unchanging info.  It would
be good to come up with some way to make it more space efficient.
Maybe we could replace "(Mail Fly Abbrev Fill)" with "(Mail..FAF)" and
then expand the FAF to "Fly Abbrev Fill" in a tooltip.

Maybe we should also come up with a scheme to shrink the displayed
buffer-name if it exceeds some number of chars.

> By contrast, dynamic information such as the current time, the system
> load, the battery condition, the mail indicator, the current function
> (when in which-func-mode), etc.

I'd separate which-func-mode from the others because it is
buffer-specific whereas the others are system-global, so the others
really just shouldn't be displayed in each and every mode-line (that's
a waste of very scarce resource).

So there are two problems:
- how/where to display global properties such as time, system load, mail
  indicator, ...
- how to make sure which-func-mode gets displayed in a visible part of
  the modeline.

Another thing we could consider is a generic "make the modeline fit"
feature: after building the complete unshrunk modeline, we look at its
length and if it exceeds the window's width, we shrink it
"intelligently" (e.g. using shrink functions provided via
text-properties on the various parts of the modeline).

> I consider this a bad misfeature.  What's more, modifying what's in
> the mode line is not an easy task (unless I'm missing something): it
> boils down to reading bindings.el and manually setting various parts
> of standard-mode-line-* variables to remove or rearrange what is
> shown.

Yes, modifying the mode-line is a pain.  I think it's more important to
improve the default mode-line, but I agree that we also want to make it
easier to customize it.


        Stefan

Re: Customizing the mode line

[Manoj Srivastava]

On Fri, Oct 30 2009, Stefan Monnier wrote:


>> information that is much less important, like
>> the percentage of the file before the window start
>
> I indeed never look at it, but I'm uneasy removing it: basically I find
> it redundant when you have scrollbars, but in case you don't have
> scrollbars (e.g. in a non-GUI terminal) it's not redundant (but I got
> so used to using the scrollbars that it never occurs to me to look at
> the modeline for that info.  Actually, I do look at the mode-line when
> I need to figure out "where am I" but then I look at the line number
> rather than the percentage).

> What do other people think about it?

        I am not a emacs developer, but as a long time user I would
 prefer to have the percentages instead of the scrollbar, if there were
 a choice (I know there is not). But I would much rather preserve the
 percentages.

        I also find the scrollbar somewhat confusing: When the end of
 buffer is visible in the window, I would expect the scrollbar to reach
 all the way to the bottom, but it does not.

> I think the major-mode/minor mode display is important, but I agree that
> it often takes up a lot of space to display unchanging info.  It would
> be good to come up with some way to make it more space efficient.
> Maybe we could replace "(Mail Fly Abbrev Fill)" with "(Mail..FAF)" and
> then expand the FAF to "Fly Abbrev Fill" in a tooltip.

        How would this work on a non-windowed environment? Could a
 mechanism be devised to show the minor modes on user request, say, in
 the minibuffer?

        manoj
-- 
The major sin is the sin of being born. Samuel Beckett
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Scrollbar thumbs (was: Customizing the mode line)

[Stefan Monnier]

>         I also find the scrollbar somewhat confusing: When the end of
>  buffer is visible in the window, I would expect the scrollbar to reach
>  all the way to the bottom, but it does not.

It does with some GUI and not with others.  In principle it should.
The only reason for it not to is to try and work around problems when
dragging the scrollbar thumb, where many GUI toolkits are absurdly
dogmatic and make it pretty much impossible for Emacs to do what
it should.

The more I see it, the more I think that rather than let the GUI code
make this choice, we should have it be in the generic part of the code
and the GUI code only chooses the default value, so users can choose to
have a half-working drag-scroll if they prefer it (because it gives them
proper display of the thumb size and position in return).


        Stefan