On Nov 8, 1:40 pm, p...@informatimago.com (Pascal J. Bourguignon) wrote:
> What you don't understand, is that emacs is not a mere application > running on MacOSX or on MS-Windows or on Linux.
> emacs is actually an operating system, with its own window manager, and > it's own consistent user interface.
> It just happens that nobody makes the hardware to run the emacs OS > anymore. It was the LispMachines. So it has to run as a virtual > machine (ever since it was conceived, admitedly and regretably).
Come on, Pascal, this is a bit of a stretch. Emacs is an Emacs Lisp interpreter, no more than that. I see your point though.
> When you run MS-Windows in a virtual machine on MacOSX, you don't > complain that it doesn't respect the MacOSX User Interface Guidelines!
> And when you run MS-Windows in a virtual machine on Linux, you don't > complain that it doesn't do things like normal unix applications!
If I were to use an application on a virtual machine heavily, I would look for ways to shape the hosted environment like the hosting one. I run Windows at work, Linux at home, and I strive to get a consistent environment. Luckily, Gnome shares the same idea about CUA.
I like the idea of Eshell as shell. I'll give it a spin.
> Now, for example, I don't like the MS-Windows system, so I don't use it. > If you don't like the emacs system, you can just forget it and don't use > it ever.
No, Pascal. Real world is different. I don't like the MS-Windows system, but I make a living out of it, thus I'm using it. I think Emacs has warts, but there's nothing better out there, therefore I work around them.
> > I think an easy solution exists. First, here is a one liner for each > > binding:
> This is something for you to do, not for the reference distribution of > emacs.
Why? Novices are more likely to flock to the reference distribution, thus it would be better if helpful directions were given there.
> And as I mentionned, it's free software, you are even free to make your > own distribution of emacs.
That's never going to happen. I dislike distributions. IMO, they either show a weakness into the extendibility of a system or a weakness into the supporting community.
> > I've answered already I agree on this. I think the only fix to this > > is a preamble to Emacs' manual.
> What could be added in the preamble if it's not already there, is what > all emacser knows very well even if it's not often mentionned in public, > is that emacs is an OS running on a VM, and it would be nice if Intel, > AMD, or some other founder woud make a LispMachine processor again. > With some microprogramming, it could even be made to run as well > LispMachine microcode as JVM as a few others similar 'V'Ms.
If Lispers teamed up to make Lisp Machines a worthwhile platform, manufacturers would resurrect Lisp machines, no doubt. This is never going to happen, however, since Lispers seem more worried about their keybindings than about - God forbid! - Lisp becoming mainstream. Nothing wrong with that, mind you. Just let's not kid ourselves things are different.
> > What about having different starting points users can improve on? At > > least for keybindings, we are already there: there are vanilla Emacs, > > vanilla Emacs + CUA, Viper + Vimpulse, ErgoEmacs...
Elena <egarr...@gmail.com> writes: > On Nov 8, 1:40 pm, p...@informatimago.com (Pascal J. Bourguignon) > wrote: >> What you don't understand, is that emacs is not a mere application >> running on MacOSX or on MS-Windows or on Linux.
>> emacs is actually an operating system, with its own window manager, and >> it's own consistent user interface.
>> It just happens that nobody makes the hardware to run the emacs OS >> anymore. It was the LispMachines. So it has to run as a virtual >> machine (ever since it was conceived, admitedly and regretably).
> Come on, Pascal, this is a bit of a stretch. Emacs is an Emacs Lisp > interpreter, no more than that. I see your point though.
Study the history!
>> When you run MS-Windows in a virtual machine on MacOSX, you don't >> complain that it doesn't respect the MacOSX User Interface Guidelines!
>> And when you run MS-Windows in a virtual machine on Linux, you don't >> complain that it doesn't do things like normal unix applications!
> If I were to use an application on a virtual machine heavily, I would > look for ways to shape the hosted environment like the hosting one. I > run Windows at work, Linux at home, and I strive to get a consistent > environment. Luckily, Gnome shares the same idea about CUA.
You should strive to make MS-Windows more like emacs.
> Why? Novices are more likely to flock to the reference distribution, > thus it would be better if helpful directions were given there.
Depend on the novice. I would have been the kind of novice who would have used the reference distribution, to be sure to be learning the true emacs way, as a long-term investment. I would hate to learn emacs with some massacred keybinding, that I would have to relearn once I switch to the real thing.
>> Why don't you try Emacs.app or Aquamacs.app?
> Because they are not GNU Emacs.
Yes, they are. Emacs.app compiles directly from gnu sources. And aquamacs is basically gnu emacs, with a custom site-start.el
> > If I were to use an application on a virtual machine heavily, I would > > look for ways to shape the hosted environment like the hosting one. I > > run Windows at work, Linux at home, and I strive to get a consistent > > environment. Luckily, Gnome shares the same idea about CUA.
> You should strive to make MS-Windows more like emacs.
Indeed I could. However, the other way around is easier. If I were to make MSW behave like some editor, I would prefer it Vi-like.
> > Why? Novices are more likely to flock to the reference distribution, > > thus it would be better if helpful directions were given there.
> Depend on the novice. I would have been the kind of novice who would > have used the reference distribution, to be sure to be learning the true > emacs way, as a long-term investment. I would hate to learn emacs with > some massacred keybinding, that I would have to relearn once I switch to > the real thing.
You would not: "GNU Emacs is an extensible, ***customizable*** text editor...". Once you have learned it, customizing it is a breeze. The hurdle is learning it, that's why novices should have it easier (without hurting power users).
> >> Why don't you try Emacs.app or Aquamacs.app?
> > Because they are not GNU Emacs.
> Yes, they are. Emacs.app compiles directly from gnu sources. > And aquamacs is basically gnu emacs, with a custom site-start.el
Elena <egarr...@gmail.com> writes: > On Nov 8, 1:40 pm, p...@informatimago.com (Pascal J. Bourguignon) > > It just happens that nobody makes the hardware to run the emacs OS > > anymore. It was the LispMachines. So it has to run as a virtual > > machine (ever since it was conceived, admitedly and regretably).
> Come on, Pascal, this is a bit of a stretch. Emacs is an Emacs Lisp > interpreter, no more than that. I see your point though.
It a slight stretch because Emacs predated the Lisp machines: it ran first on ITS, and next (I think) on Multics. But the Lisp machine versions, EINE and ZWEI were highly influential.
> > When you run MS-Windows in a virtual machine on MacOSX, you don't > > complain that it doesn't respect the MacOSX User Interface Guidelines!
> > And when you run MS-Windows in a virtual machine on Linux, you don't > > complain that it doesn't do things like normal unix applications!
> If I were to use an application on a virtual machine heavily, I would > look for ways to shape the hosted environment like the hosting one.
I think that's a serious mistake. Firstly, tools inevitably come with a preconceived notion about how they're meant to be used: trying to use them otherwise is often difficult, requiring more skill and knowledge than you'd need if you conformed to the tools' worldview; and more likely than not prevents you from using the tools to their fullest potential. Secondly, it blurs the boundaries between things which are best kept separate: a virtual machine is distinct from its host, and if you don't keep that in mind, you will get a nasty surprise when you come across one of the essential differences.
> I run Windows at work, Linux at home, and I strive to get a consistent > environment. Luckily, Gnome shares the same idea about CUA.
I always thought that adopting conventions from Windows was a mistake in Gnome. In particular, they missed an opportunity to popularize Emacs keybindings and conventions. (Why should we have a clipboard when we could have a kill ring?)
> > Now, for example, I don't like the MS-Windows system, so I don't use > > it. If you don't like the emacs system, you can just forget it and > > don't use it ever.
> No, Pascal. Real world is different. I don't like the MS-Windows > system, but I make a living out of it, thus I'm using it.
You get to choose how you make a living. Besides, if you dislike it so much, why are you trying to make Emacs mould itself to the Windows way of working rather than the other way around? ;-)
> Why? Novices are more likely to flock to the reference distribution, > thus it would be better if helpful directions were given there.
Why is it good that novices flock to anything? Popularity and quality aren't well correlated. Windows is awful: much of the awfulness is actually because it's trying to meet the requirements of an enormous number of unskilled users.
> If Lispers teamed up to make Lisp Machines a worthwhile platform, > manufacturers would resurrect Lisp machines, no doubt. This is never > going to happen, however, since Lispers seem more worried about their > keybindings than about - God forbid! - Lisp becoming mainstream.
I think becoming mainstream would be one of the worst things that could possibly happen to Lisp! All the people who currently can only write Java because they're copying `design patterns' out of a book, trying to use Lisp? Ugh.
m...@distorted.org.uk (Mark Wooding) writes: > Elena <egarr...@gmail.com> writes:
>> On Nov 8, 1:40 pm, p...@informatimago.com (Pascal J. Bourguignon) >> > It just happens that nobody makes the hardware to run the emacs OS >> > anymore. It was the LispMachines. So it has to run as a virtual >> > machine (ever since it was conceived, admitedly and regretably).
>> Come on, Pascal, this is a bit of a stretch. Emacs is an Emacs Lisp >> interpreter, no more than that. I see your point though.
> It a slight stretch because Emacs predated the Lisp machines: it ran > first on ITS, and next (I think) on Multics. But the Lisp machine > versions, EINE and ZWEI were highly influential.
AN emacs predated the Lisp machines.
But GNU emacs was started after the experience RMS had with Lisp machines.
>> If I were to use an application on a virtual machine heavily, I would >> look for ways to shape the hosted environment like the hosting one.
> I think that's a serious mistake. Firstly, tools inevitably come with a > preconceived notion about how they're meant to be used: trying to use > them otherwise is often difficult, requiring more skill and knowledge > than you'd need if you conformed to the tools' worldview; and more > likely than not prevents you from using the tools to their fullest > potential. Secondly, it blurs the boundaries between things which are > best kept separate: a virtual machine is distinct from its host, and if > you don't keep that in mind, you will get a nasty surprise when you come > across one of the essential differences.
Indeed.
>> I run Windows at work, Linux at home, and I strive to get a consistent >> environment. Luckily, Gnome shares the same idea about CUA.
> I always thought that adopting conventions from Windows was a mistake in > Gnome. In particular, they missed an opportunity to popularize Emacs > keybindings and conventions. (Why should we have a clipboard when we > could have a kill ring?)
And as an alternative, you can run X on all these systems, and use emacs X11 on all of them, with exactly the same user interface, down to the key bindings.
Or, you could run a MS-Windows in a VM and with vnc have the MS-Windows experience on either Linux or MacOSX.
Unfortunately, for the MacOSX experience, you will have to buy a Macintosh, but otherwise, you can do similarly.
>> No, Pascal. Real world is different. I don't like the MS-Windows >> system, but I make a living out of it, thus I'm using it.
> You get to choose how you make a living. Besides, if you dislike it so > much, why are you trying to make Emacs mould itself to the Windows way > of working rather than the other way around? ;-)
>> Why? Novices are more likely to flock to the reference distribution, >> thus it would be better if helpful directions were given there.
> Why is it good that novices flock to anything? Popularity and quality > aren't well correlated. Windows is awful: much of the awfulness is > actually because it's trying to meet the requirements of an enormous > number of unskilled users.
This must be repeated.
"Much of the awfulness is actually because it's trying to meet the requirements of an enormous number of unskilled users."
>> If Lispers teamed up to make Lisp Machines a worthwhile platform, >> manufacturers would resurrect Lisp machines, no doubt. This is never >> going to happen, however, since Lispers seem more worried about their >> keybindings than about - God forbid! - Lisp becoming mainstream.
> I think becoming mainstream would be one of the worst things that could > possibly happen to Lisp! All the people who currently can only write > Java because they're copying `design patterns' out of a book, trying to > use Lisp? Ugh.
Elena <egarr...@gmail.com> writes: > Pascal J. Bourguignon wrote: >> Why don't you try Emacs.app or Aquamacs.app? > Because they are not GNU Emacs.
The Emacs.app project was merged into GNU Emacs some time ago.
Consequently the Emacs.app application now builds directly from unmodified GNU sources. (There are binary downloads available too.) If it's not GNU Emacs then I 'm not sure what is.
On Nov 11, 11:14 am, m...@distorted.org.uk (Mark Wooding) wrote:
> > If I were to use an application on a virtual machine heavily, I would > > look for ways to shape the hosted environment like the hosting one.
> I think that's a serious mistake. Firstly, tools inevitably come with a > preconceived notion about how they're meant to be used: trying to use > them otherwise is often difficult, requiring more skill and knowledge > than you'd need if you conformed to the tools' worldview; and more > likely than not prevents you from using the tools to their fullest > potential.
I don't understand how this relates to keybindings. Binding "C-c" for yanking and remapping "C-c" prefix to something else, in my opinion doesn't make Emacs any less powerful. It seems I'm the only Emacs user here which doesn't bind Emacs' power to its keybindings.
> Secondly, it blurs the boundaries between things which are > best kept separate: a virtual machine is distinct from its host, and if > you don't keep that in mind, you will get a nasty surprise when you come > across one of the essential differences.
Yeah, I know the Law of Leaky abstractions. I got such a nasty surprise when I tried SSHing from Emacs on Windows.
> > I run Windows at work, Linux at home, and I strive to get a consistent > > environment. Luckily, Gnome shares the same idea about CUA.
> I always thought that adopting conventions from Windows was a mistake in > Gnome. In particular, they missed an opportunity to popularize Emacs > keybindings and conventions. (Why should we have a clipboard when we > could have a kill ring?)
And why should we have a kill ring when we could have both? I think the real mistake is not giving users choice. Do they like Emacs' bindings? Let them have their way. Do they like CUA? Let them have their way.
> > > Now, for example, I don't like the MS-Windows system, so I don't use > > > it. If you don't like the emacs system, you can just forget it and > > > don't use it ever.
> > No, Pascal. Real world is different. I don't like the MS-Windows > > system, but I make a living out of it, thus I'm using it.
> You get to choose how you make a living.
Where there's muck there's brass, they say.
> Besides, if you dislike it so > much, why are you trying to make Emacs mould itself to the Windows way > of working rather than the other way around? ;-)
Because it's more practical to mold a single application than a ton of applications on two operating systems, you know. Moreover, as I've stated already, I'm not fussy about keybindings, provided they stay the same across applications. Have I told enough times that I prefer modal over modeless editing? Yeah, it has its learning curve, but it's totally worth the effort. I fail to be mesmerized by the empowerment of using "C-y" instead of "C-c", though.
> > Why? Novices are more likely to flock to the reference distribution, > > thus it would be better if helpful directions were given there.
> Why is it good that novices flock to anything? Popularity and quality > aren't well correlated.
They aren't always uncorrelated, either.
> Windows is awful: much of the awfulness is > actually because it's trying to meet the requirements of an enormous > number of unskilled users.
Windows has more merits than you think. You have to see through the skin.
> > If Lispers teamed up to make Lisp Machines a worthwhile platform, > > manufacturers would resurrect Lisp machines, no doubt. This is never > > going to happen, however, since Lispers seem more worried about their > > keybindings than about - God forbid! - Lisp becoming mainstream.
> I think becoming mainstream would be one of the worst things that could > possibly happen to Lisp!
Yeah, maybe because then all of its shortcomings would become blindingly clear ^_^
Moreover, companies could jump at the opportunity of building Lisp machines again, and that would be awful indeed, wouldn't it? We love the Intel platform so much, don't we?
> All the people who currently can only write > Java because they're copying `design patterns' out of a book, trying to > use Lisp? Ugh.
We can bitch about Java how much we want, but being mainstream has made the JVM the most stable and performant VM out there.
> It a slight stretch because Emacs predated the Lisp machines: it ran > first on ITS, and next (I think) on Multics. But the Lisp machine > versions, EINE and ZWEI were highly influential.
I'm pretty sure that EINE was the first Emacs whose implementation language was Lisp - the older ones were (all?) TECO-based. And EINE I assume ran on the CONS or the CADR?
> Moreover, companies could jump at the opportunity of building Lisp > machines again, and that would be awful indeed, wouldn't it? We love > the Intel platform so much, don't we?
I don't love Intel systems, but it's really quite important to avoid the romanticisation of Lisp machines (which is unfortunately prevelant on CLL as I expect followups to this article will now demonstrate).
On Nov 11, 12:55 pm, Elena <egarr...@gmail.com> wrote:
> We can bitch about Java how much we want, but being mainstream has > made the JVM the most stable and performant VM out there.
Not to mention how rich the Java SDK API is and how much battle-tested the Java platform as a whole is. But we would hate having these features into our Lisp systems, wouldn't we? Much more fun hunting for libraries and scavenging for scraps of code.
Tim Bradshaw <t...@tfeb.org> writes: > I'm pretty sure that EINE was the first Emacs whose implementation language > was Lisp - the older ones were (all?) TECO-based. And EINE I assume ran on > the CONS or the CADR?
Hmm. According to http://www.multicians.org/mepap.html, Multics Emacs was implemented in Multics MacLisp; implementation started in March 1978. Wikipedia says that Weinreb's thesis on EINE was published in January 1979. The Emacs wiki page on Multics Emacs (http://www.emacswiki.org/emacs/MulticsEmacs) says that it was the first to use Lisp as an extension language.
Tim Bradshaw <t...@tfeb.org> writes: > I'm pretty sure that EINE was the first Emacs whose implementation > language was Lisp - the older ones were (all?) TECO-based. And EINE I > assume ran on the CONS or the CADR?
FINE (Fine Is Not Emacs), which was one of the first Emacsen I used (in 1981 or -82), was written in BLISS-10, which I guess was a quite common language back then.
Elena <egarr...@gmail.com> writes: > We can bitch about Java how much we want, but being mainstream has > made the JVM the most stable and performant VM out there.
On 2010-11-11 15:01:03 +0000, Pascal J. Bourguignon said:
> Isn't it what we would want for Lisp?
I suspect it's not. The JVM may be universal and all but how many instances of it are running on your machine right now? I checked my laptop and the answer is 0 (and I write stuff in Java relatively frequently).
So, well, Java's failed on the desktop/laptop, I guess we know that. For servers, well, there's a lot of it about of course, but it seems to me that virtualised x86 systems are now so common that you would not lose much by just targetting x86 (and of course we have a load of good x86-targetting CL systems).
I suppose the argument might be that you get all the good libraries that come with the JVM, and that might be a good argument, so long as the impedance mismatch from Lisp is not too high.
(And I guess another important market is going to be Android, which is at least Javaoid).
On Nov 11, 4:18 pm, Tim Bradshaw <t...@tfeb.org> wrote:
> So, well, Java's failed on the desktop/laptop, I guess we know that. > For servers, well, there's a lot of it about of course, but it seems to > me that virtualised x86 systems are now so common that you would not > lose much by just targetting x86 (and of course we have a load of good > x86-targetting CL systems).
> I suppose the argument might be that you get all the good libraries > that come with the JVM, and that might be a good argument, so long as > the impedance mismatch from Lisp is not too high.
> (And I guess another important market is going to be Android, which is > at least Javaoid).
On Nov 11, 5:18 pm, Tim Bradshaw <t...@tfeb.org> wrote:
> The JVM may be universal and all but how many > instances of it are running on your machine right now? I checked my > laptop and the answer is 0 (and I write stuff in Java relatively > frequently).
How do you know? Java applications can be packaged in a native executable (Eclipse comes to mind). They can even "disguise" themselves by using native GUIs (again, Eclipse comes to mind).
> How do you know? Java applications can be packaged in a native > executable (Eclipse comes to mind). They can even "disguise" > themselves by using native GUIs (again, Eclipse comes to mind).
Java is not being used to write most commercial apps like Quicken or mainstream free apps like browsers or OpenOffice. I believe those are almost all C++. But I don't think it has failed on the desktop for internal apps inside corporations. At least I have seen it being used to write corporate desktop business and scientific GUI apps. Developers appear to find it easier to use than C++ on Windows with MFC or C++ on Unix with Motif. However, there are newer GUI library alternatives, most notably QT, with increased functionality and ease of use over Motif/MFC, and that may be influencing corporate GUI desktop app development to the benefit of C++.
TheFlyingDutchman <zzbba...@aol.com> writes: > Java is not being used to write most commercial apps like Quicken or > mainstream free apps like browsers or OpenOffice.
Incorrect for OpenOffice. That is a Java project.
-- Thomas A. Russ, USC/Information Sciences Institute
> > Java is not being used to write most commercial apps like Quicken or > > mainstream free apps like browsers or OpenOffice.
> Incorrect for OpenOffice. That is a Java project.
I was under that same impresssion. Some years ago I told someone that I thought Eclipse was slow but that OpenOffice - "another Java app" - seemed to have good performance. But when I later looked to verify it was a Java app I found out it is not a Java project:
Contribute to a core module Core components are written in C++. If you know C++ you can start by finding the project or component that interests you. Join that project's mailing list and introduce yourself. You will probably need to familiarize yourself with the Developers Guide.
Java is required for complete OpenOffice.org functionality. Java is mainly required to use the new embedded Java technology based HSQLDB database engine, or to make use of accessibility and assistive technologies. If you do not require database tables or accessibility integration or some wizards, then you do not need to download and install Java. Base (the database component) for example completely relies on Java technologies to run, but other programs (like Writer, Calc, and Impress) only need Java for special functionality (see below).
