Customizing the mode line

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

[Juanma Barranquero]

On Fri, Oct 30, 2009 at 12:18, Eli Zaretskii <eliz@gnu.org> wrote:

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

Yes, please.

    Juanma

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Fri, 30 Oct 2009 09:38:16 -0400
> 
> > Should I file a "wish-list" bug for this?
> 
> Yes, please

Done.

> > 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).

Right, I also think that both percentage and the line number is
redundant, and we could remove one of them, at least by default,
leaving an option to restore it for those who want that.

And "C-x l" could be enhanced to show more of that information.

> 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.

We could simply display only the major mode by default, and show the
rest in a tooltip, or with some easily-typed command.

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

It should probably be moved to the right edge, because if it does not
show in full, or even not at all, it's not a disaster: the user
generally knows what buffer she is in.

> 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).

We could also make the mode line take 2 lines, but I think this would
be a big job, because I think various places in the display engine
assume it's only one line.

RE: Customizing the mode line

[Drew Adams]

I disagree with these statements about minor-mode indicators:
 - once you've seen the list of minor modes, you don't need it anymore
 - only the major mode is needed in the mode line

Two reasons:

1. Access to the minor-mode menus (same as for the major mode).

2. Current minor-mode status. The minor-mode indicator (lighter) can be a way to
convey status. I use it that way in Icicles for instance, to tell users during
input: (a) whether completion is available, (b) input case-sensitivity, (c)
require-match, (d) multi-command completion.

The point about length of text is well taken, but it is fixed by fixing the
particular minor modes that use long lighters. Icicles uses only 3-4 chars to
convey all of the info mentioned above (#2). I'd suggest limiting lighters to 4
chars. But the tooltip should show the full mode name, not just `Minor Mode'.

Likewise, major-mode lighters should be short. There is no reason, for instance,
that Emacs-Lisp mode needs to have the lighter `Emacs-Lisp' instead of `Elisp'
or even `EL'. Other things too could be shortened without any real loss of
understanding. `Unix' for eol style need not take 4 chars. The general rule
should be for a tooltip to provide the full field info.

I would not object to providing #1 in some other way, at least for a global
minor mode (such as Icicles). Anything buffer-local should remain in the mode
line, however.

If we remove, by default, info that is not buffer-specific or window-specific
(e.g. time of day, global minor modes), there still needs to be the possibility
of showing such info somewhere continually. I'm thinking especially of
minor-mode status and menu access - showing status continually can be as
important for a global minor mode as for a process. The menu bar and tool bar
are no good for this. Global info need not be shown for each window or even for
each frame, but per-frame display is the most global thing we have so far.

The buffer name is often the longest field in the mode line. It could be greatly
shortened, with a tooltip for the full name. That would be better than moving it
to the right edge. This savings alone could make a big difference. Currently,
the tooltip for the buffer name says `Buffer name', instead of, e.g., `Buffer
vc-dispatcher.el'. That's a waste.

I would prefer that we keep the size indicator (e.g. `37%'), by default. In
general, we should take chars from the long fields such as buffer name, and not
eliminate such short indicators. If need be, we could put the size info on the
tooltip for the line number - they already share the same `mouse-1' menu.

I disagree with Eli's suggestion of showing the whole mode line in the echo
area. Many of us turn off `tooltip-mode'. Information should be available as a
tooltip for individual mode-line entries, which means that the echo area should
be usable for that when `tooltip-mode' is off. Anyway, when a user wants more
information than is visible in the mode line, s?he usually wants it for one
specific field.

The general idea should be to shorten fields and change the existing tooltips,
from simply letting you know what the field is for, to letting you know what the
field's full value is. We already do that for the first few fields (encoding,
eol style etc.). We should do it especially where it offers the greatest
abbreviation potential - e.g. buffer name.

I suggest that we start by (a) simply shortening existing fields, in particular
the buffer name and the mode-name lighters, and (b) providing full field info in
tooltips. I doubt we will even need to then consider removing some fields and
finding another (e.g. global) place for their info.

Re: Customizing the mode line

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> Date: Fri, 30 Oct 2009 09:54:18 -0700
> 
> I disagree with these statements about minor-mode indicators:
>  - once you've seen the list of minor modes, you don't need it anymore
>  - only the major mode is needed in the mode line
> 
> Two reasons:
> 
> 1. Access to the minor-mode menus (same as for the major mode).

This could be solved by the menu we pop up when you click on the major
mode.  It could provide access to minor modes as well.

> 2. Current minor-mode status. The minor-mode indicator (lighter) can be a way to
> convey status. I use it that way in Icicles for instance, to tell users during
> input: (a) whether completion is available, (b) input case-sensitivity, (c)
> require-match, (d) multi-command completion.

This just means there should be an option to show the minor-mode
mnemonic, and that Icicles should turn it on.

> I disagree with Eli's suggestion of showing the whole mode line in the echo
> area.

That was meant as an addition to what the mode line shows, not as a
substitute for it.

Re: Customizing the mode line

[Stefan Monnier]

Drew Adams said:
> The general idea should be to shorten fields and change the existing
> tooltips,

I'm glad we agree.  Note that we'd also need to figure out a way to make
it work for ttys as well, where tooltips aren't available (probably
providing a command like "display-full-mode-line" to dump the modeline's
text into the (resizable) echo area, would be a good start).

Eli Zaretskii said:
> Right, I also think that both percentage and the line number is
> redundant, and we could remove one of them, at least by default,
> leaving an option to restore it for those who want that.

It's very tempting, but I can already hear screams in the distance.

> We could simply display only the major mode by default, and show the
> rest in a tooltip, or with some easily-typed command.

Maybe that'll be necessary, but if we can keep a few chars of each
minor-mode that would be better.

> It should probably be moved to the right edge, because if it does not
> show in full, or even not at all, it's not a disaster: the user
> generally knows what buffer she is in.

It's tempting, but I'm also weary of a potential rebellion.

