etc/TODO:Horizontal scrollbar

etc/TODO:Horizontal scrollbar

[Dhruva Krishnamurthy]

Hi,
 Is there anyone working on the horizontal scrollbar for GNU Emacs? Can
 someone guide me if I take it up?

Some background:
1. I got a horizontal scrollbar on W2K specific build and wrote empty
methods to get control when horizontal scrollbar moves.

It really did not look nice to me. There is a modeline and then you have
scrollbar. It was cluttring when you use the mini-buffer.
Could we use the modeline as a scrollbar instead of coming up with a real
horizontal scroll bar?

Please guide me in this regard.

with best regards,
dhruva
-- 
Dhruva Krishnamurthy
Home: http://www32.brinkster.com/schemer/

Re: etc/TODO:Horizontal scrollbar

[Robert J. Chassell]

   1. I got a horizontal scrollbar ...

   It really did not look nice to me. ...  Could we use the modeline
   as a scrollbar instead of coming up with a real horizontal scroll
   bar?

This is great!  We have needed a horizontal scrollbar for a long time.

If you use the modeline, please leave it mostly as is, since it is
useful.

On a bitmapped display, you could indicate the part of the window that
is visible by indenting or exdenting the modeline a little bit, like
this, where the indented portion is visible in the window:

    _________          ______
             \________/  

    --:--    *mail*
              _________
    _________/         \_____


(A decade or more ago, I suggested that you could mark segments of a
text, such as the beginning of a chapter in Texinfo, or a major part
difference in a source library by using indentation, or another type
of mark, on a vertical scroll bar.  This would be in addition to the
current `thumb' that marks the text visible in the window.  I have
often thought that like the current `thumb', such an indicator would
be a useful and unobstrusive help.  But I don't know enough to do this
myself.)

On a character-only display, you will need a separate mode line,
since you cannot manipulate bits.

In that case, the display might look like this, where the portion
marked by uppercase letters is visible in the window:

    xxxxxxxxxXXXXXXXXXXxxxxx
    ----:---F1    *mail*

I don't know how to mark a horizontal scroll bar for people who listen
rather than look (the permanently and the situationally blind).  How
do eyes-free people handle the current vertical scroll bar; do they
turn it off?

Now all we need is to be able to address a display as
`remote.machine.com:pts/7' or `remote.machine.com:tty4' as well as
`remote.machine.com:1.0' and Emacs will become a very nice program for
group work over slow connections.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: etc/TODO:Horizontal scrollbar

[Luc Teirlinck]

Dhruva Krishnamurthy wrote:

   Could we use the modeline as a scrollbar instead of coming up with a real
   horizontal scroll bar?

How would scolling work or would the `modeline-scrollbar' be strictly
informational?

Sincerely,

Luc.

Re: etc/TODO:Horizontal scrollbar

