fringe buffer-boundary bitmaps

fringe buffer-boundary bitmaps

[Miles Bader]

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

Re: fringe buffer-boundary bitmaps

[Miles Bader]

Also, here are some alternate versions of the fringe line-wrapping
indicator bitmaps:

(define-fringe-bitmap 'continued-line [96 16 8 8 72 80 96 120] nil nil 'bottom)
(define-fringe-bitmap 'continuation-line [8 16 16 16 18 10 6 30] nil nil 'top)

These are lighter-weight than the current defaults, so maybe more
controversial, but I like them a lot better.

Check 'em out...

Thanks,

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: fringe buffer-boundary bitmaps

[Miles Bader]

Here are some more alternate bitmaps:

;; A sharper, more obviously arrow-like overlay arrow.
;; I admit this resembles something from a bad ms-windows debugger,
;; but at least it looks like an arrow rather than a blob (which is
;; what the default overlay-arrow looks like).
(define-fringe-bitmap 'overlay-arrow [16 24 252 254 252 24 16] nil nil 'center)

;; Lighter-weight line-truncation indicators (my clever idea was to
;; use a dotted arrow-shaft to sort of add the flavor of an ellipses
;; to them).
(define-fringe-bitmap 'right-truncation [4 2 169 2 4] nil 11 'center)
(define-fringe-bitmap 'left-truncation [32 64 149 64 32] nil nil 'center)

-Miles
-- 
It wasn't the Exxon Valdez captain's driving that caused the Alaskan oil spill.
It was yours.  [Greenpeace advertisement, New York Times, 25 February 1990]

Re: fringe buffer-boundary bitmaps

[Robert J. Chassell]

Miles Bader wrote,

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

On testing, I prefer Kim's bitmaps.

I am not sure whether my preferences comes from a liking for
symmetrical images, such as top_left_angle_bits, or my high resolution
display, or something else.  The suggested continuation_bits map is
much too `thin' or `light' on my screen.

I have tried the suggested bitmaps both on an instance of Emacs
started with `emacs/src/emacs -Q -D' and on an instance started with
my usual colors and fonts.

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

Re: fringe buffer-boundary bitmaps

[Richard M. Stallman]

    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.

If there is a fixed correspondence between uses and names, which
appears to be the case, then I agree with you.  Also, the doc string
of define-fringe-bitmap ought to list these standard names, because
there is no other doc string to find them in.

However, I think it would be cleaner to keep the names as they are,
referring to the bitmap appearance, and add a layer where you specify
which bitmap to use for each standard purpose.  So if you want to use
a little "EOB" for the end of the buffer, you'd put that in a bitmap
named little-eob, then specify to use little-eob for end of buffer.

indicate-buffer-boundaries would be the place to specify this.

Re: fringe buffer-boundary bitmaps

[Markus Gritsch]

Miles Bader wrote:
> 
> 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)

I like the old ones much better.

Markus

Re: fringe buffer-boundary bitmaps

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

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

I don't have a problem with the "heavy" appearence, and they were
designed to be similar to / consistent with the older bitmaps.

> Could people try them out?  Maybe these would be better defaults than
> the existing bitmaps.

I find your "slimmer" bitmaps are quite nice on their own, but
I don't think they are an improvement. YMMV.


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

You are right that the current naming is not logical.

Feel free to suggest better names, and change the code and docs accordingly.

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

Re: fringe buffer-boundary bitmaps

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Also, here are some alternate versions of the fringe line-wrapping
> indicator bitmaps:
>
> (define-fringe-bitmap 'continued-line [96 16 8 8 72 80 96 120] nil nil 'bottom)
> (define-fringe-bitmap 'continuation-line [8 16 16 16 18 10 6 30] nil nil 'top)
>
> These are lighter-weight than the current defaults, so maybe more
> controversial, but I like them a lot better.

They are quite nice, yes.  And contrary to the current bitmaps, they
actually look like arrows...

But if we change these, then probably we should change all the bitmaps
to a lighter version...

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

Re: fringe buffer-boundary bitmaps

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Here are some more alternate bitmaps:
>
> ;; A sharper, more obviously arrow-like overlay arrow.
> ;; I admit this resembles something from a bad ms-windows debugger,
> ;; but at least it looks like an arrow rather than a blob (which is
> ;; what the default overlay-arrow looks like).
> (define-fringe-bitmap 'overlay-arrow [16 24 252 254 252 24 16] nil nil 'center)

I like the old blob better.
>
> ;; Lighter-weight line-truncation indicators (my clever idea was to
> ;; use a dotted arrow-shaft to sort of add the flavor of an ellipses
> ;; to them).
> (define-fringe-bitmap 'right-truncation [4 2 169 2 4] nil 11 'center)
> (define-fringe-bitmap 'left-truncation [32 64 149 64 32] nil nil 'center)

Nice idea, but the bitmaps are too light for my taste.

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

Re: fringe buffer-boundary bitmaps

[Miles Bader]

On 6/22/05, Robert J. Chassell <bob@rattlesnake.com> wrote:
> I am not sure whether my preferences comes from a liking for
> symmetrical images, such as top_left_angle_bits, or my high resolution
> display, or something else.  The suggested continuation_bits map is
> much too `thin' or `light' on my screen.

