I like to use Kim's fringe "buffer-boundary indicator" bitmap feature
(set with the variable `indicate-buffer-boundaries'), but the default
bitmaps are rather unpleasant for several reasons --
(1) They're quite "heavy", so tend to draw the eye too much. With the
fringe line-wrapping indicators, that's OK because wrapping is
typically an unusual situation, but the buffer-boundary indicators
are essentially _always_ present (if enabled) -- they should be
available to look at, but shouldn't draw attention.
(2) The indicators for "buffer beginning/end" and the arrows meaning
"buffer continues past the window edge" are not distinguishable
enough unless you look directly at them; it would be nice if the
difference was easier to see with just a quick glance.
So I've change my personal bitmaps to help alleviate these problems:
(define-fringe-bitmap 'down-arrow [32 32 32 32 32 32 168 112 32] nil nil
'bottom)
(define-fringe-bitmap 'up-arrow [32 112 168 32 32 32 32 32 32] nil nil 'top)
(define-fringe-bitmap 'top-left-angle [254 254 128 128 128] nil nil 'top)
(define-fringe-bitmap 'bottom-left-angle [128 128 128 254 254] nil nil
'bottom)
(define-fringe-bitmap 'left-bracket [254 254 128 128 128 0 0 0 0 128 128 128
254 254] nil nil 'center)
These only change the bitmaps used when `indicate-buffer-boundaries'
has a value of `left', so enable that mode too:
(setq-default indicate-buffer-boundaries 'left)
Could people try them out? Maybe these would be better defaults than
the existing bitmaps.
A related issue is the name of the bitmaps -- currently the names
reflect the physical appearance of the default bitmaps, but I think it
would be better if the names reflected their logical use. For instance,
a user might want to change the bitmap meaning "end of buffer" to be a
little "EOB" (shades of EDT... :-); in such an instance, not only is it
a bit wierd that it's called `bottom-left-angle', but there's a danger
that in the future some new feature will use the same bitmap (based on
its physical appearance); making the names "logical" would make it more
clear that this is bad.
Thanks,
-Miles
--
"I distrust a research person who is always obviously busy on a task."
--Robert Frosch, VP, GM Research
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