> We could also make the mode line take 2 lines, but I think this would
> be a big job, because I think various places in the display engine
> assume it's only one line.

I think that should be kept as an absolute last resort: I don't want to
waste any more vertical space than the strict minimum, and really,
fundamentally, if we need to display so much information that we need
more than one line of mode-line, maybe we're doing something wrong (the
UI is overloaded).

Joakim Verona said:
> One thing adding to the problem is that a lot of information is repeated
> in all modelines, where they could really live separately in a special
> status window.

I don't use those global indicators specifically because I don't think
they belong in the mode-line.  I'm not opposed to code such as
display-battery-mode, but making it work well is not on my list
of priorities.


        Stefan

Re: Customizing the mode line

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 30 Oct 2009 15:12:40 -0400
> Cc: 'Eli Zaretskii' <eliz@gnu.org>, emacs-devel@gnu.org
> 
> Eli Zaretskii said:
> > Right, I also think that both percentage and the line number is
> > redundant, and we could remove one of them, at least by default,
> > leaving an option to restore it for those who want that.
> 
> It's very tempting, but I can already hear screams in the distance.

Yes, me too.  Which is why I would settle for easier customization,
which I can use when necessary.

> > It should probably be moved to the right edge, because if it does not
> > show in full, or even not at all, it's not a disaster: the user
> > generally knows what buffer she is in.
> 
> It's tempting, but I'm also weary of a potential rebellion.

Ditto.

Re: Customizing the mode line

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 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 very much like the percentages, scroll-bars or no.  Even if the
information presented is theoretically equivalent, I find the form
matters too.

> 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.

I agree, kinda... but... _some_ minor modes seem fairly important to
know about -- e.g., "Narrow", in a mode where narrowing isn't normal,
and "Fill" -- whereas others are less so.  Ideally, it would be possible
to see the "important" things, and replace the others with "..." or
whatever, but I'm not sure an easy way to distinguish them.

> 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).

That seems a very good idea.

-Miles

-- 
Marriage, n. The state or condition of a community consisting of a master, a
mistress and two slaves, making in all, two.

Re: Customizing the mode line

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 31 Oct 2009 14:16:47 +0900
> 
> > 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.
> 
> I agree, kinda... but... _some_ minor modes seem fairly important to
> know about -- e.g., "Narrow", in a mode where narrowing isn't normal,
> and "Fill" -- whereas others are less so.  Ideally, it would be possible
> to see the "important" things, and replace the others with "..." or
> whatever, but I'm not sure an easy way to distinguish them.

We can start by making a list of minor modes that are important.
Right now, we have Ovwrt, Fill, Narrow, and some unspecified things in
Viper.

Re: Customizing the mode line

[Juanma Barranquero]

The discussion is centered in making room in the modeline, and that is good.

But I'm also interested in ways to make mode-line customization (from
elisp, not M-x customize) easier. Currently I have things like this in
my .emacs:

 (setcar (cdddr (cadadr (cadadr mode-line-client))) (propertize " "
'face 'variable-pitch))
 (setf (cadr (assq :propertize mode-line-modes))
       '(overwrite-mode
         ;; etc))

and it ain't pretty (and it is quite fragile, of course).

Perhaps a way to access its content similar to menus could be made to
work; currently, some things are in variables, some are not, and there
are cases where you want to add some tiny thing (like spacing around a
value), and in order to keep the text properties (tooltips, etc)
you've got to copy a bunch of stuff.

    Juanma

RE: Customizing the mode line

[Drew Adams]

> We can start by making a list of minor modes that are important.
> Right now, we have Ovwrt, Fill, Narrow, and some unspecified things in
> Viper.

No, let's start by throwing out the bathwater, not the baby.

As I said, we can start by:

a. Reducing the length of mode names that are long - both major and minor.
b. Improving tooltips to actually provide info about the current field value.
c. Perhaps reducing buffer-name length, when space becomes critical (i.e.
dynamically).

IOW, first get rid of extra, wasted space, and put the full info on tooltips, to
compensate. We may well find that there is no need to remove any fields, if
fields are shortened reasonably.

There is no reason that we abbreviate `Overwrite' as `Ovwrt' but we don't
abbreviate `Emacs-Lisp' to `Elisp' or even `EL'. There's no reason for long
lighters such as `Lisp Interaction' and `Dired by name'. They date from the days
when the mode line was the western wilderness; that territory has long since
been settled. And Eli needs room to park his mailbox+load-average+which-func
Winnebago.

Currently there is wasted space just asking to be reclaimed - that's the place
to start, if we're worried about space on the default mode line. 4 or 5 chars
should be enough for any lighter - major or minor. `Narow' or `Nrw' - even
`Vipr'. `U' instead of `Unix'. And so on.

We should not remove any global-minor-mode lighters, as long as we haven't come
up with a good alternative for providing continual access to a 4-char status
indicator (lighter) somewhere, as well as access to the minor mode's menu.

