3 ms·
> 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 s
by 4ad 14y ago
> 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 14y agoGreat! 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.