Also I don't quite get his desire to "live in" some giant all-in-one software package. I think it should be obvious now that Unix philosophy of many little specialized tools proved to be more flexible than uber-environments.
I am not sure if anybody here remembers, but back in the early 90 people believed that "future belongs to integrated environments", that's right - to IDEs and not just for programming. And now he's talking same thing again.
For those working for a web-services company (or living in SV these days) it may be natural to think that "everything is in the browser".
But is it? I still can hear PG's voice from Startup School in my ears: "Stop using the Internet please, my presentation won't open!"
I've found that the specialized tools philosophy to be effective when building a, well a toolkit. Toolkits, if done well, are extensible and interoperable in ways that no 'integrated' system can be. However, There is a certain class of problem that doesn't really lend itself to the toolkit approach. This is the interface problem.
Vim is an awesome text editor, it is streamlined in a way most editors could only dream of. It's a very good text editor. Python is a very good language. One of it's nice features is that it comes with a REPL, so I can program in it interactively. Using a third program Screen, I run both side-by-side and pipe content between them. This is the toolkit at work, and it works very well.
However, there is a slight problem here. Each of these programs has a different interface design. Each has a separate key-binding scheme and different schemes collide. You have to learn three different interfaces and learn them well, to do this effectively. It would be nice if there was a program, similar to screen, that would stand between you and the editor and interpretor and allow you rebind and customize your keys and view ports so that they don't collide and are consistent. This program is emacs. It is the universal interface, a more flexible bash than bash, and people stay in it all day, not because they don't use toolkits, but because they prefer to use it to interface with toolkits rather than bash or some ill-conceived X monstrosity.
Emacs doesn't replace cvs/git, ls, grep, awk, gdb, gcc, python, rbi, cron... It mostly just provides a very powerful scriptable interface to all of them.
> Also I don't quite get his desire to "live in" some giant all-in-one software package. I think it should be obvious now that Unix philosophy of many little specialized tools proved to be more flexible than uber-environments.
Emacs isn't one giant software package. It's a lot of small, specialized tools (functions) working together. It's one executable in your operating system, but that doesn't mean that it can't be modular inside.
There's specific stuff in the article about this. Emacs is much more discoverable than your average IDE. It is much easier to write plugins. You don't have to bow to the gods to get a working, documented interface (see the Stevey post just before when he tries to implement focus-follows-mouse in an OS X accessibility API which is basically undocumented and, fatally, doesn't work as advertised in its comments).
Here's another way to think about it: cobbling together myriad programs at the terminal and getting them to talk is an ad hoc, informally-specified, bug-ridden, slow implementation of half of GNU Emacs. Like it or not, you're going to work in some kind of environment, so it might as well give you awesoma powah in every window you open.
The concept of living in emacs makes more sense when you think of it as an operating environment in its own right, and not just another application. You can think of emacs as a framework (that happens to be awesome for manipulating text by hand, and at least adequate at doing it in an automated manner) upon which a wide variety of tools, or, if you will, apps, have been built.
The tools vary considerably in size and in how well they integrate with each other. Often the tools can be swapped in and out according to your preferences or needs: different in implementation but quite similar in spirit to the do one thing and do it well aspect of the Unix philosophy.
I was most intrigued by the thought of code editing as a serious part of Firefox. I don't know much about XUL, so I will need to read up, but I thought it would be quite sexy if I built an editor which binds to Heroku using the API. A local code editor extensible via javascript that works directly against the remote in-cloud data would be a pretty swift alternative to the Git approach.
Honestly I'm a fan of good old gedit... but this makes a good case for trying emacs one more time.
I haven't really understood the appeal of the single, monolithic, do-everything editor up until this point, but looking at it from a self-modifying point of view does make it somewhat more appealing (and I need time to ingrain the key chords into muscle memory and learn some elisp).
I think the exciting idea was that of a the browser-as-editor. Where is the browser that acts as an editor and has all it's plugins written in javascript (as opposed to elisp)? Of course, once we had that, the next goal would be to replace bash with it... browser as terminal ftw.
FWIW, Elisp is much nicer than JavaScript. It could stand to gain some features like static scoping and threading, but the "library" is so useful it's easy to ignore the linguistic flaws.
I'm sure an emacs-in-JavaScript would also have a good library, but let's face it... Lisp is very enjoyable to use. There may be more JavaScript programmers than Lisp programmers... but the same could be said for PHP, and I don't think anyone wants a PHPmacs :)
But you said in another comment here that you are an elisp developer... of course you are going to think it's nicer.
I'm not married to the javascript idea, I just suggested that because it's already used for a ton of other things in the browser, so it'd make sense to make the browser-as-editor extensible in javascript.
If we really want to make it from the ground up, it'd be nice if we could replace javascript with something like Scheme[1] (or Arc ;) as the de-facto client-side scripting-language in the browser.
My issue with doing it in elisp is that it's yet another special purpose language to use, and the web already requires three or four of them to get anything done as it is. I'm not scared of learning it, but if I am going to dream of pie-in-the-sky, I might as well dream of a world where one language gets things done on the web.
[1] I would suggest Lisp here, but honestly I got started with Scheme, and for some reason (purely aesthetic), CL just seems so ugly to me.
As an elisp developer, I would like people to stop using XEmacs also. But the thing is, it seems like most of the more experienced extension developers are using XEmacs. I'm not really sure why, since I'm only active in the GNU emacs community... but there must be some reason. (I bet not having to sign copyright papers for every 10 line patch is one.)
Once or twice a week. Did you catch the part where he said he likes to maintain perpetual sessions? When you leave apps open indefinitely, they are more prone to crash I think.
You know wxPython has a widget that can render html. It's not full featured, but I was pretty amazed by it. There's definitely a lot of potential there...
I am not sure if anybody here remembers, but back in the early 90 people believed that "future belongs to integrated environments", that's right - to IDEs and not just for programming. And now he's talking same thing again.
For those working for a web-services company (or living in SV these days) it may be natural to think that "everything is in the browser".
But is it? I still can hear PG's voice from Startup School in my ears: "Stop using the Internet please, my presentation won't open!"