Sticking all of the minor-mode menus on the same popup menu as the major mode is
not a great solution, but it could be done if we desperately need the space and
we find no other solution. (So far, we haven't even looked.) But there needs to
be some place where the equivalent of global-minor-mode lighters is displayed
continually.

Eli's original complaint said that things like minor-mode indicators and the
size indicator were crowding out stuff that he considers more important. As
examples of the latter he included time of day, a you've-got-mail indicator, and
which-func-mode help. More recently he added load-average to his list.

Those are things that are not even part of the default mode line! That means
changing the Emacs default mode line to fit one person's preferences and
customizations. And time of day, mail, and load-average are not even buffer- or
window-specific. They should be the first things to _remove_ from the default
mode line, if there were present.

If you turn on eldoc, which-func-mode, load-average display, mail notification,
and who knows what else, then sure, you might find that you are crowded for
space. But the solution to that problem is personal customization.

Which is one reason I support Eli's original request: easier customization of
the mode line. That is the solution for his personal difficulty - not removing
things like lighters and size indicator from the _default_ mode line.

[Eli, you even go so far as to say that your not being able to see which-func
help properly "clearly affects _our_ ability to work on improving Emacs".
Sheesh. You are an important developer, but you are only one user. The Emacs
mode line default should be designed for users (and not just one), not for
developers.]

So there are two things we can do to improve the mode line, without losing
anything: (1) Shorten fields that are long and put the full field info on
tooltips. (2) Find a way to let users customize the mode line more easily.

Wrt #2, I don't have a solution, but it should be along the lines of providing
for prioritization: keep stuff as long as there is room, then progressively
remove stuff that the user has given lower priority.

But let's not confuse #1, improving the default, with #2, improving
customization. And in particular, let's _not start_ by removing any fields from
the default mode line.

Re: Customizing the mode line

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <monnier@iro.umontreal.ca>, <emacs-devel@gnu.org>
> Date: Sat, 31 Oct 2009 09:03:42 -0700
> 
> `U' instead of `Unix'.

This one can be customized with eol-mnemonic-unix, so it's not a
problem.  (I have it customized to just "/".)  The non-native
mnemonics (Unix on DOS/Windows, DOS on Unix, etc.) are explicit
because users demanded that back when EOL decoding was introduced in
Emacs 20.  Maybe there's no need to do this anymore, but OTOH maybe
there will be a rebellion.

RE: Customizing the mode line

[Drew Adams]

> > `U' instead of `Unix'.
> 
> This one can be customized with eol-mnemonic-unix, so it's not a
> problem.  (I have it customized to just "/".)  The non-native
> mnemonics (Unix on DOS/Windows, DOS on Unix, etc.) are explicit
> because users demanded that back when EOL decoding was introduced in
> Emacs 20.

Good to know; thanks.

But we could instead use a shorter form for the default, and let users customize
it to something longer if they like.

> Maybe there's no need to do this anymore, but OTOH maybe
> there will be a rebellion.

Dunno about possible rebellions, but the place to start is to provide full field
info in tooltips. The tooltip for eol style is already fixed in this regard.


In general, we should start with the smallest changes that bring the greatest
benefit. In order:

1. Fix tooltips to convey full field/state info. Currently, most simply show the
name of the field.

2. _After_ that, think about shortening some of the long mode indicators. Both
major and minor - major-mode indicators are generally the longest, and sometimes
gratuitously long. With meaningful tooltips, all that's needed for the indicator
itself is, well, a brief indicator (!) - just a reminder, not an explanation.


These small changes will take us a long way toward freeing up space, I predict.
And with no significant information loss.

_After_ #1 and #2, if need be (and I don't really expect the need), we can get
down to discussing what else might be done, to free up yet more space.

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

Re: Customizing the mode line

[Štěpán Němec]

On Sat, Oct 31, 2009 at 01:09:43AM -0500, Manoj Srivastava wrote:
> 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.
> 
+1
I would prefer the percentage, too, at least with the current weird
scrollbar behaviour.

> > 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

Re: Scrollbar thumbs

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>         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.

Is it only GTK which is brain-damaged in this area?  Do other toolkits
do the same thing?

-Miles

-- 
Zeal, n. A certain nervous disorder afflicting the young and inexperienced.

Re: Scrollbar thumbs

[Stefan Monnier]

> Is it only GTK which is brain-damaged in this area?  Do other toolkits
> do the same thing?

Yes, IIUC w32 does the same (and Xaw3d as well, tho to a lesser extent).


        Stefan

Re: Scrollbar thumbs

[Jason Rumney]

Stefan Monnier wrote:
>> Is it only GTK which is brain-damaged in this area?  Do other toolkits
>> do the same thing?
>>     
>
> Yes, IIUC w32 does the same (and Xaw3d as well, tho to a lesser extent).
>   

Since 23.1, Emacs on w32 allows the scroll thumb to shrink while being 
dragged at the bottom of the buffer.  Previous versions fixed the size 
of the thumb while dragging, which I think is the brain damage which GTK 
forces on you that Miles is refering to, as you are unable to reach the 
bottom of the buffer by dragging the scrollbar in some circumstances 
because of assumptions Emacs makes to relate characters to pages of 
scrolling without wasting time doing a full calculation over the buffer.

Re: Scrollbar thumbs

[Stefan Monnier]

> Since 23.1, Emacs on w32 allows the scroll thumb to shrink while being
> dragged at the bottom of the buffer.  Previous versions fixed the size of
> the thumb while dragging, which I think is the brain damage which GTK forces
> on you that Miles is refering to, as you are unable to reach the bottom of
> the buffer by dragging the scrollbar in some circumstances because of
> assumptions Emacs makes to relate characters to pages of scrolling without
> wasting time doing a full calculation over the buffer.

Not sure how it works on w32, but yes on Gtk IIRC the thumb can't be
resized during dragging.  In Xaw3d the problem was halfway: the code
was/is able to resize the thumb during a drag, but the thumb may hit the
bottom too soon, in case we haven't resized it quickly enough.

My favorite solution to those problem nowadays is to set the thumb-size
to its minimum (typically 0, which results in a small but no invisible
thumb) during dragging: makes for smooth scrolling (without the need to
resize the thumb during scrolling) while still allowing the thumb size
to correctly reflect the begin&end of the viewed area when
not scrolling.


        Stefan

Re: Customizing the mode line

[Evil Boris]

>> 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)

I am sure usages vary, but with every new "improvement" in GUIness of
Emacs I modify my .emacs to turn the feature off.  No menu bar.  No
scroll bars.  No tool bar.  Thank you.  Please keep the percentage of
the buffer around, or make it easy to put back in if you do not.

Re: Customizing the mode line

[joakim]

Eli Zaretskii <eliz@gnu.org> writes:

> 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?

One thing adding to the problem is that a lot of information is repeated
in all modelines, where they could really live separately in a special
status window.

