default-indicate-buffer-boundaries

default-indicate-buffer-boundaries

[Richard M. Stallman]

Is there any reason not to set default-indicate-buffer-boundaries
to `left' by default?

Re: default-indicate-buffer-boundaries

[Luc Teirlinck]

Richard Stallman wrote:

   Is there any reason not to set default-indicate-buffer-boundaries
   to `left' by default?

When I tried out `left' and various other settings for
indicate-buffer-boundaries, I found it messy and confusing, because it
more or less at random can either hide other marks in the fringe or be
hidden by them.

I would rather turn on indicate-empty-lines by default, which offers
the main functionality of indicate-buffer-boundaries, in a much more
reliable way and without any of the drawbacks.  (It never hides or is
hidden by other marks in the fringe).

Sincerely,

Luc.

Re: default-indicate-buffer-boundaries

[Richard M. Stallman]

    When I tried out `left' and various other settings for
    indicate-buffer-boundaries, I found it messy and confusing, because it
    more or less at random can either hide other marks in the fringe or be
    hidden by them.

Can you provide a test case?

Re: default-indicate-buffer-boundaries

[Luc Teirlinck]

Richard Stallman wrote:

       When I tried out `left' and various other settings for
       indicate-buffer-boundaries, I found it messy and confusing, because it
       more or less at random can either hide other marks in the fringe or be
       hidden by them.

   Can you provide a test case?

Do `emacs -q' and set indicate-buffer-boundaries to 'left.
Hold your finger on the `1' key until you get a continuation line.
Note that the indicate-buffer-boundaries glyph overrides the
continuation glyph that would normally appear in the left margin.
The right continuation glyph is still visible.  But do `M-0 C-l'
and it is out of view, leaving no indication that this is a
continuation line.  But "fixing" this so that the continuation glyph
overrides the indicate-buffer-boundaries glyph would probably be worse. 

Now do `M-x toggle-truncate-lines' (with point still at the end of the
long line).  Now all indicate-buffer-boundaries glyphs are overridden
by the truncation arrows.  But "fixing" this so that the
indicate-buffer-boundaries glyphs override the truncation arrows would
be worse.

I believe to remember that some other Emacs features put glyphs in the
fringe, although I do not immediately remember the details.  Similar
problems occur for them: obviously, they either have to override the
indicate-buffer-boundaries glyphs, or be overridden by them.

It is a while ago that I played around with indicate-buffer-boundaries,
so I do not remember the exact details, but I remember that the
problems were, in my usage, bad enough that I had to decide to reset
it to nil and use `indicate-empty-lines' instead.

