[9fans] Acme without Flamage

[9fans] Acme without Flamage

[Wendell xe]

When I saw the length of the Acme thread, I thought "Wow, so much information!" But it turned out to be mostly flamage. Can't we all just get along?{C}

I don't believe in a single best IDE any more than a single best language. What is best depends on both the particular work and the coder's personal tastes. And, as with programming languages, I think it's good to familiarize yourself with different paradigms.

My nutshell evaluation of Acme is that it is for systems-level coding in C on modest-sized projects. It seems very well designed for that purpose but quickly becomes awkward as you move away. It is definitely not suited to working with Java or Lisp, or navigating large directories.

Acme is often compared to vi/emacs as a power-user's tool with a different operating paradigm. It is, but I think people wrongly point to the keyboard/mouse issue as the basic difference. The real difference is that vi/emacs are all about configurability but Acme focuses on integration with the system while not being configurable at all (unless you count hacking the source).

Also, the frequent reference to UTF-8 is a bit misleading. Handling Unicode is about more than just recognizing the code points. It is tricky to properly display the various scripts of the world. For a good treatment of the issues presented in a simple interface, look at the Yudit editor.

Finally, I'm kind of surprised at the lack of interest in controlling fonts. My usual coding font is 12 pt. Dina or Terminus. But if my eyes are really tired, I might switch to 16 pt. Monaco. On the other hand, I sometimes use 8 pt. ProFont to better get an overview. I would think even Plan 9 hackers would appreciate being able to quickly shift around like that.

Re: [9fans] Acme without Flamage

[Tom Lieber]

On Wed, Aug 20, 2008 at 11:12 AM, Wendell xe <wendellxe@yahoo.com> wrote:
> Acme is often compared to vi/emacs as a power-user's tool with a different operating paradigm. It is, but I think people wrongly point to the keyboard/mouse issue as the basic difference. The real difference is that vi/emacs are all about configurability but Acme focuses on integration with the system while not being configurable at all (unless you count hacking the source).
...
> Finally, I'm kind of surprised at the lack of interest in controlling fonts. My usual coding font is 12 pt. Dina or Terminus. But if my eyes are really tired, I might switch to 16 pt. Monaco. On the other hand, I sometimes use 8 pt. ProFont to better get an overview. I would think even Plan 9 hackers would appreciate being able to quickly shift around like that.

I think the "configuration" of acme is mostly in the realm of making
better and better scripts to keep in your tags, or utility buffers. I
believe most people who use acme set up their tags and open files with
links to their favorite scripts then dump the editor state, then use
that dump file every time they start acme. That is how acme is
configured.

Several of the responses to your original e-mail were to "write a
script to do it," mainly because executing text filters is the only
command primitive acme seems to have besides opening files.

Just like the easiest way to "implement" bookmarks was to create a
file with right-clickable bookmarks in it, the easiest way to switch
between fonts is probably to create a file with middle-clickable font
change commands.

After reading this thread I tried keeping an "Edit =" in my tag for
creating bookmarks to parts of a really long file I'm editing as I
went. It worked pretty well. It's so flexible -- everything is just
text.

--
Tom Lieber
http://AllTom.com/

Re: [9fans] Acme without Flamage

[Robert Raschke]

One of the central tenets of Plan 9 is that everything is a file. So
all file based activities are really, really easy.

Most OO programming appears to follow a more DB oriented style (at
least those with horrendous packaging/module mechanisms). That files
are used to store your programs appears to be incidental. Therefore
using a file oriented system when programming something like Java is
painful, to say the least.

Thus, acme is very probably not the right editor, unless you are in
complete control of the code. But I would say the same holds for vi or
emacs. Its just that those two have had a lot of additions poured into
them that were inspired by the IDE world.

Acme is supremely fabulous when you are in complete control or if
you're programming using a language/environment where there are no
strange rules on where your files have to go (the underlying OO DB,
essentially).

Initially, all that replacing vi/emacs with acme does is change your
habits from keyboarding to mousing. All the pain you get from the
"bad" code remains the same. Some of the IDE inspired features in
vi/emacs may help lessen that pain slightly. But to get a more radical
change, I'm afraid using a proper IDE is where it happens. Welcome to
objects, good-bye files.

Robby

Re: [9fans] Acme without Flamage

[sqweek]

On Wed, Aug 20, 2008 at 11:12 PM, Wendell xe <wendellxe@yahoo.com> wrote:
> My nutshell evaluation of Acme is that it is for systems-level coding in C on modest-sized projects. It seems very well designed for that purpose but quickly becomes awkward as you move away. It is definitely not suited to working with Java or Lisp,

 I used to feel much the same. Then I went back to coding java at
