x-uunet-gateway: mr1.ash.ops.us.uu.net from bug-gnu-emacs to
gnu.emacs.bug; Mon, 21 Jan 2002 21:12:02 GMT
Date: Mon, 21 Jan 2002 13:11:59 -0800
Message-ID: <200201212111.NAA00419@radish.petrofsky.org>
From: alv...@petrofsky.org (Alveola Petrofsky)
Subject: fringe bugs and issues (and a couple display margin bugs)
Approved: bug-gnu-em...@mail.gnu.org
Newsgroups: gnu.emacs.bug
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.uchicago.edu!newsfeed.cs.wisc.edu!nnxp1.twtelecom.net!
news-out.visi.com!hermes.visi.com!uunet!ash.uu.net!
spool0901.news.uu.net!wendy-fate.uu.net!bug-gnu-emacs
Sender: bug-gnu-em...@mail.gnu.org
Lines: 126
Xref: archiver1.google.com gnu.emacs.bug:4657
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
x-uunet-gateway: mr1.ash.ops.us.uu.net from bug-gnu-emacs to
gnu.emacs.bug; Tue, 22 Jan 2002 08:14:35 GMT
Date: Tue, 22 Jan 2002 01:14:31 -0700
Message-ID: < 200201220814.g0M8EVb15077@aztec.santafe.edu>
X-Authentication-Warning: aztec.santafe.edu: rms set sender to
rms@aztec using -f
From: r...@gnu.org (Richard Stallman)
Subject: Re: fringe bugs and issues (and a couple display margin bugs)
Reply-To: r...@gnu.org
References: < 200201212111.NAA00419@radish.petrofsky.org>
Approved: bug-gnu-em...@mail.gnu.org
Newsgroups: gnu.emacs.bug
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
nntp.cs.ubc.ca!newsfeed.direct.ca!look.ca!news-out.visi.com!
hermes.visi.com!uunet!ash.uu.net!spool0901.news.uu.net!wendy-fate.uu.net!
bug-gnu-emacs
Sender: bug-gnu-em...@mail.gnu.org
Lines: 37
Xref: archiver1.google.com gnu.emacs.bug:4664
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.
We would like to have this feature, but we need someone to implement
it. Gerd, who knows the code, is not available; I don't have time to
do it. Would anyone like to volunteer?
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.
Displaying cursors in fringes is an interesting idea, but I am not
sure I like it. This is definitely not a simple bug.
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.
This must be a misunderstanding, because Emacs has never done this.
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.
Emacs on ttys does not have fringes. It uses a different method.
There are tremendous, and intentional, differences between the way
redisplay works on window systems and how it works on ttys. It would
not make sense to try to unify them. The difference between fringes
and continuation markers is the least of them.
It is certainly possible to implement the tty-style continuation markers
on window systems, and I think that would be useful if someone wants
to write it. However, to try to unify these two two alternatives and
call them both "fringes" would be more hassle than benefit.
x-uunet-gateway: chi6sosrv11.alter.net from bug-gnu-emacs to
gnu.emacs.bug; Tue, 22 Jan 2002 09:48:12 GMT
Date: Tue, 22 Jan 2002 11:47:09 +0200
From: "Eli Zaretskii" <el...@is.elta.co.il>
Sender: ha...@zahav.net.il
Message-ID: <7704-Tue22Jan2002114709+0200-eliz@is.elta.co.il>
X-Mailer: emacs 21.2.50 (via feedmail 8 I) and Blat ver 1.8.9
Subject: Re: fringe bugs and issues (and a couple display margin bugs)
Reply-To: el...@is.elta.co.il (Eli Zaretskii)
References: <200201212111.NAA00419@radish.petrofsky.org>
Approved: bug-gnu-em...@mail.gnu.org
Newsgroups: gnu.emacs.bug
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
bloom-beacon.mit.edu!news-out.cwix.com!newsfeed.cwix.com!
nntp.abs.net!uunet!dca.uu.net!ash.uu.net!spool0901.news.uu.net!
wendy-fate.uu.net!bug-gnu-emacs
Lines: 33
Xref: archiver1.google.com gnu.emacs.bug:4665
> From: Alveola Petrofsky <alv...@petrofsky.org>
> Date: Mon, 21 Jan 2002 13:11:59 -0800
>
> The theme of this message is that there is no reason for the
> divergence of X and tty fringe behavior.
The reason is that the display code is different in these two cases.
In Emacs 21, these differences are much more significant than they
were before. So making the two versions support the same features
got harder.
In other words, these issues wait for motivated individuals who have
enough resources to make them happen.
> Is there any other aspect of fringes that's actually inherently
> specific to window systems?
The way the display code works is totally different.
> * Fringes on wrong side of display margins.
> Fringes should be inside display margins, shouldn't they?
I'm not sure. Please tell why do you think so.
> 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.
That's because tty's don't support fringes at all. If you refer to
the places where continuation and truncation glyphs are displayed as
the fringe, then the behavior is inconsistent. But that's not how
Emacs refers to that. For Emacs display code, fringes simply don't
exist on a character terminal.
x-uunet-gateway: mr1.ash.ops.us.uu.net from bug-gnu-emacs to
gnu.emacs.bug; Tue, 22 Jan 2002 23:08:01 GMT
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
newsfeeds.belnet.be!news.belnet.be!news-hub.siol.net!zur.uu.net!
ash.uu.net!spool0901.news.uu.net!wendy-fate.uu.net!corp.supernews.com!
not-for-mail
From: alv...@petrofsky.org (Alveola Petrofsky)
Subject: Re: fringe bugs and issues (and a couple display margin bugs)
Date: 22 Jan 2002 15:07:52 -0800
Organization: The Vegetable Liberation Front
Message-ID: < 87ofjmass7.fsf@radish.petrofsky.org>
Sender: a...@radish.petrofsky.org
References: < 200201212111.NAA00419@radish.petrofsky.org>
< 200201220814.g0M8EVb15077@aztec.santafe.edu>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: news...@supernews.com
Approved: bug-gnu-em...@mail.gnu.org
Newsgroups: gnu.emacs.bug
Lines: 57
Xref: archiver1.google.com gnu.emacs.bug:4674
r...@gnu.org (Richard Stallman) writes:
>
> 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.
>
> This must be a misunderstanding, because Emacs has never done this.
By "fringe", I meant the column containing continuation marks. Since
at least version 18, emacs has put the cursor in that column if you
are at the end of a line whose display width is equal to the width of
the rest of the window. The line is not continued. This is a special
case: for other line lengths, shorter or longer, the cursor is not
placed in the continuation mark column for any of the line's buffer
postions. The benefit of this feature was that emacs never wasted a
whole row to display an empty continuation line, as emacs 21 X frames
do.
Eli wrote:
> > * Fringes on wrong side of display margins.
> > Fringes should be inside display margins, shouldn't they?
>
> I'm not sure. Please tell why do you think so.
Because truncation marks should be adjacent to what is truncated.
Consider:
foo$nternationaliza$bar
$foonternationalizabar$
Which makes more sense to you? (Please pretend that the "$"s are
little bitmaps, since I seem to be the only one who thinks that's
irrelevant to choosing the desired layout :-).)
> > 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.
>
> That's because tty's don't support fringes at all. If you refer to
> the places where continuation and truncation glyphs are displayed as
> the fringe, then the behavior is inconsistent. But that's not how
> Emacs refers to that.
Emacs is living in denial if she thinks that makes it better. Forget
I used the word "fringe". If some frames put truncation marks on the
inside of the display margins, and other frames put them on the
outside, then that is inconsistent behavior.
I understand that the implementation is such that enhancing it to
behave consistently will be difficult, and that you don't consider it
worthwhile. And, unfortunately, I'm not volunteering to do it myself.
I'm just calling the bugs as I see 'em, for the consideration of
anyone who might work on this.
-al
x-uunet-gateway: mr1.ash.ops.us.uu.net from bug-gnu-emacs to
gnu.emacs.bug; Tue, 22 Jan 2002 23:26:30 GMT
X-Authentication-Warning: sykes.suse.de: schwab set sender to
sch...@suse.de using -f
Subject: Re: fringe bugs and issues (and a couple display margin bugs)
References: <200201212111.NAA00419@radish.petrofsky.org>
<200201220814.g0M8EVb15077@aztec.santafe.edu>
<87ofjmass7.fsf@radish.petrofsky.org>
X-Yow: How's it going in those MODULAR LOVE UNITS??
From: sch...@suse.de (Andreas Schwab)
Date: Wed, 23 Jan 2002 00:26:15 +0100
Message-ID: <jeelki2ciw.fsf@sykes.suse.de>
User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.2.50 (ia64-suse-linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
Approved: bug-gnu-em...@mail.gnu.org
Newsgroups: gnu.emacs.bug
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
newsfeeds.belnet.be!news.belnet.be!newsfeed00.sul.t-online.de!
t-online.de!newsfeed.wirehub.nl!news2.euro.net!uunet!ash.uu.net!
spool0901.news.uu.net!wendy-fate.uu.net!bug-gnu-emacs
Sender: bug-gnu-em...@mail.gnu.org
Lines: 29
Xref: archiver1.google.com gnu.emacs.bug:4675
Alveola Petrofsky < alv...@petrofsky.org> writes:
|> r...@gnu.org (Richard Stallman) writes:
|> >=20
|> > 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.
|> >=20
|> > This must be a misunderstanding, because Emacs has never done this.
|>=20
|> By "fringe", I meant the column containing continuation marks. Since
|> at least version 18, emacs has put the cursor in that column if you
|> are at the end of a line whose display width is equal to the width of
|> the rest of the window. The line is not continued. This is a special
|> case: for other line lengths, shorter or longer, the cursor is not
|> placed in the continuation mark column for any of the line's buffer
|> postions.
It's the same on X, except that now we have the fringes, no
continuation/truncation marker is put in the last column of the text area
any more.
Andreas.
--=20
Andreas Schwab, SuSE Labs, sch...@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 N=FCrnberg
Key fingerprint =3D 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
x-uunet-gateway: chi6sosrv11.alter.net from bug-gnu-emacs to
gnu.emacs.bug; Tue, 22 Jan 2002 23:52:00 GMT
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
newsfeeds.belnet.be!news.belnet.be!newsfeed.online.be!zur.uu.net!
ash.uu.net!spool0901.news.uu.net!wendy-fate.uu.net!
corp.supernews.com!not-for-mail
From: alv...@petrofsky.org (Alveola Petrofsky)
Subject: Re: fringe bugs and issues (and a couple display margin bugs)
Date: 22 Jan 2002 15:51:55 -0800
Organization: The Vegetable Liberation Front
Message-ID: <87hepeaqqs.fsf@radish.petrofsky.org>
Sender: a...@radish.petrofsky.org
References: <200201212111.NAA00419@radish.petrofsky.org>
<200201220814.g0M8EVb15077@aztec.santafe.edu>
<87ofjmass7.fsf@radish.petrofsky.org>
<jeelki2ciw.fsf@sykes.suse.de>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: news...@supernews.com
Approved: bug-gnu-em...@mail.gnu.org
Newsgroups: gnu.emacs.bug
Lines: 31
Xref: archiver1.google.com gnu.emacs.bug:4676
sch...@suse.de (Andreas Schwab) writes:
> Alveola Petrofsky <alv...@petrofsky.org> writes:
>
> |> at least version 18, emacs has put the cursor in that column if you
> |> are at the end of a line whose display width is equal to the width of
> |> the rest of the window. The line is not continued. This is a special
> |> case: for other line lengths, shorter or longer, the cursor is not
> |> placed in the continuation mark column for any of the line's buffer
> |> postions.
>
> It's the same on X, except that now we have the fringes, no
> continuation/truncation marker is put in the last column of the text
> area any more.
Try this:
emacs-21 -q
M-80 x RET M-80 x RET
I now see two rows of screen space wasted on empty continuation lines.
I don't believe emacs-20 ever displayed empty continuation lines.
These rows do not display any text. They are being used solely to
have a place to put the cursor when point is at the end of the line.
They wouldn't be wasted if emacs-21 were able to put the cursor in the
same horizontal location that it puts continuation marks. All
previous versions of emacs were able to put the cursor in the same
horizontal location that they put continuation marks.
-al