[prunebeads]

Personally, I switched to a tiled WM because I didn't want to go back and forth between keyboard and mouse all the time. I want an editor which I can handle using keyboard alone, and only use the mouse when I really have to (web, drawing, games - perhaps I should use a trackball). Acme relies too much on the mouse for me, but I like the idea a lot.

There's another couple of issues: syntax highlighting, large scale refactoring (which is not easy either with vi or emacs atm).

However, once you get accustomed to a certain workflow, it becomes difficult to accept something new. Maybe I should give it a shot.

[4ad]

I'm not sure what you mean by large scale refactoring, but refactoring is much easier in acme compared to any editor I used before because of the powerful sam command language[1] and structural regular expressions[2].

[1] http://plan9.bell-labs.com/sys/doc/sam/sam.pdf

[2] http://doc.cat-v.org/bell_labs/structural_regexps/se.pdf

[prunebeads]

I mean for instance changing the name of a value across multiple files, or fixing calls of a function whose prototype had been modified. That sort of things.

There are other services that an IDE can provide:

- name completion

- list of variables in current scope

- list of visible types

- access to documentation

- code annotation

All these could be implemented in external tools, but how snappy would the interface be?

The filter paradigm of Unix is great for batch processing, but fails when used interactively, unless processi are lightened to the point of becoming almost like threads within the same process, and with the matching communication speed (inter process communication using pipes isn't really that fast compared to shared memory).

That said, maybe large scale programs are the problem to begin with. With simple, one task focused programs, source code becomes easy to maintain without resorting to the services I listed above. It's not easy to get rid of them though (consider compilers for instance).

[4ad]

> I mean for instance changing the name of a value across multiple files, or fixing calls of a function whose prototype had been modified.

This is trivial in sam and acme because of the sam command language and structural regular expressions. See the links in my previous post. In fact not only that it's easy, I haven't yet found any alternative environment where the operation is so powerful. A few days ago I used sam to extract all structs in the Go tree that use a map but not a mutex, or structs that use the first ones and don't have a mutex either. I only cared about a select/find operation, but I could have paired it with a modify operation that could have added the mutex, for example. The scope and power of the language is unmatched.

> name completion

Personally I think it's worthless (and so do most acme users I know) but it's easy to implement as an external program. Jason Catena did it in one of his Inferno labs.

> list of variables in current scope

One sam command away.

> list of visible types

Same, or use Go.

> access to documentation

Right click on identifiers if you have plumber configured.

> code annotation

No idea what this is.

> inter process communication using pipes isn't really that fast compared to shared memory

Actually, it is. There are very few programs in the world where pipe throughput is not enough.

[prunebeads]

Great! How does a novice like me get his system setup to work with C++, lisp, javascript, or PHP? Do I need to write my own plumbing? Is there repositories of conf files for acme/sam (at least to have some examples to get inspiration from)? I'd like to try.

I don't program in Go btw.

> Actually, it is. There are very few programs in the world where pipe throughput is not enough.

I am very surprised by this. I always thought that programs made of threads were much faster than groups of processi, which have to communicate through OS channels, rather than a common memory space. Maybe I wasn't considering the fact that interactive programs have a lot of time to spare.

Usually, I expect my interactive programs to be snappy when I ask them something, even if I don't do it often at the CPU timescale. That's the real catch in user interaction.