Customize fringe

Customize fringe

[Simon Josefsson]

What do you think of this?

Index: loadup.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/loadup.el,v
retrieving revision 1.122
diff -u -p -r1.122 loadup.el
--- loadup.el	27 Apr 2002 03:48:19 -0000	1.122
+++ loadup.el	9 May 2002 12:04:20 -0000
@@ -135,6 +135,7 @@
       (and (boundp 'x-toolkit-scroll-bars)
 	   (load "scroll-bar"))
       (load "select")))
+(load "fringe")
 (load "timer")
 (load "isearch")
 
Index: menu-bar.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/menu-bar.el,v
retrieving revision 1.216
diff -u -p -r1.216 menu-bar.el
--- menu-bar.el	1 May 2002 22:01:16 -0000	1.216
+++ menu-bar.el	9 May 2002 12:04:21 -0000
@@ -707,6 +707,23 @@ Do the same for the keys of the same nam
 	      :help "Toggle menu-bar on/off"
 	      :button (:toggle . menu-bar-mode)))
 
+(defun showhide-fringe ()
+  "Toggle whether to turn fringe on/off."
+  (interactive)
+  (fringe-mode)
+  (if (not fringe-mode)
+      (message "Fringe mode enabled.")
+    (message "Fringe mode disabled.")))
+
+(define-key menu-bar-showhide-menu [showhide-fringe]
+  '(menu-item "Fringe"
+	      (lambda ()
+		(interactive)
+		(showhide-fringe)
+		(customize-mark-as-set 'fringe-mode))
+	      :help "Toggle fringe on/off"
+	      :button (:toggle . (not fringe-mode))))
+
 (defun showhide-tool-bar ()
   "Toggle whether to turn tool-bar on/off."
   (interactive)
Index: fringe.el
===================================================================
RCS file: fringe.el
diff -N fringe.el
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ fringe.el	9 May 2002 12:04:21 -0000
@@ -0,0 +1,128 @@
+;;; fringe.el --- window system-independent fringe support
+
+;; Copyright (C) 2001 Free Software Foundation, Inc.
+
+;; Author: Simon Josefsson <simon@josefsson.org>
+;; Maintainer: FSF
+;; Keywords: hardware
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation; either version 2, or (at your option)
+;; any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs; see the file COPYING.  If not, write to the
+;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+;; Boston, MA 02111-1307, USA.
+
+;;; Commentary:
+
+;; This file contains helpful functions for enabling and disabling the
+;; fringe.
+
+;; It is based on scroll-bar.el.
+
+;;; Code:
+
+(defvar fringe-mode)
+
+(defvar fringe-mode-explicit nil
+  "Non-nil means `set-fringe-mode' should really do something.
+This is nil while loading `fringe.el', and t afterward.")
+
+(defun set-fringe-mode-1 (ignore value)
+  "Call `set-fringe-mode' with VALUE.
+See `fringe-mode' for possible modes and their effect.
+This is usually invoked when setting `fringe-mode' via customize."
+  (set-fringe-mode value))
+
+(defun set-fringe-mode (value)
+  "Set `fringe-mode' to VALUE and put the new value into effect.
+See `fringe-mode' for possible modes and their effect."
+  (setq fringe-mode value)
+
+  (when fringe-mode-explicit
+    ;; Apply it to default-frame-alist.
+    (let ((parameter (assq 'left-fringe default-frame-alist)))
+      (if (consp parameter)
+	  (setcdr parameter fringe-mode)
+	(setq default-frame-alist
+	      (cons (cons 'left-fringe fringe-mode)
+		    default-frame-alist))))
+    (let ((parameter (assq 'right-fringe default-frame-alist)))
+      (if (consp parameter)
+	  (setcdr parameter fringe-mode)
+	(setq default-frame-alist
+	      (cons (cons 'right-fringe fringe-mode)
+		    default-frame-alist))))
+
+    ;; Apply it to existing frames.
+    (let ((frames (frame-list)))
+      (while frames
+	(modify-frame-parameters
+	 (car frames)
+	 (list (cons 'left-fringe fringe-mode)
+	       (cons 'right-fringe fringe-mode)))
+	(setq frames (cdr frames))))))
+
+(defcustom fringe-mode nil
+  "*Specify presence and width of fringes.
+This variable can take on a integer value specifying the fringe
+width (both left and right) or nil meaning default fringe width.
+To set this variable in a Lisp program, use `set-fringe-mode' to make
+it take real effect.
+Setting the variable with a customization buffer also takes effect."
+  :type '(choice (const :tag "Default width" nil)
+		 (const :tag "No fringes" 0)
+		 (integer :tag "Specific width"))
+  :group 'frames
+  :set 'set-fringe-mode-1)
+
+;; We just set fringe-mode, but that was the default.
+;; If it is set again, that is for real.
+(setq fringe-mode-explicit t)
+
+(defun fringe-mode (&optional flag)
+  "Toggle display of the fringe on all frames.
+This command applies to all frames that exist and frames to be
+created in the future.
+With a numeric argument, if the argument is negative,
+turn off the fringe; otherwise, turn on the fringe."
+  (interactive "P")
+  (if flag (setq flag (prefix-numeric-value flag)))
+
+  ;; Tweedle the variable according to the argument.
+  (set-fringe-mode
+   (if (null flag)
+       (if (eq (cdr-safe (assq 'left-fringe default-frame-alist)) 0)
+	   nil
+	 0)
+     (and (numberp flag) (< flag 0) 0))))
+
+(defun toggle-fringe (arg)
+  "Toggle whether or not the selected frame has a left and right fringe.
+With arg, turn fringes on if and only if arg is positive."
+  (interactive "P")
+  (if (null arg)
+      (setq arg
+	    (if (eq (cdr (assq 'left-fringe
+			       (frame-parameters (selected-frame)))) 0)
+		nil
+	      0))
+    (setq arg (prefix-numeric-value arg)))
+  (modify-frame-parameters
+   (selected-frame)
+   (list (cons 'left-fringe arg)
+	 (cons 'right-fringe arg))))
+
+(provide 'fringe)
+
+;;; fringe.el ends here

Re: Customize fringe

[Miles Bader]

It seems rather odd to package this functionality as `fringe-mode',
since a `mode' suggests something that's typicall either on or off.
There are many possible states for fringes, of which quite a few will
probably be popular (some that come to mind are full/full [the default],
0/full, half/half, and 0/0 [no fringes]), and I don't think that image
we should present to users is of something that is either all there or
not there at all.

[Incidentally, why did your patch preload `fringe'?  I shouldn't think
it would be necessary.]

-Miles
-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Re: Customize fringe

[Simon Josefsson]

Miles Bader <miles@gnu.org> writes:

> It seems rather odd to package this functionality as `fringe-mode',
> since a `mode' suggests something that's typicall either on or off.

Either you have a fringe or you don't.  Same as menubar and toolbar.
Size, content, color etc is additional configuration.  IMHO.  But I
see your point.

> There are many possible states for fringes, of which quite a few will
> probably be popular (some that come to mind are full/full [the default],
> 0/full, half/half, and 0/0 [no fringes]), and I don't think that image
> we should present to users is of something that is either all there or
> not there at all.

Hm.  When would I want to have half a fringe?  What do you think of
the new :type below?  Hard coding half to 4 may not be perfect, but
"half width" isn't a concept otherwise known by the fringe code it
seems, so I'm not sure if there is a better solution.  "Only right"
and "Only left" seems quite useful though, perhaps I'll modify my own
behaviour from no fringes to 0/full.

  :type '(choice (const :tag "Default width" nil)
		 (const :tag "No fringes" 0)
		 (const :tag "Half width" (4 . 4))
		 (const :tag "Only right" (nil . 0))
		 (const :tag "Only left" (0 . nil))
		 (integer :tag "Specific width")
		 (cons :tag "Different left/right size" 
		       (integer :tag "Left width")
		       (integer :tag "Right width")))

Of course, the Options->Show/Hide submenu should have a "Fringe"
submenu similar to the scroll-bar, with common choices.

> [Incidentally, why did your patch preload `fringe'?  I shouldn't think
> it would be necessary.]

If I didn't preload it, my fringes didn't go away when I started
emacs.  I had to (require 'fringe).  Maybe I did something wrong?  It
looks similar to tool-bar-mode, scroll-bar-mode etc though.

Re: Customize fringe

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: 09 May 2002 21:28:30 +0900
> 
> [Incidentally, why did your patch preload `fringe'?  I shouldn't think
> it would be necessary.]

And if it _is_ necessary, please make that conditional on
(display-graphic-p).  Character terminals shouldn't need to load that
package at all.

Re: Customize fringe

[Stefan Monnier]

See my previous post yesterday or the day before on a separate thread
for why I don't think there should be a "toggle fringe" in the menu bar.


	Stefan

Re: Customize fringe

[Miles Bader]

Simon Josefsson <jas@extundo.com> writes:
> Either you have a fringe or you don't.  Same as menubar and toolbar.
> Size, content, color etc is additional configuration.  IMHO.  But I
> see your point.

My point was that, unlike menus or toolbars, people will _usually_ want to
do something besides turning fringes entirely on or off (presuming they
want to do anything at all), and that as a result, having `fringe-mode' +
adjustments is the wrong user-interface to this functionality.

Note that this is unlike the closest analogue (I think), scrollbars --
it's common for people to want to simply turn scrollbars on or off, but
the scrollbar location is merely a detail.

I expect a common case for the fringes, though will to be to want to
toggle between full-fringes and right-side-only.  This simply doesn't map
well to the name `fringe-mode'.

As to what the right interface is, I'm not really sure; I guess it depends
a lot on what people want to do with the fringes (personally, I think
they're fine, though I might want to use half/half if we could get it to
use some alternate bitmaps for that case).

> Of course, the Options->Show/Hide submenu should have a "Fringe"
> submenu similar to the scroll-bar, with common choices.

That's a much better user-interface than `fringe-mode'.

> If I didn't preload it, my fringes didn't go away when I started
> emacs.  I had to (require 'fringe).  Maybe I did something wrong?  It
> looks similar to tool-bar-mode, scroll-bar-mode etc though.

That sort of detail should be taken care of by the dependencies in your
defcustoms.  [e.g., with the :require parameter]

-Miles
-- 
97% of everything is grunge

Re: Customize fringe

[Simon Josefsson]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> See my previous post yesterday or the day before on a separate thread
> for why I don't think there should be a "toggle fringe" in the menu bar.

This was it:

>>    From: Thien-Thi Nguyen <ttn@glug.org>
>>    Date: 03 May 2002 20:39:35 -0400
>> 
>>    > i imagine arrows dancing around the screen, some question like "these
>>    > are fringes -- do you belong to the minimalist school of thought; i.e.,
>> 
>> I think that we miss a chapter with this in the manual...
>
> If you're talking about the dancing arrows, I might agree, although
> I'd point out that we also miss the corresponding implementation.
> As for the fringes, I would rather not advertise the ability to
> remove them (to new users).  I didn't like them at first, but I now
> think they're really cool (the only thing missing is the "cursor
> inside the right fringe" feature which would allow us to display 80
> char lines with no wrapping).
> I think new users could be tempted to turn them off and never discover
> how cool they are (and/or whine about how lame the gdb-arrow looks).

1) There are many modes (mainly non-text editing ones) where fringes
   are of little use, e.g. Gnus, PCL-CVS, W3, Shell, Speedbar, Info.
   I don't think we should hide the possibility of disabling them to
   the user. Fringes are annoying to the user in the same way toolbars
   and menubars are, and it should be easy to disable.  If we hadn't
   this discussion, I'd even argue the fringes should be disabled by
   default in those modes (much like speedbar disabled menubar and
   toolbar).

2) Alot of people asked for a way to disable the fringes after 21.1,
   this would make them happy, I think.

I also did not like them at first, and have been using them up until
now that I wrote this, but I still don't like them.  I find myself
running 20.7 when editing text just because I like the fringeless
behaviour better.  I don't think I'm alone in this..

Re: Customize fringe

[Simon Josefsson]

Miles Bader <miles@gnu.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>> Either you have a fringe or you don't.  Same as menubar and toolbar.
>> Size, content, color etc is additional configuration.  IMHO.  But I
>> see your point.
>
> My point was that, unlike menus or toolbars, people will _usually_ want to
> do something besides turning fringes entirely on or off (presuming they
> want to do anything at all), and that as a result, having `fringe-mode' +
> adjustments is the wrong user-interface to this functionality.

Ok.  I based the design from what I wanted out of it.  If other people
want to do more fine tuned things, I guess it is easy to add.

> Note that this is unlike the closest analogue (I think), scrollbars --
> it's common for people to want to simply turn scrollbars on or off, but
> the scrollbar location is merely a detail.

I disagree -- I rather disable the scrollbar than to have on the left.
The location is not a detail.

> I expect a common case for the fringes, though will to be to want to
> toggle between full-fringes and right-side-only.  This simply doesn't map
> well to the name `fringe-mode'.

Compare with scroll-bar-mode and menu-bar-mode, is it really that
different?  Given scroll-bar-mode and menu-bar-mode in the past, I'd
go look for a fringe-mode to customize the fringes, but maybe that's
just me.

> As to what the right interface is, I'm not really sure; I guess it depends
> a lot on what people want to do with the fringes (personally, I think
> they're fine, though I might want to use half/half if we could get it to
> use some alternate bitmaps for that case).

I want on/off, you suggested half/half and left only and right only.
Are there more?

>> If I didn't preload it, my fringes didn't go away when I started
>> emacs.  I had to (require 'fringe).  Maybe I did something wrong?  It
>> looks similar to tool-bar-mode, scroll-bar-mode etc though.
>
> That sort of detail should be taken care of by the dependencies in your
> defcustoms.  [e.g., with the :require parameter]

I'll try to do it some other way -- that part was cut'n'paste from how
scroll-bar-mode handled customize.

Re: Customize fringe

[Stefan Monnier]

> > See my previous post yesterday or the day before on a separate thread
> > for why I don't think there should be a "toggle fringe" in the menu bar.
> This was it:
[...]
No this was not it.
It was:

Subject: Re: Enhancements to options menu (was Re: Reveal mode)
To: Thien-Thi Nguyen <ttn@glug.org>
From: "Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu>
Date: Wed, 08 May 2002 09:37:08 -0400
Cc: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>,
   Pavel@Janik.cz (Pavel Janík),
   storm@cua.dk (Kim F. Storm), rms@gnu.org, emacs-devel@gnu.org

> "Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:
> 
>    I'm not sure whether those users were novices, but even if they were,
>    that's not relevant.  My point is that fringes are good and if a
>    novice removes them because she thinks she doesn't need them, she'll
>    probably hit problems later on because of it.  We don't break Java's
>    memory safety just because some novice Java programmers might ask
>    "how do I do pointer arithmetic".
> 
> hmmm, you make it sound like turning off fringes incurs some kind of
> threat to emacs' structural integrity or design, which would shock me if
> it were true.  [insert console-freak rantings here.]

Admittedly, I forced the tone.  But I just feel like users might miss
on the neat fringes just because they think they don't want them.
If you turn off the fringes you lose:
- legibility (chars stuck right next to a window border are more difficult
  to read; the fringes act like a margin).
- continuation glyphs (i.e. it's not the same as on console).
- neat icons instead of overlayed text for the gud&edebug overlay arrow.
- various future extensions like mouse bindings in the fringes.

I don't think the tradeoffs are obvious to the first-time user (even if he's
an experienced Emacs user) so she might make the wrong decision.  This
is to be contrasted to other "similar" things like the menu-bar, the
tool-bar, the scroll-bar where the user can be reasonably expected to know
what she loses by turning it off.

I'm not saying turning off the fringe should be a hidden feature.
Just that it shouldn't be in the user's face.


	Stefan

Re: Customize fringe

[Simon Josefsson]

[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

>> > See my previous post yesterday or the day before on a separate thread
>> > for why I don't think there should be a "toggle fringe" in the menu bar.
>> This was it:
> [...]
> No this was not it.
> It was:

Oops.  I guess there were several articles in the thread.

> Admittedly, I forced the tone.  But I just feel like users might miss
> on the neat fringes just because they think they don't want them.
> If you turn off the fringes you lose:
> - legibility (chars stuck right next to a window border are more difficult
>   to read; the fringes act like a margin).
> - continuation glyphs (i.e. it's not the same as on console).
> - neat icons instead of overlayed text for the gud&edebug overlay arrow.
> - various future extensions like mouse bindings in the fringes.
>
> I don't think the tradeoffs are obvious to the first-time user (even if he's
> an experienced Emacs user) so she might make the wrong decision.  This
> is to be contrasted to other "similar" things like the menu-bar, the
> tool-bar, the scroll-bar where the user can be reasonably expected to know
> what she loses by turning it off.
>
> I'm not saying turning off the fringe should be a hidden feature.
> Just that it shouldn't be in the user's face.

I think that would translate into having fringe.el but no
modifications to menu-bar.el, meaning the user need to M-x
toggle-fringe RET or something like that.

The following has the modifications suggested by Miles; it uses
:require and it has a more flexible :type.


[-- Attachment #2: fringe.el --]
[-- Type: application/emacs-lisp, Size: 4629 bytes --]

Re: Customize fringe

[Simon Josefsson]

[-- Attachment #1: Type: text/plain, Size: 175 bytes --]

Simon Josefsson <jas@extundo.com> writes:

> ;;; fringe.el --- window system-independent fringe support

That version contained some bugs.  The following should work better.


[-- Attachment #2: fringe.el --]
[-- Type: application/emacs-lisp, Size: 4612 bytes --]

Re: Customize fringe

[Kim F. Storm]

Simon Josefsson <jas@extundo.com> writes:

> What do you think of this?
> 

I would like you to wait implementing anything like this.
It is on my TODO list to make fringe configurable 
per buffer/window rather than per frame.

Something like variables left-margin-width / right-margin-width
and functions set-window-margin / window-margin.

Once that is in place, various modes may fine-tune their
use of the fringe (e.g. gdb may explicitly enable the left
fringe for the arrow, and speedbar may turn off both fringes
by default).

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

Re: Customize fringe

[Richard Stallman]

I don't have time to check whether your fringe.el is coherent with the
way we handle other such issues.  Could someone please do that?

It would be useful to compare with the way scroll bars are handled,
since they too can be on either side.  The situation is not entirely
parallel, since you'd only have a scroll bar on one side, whereas
fringes are normally on both; nonetheless, there is probably some coherence
to be had between scroll bars and fringes.

What I see immediately is that you set up loadup.el to preload this file.
That's wasteful--please autoload the entry points instead.

Re: Customize fringe

[Miles Bader]

Simon Josefsson <jas@extundo.com> writes:
> > My point was that, unlike menus or toolbars, people will _usually_ want to
> > do something besides turning fringes entirely on or off (presuming they
> > want to do anything at all), and that as a result, having `fringe-mode' +
> > adjustments is the wrong user-interface to this functionality.
> 
> Ok.  I based the design from what I wanted out of it.  If other people
> want to do more fine tuned things, I guess it is easy to add.

Let me be more explicit:  We _shouldn't_ adopt `fringe-mode' and then
`add' to it -- we should just call it something else.

The basic name of a feature has a strong influence on how people think of
it, even if it's possible to change the details on the side.  In this case
the name `fringe-mode' suggests (by example, from many other emacs
commands) that the `basic functionality' is to have fringes either (1) on
or (2) off.  If people see this, and are annoyed by the default fringes,
they're going to thing `oh, that's how I deal with those !@#$# fringes,'
invoke it, and (95% of the time) leave it at that, ending up with no
fringes -- and that's undesirable, since other configurations also save
space without incurring the rather high penalty in usability that no
fringes does.

Here's a suggestion for what I think is a better interface:

Call it `reduced-fringe-mode', and have it switch between full fringes
and, say, right-fringe-only.  People who _really_ want to have no fringes
at all can customize an associated configuration variable and choose that
possiblity as the `reduced' state, and it will still make sense.  It could
also allow a C-u prefix to select an alternative configuration, or prompt
for the configuration, or whatever.

> > it's common for people to want to simply turn scrollbars on or off, but
> > the scrollbar location is merely a detail.
> 
> I disagree -- I rather disable the scrollbar than to have on the left.
> The location is not a detail.

That's what I said -- `people to want to simply turn scrollbars on or
off.'  Here `detail' implies a secondary characteristic, of less
importantance that the main `boolean' behavior (and obviously for you, of
_zero_ importance).

> Compare with scroll-bar-mode and menu-bar-mode, is it really that
> different?

Yes, because simply eliminating fringes is more harmful than removing the
scroll-bar or menu-bar (which have good alternatives), so we want to
gently encourage people to do something less drastic -- and I think people
would generally be happy with a `reduced' option.  I suspect that the main
thing that makes people dislike fringes is that a whole column for each
side seems like a lot of wasted space, especially for the left side (where
it's much more obvious than the right-side because all the text abuts it).

> I want on/off, you suggested half/half and left only and right only.
> Are there more?

I don't think it really matters for this purpose; if any are found, they
can easily be added later.

I think enhancing the display code so that it tries to use alternative
bitmaps for `reduced' fringes would make them much more useful --
e.g. a 4/4 split or 2/6 split might be perfect if they had bitmaps
tuned for them.

-Miles
-- 
97% of everything is grunge

Re: Customize fringe

[Eli Zaretskii]

> From: Miles Bader <miles@lsi.nec.co.jp>
> Date: 10 May 2002 10:32:08 +0900
> 
> The basic name of a feature has a strong influence on how people think of
> it

Agreed.  However, we do have *-mode functions that take more than
on/off choices.  An example is mouse-avoidance-mode.

> Call it `reduced-fringe-mode', and have it switch between full fringes
> and, say, right-fringe-only.  People who _really_ want to have no fringes
> at all can customize an associated configuration variable and choose that
> possiblity as the `reduced' state, and it will still make sense.  It could
> also allow a C-u prefix to select an alternative configuration, or prompt
> for the configuration, or whatever.

To continue the same example, mouse-avoidance-mode prompts for the
avoidance method.

Re: Customize fringe

[Miles Bader]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:
> However, we do have *-mode functions that take more than
> on/off choices.  An example is mouse-avoidance-mode.  To continue the
> same example, mouse-avoidance-mode prompts for the avoidance method.

I think that would be a reasonable solution for the fringe too (though
if people would want to toggle between, say, `reduced' and `full' modes,
the prompting might become annoying; I don't know how people will
actually use this functionaity, so it's hard to say if it matters).

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: Customize fringe

[Kim F. Storm]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> To continue the same example, mouse-avoidance-mode prompts for the
> avoidance method.

.. and we could call it fringe-avoidance-mode  :-)

In any case, I think general fringe on/off will be less useful
once fringes are per buffer/window rather than per frame.

At lease, fringe.el should have some hooks (e.g. an alist) which
automatically selects the proper (default) fringe setup for
various major modes.

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

Re: Customize fringe

[Robert J. Chassell]

    The basic name of a feature has a strong influence on how people
    think of it ....

Miles is right:

  * if I toggle mouse-avoidance-mode, I expect the mouse appear or go
    away, as the documentation says;

  * if I toggle font-lock-mode, I expect Font Locking to turn on or off. 

By the same reasoning,

  * if I toggle fringe-mode, I expect the fringe to appear or vanish;

  * if I toggle reduced-fringe-mode, I expect the fringe to appear or
    be reduced.  (I can also imagine that if I give a zero-width
    argument to reduced-fringe-mode, I can reduce the fringes to zero
    width.  But then, I am no longer an Emacs newbie.)

Hence, if the goal is to encourage people to use fringes of some
width, be the width large or small, on one side or two, in those
circumstances where fringes make sense, then reduced-fringe-mode is a
better name.

If, on the other hand, the goal is to enable people to turn off
fringes altogether, even in situations where Emacs can handle them,
then fringe-mode is a better name.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: Customize fringe

[Robert J. Chassell]

On 2002 May 10, Eli Zaretskii <eliz@is.elta.co.il> wrote:

   In any case, I think general fringe on/off will be less useful
   once fringes are per buffer/window rather than per frame.

Yes, this is definitely true.  Indeed, I tend to think of all toggles
as per-buffer rather than per-frame, even though I know they are not.

This is because I seen the buffer as the fundamental unit: the place
where one works, the place that holds files, the place where commands
go and messages come from (in my mental model of what Emacs does, a
mini-buffer/echo area applies only to the current buffer, not to a
frame); when I run an external process, such as grep, I see it as
within a buffer, and independent of other buffers.

That, by the way, is why I expect one instance of Emacs to be able to
run multiple Emacs Lisp processes at the same time and am still, often
surprised that Emacs cannot -- I know the difficulties of doing this;
I am saying that the feature is contrary to my expectation.

In other words, I think of a buffer metaphorically as a `place', such
as an island in an ocean.  I can approach such an island in various
ways; that is to say, I can open several windows on the same buffer;
and different buffers have different features available to me.  Dired
buffers enable me to do some things, *cvs* buffers enable me to do
other things, buffers visiting files enable be to do yet different
actions.  Moreover, I can copy from one island to another using the
`kill' command.  

Note how the naming of the `kill' command comes from a different
metaphor.  In a metaphor based on place, `kill' is the wrong metaphor;
the word should be `clip', as in clipping the blossom off of a flower.
But where text is seen as a living entity that a god can kill
resurrect, `kill' become the right metaphor.  The `cut', `paste'
metaphor comes from the old practice, which I engaged in before
computers, of cutting segments of text out of pages, and pasting them
onto fresh paper so the resulting document has the segments of text in
a different order.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: Customize fringe

[Robert J. Chassell]

My mistake and my apologies, it was storm@cua.dk (Kim F. Storm) who wrote:

   In any case, I think general fringe on/off will be less useful
   once fringes are per buffer/window rather than per frame.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: Customize fringe

[Eli Zaretskii]

> From: "Robert J. Chassell" <bob@rattlesnake.com>
> Date: Fri, 10 May 2002 10:44:27 +0000 (UTC)
> 
>   * if I toggle mouse-avoidance-mode, I expect the mouse appear or go
>     away, as the documentation says;

The documentation of mouse-avoidance-mode says:

    Set cursor avoidance mode to MODE.
    MODE should be one of the symbols `banish', `exile', `jump', `animate',
    `cat-and-mouse', `proteus', or `none'.

    If MODE is nil, toggle mouse avoidance between `none' and `banish'
    modes.

So it's not a simple toggle.  Interactively, it prompts you for the
avoidance mode; that is not what a simple toggle is expected to do.

There are some *-mode functions that are simple on/off toggles, but
that's not universally true.

> Hence, if the goal is to encourage people to use fringes of some
> width, be the width large or small, on one side or two, in those
> circumstances where fringes make sense, then reduced-fringe-mode is a
> better name.

I'm not sure.  The ``reduction'' of the fringes sounds a lot like
different styles, so perhaps set-fringe-style or some such would be a
better name (assuiming that fringe-mode is deemed not a good idea).

Re: Customize fringe

[Robert J. Chassell]

   The documentation of mouse-avoidance-mode says:

       Set cursor avoidance mode to MODE.
       MODE should be one of the symbols `banish', `exile', `jump', `animate',
       `cat-and-mouse', `proteus', or `none'.

       If MODE is nil, toggle mouse avoidance between `none' and `banish'
       modes.

   So it's not a simple toggle.  Interactively, it prompts you for the
   avoidance mode; that is not what a simple toggle is expected to do.

Good point. I missed that, which indicates that I expect a simple
on/off toggle....  

   I'm not sure.  The ``reduction'' of the fringes sounds a lot like
   different styles, so perhaps set-fringe-style or some such would be a
   better name...

I agree; that is a much better name, it is like `set-fill-column'.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: Customize fringe

[Richard Stallman]

    I think that would translate into having fringe.el but no
    modifications to menu-bar.el, meaning the user need to M-x
    toggle-fringe RET or something like that.

I think it would be good to have menu bar items for the fringes.

Re: Customize fringe

[Richard Stallman]

    > I disagree -- I rather disable the scrollbar than to have on the left.
    > The location is not a detail.

    That's what I said -- `people to want to simply turn scrollbars on or
    off.'

I suspect he meant to say, "I WOULD rather disable the scrollbar than
have it on the left."  If so, his point is just the opposite: which
side it's on is more important to him than whether it is there at all.

Simon, please correct me if I am wrong.

Re: Customize fringe

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

>     > I disagree -- I rather disable the scrollbar than to have on the left.
>     > The location is not a detail.
>
>     That's what I said -- `people to want to simply turn scrollbars on or
>     off.'
>
> I suspect he meant to say, "I WOULD rather disable the scrollbar than
> have it on the left."  If so, his point is just the opposite: which
> side it's on is more important to him than whether it is there at all.
>
> Simon, please correct me if I am wrong.

Yes, that was what I meant, sorry my english isn't very good.

Re: Customize fringe

[Pavel Janík]

   From: Simon Josefsson <jas@extundo.com>
   Date: Fri, 10 May 2002 00:24:59 +0200

Hi Simon,

   > > ;;; fringe.el --- window system-independent fringe support

I like it. Can you think of an interface to this in Show/Hide menu? What
about this:

Show/Hide -> Fringe -> Default
                       None
                       Only Right
                       Only Left
                       Customize (link to Customize buffer)

Can you implement it when we all agree on it?

   > ;; Copyright (C) 2001 Free Software Foundation, Inc.

2002

   > ;; Keywords: hardware

I think that frames or something similar would be better.

   > This variable can be nil (the default) meaning the fringes should have
   > the default width (8 pixels), it can be an integer value specifying

I though that the default width of fringe is dependant on the font
used. Can you please check this?
-- 
Pavel Janík

Choose variable names that won't be confused.
                  --  The Elements of Programming Style (Kernighan & Plaugher)

Re: Customize fringe

[Simon Josefsson]

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

> Simon Josefsson <jas@extundo.com> writes:
>
>> What do you think of this?
>
> I would like you to wait implementing anything like this.
> It is on my TODO list to make fringe configurable 
> per buffer/window rather than per frame.
>
> Something like variables left-margin-width / right-margin-width
> and functions set-window-margin / window-margin.
>
> Once that is in place, various modes may fine-tune their
> use of the fringe (e.g. gdb may explicitly enable the left
> fringe for the arrow, and speedbar may turn off both fringes
> by default).

Hm.  Aren't these separate issues?  Fine tuning for each mode would
require per buffer fringes.  But the overall customization by the user
to disable fringes works if default-frame-alist and all existing
frames are modified.  If the fine tuning exist, it can override the
frame wide decision not to have fringes.

My main goal is that it should not be very difficult for the user to
just disable fringes everywhere, much like you can disable the toolbar
and menubar everywhere today.  Fine tuning is useful for re-enabling
fringes in those modes where the user wants them, but couldn't that be
added to fringe.el later?

But I won't do anything if you and others object, of course.

Re: Customize fringe

[Simon Josefsson]

Pavel@Janik.cz (Pavel Janík) writes:

>    > > ;;; fringe.el --- window system-independent fringe support
>
> I like it. Can you think of an interface to this in Show/Hide menu? What
> about this:
>
> Show/Hide -> Fringe -> Default
>                        None
>                        Only Right
>                        Only Left
>                        Customize (link to Customize buffer)
>
> Can you implement it when we all agree on it?

The patch below does this (fringe.el as posted previously is needed as
well).

I think it looks good in the menu, but I also think there is no
consensus on doing anything.

>    > This variable can be nil (the default) meaning the fringes should have
>    > the default width (8 pixels), it can be an integer value specifying
>
> I though that the default width of fringe is dependant on the font
> used. Can you please check this?

It says 8 pixels in NEWS.

--- menu-bar.el.~1.217.~	Fri May 10 22:10:18 2002
+++ menu-bar.el	Sat May 11 11:00:54 2002
@@ -583,7 +583,7 @@
     ;; These are set with `customize-set-variable'.
     (dolist (elt '(line-number-mode column-number-mode scroll-bar-mode
 		   debug-on-quit debug-on-error menu-bar-mode tool-bar-mode
-		   save-place uniquify-buffer-name-style
+		   save-place uniquify-buffer-name-style fringe-mode
 		   case-fold-search cua-mode show-paren-mode
 		   transient-mark-mode global-font-lock-mode
 		   display-time-mode auto-compression-mode
@@ -653,6 +653,57 @@
 			      (frame-visible-p
 			       (symbol-value 'speedbar-frame))))))
 
+(setq menu-bar-showhide-fringe-menu (make-sparse-keymap "Fringe"))
+
+(define-key menu-bar-showhide-fringe-menu [customize]
+  '(menu-item "Customize"
+	      (lambda ()
+		(interactive)
+		(customize-variable 'fringe-mode))
+	      :help "Detailed customization of fringe"
+	      :visible (display-graphic-p)))
+
+(define-key menu-bar-showhide-fringe-menu [default]
+  '(menu-item "Default"
+	      (lambda ()
+		(interactive)
+		(customize-set-variable 'fringe-mode nil))
+	      :help "Default width fringe on both left and right side"
+	      :visible (display-graphic-p)
+	      :button (:radio . (eq fringe-mode nil))))
+
+(define-key menu-bar-showhide-fringe-menu [left]
+  '(menu-item "On the Left"
+	      (lambda ()
+		(interactive)
+		(customize-set-variable 'fringe-mode '(nil . 0)))
+	      :help "Fringe only on the left side"
+	      :visible (display-graphic-p)
+	      :button (:radio . (equal fringe-mode '(nil . 0)))))
+
+(define-key menu-bar-showhide-fringe-menu [right]
+  '(menu-item "On the Right"
+	      (lambda ()
+		(interactive)
+		(customize-set-variable 'fringe-mode '(0 . nil)))
+	      :help "Fringe only on the right side"
+	      :visible (display-graphic-p)
+	      :button (:radio . (equal fringe-mode '(0 . nil)))))
+
+(define-key menu-bar-showhide-fringe-menu [none]
+  '(menu-item "None"
+	      (lambda ()
+		(interactive)
+		(customize-set-variable 'fringe-mode 0))
+	      :help "Turn off fringe"
+	      :visible (display-graphic-p)
+	      :button (:radio . (eq fringe-mode 0))))
+
+(define-key menu-bar-showhide-menu [showhide-fringe]
+  (list 'menu-item "Fringe" menu-bar-showhide-fringe-menu
+	:visible `(display-graphic-p)
+	:help "Select fringe mode"))
+
 (defvar menu-bar-showhide-scroll-bar-menu (make-sparse-keymap "Scroll-bar"))
 
 (define-key menu-bar-showhide-scroll-bar-menu [right]

Re: Customize fringe

[Eli Zaretskii]

> From: Simon Josefsson <jas@extundo.com>
> Date: Sat, 11 May 2002 11:14:46 +0200
>  
> +(setq menu-bar-showhide-fringe-menu (make-sparse-keymap "Fringe"))
> +
> +(define-key menu-bar-showhide-fringe-menu [customize]
> +  '(menu-item "Customize"
> +	      (lambda ()
> +		(interactive)
> +		(customize-variable 'fringe-mode))
> +	      :help "Detailed customization of fringe"
> +	      :visible (display-graphic-p)))

I think it's generally best to avoid anonymous lambda expressions in
the menu bar bindings, since they cause "C-h c" and "C-h k" to display
useless information for anyone but Lisp hackers.

Re: Customize fringe

[Simon Josefsson]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

>> +	      (lambda ()
>> +		(interactive)
>> +		(customize-variable 'fringe-mode))
>
> I think it's generally best to avoid anonymous lambda expressions in
> the menu bar bindings, since they cause "C-h c" and "C-h k" to display
> useless information for anyone but Lisp hackers.

I agree, altough menu-bar.el is full of similar constructs so doing
something else probably makes it more difficult to read the code.  The
best would be if all anonymous lambda expressions in the file were
removed though.

Re: Customize fringe

[Simon Josefsson]

On Sunday 12 May 2002 01:44, Kim F. Storm wrote:
> Simon Josefsson <jas@extundo.com> writes:
> > storm@cua.dk (Kim F. Storm) writes:
> > > Simon Josefsson <jas@extundo.com> writes:
> > >> What do you think of this?
> > >
> > > I would like you to wait implementing anything like this.
> > > It is on my TODO list to make fringe configurable
> > > per buffer/window rather than per frame.
> > >
> > > Something like variables left-margin-width / right-margin-width
> > > and functions set-window-margin / window-margin.
> > >
> > > Once that is in place, various modes may fine-tune their
> > > use of the fringe (e.g. gdb may explicitly enable the left
> > > fringe for the arrow, and speedbar may turn off both fringes
> > > by default).
> >
> > Hm.  Aren't these separate issues?  Fine tuning for each mode would
> > require per buffer fringes.  But the overall customization by the user
> > to disable fringes works if default-frame-alist and all existing
> > frames are modified.  If the fine tuning exist, it can override the
> > frame wide decision not to have fringes.
>
> Can it?  Should it?
>
> If you think of this as similar to the menu-bar, I don't think we
> have any major modes which turns on the menu bar if the user has
> turned it off  (and likewise with the scroll-bar).

I don't know -- for me disabling the fringes everywhere is acceptable (and, to 
me, preferable).  I was trying to understand why fine tuning of fringes would 
be useful, and then trying to understand how this fine tuning relates to the 
high level customization made possible by fringe.el.

> So will it be acceptable to have a non-standard behaviour for fringes
> where major (or minor) modes override the user's choice?

Probably not.  OTOH, some modes do override the user's choice because it 
"knows better".  E.g., speedbar (menu-bar, tool-bar) and ediff (ditto).

> I would prefer to have per-buffer fringes controlled by a per-mode
> alist -- then you (as a user) will be able to add e.g. fundamental-mode
> and text-mode to that alist with option "no fringes".
>
> That's less intrusive than simply turning off the fringe for all modes.

Ah.  That could be useful. Would adding similar controls for controlling the 
menu-bar and tool-bar be useful as well?

> IMO it is a bad idea to remove the left fringe in e.g. C buffers, as
> it is used by gdb-mode if you debug that C program/module.

gdb-mode moves the point as well, if I recall correctly.  I'm satisfied with 
that, and in fact I prefer it over having an arrow in the fringe.

> However, I don't object to adding "Fringe" to the Show/Hide menu -- as
> long as it is understood that it only controls the default settings
> for the fringes.  I think the options should be: Both/Left/Right/None.

Yes, sounds good.

> > My main goal is that it should not be very difficult for the user to
> > just disable fringes everywhere, much like you can disable the toolbar
> > and menubar everywhere today.  Fine tuning is useful for re-enabling
> > fringes in those modes where the user wants them, but couldn't that be
> > added to fringe.el later?
>
> Yes.

Ok.

Re: Customize fringe

[Kim F. Storm]

Simon Josefsson <jas@extundo.com> writes:

> >
> > I though that the default width of fringe is dependant on the font
> > used. Can you please check this?
> 
> It says 8 pixels in NEWS.

It says more than that...  By default, the minimum width is 8 pixels
PLUS additional pixels necessary to make the combined fringe widths an
integral number of characters.

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

Re: Customize fringe

[Kim F. Storm]

Simon Josefsson <jas@extundo.com> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > Simon Josefsson <jas@extundo.com> writes:
> >
> >> What do you think of this?
> >
> > I would like you to wait implementing anything like this.
> > It is on my TODO list to make fringe configurable 
> > per buffer/window rather than per frame.
> >
> > Something like variables left-margin-width / right-margin-width
> > and functions set-window-margin / window-margin.
> >
> > Once that is in place, various modes may fine-tune their
> > use of the fringe (e.g. gdb may explicitly enable the left
> > fringe for the arrow, and speedbar may turn off both fringes
> > by default).
> 
> Hm.  Aren't these separate issues?  Fine tuning for each mode would
> require per buffer fringes.  But the overall customization by the user
> to disable fringes works if default-frame-alist and all existing
> frames are modified.  If the fine tuning exist, it can override the
> frame wide decision not to have fringes.

Can it?  Should it?

If you think of this as similar to the menu-bar, I don't think we
have any major modes which turns on the menu bar if the user has
turned it off  (and likewise with the scroll-bar).

So will it be acceptable to have a non-standard behaviour for fringes
where major (or minor) modes override the user's choice?

I would prefer to have per-buffer fringes controlled by a per-mode
alist -- then you (as a user) will be able to add e.g. fundamental-mode
and text-mode to that alist with option "no fringes".

That's less intrusive than simply turning off the fringe for all modes.

IMO it is a bad idea to remove the left fringe in e.g. C buffers, as
it is used by gdb-mode if you debug that C program/module.

However, I don't object to adding "Fringe" to the Show/Hide menu -- as
long as it is understood that it only controls the default settings
for the fringes.  I think the options should be: Both/Left/Right/None.

> 
> My main goal is that it should not be very difficult for the user to
> just disable fringes everywhere, much like you can disable the toolbar
> and menubar everywhere today.  Fine tuning is useful for re-enabling
> fringes in those modes where the user wants them, but couldn't that be
> added to fringe.el later?
> 
Yes.

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

Re: Customize fringe

[Eli Zaretskii]

On Sun, 12 May 2002, Simon Josefsson wrote:

> > IMO it is a bad idea to remove the left fringe in e.g. C buffers, as
> > it is used by gdb-mode if you debug that C program/module.
> 
> gdb-mode moves the point as well, if I recall correctly.

But what if the user disables the cursor in non-selected windows?

Re: Customize fringe

[Simon Josefsson]

On Sunday 12 May 2002 06:49, Eli Zaretskii wrote:
> On Sun, 12 May 2002, Simon Josefsson wrote:
> > > IMO it is a bad idea to remove the left fringe in e.g. C buffers, as
> > > it is used by gdb-mode if you debug that C program/module.
> >
> > gdb-mode moves the point as well, if I recall correctly.
>
> But what if the user disables the cursor in non-selected windows?

The point is still moved, isn't it?   There are many nonsensical 
customizations possible, does it really make sense to detect them and do 
something clever?  FWIW, I wouldn't have any problem with no fringe and no 
visible cursor, as gud-mode recenter the display when the breakpoint hits and 
from there I can remember how many (3-4 max) 'n' I typed and look at the 
right line, until it recenters again.

Re: Customize fringe

[Eli Zaretskii]

On Sun, 12 May 2002, Simon Josefsson wrote:

> > > gdb-mode moves the point as well, if I recall correctly.
> >
> > But what if the user disables the cursor in non-selected windows?
> 
> The point is still moved, isn't it?

It does, but you won't see it until you switch to the source buffer.

> There are many nonsensical 
> customizations possible, does it really make sense to detect them and do 
> something clever?

I don't see why customizing cursor-in-non-selected-windows should be 
considered nonsensical.

Re: Customize fringe

[Simon Josefsson]

On Sunday 12 May 2002 12:06, Eli Zaretskii wrote:
> > There are many nonsensical
> > customizations possible, does it really make sense to detect them and do
> > something clever?
>
> I don't see why customizing cursor-in-non-selected-windows should be
> considered nonsensical.

Eh.  I thought you meant that disabling both the fringe and 
cursor-in-non-selected-windows was nonsensical.  I don't agree, but I also 
don't think emacs should detect nonsensical combinations of customizations.  
So I don't understand what the problem is now.

Re: Customize fringe

[Eli Zaretskii]

On Sun, 12 May 2002, Simon Josefsson wrote:

> > I don't see why customizing cursor-in-non-selected-windows should be
> > considered nonsensical.
> 
> Eh.  I thought you meant that disabling both the fringe and 
> cursor-in-non-selected-windows was nonsensical.  I don't agree, but I also 
> don't think emacs should detect nonsensical combinations of customizations.  
> So I don't understand what the problem is now.

It went this way: you said point was enough to show the current execution 
line in a program being debugged; I said that the point is only visible 
if either you are in the source buffer or the cursor is visible in 
non-selected windows.

In other words, if the selected window is the one which displays the GUD 
buffer, and the user customized cursor-in-non-selected-windows to not 
display the cursor, you won't see where point is, and thus the current 
execution line is invisible if there's no left fringe.

Re: Customize fringe

[Miles Bader]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:
> I'm not sure.  The ``reduction'' of the fringes sounds a lot like
> different styles, so perhaps set-fringe-style or some such would be a
> better name (assuiming that fringe-mode is deemed not a good idea).

I like that too.  What would customization option be called?  [I guess
`fringe-style' or something]

Anyway, the important point seems to be that it should prompt for a
style rather than simply toggling.

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: Customize fringe

[Richard Stallman]

    So will it be acceptable to have a non-standard behaviour for fringes
    where major (or minor) modes override the user's choice?

That seems like a good idea.

I think the best way is to have a buffer-local variable that the mode
can set.  That is how major modes control most everything else.
If a major mode says it wants fringes, that should override the default
selected by the user.

    However, I don't object to adding "Fringe" to the Show/Hide menu -- as
    long as it is understood that it only controls the default settings
    for the fringes.

Right.