Not only does it lack them, there is a huge amount of resistance to porting them because they are 'against the spirit of plan 9' or something to that effect. Which increases the barrier to entry.
I'm a huge fan of the principles behind Plan9 but I've never done much more with it than install it, play around with it for a bit, read documentation and newsgroups on what makes it tick. Other than that I've de-installed it... And I would probably use it, maybe even on a (light) production box to see how well it would fare in real life given a chance.
But the amount of stuff that is missing compared to vanilla unix makes that a non-starter.
No one is stopping you from porting whatever you please. All you have to do is sit down and do it. If I had to guess, I'd say that the main barrier you face is that you de-installed it.
It should not be too hard for people to write utilities to fortify what Plan9 offers, if they know what to write. But it's a chicken-egg problem to write utilities if nobody uses the platform. Is it a dead cause?
Converting many of the tools used by the Unix hackerdom is made rather difficult by two aspects:
* Plan 9's approach on terminal is entirely decoupled from the TTY idea. The terminal is basically a program that takes commands, has a shell run them, and pipes back the result, with none of the VT-whatever stuff. Even getting ncurses-based tools to run would require some effort.
* There's no X11
There are some graphical tools for Plan 9 (including more or less barebones web browsers), but there is just enough difference from Linux and BSD environments that people aren't quite willing to cope with it.
Good point. I sort of lost contact with the Plan 9 world a while ago -- I kept following the news, but no longer ran a system. Last time I used it, the X11 port was somewhere between experimental and broken, and vim is, uhm, not the editor whose port I'd be interested in :-). My comment is certainly not up-to-date.
Edit: I share your point about the lack of need for either ncurses or vim (especially vim, hheheh). My first contact with Plan 9 was somewhat disappointing, mainly due to the fact that I approached it with the oh, Unix, I know this! frame of mind. I was very much a Linux fanboy back then (did I mention it was in highschool? And this is not the dumbest thing I did in highschool!). Only after I studied the source code a little, and learned rc more seriously, did I really begin to appreciate it.
None of which are likely to happen, I'd point out, because vim, emacs, bash and zsh are all tied into some sort of notion of a virtual terminal with software controlled cursors, etc etc etc. Plan 9's TTY is astoundingly primitive by those standards; essentially it emulates a line printer but doesn't even have the good grace to allow backspacing. Oddly, said terminal exposes the contents of the scrollback buffer—both read and write—to a file, which is how the native Plan 9 history mechanisms work. This is entirely deliberate, of course, and a substantial part of what makes the system so different and interesting, but step #1 to porting those would involve reinventing xterm, basically.
In theory for vim and emacs you could work around that by using the graphical interface, much as say Acme does. I would estimate this to be at least as much work as porting from X11 to, say, Cocoa was, and possibly even worse. And this port would only get you a vim or an emacs that was materially identical to its Unix counterpart—no Acme style control FS and essentially no cooperation with the normal Plan 9 UI elements.
That's quite a load of legacy baggage. If your first reaction to a new system is "how do I get my old environment?", you may be missing the point. You need two shells, two editors, and a specific (gigantic!) compiler?
There's a vi for Plan 9 (even skipping the old joke about the MIPS interpreter...). I think it's vim, but I haven't paid much attention. David Hogan did a gcc port, and mostly nobody cared so it languished.
Plan9 can probably gain traction in something completely different than workstations or even servers, more like embedded or highly specialized devices. Just like a lot of people say, often one needs single killer app.
I'm always interested to hear opinions from Acme/Sam users. While these "editors" have some unique features, don't you find annoying the lack of basic code completion and syntax highlighting?
Don't you find annoying the lack of built-in file browser and powerful regex-based transformation language?
Don't you find annoying the lack of quick access to search/navigate/execute/copy-paste mechanics via mouse click?
In Acme, all text is hypertext. The difference between Acme and previous generation editors (Vim, EMACS etc.) is like between The Web and a library of paper books.
> Don't you find annoying the lack of quick access to search/navigate/execute/copy-paste mechanics via mouse click?
Yes, which is why I've written some acme emulation for vim twice. (Incidentally, I was working on that yesterday before this link was posted: https://github.com/fmoralesc/plan9-for-vimspace I have to improve the button 2 functionality, and chords are still not supported, but I'm on it. A plumbing system is planned, although I'm not sure if its best to reuse plan9port's plumber or reimplement it.)
> In Acme, all text is hypertext.
Exactly. Which is why, even though I am a serious vim junkie, I love acme so much.
Not at all. I find syntax highlighting awful for actual programming (it's sort of useful for the first few days of learning a new language). It makes code less readable, and encourages some of the worst practices of programming. People have written tons about this. At its best, it's a crutch.
I think code completion is more of a mixed bag. It's useful when you're stuck in ugly environments with FrameworksAndLibraries[withFunctionsLikeThese], but I just avoid those environments.
Also, people have built external commands that do code completion. They're not as nicely integrated, but could be improved enough to be quite comfortable, if that's what you're after. (syntax highlighting couldn't ever really work in acme or sam)
