fringe bugs and issues (and a couple display margin bugs)

[Alveola Petrofsky]

In emacs 21.1:

Some of the bugs reported below everyone will agree are bugs.  Others
are more subjective, or clearly just feature requests.  Most of the
feature requests are for features that existed in emacs 20.

Since 21.1 came out, there have been many requests for the ability to
turn off fringes.  That ability has been added in the cvs sources, but
I believe that, as currently implemented, it will please no one.  What
the fringe detractors really want is emacs 20 fringe functionality,
not the total lack of continuation/truncation marks that results from
turning off fringes in 21.2.50.

The theme of this message is that there is no reason for the
divergence of X and tty fringe behavior.  Emacs has always had
fringes, it just hasn't used that name before.  The current
implementation of the new fringe features creates several unnecessary
and confusing differences between tty and X frames.  Why not use the
same terminology and provide the same functionality on both types of
frames?  The only point on which I see any reason to differ is in the
specification of fringe marks: glyphs are used on ttys and bitmaps on
X.  Is there any other aspect of fringes that's actually inherently
specific to window systems?


Bugs:

* Cursor is not displayed in fringes.

  emacs -q
  M-1 0 C-x 3
  C-x <
  
The cursor is now located in the first column of displayed text, but
it should be in the left fringe to indicate that point is not visible.

  M-: (setq automatic-hscrolling nil) RET
  C-e
  
Now the cursor disappears completely, and there is no indication of
what line point is in.  The cursor should be displayed in the right
fringe.

The second bug only occurs on X frames, the first one happens on X
and tty frames.  In emacs <=20, both X and tty frames handled both
scenarios correctly.

* Wasted screen space for empty continued lines.
In X frames, if a line ends just at the right fringe, an empty
continued line is displayed.  It should be possible to get the emacs 20
behavior of not continuing the line, and placing the cursor in the
fringe when point is at the end of such a line.  (The ability to
display the cursor in the fringe is necessary to fix the previous bug
anyway, so adding this shouldn't be too much trouble.)

* Wasted screen space for empty left fringe.
In X frames, there should be an option to have the left fringe
displayed if and only if the horizontal scroll position is non-zero.
Emacs <=20 had this feature.

* In the second sentence of (elisp) Horizontal Scrolling the word "vertical"
should be changed to "horizontal".

* Both manuals need more index entries for "fringe".
Specifically, in the nodes that discuss continuation marks, the
overlay arrow, and indicate-empty-lines.

* Truncation marks for empty lines.
When a window has been scrolled left, left-fringe truncation marks
should not be shown for empty lines (because there isn't anything that's
actually been cut off).  This puts more useful information in the left
fringe.  Emacs <=20 had this feature.
Try C-h n C-x < in emacs 20 and emacs 21 to see what I mean.
(Note: here I'm talking about actual empty lines within the buffer, not the
after-buffer "empty lines" of indicate-empty-lines.)

* Indicate-empty-lines should work on ttys.
As in 21.2.50, the fringe marks should be displayed in the right
fringe if there is no left fringe.

* (in 21.2.50) The overlay arrow should be overlayed when left fringe is off.

* (in 21.2.50) Fringe widths unit
Fringe widths should be specified in columns (with floating-point
values allowed), not pixels.
If you're trying to budget your screen space, columns are the more
convenient and resolution-independent unit, as well as being the
actual unit of allocation anyway.  If you're trying to match the width
of your bitmaps, you'll just use nil.
(The same goes for scroll-bar-width.)

* Fringes on wrong side of display margins.
Fringes should be inside display margins, shouldn't they?  In any
case they should be consistent on tty and X frames.  Currently the
fringes are inside the display margins on ttys and outside on X frames.

* window-width documentation unclear.
There are now several width-using window components: vertical lines,
scroll-bars, display margins, and fringes (both traditional and
new-fangled).  The window-width documentation should enumerate all
the elements and state which are included.

* window-min-width documentation unclear.
It needs to be stated that window-min-width specifies a minimum for
total width, not for the value returned by window-width.

* There should probably be a window-total-width convenience function.
This would aid documentation clarity, too.  Unfortunately, the
window-total-height function was long ago named window-height, so
complete consistency is probably not possible at this point, unless
you want to provide window-{body,total}-{width,height}, and mark the
inconsistent window-{width,height} functions obsolete.

* scroll-left and scroll-right go too far when there are display margins.
They scroll by one window-width, including display margins, which
means there's a gap of (+ left-margin-width right-margin-width)
characters between what is displayed before and after the command.

* Naming of display margin variables is poor.
left-margin-width is too similar to left-margin.  It should be named
left-display-margin.  (The "display" makes its meaning more obvious,
the lack of "width" makes its name more consistent.)  (Rename
right-margin-width too, of couse.)


-al