[9fans] Why does Acme only show text?

[9fans] Why does Acme only show text?

[Jason Catena]

I've been wondering for years now why Acme (and Wily, which I used
first) only display text files.

It seems to me that the content of an Acme window could be anything: a
picture, a postscript or PDF file, a star chart, a web page.  Keeping
with the spirit of small parts brought together, Acme could outsource
the displaying of the content to another program, place its output in
the Acme window, and operate on it by sending commands from the tag to
the rendering program.  Browsers do this (except the tag-command part)
with PDF for example, displaying a PDF file within an embedded viewer
(usually Acrobat).  Looking through the Oberon document, I see that
its Acme-like interface uses exactly this kind of embedded-viewer
architecture, and commands in the tag suitable to the object viewed.

I know Oberon came first, so my question is, is there an architectural
or design reason the plumber invokes programs completely outside Acme
to view and control files other than text?  Is the embedded capture
and control a planned feature or enhancement that was just never added
to Acme yet?  Is it considered too much work or too complicated to
implement for the benefit of a more integrated interface?  Or is any
format other than text considered a red-headed stepchild to be
delegated to other programs in the few cases where it must be used?

Jason Catena

Re: [9fans] Why does Acme only show text?

[Rob Pike]

I always intended to do something about that but never got around to
it. Other things took precedence.

In any case I doubt it could ever work as well in Acme as it does in Oberon.

-rob

Re: [9fans] Why does Acme only show text?

[David Leimbach]

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

On Tue, Jul 14, 2009 at 9:36 PM, Rob Pike <robpike@gmail.com> wrote:

> I always intended to do something about that but never got around to
> it. Other things took precedence.
>
> In any case I doubt it could ever work as well in Acme as it does in
> Oberon.
>
> -rob
>

Rio works nicely though, and thanks for that! :-)