`indicate-empty-lines' works well with continuation lines, truncated
lines and other Emacs features that use the fringe.  It only puts
glyphs in the fringe of empty lines, so it does not compete with
anything else.

Sincerely,

Luc.

Re: default-indicate-buffer-boundaries

[Richard M. Stallman]

    Note that the indicate-buffer-boundaries glyph overrides the
    continuation glyph that would normally appear in the left margin.
    The right continuation glyph is still visible.  But do `M-0 C-l'
    and it is out of view, leaving no indication that this is a
    continuation line.

    Now do `M-x toggle-truncate-lines' (with point still at the end of the
    long line).  Now all indicate-buffer-boundaries glyphs are overridden
    by the truncation arrows.

These are pretty serious problems.

I am not willing to abandon such a nice feature without a fight!  We
do not need to fix this feature before the release, but does anyone
have an idea for how to fix it?

In the continuation case, we could solve the problem for the
end-of-buffer indicator by putting it on the right.  But that won't
help in the truncation case.

Re: default-indicate-buffer-boundaries

[Miles Bader]

2006/2/3, Richard M. Stallman <rms@gnu.org>:
> In the continuation case, we could solve the problem for the
> end-of-buffer indicator by putting it on the right.  But that won't
> help in the truncation case.

The code combines indicators for other cases; can't it do so in these?

BTW, before the release I want to change the name of the fringe
bitmaps so they indicate the _meaning_ of the bitmaps, rather than
being named after the default appearance... the current names are very
confusing and inflexible if you change the appearance using
define-fringe-bitmap.

-miles
--
Do not taunt Happy Fun Ball.

Re: default-indicate-buffer-boundaries

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> 2006/2/3, Richard M. Stallman <rms@gnu.org>:
>> In the continuation case, we could solve the problem for the
>> end-of-buffer indicator by putting it on the right.  But that won't
>> help in the truncation case.
>
> The code combines indicators for other cases; can't it do so in these?
>
> BTW, before the release I want to change the name of the fringe
> bitmaps so they indicate the _meaning_ of the bitmaps, rather than
> being named after the default appearance... the current names are very
> confusing and inflexible if you change the appearance using
> define-fringe-bitmap.

This is already in FOR RELEASE:

** Rework how fringe bitmaps are defined and used.
Currently, bitmap usage and bitmap appearence are "mixed-up" in a
one-level representation.  It would be cleaner to split the
representation into a two-level model where first level maps
bitmap usage to a bitmap name, and second level maps bitmap name to
a bitmap appearence.
[Assigned to KFS]


I have some of the code written, but I haven't had time to
finish the work.  I'll try to find the time soon.


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

Re: default-indicate-buffer-boundaries

[Richard M. Stallman]

    > In the continuation case, we could solve the problem for the
    > end-of-buffer indicator by putting it on the right.  But that won't
    > help in the truncation case.

    The code combines indicators for other cases; can't it do so in these?

What do you mean by "combines indicators"?
Do you mean that it displays multiple fringe bitmaps,
one across the other?  Or some other kind of "combination"?

    BTW, before the release I want to change the name of the fringe
    bitmaps so they indicate the _meaning_ of the bitmaps, rather than
    being named after the default appearance... the current names are very
    confusing and inflexible if you change the appearance using
    define-fringe-bitmap.

That change would go counter to other changes that we should make in
the longer term, making a mechanism for users to specify which bitmap
to use for a given purpose.  For that to make sense, the actual names
of the bitmaps should reflect their appearance.

Re: default-indicate-buffer-boundaries

[Kim F. Storm]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Note that the indicate-buffer-boundaries glyph overrides the
>     continuation glyph that would normally appear in the left margin.
>     The right continuation glyph is still visible.  But do `M-0 C-l'
>     and it is out of view, leaving no indication that this is a
>     continuation line.
>
>     Now do `M-x toggle-truncate-lines' (with point still at the end of the
>     long line).  Now all indicate-buffer-boundaries glyphs are overridden
>     by the truncation arrows.
>
> These are pretty serious problems.
>
> I am not willing to abandon such a nice feature without a fight!  We
> do not need to fix this feature before the release, but does anyone
> have an idea for how to fix it?

>
> In the continuation case, we could solve the problem for the
> end-of-buffer indicator by putting it on the right.  But that won't
> help in the truncation case.

We could put the indicator on the next line in those case.

Or we could combine those two bitmaps (there is already code
which allows two bitmaps to be shown at the same time, like
a breakpoint icon and the overlay arrow.)

I will try to figure out what to do.

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

Re: default-indicate-buffer-boundaries

[Luc Teirlinck]

Kim Storm wrote:

   We could put the indicator on the next line in those case.

Would be confusing for the end-of-buffer indicator.  Also the entire
buffer could be one single continued line.

   Or we could combine those two bitmaps (there is already code
   which allows two bitmaps to be shown at the same time, like
   a breakpoint icon and the overlay arrow.)

The indicate-buffer-boundary bitmaps already "combine" with the
overlay arrow right now, although the result does not really look that
great.  I did not test how they interact with breakpoint bitmaps.

One should not concentrate too exclusively on the testcases I
provided.  There is a general problem here.  Both fringes are used for
continuation/truncation.  The left fringe is also used for the overlay
arrow and breakpoints.  The fringes are probably still used for
additional stuff I can not think of right now.

Whenever one wants to show something to the user without hiding any
part of the buffer, the "obvious" solution is to put a bitmap in one
of the two fringes, if fringe mode is enabled.  But the problem is
that there is not that much space in the fringe, so conflicts result.

There is a lot that the fringes potentially _could_ be useful for, but
they can not _actually_ be used for a lot.  Hence, I believe that one
should be very reluctant to put any bitmaps other than the
continuation/truncation and overlay/breakpoint bitmaps (and
occasionally point) in the fringes _by default_.  It is OK for
non-default features to put icons in the fringe, since the user who
enables the feature explicitly indicates that the feature is important
enough to him to be willing to live with the potential conflicts.

The indicate-empty-lines bitmaps do not conflict with anything else in
the fringe, because they only are put on empty lines.  They indicate
end of buffer whitespace more clearly than the
indicate-buffer-boundaries icons.  (In practice, I personally still
needed them, _even_ with indicate-buffer-boundaries enabled.)  I
believe to remember that Miles, the only person complaining about them
being "too much in your face" uses a non-default fringe background color.

So I believe that enabling `indicate-empty-lines' by default would be
more useful, without creating any problems.  I believe that the extra
info provided by `indicate-buffer boundaries' (showing _beginning_ of
buffer) is not sufficiently important to sufficiently many people to
put all these bitmaps in the fringe _by default_.

Sincerely,

Luc.

Re: default-indicate-buffer-boundaries

[Miles Bader]

2006/2/4, Luc Teirlinck <teirllm@dms.auburn.edu>:
> I believe that Miles, the only person complaining about them
> being "too much in your face" uses a non-default fringe background color.

Yes.

[It's not uncommon that various emacs defaults which look OK on a
light background look a bit crappy on a dark background.]

-miles

--
Do not taunt Happy Fun Ball.

Re: default-indicate-buffer-boundaries

[Robert J. Chassell]

   > I believe that Miles, the only person complaining about them
   > being "too much in your face" uses a non-default fringe
   > background color.

I also find them too vivid.  (I use a dark background.  Does the
default for a light background look fine in that circumstance?)

What is an easy and quick way to set the icon in a .emacs file to look
different?

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

Re: default-indicate-buffer-boundaries

[Luc Teirlinck]

Robert Chassell wrote:

      > I believe that Miles, the only person complaining about them
      > being "too much in your face" uses a non-default fringe
      > background color.

   I also find them too vivid.  (I use a dark background.  Does the
   default for a light background look fine in that circumstance?)

I can not speak for other people, but it looks perfectly fine on the
default light background to me.

Sincerely,

Luc.

Re: default-indicate-buffer-boundaries

[Juri Linkov]

>       > I believe that Miles, the only person complaining about them
>       > being "too much in your face" uses a non-default fringe
>       > background color.
>
>    I also find them too vivid.  (I use a dark background.  Does the
>    default for a light background look fine in that circumstance?)
>
> I can not speak for other people, but it looks perfectly fine on the
> default light background to me.

Actually it depends on the default font size rather than on the background.
I use a light background and small font size, and default fringe icons
look very ugly to me.  They are bigger and more "fat" than average characters.
They look like a fly sitting on the screen :-)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: default-indicate-buffer-boundaries

[Kim F. Storm]

"Richard M. Stallman" <rms@gnu.org> writes:

> Is there any reason not to set default-indicate-buffer-boundaries
> to `left' by default?

