I have to admit that I'm a bit skeptical about whether such a technique
actually works, and so, I thought I would pose some questions to you.
Firstly, how many of you using Acme for programming on a daily basis remap
your fonts so that the fixed width font is the main one that you use?
Secondly, if you do use proportional width fonts, why, and what troubles
did you encounter; what benefits did you encounter?
Thirdly, would you continue using proportional width fonts in cases like
Lisp code, where you very often see something like the following
indentation scheme, and how would you resolve these indentation problems
with proportional width fonts if you did continue to use them?
(let ([foo bar]
[something else])
(some-func (called again)
(with fun indentation)
(and yet)
(another)))
Thanks!
Aaron W. Hsu
--
Of all tyrannies, a tyranny sincerely exercised for the good of its
victims may be the most oppressive. -- C. S. Lewis
> Secondly, if you do use proportional width fonts, why, and what
> troubles did you encounter; what benefits did you encounter?
You can't very well engage in weird formatting tricks, but I'm not much
a fan of those anyway. IMO, the more attractive letters and generally
lesser character width more than make up for the inability to precisely
align columns that don't contain whitespace. I just use tabs to give
myself a semantic clue.
> Thirdly, would you continue using proportional width fonts in cases
> like Lisp code, where you very often see something like the following
> indentation scheme,
No. Lisp indentation is hairy enough that I'd rather have the editor do
it anyway (I'll take a structure editor too, if you please), so Acme is
right out. Lisp code is so structurally complex that the indentation
scheme I use in C doesn't work so well. I really want arguments to a
function to begin at the same column, and for macro bodies to be
indented by two characters precisely, so I don't get hopelessly lost. I
just go on back to Emacs for Lisp coding.
> and how would you resolve these indentation problems with proportional
> width fonts if you did continue to use them?
I'd make leading spaces inherit their width from the characters above.
(let ((foo bar)
(something else))
(some-func (called again)
(with fun indentation)
(and yet)
(another)))
So in this example, the first space on line two would have the width of
"(", the second the width of an "l", and so on. But the space in
"something else" uses whatever width is defined in the font, since
spacing would get weird otherwise.
You couldn't do
(let ((foo bar)
(something else))
...)
and expect proper alignment, but like I said, I don't like that trick
anyway.
i use proportional fonts in acme for programming.
> Secondly, if you do use proportional width fonts, why, and what troubles did
> you encounter; what benefits did you encounter?
i use them because they're more readable, and i get more
characters per line than in a similarly sized fixed-width font.
in C-like syntax, everything works just fine; a single
tab character is ideal for indentation.
use of tabs other than at the start of a line won't
guarantee alignment with other fonts, but this rarely matters
too much.
in LISP, i sometimes ended up using a fixed-width font,
due to the convention of aligning a subform with part
of its parent, as you point out. variable-width fonts can
work ok in lisp, although the indentation tends to
end up slightly non-standard (although still passable).
in haskell, i used proportional spacing with single-tab
indentation, and it worked just fine apart from, AFAIR,
multiple assignments for a single let - i just always
used let...in.
> Thirdly, would you continue using proportional width fonts in cases like
> Lisp code, where you very often see something like the following indentation
> scheme, and how would you resolve these indentation problems with
> proportional width fonts if you did continue to use them?
>
> (let ([foo bar]
> [something else])
> (some-func (called again)
> (with fun indentation)
> (and yet)
> (another)))
i presume you meant this:
(let ([foo bar]
[something else])
(some-func (called again)
(with fun indentation)
(and yet)
(another)))
using a varwidth font, i'd format this as:
(let ([foo bar]
[something else])
(some-func
(called again)
(with fun indentation)
(and yet)
(another)))
(note 4-space indent, not 2-space indent
for the some-func arguments. not perfect, but ok, i reckon)
i found unlike macros, functions rarely need multiline continuation,
but i think the case is arguable. as i said, i've done it both ways.
PS. i'd really like to see an acme-integrated lisp environment. one of
these years
i'll get around to it...
I always use tabs not spaces for indenting
I don't remember it ever being a problem, certainly not one unsolved by
clicking on Font
So, I was browsing around the other day looking at Acme resources, and I discovered an old post from 1995 wherein someone advocated the use of proportional fonts for programming in Acme.
> So, I was browsing around the other day looking at Acme resources, and I
> discovered an old post from 1995 wherein someone advocated the use of
> proportional fonts for programming in Acme. This surprised me, to say the
> least. He even went as far as to mention that SML was the language they
> were using, and had managed to get a decent indenting pattern for it that
> was just as readable, without messing things up for proportional font
> users.
>
> I have to admit that I'm a bit skeptical about whether such a technique
> actually works, and so, I thought I would pose some questions to you.
>
> Firstly, how many of you using Acme for programming on a daily basis remap
> your fonts so that the fixed width font is the main one that you use?
>
> Secondly, if you do use proportional width fonts, why, and what troubles
> did you encounter; what benefits did you encounter?
I don't program on a daily basis, but using a proportional font in rio
I'm finding it so much easier on the eyes that I hold back from opening
xterms and from switching acme windows into the fixed-width font.
>
> Thirdly, would you continue using proportional width fonts in cases like
> Lisp code, where you very often see something like the following
> indentation scheme, and how would you resolve these indentation problems
> with proportional width fonts if you did continue to use them?
>
> (let ([foo bar]
> [something else])
> (some-func (called again)
> (with fun indentation)
> (and yet)
> (another)))
This particular form of indentation is the only thing I'd be worried
about, and where a great deal of nesting is not required it's never
strictly necessary. In a certain scripting environment with a C-like
syntax and a very weak editor I got into the habit of treating parentheses
as block structure when the parameter list is long:
llSetPrimitiveParams([
PRIM_TYPE, PRIM_TYPE_CYLINDER, 0,
<open_cut_start, open_cut_end, 0>, hollow,
<0, 0, 0>, <1, 1, 0>, <0, 0, 0>
]);
That's not a practical style in Lisp, of course. I've thought about
this in the past as I was never entirely comfortable with some very
common indenting styles. Gnu style has 2-character indents, that's not
an indent, it's natural roughness! The Linux kernel style on the other
hand has full tabs. 8-character tabs break things up a little too much
for my eyes so I set my editor to have narrower tabs when loading code
from the kernel tree. This worked great so long as no code had a special
indent (as Aaron's Lisp code above) nor was aligned after the indent
(e.g. comments on the same line as code). This eventually led me to
consider an editor which dynamically managed indents, displaying the
code quite differently to the fixed indents in the source file. Such an
editor could work well with proportional fonts and s-expressions together,
but I can't work out whether it would be 'too clever' - i.e. irritating.
--
Ethan Grammatikidis
Those who are slower at parsing information must
necessarily be faster at problem-solving.
> So, I was browsing around the other day looking at Acme resources,
> and I discovered an old post from 1995 wherein someone advocated the
> use of proportional fonts for programming in Acme. This surprised
> me, to say the least. He even went as far as to mention that SML was
> the language they were using, and had managed to get a decent
> indenting pattern for it that was just as readable, without messing
> things up for proportional font users.
>
> I have to admit that I'm a bit skeptical about whether such a
> technique actually works, and so, I thought I would pose some
> questions to you.
Bjarne Stroustrup actually advocates this style in "The C++
Programming Language."
This discussion reminds me of this elastic tab stops concept:
http://nickgravgaard.com/elastictabstops/
I don't think it made it into any editors, but it would support the
kind of fancy alignment I like to have in my code while also
supporting real fonts, which I would prefer to use.
> Thirdly, would you continue using proportional width fonts in cases
> like Lisp code, where you very often see something like the
> following indentation scheme, and how would you resolve these
> indentation problems with proportional width fonts if you did
> continue to use them?
>
> (let ([foo bar]
> [something else])
> (some-func (called again)
> (with fun indentation)
> (and yet)
> (another)))
I bet you could set up Emacs to use a proportional font. It can do
anything, right? :)
I'd love it if Acme or Plan 9 had good support for some kind of Lisp
variant.
—
Daniel Lyons
—
Daniel Lyons
it took me at least 5 seconds to realize that abaco was formatting
that page correctly. ☺
the key to the joke, however, is there is a vast difference between
leading indentation and stuff like
if(x == 1 &&
y == 2)
which just doesn't work well with proportional fonts.
i guess this email is an excercize in making presotto unfunny
in 3 easy steps.
- erik
Speaking of which (or may be not ;-)) is there anybody using Lua
on Plan9?
Thanks,
Roman.
P.S. The more I look into Lua (as a way to help C refuge start
doing some functional stuff) the more it seems that the two have
a lot in common when it comes to software architecture.
> I'd love it if Acme or Plan 9 had good support for some kind of Lisp
> variant.
Maybe that should be my next side project.
BTW I have found a difference between Linux and Plan9 version:
- Linux version can handle "dividing by 0" without crash of Lua
interpretter,
- Plan9 version cannot. ;-)
Pavel
> On Thu, 13 Aug 2009 13:58:39 -0400, Daniel Lyons <fus...@storytotell.org
> > wrote:
>
>> I'd love it if Acme or Plan 9 had good support for some kind of
>> Lisp variant.
>
> Maybe that should be my next side project.
If that's something you're thinking about doing, let me suggest you
take a look at Clojure. The Java aspect aside, it is a good compromise
in design between Scheme and Lisp and introduces lots of good ideas.
This is something I would want to do but I have a long way to go with
Plan 9 before I think I could be serious about it.
—
Daniel Lyons
> Last time I tried, the standard Lua compiled out of the box under the
> APE.
That is good to know. Still, I'd rather see it run without APE.
> Great little language. I use it in my day job (together with Erlang).
*together* with Erlang?!?! That I have to know more about. Perhaps
off-list.
> It's implementation is indeed just as enlightening as the Plan 9
> code. An exercise in doing exactly what is required and no more. Very
> elegant in my eyes.
Couldn't agree more!
Thanks,
Roman.
What do you use it for? Any kind of fun projects? My idea is to try
and see whether Plan9+Lua would be a more useful combination for
building Web service environment than werc.
Thanks,
Roman.
I looked at it for a while and came with a realization that it could
be just a tad heavier than what I need for most of the stuff I do. Plus
I'm not sure how to port it to Plan9 without first porting the JVM.
Thanks,
Roman.
Kenji has written a webdav server for pegasus (Kenji's httpd branch)
using lua.
Just fetched the tarball for lua-5.1.4, changed the CC=gcc to CC=cc
and tried "make posix". After lots of complaining about the -O2
option, I see:
/usr/john/lua-5.1.4/src/liolib.c:178[stdin:2686] incompatible types:
"IND STRUCT _1_" and "INT" for op "AS"
I'm going to poke around and look into things, also try compiling with
different targets ("make linux" etc.), but can I get a description of
exactly how you compiled it, Robert?
John
--
"Object-oriented design is the roman numerals of computing" -- Rob Pike
Kenji has written a webdav server for pegasus (Kenji's httpd branch)
using lua.
make ansi
-Josh
Yeah, I'm kinda dumb... I tried make generic and make ansi without
doing a make clean (after trying a make posix) so I had some old crap
lying around.
Thanks
See also my post: http://ninetimes.cat-v.org/news/2009/07/19/0/
and the included link to setting it up on Plan 9.
Best,
ak
how could I possibly miss that
ak
P.S.: This isn't Acme's fault - it's the same trouble
in the font I'm using to type this message - in
GMail in Firefox.
I actually meant to create a new Plan 9-specific Lisp variant, perhaps
stealing some of Clojure's new ideas. Especially with respect to
parallelism, the standard library and a few other things. I like that
I can call into Java libs from Clojure but that's not the most
interesting thing about it to me.
Another thing which would be cool would be something like scsh.
--
Daniel Lyons
> Speaking of fonts in Acme, using the default,
> I spent extra amount of time tracking down
> a bug in my gs(1) source, which was the mix-up
> between -lijs and -Iijs. Apparently 'I' is shorter
> than 'l' by some portion of a pixel.
I use Times in Acme. That distinguishes things pretty well.
> If that's something you're thinking about doing, let me suggest you take
> a look at Clojure. The Java aspect aside, it is a good compromise in
> design between Scheme and Lisp and introduces lots of good ideas. This
> is something I would want to do but I have a long way to go with Plan 9
> before I think I could be serious about it.
Sorry, I'm a Scheme programmer, and Clojure does not appeal to me in
enough aspects (very few, actually) to make me even learn how to use it.
Rather, I think a very small number of simple conveniences would suffice
to make Scheme programming very convenient with Acme. Already, most of the
necessary features are there, and I am using Acme pleasantly right now in
my daily Scheme work.
> For Lisp variants ask Alex Shinn(alex...@gmail.com), he's got an
> interesting scheme implementation mostly working. It's a summer of
> code project this year.
Indeed, there are a number of fairly portable Scheme implementations that
I could see working with Plan 9.