2:57 p.m.
Martin Buchholz <martin(a)xemacs.org> writes:
>>>>> "cgw" == Charles G Waldman
<cgw(a)fnal.gov> writes:
cgw> How can I tell, without looking ahead to the next line, that that "d"
cgw> is subject to columnar alignment? I'm hoping somebody comes up with an
cgw> absolutely brilliant suggestion here... in the meanwhile I'll keep on
cgw> tinkering.
You have to be able to backtrack. When you read the next line, with its
two spaces, you know you might have to go back and align previous line(s)
as well. Single pass won't work. It'll be expensive. But computers are
fast.
That's what the new dual processor G4s are good for. :) We should optimize
the redisplay calculations with those fancy 128-bit instructions. I agree
that most computers are fast enough to deal with something like this now,
but we should always permit a way to turn it off.
We also have to make sure only to do this in source code and not in
text mode.
I disagree - there are plenty of instances where I want things to align in
text mode. Granted, I do write most of my documentation on HTML now, but
having nicely aligned tables of figures in email or plain text files can be
very useful. :)
-Bill P.
5:27 p.m.
New subject: an experiment with proportional-width fonts
William M. Perry writes:
there are plenty of instances where I want things to align in
text mode. Granted, I do write most of my documentation on HTML now, but
having nicely aligned tables of figures in email or plain text files can be
very useful. :)
I agree. My current (hack) implementation of alignment uses some
buffer-local variables to control the behavior, so that it's
independent of mode. I could also imagine implementing this as a
minor mode, `align-columns-mode' or something like that, so the user
could switch it on and off, rather than having redisplay itself making
decisions like "use alignment in C-mode but not text-mode". And there
would still have to be some variable controlling the aggressiveness of
the alignment (e.g. whether to use backtracking or not...)
7:51 a.m.
New subject: an experiment with proportional-width fonts
>>>> "WMP" == William M Perry
<wmperry(a)aventail.com> writes:
> We also have to make sure only to do this in source code and not
in
> text mode.
WMP> I disagree - there are plenty of instances where I want things to align in
WMP> text mode. Granted, I do write most of my documentation on HTML now, but
WMP> having nicely aligned tables of figures in email or plain text files can be
WMP> very useful. :)
Hmmm. XEmacs would have to VERY smart to do this right. <== like
ignore those two spaces at the beginning of this non-sentence.
9:38 a.m.
New subject: an experiment with proportional-width fonts
>>>> "mb" == Martin Buchholz
<martin(a)xemacs.org> writes:
mb> Hmmm. XEmacs would have to VERY smart to do this right. <==
mb> like ignore those two spaces at the beginning of this
mb> non-sentence.
Getting columnation right in all cases is simply not possible.
Without real AI, anyway. Simply take any example, duplicate it, and
insert the semantic equivalent of "Here is what a sample text looks
like properly columnated with proportional fonts:" before one of the
segments and "Here is how terrible a sample text looks with
proportional fonts but without columnation:" before the other. You
simply won't be able to handle all such texts with regexps!
I think 100% is simply unnecessary. Everything that is true of
proportional fonts is true of code colorization, and we should treat
it the same way as we do font-lock. It may be a little harder to
implement for proportional fonts. Eg, it absolutely must involve
arbitrary[1] amounts of backtracking since `mmmm' for most fonts will
be much wider than `iiii', yet there is no guarantee that the former
will occur before the latter in a columnated list, or how far apart
they will be, a non-backtracking implementation is hosed. Nor can you
even use a heuristic like "space is always intermediate in width
between `i' and `m'." But probably font-lock will take you some ways
in creating a framework for a "column-lock" package that can be
flexibly configured to columnate various kinds of text acceptably
well.
Anyway, well-chosen screen shots will surely excite much envy from
those trying to implement "word processors" on top of an Emacs editor.
;-)
Footnotes:
[1] Well, you could restrict the amount of backtracking to a window-
full if you're willing to have columns bouncing back and forth on
every scroll.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
11:09 p.m.
New subject: an experiment with proportional-width fonts
Maybe I'm Missing The Point but Charles' approach seems wrongheaded to
me. If I understand correctly Charles' approach is to work out at
redisplay time which characters in a buffer need to be aligned with
which other characters so that tabular data is displayed correctly. This
is tricky and likely to be expensive.
But isn't this exactly the problem that tabs are meant to solve? The
package list example looks so bad with a proportional font because
spaces are used instead of tabs. There's no reason that tabs couldn't be
used instead. And frankly I don't think that the "int i; double d"
problem is worth solving.
Stephen J. Turnbull wrote:
[snip]
Eg, it absolutely must involve
arbitrary[1] amounts of backtracking since `mmmm' for most fonts will
be much wider than `iiii', yet there is no guarantee that the former
will occur before the latter in a columnated list, or how far apart
they will be, a non-backtracking implementation is hosed.
No-one else tries to solve the `mmmm' problem (actually I think that
'W's are usually considered the widest letter?). In word processors the
user sets tab stops in inches and it's up to the user to make sure that
the tab stops are wide enough to accommodate the data. I don't see why
we should try to do more. We don't have the concept of inches but
setting tabs in multiples of average character widths would work just as
well.
Jonathan.
--
Jonathan Harris | jhar(a)tardis.ed.ac.uk
London, England | Jonathan.Harris(a)symbian.com
12:16 a.m.
New subject: an experiment with proportional-width fonts
Jonathan Harris writes:
Maybe I'm Missing The Point but Charles' approach seems
wrongheaded to
me.
Why, thank you for the compliment! That's the nicest thing anybody's
said to me all day! ;-)
If I understand correctly Charles' approach is to work out at
redisplay time which characters in a buffer need to be aligned with
which other characters so that tabular data is displayed correctly. This
is tricky and likely to be expensive.
Maybe it's a little tricky but my current one-pass implementation is
not expensive at all. And, you can always turn it off.
If I put in the backtracking that Martin suggests, then it will get a lot
more expensive. But, as Martin also points out, "computers are
fast". I've got cycles to burn... hell, I've even toyed with the idea
of antialiasing...
But isn't this exactly the problem that tabs are meant to solve?
The
package list example looks so bad with a proportional font because
spaces are used instead of tabs. There's no reason that tabs couldn't be
used instead.
How about the calendar example? Hmm, I guess you could set a
tab-width of 3 and use tabs instead of spaces.
But I think it would be a huge amount of work to change all the
packages to use tabs instead of spaces. The problem is widespread; it
affects GNUS and VM and dired and efs and pcl-cvs and ...
Suppose I change all these packages to use tabstops instead of spaces
for alignment. Having done so, I would have a nice-looking package
list and nice-looking calendar, but when I go to edit some arbitrary
file that uses spaces for indentation I don't get aligned text. Or,
if I'm viewing man pages. Or using W3 to view some <pre> text that's
supposed to be aligned. And how about when I'm in my *shell* buffer
and type "ls" ?
Taking care of the alignment inside of redisplay is a *universal*
solution, rather than changing 10,000 individual .el files.
And frankly I don't think that the "int i; double
d"
problem is worth solving.
I'm on the fence about this one. I may not think it's quite as
important as Martin does, but it *would* be nice. I don't like the
idea of introducing backtracking, though.
No-one else tries to solve the `mmmm' problem (actually I think
that
'W's are usually considered the widest letter?).
So you would call it the `WWW' problem? (Sorry, couldn't resist).
In word processors the user sets tab stops in inches and it's up
to
the user to make sure that the tab stops are wide enough to
accommodate the data. I don't see why we should try to do more.
I thought XEmacs was all about "doing more" !
1:38 a.m.
New subject: an experiment with proportional-width fonts
charles, i agree with you that your approach is good. i think a good solution
would be to use cooperation between redisplay and individual modes -- e.g.
create an extent property called `align-spaces' that can be put on text. this
should be settable either way -- force alignment or force non-alignment. you
could, for example, have code in C mode that scanned for what appeared to be
successive lines with aligned declarations on them, and put the `align-spaces'
property on the text.
Charles G Waldman wrote:
Jonathan Harris writes:
> Maybe I'm Missing The Point but Charles' approach seems wrongheaded to
> me.
Why, thank you for the compliment! That's the nicest thing anybody's
said to me all day! ;-)
> If I understand correctly Charles' approach is to work out at
> redisplay time which characters in a buffer need to be aligned with
> which other characters so that tabular data is displayed correctly. This
> is tricky and likely to be expensive.
Maybe it's a little tricky but my current one-pass implementation is
not expensive at all. And, you can always turn it off.
If I put in the backtracking that Martin suggests, then it will get a lot
more expensive. But, as Martin also points out, "computers are
fast". I've got cycles to burn... hell, I've even toyed with the idea
of antialiasing...
> But isn't this exactly the problem that tabs are meant to solve? The
> package list example looks so bad with a proportional font because
> spaces are used instead of tabs. There's no reason that tabs couldn't be
> used instead.
How about the calendar example? Hmm, I guess you could set a
tab-width of 3 and use tabs instead of spaces.
But I think it would be a huge amount of work to change all the
packages to use tabs instead of spaces. The problem is widespread; it
affects GNUS and VM and dired and efs and pcl-cvs and ...
Suppose I change all these packages to use tabstops instead of spaces
for alignment. Having done so, I would have a nice-looking package
list and nice-looking calendar, but when I go to edit some arbitrary
file that uses spaces for indentation I don't get aligned text. Or,
if I'm viewing man pages. Or using W3 to view some <pre> text that's
supposed to be aligned. And how about when I'm in my *shell* buffer
and type "ls" ?
Taking care of the alignment inside of redisplay is a *universal*
solution, rather than changing 10,000 individual .el files.
> And frankly I don't think that the "int i; double d"
> problem is worth solving.
I'm on the fence about this one. I may not think it's quite as
important as Martin does, but it *would* be nice. I don't like the
idea of introducing backtracking, though.
> No-one else tries to solve the `mmmm' problem (actually I think that
> 'W's are usually considered the widest letter?).
So you would call it the `WWW' problem? (Sorry, couldn't resist).
> In word processors the user sets tab stops in inches and it's up to
> the user to make sure that the tab stops are wide enough to
> accommodate the data. I don't see why we should try to do more.
I thought XEmacs was all about "doing more" !
--
Ben
In order to save my hands, I am cutting back on my mail. I also write
as succinctly as possible -- please don't be offended. If you send me
mail, you _will_ get a response, but please be patient, especially for
XEmacs-related mail. If you need an immediate response and it is not
apparent in your message, please say so. Thanks for your understanding.
See also http://www.666.com/ben/chronic-pain/
3:40 a.m.
New subject: an experiment with proportional-width fonts
>>>> "cgw" == Charles G Waldman
<cgw(a)fnal.gov> writes:
cgw> I thought XEmacs was all about "doing more" !
Hear, hear!
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
9:05 a.m.
New subject: an experiment with proportional-width fonts
At 11:09 PM 8/7/00 +0100, Jonathan Harris wrote:
Maybe I'm Missing The Point but Charles' approach seems
wrongheaded to
me. If I understand correctly Charles' approach is to work out at
redisplay time which characters in a buffer need to be aligned with
which other characters so that tabular data is displayed correctly. This
is tricky and likely to be expensive.
But isn't this exactly the problem that tabs are meant to solve? The
package list example looks so bad with a proportional font because
spaces are used instead of tabs. There's no reason that tabs couldn't be
used instead. And frankly I don't think that the "int i; double d"
problem is worth solving.
This has been on my list of redisplay fixes for ages. I am unlikely to get
to it in this lifetime though.
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
11:15 a.m.
New subject: an experiment with proportional-width fonts
Martin Buchholz <martin(a)xemacs.org> writes:
>> We also have to make sure only to do this in source code and
not in
>> text mode.
WMP> I disagree - there are plenty of instances where I want things to align in
WMP> text mode. Granted, I do write most of my documentation on HTML now, but
WMP> having nicely aligned tables of figures in email or plain text files can be
WMP> very useful. :)
Hmmm. XEmacs would have to VERY smart to do this right. <== like
ignore those two spaces at the beginning of this non-sentence.
Why don't have mode-specific functions for this?
C-mode knows perfectly well that it's likely that there should be
alignment between types and variable names, text-mode knows that there
shouldn't be alignmnent for "[a-z]\. [a-z]". Etc.
A function that tries to Do The Right Thing everywhere won't DTRT
anywhere.
Improvements on the font situation would be real nice, the defaults on
my redhat linux box are very ugly. (Like, italic faces use much larger
fonts than other faces.)
1:32 a.m.
New subject: an experiment with proportional-width fonts
>>>> "Simon" == Simon Josefsson
<simon(a)josefsson.org> writes:
Simon> Improvements on the font situation would be real nice, the
Simon> defaults on my redhat linux box are very ugly. (Like,
Simon> italic faces use much larger fonts than other faces.)
This can often be fixed by using either point-size specifications or
by eliminating one or the other of /usr/X11R6/lib/fonts/{75,100}dpi
from the fontpath.
However, the problem here may be in your Linux distribution. Many
Linux distros have fonts.alias files aliasing from 75dpi to 100dpi or
vice versa, even using symlinks. I first saw the bug on a Red Hat
Linux system, but it has since propagated to other Linux distros and
perhaps upstream to XFree86. This makes point-size specs (used by
XEmacs Customize) inappropriate. Debian (woody) doesn't seem to do
this any more, but I don't know if they have gotten appropriate BDFs
for all those formerly aliased fonts or rasterized them from outline
fonts or what.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
9:09 a.m.
New subject: an experiment with proportional-width fonts
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
Simon> Improvements on the font situation would be real nice,
the
Simon> defaults on my redhat linux box are very ugly. (Like,
Simon> italic faces use much larger fonts than other faces.)
This can often be fixed by using either point-size specifications or
by eliminating one or the other of /usr/X11R6/lib/fonts/{75,100}dpi
from the fontpath.
Removing 100dpi solved the problem for me. (... in XEmacs. Dunno
what will happen to netscape and other font intensive programs.)
Thanks.
However, the problem here may be in your Linux distribution. Many
Linux distros have fonts.alias files aliasing from 75dpi to 100dpi or
vice versa, even using symlinks.
Couldn't find that on my system, so I guess redhat fixed this (version
6.2 here).
9:18 a.m.
New subject: an experiment with proportional-width fonts
William M. Perry writes:
having nicely aligned tables of figures in email or plain text
files can be very useful. :)
;;; align --- align text to a specific column, by regexp
;; Copyright (C) 1999 John Wiegley
;; Author: John Wiegley <johnw(a)gnu.org>
;; Created: 21 Mar 1996
;; Version: 2.61
;; Keywords: convenience languages lisp
;; X-URL: http://oneworld.new-era.com/johnw/emacs.html
10:09 a.m.
New subject: an experiment with proportional-width fonts
giacomo boffi writes:
William M. Perry writes:
> having nicely aligned tables of figures in email or plain text
> files can be very useful. :)
>
;;; align --- align text to a specific column, by regexp
uh, were we talking about _proportional_ fonts?
5:27 p.m.
New subject: an experiment with proportional-width fonts
giacomo boffi writes:
uh, were we talking about _proportional_ fonts?
Yes, check the subject line of the message, and my original message.
Screenshots and discussion are (still) at
http://home.fnal.gov/~cgw/xemacs/experiment
8872
days inactive
8875
days old
14 comments
9 participants
participants (9)
-
Andy Piper -
Ben Wing -
Charles G Waldman -
Giacomo Boffi -
Jonathan Harris -
Martin Buchholz -
Simon Josefsson -
Stephen J. Turnbull -
William M. Perry