work, fired up eclipse and was like "... where's my chording? :( :(".
I had to whip up a plumbing rule so I could button 3 stack traces, but
after that it was pretty comfortable. I keep switching between them
now, generally using eclipse for browsing existing code or when using
a lot of interfaces that I'm not familiar with (function completion =
lazy way out), and acme when I want to view files side by side
(eclipse's "window management" can bite me) or when eclipse annoys me
too much with its highlights and tooltips and ctrl-w closing the
window and automatic paren balancing and popups and underlines and
FUCK OFF I KNOW THE FUNCTION NEEDS TO RETURN A BOOLEAN I'M HALFWAY
THROUGH DEFINING IT GIVE ME A CHANCE JEEZE. ...which is somewhat
often.

> or navigating large directories.

 Hm, why is acme particularly bad at this? I know I sigh every time I
open my home directory in p9p acme because it's full to the brim with
.foo .bar .qux .etc, the trick is just to know what you're looking for
and type it in instead of trying to find it.

> Finally, I'm kind of surprised at the lack of interest in controlling fonts. My usual coding font is 12 pt. Dina or Terminus. But if my eyes are really tired, I might switch to 16 pt. Monaco. On the other hand, I sometimes use 8 pt. ProFont to better get an overview. I would think even Plan 9 hackers would appreciate being able to quickly shift around like that.

 That surprises me, to be honest. Most people I know find a font they
like and stick with it.
-sqweek

Re: [9fans] Acme without Flamage

[David Leimbach]

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

On Wed, Aug 20, 2008 at 10:14 AM, sqweek <sqweek@gmail.com> wrote:

> On Wed, Aug 20, 2008 at 11:12 PM, Wendell xe <wendellxe@yahoo.com> wrote:
> > My nutshell evaluation of Acme is that it is for systems-level coding in
> C on modest-sized projects. It seems very well designed for that purpose but
> quickly becomes awkward as you move away. It is definitely not suited to
> working with Java or Lisp,
>
>  I used to feel much the same. Then I went back to coding java at
> work, fired up eclipse and was like "... where's my chording? :( :(".
> I had to whip up a plumbing rule so I could button 3 stack traces, but
> after that it was pretty comfortable. I keep switching between them
> now, generally using eclipse for browsing existing code or when using
> a lot of interfaces that I'm not familiar with (function completion =
> lazy way out), and acme when I want to view files side by side
> (eclipse's "window management" can bite me) or when eclipse annoys me
> too much with its highlights and tooltips and ctrl-w closing the
> window and automatic paren balancing and popups and underlines and
> FUCK OFF I KNOW THE FUNCTION NEEDS TO RETURN A BOOLEAN I'M HALFWAY
> THROUGH DEFINING IT GIVE ME A CHANCE JEEZE. ...which is somewhat
> often.


Hmmm acme plumbing rule for lisp s-expressions... that'd be neat :-)

As I've never written a plumbing rule in my life, I'm not sure how practical
that is.  (just haven't needed to do it...)

The only thing I'd miss in Acme vs emacs then, most likely, for lisp-like
languages is paren-matching.

And I'd miss it dearly.

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

Re: [9fans] Acme without Flamage

[Gorka Guardiola]

On Wed, Aug 20, 2008 at 7:42 PM, David Leimbach <leimy2k@gmail.com> wrote:
>
>
> The only thing I'd miss in Acme vs emacs then, most likely, for lisp-like
> languages is paren-matching.
> And I'd miss it dearly.
>
>

Double click on the paren selects the area enclosed by the matching paren.



--
- curiosity sKilled the cat

Re: [9fans] Acme without Flamage

[Paul Donnelly]

paurea@gmail.com (Gorka Guardiola) writes:

> On Wed, Aug 20, 2008 at 7:42 PM, David Leimbach <leimy2k@gmail.com> wrote:
>>
>>
>> The only thing I'd miss in Acme vs emacs then, most likely, for lisp-like
>> languages is paren-matching.
>> And I'd miss it dearly.
>>
>>
>
> Double click on the paren selects the area enclosed by the matching paren.
>
>
>
> --
> - curiosity sKilled the cat

I don't know if posts to usenet (where I lurk this list) go through to
the mailing list, but I've found Acme's paren matching to be
sufficient. The bear is indentation, since to make it work out it's
necessary to use a fixed-width font (something I'd rather not do) and
adjust it by hand, which needs to happen more often and by greater
degrees than in a language like C. The chief issues being:

(list (list 'a 'b 'c)
      (list 1 2 3))
;     ^
;     These need to line up.

;     These need to line up.
;     V
(let ((a 3)
      (b 4))
  (+ a b))
; ^
; Should be two spaces or so.

Re: [9fans] Acme without Flamage

[David Leimbach]

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

On Thu, Aug 21, 2008 at 2:06 AM, Paul Donnelly
<paul-donnelly@sbcglobal.net>wrote:

> paurea@gmail.com (Gorka Guardiola) writes:
>
> > On Wed, Aug 20, 2008 at 7:42 PM, David Leimbach <leimy2k@gmail.com>
> wrote:
> >>
> >>
> >> The only thing I'd miss in Acme vs emacs then, most likely, for
> lisp-like
> >> languages is paren-matching.
> >> And I'd miss it dearly.
> >>
> >>
> >
> > Double click on the paren selects the area enclosed by the matching
> paren.
> >
> >
> >
> > --
> > - curiosity sKilled the cat
>
> I don't know if posts to usenet (where I lurk this list) go through to
> the mailing list, but I've found Acme's paren matching to be
> sufficient. The bear is indentation, since to make it work out it's
> necessary to use a fixed-width font (something I'd rather not do) and
> adjust it by hand, which needs to happen more often and by greater
> degrees than in a language like C. The chief issues being:
>
> (list (list 'a 'b 'c)
>      (list 1 2 3))
> ;     ^
> ;     These need to line up.
>
> ;     These need to line up.
> ;     V
> (let ((a 3)
>      (b 4))
>  (+ a b))
> ; ^
> ; Should be two spaces or so.
>
>
Yeah I guess I'm spoiled by the hotkey visual cues I get from Emacs when
typing in code, that automatically show me the matching parens as I type.
 Perhaps I really don't *need* that.  I'll try Plan 9 Port acme again for
some Scheme Shell or something and see how it goes.  (Emacs screws up Scheme
Shell pretty badly, due to it's not accepting | characters in it's syntax
definition, and as I said before, customizing emacs is not the same as me
getting my work done)

Dave

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

Re: [9fans] Acme without Flamage

[sqweek]

On Thu, Aug 21, 2008 at 5:06 PM, Paul Donnelly
<paul-donnelly@sbcglobal.net> wrote:
> The bear is indentation, since to make it work out it's
> necessary to use a fixed-width font (something I'd rather not do) and
> adjust it by hand, which needs to happen more often and by greater
> degrees than in a language like C. The chief issues being:
>
> (list (list 'a 'b 'c)
>      (list 1 2 3))
> ;     ^
> ;     These need to line up.
>
> ;     These need to line up.
> ;     V
> (let ((a 3)
>      (b 4))
>  (+ a b))
> ; ^
> ; Should be two spaces or so.

 Huh. I always thought lisp had a couple of simple indentation rules,
but after spending a little time on fmtsexp.c it has become apparent
that the "two spaces or so" is a special case for let! Not sure I care
to try and deal with such cases, but maybe it is still somewhat
useful: http://sqweek.dnsdojo.org/plan9/fmtsexp.c
-sqweek

Re: [9fans] Acme without Flamage

[Paul Donnelly]

sqweek@gmail.com (sqweek) writes:

> On Thu, Aug 21, 2008 at 5:06 PM, Paul Donnelly
> <paul-donnelly@sbcglobal.net> wrote:
>> The bear is indentation, since to make it work out it's
>> necessary to use a fixed-width font (something I'd rather not do) and
>> adjust it by hand, which needs to happen more often and by greater
>> degrees than in a language like C. The chief issues being:
>>
>> (list (list 'a 'b 'c)
>>       (list 1 2 3))
>> ;     ^
>> ;     These need to line up.
>>
>> ;     These need to line up.
>> ;     V
>> (let ((a 3)
>>       (b 4))
>>   (+ a b))
>> ; ^
>> ; Should be two spaces or so.
>
>  Huh. I always thought lisp had a couple of simple indentation rules,
> but after spending a little time on fmtsexp.c it has become apparent
> that the "two spaces or so" is a special case for let! Not sure I care
> to try and deal with such cases, but maybe it is still somewhat
> useful: http://sqweek.dnsdojo.org/plan9/fmtsexp.c
> -sqweek

A fairly complete description of the rules is that forms line up with
other forms at the same level of nesting (the binding forms in the LET
or the arguments to LIST), but anything using &BODY FOO in its lambda
list (&BODY collects trailing arguments into FOO) gets two-space
indentation for the body. Indeed, this is the reason &BODY
exists. DEFMETHOD, though, needs to be specially recognized.  LOOP has
special needs. It's easier to indent with a program running in or
communing with your Lisp, since there's no other way to know, short of
reading every file in a project, whether a given macro uses &BODY or
not.