I wouldn't object, although I prefer the following setting myself:

  ((top . left) (t . right))

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

Re: default-indicate-buffer-boundaries

[Miles Bader]

2006/2/1, Richard M. Stallman <rms@gnu.org>:
> Is there any reason not to set default-indicate-buffer-boundaries
> to `left' by default?

I strongly prefer `left' myself.

When indicators are on both the left and the right, it's harder to
keep track of them.

I don't understand Luc's complaint about the boundary icons
"interfering" with other fringe indicators on the left -- there don't
seem to be any common cases where that happens.

[`indicate-empty-lines' probably does do a better job of indicating
"after eob" space, but I think it's unacceptably annoying given it's
current default icon.  If the icon was made less in-your-face, it
might be acceptable.]

-Miles
--
Do not taunt Happy Fun Ball.

Re: default-indicate-buffer-boundaries

[Luc Teirlinck]

Miles Bader wrote:

   I don't understand Luc's complaint about the boundary icons
   "interfering" with other fringe indicators on the left -- there don't
   seem to be any common cases where that happens.

What is common depends on your usage pattern.

   [`indicate-empty-lines' probably does do a better job of indicating
   "after eob" space,

Yes it does and I believe that this is very important, especially
given Emacs' overscrolling feature, which often confuses people.

   but I think it's unacceptably annoying given it's
   current default icon.  If the icon was made less in-your-face, it
   might be acceptable.

To me, the indicate-buffer-boundaries icons are _way_ more in your face
and potentially distracting than the indicate-empty-lines icons, which
is an additional reason why I do not like indicate-buffer-boundaries.
To me, the indicate-empty-lines icons seem very subdued, exactly the
opposite as the way they appear to you.  I do not remember anybody
other than you complaining about these icons being too "in-your-face".

Sincerely,

Luc.