[Frank Schmitt]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Dhruva Krishnamurthy wrote:
>
>    Could we use the modeline as a scrollbar instead of coming up with a real
>    horizontal scroll bar?
>
> How would scolling work or would the `modeline-scrollbar' be strictly
> informational?

Perhaps like in XFig? Right-Click on scrollbar-area of the modeline
scrolls to the right, left-click to the left?

-- 
WANTED: A nice signature
REWARD: none

Re: etc/TODO:Horizontal scrollbar

[Luc Teirlinck]

Frank Schmitt wrote:

   Perhaps like in XFig? Right-Click on scrollbar-area of the modeline
   scrolls to the right, left-click to the left?

The most logical behavior for a horizontal scroll-bar would be
analogous to the vertical one.  (Where there is the potential problem
that that behavior seems to depend on the actual scroll-bar used.)

However, the problem is that the proposal is to use the modeline as
the scroll-bar.  Hence unmodified mouse-1, 2 and 3 are off-limits since
they are already bound (actually, already bound to too many things at
once, for my taste).

Sincerely,

Luc.

Re: etc/TODO:Horizontal scrollbar

[Richard Stallman]

    It really did not look nice to me. There is a modeline and then you have
    scrollbar.

It seems that the horizontal scroll bar should be above the mode line.

	       It was cluttring when you use the mini-buffer.

I don't understand that part; you said how you felt about the
behavior, but not what the specific behavior you saw.

    Could we use the modeline as a scrollbar instead of coming up with a real
    horizontal scroll bar?

That is a bizarre idea, worth thinking about.  We could put arrows
into the mode line that could be used for scrolling.  That would be
fairly easy, I think.  However, it can't be an actual scroll bar,
since there is no room to display a slider.

Re: etc/TODO:Horizontal scrollbar

[Richard Stallman]

    On a character-only display, you will need a separate mode line,
    since you cannot manipulate bits.

We don't support vertical scroll bars on character-only displays, so I
think we may as well not support horizontal scrollbars there either.

Re: etc/TODO:Horizontal scrollbar

[Dhruva Krishnamurthy]

On Thu, 03 Jul 2003 11:48:21 -0400, "Richard Stallman" <rms@gnu.org>
said:
>     On a character-only display, you will need a separate mode line,
>     since you cannot manipulate bits.
> 
> We don't support vertical scroll bars on character-only displays, so I
> think we may as well not support horizontal scrollbars there either.
> 
I now get a fair idea regarding the way I should proceed. I plan to do
the following things.

1. I will try to work only on W2K port (maybe using Win32 API support if
needed)
2. Later spend time on using the GNU Emacs vertical scrolling methods
which is well ported
3. I will scroll based on pixels and NOT on charecters (to avoid problems
in variable width chars)
    We could try to handle charecter based scrolling later.
4. I will not concentrate on the THUMB display etc for the first shot I
take but will refine as I progress.
5. I guess using the MODELINE is ruled out as all MOUSE buttons are
bound. We could have an area on the modeline where we bind it to
scrolling though. I will send an image for those interested with the
horizontal scroll-bar under the minibuffer. It looks like the minibuffer
is sandwiched between the modeline and the horizontal scroll-bar. Just
imagine when you type a long line in the modeline, the horizontal
scroll-bar's THUMB is moving/scrolling. It is quite distracting. This is
my opinion though.

Once I get a basic version ready (I do not have CVS as I am behind a
proxy-firewall), I will send the related files (tared and gziped) to
interested developers on MS Windows to try it and give me a feedback.
This is my first development in GNU Emacs, I need plenty of help when it
comes to redisplay, paning/(horizontally moving) the buffer contents.

with best regards,
dhruva
-- 
Dhruva Krishnamurthy
Home: http://www32.brinkster.com/schemer/

Re: etc/TODO:Horizontal scrollbar

[Robert J. Chassell]

   .... It looks like the minibuffer is sandwiched between the
   modeline and the horizontal scroll-bar.

This is only if you use one window at a time, rather than two or more.
As is, the statement does not make sense.  Are you trying to say that

   .... It looks like the minibuffer is below the horizontal
   scroll-bar and modeline.

?

Moreover, a mode line separates two windows.  It indicates the bottom
of the window above it.  The minibuffer is not relevant.

Putting the horizontal scroll-bar below a mode line means putting it
in the `other buffer', the one that is displayed in the window below
the mode line.  The horizontal scroll-bar should go above the
mode-line, either next to it or at the other end (the `top' end) of
the window.

In any event, just as you can set the value of vertical-scroll-bar to
left, right, nil, or t, so you should be able to set the value of
horizontal-scroll-bar to top, bottom, nil, or t.  (Presumably, you
will also need a variable for the `bottom' case in a windowing
display, to specify whether the scroll bar is separate from the mode
line, or is part of the mode line, perhaps shown as I suggested.)

   ... Just imagine when you type a long line in the modeline, the
   horizontal scroll-bar's THUMB is moving/scrolling. It is quite
   distracting.

I do not understand you.  When I type many vertical lines, I don't
find it distracting for the vertical scroll-bar's slider or thumb to
move; indeed, I hardly notice it, but when I want to see it, it is
there and I want it to move or have moved.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: etc/TODO:Horizontal scrollbar

[Luc Teirlinck]

Dhruva Krishnamurthy wrote:
   
   I will send an image for those interested with the
   horizontal scroll-bar under the minibuffer. It looks like the minibuffer
   is sandwiched between the modeline and the horizontal scroll-bar. Just
   imagine when you type a long line in the modeline, the horizontal
   scroll-bar's THUMB is moving/scrolling. It is quite distracting. This is
   my opinion though.