I tried adding functions to help with this problem, for instance the
"window groups" patch that let you keep a window on screen, that could
keep status info. This is currently unfinished.

Currently I just use this instead:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; modeline-depopulator
;;test little hack to see info in msg area
;;TODO  lan status
(require 'battery)
(require 'timeclock)
(defun modeline-depopulator ()
  (interactive)
  (message "%s\n%s\n%s"
           (format-time-string "%H:%M %Y-%m-%d" (current-time))
           (battery-format battery-echo-area-format (funcall
                                                     battery-status-function))
           (timeclock-status-string)))
(global-set-key [f5] 'modeline-depopulator)


I press f5 when I want to know something I dont need to know all the
time, like time and date, time spent in a project, and battery status.

It is not distracting and it does in fact work surprisingly well.

>
-- 
Joakim Verona

Re: Customizing the mode line

[Eli Zaretskii]

> From: joakim@verona.se
> Date: Fri, 30 Oct 2009 16:01:42 +0100
> Cc: emacs-devel@gnu.org
> 
> Currently I just use this instead:
> 
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;; modeline-depopulator
> ;;test little hack to see info in msg area
> ;;TODO  lan status
> (require 'battery)
> (require 'timeclock)
> (defun modeline-depopulator ()
>   (interactive)
>   (message "%s\n%s\n%s"
>            (format-time-string "%H:%M %Y-%m-%d" (current-time))
>            (battery-format battery-echo-area-format (funcall
>                                                      battery-status-function))
>            (timeclock-status-string)))
> (global-set-key [f5] 'modeline-depopulator)
> 
> 
> I press f5 when I want to know something I dont need to know all the
> time, like time and date, time spent in a project, and battery status.

Perhaps we should have a command to show the entire mode-line string
in the echo area.  The echo area is not limited to a single line, so
it will show everything.

Re: Customizing the mode line

[Stephen Berman]

On Fri, 30 Oct 2009 17:25:27 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

> Perhaps we should have a command to show the entire mode-line string
> in the echo area.  The echo area is not limited to a single line, so
> it will show everything.

FWIW, I use this:

(defun srb-display-mode-line-string (&optional arg)
  "Display the unpropertized mode-line string in the echo area.
With prefix argument ARG, insert it at point in the current buffer."
  (interactive "P")
  (let ((mode-line-string
	 (eval-expression '(format-mode-line mode-line-format 0))))
    (and arg (insert mode-line-string))))
(global-set-key "\C-cf" 'srb-display-mode-line-string)

Steve Berman

Re: Customizing the mode line

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> 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 major and minor mode indicators are important.  For instance, there
must be a visible indicator of whether overwrite mode is on, because if
you toggle it frequently, you may forget whether it's currently on.

> 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,

The gnus and rmail mode line formats definitely need to be improved, I
agree.

By the way, since we're complaining about the mode-line: I find the
sequence of "----" characters at the end of the mode-line hideous.  I
wouldn't object to removing them for graphical displays (they're
probably necessary for terminal displays).

Re: Customizing the mode line

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 30 Oct 2009 13:45:10 -0400
> 
> The major and minor mode indicators are important.  For instance, there
> must be a visible indicator of whether overwrite mode is on, because if
> you toggle it frequently, you may forget whether it's currently on.

I agree that the overwrite mode should be visible.  But that doesn't
mean we need to see "Mail Fly Abbrev Fill" or their ilk in all other
modes.

Do you have instances other than the overwrite mode, which are
similarly important?  Or is that the only one?

Re: Customizing the mode line

[Lennart Borgman]

On Fri, Oct 30, 2009 at 9:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Chong Yidong <cyd@stupidchicken.com>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 30 Oct 2009 13:45:10 -0400
>>
>> The major and minor mode indicators are important.  For instance, there
>> must be a visible indicator of whether overwrite mode is on, because if
>> you toggle it frequently, you may forget whether it's currently on.
>
> I agree that the overwrite mode should be visible.  But that doesn't
> mean we need to see "Mail Fly Abbrev Fill" or their ilk in all other
> modes.
>
> Do you have instances other than the overwrite mode, which are
> similarly important?  Or is that the only one?


There are similar things in Viper which probably should be moved into
the this new mode line handling too (when someone gets time to do it).

Re: Customizing the mode line

[Stefan Monnier]

> The major and minor mode indicators are important.  For instance, there
> must be a visible indicator of whether overwrite mode is on, because if
> you toggle it frequently, you may forget whether it's currently on.

Agreed, which is also why I'd rather shorten them down to maybe even
a single char rather than eliminate them altogether.

> The gnus and rmail mode line formats definitely need to be improved, I
> agree.

Don't know about Rmail, but at least Gnus mode-lines haven't been
problematic for me.  The worst seems to be for message-mode, where the
buffer name tends to be long and the mode part says "(Message SC MML Fly
Abbrev Fill Narrow)": of those, "MML" should simply be removed because
it's not a major mode one should even be able to turn off (i.e. although
it's been implemented as a separate module, to the user, it's just an
integral part of message-mode), and Narrow should be eliminated by not
using narrowing (the narrowing is only used to hide a few headers,
namely (in my experience) "X-Draft-From:" and "References:").

> By the way, since we're complaining about the mode-line: I find the
> sequence of "----" characters at the end of the mode-line hideous.  I
> wouldn't object to removing them for graphical displays (they're
> probably necessary for terminal displays).

They are clearly needed for text terminals that don't support inverse
video, and may be occasionally vaguely useful even for text terminals
that do support inverse video, but for GUI terminals, they're just
a nuisance.


        Stefan

Re: Customizing the mode line

[Justin Bogner]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> The major and minor mode indicators are important.  For instance, there
>> must be a visible indicator of whether overwrite mode is on, because if
>> you toggle it frequently, you may forget whether it's currently on.
>
> Agreed, which is also why I'd rather shorten them down to maybe even
> a single char rather than eliminate them altogether.

There's a diminish.el on emacswiki that can do this (though you must
specify which minor modes you'd like to shorten). I recently started
using it to get rid of modes like filladapt and outline, that I enable
globally, and my modeline is now usually less than 80 characters wide.

I've also removed the padding in mode-line-buffer-identification:

    (setq-default mode-line-buffer-identification
                  (propertized-buffer-identification "%b"))

and shortened the display-time format. These days it's largely only gnus
buffers and git branches with long names that make my mode line too
long.

Re: Customizing the mode line

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
> By the way, since we're complaining about the mode-line: I find the
> sequence of "----" characters at the end of the mode-line hideous.  I
> wouldn't object to removing them for graphical displays (they're
> probably necessary for terminal displays).

They're rarely necessary for terminal displays either, because
reverse-video is used for the mode-line.

AFAIK, the dashes were basically intended for terminals like the vt52
which had no reverse-video, but the there's no significant usage of such
terminals today.

-Miles

-- 
Bacchus, n. A convenient deity invented by the ancients as an excuse for
getting drunk.

Re: Customizing the mode line

[Richard Stallman]

I don't think that a better UI for customizing the mode line is a
really important place to improve.  Customizing it is not that hard to
do.

Let's spend our time working on features that will enable Emacs to do
things that it currently cannot do, and handle situations it currently
cannot handle.

Re: Customizing the mode line

[Juanma Barranquero]

> I don't think that a better UI for customizing the mode line is a
> really important place to improve.

I don't know whether it is "really important". I know that my
customizations break almost every time someone changes the default
mode-line.

>   Customizing it is not that hard to do.

I'm not sure what do you mean here by "customizing". Certainly,

  (setcar (cdddr (cadadr (cadadr mode-line-client))) ...)

is not "hard", but it is not evident either.

    Juanma

Re: Customizing the mode line

[Richard Stallman]

The basic way to customize the mode line is by setting the variables
that control it.  It is not terribly hard.

The more important issue is that helping users customize the mode line
is not vitally important, as things go.  If we made customizing the
mode line much easier, Emacs would not be significantly more useful as
a result.

Let's do the things that really make Emacs more useful.

For instance, a lot of work has been done on MuMaMo.  Perhaps we
should get that installed now.  Or perhaps we should use one of the
other programs that do this job, or a combination.

Re: Customizing the mode line

[Juanma Barranquero]

On Sun, Nov 1, 2009 at 10:28, Richard Stallman <rms@gnu.org> wrote:

> The more important issue is that helping users customize the mode line
> is not vitally important, as things go.  If we made customizing the
> mode line much easier, Emacs would not be significantly more useful as
> a result.
>
> Let's do the things that really make Emacs more useful.

By that simplistic priority scheme, we should not waste any time
fixing typos either.

> For instance, a lot of work has been done on MuMaMo.  Perhaps we
> should get that installed now.  Or perhaps we should use one of the
> other programs that do this job, or a combination.

That's a false dichotomy. Installing MuMaMo does not preclude working
on the modeline issue, or vice versa.

    Juanma

Re: Customizing the mode line

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Sat, 31 Oct 2009 07:07:44 -0400
> 
> I don't think that a better UI for customizing the mode line is a
> really important place to improve.  Customizing it is not that hard to
> do.

??? Really?  Then please describe how to do that.  What user options
are available for that, and what values one should give them for the
following use-cases:

 . Show only the major mode, not the minor modes.

 . Remove the percent/All/Top/Bot part.

 . Display the load-average and the Mail notification between the line
   number and the major/minor mode indicator.

> Let's spend our time working on features that will enable Emacs to do
> things that it currently cannot do, and handle situations it currently
> cannot handle.

You seem to say, in effect, that features which use the mode line are
not important enough to discuss.  If so, I certainly disagree.  The
system load is very important to me when I get sluggish response from
Emacs: it allows me to figure out if my net connection is the
culprit.  The mail notification is very important to me as well, for
obvious reasons.

Btw, my complaint was triggered by the need to see the current
function (displayed by which-func-mode) when I was studying the
display engine code for my bidi work.  So this problem clearly affects
our ability to work on improving Emacs in other areas, certainly so
for me.

Re: Customizing the mode line

[Robert J. Chassell]

    > I don't think that a better UI for customizing the mode line is a
    > really important place to improve.  Customizing it is not that hard to do.

    ??? Really?  Then please describe how to do that.  

I have the following in my .emacs file and am not as good a programmer as
Eli Zaretski:

  (setq default-mode-line-format
   (quote
    (#("-" 0 1
       (help-echo
        "mouse-1: select (drag to resize), mouse-2: delete others, mouse-3: delete"))
     mode-line-mule-info
     mode-line-modified
     mode-line-remote
  ;;   mode-line-frame-identification
  ;;   "`"
  ;;   (:eval  (user-real-login-name))
  ;;   "' "
     "  "
     mode-line-buffer-identification
     #("  " 0 2
       (help-echo
        "mouse-1: select (drag to resize), mouse-2: delete others, mouse-3: delete"))
     (:eval (user-real-login-name))
     "@"
     default-directory
     #(" " 0 1
       (help-echo
        "mouse-1: select window, mouse-2: delete others, mouse-3: delete"))
     (size-indication-mode
      (6
       #(" %I " 0 4
         (help-echo "mouse-1: select (drag to resize), mouse-2: delete others, mouse-3: delete this"))))
  ;;    (if (string= (cdr (assq 'name (frame-parameters)))
  ;;                 (or "Root Emacs 22" "Bobs Emacs 22"))
     (line-number-mode "Line %l")
     (vc-mode vc-mode)
     (:propertize
      (" (" mode-name mode-line-process minor-mode-alist)
      help-echo "mouse-3: minor mode menu" local-map
      (keymap
       (header-line keymap
                    (down-mouse-3 . mode-line-mode-menu-1))
       (mode-line keymap
                  (down-mouse-3 . mode-line-mode-menu-1))))
  ;; the following is replaced by    the :propertize expression above
  ;;    #(" %[(" 0 4                    ; 4 is number of chars between quotes
  ;;      (help-echo
  ;;       "mouse-1: select window, mouse-2: delete others, mouse-3: delete"))
  ;;

  ;;    (:eval (mode-line-mode-name))
  ;;    mode-line-process
  ;;    minor-mode-alist
     #("%n" 0 2 (help-echo "mouse-2: widen" local-map (keymap ...)))
     ")%] "
     (-3 . "%P")
     global-mode-string
  ;;   "-%-"
    )))

-- 
    Robert J. Chassell                          
    bob@gnu.org                                 bob@rattlesnake.com
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Customizing the mode line

[Eli Zaretskii]

> From: bob@gnu.org (Robert J. Chassell)
> Date: Sat, 31 Oct 2009 14:09:23 +0000
> Cc: bob@gnu.org
> 
>     > I don't think that a better UI for customizing the mode line is a
>     > really important place to improve.  Customizing it is not that hard to do.
> 
>     ??? Really?  Then please describe how to do that.  
> 
> I have the following in my .emacs file and am not as good a programmer as
> Eli Zaretski:

That's just a copy of what bindings.el has, with some changes.  It may
be suited for .emacs, when you want to change the mode line once and
for all.

What I was after were _user_options_ that can be set for when I want
to change the mode-line appearance temporarily.

Re: Customizing the mode line

[Robert J. Chassell]

-- 
    Robert J. Chassell                          
    bob@gnu.org                                 bob@rattlesnake.com
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Customizing the mode line

[Robert J. Chassell]

        > I have the following in my .emacs file

    That's just a copy of what bindings.el has, with some changes.

Yes!  That is why it is a simpler user command than one such as
customize-* which has more than a dozen completions.

    ... set for when I want to change the mode-line appearance temporarily.

I cannot help you.  Changing the value in a setq is the quickest method
that I know and requires the least learning.  Fortunately, writing a
.emacs file (mostly by copying, of course) is less complicated than
reading, which almost every child learns (in a developed country).
Emacs takes some learning, like all else.  Doubtless, anything that we
can learn and become accustomed to, even `customize-*', can become
`intuitive'.  But I lack the ability to learn anything complicated.  So
I stick to .emacs files.  (I am not as good as I was.)
-- 
    Robert J. Chassell                          
    bob@gnu.org                                 bob@rattlesnake.com
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Customizing the mode line

[Eli Zaretskii]

> From: bob@gnu.org (Robert J. Chassell)
> Date: Sat, 31 Oct 2009 22:40:49 +0000
> 
>     ... set for when I want to change the mode-line appearance temporarily.
> 
> I cannot help you.  Changing the value in a setq is the quickest method
> that I know and requires the least learning.  Fortunately, writing a
> .emacs file (mostly by copying, of course) is less complicated than
> reading, which almost every child learns (in a developed country).
> Emacs takes some learning, like all else.  Doubtless, anything that we
> can learn and become accustomed to, even `customize-*', can become
> `intuitive'.  But I lack the ability to learn anything complicated.  So
> I stick to .emacs files.  (I am not as good as I was.)

"M-x set-variable RET" is not complicated.

Re: Customizing the mode line

[Juanma Barranquero]

On Sat, Oct 31, 2009 at 15:09, Robert J. Chassell <bob@gnu.org> wrote:

> I have the following in my .emacs file and am not as good a programmer as
> Eli Zaretski:
>
>  (setq default-mode-line-format
...
>    )))

I hope that's not an example of how easy is customizing the mode line.

    Juanma

Re: Customizing the mode line

[M Jared Finder]

Eli Zaretskii wrote:
>> From: Richard Stallman <rms@gnu.org>
>> CC: emacs-devel@gnu.org
>> Date: Sat, 31 Oct 2009 07:07:44 -0400
>>
>> I don't think that a better UI for customizing the mode line is a
>> really important place to improve.  Customizing it is not that hard to
>> do.
> 
> ??? Really?  Then please describe how to do that.  What user options
> are available for that, and what values one should give them for the
> following use-cases:

The first two are easy.

>  . Show only the major mode, not the minor modes.

(setq minor-mode-alist nil) or customize mode-line-modes

>  . Remove the percent/All/Top/Bot part.

Remove the first two entries of mode-line-position


>  . Display the load-average and the Mail notification between the line
>    number and the major/minor mode indicator.

Reordering the mode line is much harder (and would be greatly 
appreciated by me).  I think if you cleaned up mode-line-format so that 
it only included VARIABLES, then this would be clear as day.  Right now 
mode-line-format's default value is big and scary (note, from Emacs22):

("%e"
  #("-" 0 1
    (help-echo "mouse-1: select (drag to resize), mouse-2 = C-x 1, 
mouse-3 = C-x 0"))
  mode-line-mule-info mode-line-modified mode-line-frame-identification 
mode-line-buffer-identification
  #("   " 0 3
    (help-echo "mouse-1: select (drag to resize), mouse-2 = C-x 1, 
mouse-3 = C-x 0"))
  mode-line-position
  (vc-mode vc-mode)
  #("  " 0 2
    (help-echo "mouse-1: select (drag to resize), mouse-2 = C-x 1, 
mouse-3 = C-x 0"))
  mode-line-modes
  (which-func-mode
   ("" which-func-format
    #("--" 0 2
      (help-echo "mouse-1: select (drag to resize), mouse-2 = C-x 1, 
mouse-3 = C-x 0"))))
  (global-mode-string
   (#("--" 0 2
      (help-echo "mouse-1: select (drag to resize), mouse-2 = C-x 1, 
mouse-3 = C-x 0"))
    global-mode-string))
  #("-%-" 0 3
    (help-echo "mouse-1: select (drag to resize), mouse-2 = C-x 1, 
mouse-3 = C-x 0")))

You could clean this up to be a lot clearer.  Part of it is the pretty 
printer is doing an awful job, part of it is the explicit propertized 
strings.  Imagine if it was like this:

(mode-line-mem-info
  (:propertize "-" (mode-line-default-props))
  mode-line-mule-info
  mode-line-modified
  mode-line-frame-identification
  (:propertize "    " (mode-line-default-props))
  mode-line-position
  mode-line-vc-info
  mode-line-modes
  mode-line-which-func-info
  global-mode-string
  (:propertize "-%-" (mode-line-default-props)))

And then you could expose this in Customize as a reorder-able list!

In short, I have four proposals:

1. Change mode-line-format to not include ANY explicitly propertized 
strings.  Use :eval and :propertize.
2. Remove condition branching in mode-line-format.  Just variables with 
formatting info should be there, put the branching in those variables.
3. Change the pretty-printer used by C-h v to somehow recognize that 
mode-line-format should be formatted with a newline after every element.
4. Change the customize option for mode-line-format to display it as a 
reorderable list, like c-mode-hook.

   -- MJF

Re: Customizing the mode line

[Eli Zaretskii]

> From: M Jared Finder <jared@hpalace.com>
> Date: Sat, 31 Oct 2009 10:46:23 -0700
> 
> Eli Zaretskii wrote:
> >> From: Richard Stallman <rms@gnu.org>
> >> CC: emacs-devel@gnu.org
> >> Date: Sat, 31 Oct 2009 07:07:44 -0400
> >>
> >> I don't think that a better UI for customizing the mode line is a
> >> really important place to improve.  Customizing it is not that hard to
> >> do.
> > 
> > ??? Really?  Then please describe how to do that.  What user options
> > are available for that, and what values one should give them for the
> > following use-cases:
> 
> The first two are easy.

Not really.

> >  . Show only the major mode, not the minor modes.
> 
> (setq minor-mode-alist nil)

"C-h v minor-mode-alist RET" produces a 100-odd line long "*Help*"
buffer, where even I get lost.  And how did you know that setting it
to nil will do the trick? the doc string doesn't tell.

> or customize mode-line-modes

This one produces a 123-line "*Help*" buffer.  Most users will not
know how even to start customizing it, because the various portions of
the spec are not documented at all.

> >  . Remove the percent/All/Top/Bot part.
> 
> Remove the first two entries of mode-line-position

Come on! "C-h v" on this variable produces a 71-line "*Help*" buffer
for just 3 indicators.  If this is user-friendly UI, then I don't know
what a user-friendly UI is.

> In short, I have four proposals:
> 
> 1. Change mode-line-format to not include ANY explicitly propertized 
> strings.  Use :eval and :propertize.
> 2. Remove condition branching in mode-line-format.  Just variables with 
> formatting info should be there, put the branching in those variables.
> 3. Change the pretty-printer used by C-h v to somehow recognize that 
> mode-line-format should be formatted with a newline after every element.
> 4. Change the customize option for mode-line-format to display it as a 
> reorderable list, like c-mode-hook.

Sounds like a good plan.  Thanks.

Re: Customizing the mode line

[Juanma Barranquero]

On Sat, Oct 31, 2009 at 18:46, M Jared Finder <jared@hpalace.com> wrote:

> 1. Change mode-line-format to not include ANY explicitly propertized
> strings.  Use :eval and :propertize.
> 2. Remove condition branching in mode-line-format.  Just variables with
> formatting info should be there, put the branching in those variables.
> 3. Change the pretty-printer used by C-h v to somehow recognize that
> mode-line-format should be formatted with a newline after every element.
> 4. Change the customize option for mode-line-format to display it as a
> reorderable list, like c-mode-hook.

These are really good suggestions. 1 and 2 would go a long way towards
reducing the current pain.

    Juanma

Re: Customizing the mode line

[Chong Yidong]

Here's one small simplification to the mode-line that we can easily
introduce: define a variable mode-line-help-echo, which serves as the
default help echo for any mode-line element not having its own
help-echo.

Now, bindings.el won't need to manuall apply the default help-echo to
"neutral" mode-line elements like spaces.  This makes the value shown in
`C-h v mode-line-format' less of a mess:

Value:
("%e-" mode-line-mule-info mode-line-client mode-line-modified mode-line-remote mode-line-frame-identification mode-line-buffer-identification "   " mode-line-position
 (vc-mode vc-mode)
 "  " mode-line-modes
 (which-func-mode
  ("" which-func-format "--"))
 (global-mode-string
  ("" global-mode-string "--"))
 "-%-")

Do you think that helps?


*** emacs/src/xdisp.c.~1.1316.~	2009-10-22 10:28:39.000000000 -0400
--- emacs/src/xdisp.c	2009-10-31 10:24:42.000000000 -0400
***************
*** 230,235 ****
--- 230,236 ----
  
  extern Lisp_Object Qface;
  extern Lisp_Object Qmode_line, Qmode_line_inactive, Qheader_line;
+ Lisp_Object Vmode_line_help_echo;
  
  extern Lisp_Object Voverriding_local_map;
  extern Lisp_Object Voverriding_local_map_menu_flag;
***************
*** 23421,23426 ****
--- 23422,23429 ----
        if (NILP (help))
  	{
  	  help = Fget_text_property (pos, Qhelp_echo, string);
+ 	  if (NILP (help) && !NILP (Vmode_line_help_echo))
+ 	    help = Vmode_line_help_echo;
  	  if (!NILP (help))
  	    {
  	      help_echo_string = help;
***************
*** 24914,24919 ****
--- 24917,24930 ----
  `header-line', or `menu' respectively.  */);
    mode_line_inverse_video = 1;
  
+   DEFVAR_LISP ("mode-line-help-echo", &Vmode_line_help_echo,
+ 	       doc: /* Default help-echo (tooltip) for mode-line elements.
+ This help-echo applies to any mode-line elements lacking a `help-echo'
+ property (see `mode-line-format'.  */);
+   Vmode_line_help_echo = build_string ("mouse-1: Select (drag to resize)\n\
+ mouse-2: Make current window occupy the whole frame\n\
+ mouse-3: Remove current window from display");
+ 
    DEFVAR_LISP ("line-number-display-limit", &Vline_number_display_limit,
      doc: /* *Maximum buffer size for which line number should be displayed.
  If the buffer is bigger than this, the line number does not appear

Re: Customizing the mode line

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 31 Oct 2009 10:33:45 -0400
> 
> Here's one small simplification to the mode-line that we can easily
> introduce: define a variable mode-line-help-echo, which serves as the
> default help echo for any mode-line element not having its own
> help-echo.
> 
> Now, bindings.el won't need to manuall apply the default help-echo to
> "neutral" mode-line elements like spaces.  This makes the value shown in
> `C-h v mode-line-format' less of a mess:
> 
> Value:
> ("%e-" mode-line-mule-info mode-line-client mode-line-modified mode-line-remote mode-line-frame-identification mode-line-buffer-identification "   " mode-line-position
>  (vc-mode vc-mode)
>  "  " mode-line-modes
>  (which-func-mode
>   ("" which-func-format "--"))
>  (global-mode-string
>   ("" global-mode-string "--"))
>  "-%-")
> 
> Do you think that helps?

Sorry, I do not follow: which problem is this supposed to help with,
and how?

(There are too many different issues discussed in this thread, so it's
really hard to know which one you are trying to solve.)

Thanks.

Re: Customizing the mode line

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> Sorry, I do not follow: which problem is this supposed to help with,
> and how?

It makes it easier to users to figure out how to re-order the mode-line.
As Jared Finder just posted in another sub-thread:

> Reordering the mode line is much harder (and would be greatly
> appreciated by me).  I think if you cleaned up mode-line-format so
> that it only included VARIABLES, then this would be clear as day.
> Right now mode-line-format's default value is big and scary

Re: Customizing the mode line

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 31 Oct 2009 14:07:18 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Sorry, I do not follow: which problem is this supposed to help with,
> > and how?
> 
> It makes it easier to users to figure out how to re-order the mode-line.

Yes, that would help.  Thanks.  But the variables need to be options,
so that "M-x set-variable RET" completes on them.  Having to use setq
automatically means users who are not Lisp programmers will have
difficulties.

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.

Re: Scrollbar thumbs

[grischka]

> > 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.

In practice, if the file is large, scrollbar operations are less 
accurate and less smooth anyway, so you can get away with rough 
estimations very well without further compromising the scroll quality.

However the smaller the file the better a scrollbar can work and that 
is why accurate size calculations are especially beneficial for small 
files rsp. well choosen small parts of a file, such as at the top and 
the bottom.

--- grischka

Re: Scrollbar thumbs

[David Kastrup]

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

>> > 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.
>
> In practice, if the file is large, scrollbar operations are less
> accurate and less smooth anyway, so you can get away with rough
> estimations very well without further compromising the scroll quality.

Scrollbars are not just updated when scrolling.

-- 
David Kastrup

Re: Scrollbar thumbs

[grischka]

Óscar Fuentes wrote:
> Sure, the Real World is slowly adapting to the rules stated by some
> illuminated GUI toolkit designers.

The entire Real World?  No! A small village of indomitable lisp hackers
still holds out against the visual invasion, fortified by their magic
knowledge of the mantras that allow them to transform pure human will
into virtual user interfaces located in the user herself.

--- grischka

Re: Scrollbar thumbs

[Óscar Fuentes]

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

> Óscar Fuentes wrote:
>> Sure, the Real World is slowly adapting to the rules stated by some
>> illuminated GUI toolkit designers.
>
> The entire Real World?  No! A small village of indomitable lisp hackers
> still holds out against the visual invasion, fortified by their magic
> knowledge of the mantras that allow them to transform pure human will
> into virtual user interfaces located in the user herself.

Just in case someone takes the above comment half-seriously, it is worth
noting that the problem faced by emacs wrt GTK scrollbar would hinder
other applications too. For instance, on some areas it is required to
display very large datasets on a grid. There, it is not often clear how
much rows there are on the dataset, nor exists the concept on n-th row,
so it is not possible to have a precise 1-to-1 mapping among the
scrollbar thumb position and the dataset cursor position. On those
applications it is useful to handle thumb movements as exponential
displacements too.

Nothing on the Holy Scripture says that scrollbars are forbidden for
those uses. Quite the contrary, users have no problem at all using
scrollbars with that behaviour.

GTK chose a very restrictive concept of scrollbar. Not only this, but it
chose to *force* this concept on the users.

You can adapt Emacs to GTK requirements, but I wouldn't consider that a
bug fix, but rather a workaround for a dumb widget.

-- 
Óscar

Re: Scrollbar thumbs

[David De La Harpe Golden]

Óscar Fuentes wrote:


> Just in case someone takes the above comment half-seriously, it is worth
> noting that the problem faced by emacs wrt GTK scrollbar would hinder
> other applications too. For instance, on some areas it is required to
> display very large datasets on a grid. There, it is not often clear how
> much rows there are on the dataset, nor exists the concept on n-th row,
> so it is not possible to have a precise 1-to-1 mapping among the
> scrollbar thumb position and the dataset cursor position.


Hmm. The is an old ui convention for [some of] that, whereby using the 
scrollbar arrows allows pushing "past the end", shrinking the thumb.
Back in the amiga days at least, this was some sort of a FAQ along the 
lines of
"Q. Why do scrollbars have those redundant arrow things at all, anyway?
A. Because they're not redundant, in some situations the arrows grow the 
size of the content area, the bar only scrolls within the current extent 
of the content area"

- you see that in the "workbench" file browser windows on the amiga, for 
example.   The fact people had to have that explained to them on 
occasion suggests it wasn't all that obvious though.

I don't know if gtk actually allows that, and I don't think it really
helps in the emacs case, just saying that convention existed.