for some reason I can't use the arrow keys when using the cmucl or sbcl
interpreters, i just get ^[[A (up arrow) or ^[[C (right arrow) etc..
Is this a problem with the terminal program?
BTW I am using linux,
Thanks in advance.
P.S. any tips for using vim to edit common lisp code?
From: Maciek Pasternacki
Subject: Re: arrow keys in sbcl or cmucl interpreter
Date:
Message-ID: <87iryi4oaw.fsf@lizard.king>
On Prickle-Prickle, Confusion 73, 3171 YOLD, Ido Yehieli wrote:
> for some reason I can't use the arrow keys when using the cmucl or sbcl
> interpreters, i just get ^[[A (up arrow) or ^[[C (right arrow) etc..
>
> Is this a problem with the terminal program?
It's normal, cmucl and sbcl use plain stdio, without any control
features or line editor. You can use external linedit package to get
line-editing (it can be used as sbcl top-level REPL).
--
__ Maciek Pasternacki <·······@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ETERNITY: He who binds to himself a joy / Does the winged
,|{-}|}| }\/ life destroy; / But he who kisses the joy as it flies / Lives in
\/ |____/ eternity's sun rise. } ( William Blake ) -><-
···········@gmail.com writes:
> for some reason I can't use the arrow keys when using the cmucl or sbcl
> interpreters, i just get ^[[A (up arrow) or ^[[C (right arrow) etc..
>
> Is this a problem with the terminal program?
No.
> BTW I am using linux,
> Thanks in advance.
>
> P.S. any tips for using vim to edit common lisp code?
Yes: use emacs!
By the way, arrows work inside emacs.
If you don't want to use emacs, switch to clisp, which uses readline.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Grace personified,
I leap into the window.
I meant to do that.
From: Edi Weitz
Subject: Re: arrow keys in sbcl or cmucl interpreter
Date:
Message-ID: <uy87ent1o.fsf@agharta.de>
On 6 Aug 2005 16:21:34 -0700, ···········@gmail.com wrote:
> for some reason I can't use the arrow keys when using the cmucl or
> sbcl interpreters, i just get ^[[A (up arrow) or ^[[C (right arrow)
> etc..
You can use something like rlwrap as a workaround:
<http://weitz.de/completions.html>
> P.S. any tips for using vim to edit common lisp code?
You should really learn Emacs. This is not about the usual Emacs/vi
flamewar, it's just that Emacs is by tradition the editor that has by
far the best support for Lisp. If you've been using Lisp for a while
you'll realize that it's not only about /editing/ Lisp program but
about using Emacs as an IDE for your Lisp. Check out SLIME
<http://common-lisp.net/project/slime/>
or use the Emacs clone of one of the commercial Lisps, e.g.
<http://www.lispworks.com/>.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
I think it's worth mentioning the SLIME video. If you don't know much
about SLIME, download it and be both awed and enlightened:
Please use this link if possible:
<http://common-lisp.net/movies/slime.torrent>
If you can't use BitTorrent, it can be downloaded from
<http://common-lisp.net/movies/slime.mov>
-Peter
i have seen the frist couple of minutes, and browsed through the rest.
seems far too complicated...
this is kind of what also bothers me with emacs and vi: why is it not
working the way 99% of my apps are? i.e. using the common UI
keybindings (that's the most important one). I don't want to learn a
new UI for each program I run, I'm lazy- i want it to function as I
expect it to function (like most of my apps - eclipse, mozilla,
open-office, gaim, all the [kde|gnome] apps etc. all basicly use the
same UI style). </rant>
Emacs predates the rest of your apps, and over the years many people
have become so productive with its key bindings that changing them
would immediately provoke an angry outcry (not to mention that you'd
have to remap hundreds, maybe thousands, of key bindings just to have
normal cut, copy, paste, and undo key bindings).
Despite the learning curve, I still recommend emacs because once you
get some level of skill, it becomes the finest text editor you've ever
used. An emacs master is generally dependent on it like a crack addict.
Personally, I've often been annoyed that the rest of my programs didn't
use basic emacs key bindings for text editing.
-Peter
···········@gmail.com writes:
> i have seen the frist couple of minutes, and browsed through the rest.
> seems far too complicated...
> this is kind of what also bothers me with emacs and vi: why is it not
> working the way 99% of my apps are? i.e. using the common UI
> keybindings (that's the most important one).
emacs was there before MacOS or MS-Windows. It's MacOS and MS-Windows
applications that are working with strange key bindings. You should
ask your vendors to use emacs key bindings which are the established
common UI.
By the way, NeXTSTEP DID use emacs key bindings, as can easily be
verified in Text.app (that's thanks to NeXTSTEP that I transitionned
to the wrong MacOS keybindings to the historically correct emacs key
bindings :-) And it still does, under the name of MacOSX as can be
seen in TextEdit.app or Mail.app for example. Since MacOS doesn't
exist anymore, I'd say: emacs: 1 - other: 0
> I don't want to learn a
> new UI for each program I run, I'm lazy- i want it to function as I
> expect it to function (like most of my apps - eclipse, mozilla,
> open-office, gaim, all the [kde|gnome] apps etc. all basicly use the
> same UI style). </rant>
If you were as lazy as I am, you'd just learn emacs and be done forever.
All applications exist in emacs: web, ftp, email, editing compiling,
terminal emulators, debugging, word processors, games, speach
synthesis, you name it, all under one coherent key binding system.
Just forget the lesser environments and switch definitively and
comprehensively to emacs:
http://www.informatimago.com/linux/emacs-on-user-mode-linux.html
--
"Indentation! -- I will show you how to indent when I indent your skull!"
Pascal Bourguignon wrote:
> emacs was there before MacOS or MS-Windows. It's MacOS and MS-Windows
> applications that are working with strange key bindings. You should
> ask your vendors to use emacs key bindings which are the established
> common UI.
i would suggest looking up the defenition of the words "established"
and "common".
like it or not, today the number of users using MacOS and MS-Windows
applications + linux apps that work like them out number emacs and vi
users combined by several orders of magnitude, hence making them the
"established common UI."
You can (and will) ofcourse use what ever UI you want for your
applications, but I'll take the "standart" UI that I (and the vast
majority of users) already know by heart and that is portable among
surely far more then 99% of all userland apps (number pulled out of
ass, but I'm quite sure it is true - feel free to correct me if you
think isn't).
I think one of the most important lessons of growing up is realising
that sometimes the pragmatic solution (UI parctically everyone already
know and are comfortable with) is better then the "correct" solution
(special UI almost no one knows, even though it might be more
efficiant)
</rant></offtopic>
From: Robert Uhl
Subject: Re: arrow keys in sbcl or cmucl interpreter
Date:
Message-ID: <m3br48febw.fsf@4dv.net>
···········@gmail.com writes:
>
> I think one of the most important lessons of growing up is realising
> that sometimes the pragmatic solution (UI parctically everyone already
> know and are comfortable with) is better then the "correct" solution
> (special UI almost no one knows, even though it might be more
> efficiant)
And yet you use vim:-)
Seriously, the emacs bindings grow on one--and they _are_ available in
most Unix programs, on most Mac OS X programs and so forth. And they
really are nice, esp. for editing code.
I avoided emacs for years (after an initial stint using it), but I've
really come to enjoy using it.
--
Robert Uhl <http://public.xdi.org/=ruhl>
I stopped and considered for a moment whether such a person would behave
any differently with his head cut right off, but then realized it would
make a difference: it would allow him to stand upright again.
--Anthony de Boer
···········@gmail.com writes:
> I think one of the most important lessons of growing up is realising
> that sometimes the pragmatic solution (UI parctically everyone already
> know and are comfortable with)
Which, in the context of lisp development, is emacs. Most common
lispers I know are quite pragmatic, not to mention grown up. In my
case, the pragmatic solution is to use emacs for lisp development (and
a lot of other things), and silently cope with more than one set of
user interfaces if I have to deal with these other newfangled UIs.
I find the benefits of emacs in lisp development far outweighs the
drawbacks of having to relate to more than one set of keybindings.
Reimplementing emacs with modern keybindings beyond what pc-select.el
will give you does not sound very pragmatic to me. Nor does
implementing the lisp integration features of emacs into some other
editor with a "standard UI". Expecting mainstream emacs to change to
accomodate your wish would seem plain naive, and would most likely be
actively opposed by most experienced users, let alone the
maintainers.
For emacs developers, I expect the pragmatic choice has been not to
upset the entire existing userbase by trying to be "modern".
...Peder...
--
Sl�v uten dop.
···········@gmail.com writes:
> I think one of the most important lessons of growing up is realising
> that sometimes the pragmatic solution (UI parctically everyone already
> know and are comfortable with) is better then the "correct" solution
> (special UI almost no one knows, even though it might be more
> efficiant)
I think one of the most important lessons of growing up is realizing
that sometimes it is a good idea to listen to people you ask advice
of, because presumably they know much more than you about the subject
you ask their advice about.
really, the traffic of this forum would become a quoter of what it is
today if only more people had the benefit of going through a real, as
in beating-with-a-stick-involving, apprenticeships in their formative
years.
cheers,
--m
--
Long computations which yield zero are probably all for naught.
thank you all for your advice, I didn't mean to hurt anyone (sorry Mr.
Livshin).
maybe what i said came a bit more agressive then what i meant:
I did not say "emacs sucks - you should all use editor [x|y|z] that i
like"
it was simply a rant about what bothers me _personally_ about emacs
_and vi_, and basically every program that does not act very similarly
to most other program in terms of UI.
I did not say (or mean) that emacs or vi must be altered to suit my
needs (although I thank those that pointed how it can be made so) - i
was simply complaining that i need to learn a lot of new keybinding to
use what seems to be the default editor for lisp (a statment that is
not true, for example, for java or Python).
hence the </rant> at the end...
cheers,
Ido.
···········@gmail.com writes:
> i was simply complaining that i need to learn a lot of new
> keybinding to use what seems to be the default editor for lisp (a
> statment that is not true, for example, for java or Python).
Wait a sec, isn't Emacs the default editor for Java and Python too?
;-)
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel wrote:
> ···········@gmail.com writes:
>
>> i was simply complaining that i need to learn a lot of new
>> keybinding to use what seems to be the default editor for lisp (a
>> statment that is not true, for example, for java or Python).
>
> Wait a sec, isn't Emacs the default editor for Java and Python too?
> ;-)
No, they rewrote Emacs, so that it takes 100MB memory instead of
merely 10MB. For Java, in Java. It's called Eclipse (with its
cousins Netbeans and Idea). The UI has wizards, dialogs and lots
of icons, but isn't really any better than Emacs.
--
I believe in Karma. That means I can do bad things to people
all day long and I assume they deserve it.
Dogbert
Ulrich Hobelmann wrote:
> No, they rewrote Emacs, so that it takes 100MB memory instead of
> merely 10MB. For Java, in Java. It's called Eclipse (with its
> cousins Netbeans and Idea). The UI has wizards, dialogs and lots
> of icons, but isn't really any better than Emacs.
does emacs has an equivalent to the Eclipse Visual Editor?
if not (and I assume it doesn't), then at least for creating java GUI
apps Eclipse _is_ better then emacs.
···········@gmail.com wrote:
> Ulrich Hobelmann wrote:
>> No, they rewrote Emacs, so that it takes 100MB memory instead of
>> merely 10MB. For Java, in Java. It's called Eclipse (with its
>> cousins Netbeans and Idea). The UI has wizards, dialogs and lots
>> of icons, but isn't really any better than Emacs.
>
> does emacs has an equivalent to the Eclipse Visual Editor?
> if not (and I assume it doesn't), then at least for creating java GUI
> apps Eclipse _is_ better then emacs.
Maybe. I haven't tried the Eclipse Visual Editor. I guess it
adds a few dozens MB to the RAM usage (not that that adds
unsurmountable costs to a business). For text editing I prefer
Emacs. For GUIs I much prefer (Apple) Interface Builder (to other
GUI builders I've seen at least). So far the Eclipse parts I've
tried have left me severely underwhelmed. I don't expect that
trying the Visual Editor would change anything about that.
--
I believe in Karma. That means I can do bad things to people
all day long and I assume they deserve it.
Dogbert
From: Stefan Nobis
Subject: Re: arrow keys in sbcl or cmucl interpreter
Date:
Message-ID: <87oe87d1pi.fsf@snobis.de>
Ulrich Hobelmann <···········@web.de> writes:
> Maybe. I haven't tried the Eclipse Visual Editor.
I never use visual editors, i prefer coding GUI code manually. In
all cases till now i'm at least as fast as others using a visual
editor. :)
> So far the Eclipse parts I've tried have left me severely
> underwhelmed.
One nice thing in Eclipse (for Java) is the refactoring tool. Once
i wanted to change a lot in an existing Java app. First i tried it
with emacs (and JDE), then with Eclipse. In this regard i found
Eclipse much more capable (but then: i'm a really novice with JDE
and maybe today JDE has similiar features).
Ah, and automatic generation of imports is also a nice gimmick in
Eclipse. :)
All other things, espcially writing new code, comes more handy in
Emacs (without JDE) than Eclipse for me.
--
Stefan.
On 9196 day of my life Stefan Nobis wrote:
> Ah, and automatic generation of imports is also a nice gimmick in
> Eclipse. :)
JDE can do it semiautomatically: you can ask it to import specific
class with C-c C-v z (AFAIR).
--
Ivan Boldyrev
XML -- new language of ML family.
From: Robert Uhl
Subject: Re: arrow keys in sbcl or cmucl interpreter
Date:
Message-ID: <m37jewf1y4.fsf@4dv.net>
···········@gmail.com writes:
>
> i was simply complaining that i need to learn a lot of new keybinding
> to use what seems to be the default editor for lisp (a statment that
> is not true, for example, for java or Python).
Well, it's kinda true since the best editor for Java is...emacs. And
the best editor for python is...emacs:-)
But I am perhaps biased *grin*
--
Robert Uhl <http://public.xdi.org/=ruhl>
He that would make his own liberty secure, must guard even his enemy
from oppression; for if he violates this duty, he establishes a
precedent which will reach to himself. --Thomas Paine
···········@gmail.com writes:
> thank you all for your advice, I didn't mean to hurt anyone
I don't think anyone is hurt. I was just trying to be helpful,
really, pointing out that your particular manner of receiving advice
is not conductive to you getting more advice later on.
> i was simply complaining that i need to learn a lot of new
> keybinding to use what seems to be the default editor for lisp (a
> statment that is not true, for example, for java or Python).
I really don't mean to be nasty, but you should be careful about such
unprovoked complaints in this forum. there are many old-timers here,
and in general Lisp seems to attract people who value history and
don't voice loud complaints about old things just because they are old
and unfashionable (like Lisp).
> hence the </rant> at the end...
bah. what next, *smilies*?
cheers,
--m
--
What is this talk of 'release'? Klingons do not make software
'releases.' Our software 'escapes' leaving a bloody trail of designers
and Quality Assurance people in its wake.
-- Klingon Programmer
Michael Livshin wrote:
> I really don't mean to be nasty, but you should be careful about such
> unprovoked complaints in this forum. there are many old-timers here,
> and in general Lisp seems to attract people who value history and
> don't voice loud complaints about old things just because they are old
> and unfashionable (like Lisp).
advice accepted.
Just as side note, I did not complain about emacs "just because it is
old and unfashionable", I complained about what _I_ perceived to be a
usability hindrance.
Anyway, that's water under the bridge - I accept the points raised that
it would probably be the reasonable thing to do to just accept it since
there is no better alternative to emacs for lisp editing (and I havn't
the time or will to implement such an alternative).
if you may, since we are already speaking of emacs, let me ask another
question: Isn't the all-reaching-all-powerfull approach of connecting
everything including the kitchen sink to it makes emacs somewhat
against the "Unix way" of having lots of small independent apps
comunicating with one another, each doing just one thing but doing it
well, instead of giant apps that do lots of things each?
···········@gmail.com wrote:
> if you may, since we are already speaking of emacs, let me ask another
> question: Isn't the all-reaching-all-powerfull approach of connecting
> everything including the kitchen sink to it makes emacs somewhat
> against the "Unix way" of having lots of small independent apps
> comunicating with one another, each doing just one thing but doing it
> well, instead of giant apps that do lots of things each?
Totally. But Emacs didn't start out on UNIX.
--
Cameron MacKinnon
Toronto, Canada
Thanks for the info,i did not know that...
it is strange though, since Richard Stallman (which I assume is the
first person most people would associate with emacs) seems like such a
"Philosphy/ideoligy comes first" kind of guy.
···········@gmail.com writes:
> Thanks for the info,i did not know that...
> it is strange though, since Richard Stallman (which I assume is the
> first person most people would associate with emacs) seems like such a
> "Philosphy/ideoligy comes first" kind of guy.
Yes, it's strange that RMS decided to implement a free unix instead of
a free lispmachine. I think at the time he made the decision, unix
had more arguments in its favor, but that if he had started ten years
later, with more powerful processors, then he might have started a
free "lisp machine" instead. And linux would be actually a lispus :-)
--
"Debugging? Klingons do not debug! Our software does not coddle the
weak."
Pascal Bourguignon wrote:
> ···········@gmail.com writes:
>> Thanks for the info,i did not know that...
>> it is strange though, since Richard Stallman (which I assume is the
>> first person most people would associate with emacs) seems like such a
>> "Philosphy/ideoligy comes first" kind of guy.
>
> Yes, it's strange that RMS decided to implement a free unix instead of
> a free lispmachine. I think at the time he made the decision, unix
> had more arguments in its favor, but that if he had started ten years
> later, with more powerful processors, then he might have started a
> free "lisp machine" instead. And linux would be actually a lispus :-)
Some time ago I read RMS's original proposal in which he mentions
that he wanted a Unix (because it's standard/accepted/portable I
guess) but he explicitly mentioned C and Lisp both being standard
programming languages. Obviously worse-is-better won that part of
the deal later on (and with Linux, not BSD, being the kernel ;) )...
--
I believe in Karma. That means I can do bad things to people
all day long and I assume they deserve it.
Dogbert
From: Karl A. Krueger
Subject: Re: arrow keys in sbcl or cmucl interpreter
Date:
Message-ID: <dd96r3$25b$1@baldur.whoi.edu>
Ulrich Hobelmann <···········@web.de> wrote:
> Some time ago I read RMS's original proposal in which he mentions
> that he wanted a Unix (because it's standard/accepted/portable I
> guess) but he explicitly mentioned C and Lisp both being standard
> programming languages.
Indeed, both being *systems* programming languages, which would suggest
the need for some sort of bidirectional FFI between them.
It's interesting to note that the only other "campaign promises" of the
original GNU announcement that are unfulfilled by a modern GNU/Linux
system are:
* a versioning filesystem
* a Lisp-based windowing system
* CHAOSnet support
... and some would say that last one is slightly overtaken by events. :)
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
Pascal Bourguignon <····@mouse-potato.com> writes:
> Yes, it's strange that RMS decided to implement a free unix instead of
> a free lispmachine. I think at the time he made the decision, unix
> had more arguments in its favor, but that if he had started ten years
> later, with more powerful processors, then he might have started a
> free "lisp machine" instead. And linux would be actually a lispus :-)
I seriously doubt that. I have given this some of thought, and I am
convinced that RMS would still have gone for the Unix clone, or
perhaps for a Windows clone, simply because it makes writing the
specification so much simpler. As was the case when RMS started the
GNU project, today still many more developers have been exposed to
Unix (or Windows) than to Lisp machines.
--
Robert Strandh
From: Robert Uhl
Subject: Re: arrow keys in sbcl or cmucl interpreter
Date:
Message-ID: <m33bpkf1pi.fsf@4dv.net>
···········@gmail.com writes:
>
> if you may, since we are already speaking of emacs, let me ask another
> question: Isn't the all-reaching-all-powerfull approach of connecting
> everything including the kitchen sink to it makes emacs somewhat
> against the "Unix way" of having lots of small independent apps
> comunicating with one another, each doing just one thing but doing it
> well, instead of giant apps that do lots of things each?
From one perspective, yes. But from another perspective, not quite.
emacs _does_ do one thing and do it extremely well: it is a programmable
text editor, and does that very well indeed. Being able to support
every language--including those yet undreamt of--is really quite a
difficult problem, and it happens that the solution thereto is rather
complex.
Because it's so extensible, it ends up that emacs is useful for other
things as well, but that's just a happy coincidence (or perhaps not: if
one considers that text editing is fundamentally similar to
command-issuing, it stands to reason that a truly excellent text editor
would be useful for controlling a computer).
As for small tools, ed is very, very small--and I'd rather never use a
computer again than be forced to program within its confines for
eternity.
--
Robert Uhl <http://public.xdi.org/=ruhl>
A horse will usually shy from a plastic bin-liner in a hedge.
I don't know why; maybe tigers used to go around dressed in
bin-liners or something once. --Dan Holdsworth
> Because it's so extensible, it ends up that emacs is useful for other
> things as well, but that's just a happy coincidence (or perhaps not: if
> one considers that text editing is fundamentally similar to
> command-issuing, it stands to reason that a truly excellent text editor
> would be useful for controlling a computer).
Indeed. Check Genera and Oberon for other examples.
> As for small tools, ed is very, very small--and I'd rather never use a
> computer again than be forced to program within its confines for
> eternity.
ed is great when you have 16KW of core memory for it, the OS and other
processes.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Wanna go outside.
Oh, no! Help! I got outside!
Let me back inside!
From: Torsten Poulin
Subject: Re: arrow keys in sbcl or cmucl interpreter
Date:
Message-ID: <luvms2-h9.ln1@poulin.dk>
Pascal Bourguignon wrote:
> ed is great when you have 16KW of core memory for it, the OS and
> other processes.
$ size /bin/ed
text data bss dec hex filename
127403 8780 75448 211631 33aaf /bin/ed
:-(
--
Torsten
he didn't say kilo-byte, he said kilo-watt...
so your example doesn't contradict him
From: Torsten Poulin
Subject: Re: arrow keys in sbcl or cmucl interpreter
Date:
Message-ID: <hr8ns2-4j.ln1@poulin.dk>
···········@gmail.com wrote:
> he didn't say kilo-byte, he said kilo-watt...
> so your example doesn't contradict him
Heh-heh. He said kilo-words, but on the stuff Unix ran on back then,
16 of those would still be too little ...
--
Torsten
···········@gmail.com writes:
> oh, ok.
> kilo-words? who the fuck uses _that_ to measure memory?
People who worked with LISP 1.5 on a 7090 for example.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
From: Joe Marshall
Subject: Re: arrow keys in sbcl or cmucl interpreter
Date:
Message-ID: <psslu9bi.fsf@ccs.neu.edu>
···········@gmail.com writes:
> 7090?
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP7090.html
The IBM 7090 used the IBM 7302 Magnetic Core Storage module. It
appears as if you can attach up to 8 of these to the Data Processing
System.
``The IBM 7302 Magnetic Core Storage has a capacity of 32,768
thirty-six bit words; the access time for extracting or storing a
word does not exceed 2.4 microseconds, including the complete read
and rewrite cycle.''
Amusing tidbits:
``The fully-transistorized system has computing speeds six times
faster than those of its vacuum-tube predecessor, the IBM 709...
``The six-fold increase in the 7090's speed results largely from
the use of more than 50,000 transistors plus extremely fast
magnetic core storage. The new system can simultaneously read and
write electronically at the rate of 3,000,000 bits of information
a second, when eight data channels are in use. In 2.18 millionths
of a second, it can locate and make ready for use any of 32,768
data or instruction numbers (each of 10 digits) in the magnetic
core storage. The 7090 can perform any of the following
operations in one second: 229,000 additions or subtractions,
39,500 multiplications, or 32,700 divisions.''
``Computation is in the very efficient binary arithmetic, and as
with most internal operations, is accomplished in parallel in a
36-bit fixed word length.
Joe Marshall <···@ccs.neu.edu> wrote:
+---------------
| ···········@gmail.com writes:
| > 7090?
|
| http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP7090.html
+---------------
And the successor to the IBM 7090 was the 7094:
http://www.columbia.edu/acis/history/7094.html
...
The IBM 7094 computer in the Columbia University Computer Center
machine room some time between 1964 and 1968, operator John
Szallasi at the console. The IBM 709x series are the 36-bit
machines on which LISP was developed; its 18-bit halfwords were
perfect for CARs and CDRs. This is the machine that inspired
DEC's first 36-bit machine, the PDP-6, which was followed by the
PDP-10 and DEC-20.
And the DEC PCP-10 <http://www.columbia.edu/acis/history/pdp10.html>
was, of course, possibly the most widely-used machine for early Lisp work.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Torsten Poulin <·············@hotmail.com> writes:
> ···········@gmail.com wrote:
>
>> he didn't say kilo-byte, he said kilo-watt...
>> so your example doesn't contradict him
>
> Heh-heh. He said kilo-words, but on the stuff Unix ran on back then,
> 16 of those would still be too little ...
Indeed I said kilo word since it could be 18-bit or 36-bit at his time.
But you've asked the size of the wrong executable.
$ ls -l /local/apps/apout-simulator/*/bin/ed|sed -e 's/pjb //g'
-r-xr-xr-x 1 3998 1973-05-09 16:23 /local/apps/apout-simulator/V1/bin/ed*
-rwxr-xr-x 1 4292 1974-11-27 00:30 /local/apps/apout-simulator/V5/bin/ed*
-rwxr-xr-x 1 6308 1975-07-18 16:49 /local/apps/apout-simulator/V6/bin/ed*
-rwxr-xr-x 1 11074 1979-05-05 11:30 /local/apps/apout-simulator/V7/bin/ed*
-rwxr-xr-x 1 9354 1997-12-29 08:20 /local/apps/apout-simulator/2.11/bin/ed*
--
__Pascal Bourguignon__ http://www.informatimago.com/
From: Christopher C. Stacy
Subject: Re: arrow keys in sbcl or cmucl interpreter
Date:
Message-ID: <uirygnqha.fsf@news.dtpq.com>
···········@gmail.com writes:
> if you may, since we are already speaking of emacs, let me ask another
> question: Isn't the all-reaching-all-powerfull approach of connecting
> everything including the kitchen sink to it makes emacs somewhat
> against the "Unix way" of having lots of small independent apps
> comunicating with one another, each doing just one thing but doing it
> well, instead of giant apps that do lots of things each?
You mean like Perl?
But, then, Emacs was not invented for Unix.
···········@gmail.com wrote:
> if you may, since we are already speaking of emacs, let me ask another
> question: Isn't the all-reaching-all-powerfull approach of connecting
> everything including the kitchen sink to it makes emacs somewhat
> against the "Unix way" of having lots of small independent apps
> comunicating with one another, each doing just one thing but doing it
> well, instead of giant apps that do lots of things each?
Well, emacs runs on different operating systems, among which are
different, totally incompatible Unices, so having a reasonable
programming language (elisp) available bundled with a powerful
editor isn't the worst thing that can happen to you. Arguably
better than having vi with different feature-sets and lots of
different Unix-utilities in their GNU/BSD/SGI/HP glory, depending
on what system you're sitting. Oh, and on Windows the alternative
isn't even vi, but Notepad.
--
I believe in Karma. That means I can do bad things to people
all day long and I assume they deserve it.
Dogbert
···········@gmail.com writes:
> if you may, since we are already speaking of emacs, let me ask another
> question: Isn't the all-reaching-all-powerfull approach of connecting
> everything including the kitchen sink to it makes emacs somewhat
> against the "Unix way" of having lots of small independent apps
> comunicating with one another, each doing just one thing but doing it
> well, instead of giant apps that do lots of things each?
They are not as different as you might think. It is just that Unix
made an "independent app" into something to be run in a separate
process, whereas you could think of the different Emacs subsystems and
functions as "independent apps" as well.
The part of the "Unix way" that has to do with modular software is
good, but the part about having the applications in separate address
spaces is the root of many problems with Unix.
--
Robert Strandh
From: David Trudgett
Subject: Re: arrow keys in sbcl or cmucl interpreter
Date:
Message-ID: <m3mznq22tb.fsf@rr.trudgett>
···········@gmail.com writes:
> if you may, since we are already speaking of emacs, let me ask another
> question: Isn't the all-reaching-all-powerfull approach of connecting
> everything including the kitchen sink to it makes emacs somewhat
> against the "Unix way" of having lots of small independent apps
> comunicating with one another, each doing just one thing but doing it
> well, instead of giant apps that do lots of things each?
>
You forget that Emacs is itself an operating system ;-) All of its
pieces/modules *do* do "one" thing and do it well, so Emacs is
actually a great example of the Unix philosophy. Not only does Emacs
take the Unix "toolkit" approach to heart in its own programmable
module department, but it *also* can and does allow one to easily use
whatever *other* Unix tools happen to be available on the system.
When I run a build in ada-mode (one of those "independent apps" of
which you speak!), for instance, it goes off and executes the various
system commands to accomplish the task, and then feeds back hot-linked
error notifications so I can jump to the appropriate place and make
the required corrections. That seems pretty Unix-y to me! :-)
David
--
David Trudgett
http://www.zeta.org.au/~wpower/
Many young soldiers enter military service having bought the whole
story about the US military as some liberatory force, and the
discovery of its true nature creates a traumatic sense of dislocation
and betrayal.
-- Stan Goff, retired from U.S. special forces.
On 9196 day of my life Ido Yehieli wrote:
> Isn't the all-reaching-all-powerfull approach of connecting
> everything including the kitchen sink to it makes emacs somewhat
> against the "Unix way" of having lots of small independent apps
> comunicating with one another, each doing just one thing but doing
> it well, instead of giant apps that do lots of things each?
Emacs is not tool. It is separate OS that itself consists of small
independent apps (functions, actually) communicating with one
another. So, it fits "Unix way" precisely, but in unusual manner :)
OTOH, you can consider Emacs as a library (or a "framework") that
other apps (Gnus, SLIME, XTLA, JDE etc) use. And that apps use other
Unix apps (sendmail, w3m, cvs, tla, lisp, java, ant, make etc.)
--
Ivan Boldyrev
Perl is a language where 2 x 2 is not equal to 4.
···········@gmail.com writes:
>i would suggest looking up the defenition of the words "established"
>and "common".
>like it or not, today the number of users using MacOS and MS-Windows
>applications + linux apps that work like them out number emacs and vi
>users combined by several orders of magnitude, hence making them the
>"established common UI."
What are you whining about? You don't have to use either vi or emacs.
And you don't have to use Unix or Linux either. Surely you do not
suggest that everyone shall cease using vi or emacs and use
notepad.exe henceforth?
mkb.
Pascal Bourguignon wrote:
>> I don't want to learn a
>> new UI for each program I run, I'm lazy- i want it to function as I
>> expect it to function (like most of my apps - eclipse, mozilla,
>> open-office, gaim, all the [kde|gnome] apps etc. all basicly use the
>> same UI style). </rant>
>
> If you were as lazy as I am, you'd just learn emacs and be done forever.
>
> All applications exist in emacs: web, ftp, email, editing compiling,
> terminal emulators, debugging, word processors, games, speach
> synthesis, you name it, all under one coherent key binding system.
Well, using emacs for mail and www might be a matter of taste, but
Mozilla actually does respect C-a and C-e C-k and maybe other
keybindings, so learning Emacs doesn't hurt.
On the Mac there's also Aquamacs with lots of standard
Mac-keybindings.
> Just forget the lesser environments and switch definitively and
> comprehensively to emacs:
>
> http://www.informatimago.com/linux/emacs-on-user-mode-linux.html
But isn't the kernel a total waste of resources there? They
should build a VFS and disk drivers for emacs. Hm, maybe Movitz
will run an Emacs port at some point.
--
I believe in Karma. That means I can do bad things to people
all day long and I assume they deserve it.
Dogbert
From: Edi Weitz
Subject: Re: arrow keys in sbcl or cmucl interpreter
Date:
Message-ID: <ubr487w30.fsf@agharta.de>
On Mon, 08 Aug 2005 08:43:43 +0200, Ulrich Hobelmann <···········@web.de> wrote:
> Hm, maybe Movitz will run an Emacs port at some point.
<http://www.emmett.ca/~sabetts/>
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
···········@gmail.com wrote:
> working the way 99% of my apps are? i.e. using the common UI
> keybindings (that's the most important one). I don't want to learn a
Many programs use a subset of the Emacs keybinding. Like ^a for moving
the cursor to the beginning of the line. ^g to abort operations.
See the bash + readline.
Stefan Scholl wrote:
> ···········@gmail.com wrote:
>
>>working the way 99% of my apps are? i.e. using the common UI
>>keybindings (that's the most important one). I don't want to learn a
>
>
> Many programs use a subset of the Emacs keybinding. Like ^a for moving
> the cursor to the beginning of the line. ^g to abort operations.
I was happy to recently discover that standard GUI text fields on Mac OS
X have support for some Emacs key bindings. I hit ctrl-e out of habit
and was surprised to see the cursor move to the end of the line in a
Safari text field :)
John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL
···········@gmail.com wrote:
> i have seen the frist couple of minutes, and browsed through the rest.
> seems far too complicated...
> this is kind of what also bothers me with emacs and vi: why is it not
> working the way 99% of my apps are? i.e. using the common UI
> keybindings (that's the most important one). I don't want to learn a
> new UI for each program I run, I'm lazy- i want it to function as I
> expect it to function (like most of my apps - eclipse, mozilla,
> open-office, gaim, all the [kde|gnome] apps etc. all basicly use the
> same UI style). </rant>
I agree. Add the following to your .emacs to make it act more like
other apps. It's still different in some places, but not for most of
the core functionality:
> (cua-mode 1)
> (mouse-wheel-mode 1)
>
> (when window-system
> (setf (global-key-binding (kbd "<down-mouse-3>")) (lambda (event prefix)
> (interactive ·@e\np")
> (popup-menu menu-bar-edit-menu event prefix))))
> ;; simpler sexp bindings
> (setf (global-key-binding (kbd "M-<right>")) 'forward-sexp
> (global-key-binding (kbd "M-<left>")) 'backward-sexp
> (global-key-binding (kbd "M-<up>")) 'backward-up-list
> (global-key-binding (kbd "M-<down>")) 'down-list
> (global-key-binding (kbd "M-SPC")) 'mark-sexp
> (global-key-binding (kbd "M-<delete>")) 'kill-sexp
> (global-key-binding (kbd "M-<backspace>")) 'backward-kill-sexp)
You may need to replace cua-mode with CUA-mode, depending on your
version of Emacs.
-- MJF
···········@gmail.com writes:
>this is kind of what also bothers me with emacs and vi: why is it not
>working the way 99% of my apps are? i.e. using the common UI
>keybindings (that's the most important one). I don't want to learn a
>new UI for each program I run, I'm lazy- i want it to function as I
>expect it to function (like most of my apps - eclipse, mozilla,
>open-office, gaim, all the [kde|gnome] apps etc. all basicly use the
>same UI style). </rant>
Then use Windows and leave us alone.
Both vi and Emacs predate the applications you cited by 1-2 _decades_.
mkb.