All of this only seems to apply to the minibuffer's horizontal
scroll-bar.  It would appear that only windows in which truncation is
in effect should get a horizontal scroll-bar.  (I do not see what
sense it makes for windows that use continuation lines.)  For most
people, it seems that horizontal scroll-bars would only be used in
vertically split windows.  (And thus not in the minibuffer.)  For
people who have truncate-lines set to t, it might be possible to
design the variable horizontal-scroll-bar-mode such that it would be
possible to exclude the minibuffer from the list of windows getting a
horizontal scroll-bar, assuming that it looks really that annoying.

Sincerely,

Luc.

Re: etc/TODO:Horizontal scrollbar

[Luc Teirlinck]

Kim Storm wrote:
   
   What about splitting the existing modeline into two parts:  
	   a scroll-bar part with a width equal to, say, 10 characters,
	   a text part corresponding to the current mode line.

Except for the fact that horizontal scrolling is probably mainly
useful in smaller-than-usual width windows.   How much of a mode line
is going to remain?  I already often wind up having large chunks of
the mode line hidden in full sized windows.

Sincerely,

Luc.

Re: etc/TODO:Horizontal scrollbar

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Dhruva Krishnamurthy wrote:
>    
>    I will send an image for those interested with the
>    horizontal scroll-bar under the minibuffer. It looks like the minibuffer
>    is sandwiched between the modeline and the horizontal scroll-bar. Just
>    imagine when you type a long line in the modeline, the horizontal
>    scroll-bar's THUMB is moving/scrolling. It is quite distracting. This is
>    my opinion though.
> 
> All of this only seems to apply to the minibuffer's horizontal
> scroll-bar.  It would appear that only windows in which truncation is
> in effect should get a horizontal scroll-bar.  (I do not see what
> sense it makes for windows that use continuation lines.)

That's true .. just like a vertical scroll bar is really unnecessary
for a buffer which fits entirely in its window...

> For most
> people, it seems that horizontal scroll-bars would only be used in
> vertically split windows.  (And thus not in the minibuffer.)  For
> people who have truncate-lines set to t, it might be possible to
> design the variable horizontal-scroll-bar-mode such that it would be
> possible to exclude the minibuffer from the list of windows getting a
> horizontal scroll-bar, assuming that it looks really that annoying.

The latest "big changes" I made allow vertical scroll bars to be
configured "per-window" and "per-buffer"; of course, vertical scroll
bars should be equally flexible.

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

Re: etc/TODO:Horizontal scrollbar

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Frank Schmitt wrote:
> 
>    Perhaps like in XFig? Right-Click on scrollbar-area of the modeline
>    scrolls to the right, left-click to the left?
> 
> The most logical behavior for a horizontal scroll-bar would be
> analogous to the vertical one.  (Where there is the potential problem
> that that behavior seems to depend on the actual scroll-bar used.)
> 
> However, the problem is that the proposal is to use the modeline as
> the scroll-bar.  Hence unmodified mouse-1, 2 and 3 are off-limits since
> they are already bound (actually, already bound to too many things at
> once, for my taste).

There's another alternative to having the vertical scroll bar on
a line of its own:

What about splitting the existing modeline into two parts:  
        a scroll-bar part with a width equal to, say, 10 characters,
        a text part corresponding to the current mode line.

Something like this:

  | |
  | |
  |_|
  |v|
    |<|   ||    |>|-=?**  c.c    etc.  ----------


when the vertical scroll bar is at the left, and


                                              | |
                                              | |
                                              | |
                                              |_|
                                              |v|
  -=?**  c.c    etc.  ----------|<|   ||    |>|


when the vertical scroll bar is on the right.



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

Re: etc/TODO:Horizontal scrollbar

[Richard Stallman]

    1. I will try to work only on W2K port (maybe using [Windows]32
    API support if needed)

I don't like the idea of installing any feature in a GNU package that
works only on Windows.  That is a very dangerous path to go down.
It's part of the GNU project standards that every GNU package should
run best on the GNU system.

Can you implement X support also at the same time?