I did some more testing, and it became pretty clear that which style
("light" or "heavy") looks better depends strongly on the font
(smaller fonts go better with "light", but the thin bitmaps can start
looking a bit lost with large fonts), background color (on a dark
background, the white bitmaps stand out much more, which makes the
"heavy" bitmaps look even heavier), and probably display type (I use
an LCD display which is very good at showing single-pixel lines
precisely).

So I dunno.  Maybe it would make sense to have a few alternate sets of
bitmaps packaged with emacs, similar to Gnome's icon-themes?

[BTW I still think the default overlay-arrow (aka "the blob") is
completely awful, regardless of context...]

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: fringe buffer-boundary bitmaps

[Kim F. Storm]

Miles Bader <snogglethorpe@gmail.com> writes:

> So I dunno.  Maybe it would make sense to have a few alternate sets of
> bitmaps packaged with emacs, similar to Gnome's icon-themes?

If you like, you could add a new function in fringe.el which selects
a specific style of the standand fringe bitmaps:

(fringe-bitmaps-style 'light)
(fringe-bitmaps-style nil)  -> the default ("heavy")

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

Re: fringe buffer-boundary bitmaps

[Kim F. Storm]

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

>     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.
>
> If there is a fixed correspondence between uses and names, which
> appears to be the case, then I agree with you.  Also, the doc string
> of define-fringe-bitmap ought to list these standard names, because
> there is no other doc string to find them in.


>
> However, I think it would be cleaner to keep the names as they are,
> referring to the bitmap appearance, and add a layer where you specify
> which bitmap to use for each standard purpose.  So if you want to use
> a little "EOB" for the end of the buffer, you'd put that in a bitmap
> named little-eob, then specify to use little-eob for end of buffer.

I disagree this would be much cleaner.

The implementation is already quite tricky, as there are already
several levels of preferences involved in deciding which bitmaps to
show left and right for a specific row.

And it would require that we define all the build-in bitmaps 
An extra layer of indirection does not give us any advantages IMO.



> indicate-buffer-boundaries would be the place to specify this.

I don't see why the mapping should be restricted to just the bitmaps
used for buffer boundaries ?


IMO, this is a lot of extra work for _NO_ added benefit.

My vote is for just changing the names of the bitmaps to reflect the
purpose rather than apperance.  

To do that, we just have to change the names of the symbols defined in
fringe.el (compared to your suggested change which requires a lot of
work at the C level).

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

Re: fringe buffer-boundary bitmaps

[Miles Bader]

On 6/23/05, Kim F. Storm <storm@cua.dk> wrote:
> If you like, you could add a new function in fringe.el which selects
> a specific style of the standand fringe bitmaps:
> 
> (fringe-bitmaps-style 'light)
> (fringe-bitmaps-style nil)  -> the default ("heavy")

Sure; I think changing the underlying implementation to use Richard's
suggested two-level mapping would make it a bit nicer though...

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: fringe buffer-boundary bitmaps

[Lute Kamstra]

Miles Bader <miles@lsi.nec.co.jp> writes:

[...]

> Could people try them out?  Maybe these would be better defaults
> than the existing bitmaps.

Ehrm, maybe I'm doing something really stupid, but your redefinitions
don't seem to change the appearance of the fringe bitmaps in my Emacs.

What I do is this:

1. Start Emacs with "emacs -Q".
2. Eval this in the *scratch* buffer:

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

  (define-fringe-bitmap 'continued-line [96 16 8 8 72 80 96 120] nil nil 'bottom)
  (define-fringe-bitmap 'continuation-line [8 16 16 16 18 10 6 30] nil nil 'top)

  (setq-default indicate-buffer-boundaries 'left))

Then the bitmaps still look very much like they normally look.

Lute.

Re: fringe buffer-boundary bitmaps

[Miles Bader]

On 6/23/05, Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> wrote:
> Ehrm, maybe I'm doing something really stupid, but your redefinitions
> don't seem to change the appearance of the fringe bitmaps in my Emacs.

I didn't realize this when I sent those messages, but you first have to do:

   (require 'fringe)

Unfortunately it seems that if you try to use define-fringe-bitmap
_without_ doing the above require, it will never work after that, even
if you later use the require and then redo the define-fringe-bitmap
calls; I had to restart emacs to make things take.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: fringe buffer-boundary bitmaps

[Lute Kamstra]

Miles Bader <snogglethorpe@gmail.com> writes:

> I didn't realize this when I sent those messages, but you first have to do:
>
>    (require 'fringe)

Yup, that makes it work.  Your bitmaps are a bit to thin for my taste.
(I use 1024x768 on a 17" monitor.)  Also, the empty-line bitmap
touches the bottom-left-angle bitmap, which looks messy.

> Unfortunately it seems that if you try to use define-fringe-bitmap
> _without_ doing the above require, it will never work after that, even
> if you later use the require and then redo the define-fringe-bitmap
> calls; I had to restart emacs to make things take.

Hmm, that should probably be fixed somehow.

Lute.

Re: fringe buffer-boundary bitmaps

[Juanma Barranquero]

On 6/23/05, Miles Bader <snogglethorpe@gmail.com> wrote:

> I didn't realize this when I sent those messages, but you first have to do:
> 
>    (require 'fringe)

BTW, loading fringe resets `default-indicate-buffer-boundaries'.
That's Not Good. I have no problem with "M-x customize-variable
fringe-indicators" setting it (it is clearly documented in the
`fringe-indicators' docstring), but just (require 'fringe) should not
change my defaults.

I propose the following patch (but people more experienced on
customize will have perhaps a better fix): if `fringe-indicators' is
set, it takes precedence over `default-indicate-buffer-boundaries',
which seems sensible.

-- 
                    /L/e/k/t/u


Index: lisp/fringe.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/fringe.el,v
retrieving revision 1.17
diff -u -2 -r1.17 fringe.el
--- lisp/fringe.el	9 Feb 2005 15:50:42 -0000	1.17
+++ lisp/fringe.el	23 Jun 2005 11:47:26 -0000
@@ -281,4 +281,10 @@
 	 (t nil))))
 
+(defun initialize-fringe-indicators (ignore value)
+  (set-fringe-indicators-1 nil
+                           (or value
+                               fringe-indicators
+                               default-indicate-buffer-boundaries)))
+
  ;;;###autoload
  (defcustom fringe-indicators nil
@@ -293,5 +299,6 @@
   :group 'fringe
   :require 'fringe
-  :set 'set-fringe-indicators-1)
+  :set 'set-fringe-indicators-1
+  :initialize 'initialize-fringe-indicators)
 
 (provide 'fringe)

Re: fringe buffer-boundary bitmaps

[Juanma Barranquero]

> +(defun initialize-fringe-indicators (ignore value)
> +  (set-fringe-indicators-1 nil
> +                           (or value
> +                               fringe-indicators
> +                               default-indicate-buffer-boundaries)))
> +

Well, perhaps not exactly that, because the values of
`fringe-indicators' and `indicate-buffer-boundaries' aren't the
same... :( It is necessary a transformation function from
`indicate-buffer-boundaries' style to `fringe-indicators'.


-- 
                    /L/e/k/t/u

Re: fringe buffer-boundary bitmaps

[Luc Teirlinck]

Also, unless I misunderstand, I believe that your :initialize function
would not solve the following problem:

I have:

(setq default-indicate-empty-lines t)

in my .emacs.  

Just loading fringe overrides this.  `custom-initialize-reset' is a real
problem, in that user customizations can be overridden without notice
by just loading files.  It was made the default :initialize function
to handle some problems with autoloaded defcustoms, but it probably
creates worse problems than it solves.

In this case there is, apart from the `custom-initialize-reset'
problem, the problem that the :set function appears to be flawed.
Even if you replace `custom-initialize-reset' with
`custom-initialize-set' or with your function, it would appear that
experimenting with customizing `fringe-indicators' through Custom and
then erasing that customization using Custom will reset
default-indicate-empty-lines to nil, which it should not.

I believe that there is a design flaw with `fringe-indicators'.  I
believe that this flaw should be fixed in such a way that
`default-indicate-buffer-boundaries' gets respected and that one can
safely do:

:initialize 'custom-initialize-set

The docstring of fringe-indicators is wrong:

  "Visually indicate buffer boundaries and scrolling.
Setting this variable, changes `default-indicate-buffer-boundaries'."

No setting this variable only takes effect by loading or reloading
fringe, or when set through Custom.

Sincerely,

Luc.

Re: fringe buffer-boundary bitmaps

[Luc Teirlinck]

The `fringe-indicators' docstring is not only incorrect, but useless.
It does not tell what the possible values are and what their meaning
is.  It does not tell what you have to do to make the value take
effect when setting it outside Custom.

Sincerely,

Luc.

Re: fringe buffer-boundary bitmaps

[Juanma Barranquero]

> Also, unless I misunderstand, I believe that your :initialize function
> would not solve the following problem:
> 
> I have:
> 
> (setq default-indicate-empty-lines t)
> 
> in my .emacs.

Yes. I became aware of this just after sending my second message :(

> I believe that there is a design flaw with `fringe-indicators'.  I
> believe that this flaw should be fixed in such a way that
> `default-indicate-buffer-boundaries' gets respected and that one can
> safely do:
> 
> :initialize 'custom-initialize-set

I agree at 100%.

-- 
                    /L/e/k/t/u

Re: fringe buffer-boundary bitmaps

[Luc Teirlinck]

I believe that `fringe-indicators' and `set-fringe-indicators-1'
should be eliminated (they only exists in CVS, so this is not an
incompatible change) and that instead `indicate-buffer-boundaries'
should be made directly customizable through Custom in cus-start.el.

I believe this is the only way to avoid potential problems and user
confusion.

If a user wants to have the buffer boundaries indicated by
`default-indicate-buffer-boundaries' and at the same time wants to
have the lower boundaries indicated by `default-indicate-empty-lines'
(apparently the "problem" `fringe-indicators' was designed to avoid),
then one may not consider that very useful, but that is up to the user
to decide.  Maybe the two docstrings could refer to each other and
mention that there is some overlap in functionality.

Sincerely,

Luc.

Re: fringe buffer-boundary bitmaps

[Robert J. Chassell]

   ... it became pretty clear that which style ("light" or "heavy")
   looks better depends strongly on the font (smaller fonts go better
   with "light", but the thin bitmaps can start looking a bit lost
   with large fonts), background color (on a dark background, the
   white bitmaps stand out much more, which makes the "heavy" bitmaps
   look even heavier), and probably display type (I use an LCD display
   which is very good at showing single-pixel lines precisely).

That makes a great deal of sense.  Useful discovery.

   ... it would make sense to have a few alternate sets of
   bitmaps packaged with emacs, similar to Gnome's icon-themes?

Yes.  Please figure out several defaults, one of which is selected
depending on some automatically measured value such as that coming
from `display-pixel-width'.  (Doubtless, some other function or
variable would be better, but I don't know it.)

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

Re: fringe buffer-boundary bitmaps

[Juanma Barranquero]

On 6/23/05, Luc Teirlinck <teirllm@dms.auburn.edu> wrote:

> I believe that `fringe-indicators' and `set-fringe-indicators-1'
> should be eliminated (they only exists in CVS, so this is not an
> incompatible change) and that instead `indicate-buffer-boundaries'
> should be made directly customizable through Custom in cus-start.el.

That's OK (or, in fact, preferable) to me.

-- 
                    /L/e/k/t/u

Re: fringe buffer-boundary bitmaps

[Richard M. Stallman]

    I did some more testing, and it became pretty clear that which style
    ("light" or "heavy") looks better depends strongly on the font
    (smaller fonts go better with "light", but the thin bitmaps can start
    looking a bit lost with large fonts), background color (on a dark
    background, the white bitmaps stand out much more, which makes the
    "heavy" bitmaps look even heavier), and probably display type (I use
    an LCD display which is very good at showing single-pixel lines
    precisely).

Maybe they should be selected based on the font of the default face.

Re: fringe buffer-boundary bitmaps

[Richard M. Stallman]

    > indicate-buffer-boundaries would be the place to specify this.

    I don't see why the mapping should be restricted to just the bitmaps
    used for buffer boundaries ?

As far as I know, these bitmaps are used in two ways.   You can specify
them by name, in a display property, and certain fixed bitmap names
are used for specific standard purposes.

In the case of the display property, you can give the bitmap any name
you like; the display property specifies which name to use.

My proposal is to create a similar level of specifying the name for
the specific standard purposes.

Re: fringe buffer-boundary bitmaps

[Richard M. Stallman]

    Unfortunately it seems that if you try to use define-fringe-bitmap
    _without_ doing the above require, it will never work after that, even

Perhaps we should rename the function define-fringe-bitmap to
define-fringe-bitmap-internal, and define a trivial new
autoloaded define-fringe-bitmap in fringe.el.  That way,
any attempt to call the function will load the necessary file.

Re: fringe buffer-boundary bitmaps

[Kim F. Storm]

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

>     > indicate-buffer-boundaries would be the place to specify this.
>
>     I don't see why the mapping should be restricted to just the bitmaps
>     used for buffer boundaries ?
>
> As far as I know, these bitmaps are used in two ways.   You can specify
> them by name, in a display property, and certain fixed bitmap names
> are used for specific standard purposes.
>
> In the case of the display property, you can give the bitmap any name
> you like; the display property specifies which name to use.
>
> My proposal is to create a similar level of specifying the name for
> the specific standard purposes.

I understand that, but I don't see why we need two different ways to
modify them -- you can redefine the standard bitmap directly, so I
don't see why do we need an extra level of indirection here (which has
to be done at the C level to an already quite complex piece of code).

Currently, what we have are standard bitmaps for "bob-left",
"bob-right", "eob-left", "eob-right" etc...

But, rather than following the existing pattern of naming them after
their purpose (like "continuation-line", "left-truncation" etc), I
have named them after their visual appearence, e.g. "top-left-angle",
"top-right-angle", "bottom-left-angle", etc...

That is a bug IMO, so I agree with Miles that those names should be
changed to match their purpose rather their appearence.  If we do that,
the extra level of indirection you suggested is not necessary.


The relevant bitmaps that should be renamed are:

up-arrow             => top-scroll
down-arrow           => bottom-scroll

top-left-angle       => left-beginning-of-buffer
top-right-angle      => right-beginning-of-buffer

bottom-left-angle    => left-end-of-buffer
bottom-right-angle   => right-end-of-buffer

left-bracket         => left-all-of-buffer
right-bracket        => right-all-of-buffer


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

Re: fringe buffer-boundary bitmaps

[Stefan Monnier]

> I believe that `fringe-indicators' and `set-fringe-indicators-1'
> should be eliminated (they only exists in CVS, so this is not an
> incompatible change) and that instead `indicate-buffer-boundaries'
> should be made directly customizable through Custom in cus-start.el.

Agreed.


        Stefan

Re: fringe buffer-boundary bitmaps

[Richard M. Stallman]

    I understand that, but I don't see why we need two different ways to
    modify them -- you can redefine the standard bitmap directly, so I
    don't see why do we need an extra level of indirection here (which has
    to be done at the C level to an already quite complex piece of code).

    Currently, what we have are standard bitmaps for "bob-left",
    "bob-right", "eob-left", "eob-right" etc...

    But, rather than following the existing pattern of naming them after
    their purpose (like "continuation-line", "left-truncation" etc), I
    have named them after their visual appearence, e.g. "top-left-angle",
    "top-right-angle", "bottom-left-angle", etc...

    That is a bug IMO, so I agree with Miles that those names should be
    changed to match their purpose rather their appearence.

I would not say we "need" the extra level--that word is too
strong--but I think it would be cleaner.

It would be cleaner to name each bitmap after what it looks like, such
as top-left-angle, then specify by name one of these bitmaps to use
for a given purpose, such as beginning-of-buffer.

It's like defining a function with your own choice of name and then
putting that name in a hook or variable with a standard fixed name,
instead of redefining a function with a fixed name.

Re: fringe buffer-boundary bitmaps

[Kim F. Storm]

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

>     I understand that, but I don't see why we need two different ways to
>     modify them -- you can redefine the standard bitmap directly, so I
>     don't see why do we need an extra level of indirection here (which has
>     to be done at the C level to an already quite complex piece of code).
>
>     Currently, what we have are standard bitmaps for "bob-left",
>     "bob-right", "eob-left", "eob-right" etc...
>
>     But, rather than following the existing pattern of naming them after
>     their purpose (like "continuation-line", "left-truncation" etc), I
>     have named them after their visual appearence, e.g. "top-left-angle",
>     "top-right-angle", "bottom-left-angle", etc...
>
>     That is a bug IMO, so I agree with Miles that those names should be
>     changed to match their purpose rather their appearence.
>
> I would not say we "need" the extra level--that word is too
> strong--but I think it would be cleaner.
>
> It would be cleaner to name each bitmap after what it looks like, such
> as top-left-angle, then specify by name one of these bitmaps to use
> for a given purpose, such as beginning-of-buffer.
>
> It's like defining a function with your own choice of name and then
> putting that name in a hook or variable with a standard fixed name,
> instead of redefining a function with a fixed name.

I have finally found some time to work on this item in FOR-RELEASE.

I have installed some changes to implement it, along with changes to
the lispref and NEWS.  New buffer-local variables are
fringe-indicator-alist and fringe-cursor-alist.

Note that fringe.el is now pre-loaded, so I might have broken
something related to the way fringe-mode is handled, or the
involved code can be simplified.

Please take a look.

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

Re: fringe buffer-boundary bitmaps

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> I have installed some changes to implement it, along with changes to
> the lispref and NEWS.  New buffer-local variables are
> fringe-indicator-alist and fringe-cursor-alist.

Cool!  Thank you Kim!

-miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: fringe buffer-boundary bitmaps

[Giorgos Keramidas]

On 2006-02-20 23:38, "Kim F. Storm" <storm@cua.dk> wrote:
>"Richard M. Stallman" <rms@gnu.org> writes:
>>     I understand that, but I don't see why we need two different ways to
>>     modify them -- you can redefine the standard bitmap directly, so I
>>     don't see why do we need an extra level of indirection here (which has
>>     to be done at the C level to an already quite complex piece of code).
>>
>>     Currently, what we have are standard bitmaps for "bob-left",
>>     "bob-right", "eob-left", "eob-right" etc...
>>
>>     But, rather than following the existing pattern of naming them after
>>     their purpose (like "continuation-line", "left-truncation" etc), I
>>     have named them after their visual appearence, e.g. "top-left-angle",
>>     "top-right-angle", "bottom-left-angle", etc...
>>
>>     That is a bug IMO, so I agree with Miles that those names should be
>>     changed to match their purpose rather their appearence.
>>
>> I would not say we "need" the extra level--that word is too
>> strong--but I think it would be cleaner.
>>
>> It would be cleaner to name each bitmap after what it looks like, such
>> as top-left-angle, then specify by name one of these bitmaps to use
>> for a given purpose, such as beginning-of-buffer.
>>
>> It's like defining a function with your own choice of name and then
>> putting that name in a hook or variable with a standard fixed name,
>> instead of redefining a function with a fixed name.
>
> I have finally found some time to work on this item in FOR-RELEASE.
>
> I have installed some changes to implement it, along with changes to
> the lispref and NEWS.  New buffer-local variables are
> fringe-indicator-alist and fringe-cursor-alist.
>
> Note that fringe.el is now pre-loaded, so I might have broken
> something related to the way fringe-mode is handled, or the
> involved code can be simplified.

Revision 1.26 of fringe.el in CVS doesn't complete a bootstrap here:

    Compiling /home/keramida/svn/emacs/trunk/emacs/lisp/./rfn-eshadow.el
    Wrote /home/keramida/svn/emacs/trunk/emacs/lisp/rfn-eshadow.elc
    Compiling /home/keramida/svn/emacs/trunk/emacs/lisp/./rot13.el
    Wrote /home/keramida/svn/emacs/trunk/emacs/lisp/rot13.elc
    Compiling /home/keramida/svn/emacs/trunk/emacs/lisp/./ruler-mode.el

    In toplevel form:
    ruler-mode.el:115:1:Error: Symbol's value as variable is void: fringe-bitmaps
    *** Error code 1

    Stop in /home/keramida/svn/emacs/trunk/emacs/lisp.
    *** Error code 1

    Stop in /home/keramida/svn/emacs/trunk/emacs.
    *** Error code 1

    Stop in /home/keramida/svn/emacs/trunk/emacs.

It looks like ruler-mode.el needs to change a bit after fringe.el,1.26

Re: fringe buffer-boundary bitmaps

[Kim F. Storm]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> Revision 1.26 of fringe.el in CVS doesn't complete a bootstrap here:

Please try again.

> It looks like ruler-mode.el needs to change a bit after fringe.el,1.26

Yes,  the (require 'fringe) could be placed in eval-when-compile.

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

Re: fringe buffer-boundary bitmaps

[Giorgos Keramidas]

On 2006-02-21 12:40, "Kim F. Storm" <storm@cua.dk> wrote:
> Giorgos Keramidas <keramida@ceid.upatras.gr> writes:
>
> > Revision 1.26 of fringe.el in CVS doesn't complete a bootstrap here:
>
> Please try again.

1.27 works fine.  Amazingly fast fix, thanks :)

Re: fringe buffer-boundary bitmaps

[Chong Yidong]

storm@cua.dk (Kim F. Storm) writes:

> I have finally found some time to work on this item in FOR-RELEASE.
>
> I have installed some changes to implement it, along with changes to
> the lispref and NEWS.  New buffer-local variables are
> fringe-indicator-alist and fringe-cursor-alist.
>
> Note that fringe.el is now pre-loaded, so I might have broken
> something related to the way fringe-mode is handled, or the
> involved code can be simplified.
>
> Please take a look.

Looks good.  Thanks very much!

Re: fringe buffer-boundary bitmaps

[Richard M. Stallman]

Thanks for cleaning up that mess.  It is good that these features will
have a clean design in their first release.

Re: fringe buffer-boundary bitmaps

[Juri Linkov]

> I have finally found some time to work on this item in FOR-RELEASE.
>
> I have installed some changes to implement it, along with changes to
> the lispref and NEWS.  New buffer-local variables are
> fringe-indicator-alist and fringe-cursor-alist.
>
> Note that fringe.el is now pre-loaded, so I might have broken
> something related to the way fringe-mode is handled, or the
> involved code can be simplified.
>
> Please take a look.

Thanks, Kim.

Now what about adding to Emacs lighter-weight bitmaps proposed by Miles?
These bitmaps look much nicer with small font sizes.  I now have in .emacs:

(when (boundp 'fringe-indicator-alist)
  (define-fringe-bitmap 'light-down-arrow [32 32 32 32 32 32 168 112 32] nil nil 'bottom)
  (define-fringe-bitmap 'light-up-arrow [32 112 168 32 32 32 32 32 32] nil nil 'top)
  (define-fringe-bitmap 'light-top-left-angle [254 254 128 128 128] nil nil 'top)
  (define-fringe-bitmap 'light-bottom-left-angle [128 128 128 254 254] nil  nil 'bottom)
  (define-fringe-bitmap 'light-left-bracket [254 254 128 128 128 0 0 0 0 128 128 128 254 254] nil nil 'center)
  (define-fringe-bitmap 'light-right-curly-arrow [96 16 8 8 72 80 96 120] nil nil 'bottom)
  (define-fringe-bitmap 'light-left-curly-arrow [8 16 16 16 18 10 6 30] nil nil 'top)
  (define-fringe-bitmap 'light-right-arrow [16 8 252 8 16] nil 11 'center)
  (define-fringe-bitmap 'light-left-arrow [32 64 254 64 32] nil nil 'center)
  (setq-default fringe-indicator-alist
		'((truncation . (light-left-arrow light-right-arrow))
		  (continuation . (light-left-curly-arrow light-right-curly-arrow))
		  (overlay-arrow . right-triangle)
		  (up . light-up-arrow)
		  (down . light-down-arrow)
		  (top . (light-top-left-angle top-right-angle))
		  (bottom . (light-bottom-left-angle bottom-right-angle
			     top-right-angle light-top-left-angle))
		  (top-bottom . (light-left-bracket right-bracket
				 top-right-angle light-top-left-angle))
		  (empty-line . empty-line)
		  (unknown . question-mark))))

This is too much code for every user who wants a lighter-weight fringe bitmap
style.  It is also unclear where the user can get this code: find it from
emacs-devel archives, or from .emacs files of other Emacs users on the web?

I think lighter-weight bitmaps should be defined in Emacs, and there should
be an easy way (a customization option) to switch the whole set of bitmaps.

PS: Note that I modified lines in `light-left-arrow' and `light-right-arrow'
from dotted to solid, because dotted lines are too light.

Also I don't redefine a blob to an arrow, because I find an arrow more
"insisting": it draws more attention than a shapeless blob.

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

Re: fringe buffer-boundary bitmaps

[Kim F. Storm]

Juri Linkov <juri@jurta.org> writes:

> Now what about adding to Emacs lighter-weight bitmaps proposed by Miles?

Personally, I don't like these lighter bitmaps, but I wouldn't mind having
them installed as an optional set if it can be done cleanly.

The light-right-arrow doesn't work for me, as my fringes are only 9 pixels wide;
if I replace 11 by nil it works.

> I think lighter-weight bitmaps should be defined in Emacs, and there should
> be an easy way (a customization option) to switch the whole set of bitmaps.

Options -> Show/Hide -> Fringe ->  Indicator Style  ->  Normal | Light 

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

Re: fringe buffer-boundary bitmaps

[Richard Stallman]

    Now what about adding to Emacs lighter-weight bitmaps proposed by Miles?
    These bitmaps look much nicer with small font sizes.  I now have in .emacs:

Perhaps we could make Emacs select this automatically based
on the height of the default font.  But let's not do this now.

Re: fringe buffer-boundary bitmaps

[Juri Linkov]

>> Now what about adding to Emacs lighter-weight bitmaps proposed by Miles?
>
> Personally, I don't like these lighter bitmaps, but I wouldn't mind having
> them installed as an optional set if it can be done cleanly.
>
> The light-right-arrow doesn't work for me, as my fringes are only
> 9 pixels wide; if I replace 11 by nil it works.

As you can see in the definition of the light-right-arrow bitmap I sent
earlier, I already moved the image of this arrow on the original Miles'
definition 2 pixels to the left to fit into 9 pixel width.  Perhaps the
same result could be achieved when I replace 11 by nil.

>> I think lighter-weight bitmaps should be defined in Emacs, and there should
>> be an easy way (a customization option) to switch the whole set of bitmaps.
>
> Options -> Show/Hide -> Fringe ->  Indicator Style  ->  Normal | Light

Looks good to me.  I guess this can be done with a new customization option?

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