[-- Attachment #2: Type: text/html, Size: 625 bytes --]

Re: [9fans] Why does Acme only show text?

[Charles Forsyth]

Oberon takes advantage of a structured text representation
where both the interpretation and graphic representation
of particular elements is provided by Oberon modules.
One demonstration had a little animated cartoon character
that could be cut and pasted into another frame, where it
continued to move.

Acme exploits one chunk of identical text being the same as
any other, given particular meaning by the
button used to select it and its frame or tag context
(the context including a program sitting behind the frame).

It's probably relatively easy to give over Acme frames to a
program that draws, but is there a good way of providing
something more than that, giving more of the
`structural support' that Acme provides to text-oriented
applications? Is it time to consider a possible role for structured text
along Oberon lines?

One of the reasons for porting Acme to Inferno originally
was to try to explore those things in a slightly more
flexible environment, but it didn't happen, partly for lack of time.

Re: [9fans] Why does Acme only show text?

[cej]

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


Maybe, it would also be great if the column-handle could react in the same way as the window-handle works:
B3 to hide all other columns, B2 to show all and maximize the current column, B1 widen the current column.
I don't know whether it is even possible in current design, nor, if it is, how complicated the coding of these features would be.
Just an idea. I suspect also that it was already mentioned on 9fans.

Greetings,

++pac.

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2630 bytes --]

Re: [9fans] Why does Acme only show text?

[mattmobile]

cej@gli.cas.cz wrote:
> Maybe, it would also be great if the column-handle could react in the same way as the window-handle works:
> B3 to hide all other columns, B2 to show all and maximize the current column, B1 widen the current column.
> I don't know whether it is even possible in current design, nor, if it is, how complicated the coding of these features would be.
> Just an idea. I suspect also that it was already mentioned on 9fans.
>

I would like that too, it always disappoints me when I right click the
column box expecting it to expand :)

Re: [9fans] Why does Acme only show text?

[michael block]

On Thu, Jul 16, 2009 at 04:58, <cej@gli.cas.cz> wrote:
>
> Maybe, it would also be great if the column-handle could react in the same way as the window-handle works:
> B3 to hide all other columns, B2 to show all and maximize the current column, B1 widen the current column.

wily does this

Re: [9fans] Why does Acme only show text?

[cej]

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



>
> > Maybe, it would also be great if the column-handle could react in the same way as the window-handle works:
> > B3 to hide all other columns, B2 to show all and maximize the current column, B1 widen the current column.

> wily does this


ufff, so could sb put his/her hands on it to bring this functionality back to native Acme?
Thanks, regards,

++pac.

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2726 bytes --]

Re: [9fans] Why does Acme only show text?

[Paul Donnelly]

jason.catena@gmail.com (Jason Catena) writes:

> I've been wondering for years now why Acme (and Wily, which I used
> first) only display text files.
>
> It seems to me that the content of an Acme window could be anything: a
> picture, a postscript or PDF file, a star chart, a web page.  Keeping
> with the spirit of small parts brought together, Acme could outsource
> the displaying of the content to another program, place its output in
> the Acme window, and operate on it by sending commands from the tag to
> the rendering program.

Hi, I don't know anything about anything, but it seems to me that it's
more productive to look at the question the other way around: why not
modify Rio to tile windows like Acme does? Acme is a text editor, so
it's no surprise that it handles text only. If you want tiled windows
you can display arbitrary graphics in... well, there's already an API
for graphics (and input).

If you wrote up a general API for sending commands to windows, then you
could write a window system that tiled windows and provided tags to
execute commands from. I think that would be a very good thing,
FWIW. Not that there aren't other issues to consider to make the system
as usable as Acme, for example how the “applets” in this system are
going to interoperate with each other.

Re: [9fans] Why does Acme only show text?

[Ethan Grammatikidis]

On Wed, 15 Jul 2009 09:25:51 GMT
Paul Donnelly <paul-donnelly@sbcglobal.net> wrote:

> jason.catena@gmail.com (Jason Catena) writes:
>
> > I've been wondering for years now why Acme (and Wily, which I used
> > first) only display text files.
> >
> > It seems to me that the content of an Acme window could be anything: a
> > picture, a postscript or PDF file, a star chart, a web page.  Keeping
> > with the spirit of small parts brought together, Acme could outsource
> > the displaying of the content to another program, place its output in
> > the Acme window, and operate on it by sending commands from the tag to
> > the rendering program.
>
> Hi, I don't know anything about anything, but it seems to me that it's
> more productive to look at the question the other way around: why not
> modify Rio to tile windows like Acme does? Acme is a text editor, so
> it's no surprise that it handles text only.

You may be thinking too monolithically. The draw device multiplexes itself so it shouldn't take much coding for acme to provide draw in addition to the other files it provides in /mnt/wsys.

Mouse is just as important as draw and will need a little more code. Not only would acme need to multiplex it but it would need to emulate rio's behaviour. To quote Rio's man page: "Opening it turns off scrolling, editing, and rio-supplied menus in the associated window." That isn't 100% true, scrolling isn't actually disabled but is not naturally accessible and looks very messy when you force it. What is true is that rio ceases to interpret keys specially other than backspace and return (curiously), and mouse events on the window are blindly sent to the application.

It still doesn't sound like a lot of code, but may take some careful thought. Maybe that's a summary of Plan 9 methodology. :)

I also take issue with the statement "Acme is a text editor," that never sounds right, no more than describing Emacs as a text editor. It's natural to use Acme as a text editor and it provides many more text-editing facilities than Rio does, but it is also natural to use it as a file manager, shell window provider, email client, etc, etc. It provides more than Rio and it does it all with tiling windows and without menus, but that's just style. Rio windows could seriously use a search function and one or two other text-editor facilities wouldn't go amiss. It doesn't seem natural to me that Acme does not allow graphical programs in it's windows.

--
Ethan Grammatikidis

Those who are slower at parsing information must
necessarily be faster at problem-solving.

Re: [9fans] Why does Acme only show text?

[cej]

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



>  I also take issue with the statement "Acme is a text editor," that never sounds right, no more than describing Emacs as
>  a text editor. It's natural to use Acme as a text editor and it provides many more text-editing facilities than Rio
>  does, but it is also natural to use it as a file manager, shell window provider, email client, etc, etc. 
>  It provides more than Rio and it does it all with tiling windows and without menus, but that's just style. 

I always thought of using Acme as 'The' UI for Plan 9, much in the Oberon way. I'm not a techie, but I use Plan 9 since 2000, or so, as my main OS. I would *way* love having graphics in Acme, asi it IS a great UI, IMHO.

Peter A. Cejchan, aka
++pac.

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2850 bytes --]

Re: [9fans] Why does Acme only show text?

[Ethan Grammatikidis]

On Wed, 15 Jul 2009 17:32:09 +0200
<cej@gli.cas.cz> wrote:

>
>
> >  I also take issue with the statement "Acme is a text editor," that never sounds right, no more than describing Emacs as
> >  a text editor. It's natural to use Acme as a text editor and it provides many more text-editing facilities than Rio
> >  does, but it is also natural to use it as a file manager, shell window provider, email client, etc, etc.
> >  It provides more than Rio and it does it all with tiling windows and without menus, but that's just style.
>
> I always thought of using Acme as 'The' UI for Plan 9, much in the Oberon way. I'm not a techie, but I use Plan 9 since 2000, or so, as my main OS. I would *way* love having graphics in Acme, asi it IS a great UI, IMHO.

As-is it's actually not a great UI for me, but perhaps with some small changes it could be. I'm still thinking those changes over.

--
Ethan Grammatikidis

Those who are slower at parsing information must
necessarily be faster at problem-solving.

Re: [9fans] Why does Acme only show text?

[John Floren]

On Wed, Jul 15, 2009 at 8:44 AM, Ethan Grammatikidis<eekee57@fastmail.fm> wrote:
> On Wed, 15 Jul 2009 17:32:09 +0200
> <cej@gli.cas.cz> wrote:
>
>>
>>
>> >  I also take issue with the statement "Acme is a text editor," that never sounds right, no more than describing Emacs as
>> >  a text editor. It's natural to use Acme as a text editor and it provides many more text-editing facilities than Rio
>> >  does, but it is also natural to use it as a file manager, shell window provider, email client, etc, etc.
>> >  It provides more than Rio and it does it all with tiling windows and without menus, but that's just style.
>>
>> I always thought of using Acme as 'The' UI for Plan 9, much in the Oberon way. I'm not a techie, but I use Plan 9 since 2000, or so, as my main OS. I would *way* love having graphics in Acme, asi it IS a great UI, IMHO.
>
> As-is it's actually not a great UI for me, but perhaps with some small changes it could be. I'm still thinking those changes over.
>

Acme is the worst editor/environment, except for all the others.

Sometimes it seems cluttered and confusing, but then I realize that's
because it has more files open than I would even try on emacs, merely
because switching around between emacs buffers is slower and less
convenient. Speaking of which, I recently discovered that emacs (on X,
at least) is now capable of running a terminal which can in turn run
vi or console-mode emacs. OT but madness. Now I want to run sam in
acme.

Eric and myself, and I think maybe Ron, are using acme and acme-sac to
interact with a BlueGene/P system. I write code in acme, then use a
guide file to run the various scripts I need to connect to the
frontend node and launch jobs, then use win to telnet into the
individual nodes and run tests. The real advantage comes from the
"Local" command and the way windows are managed/output is handled.

I'd really like to see acme get support for graphical programs,
although right now I'm content enough as things stand.


John
-- 
"I've tried programming Ruby on Rails, following TechCrunch in my RSS
reader, and drinking absinthe. It doesn't work. I'm going back to C,
Hunter S. Thompson, and cheap whiskey." -- Ted Dziuba

Re: [9fans] Why does Acme only show text?

[Francisco J Ballesteros]

This is funny: O/live supports both images and text. *but* It's been
months ago that I do not use it any longer to display images but only
for text. That way I may have more screen surface for text. Would
the same happen to acme? Or perhaps it's me.

On Wed, Jul 15, 2009 at 7:00 PM, John Floren<slawmaster@gmail.com> wrote:
> On Wed, Jul 15, 2009 at 8:44 AM, Ethan Grammatikidis<eekee57@fastmail.fm> wrote:
>> On Wed, 15 Jul 2009 17:32:09 +0200
>> <cej@gli.cas.cz> wrote:
>>
>>>
>>>
>>> >  I also take issue with the statement "Acme is a text editor," that never sounds right, no more than describing Emacs as
>>> >  a text editor. It's natural to use Acme as a text editor and it provides many more text-editing facilities than Rio
>>> >  does, but it is also natural to use it as a file manager, shell window provider, email client, etc, etc.
>>> >  It provides more than Rio and it does it all with tiling windows and without menus, but that's just style.
>>>
>>> I always thought of using Acme as 'The' UI for Plan 9, much in the Oberon way. I'm not a techie, but I use Plan 9 since 2000, or so, as my main OS. I would *way* love having graphics in Acme, asi it IS a great UI, IMHO.
>>
>> As-is it's actually not a great UI for me, but perhaps with some small changes it could be. I'm still thinking those changes over.
>>
>
> Acme is the worst editor/environment, except for all the others.
>
> Sometimes it seems cluttered and confusing, but then I realize that's
> because it has more files open than I would even try on emacs, merely
> because switching around between emacs buffers is slower and less
> convenient. Speaking of which, I recently discovered that emacs (on X,
> at least) is now capable of running a terminal which can in turn run
> vi or console-mode emacs. OT but madness. Now I want to run sam in
> acme.
>
> Eric and myself, and I think maybe Ron, are using acme and acme-sac to
> interact with a BlueGene/P system. I write code in acme, then use a
> guide file to run the various scripts I need to connect to the
> frontend node and launch jobs, then use win to telnet into the
> individual nodes and run tests. The real advantage comes from the
> "Local" command and the way windows are managed/output is handled.
>
> I'd really like to see acme get support for graphical programs,
> although right now I'm content enough as things stand.
>
>
> John
> --
> "I've tried programming Ruby on Rails, following TechCrunch in my RSS
> reader, and drinking absinthe. It doesn't work. I'm going back to C,
> Hunter S. Thompson, and cheap whiskey." -- Ted Dziuba
>
>

Re: [9fans] Why does Acme only show text?

[Steve Simon]

> Eric and myself, and I think maybe Ron, are using acme and acme-sac to
> interact with a BlueGene/P system.

Not as glamorous, but an alternative senario - I use sam and rio
to write embedded and windows code.

I edit the code with sam, but I do my best not to ever access
the seperate rio snarf buffer.

I keep the commands or scripts I need to test the code in rio's
snarf, when I am ready to try things I just click the rio window
and Button 2 to execute send.

-Steve

Re: [9fans] Why does Acme only show text?

[David Leimbach]

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

On Wed, Jul 15, 2009 at 11:26 AM, Steve Simon <steve@quintile.net> wrote:

> > Eric and myself, and I think maybe Ron, are using acme and acme-sac to
> > interact with a BlueGene/P system.
>
> Not as glamorous, but an alternative senario - I use sam and rio
> to write embedded and windows code.
>
> I edit the code with sam, but I do my best not to ever access
> the seperate rio snarf buffer.
>
> I keep the commands or scripts I need to test the code in rio's
> snarf, when I am ready to try things I just click the rio window
> and Button 2 to execute send.
>
> -Steve
>

I use plan 9 port acme fairly regularly, when I get tired of weird Emacsisms
that get in my way rather than helping me.

Just yesterday I was writing Common Lisp code, with an SBCL REPL in the
bottom window and an editor of the lisp code in the upper window, for
testing out an SNMP agent I wrote for another platform (Common Lisp for the
test harness seems like it's been a great choice so far... I just love
defmacro)

It's really nice to quickly cut and paste an expression from the editor to
the REPL to test ideas, or vice versa... fight with S-expressions at the
REPL, then cobble the program together by pasting functional parts together.

I'll probably start writing my Haskell that way, but Haskell has this damned
"layout" style that I seem to default to that's like Python and gets most
annoying when spacing isn't "just so".  I guess I'll switch to the { ;}
style that it also supports.  Emacs is sadly far better with the layout
style than acme seems like it could be, as there's some "choices" to the
indentation that mean different things that one can cycle through, and
Emacs' mode gets this right.

Again, the layout mode seems to be a bug in Haskell not a feature, but
that's not a popular belief in that community.

Dave

[-- Attachment #2: Type: text/html, Size: 2385 bytes --]

Re: [9fans] Why does Acme only show text?

[John Floren]

On Wed, Jul 15, 2009 at 11:59 AM, David Leimbach<leimy2k@gmail.com> wrote:
>
>
> On Wed, Jul 15, 2009 at 11:26 AM, Steve Simon <steve@quintile.net> wrote:
>>
>> > Eric and myself, and I think maybe Ron, are using acme and acme-sac to
>> > interact with a BlueGene/P system.
>>
>> Not as glamorous, but an alternative senario - I use sam and rio
>> to write embedded and windows code.
>>
>> I edit the code with sam, but I do my best not to ever access
>> the seperate rio snarf buffer.
>>
>> I keep the commands or scripts I need to test the code in rio's
>> snarf, when I am ready to try things I just click the rio window
>> and Button 2 to execute send.
>>
>> -Steve
>
> I use plan 9 port acme fairly regularly, when I get tired of weird Emacsisms
> that get in my way rather than helping me.

Emacs is great for writing Lisp. Now, if only I could find the correct
.emacs invocation to make the tab key insert a tab character in C
mode, rather than a bunch of spaces the way His Holy Lunacy RMS
desires. If I wanted spaces instead of tabs, I'd type them!


John
--
"I've tried programming Ruby on Rails, following TechCrunch in my RSS
reader, and drinking absinthe. It doesn't work. I'm going back to C,
Hunter S. Thompson, and cheap whiskey." -- Ted Dziuba

Re: [9fans] Why does Acme only show text?

[David Leimbach]

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

On Wed, Jul 15, 2009 at 12:07 PM, John Floren <slawmaster@gmail.com> wrote:

> On Wed, Jul 15, 2009 at 11:59 AM, David Leimbach<leimy2k@gmail.com> wrote:
> >
> >
> > On Wed, Jul 15, 2009 at 11:26 AM, Steve Simon <steve@quintile.net>
> wrote:
> >>
> >> > Eric and myself, and I think maybe Ron, are using acme and acme-sac to
> >> > interact with a BlueGene/P system.
> >>
> >> Not as glamorous, but an alternative senario - I use sam and rio
> >> to write embedded and windows code.
> >>
> >> I edit the code with sam, but I do my best not to ever access
> >> the seperate rio snarf buffer.
> >>
> >> I keep the commands or scripts I need to test the code in rio's
> >> snarf, when I am ready to try things I just click the rio window
> >> and Button 2 to execute send.
> >>
> >> -Steve
> >
> > I use plan 9 port acme fairly regularly, when I get tired of weird
> Emacsisms
> > that get in my way rather than helping me.
>
> Emacs is great for writing Lisp. Now, if only I could find the correct
> .emacs invocation to make the tab key insert a tab character in C
> mode, rather than a bunch of spaces the way His Holy Lunacy RMS
> desires. If I wanted spaces instead of tabs, I'd type them!



And yet since every damned editor interprets a tab differently, I'd almost
with the tab key away completely :-)

I guess we just make everyone use Acme and move on :-).

Dave

>
>
>
> John
> --
> "I've tried programming Ruby on Rails, following TechCrunch in my RSS
> reader, and drinking absinthe. It doesn't work. I'm going back to C,
> Hunter S. Thompson, and cheap whiskey." -- Ted Dziuba
>
>

[-- Attachment #2: Type: text/html, Size: 2400 bytes --]

Re: [9fans] Why does Acme only show text?

[Chad Brown]

> Emacs is great for writing Lisp. Now, if only I could find the correct
> .emacs invocation to make the tab key insert a tab character in C
> mode, rather than a bunch of spaces the way His Holy Lunacy RMS
> desires. If I wanted spaces instead of tabs, I'd type them!

OT for the list, but this is trivial in emacs for several years now,
and RMS has nothing to do with the special code for C mode (which is
called CC-mode, and supports a bevy of languages, and is complicated
enough that it can probably boot minix on it's own by now).

*Chad

Re: [9fans] Why does Acme only show text?

[John Floren]

On Wed, Jul 15, 2009 at 1:58 PM, Chad Brown<yandros@mit.edu> wrote:
>> Emacs is great for writing Lisp. Now, if only I could find the correct
>> .emacs invocation to make the tab key insert a tab character in C
>> mode, rather than a bunch of spaces the way His Holy Lunacy RMS
>> desires. If I wanted spaces instead of tabs, I'd type them!
>
> OT for the list, but this is trivial in emacs for several years now, and RMS
> has nothing to do with the special code for C mode (which is called CC-mode,
> and supports a bevy of languages, and is complicated enough that it can
> probably boot minix on it's own by now).
>
> *Chad
>
>

In the interests of not slandering Emacs excessively, I'd like to
state that I seem to have figured out my .emacs file to a point where
hitting a tab inserts a tab. That will be all.

John
--
"I've tried programming Ruby on Rails, following TechCrunch in my RSS
reader, and drinking absinthe. It doesn't work. I'm going back to C,
Hunter S. Thompson, and cheap whiskey." -- Ted Dziuba

Re: [9fans] Why does Acme only show text?

[Jason Catena]

> Again, the layout mode seems to be a bug in Haskell not a feature, but
> that's not a popular belief in that community.

It's only as complex as the various levels of scope you end up needing
in your program.  Meaningful whitespace enforces a clean, readable,
delimiter-free style, making programs look more like each other.  It's
a lot easier to see (and not have in the first place) incorrect scope
and continuation with whitespace than with braces or parentheses.

Acme only has two indentation rules (nothing, or same as the existing
line), so Emacs' constant re-parsing of the file to determine the
correct indentation level is always going to be more "correct".  This
kind of programming support seems akin to me to colorful syntax
highlighting: great if you need it, distracting once you really get
good with a language.  In the case of indenting, I might not actually
code the next line right away, but auto-indent to just the right place
for it means I have to go out of my way more often to get the cursor
to where I actually want it.

> Dave

Jason Catena

Re: [9fans] Why does Acme only show text?

[erik quanstrom]

> It's
> a lot easier to see (and not have in the first place) incorrect scope
> and continuation with whitespace than with braces or parentheses.

do you have a reference for this claim?

- erik

Re: [9fans] Why does Acme only show text?

[andrey mirtchovski]

>> It's
>> a lot easier to see (and not have in the first place) incorrect scope
>> and continuation with whitespace than with braces or parentheses.

i read this as "it's a lot easier to see incorrect variations in the
tempo of a mucal piece with white noise than with a metronome"

> do you have a reference for this claim?
>

and here i imagined the crazy-haired mad scientist saying "your
whitespace is not so white now, is it?! muahahahaha"

then i took my meds.

Re: [9fans] Why does Acme only show text?

[Devon H. O'Dell]

2009/7/15 erik quanstrom <quanstro@coraid.com>:
>> It's
>> a lot easier to see (and not have in the first place) incorrect scope
>> and continuation with whitespace than with braces or parentheses.
>
> do you have a reference for this claim?

Without turning this into a holy war, I really always see these issues
as a matter of personal preference. This is why editors are so bloated
and languages have weird conventions.

On that note, my personal experience has found it to be a lot easier
to find and correct scope issues in Python than it has to find missing
braces or semicolons in other languages, sometimes even with matching
enabled. This usually is the case for awful spaghetti-ish code.

But I digress.

--dho

Re: [9fans] Why does Acme only show text?

[Jason Catena]

Devon's anecdote is along the lines of my position.  I'm sure there's
a paper somewhere that counts parenthesis versus whitespace errors,
but I haven't yet read it.  I have programmed Lisp and Haskell (at two
extremes), and from this experience at least much prefer whitespace to
parentheses.  In addition, I rely on design theory (esp. Tufte et al
on his web site) that reducing clutter aids comprehension, and
delimiters very much seem clutter to me.

Jason Catena

Re: [9fans] Why does Acme only show text?

[Noah Evans]

http://9fans.net/archive/2008/05/6

On Wed, Jul 15, 2009 at 10:29 PM, Jason Catena<jason.catena@gmail.com> wrote:
> Devon's anecdote is along the lines of my position.  I'm sure there's
> a paper somewhere that counts parenthesis versus whitespace errors,
> but I haven't yet read it.  I have programmed Lisp and Haskell (at two
> extremes), and from this experience at least much prefer whitespace to
> parentheses.  In addition, I rely on design theory (esp. Tufte et al
> on his web site) that reducing clutter aids comprehension, and
> delimiters very much seem clutter to me.
>
> Jason Catena
>
>

Re: [9fans] Why does Acme only show text?

[David Leimbach]

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

On Wed, Jul 15, 2009 at 1:42 PM, Noah Evans <noah.evans@gmail.com> wrote:

> http://9fans.net/archive/2008/05/6


Haskell *will* tell you errors that don't make any sense (at least GHC
errors) when you don't have things like this done properly

do x <- foo
y <- bar

the y <- bar must be directly under the x on the previous line or it's a
syntax error, and the error you get from GHC is "the last statement of a do
construct must be an expression"

not

"dude, you suck at indenting code, and should have used Emacs to keep track
of it, because nothing else does the job right".

Luckilly Haskell will let you ignore "layout" and do the following:

do { x <- foo
; y <- bar }

However, I don't see enough of this style code to feel comfortable writing
anything I'd plan to share with anyone and expect them to feel ok reading
it.

Dave


> <http://9fans.net/archive/2008/05/6>
>
> On Wed, Jul 15, 2009 at 10:29 PM, Jason Catena<jason.catena@gmail.com>
> wrote:
> > Devon's anecdote is along the lines of my position.  I'm sure there's
> > a paper somewhere that counts parenthesis versus whitespace errors,
> > but I haven't yet read it.  I have programmed Lisp and Haskell (at two
> > extremes), and from this experience at least much prefer whitespace to
> > parentheses.  In addition, I rely on design theory (esp. Tufte et al
> > on his web site) that reducing clutter aids comprehension, and
> > delimiters very much seem clutter to me.
> >
> > Jason Catena
> >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 2423 bytes --]

Re: [9fans] Why does Acme only show text?

[Ethan Grammatikidis]

On Wed, 15 Jul 2009 13:51:02 -0700
David Leimbach <leimy2k@gmail.com> wrote:

> On Wed, Jul 15, 2009 at 1:42 PM, Noah Evans <noah.evans@gmail.com> wrote:
>
> > http://9fans.net/archive/2008/05/6
>
>
> Haskell *will* tell you errors that don't make any sense (at least GHC
> errors) when you don't have things like this done properly

The linked post pointed out there are times when barely-visible errors are not caught and go on to cause big problems. That's pretty nasty.

>
> do x <- foo
> y <- bar
>
> the y <- bar must be directly under the x on the previous line or it's a
> syntax error, and the error you get from GHC is "the last statement of a do
> construct must be an expression"

Huh, so this Haskell syntax actually prevents you from indenting something that would be indented in any other language. Okay...

>
> Luckilly Haskell will let you ignore "layout" and do the following:
>
> do { x <- foo
> ; y <- bar }
>
> However, I don't see enough of this style code to feel comfortable writing
> anything I'd plan to share with anyone and expect them to feel ok reading
> it.

It sure doesn't look comfortable to me. Strange semicolon placement for one thing. Do the braces have to be on the same lines as the code like that? Could it be written like this?:

do
{
	x <- foo;
	y <- bar
}

That's readable to my eyes, but looks like it may be quite different to the first form.


--
Ethan Grammatikidis

Those who are slower at parsing information must
necessarily be faster at problem-solving.

Re: [9fans] Why does Acme only show text?

[Jason Catena]

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

Real World Haskell ch4 pp71-72
>> do x <- foo
>> y <- bar
>>
>> the y <- bar must be directly under the x on the previous line or it's a
>> syntax error, and the error you get from GHC is "the last statement of a
do
>> construct must be an expression"
>
> Huh, so this Haskell syntax actually prevents you from indenting something
that would be indented in any other language. Okay...

I didn't read it like this.  The x and y must be lined up because they are
both part of the same set of do-statements.  If the y line was a standalone
statement, then it could be indented as shown in this code segment.  But in
that case there's no need for a do, since the point of do is to order
statements in sequential time.

the following is a complete Haskell program, using do, which passes through
its input file to an output file.  The > specifies code lines, other lines
are considered comments. (I hope gmail preserves the spacing.)

Real World Haskell ch4 pp71-72

> import System.Environment (getArgs)
>
> interactWith function inputFile outputFile = do
>   input <- readFile inputFile
>   writeFile outputFile (function input)
>
> main = mainWith myFunction
>   where mainWith function = do
>           args <- getArgs
>           case args of
>             [input,output] -> interactWith function input output
>             _ -> putStrLn "error: need exactly two arguments"

Replace id with any function (of the same type)
to process the data.

> myFunction = id

[-- Attachment #2: Type: text/html, Size: 5025 bytes --]

Re: [9fans] Why does Acme only show text?

[Ethan Grammatikidis]

On Wed, 15 Jul 2009 22:42:20 +0200
Noah Evans <noah.evans@gmail.com> wrote:

> http://9fans.net/archive/2008/05/6

Good to see this brought up. Whitespace may be the most comfortably readable means of indicating flow, but it's fragile. Better, IMHO, is delimiters with plenty of space around them, but even then they do intrude. Currently I like Q where parentheses can be used if necessary but a couple of syntactic tricks are used to keep them to the minimum and whitespace has some meaning but (IIRC) not over-much.

I find the best thing to do with languages with delimeters is to run code through a code formatter often. I'm using Gnu indent for C code (especially valuable when dealing with Gnu C :) ), is there a similar tool for Plan 9?

> 
> On Wed, Jul 15, 2009 at 10:29 PM, Jason Catena<jason.catena@gmail.com> wrote:
> > Devon's anecdote is along the lines of my position.  I'm sure there's
> > a paper somewhere that counts parenthesis versus whitespace errors,
> > but I haven't yet read it.  I have programmed Lisp and Haskell (at two
> > extremes), and from this experience at least much prefer whitespace to
> > parentheses.  In addition, I rely on design theory (esp. Tufte et al
> > on his web site) that reducing clutter aids comprehension, and
> > delimiters very much seem clutter to me.
> >
> > Jason Catena
> >
> >
>

-- 
Ethan Grammatikidis

Those who are slower at parsing information must
necessarily be faster at problem-solving.

Re: [9fans] Why does Acme only show text?

[erik quanstrom]

> I find the best thing to do with languages with delimeters is to run code through a code formatter often. I'm using Gnu indent for C code (especially valuable when dealing with Gnu C :) ), is there a similar tool for Plan 9?

i find that formatting code well to begin with works best.
but when faced with ugly code, cb(1) is helpful.  steve has
something a bit more aggressive in his contrib area.

- erik

Re: [9fans] Why does Acme only show text?

[Ethan Grammatikidis]

On Wed, 15 Jul 2009 17:12:58 -0400
erik quanstrom <quanstro@coraid.com> wrote:

> > I find the best thing to do with languages with delimeters is to run code through a code formatter often. I'm using Gnu indent for C code (especially valuable when dealing with Gnu C :) ), is there a similar tool for Plan 9?
>
> i find that formatting code well to begin with works best.
> but when faced with ugly code, cb(1) is helpful.  steve has
> something a bit more aggressive in his contrib area.

Cheers, I'll try cb


--
Ethan Grammatikidis

Those who are slower at parsing information must
necessarily be faster at problem-solving.

Re: [9fans] Why does Acme only show text?

[Lyndon Nerenberg]

> On that note, my personal experience has found it to be a lot easier
> to find and correct scope issues in Python than it has to find missing
> braces or semicolons in other languages, sometimes even with matching
> enabled. This usually is the case for awful spaghetti-ish code.

I find Python's whitespace rules annoying, but I can live with them.

Where the whitespace flow control always screws me is when I'm working on
a particular chunk of code using different editors that have different
semantics for interpreting <HT>. You have to remember if the editor of the
moment interprets <HT> as:

1) HT passed through, displays to next col%8
2) HT passed through, displays to next col%user_defined_tabstop setting
3) As for (1) and (2), but <HT> also expanded to corresponding n*<SP>
    to match display interpretation.

As soon as you mix 8 and non-8 tabstop rails, any remnants of sanity exit
stage left. Because of this I far-too-often find myself running
acme-edited code through [un]expand to ensure sane tab behaviour.
(Not acme's falut per se -- it's just the editor I most commonly use that
does non-8 tabstops by default.)

--lyndon

Re: [9fans] Why does Acme only show text?

[Federico G. Benavento]

acme is more than a buffer with text to edit, it also has the
filesystem interface
that allows programs to be written specifically for it (Mail, Wiki, etc).
I never thought that doing graphics in acme was a need, as most of the time
I'm just editing text and having some graphical up there would take space that
I can really use to list a directory, another source file, or whatever.

I also don't think that you'll have to emulate rio's behavior as you
can run most
of the graphical programs without rio, that's the beauty of rio, it gives almost
the same interface as it gets from the kernel.

in any case, years ago I gave it a try, but I after a day of hacking I lost my
interest, I know some people still want this functionality, so if you are
up to the challenge go for it. I have a tgz on mordor which can run
draw apps on acme, but it's not functional at all, so if you're
interested let me know

http://www.tip9ug.jp/who/fgb/acme.png


On Wed, Jul 15, 2009 at 9:22 AM, Ethan Grammatikidis<eekee57@fastmail.fm> wrote:
> On Wed, 15 Jul 2009 09:25:51 GMT
> Paul Donnelly <paul-donnelly@sbcglobal.net> wrote:
>
>> jason.catena@gmail.com (Jason Catena) writes:
>>
>> > I've been wondering for years now why Acme (and Wily, which I used
>> > first) only display text files.
>> >
>> > It seems to me that the content of an Acme window could be anything: a
>> > picture, a postscript or PDF file, a star chart, a web page.  Keeping
>> > with the spirit of small parts brought together, Acme could outsource
>> > the displaying of the content to another program, place its output in
>> > the Acme window, and operate on it by sending commands from the tag to
>> > the rendering program.
>>
>> Hi, I don't know anything about anything, but it seems to me that it's
>> more productive to look at the question the other way around: why not
>> modify Rio to tile windows like Acme does? Acme is a text editor, so
>> it's no surprise that it handles text only.
>
> You may be thinking too monolithically. The draw device multiplexes itself so it shouldn't take much coding for acme to provide draw in addition to the other files it provides in /mnt/wsys.
>
> Mouse is just as important as draw and will need a little more code. Not only would acme need to multiplex it but it would need to emulate rio's behaviour. To quote Rio's man page: "Opening it turns off scrolling, editing, and rio-supplied menus in the associated window." That isn't 100% true, scrolling isn't actually disabled but is not naturally accessible and looks very messy when you force it. What is true is that rio ceases to interpret keys specially other than backspace and return (curiously), and mouse events on the window are blindly sent to the application.
>
> It still doesn't sound like a lot of code, but may take some careful thought. Maybe that's a summary of Plan 9 methodology. :)
>
> I also take issue with the statement "Acme is a text editor," that never sounds right, no more than describing Emacs as a text editor. It's natural to use Acme as a text editor and it provides many more text-editing facilities than Rio does, but it is also natural to use it as a file manager, shell window provider, email client, etc, etc. It provides more than Rio and it does it all with tiling windows and without menus, but that's just style. Rio windows could seriously use a search function and one or two other text-editor facilities wouldn't go amiss. It doesn't seem natural to me that Acme does not allow graphical programs in it's windows.
>
> --
> Ethan Grammatikidis
>
> Those who are slower at parsing information must
> necessarily be faster at problem-solving.
>
>



-- 
Federico G. Benavento

Re: [9fans] Why does Acme only show text?

[David Leimbach]

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

fgb, your ability to hack is mighty indeed :-)

On Wed, Jul 15, 2009 at 2:00 PM, Federico G. Benavento
<benavento@gmail.com>wrote:

> acme is more than a buffer with text to edit, it also has the
> filesystem interface
> that allows programs to be written specifically for it (Mail, Wiki, etc).
> I never thought that doing graphics in acme was a need, as most of the time
> I'm just editing text and having some graphical up there would take space
> that
> I can really use to list a directory, another source file, or whatever.
>
> I also don't think that you'll have to emulate rio's behavior as you
> can run most
> of the graphical programs without rio, that's the beauty of rio, it gives
> almost
> the same interface as it gets from the kernel.
>
> in any case, years ago I gave it a try, but I after a day of hacking I lost
> my
> interest, I know some people still want this functionality, so if you are
> up to the challenge go for it. I have a tgz on mordor which can run
> draw apps on acme, but it's not functional at all, so if you're
> interested let me know
>
> http://www.tip9ug.jp/who/fgb/acme.png
>
>
> On Wed, Jul 15, 2009 at 9:22 AM, Ethan Grammatikidis<eekee57@fastmail.fm>
> wrote:
> > On Wed, 15 Jul 2009 09:25:51 GMT
> > Paul Donnelly <paul-donnelly@sbcglobal.net> wrote:
> >
> >> jason.catena@gmail.com (Jason Catena) writes:
> >>
> >> > I've been wondering for years now why Acme (and Wily, which I used
> >> > first) only display text files.
> >> >
> >> > It seems to me that the content of an Acme window could be anything: a
> >> > picture, a postscript or PDF file, a star chart, a web page.  Keeping
> >> > with the spirit of small parts brought together, Acme could outsource
> >> > the displaying of the content to another program, place its output in
> >> > the Acme window, and operate on it by sending commands from the tag to
> >> > the rendering program.
> >>
> >> Hi, I don't know anything about anything, but it seems to me that it's
> >> more productive to look at the question the other way around: why not
> >> modify Rio to tile windows like Acme does? Acme is a text editor, so
> >> it's no surprise that it handles text only.
> >
> > You may be thinking too monolithically. The draw device multiplexes
> itself so it shouldn't take much coding for acme to provide draw in addition
> to the other files it provides in /mnt/wsys.
> >
> > Mouse is just as important as draw and will need a little more code. Not
> only would acme need to multiplex it but it would need to emulate rio's
> behaviour. To quote Rio's man page: "Opening it turns off scrolling,
> editing, and rio-supplied menus in the associated window." That isn't 100%
> true, scrolling isn't actually disabled but is not naturally accessible and
> looks very messy when you force it. What is true is that rio ceases to
> interpret keys specially other than backspace and return (curiously), and
> mouse events on the window are blindly sent to the application.
> >
> > It still doesn't sound like a lot of code, but may take some careful
> thought. Maybe that's a summary of Plan 9 methodology. :)
> >
> > I also take issue with the statement "Acme is a text editor," that never
> sounds right, no more than describing Emacs as a text editor. It's natural
> to use Acme as a text editor and it provides many more text-editing
> facilities than Rio does, but it is also natural to use it as a file
> manager, shell window provider, email client, etc, etc. It provides more
> than Rio and it does it all with tiling windows and without menus, but
> that's just style. Rio windows could seriously use a search function and one
> or two other text-editor facilities wouldn't go amiss. It doesn't seem
> natural to me that Acme does not allow graphical programs in it's windows.
> >
> > --
> > Ethan Grammatikidis
> >
> > Those who are slower at parsing information must
> > necessarily be faster at problem-solving.
> >
> >
>
>
>
> --
> Federico G. Benavento
>
>

[-- Attachment #2: Type: text/html, Size: 4894 bytes --]

Re: [9fans] Why does Acme only show text?

[Paul Donnelly]

eekee57@fastmail.fm (Ethan Grammatikidis) writes:

> On Wed, 15 Jul 2009 09:25:51 GMT
> Paul Donnelly <paul-donnelly@sbcglobal.net> wrote:
>
>> jason.catena@gmail.com (Jason Catena) writes:
>>
>> > I've been wondering for years now why Acme (and Wily, which I used
>> > first) only display text files.
>> >
>> > It seems to me that the content of an Acme window could be anything: a
>> > picture, a postscript or PDF file, a star chart, a web page.  Keeping
>> > with the spirit of small parts brought together, Acme could outsource
>> > the displaying of the content to another program, place its output in
>> > the Acme window, and operate on it by sending commands from the tag to
>> > the rendering program.
>>
>> Hi, I don't know anything about anything, but it seems to me that it's
>> more productive to look at the question the other way around: why not
>> modify Rio to tile windows like Acme does? Acme is a text editor, so
>> it's no surprise that it handles text only.
>
> You may be thinking too monolithically. The draw device multiplexes itself so it shouldn't take much coding for acme to provide draw in addition to the other files it provides in /mnt/wsys.
>
> Mouse is just as important as draw and will need a little more code. Not only would acme need to multiplex it but it would need to emulate rio's behaviour. To quote Rio's man page: "Opening it turns off scrolling, editing, and rio-supplied menus in the associated window." That isn't 100% true, scrolling isn't actually disabled but is not naturally accessible and looks very messy when you force it. What is true is that rio ceases to interpret keys specially other than backspace and return (curiously), and mouse events on the window are blindly sent to the application.
>
> It still doesn't sound like a lot of code, but may take some careful thought. Maybe that's a summary of Plan 9 methodology. :)

That's why Rio seems like a more apropos starting point to me. :) It
seems to me that the primary task of this hypothetical program would be
providing /dev/draw to the programs running under it. Changing Rio's
window layout code and adding a command protocol strikes me as less
monolithic than combining window system duties with everything Acme
already does.

> I also take issue with the statement "Acme is a text editor," that never sounds right, no more than describing Emacs as a text editor. It's natural to use Acme as a text editor and it provides many more text-editing facilities than Rio does, but it is also natural to use it as a file manager, shell window provider, email client, etc, etc. It provides more than Rio and it does it all with tiling windows and without menus, but that's just style. Rio windows could seriously use a search function and one or two other text-editor facilities wouldn't go amiss. It doesn't seem natural to me that Acme does not allow graphical programs in it's windows.

Fair enough. I just meant to say that Acme has a fairly focused design,
which is oriented around the notion of windows containing text. If I
wanted windows to potentially contain something other that text I'd
reevaluate the design based on that criterion. And what I think I'd do
would be as I described above, with the addition of a program that
behaved like a single Acme window. FWIW, I don't think Emacs's design is
perfect for a general application host either, although it's certainly a
great program despite that.

It's not like I'm some master software architect (and I see Rob Pike,
who certainly has a more informed perspective on this than me, was
thinking along the lines of Acme with graphics). I'm just saying my
instinct is to decompose further and take as much out of the
graphics/command host as possible. There are trade-offs either way, and
maybe it would be more productive after all to mod Acme.