Alternatively, when you get it running on Windows, someone else who
would like to make it work on GNU/Linux could get the code from you.

    5. I guess using the MODELINE is ruled out as all MOUSE buttons are
    bound. We could have an area on the modeline where we bind it to
    scrolling though.

We could do that, but it has little to do with horizontal scroll
bars, so don't worry about it.

    It looks like the minibuffer
    is sandwiched between the modeline and the horizontal scroll-bar.

That is a strange place to put the horizontal scroll-bar.  Did you
make just one per frame?  There should be a horizontal scroll-bar in each
window, just as there is a vertical scroll-bar in each window.
It ought to be above the window's mode line.

Re: etc/TODO:Horizontal scrollbar

[Richard Stallman]

    All of this only seems to apply to the minibuffer's horizontal
    scroll-bar.  It would appear that only windows in which truncation is
    in effect should get a horizontal scroll-bar.

Maybe you are right, but I think that perhaps the horizontal
scroll bar should be controlled by a separate flag--merely turning
on truncation should not always automatically create a horizontal
scroll bar.

Certainly the minibuffer should not have a horizontal scroll bar,
at least not in the default configuration.

Re: etc/TODO:Horizontal scrollbar

[Luc Teirlinck]

Richard Stallman wrote:

   Maybe you are right, but I think that perhaps the horizontal
   scroll bar should be controlled by a separate flag--merely turning
   on truncation should not always automatically create a horizontal
   scroll bar.

Of course, but that flag would not only have a local, but also a
global value.  Customize, for instance, will only set the global
value.  The choice for the local value would be t or nil (or maybe
top, bottom or nil, as Robert suggested).  I was talking about choices
for the global value.  I definitely believe that one of the global
choices should mean that a window gets a horizontal scroll-bar if and
only if truncation is in effect (and the window is not a minibuffer
window).  Maybe this could even be the default value.

Sincerely,

Luc.

Re: etc/TODO:Horizontal scrollbar

[Richard Stallman]

    What about splitting the existing modeline into two parts:  
	    a scroll-bar part with a width equal to, say, 10 characters,
	    a text part corresponding to the current mode line.

The mode line is already short of space.  I don't think this
is a very useful approach.  It is better to focus on the idea
of a plain old scroll-bar for horizontal scrolling.

Re: etc/TODO:Horizontal scrollbar

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     What about splitting the existing modeline into two parts:  
> 	    a scroll-bar part with a width equal to, say, 10 characters,
> 	    a text part corresponding to the current mode line.
> 
> The mode line is already short of space.  I don't think this
> is a very useful approach.  It is better to focus on the idea
> of a plain old scroll-bar for horizontal scrolling.

Considering that you can click on the fringe-arrows of a truncated
line to scroll the window left and right, the only real benefit you
get from the vertical scroll bar is the position of the thumb (besides
"common look-and-feel").

I hate wasting real estate on a horizontal scroll bar in every
window....  A _very tiny_ scroll bar in the mode line would do it for
me, as the only really interesting thing to know is the relative
scrolling position that can be deduced from the position and size of
the thumb.

BTW, should the size of the thumb reflect the relative scrolling in
the lines currently visible (I think so), or the entire file (probably
too expensive to compute I think).

I'd like to suggest some other methods to reduce the mode line
clutter.  E.g.

* Provide a `split-window-mode-line-format' that could leave out some
lesser used information (e.g. time of day) in vertically split
windows.

* Use a condensed font in the mode-line.

* Put selected information in the echo area rather than the mode line,
  e.g. line and column, minor modes, date/time, load, mail ...

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

Re: etc/TODO:Horizontal scrollbar

[Luc Teirlinck]

Kim Storm wrote:

   I hate wasting real estate on a horizontal scroll bar in every
   window....

Me too, but in my view only exceptional windows would actually get one
by default.  (If the user wants one in every window by customization,
that is his business and his prerogative.)  In my view, we are talking
about vertically split windows, picture-mode and the like.

   A _very tiny_ scroll bar in the mode line would do it for
   me, as the only really interesting thing to know is the relative
   scrolling position that can be deduced from the position and size of
   the thumb.

One might want to use the thumb for scrolling with mouse-2.  In a full
length scroll-bar, mouse-1 could move the column above that position
to the left window edge.  mouse-3 could move the column currently at
the left edge to where one clicks, or as far toward that position as
possible.  In other words, a full sized horizontal scroll-bar could be
a perfect horizontal analogue of the native vertical scroll-bar.  I am
not necessarily saying that we desperately need a full-sized
horizontal scroll-bar, all I am saying is that having a full-sized
horizontal scroll-bar is not necessarily useless.

Sincerely,

Luc.

Re: etc/TODO:Horizontal scrollbar

[Luc Teirlinck]

Kim Storm wrote:   
   
   I'd like to suggest some other methods to reduce the mode line
   clutter.  E.g.

   * Provide a `split-window-mode-line-format' that could leave out some
   lesser used information (e.g. time of day) in vertically split
   windows.

   * Use a condensed font in the mode-line.

   * Put selected information in the echo area rather than the mode line,
     e.g. line and column, minor modes, date/time, load, mail ...

The two first ones might be OK, the third one would look weird, in my
opinion.  Certainly the window specific items would make no sense in
the echo area.

I should say that the main problem I currently have with the mode line
are all these special mouse-1,-2 and -3 bindings.  The basic
mouse-1,-2 and -3 bindings are very important if one has multiple
windows.  It used to be that one could click anywhere in the mode
line, now one has to be careful and wait for a both-sided arrow to
appear to make sure that clicking in that position is safe.  Sometimes
one has to search the mode line for a while to find an appropriate
position.  In narrow windows with a long buffer name, one has very
little suitable space.

Certainly, if part of the mode-line would be used for the scroll-bar,
one definitely should make sure that in all situations, that is even
in extremely narrow windows, there is enough room left in the
mode-line for the basic mouse-1,-2,-3 functionality.

Should all those fancy bindings masking the basic ones not be a user
option?  Could it be possible to have basic and fancy areas look
clearly differently to avoid accidents and make basic use of the mouse
in the mode line easier?

Some of the special bindings are especially dangerous for newbies.
One of the worst is the mouse-2 binding of "widen", which could easily
be accidentally applied to buffers that are narrowed for internal
reasons and should normally not be widened (RMAIL and the like).
Newbies could easily misinterpret "widen" as meaning that the buffer
is going to occupy the full screen, especially since that is exactly
what mouse-2 normally does in the mode line.

Sincerely,

Luc.

Re: etc/TODO:Horizontal scrollbar

[Dhruva Krishnamurthy]

On Sun, 6 Jul 2003 21:01:17 -0500 (CDT), "Luc Teirlinck"
<teirllm@dms.auburn.edu> said:
> Kim Storm wrote:
> 
>    I hate wasting real estate on a horizontal scroll bar in every
>    window....

> possible.  In other words, a full sized horizontal scroll-bar could be
> a perfect horizontal analogue of the native vertical scroll-bar.  I am
> not necessarily saying that we desperately need a full-sized
> horizontal scroll-bar, all I am saying is that having a full-sized
> horizontal scroll-bar is not necessarily useless.

Well, I am working on the inputs provided by the list members.
- I am now getting the scroll bar above the modeline and for ever new
frame (NOT for the MINI-BUFFER)
I did a quick hack in w32term.c along the same lines of
w32_set_vertical_scroll_bar ()
and did other changes for horizontal scroll. I am facing problems in
"redeem"... I need to understand the way windows in GNU Emacs works
before I can come up with a robust solution.
 With RMS's concern of having a MS-WIN specific feature, I fully agree. I
 do not know 'X' windows stuff. I will do this for MS-windows and once it
 is complete, I will send the modified files for review/porting.

with regards,
dhruva
-- 
Dhruva Krishnamurthy
Home: http://www32.brinkster.com/schemer/

Re: etc/TODO:Horizontal scrollbar

[Richard Stallman]

    and did other changes for horizontal scroll. I am facing problems in
    "redeem"... I need to understand the way windows in GNU Emacs works
    before I can come up with a robust solution.

It is a sort of GC for scroll bars.  Redisplay marks all scroll
bars as possibly to be freed, then when it redisplays a window,
it marks that window's scroll bar as "still in use".  I think
that redeem_scroll_bar does the latter part of the job.
At the end,. those that weren't redeemed are really deallocated.