the Modernization of Emacs
Xah Lee
* Change the keyboard shortcut of Copy & Paste to meta-C and meta-V
as to be the same with all modern applications.
* Change the undo behavior so that there is a Undo and Redo, as the
same with all modern applications.
* Get rid of the *scratch* buffer.
* Make longlines-mode the default editor behavior for any file.
Things emacs should do now, even though it eventually will do.
* When opening a HTML document, automatically provide highlighting
of HTML, CSS, and Javascript codes. Similarly for other multi-language
files such as PHP, JSP, et al. This behavior must be automatic without
requiring user to customize emacs.
Possible Documentation Change Proposals
* Reduce the use of the word “buffer” in the emacs
documentation. Call it “opened file” or “unsaved document”.
* Switch the terminology of Window and Frame so it is more
standard. That is, Emacs's “Window” should be called Panes or
Frames. While Emacs's “Frame” should be termed Window.
* Change the terminology of keybinding to “keyboard shortcut”
in emacs documentation. Use the term keybinding or binding only in a
technical context, such as in elisp documentation.
Burton Samograd
> Things emacs need to change for modern world:
<snip a bunch things you don't like about emacs>
the code is there and pretty easy to read and modify. maybe you
should get it, make you changes until you're happy and release it
under a new name...emacsNG maybe?
some of us like emacs the way it is, and we took the time to learn how
to make it do what we want, maybe you should too.
--
burton samograd kruhft .at. gmail
kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com
fredri...@gmail.com
emacs with an alternative beginners .emacs file.
Not all buffers are "open files". I see no reason why the difference
between files and buffers should be swept under the rug.
Even beginners like having a *scratch* buffer for temporary stuff. What
have you got against it?
/Fredrik
Greg Menke
Sounds great. Download the source, make the changes but do please keep
it to yourself.
Gregm
Pascal Bourguignon
> Things emacs need to change for modern world:
>
> * Change the keyboard shortcut of Copy & Paste to meta-C and meta-V
> as to be the same with all modern applications.
For the innocent bystanders, I should mention that the whole point of
programmable editors such as emacs, is to be sufficiently automatic
that you rarely have to do copy-and-paste yourself, contrary of
slaving editors such as MacWrite or Microsoft Words, where you, the
user, have to do all the editing work using intensively copy and
paste.
> * Change the undo behavior so that there is a Undo and Redo, as the
> same with all modern applications.
And of course, since the editing is programmed, in emacs, it rarely
err and rarely needs to be undone.
> [... blah blah blah ...]
> Xah
Xah, if you want Microsoft Word, then just use Microsoft Word. I hear
it even contains a Basic programming language to let you write
scripts, just like in emacs!
--
__Pascal Bourguignon__ http://www.informatimago.com/
PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.
robert...@antenova.com
> "Xah Lee" <x...@xahlee.org> writes:
>
> > Things emacs need to change for modern world:
> >
> > * Change the keyboard shortcut of Copy & Paste to meta-C and meta-V
> > as to be the same with all modern applications.
>
> For the innocent bystanders, I should mention that the whole point of
> programmable editors such as emacs, is to be sufficiently automatic
> that you rarely have to do copy-and-paste yourself, contrary of
> slaving editors such as MacWrite or Microsoft Words, where you, the
> user, have to do all the editing work using intensively copy and
> paste.
>
> > * Change the undo behavior so that there is a Undo and Redo, as the
> > same with all modern applications.
>
> And of course, since the editing is programmed, in emacs, it rarely
> err and rarely needs to be undone.
I rarely find that the programmable functions of Emacs negate the need
for undo and redo. I also find I have to use copy and paste quite
often too. The programmability only helps in circumstances where it's
faster to record a macro or write elisp to do something, than it is to
do it manually, those situations aren't that common.
Anyway, GNU Emacs does have undo and redo. If you use C-x u or C-_ to
undo, it will do successive undos, until you type something else. Then
after that it will do successive redoes. It could definetely be more
flexible, but it is certainly present.
Frode Øijord
> Things emacs need to change for modern world:
>
> * Change the keyboard shortcut of Copy & Paste to meta-C and meta-V
> as to be the same with all modern applications.
> * Change the undo behavior so that there is a Undo and Redo, as the
> same with all modern applications.
>
cua-mode.
I'm not sure if there is any precompiled emacs available with this on
windows, so you should probably just grab the latest source from CVS and
compile it yourself.
--
Frode, SIM
"Any fool can write code that a computer can understand.
Good programmers write code that humans can understand"
Rob Thorpe
This is Emacs we're talking about, for most of what the Xah mentioned
the source doesn't even need changing. You could make all the changes
only by overriding functions. AFAIK only dispensing with scratch and
changing the documentation needs source modification.
Of-course it would be useful if some of these things were done by
default since it would make Emacs easier to use for the beginner. I
get the impression a lot of people end up using Vim and Eclipse because
the default setup of Emacs is not suitable for their needs, so they
abandon it straight away.
Ray Dillinger
> Things emacs need to change for modern world:
Dude, that's always been the strength of emacs. If you
don't like the way it does things, just write a major
mode that makes it work the way you want.
Bear
Burton Samograd
> Even beginners like having a *scratch* buffer for temporary stuff. What
> have you got against it?
i'm thinking that having it in elisp-interaction mode is not what most
beginners want to start in, and not knowing how to change (or even
know what) a mode it might leave some of them confused...i know i was
for years until i understood what emacs, and it's internals, was
really all about...
emacs is great, but as a tool it really takes years of dedication and
effort to understand it, it's quirks and it why it's the way it is.
the time pays off in the end, but it can really be a pain when you
want to figure out how to do something *fast* (thank $DEITY for wiki's
and google these days).
Bruce Stephens
And, since it's so easy, you'll probably find someone else has done
much of it:
<http://www.dur.ac.uk/p.j.heslin/Software/Emacs/Easymacs/>.
Pascal Bourguignon
> "fredri...@gmail.com" <fredri...@gmail.com> writes:
>
>> Even beginners like having a *scratch* buffer for temporary stuff. What
>> have you got against it?
>
> i'm thinking that having it in elisp-interaction mode is not what most
> beginners want to start in, and not knowing how to change (or even
> know what) a mode it might leave some of them confused...i know i was
> for years until i understood what emacs, and it's internals, was
> really all about...
Modes are extensively explained in the tutorial
> emacs is great, but as a tool it really takes years of dedication and
> effort to understand it, it's quirks and it why it's the way it is.
> the time pays off in the end, but it can really be a pain when you
> want to figure out how to do something *fast* (thank $DEITY for wiki's
> and google these days).
If you want to do something *fast*, you use nano or Notepad.exe.
--
__Pascal Bourguignon__ http://www.informatimago.com/
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 it's wake.
Burton Samograd
> Burton Samograd <kruhft...@gmail.com> writes:
>
> > i'm thinking that having it in elisp-interaction mode is not what most
> > beginners want to start in, and not knowing how to change (or even
> > know what) a mode it might leave some of them confused...i know i was
> > for years until i understood what emacs, and it's internals, was
> > really all about...
>
> Modes are extensively explained in the tutorial
true, but emacs still has a unique language that can be difficult to
wrap one's head around when you first start to use it...especially
when you're used to non-programmer's text editors/word processor
(notepad, word, etc). it's a bit daunting to the beginner to find
that a program that simply edits text can be so damn complicated...it
takes years to really figure out that editing text is what a
programmer does, and the reason the editors are complicated is so that
they have the tools to edit with the full power that they need/desire
(plus, in the case of emacs, read news, send mail and chat on irc ;-)
> > emacs is great, but as a tool it really takes years of dedication and
> > effort to understand it, it's quirks and it why it's the way it is.
> > the time pays off in the end, but it can really be a pain when you
> > want to figure out how to do something *fast* (thank $DEITY for wiki's
> > and google these days).
>
> If you want to do something *fast*, you use nano or Notepad.exe.
i mean fast in the sense of doing a difficult editing task, not just
writing some text. i've spent enough time with emacs to do everything
in it (it's a way of life, yadayadayada) but it takes a while to get
there...
Tim Bradshaw
> that a program that simply edits text can be so damn complicated...
You know, that's *exactly* what I think every time I have to do
something in Word.
Xah Lee
don't feel like dealing now.
will write off in few days.
maybe i'm down,
but sometimes i wonder,
whether my problems's because,
i'm a outlier of mind.
coupled with a character,
due by a odd growth'n'faring,
rose a difficulty,
with the sea of 'holes,
and the motherfucking heart,
that's in males, demonic.
Xah
x...@xahlee.org
∑ http://xahlee.org/
Timofei Shatrov
<fr...@sim.no> tried to confuse everyone with this message:
>
>I'm not sure if there is any precompiled emacs available with this on
>windows, so you should probably just grab the latest source from CVS and
>compile it yourself.
EmacsW32: http://ourcomments.org/Emacs/EmacsW32.html
--
|WAR HAS NEVER SOLVED ANYTHING|,----- Timofei Shatrov aka Grue---------.
|(except for ending slavery, ||mail: grue at mail.ru ================ |
| fascism and communism) ||============= http://grue3.tripod.com |
|...and Saddam's dictatorship |`----------------------------------[4*72]
Miles Bader
> but sometimes i wonder,
> whether my problems's because,
> i'm a outlier of mind.
Your problem is that you keep trolling Emacs groups with this crap.
What response do you expect, exactly?
-miles
--
Next to fried food, the South has suffered most from oratory.
-- Walter Hines Page
Sacha
"Miles Bader" <mi...@gnu.org> wrote in message
news:87acatn...@catnip.gol.com...
> "Xah Lee" <x...@xahlee.org> writes:
>> but sometimes i wonder,
>> whether my problems's because,
>> i'm a outlier of mind.
>
> Your problem is that you keep trolling Emacs groups with this crap.
> What response do you expect, exactly?
>
He's got a point though, as a newcomer to lisp, and windows user,
i found it pretty hard to have to learn emacs while learning lisp...
None of these two are trivial.
I eventually settled for the lispworks editor, which will allow me to learn
some
of those emacs keystrokes while still being somewhat user-friendly.
Sure the tool looks like awesome, but does it really need to be so
unfriendly ?
I can't imagine any better way than emacs to frighten the newbie lisper.
Sacha
Adi Ron
> Things emacs need to change for modern world:
>
> * Change the keyboard shortcut of Copy & Paste to meta-C and meta-V
> as to be the same with all modern applications.
> * Change the undo behavior so that there is a Undo and Redo, as the
> same with all modern applications.
> * Get rid of the *scratch* buffer.
> * Make longlines-mode the default editor behavior for any file.
>
You're more than welcome to put these things in your ~/.emacs file.
> Things emacs should do now, even though it eventually will do.
>
> * When opening a HTML document, automatically provide highlighting
> of HTML, CSS, and Javascript codes. Similarly for other multi-language
> files such as PHP, JSP, et al. This behavior must be automatic without
> requiring user to customize emacs.
It pretty much does that as far as I know.
>
> Possible Documentation Change Proposals
>
> * Reduce the use of the word “buffer” in the emacs
> documentation. Call it “opened file” or “unsaved document”.
No, buffer makes more sense for developers, because it's a buffer -
not a file necessarily.
> * Switch the terminology of Window and Frame so it is more
> standard. That is, Emacs's “Window” should be called Panes or
> Frames. While Emacs's “Frame” should be termed Window.
> * Change the terminology of keybinding to “keyboard shortcut”
> in emacs documentation. Use the term keybinding or binding only in a
> technical context, such as in elisp documentation.
"Keybinding" is very accepted in all sorts of software.
>
> Xah
> x...@xahlee.org
> ∑ http://xahlee.org/
>
If we do what you say, emacs will just be a glorified M$ Notepad (TM
of course) clone.
--
Dushkin
M Jared Finder
> Things emacs need to change for modern world:
>
> * Change the keyboard shortcut of Copy & Paste to meta-C and meta-V
> as to be the same with all modern applications.
Actually, that would be C-c and C-v, not M-C and M-V.
I agree with this. If you try out EmacsW32
<http://ourcomments.org/Emacs/EmacsW32.html>, you'll find that it has a
wizard that runs when you first run Emacs that enables CUA, and also
rebinds C-a to select all, instead of beginning-of-line.
> * Change the undo behavior so that there is a Undo and Redo, as the
> same with all modern applications.
This would make sense. Emacs already has undo-only; it's not hard to
imagine adding a redo-only. This would also bring Emacs in line with
just about every other editor.
Now the big question is what the keybinding should be -- C-y or C-S-z.
> * Get rid of the *scratch* buffer.
I completely disagree. Just like you wouldn't want to get rid of /tmp/,
you don't want to get rid of *scratch*. Sometimes you want to create
some temporary notes, and you don't care about them being saved. That's
what *scratch* is for.
> * Make longlines-mode the default editor behavior for any file.
Unless you can make longlines-mode act sensibly with programming
languages, no way. If my C code is going to be token wrapped, it'd
better put the newlines in the right places -- before the operator,
after my open parenthesis in function definitions, etc. If it doesn't
do that correctly, I'd be extremely pissed.
Now for text-mode, this makes sense.
>
> Things emacs should do now, even though it eventually will do.
>
> * When opening a HTML document, automatically provide highlighting
> of HTML, CSS, and Javascript codes. Similarly for other multi-language
> files such as PHP, JSP, et al. This behavior must be automatic without
> requiring user to customize emacs.
I agree. There's mmm-mode, but that's not part of Emacs core yet.
Maybe in Emacs 23...
> Possible Documentation Change Proposals
>
> * Reduce the use of the word “buffer” in the emacs
> documentation. Call it “opened file” or “unsaved document”.
I disagree. Not all buffers are files. I don't think it makes sense to
talk about the *compilation* unsaved document or the *grep* unsaved
document. A buffer is just a collection of text that you can edit. It
may or may not make sense for this collection of text to be associated
with a file.
> * Switch the terminology of Window and Frame so it is more
> standard. That is, Emacs's “Window” should be called Panes or
> Frames. While Emacs's “Frame” should be termed Window.
I like the idea, but it'd be hard to change all the names of all the
existing functions, as long as Emacs does not have a namespace system
(like Common Lisp's package system).
> * Change the terminology of keybinding to “keyboard shortcut”
> in emacs documentation. Use the term keybinding or binding only in a
> technical context, such as in elisp documentation.
Why bother? It makes sense, and in fact Emacs mentions Keyboard
shortcut in the index. But I don't think it matters enough to change
all the documentation.
-- MJF
Robert Uhl
>
> Sure the tool looks like awesome, but does it really need to be so
> unfriendly ? I can't imagine any better way than emacs to frighten
> the newbie lisper.
Part of the problem is that the things which might make it initially
friendlier would make it far less friendly in the long run. The
keystrokes are a good example: yes, they're unlike anything else out
there; they're also amazingly useful and for the most part very
well-thought-out. Changing C-y to C-v and C-v to PgDn and so forth
would really hurt emacs; once one has learnt the (admittedly strange to
the modern user) emacs keys one will never want to go back.
--
Robert Uhl <http://public.xdi.org/=ruhl>
The betterment of fools, Goethe tells us, is the appropriate business of
other fools. The Underground Grammarian does not seek to educate
anyone. We intend rather to ridicule, humiliate, and infuriate those
who abuse our language not so that they will do better but so that they
will stop using language entirely or at least go away.
--The Underground Grammarian
Tom Lord
direction but ....
Well, yr specific suggestions are suggestive but don't go far
enough and are easily dismissed with arguments like "Well, if
*that's* all you want just publish a suitable .emacs file!"
Which is basically what yr getting.
Emacs needs work on the interaction loop, the detailed structure
of buffers, the specific lisp dialect used, and the graphical
display capabilities. As it stands its a handy brutish tool and
a good demonstration of architectural concepts that run circles
around the dominant architectures for desktop tools but it's
pretty irrevocably stuck in the 1980s -- there's no way to get
there, from here, short of a rewrite. Yr just scratching the
surface.
And in that way, I share yr frustration with the responses
because it's basically just people saying they don't care what's
possible and/or can't imagine themselves free to work on it and
they'll take an over-literal reading of you as an excuse to
dismiss. But one can imagine in the direction yr pointing and,
yes, it's hard to imagine a spirit so impoverished it would turn
its back on that. Yet that is nearly all one finds.
Knowing some of them, I can't accept "morons". Those who have
internalized a form of oppression and just "given up" -- yeah,
that I can see. Bit of a difference, there.
Well, unless you meant something completely different from what
I'm projecting on you, anyway,
-t
p.s.: yr view of Bush (via yr web site) is self refuting. If yr
analysis of him were correct, we'd be more aggressively taking
over the Americas, not trying to fix western Asia. Easy play,
there, if yr goal is world domination.
Tom Lord
but ....
Well, yr specific suggestions are suggestive but don't go far enough
and
are easily dismissed with arguments like "Well, if *that's* all you
want
just publish a suitable .emacs file!" Which is basically what yr
getting.
Emacs needs work on the interaction loop, the detailed structure of
buffers, the specific lisp dialect used, and the graphical display
capabilities. As it stands its a handy brutish tool and a good
demonstration
of architectural concepts that run circles around the dominant
architectures
for desktop tools but it's pretty irrevocably stuck in the 1980s --
there's
no way to get there, from here, short of a rewrite. Yr just scratching
the
surface.
And in that way, I share yr frustration with the responses because it's
basically just people saying they don't care what's possible and/or
can't
imagine themselves free to work on it. But one can imagine in the
direction
yr pointing and, yes, it's hard to imagine a spirit so impoverished it
would
turn its back on that. Yet that is nearly all one finds.
Knowing some of them, I can't accept "morons". Those who have
internalized
a form of oppression and just "given up" -- yeah, that I can see. Bit
of a
difference, there.
Well, unless you meant something completely different from what I'm
projecting on
you, anyway,
-t
p.s.: yr view of Bush (via yr web site) is self refuting. If yr
analysis of him were
correct, we'd be more aggressively taking over the Americas, not
trying to fix western Asia.
Easy play, there, if yr goal is world domination.
Rob Thorpe
I learnt emacs lisp first before learning any common lisp. This makes
things less difficult.
When I first started using Emacs I just didn't use the keystrokes until
I'd got used to it.
Emacs could certainly do to be friendlier though.
Marc Tfardy
> "fredri...@gmail.com" <fredri...@gmail.com> writes:
>
>> Even beginners like having a *scratch* buffer for temporary stuff. What
>> have you got against it?
>
> i'm thinking that having it in elisp-interaction mode is not what most
> beginners want to start in, and not knowing how to change (or even
> know what) a mode
Beginners have to learn, learn and learn again. When someone expect
a simple editor, he should take a notepad or something similar.
> emacs is great, but as a tool it really takes years of dedication and
> effort to understand it,
Yes, but where is the problem? There are things, for which one needs
years.
Marc
Tom Lord
Tim Bradshaw
> He's got a point though,
I don't think he really does.
Before I start: yes, emacs is crufty in a lot of ways (horrible lisp
dialect etc), yes it's left-field in lots of ways (odd key bindings for
people coming from a Windowsoid background), yes it's big and
complicated. Yes, yes yes.
> as a newcomer to lisp, and windows user,
> i found it pretty hard to have to learn emacs while learning lisp...
> None of these two are trivial.
Who said learning to program in a new language should be trivial? And
do you *really* think that Emacs is the thing that's making it too hard
to learn? Programming is a fairly intellectually hard activity, and if
you're going to succeed at it then you probably won't be put off by
something like Emacs - some time you're going to have to deal with
J2EE, or Unix or something, and if you think that Emacs is hard &
cruftily designed, then you have another think coming.
I play the guitar: not, generally, very well, but well enough. Playing
a musical instrument is kind of like programming: it's hard, and the
tools you use are generally not perfectly designed. And two things are
immediately apparent. Firstly people who try the guitar and complain
because the strings are too tight, the hand position makes their wrists
sore, it's just basically impossible to tune the thing right (really,
it is) and any of the myriad of other things which are objectively
wrong with guitars don't get very far. Secondly, of people who persist
and through talent and hard work become great guitarists *very few*
redesign the instrument. Not because it's a perfect design - it's
clearly not - but because it's a good enough design and there are more
important things to do, like playing music.
Emacs is like a guitar: imperfect, hard to learn, but you can do great
things with it. And, I'm glad to say, the vast majority of people who
understand emacs well enough to change it realise that there isn't much
point - not that such changes would not be a good thing, but because in
the finite amount of time they have, changing emacs would be a less
good thing than just getting on and using the flawed tool. (I'm also
glad that some people do work on Emacs, just as I'm glad that there are
people working on new guitar designs.)
> I can't imagine any better way than emacs to frighten the newbie lisper.
Anyone who wants to seriously look after Unix/Linux machines needs to
be at least competent with vi, and if you think Emacs is frightening
then, well. And lots of people do this, by the way. You should be
glad that you don't have to learn ed any more.
--tim
pookiebe...@yahoo.com
think they have it for unix now.
Sacha
"Tim Bradshaw" <tfb+g...@tfeb.org> wrote in message
news:1144758312.9...@e56g2000cwe.googlegroups.com...
> Sacha wrote:
>> He's got a point though,
>
> I don't think he really does.
haha well i think he does ! (this time anyways)
>> as a newcomer to lisp, and windows user,
>> i found it pretty hard to have to learn emacs while learning lisp...
>> None of these two are trivial.
>
> Who said learning to program in a new language should be trivial? And
I used to say so, until now every languages i learned were pretty easy to
grasp,
granted these were all the same thing. I used to say once you know one, you
know
them all ...well i was wrong. Lisp really is different.
> do you *really* think that Emacs is the thing that's making it too hard
> to learn? Programming is a fairly intellectually hard activity, and if
> you're going to succeed at it then you probably won't be put off by
> something like Emacs - some time you're going to have to deal with
> J2EE, or Unix or something, and if you think that Emacs is hard &
> cruftily designed, then you have another think coming.
Well i succeeded at programming, which gives me time to learn lisp.
I'm really not intereted in working with unixes, my customer base
just can't work with it anyways.
> I play the guitar: not, generally, very well, but well enough. Playing
> a musical instrument is kind of like programming: it's hard, and the
> tools you use are generally not perfectly designed. And two things are
> immediately apparent. Firstly people who try the guitar and complain
> because the strings are too tight, the hand position makes their wrists
> sore, it's just basically impossible to tune the thing right (really,
> it is) and any of the myriad of other things which are objectively
> wrong with guitars don't get very far. Secondly, of people who persist
> and through talent and hard work become great guitarists *very few*
> redesign the instrument. Not because it's a perfect design - it's
> clearly not - but because it's a good enough design and there are more
> important things to do, like playing music.
I have to totaly agree with you.
Most human activities are so much alike, and yes,
sometimes it's best to get things done rather than endlessly working on the
tools.
> Emacs is like a guitar: imperfect, hard to learn, but you can do great
> things with it. And, I'm glad to say, the vast majority of people who
> understand emacs well enough to change it realise that there isn't much
> point - not that such changes would not be a good thing, but because in
> the finite amount of time they have, changing emacs would be a less
> good thing than just getting on and using the flawed tool. (I'm also
> glad that some people do work on Emacs, just as I'm glad that there are
> people working on new guitar designs.)
Agreed, that's why i choose to easy route...learn the keystrokes while not
being stuck with emacs itself... When i'll feel more comfortable, maybe
i'll switch... I just feel it is pretty bad that we have to work with this
ages old
tool. Lisp is supposedly one of the best languages around, it's sad we have
to
overcome the emacs barrier in order to use it effectively.
>> I can't imagine any better way than emacs to frighten the newbie lisper.
>
> Anyone who wants to seriously look after Unix/Linux machines needs to
> be at least competent with vi, and if you think Emacs is frightening
> then, well. And lots of people do this, by the way. You should be
> glad that you don't have to learn ed any more.
I don't quite understand what's with unix, sure it's a good server platform,
but there's a world outside it. Some of my customers barely can use a mouse,
I'm not anywhere close to make them switch to linux !
I've been using delphi a lot, that was a pretty good editor, very easy to
use too.
Also i used visual studio quite a bit, maybe you all despise it, but still,
I used it for a while and found
there were some good tools in this environement, but they're not hindering a
simple
editing session. Just because a tool is powerfull doesn't mean it has to be
hard to use.
Anyways i'm not out to kill emacs or anything. I'll probably end up using it
myself.
Sacha
Harald Hanche-Olsen
| Just alias your emacs to notepad and you are 99% of the way there.
| I think they have it for unix now.
Reminds me of a classic: Google for "HAL model 9000" (with quotes)
to see what I mean.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Alan Mackenzie
> "Tim Bradshaw" <tfb+g...@tfeb.org> wrote in message
> news:1144758312.9...@e56g2000cwe.googlegroups.com...
>> Sacha wrote:
>>> He's got a point though,
>> I don't think he really does.
> haha well i think he does ! (this time anyways)
>>> as a newcomer to lisp, and windows user, i found it pretty hard to
>>> have to learn emacs while learning lisp... None of these two are
>>> trivial.
>> Emacs is like a guitar: imperfect, hard to learn, but you can do great
>> things with it. And, I'm glad to say, the vast majority of people who
>> understand emacs well enough to change it realise that there isn't
>> much point - not that such changes would not be a good thing, but
>> because in the finite amount of time they have, changing emacs would
>> be a less good thing than just getting on and using the flawed tool.
>> (I'm also glad that some people do work on Emacs, just as I'm glad
>> that there are people working on new guitar designs.)
> Agreed, that's why i choose to easy route...learn the keystrokes while
> not being stuck with emacs itself... When i'll feel more comfortable,
> maybe i'll switch... I just feel it is pretty bad that we have to work
> with this ages old tool.
I think it's good that we've got the choice. Emacs is decades old rather
than months old, and it has been honed to gleaming efficiency in that
time. Most other editors I find clumsy indeed.
> Lisp is supposedly one of the best languages around, it's sad we have
> to overcome the emacs barrier in order to use it effectively.
Quite possibly, Lisp is the very best general purpose language. Aren't
there any other editors around with effective support for Lisp?
> I don't quite understand what's with unix, sure it's a good server
> platform, but there's a world outside it. Some of my customers barely
> can use a mouse, I'm not anywhere close to make them switch to linux !
I can barely use a mouse. That's one reason I'm so fond of Emacs and the
Unix command line. GUI interfaces are pretty restrictive and inefficient
by comparison.
> I've been using delphi a lot, that was a pretty good editor, very easy
> to use too. Also i used visual studio quite a bit, maybe you all
> despise it, but still, I used it for a while and found there were some
> good tools in this environement, but they're not hindering a simple
> editing session.
Again, it's good we've got the choice. I found VS close to unusable,
because dialog boxes kept exploding in my face over the tiny portion of
the screen reserved for my text, and it took forever to find anything in
the rambling menu structure, and even then I had to guess what menu items
like "<system>" and "<format>" and "<compile>" actually did. MSVS
imposes a development process on you - Emacs doesn't.
> Just because a tool is powerful doesn't mean it has to be hard to use.
True. But Emacs is exceptionally easy to use. It's just hard to learn.
> Anyways i'm not out to kill emacs or anything. I'll probably end up
> using it myself.
:-)
> Sacha
--
Alan Mackenzie (Munich, Germany)
Email: aa...@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").
David Kastrup
> Sacha <n...@address.spam> wrote on Tue, 11 Apr 2006 13:02:20 GMT:
>
>> "Tim Bradshaw" <tfb+g...@tfeb.org> wrote
>
>>> Emacs is like a guitar: imperfect, hard to learn, but you can do great
>>> things with it.
>
>> Agreed, that's why i choose to easy route...learn the keystrokes
>> while not being stuck with emacs itself... When i'll feel more
>> comfortable, maybe i'll switch... I just feel it is pretty bad that
>> we have to work with this ages old tool.
>
> I think it's good that we've got the choice. Emacs is decades old
> rather than months old, and it has been honed to gleaming efficiency
> in that time.
Uh, gleaming efficiency? Sorry to disagree, but Emacs is a traveling
junk yard and freak show. A junk yard which has got everything, and
building materials for building everything else. It's not as much
"honed" rather than having lots of people making it their home and
improving their personal corner of the junk yard. People are always
running around with soldering irons and swapping their favorite pieces
of scrap and construction recipes. It is a gathering ground for Mad
Scientists(TM) in the text processing area.
> Most other editors I find clumsy indeed.
They are not necessarily clumsy. Just not accommodating. Emacs is
probably the clumsiest and most dissociated piece of software ever.
But it works with you, lives with you. It's a walrus tangoing with
you, following your lead like a feather. If you have learnt how to
properly lead and don't make it flap on your feet.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
aug...@mail.wplus.net
> Things emacs need to change for modern world:
I dislike this attitude somehow. May I ask you to change modern world
instead?
Tim Bradshaw
> I don't quite understand what's with unix, sure it's a good server platform,
> but there's a world outside it. Some of my customers barely can use a mouse,
> I'm not anywhere close to make them switch to linux !
Ignore the specific examples. The point is that when you program
computers - as when you do almost anything - you will spend your life
dealing with overcomplex crufty systems that don't really work properly
and have all sorts of historical baggage associated with them. Most
of those systems will just get in the way - however much you learn
they'll just cause you pain: programming is basically pain. Some very
few of these systems, crufty as they are, can be beaten into tools of
incredible efficiency. Emacs is one of those few. And for all sorts
of reasons, in almost all cases you're better off learning it as it is
than trying to make it fit with whatever is fashionable today: in the
same way that you're better off learning the guitar than inventing a
new, better guitar.
--tim
David Kastrup
> Sacha wrote:
>
>> I don't quite understand what's with unix, sure it's a good server platform,
>> but there's a world outside it. Some of my customers barely can use a mouse,
>> I'm not anywhere close to make them switch to linux !
>
> Ignore the specific examples. The point is that when you program
> computers - as when you do almost anything - you will spend your
> life dealing with overcomplex crufty systems that don't really work
> properly and have all sorts of historical baggage associated with
> them. Most of those systems will just get in the way - however much
> you learn they'll just cause you pain: programming is basically
> pain. Some very few of these systems, crufty as they are, can be
> beaten into tools of incredible efficiency. Emacs is one of those
> few.
Emacs has been beaten into a black hole. Get too close to it, and
you'll never escape again. It bends reality.
> And for all sorts of reasons, in almost all cases you're better off
> learning it as it is than trying to make it fit with whatever is
> fashionable today: in the same way that you're better off learning
> the guitar than inventing a new, better guitar.
A harp. Lots and lots of strings, and pedals, so that you are not
restricted to A minor, but can also play M-C-major. Harp harp harp.
Miles Bader
> also rebinds C-a to select all, instead of beginning-of-line.
Erg. That's just evil...
-Miles
--
"An atheist doesn't have to be someone who thinks he has a proof that there
can't be a god. He only has to be someone who believes that the evidence
on the God question is at a similar level to the evidence on the werewolf
question." [John McCarthy]
Larry Clapp
> Sacha <n...@address.spam> wrote on Tue, 11 Apr 2006 13:02:20 GMT:
>> Lisp is supposedly one of the best languages around, it's sad we
>> have to overcome the emacs barrier in order to use it effectively.
>
> Quite possibly, Lisp is the very best general purpose language.
> Aren't there any other editors around with effective support for
> Lisp?
There's a group working on adding Embeddable Common Lisp (ECL) to Vim.
(See http://wiki.alu.org:80/Vim_ECL.) I wouldn't go so far as to call
it "effective" yet, though.
-- Larry
Greg Menke
David Kastrup <d...@gnu.org> writes:
> Alan Mackenzie <a...@muc.de> writes:
>
> Uh, gleaming efficiency? Sorry to disagree, but Emacs is a traveling
> junk yard and freak show. A junk yard which has got everything, and
> building materials for building everything else. It's not as much
> "honed" rather than having lots of people making it their home and
> improving their personal corner of the junk yard. People are always
> running around with soldering irons and swapping their favorite pieces
> of scrap and construction recipes. It is a gathering ground for Mad
> Scientists(TM) in the text processing area.
>
> > Most other editors I find clumsy indeed.
>
> They are not necessarily clumsy. Just not accommodating. Emacs is
> probably the clumsiest and most dissociated piece of software ever.
> But it works with you, lives with you. It's a walrus tangoing with
> you, following your lead like a feather. If you have learnt how to
> properly lead and don't make it flap on your feet.
This is probably the best appraisal of Emacs I think I have ever read.
Many thanks!
Gregm
Alan Mackenzie
> Alan Mackenzie <a...@muc.de> writes:
>> Sacha <n...@address.spam> wrote on Tue, 11 Apr 2006 13:02:20 GMT:
>>> "Tim Bradshaw" <tfb+g...@tfeb.org> wrote
>>>> Emacs is like a guitar: imperfect, hard to learn, but you can do
>>>> great things with it.
>>> Agreed, that's why i choose to easy route...learn the keystrokes
>>> while not being stuck with emacs itself... When i'll feel more
>>> comfortable, maybe i'll switch... I just feel it is pretty bad that
>>> we have to work with this ages old tool.
>> I think it's good that we've got the choice. Emacs is decades old
>> rather than months old, and it has been honed to gleaming efficiency
>> in that time.
> Uh, gleaming efficiency? Sorry to disagree, but Emacs is a traveling
> junk yard and freak show.
Just like the human body after a few gazillion years of evolution, you
mean?
> A junk yard which has got everything, and building materials for
> building everything else. It's not as much "honed" rather than having
> lots of people making it their home and improving their personal corner
> of the junk yard.
But it's just brilliant for editing a TeX file or a C file, though.
> People are always running around with soldering irons and swapping
> their favorite pieces of scrap and construction recipes. It is a
> gathering ground for Mad Scientists(TM) in the text processing area.
And what other editor can offer that? :-)
>> Most other editors I find clumsy indeed.
> They are not necessarily clumsy. Just not accommodating. Emacs is
> probably the clumsiest and most dissociated piece of software ever.
> But it works with you, lives with you. It's a walrus tangoing with
> you, .....
yeah, but I'm not a carpenter[*].
> .... following your lead like a feather. If you have learnt how to
> properly lead and don't make it flap on your feet.
[*] For those from non-English speaking cultures:
"The Walrus and the Carpenter
Were walking close at hand:
They wept like anything to see
Such quantities of sand:
'If this were only cleared away,'
They said, 'it would be grand.'"
From "Through the Looking Glass" by Lewis Carroll.
Do you think we're sufficiently off-topic, yet?
> David Kastrup
Alan Mackenzie
> "Tim Bradshaw" <tfb+g...@tfeb.org> writes:
> Emacs has been beaten into a black hole. Get too close to it, and
> you'll never escape again. It bends reality.
David, is there anything which makes you happy? ;-)
>> And for all sorts of reasons, in almost all cases you're better off
>> learning it as it is than trying to make it fit with whatever is
>> fashionable today: in the same way that you're better off learning the
>> guitar than inventing a new, better guitar.
> A harp. Lots and lots of strings, and pedals, so that you are not
> restricted to A minor, but can also play M-C-major. Harp harp harp.
47 strings and 7 pedals, actually. Also 88 rotating disks, just as a
piano has 88 keys. A harp is as different from a guitar as Emacs is from
Nano. Principally, the strings are at an angle to the soundboard rather
than being parallel to it. Also, the strings on a harp are at a _much_
higher tension than those of a guitar, so you get both a higher volume of
sound and calloused fingers from it. A typical harp weighs 35 - 40 kg,
and is a bloody pain to cart around.
Ray Dillinger
Let's take this and turn it on its head.
As people who can see past the user interface, most of us
know that most of the things OP was talking about are in
fact pointless, like painting a statue. Sure, it makes
it look "more like a person" but it doesn't change what
it actually *is*. Wait another ten years for interface
conventions and preferred color schemes to change, and
the statue will need a different coat of paint. And it
still won't change what it is a single iota.
If you *were* redesigning emacs from the ground up in the
modern era, what really ought to be *done* differently?
Don't waste our time with interface crap, I mean real things
that change what the tool actually is and how it works.
Bear
Tim Bradshaw
> Also, the strings on a harp are at a _much_
> higher tension than those of a guitar, so you get both a higher volume of
> sound and calloused fingers from it.
I'm not sure about *much* - the only set of strings I have to hand for
a guitar have tensions from 15-20lb, and some very casual searching
inidcates harps might have up to 30-something. But those guitar
tensions are or fairly light strings (10-46). I'd guess that
heavily-strung guitars might double the tension. Of course
nylon-strung guitars have much lower tensions (and necks without truss
rods...). Are harps all wood? Do they have problems with falling to
bits under load like wooden-framed pianos used to?
--tim (now what does this have to do with Lisp?)
Tim Bradshaw
> Let's take this and turn it on its head.
>
> modern era, what really ought to be *done* differently?
> Don't waste our time with interface crap, I mean real things
> that change what the tool actually is and how it works.
It should be able to keep up when I type. Yes, I mean even with
font-lock turned on.
--tim
Miles Bader
> It should be able to keep up when I type. Yes, I mean even with
> font-lock turned on.
Er, can it not now?
I'm using rather old hardware (450 MHz PIII), but even the latest Emacs
with all the goo-goo turned on feels rather speedy and light-weight --
especially compared to typical modern bloatware (for a truly slothful
experience, try Eclipse or VS...).
[Of course this probably doesn't apply when you're trying to process
that massive database in a text-buffer using elisp!]
-Miles
--
"1971 pickup truck; will trade for guns"
Tim Bradshaw
> Er, can it not now?
Tragically, no.
>
> I'm using rather old hardware (450 MHz PIII), but even the latest Emacs
> with all the goo-goo turned on feels rather speedy and light-weight --
> especially compared to typical modern bloatware (for a truly slothful
> experience, try Eclipse or VS...).
I think it's just that the native mac xemacs port really sucks (*knew*
it was a mistake to build it). But still, it *is* the single thing
that would most make it better for me. I'm planning on reimplementing
it in applescript, which will probably be faster.
Damn, you've spoilt my joke now, I may have to kill you.
--tim
David Kastrup
> Miles Bader wrote:
>
>> Er, can it not now?
>
> Tragically, no.
>
>>
>> I'm using rather old hardware (450 MHz PIII), but even the latest Emacs
>> with all the goo-goo turned on feels rather speedy and light-weight --
>> especially compared to typical modern bloatware (for a truly slothful
>> experience, try Eclipse or VS...).
>
> I think it's just that the native mac xemacs port really sucks (*knew*
> it was a mistake to build it).
XEmacs is not Emacs. The font lock code of XEmacs is older than that
of Emacs 21.1, and Emacs 21.1 did not turn on font locking by default
for _good_ reason.
And what one hears about the XEmacs MacOSX port does not particularly
recommend it, anyway.
Tim Bradshaw
>
> XEmacs is not Emacs.
Um, yes, it is. It may not be whatever your little cult prefers to
anoint, but that's a different issue, and I don't really care for cults
anyway (Oh God, I just realised this is going to comp.emacs: I shall
expect people with pitchforks and torches at the door any minute,
chanting whatever slogan whoever it is you worship has blessed this
week).
>The font lock code of XEmacs is older than that
> of Emacs 21.1, and Emacs 21.1 did not turn on font locking by default
> for _good_ reason.
This is nothing to do with that - I used font lock on Xemacs on
sub-100-MHz (probably sub 50MHz) machines just fine, and before FSF
Emacs *had* fonts (well, technically I used it on lemacs of course).
>
> And what one hears about the XEmacs MacOSX port does not particularly
> recommend it, anyway.
All the emacs mac ports suck more-or-less equally. That is, as I said,
why I'm reimplementing it in applescript. (To be precise: I'm
implementing a PDP10 emulator in applescript, and I then plan on
getting ITS up and running TECO emacs.)
--tim
M Jared Finder
> M Jared Finder <ja...@hpalace.com> writes:
>> also rebinds C-a to select all, instead of beginning-of-line.
>
> Erg. That's just evil...
Why? The home and end keys are on every keyboard I've seen in the past
ten years, and work fine under xterm and ssh just fine. Why do we need
C-a and C-e any more?
-- MJF
Rob Warnock
+---------------
|
| Agreed, that's why i choose to easy route...learn the keystrokes
| while not being stuck with emacs itself... When i'll feel more
| comfortable, maybe i'll switch... I just feel it is pretty bad that
| we have to work with this ages old tool. Lisp is supposedly one of
| the best languages around, it's sad we have to overcome the emacs
| barrier in order to use it effectively.
Well, actually, you don't!! Really. Despite the cries of "Heretic!
Heretic! Burn the heretic!" you'll probably hear in response to
this post, it is *NOT* necessary to use Emacs to use Common Lisp
[or Scheme] effectively. I started using Scheme in 1992 and had
more-or-less completely switched to Common Lisp by 2000 and I
*still* use only Vi[1], and have written several medium-sized
production apps and a *host* of small tools in both Scheme and
Common Lisp without *ever* feeling that my editing environment
was in any way a hindrance. All you really need is an editor that:
- You're comfortable & fluent with, so that thinking about editing
doesn't interfere with thinking about *programming*;
- Has at least basic parenthesis matching[2];
- Has either language-sensitive indenting (Emacs) *OR* standard
text-based auto-indent (Vi) [that is, so that when you type an
"Enter" at the end of an indented line the editor starts the next
line under the first non-blank character of the previous line],
plus some way to shift a bunch of lines right or left by one column.
(It's *nice* if you can shift a whole s-expr[3], or shift by more
than one column at a time, but not necessary.)
Everything else is just gravy.[4]
If you want to learn Lisp, then LEARN LISP!! Use whatever editor you
already know, pasting code from an editor buffer into a Lisp REPL
[or do an editor "Save" and then type (LOAD "filename") in the REPL,
whichever makes more sense depending on how much has changed]. But
*don't* let learning Emacs (or Slime) slow you down! You *CAN*
learn Lisp and "use it effectively" without it. Really, you can.
Then, assuming that you become convinced that Lisp is for you, ;-}
if you later want to see whether Emacs/Slime will *further*
improve your productivity, well, then give it a try.
But *DON'T* blame Emacs for lack of success with Lisp, either
at first or later. That's just not right.
-Rob
[1] Not for lack of trying, multiple times, to switch to Emacs.
My fingers simply do *not* "chord" well -- sorry 'bout that.
And I *like* "moded" editors such as TECO, Bravo, and Vi
where lower-case characters are used for editing commands
[except in insert mode], since I tend to alternate between
fairly long periods of thinking followed by fairly long periods
of uninterrupted "inserting" followed by moderate periods of
"editing"... and then some testing & more thinking. But YMMV.
[2] Vi has matching-paren flashing *and* the ability to jump
back & forth between matching parens, as well as using such
"motion" indications as a selector for other operations.
E.g., when sitting on a paren, "d%" deletes the whole s-expr
[which you can then paste in somewhere else with "p" or "P"].
Even better, if you're sitting on a space *before* an open paren,
"d%" deletes the space, too, so you can swap two s-exprs easily.
Changing (FOO (BAR 35) (BAZ 53 21)) into (FOO (BAZ 53 21) (BAR 35))
takes just 5 keystrokes: "d%l%p". Longer than Meta-Ctrl-whatever
in Emacs, but not *that* much longer...
[3] Vi can do that. Assuming you've set your "shift width" to 1
(":se sw=1"), which IMHO is the only sane value when coding
Lisp/Scheme in Vi, then at a paren ">%" will shift all of the
lines containing the indicated s-expr right one column, and
>%...." will shift them right 5. Ditto "<%" and "<%....", etc.
[4] Well, you probably also need some kind of bit-mapped desktop
that at least lets you keep several windows open at once
(including an HTTP browser or two) and lets you cut&paste
easily between windows -- say, X Windows with even the *dumbest*
window manager, e.g., "twm" [which is what I use]. Personally,
I insist on "focus follows mouse" [as opposed to "click to focus"]
*without* "raise window on focus", which is why I don't like
MS Windows very much. [Somebody once said you can tweak it to
the prefs I like, but I never could figure out how without
breaking a bunch of ither stuff.]
Having a separate window open to a REPL into which you can
type APROPOS and DESCRIBE and INSPECT and the occasional bit
of code [or a LOAD or ASDF command] is pretty necessary, too.
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Dale Henderson
Because C-a and C-e are what I've trained my fingers to use over the
past ten years.
Because I bind [home] and [end] to beggining-of-buffer and
end-of-buffer respectively. Which is where they were bound prior to
emacs 20. (I still want to know what moron is responsible for that).
Because using [home] and [end] makes me take my fingers off the home
row.
Because M-<, M-> (or [home] [end] ) already selects all. (How often do
you need to select the entire buffer anyway.)
Because the world doesn't have to be "Windows-compatible". (Are you
guys that write window managers that steal M-TAB reading this?) Emacs
was here first. If anything, Windows should be emacs compatible.
Now I just need to go look up the rules to make windows firefox use
emacs keybindings.
Rob Warnock
+---------------
| All the emacs mac ports suck more-or-less equally. That is, as I said,
| why I'm reimplementing it in applescript. (To be precise: I'm
| implementing a PDP10 emulator in applescript, and I then plan on
| getting ITS up and running TECO emacs.)
Tim, Tim, why not just stop with TECO itself?!? ;-}
O.k., VTECO, maybe...
-Rob
p.s. Hmmm... What does TECO have that Vi doesn't?
Answer: Tests, branching, and looping in its macros.
*Real* answer: Let's port VTECO to curses! That's
the ticket!
Benjamin Teuber
Would it be so hard to make the emacs windows (besides shell-mode which
is great as it is) look like any other modern application? I know it's
just "aesthetic sugar", but to me (x)emacs looks just terribly ugly...
Benjamin
Robert Uhl
>
> Would it be so hard to make the emacs windows (besides shell-mode
> which is great as it is) look like any other modern application? I
> know it's just "aesthetic sugar", but to me (x)emacs looks just
> terribly ugly...
Well, no 'modern' apps that I know of have a mini-bar-like feature--and
it's really key to a _lot_ of what makes emacs such a great
environment. That, and the ability to get out of any problem without
harming by hitting C-g until things return to normal...
--
Robert Uhl <http://public.xdi.org/=ruhl>
`What would you do if you won $1,000,000?'
`Well, I guess I'd spend the first $900,000 on women and beer, then just
waste the rest.'
Robert Figura
> p.s. Hmmm... What does TECO have that Vi doesn't?
> Answer: Tests, branching, and looping in its macros.
It does, if you use metaprogramming.
Regards
- Robert Figura
--
/* mandlsig.c v0.23 (c) by Robert Figura */
I=1702;float O,o,i;main(l){for(;I--;putchar("oO .,\nm>cot.bitamea\
@urigrf <raguFit erobR"[I%74?I>837&874>I?I^833:l%5:5]))for(O=o=l=
0;O*O+o*o<(16^l++);o=2*O*o+I/74/11.-1,O=i)i=O*O-o*o+I%74*.04-2.2;}
David Kastrup
> David Kastrup wrote:
>>
>> XEmacs is not Emacs.
>
> Um, yes, it is.
It is a fork, so you can't blame the Emacs developers for the
deficiencies in XEmacs. Enabling font-lock by default in a version
that is clearly not fit for general use is not something that happened
in Emacs. When Emacs development made the decision to enable it by
default in future versions, _months_ of work were invested until the
state was deemed tolerable. And XEmacs has an even earlier version of
font-lock.
So for the purpose of complaining about unusable defaults, you simply
can't blame the Emacs developers, and it is extremely unfair to
chastize Emacs over several postings and then mention in passing that
you are actually talking about XEmacs, a completely different project.
> It may not be whatever your little cult prefers to anoint,
Emacs is free software, and anybody may fork it if he wishes. Blaming
the original developers for the bad design and code of people forking
it, however, is not fair.
>> The font lock code of XEmacs is older than that of Emacs 21.1, and
>> Emacs 21.1 did not turn on font locking by default for _good_
>> reason.
>
> This is nothing to do with that - I used font lock on Xemacs on
> sub-100-MHz (probably sub 50MHz) machines just fine, and before FSF
> Emacs *had* fonts (well, technically I used it on lemacs of course).
That's probably some entirely different code. Anyway, the problem
with the XEmacs font lock code is that it does _not_ work "just fine"
in all cases, merely in most. Whether this has been different at some
previous time, no idea. But at the current point of time, XEmacs
font-lock is trailing behind the Emacs code considerably.
>> And what one hears about the XEmacs MacOSX port does not
>> particularly recommend it, anyway.
>
> All the emacs mac ports suck more-or-less equally.
What did you find wrong with Yaced? I have not used it myself (as I
don't _have_ MacOSX), but from what I heard it should be a pretty
straightforward Mac Port, and MacOSX certainly appears well-supported
in the Emacs-CVS code base.
> That is, as I said, why I'm reimplementing it in applescript. (To
> be precise: I'm implementing a PDP10 emulator in applescript, and I
> then plan on getting ITS up and running TECO emacs.)
You might experience some difference in usability as compared to
Yaced, and I doubt it is all positive.
David Kastrup
The current developer variant of Emacs looks rather native on Gtk+,
Windows and MacOSX. XEmacs, on the other hand, has its own widget
abstraction layers and looks consistently ugly everywhere. But that
means that it can easier be ported to different platforms, with more
consistent results. In theory.
John Thingstad
wrote:
> Because using [home] and [end] makes me take my fingers off the home
> row.
>
> Because M-<, M-> (or [home] [end] ) already selects all. (How often do
> you need to select the entire buffer anyway.)
> Because the world doesn't have to be "Windows-compatible". (Are you
> guys that write window managers that steal M-TAB reading this?) Emacs
> was here first. If anything, Windows should be emacs compatible.
>
> Now I just need to go look up the rules to make windows firefox use
> emacs keybindings.
>
The whole point of Common User Access (CUA) is that all programs under it
behave in the same way.
Personally I find it intensly annoying when <home> takes me to the
beginning
of buffer and the first thing I do is to rebind it.
The copy and past I usually leave alone though.. I like <Ctrl>-c to
bind to the mode commands. Besides Cut-Yank (<Ctrl-<space>, <Ctrl>-k,
<Ctrl>-w, <Ctrl>-y, <Alt>-y ...) which I prefer is not compatible with
the windows copy paste anyhow. If I need to 'copy to'/'paste from' the
clipboard
I can still select them from the edit menu.
Given that the keystrokes are completely programmable reassigning
keys is a trivil affair.
What I would like, however, is to put each buffer I edit on a tabbed pane
which
is more according to windows standard and gives me a better overview.
(Yes, I know of list-buffers <Ctrl>-x-<Ctrl>-b) and switch-buffer
(<Ctrl>-x-b).)
I have used EMACS since 1987 so we go way back..
In fact programming EMACS modes was my first introduction to Lisp
programming.
Now I usually use Common-Lisp..
For the record EMACS is much more newbe friendly now then when I started
using it.
(EMACS 18 or so..)
I particular some of the more confusing commands are turned of and must be
deliberatly enabled. My first encounter with narrow-to-region (<Ctrl>-x-n-n
was not a plesant one.. Now I use it occasionally and leave it on. Just
remember
<Ctrl>-x-n-w to see the whole buffer again.
I like EMACS and I am used to it. I love the powerfull keyboard macro
features.
You dont really appreciate the need for commands like next-paragraph,
end-of-function, end-of-expression etc.. until you write generic key
macroes
to transform text. Then EMACS, in particular it's mode to filetype
commands,
really show their power. I remeber starting with a spesification of Java
byte codes
and converting it to a working java disassembler by mostly just
transforming the
document by the use of macroes in 20 minutes (!). I can't think of any
other
editor that lets me do that. Even though I use Visual Studio, which isn't
half
bad, I still sometimes find myself taking the task over in EMACS because I
need
the superior macro facilleties sometimes..
By the way if you hate EMACS (and some apperently do) UltraEdit isn't half
bad.
(on Windows)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Pascal Costanza
> "Tim Bradshaw" <tfb+g...@tfeb.org> writes:
>
>>All the emacs mac ports suck more-or-less equally.
>
>
> What did you find wrong with Yaced? I have not used it myself (as I
> don't _have_ MacOSX), but from what I heard it should be a pretty
> straightforward Mac Port, and MacOSX certainly appears well-supported
> in the Emacs-CVS code base.
Aquamacs works pretty well for me, and even fulfils many of the OP's
requirements. (However, he would probably complain that Mac OS X doesn't
look enough like Windows, or something... ;)
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Bruce Stephens
Because beginning-of-line is rather a common operation, and C-a is
more convenient than Home on most keyboards (it's right under my
fingers, and in the same place all the time, whereas Home, while on
all keyboards I use, is in slightly different positions because on
some that block of keys is 2x3, and on some it's 3x2). Wanting to
select the whole buffer strikes me as not very important---not worth
such a convenient keybinding as C-a, anyway. C-x h is quite
sufficient for that.
(For what it's worth, Home appears to be bound to
move-beginning-of-line in Emacs by default, and End appears to be
bound to move-end-of-line. It is in the Emacs I'm using at the
moment, anyway, and I'm sure I haven't bound them myself.)
Greg Menke
> David Kastrup wrote:
> > "Tim Bradshaw" <tfb+g...@tfeb.org> writes:
> >
> >>All the emacs mac ports suck more-or-less equally.
> > What did you find wrong with Yaced? I have not used it myself (as I
> > don't _have_ MacOSX), but from what I heard it should be a pretty
> > straightforward Mac Port, and MacOSX certainly appears well-supported
> > in the Emacs-CVS code base.
>
> Aquamacs works pretty well for me, and even fulfils many of the OP's
> requirements. (However, he would probably complain that Mac OS X doesn't
> look enough like Windows, or something... ;)
Aquamacs is pretty nice, just tedious to work with unless you're into
fooling around with the mouse. Same sort of problem as using NTEmacs
and cygwin on a Windows box.
Gregm
David Kastrup
NTEmacs should be a normal port IIRC, with the normal defaults. And
in general, Emacs will not open a mouse dialog when you trigger
commands by keyboard. From what I hear, Aquamacs is configured to
open a new frame (as opposed to switching buffers or opening a new
window) for everything, and that means that you can't avoid using the
GUI features for sorting out a self-cluttering desktop.
But most other Emacsen (including the Yaced bundle for MacOSX) should
not do that.
Alan Mackenzie
> Alan Mackenzie wrote:
>> Also, the strings on a harp are at a _much_ higher tension than those
>> of a guitar, so you get both a higher volume of sound and calloused
>> fingers from it.
> I'm not sure about *much* - the only set of strings I have to hand for
> a guitar have tensions from 15-20lb, and some very casual searching
> inidcates harps might have up to 30-something. But those guitar
> tensions are or fairly light strings (10-46). I'd guess that
> heavily-strung guitars might double the tension. Of course
> nylon-strung guitars have much lower tensions (and necks without truss
> rods...).
I've never measured the tension. However, it really is much higher on a
harp than a guitar. To pluck a guitar string, you can tickle it with a
finger. To pluck a harp string requires firm muscular support from the
wrist and arm.
> Are harps all wood? Do they have problems with falling to bits under
> load like wooden-framed pianos used to?
Most of the structural bits are wood. The soundboard is always wood,
otherwise it wouldn't sound right. I think the top is, too. On my harp,
the column is carbon fibre for lightness. Harps don't fall to bits under
the load, no - the tension from the 47 strings is an order of magnitude
less than that of a piano's ~220. However, if you let a harp dry out
(several years of very dry air) or swell up from dampness (several years
of very humid air) it can come apart. And if you leave one in a hot car,
the glue can melt and the whole thing comes adrift - so I've been told.
> --tim (now what does this have to do with Lisp?)
:-)
Pascal Costanza
> Greg Menke <gregm-...@toadmail.com> writes:
>
>>Aquamacs is pretty nice, just tedious to work with unless you're
>>into fooling around with the mouse. Same sort of problem as using
>>NTEmacs and cygwin on a Windows box.
>
> NTEmacs should be a normal port IIRC, with the normal defaults. And
> in general, Emacs will not open a mouse dialog when you trigger
> commands by keyboard. From what I hear, Aquamacs is configured to
> open a new frame (as opposed to switching buffers or opening a new
> window) for everything, and that means that you can't avoid using the
> GUI features for sorting out a self-cluttering desktop.
You can use Command-~ for switching between frames/windows, and the Mac
OS X Expose feature to get an overview of all frames/windows, also via
keyboard shortcuts. It works quite well this way.
funkyj
thread to rest.
--fj
David Kastrup
> I think someone needs to be compared to hitler before we can put the
> thread to rest.
Is that the regular procedure to obey also when the combatants are
situated in Germany?
Burton Samograd
> I think someone needs to be compared to hitler before we can put the
> thread to rest.
I wonder, would hitler have used emacs?
<duck>
--
burton samograd kruhft .at. gmail
kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com
Greg Menke
David Kastrup <d...@gnu.org> writes:
The biggest problem with NTEmacs & cygwin is NTEmacs is aware of drive
letters but cygwin wants /cygdrive/?/ where ? is the drive letter. Not
a big deal once you're used to it. I've had numerous tty problems with
cygwin emacs so haven't tried using it in a while.
As far as OS X, the gui & mouse are just too tedious. I find it easier
to use plain emacs -nw in multiple terminal windows and get on with the
job at hand. My preference with Mac hardware is to put Linux on it and
run Windowmaker.
Gregm
rsher...@gmail.com
Burton Samograd wrote:
> "funkyj" <fun...@gmail.com> writes:
>
> > I think someone needs to be compared to hitler before we can put the
> > thread to rest.
>
> I wonder, would hitler have used emacs?
No. Too many security issues. See:
http://groups.google.com/group/gnu.emacs.help/browse_frm/thread/47bc043c2257b9a2/f4f658199b65eeaf?hl=en&lr=&ie=UTF-8&rnum=2&prev=/groups%3Fq%3Demacs%2Bjews%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D989898671967295%2540amnet.net.ae%26rnum%3D2#f4f658199b65eeaf
David Kastrup
> Burton Samograd wrote:
>> "funkyj" <fun...@gmail.com> writes:
>>
>> > I think someone needs to be compared to hitler before we can put the
>> > thread to rest.
>>
>> I wonder, would hitler have used emacs?
>
> No. Too many security issues. [Jewish conspiracy thread link]
He did not have much of a problem with appropriating other stuff from
such a purported source, and "security issues" for someone indulging
in a Dreifrontenkrieg? Well, Emacs may be taking a stand against
XEmacs, vi and Windows, but is lacking persuasion. It comes with
several vi emulators, has mimicked some XEmacs features and runs on
Windows.
Tom Lord
Ray Dillinger wrote:
> Let's take this and turn it on its head.
>
> As people who can see past the user interface, most of us
> know that most of the things OP was talking about are in
> fact pointless, like painting a statue. Sure, it makes it
> look "more like a person" but it doesn't change what it
> actually *is*. Wait another ten years for interface
> conventions and preferred color schemes to change, and the
> statue will need a different coat of paint. And it still
> won't change what it is a single iota.
That's right. Evidence can be found for this, too, in the
fact that many current aspects of the GUI surface were, when
introduced, considered evidence of the "modernization of
Emacs". That was then.
Nevertheless, there is something to say to this phenomenon:
Take just about anyone who has used a couple of
Windows-style apps (that includes things like Open Office or
Gnome foo), plunk them down in front of a new app in that
style, tell them in a couple sentences what they can use the
app for, and most times they'll figure out 80% of what they
need from there, just by playing around. Maybe a small
number of questions they need to ask the user sitting next
to them.
The same is true for Emacs users relative to new major modes
but: (a) there's many more people in that other group; (b) a
lot of the little details of that other style of UI are
actually pretty good even if every app in that style gets a
number of major UI points -- well -- wrong.
Often I encounter little programs where a good solution
would be "Write a tiny little interactive program for these
users!" And often, abstractly speaking, the little
interactive program would take some small number of hours to
do in Emacs with a result that was really, really, rich in
functionality.
Almost always, that convenient path isn't a real option
because there's no "budget" for training users that much.
Let's see -- an hour on "buffers" and basic editting. An
hour on incremental search. An hour on windows and frames.
An hour on the new app. An hour practicing. Then N-hours
of support in coming weeks to handle the panic calls. Then
a similar N hours for every new user (usually someone's
employee) that walks in the door. At least for years to
come until the new paradigm spreads.
It's just an empirical fact that in the judgment of nearly
all customers, the time value of money is such that they
would rather amortize the costs of a weaker, harder to
extend app over years of employees being slightly
inefficient rather than eat those up-front costs to give
their users new computing skills.
UI improvements to Emacs to make that class of users more
comfortable might well change the economics of the skill of
hacking Emacs. The real problem is that the current
implementation (I'll speak of GNU but I think this applies
to XEmacs, too) isn't really powerful enough (in the right
areas) to do a good job of supporting those users, no matter
how much Emacs lisp hacking you do.
Which brings us us to your question:
> If you *were* redesigning emacs from the ground up in the
> modern era, what really ought to be *done* differently?
> Don't waste our time with interface crap, I mean real
> things that change what the tool actually is and how it
> works.
> Bear
Why do you ask? You wanna help hack such a
redesign/rewrite? You live in the Bay Area, right? Contact
me off list if you want to put some time into such a
project.
An obvious thing is an improved lisp (performance, dialect,
modules, threads). One side effect should be less code not
written in lisp.
Less obvious: it needs more buffer types. Minimally, 2d
data (from bitmaps to pixmaps to arrays of arbitrary values)
including support for properties and overlays on regions.
Perhaps: 3d data. Far out: Nd data with projections into
navigable dimensionality (2, or 3). Also: simple tree data
with per-node properties (think: drawing editor, or XHTML
browser, e.g.).
Less obvious: multiple concurrent complex commands is good
but mandating a single thread and a recursive minibuffer
model is bogus.
Tricky: more flexible display options. I don't mean "tree
of widgets" in the conventional sense -- an abstraction that
runs contrary to Emacs' excellent take on the model, view,
controller split. In conjunction with fixing display, the
input event model needs some complementary generalization.
Relaxation of the "also works on a terminal" model. Only
some types of display can work on a terminal (and, of
course, they should).
Synthetic buffers: better support for the live embedding of
one buffer inside of another.
So, those are some things that should be done differently.
The net result takes Emacs much further in the direction of
fully general application framework based on a small number
concepts with a strong (and post this redesign, more
powerful) emphasis on re-usable components.
Support only Unicode-like character and string encodings
internally. Read and write anything, sure. Follow the
programmatic model of Unicode internally. Add some
extensions such as excellent support for non-standard
characters. Make good use of codepoint properties.
Add a *really* good regexp engine with heavy emphasis on
low-level DFA support (on-the-fly DFA construction from NFA
spec, suspendable and cheaply forked DFAs). This is mostly
for text and tree editting. In lisp, highly error-tolerant
incremental lexing and parsing (including isolated restarts
after plain-text edits of regions). "I got yr font-lock and
syntax-directed-editting modes right here, babe."
How to do these things, including how to translate finite
design/hacking bandwidth into an implementation path that
becomes financially self-sustaining early is a separate
question. An *interesting* and *current* question, mind
you. But a separate question nonetheless.
So, again, why do you ask?
-t
funkyj
http://en.wikipedia.org/wiki/Godwin%27s_law
Even if localization is allowed I would expect Godwin's Law to require
that a politically/emotionally charged analogy.
Given that hitler/nazism is probably more emotionally charged in
germany than anywhere else it would seem an especially proper occurance
of Godwin's law being fufilled when used with a german combatant.
Miles Bader
>> I think someone needs to be compared to hitler before we can put the
>> thread to rest.
>
> Is that the regular procedure to obey also when the combatants are
> situated in Germany?
Well the results are certainly more entertaining in that case...
-Miles
--
.Numeric stability is probably not all that important when you're guessing.
funkyj
> The biggest problem with NTEmacs & cygwin is NTEmacs is aware of drive
> letters but cygwin wants /cygdrive/?/ where ? is the drive letter. Not
> a big deal once you're used to it.
FYI: some useful cygwin related stuff from my window .emacs
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; ;; The latest version of cygwin-mount.el can always be found at
;; ;; http://www.blarg.net/~offby1/cygwin-mount/
;; ;
;; ; 'cygwin-mount' makes emacs/gdb mode work properly under cygwin.
In
;; ; particular, it helps emacs find source files. We need this
because
;; ; gdb is a cygwin program and uses unix/cygwin style file name paths
;; ; (e.g. "/home/xyz/.emacs") while GNU emacs for NT is an MSWindows
;; ; Program that understands DOS style file names
;; ; (e.g. "C:/cygwin/home/xyz/.emacs"). the cygwin-mount.el package
;; ; bridges this gap.
(require 'cygwin-mount)
(cygwin-mount-activate)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; from
;; http://cygwin.com/faq/faq_4.html#SEC62
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; This assumes that Cygwin is installed in C:\cygwin (the
;; default) and that C:\cygwin\bin is not already in your
;; Windows Path (it generally should not be).
;;
(setq exec-path (cons "C:/cygwin/bin" exec-path))
(setenv "PATH" (concat "C:\\cygwin\\bin;" (getenv "PATH")))
;;
;; NT-emacs assumes a Windows command shell, which you change
;; here.
;;
(setq process-coding-system-alist '(("bash" . undecided-unix)))
(setq shell-file-name "bash")
(setenv "SHELL" shell-file-name)
(setq explicit-shell-file-name shell-file-name)
;;
;; This removes unsightly ^M characters that would otherwise
;; appear in the output of java applications.
;;
(add-hook 'comint-output-filter-functions
'comint-strip-ctrl-m)
David Kastrup
> I'm not sure. Does Godwin's Law include localizations?
>
> http://en.wikipedia.org/wiki/Godwin%27s_law
>
> Even if localization is allowed I would expect Godwin's Law to require
> that a politically/emotionally charged analogy.
Well, Bush is pretty good at ignoring the laws of his country, lying
to his people, ignoring international treaties and abolishing human
rights. I don't know whether beating about the Bush will do the
trick, though.
> Given that hitler/nazism is probably more emotionally charged in
> germany than anywhere else it would seem an especially proper
> occurance of Godwin's law being fufilled when used with a german
> combatant.
Maybe somebody else wants to fill in the required emotionally charged
parts after I have given a basic lead?
Emilio Lopes
> Miles Bader wrote:
>> M Jared Finder <ja...@hpalace.com> writes:
>>> also rebinds C-a to select all, instead of beginning-of-line.
>> Erg. That's just evil...
> Why? The home and end keys are on every keyboard I've seen in the
> past ten years, and work fine under xterm and ssh just fine. Why do
> we need C-a and C-e any more?
People who can touch-type find it very annoying to have to leave the
home row for such a common task as `beginning-of-line'.
--
Emílio C. Lopes
Munich, Germany
Harald Hanche-Olsen
So I can have a long running emacs on the computer in my office, and
when I get home I can connect to my office emacs and keep on editing
files with the entire setup, including the undo history, intact. And
I won't get into trouble because I forgot to save a buffer before I
left work and now I want to continue editing the same file from home.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
David Kastrup
> So long as we're dreaming, I'd like to see emacs server
> functionality. So I can have a long running emacs on the computer
> in my office, and when I get home I can connect to my office emacs
> and keep on editing files with the entire setup, including the undo
> history, intact. And I won't get into trouble because I forgot to
> save a buffer before I left work and now I want to continue editing
> the same file from home.
The multi-tty branch exists.
David Kastrup
> So long as we're dreaming, I'd like to see emacs server
> functionality. So I can have a long running emacs on the computer
> in my office, and when I get home I can connect to my office emacs
> and keep on editing files with the entire setup, including the undo
> history, intact. And I won't get into trouble because I forgot to
> save a buffer before I left work and now I want to continue editing
> the same file from home.
The multi-tty branch exists and is slated for inclusion in Emacs 23.1.
Christophe Rhodes
this comes across the wrong way ]
"Tom Lord" <lo...@emf.net> writes:
> Why do you ask? You wanna help hack such a
> redesign/rewrite? You live in the Bay Area, right? Contact
> me off list if you want to put some time into such a
> project.
>
> An obvious thing is an improved lisp (performance, dialect,
> modules, threads). One side effect should be less code not
> written in lisp.
If Common Lisp is an improved lisp from your point of view, can I
encourage you to look at the Climacs project? I am away from
development for a few days, but I can try to make a binary available
for your platform if compiling it and its dependencies looks too
daunting. (You are most welcome to contact me or the climacs
development mailing list for more information.)
Christophe
Bill Atkins
Why do you use "yr" instead of "your" but write the rest of your posts
in totally coherent English?
I have never seen anything so bizarre.
Ari Johnson
Christophe Rhodes <cs...@cam.ac.uk> writes:
> If Common Lisp is an improved lisp from your point of view, can I
> encourage you to look at the Climacs project? I am away from
> development for a few days, but I can try to make a binary available
> for your platform if compiling it and its dependencies looks too
> daunting. (You are most welcome to contact me or the climacs
> development mailing list for more information.)
The problem I have with Climacs is that I can't use it. All my
machines are Macs except for Linux servers, so X11 applications (while
technically usable) are not useful to me. I wish that I had the CLIM
and Cocoa experience necessary to create an OSX CLIM, as that is
something I see as being an immensely useful project.
The other problem that many people would have with adopting Climacs is
that it appears to the average user to be comparatively difficult to
install and run, when compared head-to-head against Emacs. Emacs is
well-tested on all platforms it runs on and Elisp is consistent across
them. Also, there is little danger that a piece of Elisp code will
step outside of Emacs to do something naughty; whereas, with a CL
editor, there is much more opportunity for a script to do something
outside the scope of the editor. Furthermore, you would be best to
package a CL with the editor, since the capabilities of a given CL
change with each version. (Witness that Debian 'sarge' comes with
SBCL 0.8.16, which cannot run the Swank component of SLIME post-April
19, 2005.) So you have a size issue - Emacs is big, but a CL is not a
tiny thing to be throwing around along with it.
Do you have plans to address these issues?
Edward Dodge
> As far as OS X, the gui & mouse are just too tedious. I find it easier
> to use plain emacs -nw in multiple terminal windows and get on with the
> job at hand. My preference with Mac hardware is to put Linux on it and
> run Windowmaker.
Why bother with Linux just to use an X11 manager? Install X11.app on OSX and
then install the X11-version of EMACS. Run OSX and an X-Window window-manager
(complete with all your X-based apps) at the same time.
--
Edward Dodge
__o
_`\(,_
(_)/ (_) --- ---
Bill Atkins
> [...]
> them. Also, there is little danger that a piece of Elisp code will
> step outside of Emacs to do something naughty; whereas, with a CL
> editor, there is much more opportunity for a script to do something
> outside the scope of the editor. Furthermore, you would be best to
> [...]
Really?
;; intentionally misspelled to prevent accidental evaluation, but
;; you get the idea
(shel-command "rm / -rf")
I'm not aware of any effort on Elisp's part to prevent code from doing
damage to a machine.
Bill
Ari Johnson
I was thinking more in terms of within the Lisp but outside of the
editor. I'm not well-versed in elisp, but it seems to me that it
would be easier to break the editor in CL than in elisp, given that at
least part of Emacs is not written in elisp and thus at least part of
it cannot be broken with elisp alone. I may be entirely wrong.
Tom Lord
Christophe Rhodes wrote:
> If Common Lisp is an improved lisp from your point of view,
Not for the purpose of an Emacs on a non-lisp-machine platform.
> can I
> encourage you to look at the Climacs project?
You did and I did. The notes in the "how to contribute" section about
what is not of interest suggest we have very different goals.
Thanks, though. Looks like a potentially fun project in its own right.
-t
Tom Lord
Bill Atkins wrote:
> Why do you use "yr" instead of "your" but write the rest of your posts
> in totally coherent English?
>
> I have never seen anything so bizarre.
I am sorry for you that you have led such a sheltered life.
-t
Greg Menke
Edward Dodge <us...@foo.bar> writes:
Its not the X11 I'm so interested in, its the non-bizarre suite of gnu
stuff, easily configurable OS & daemons, etc..
OS X is extremely tedious to configure once you get beyond what the
click-and-drool control panel gives you. For instance, try to get OS X
to stop hostname'ing itself when it gets an address from an ISP. It
wouldn't be so bad if OS X offered virtual terminals like Linux does-
which I make a lot of use of. There are also some subtle fragility
relating to OS bootup and ipfw, any custom firewall/gateway/nat
configuration has to be hacked with great care. And last time I checked
there is an almost complete lack of detailed OS config documentation
which doesn't help.
Gregm
Robert Strandh
prime time, but Christophe did, so now I feel I should comment.
Ari Johnson <iamt...@gmail.com> writes:
> The problem I have with Climacs is that I can't use it. All my
> machines are Macs except for Linux servers, so X11 applications (while
> technically usable) are not useful to me. I wish that I had the CLIM
> and Cocoa experience necessary to create an OSX CLIM, as that is
> something I see as being an immensely useful project.
Right. As you know, Climacs is a CLIM application and not an X11
application. Though you can argue that McCLIM is mostly an X11
application, so Climacs right now indirectly requires X11 as you have
realized. However, I maintain that using CLIM as the interface
substrate for Climacs was and is the right decision because it creates
infrastructure that is useful elsewhere. We welcome more backends for
McCLIM that will make Climacs and other CLIM applications useful on
platforms that do not have X11, but as with most free software
projects, we need help to do this.
> The other problem that many people would have with adopting Climacs is
> that it appears to the average user to be comparatively difficult to
> install and run, when compared head-to-head against Emacs. Emacs is
> well-tested on all platforms it runs on and Elisp is consistent across
> them.
While I agree with this in principle, it is hardly a fair comparison.
Like I said, Climacs is not ready for prime time, and I don't know
when it will be. Making it easy to install and run is just one of
literally hundreds of little tedious issues that need to be
addressed. I sure hope they will be addressed eventually, but it is
not possible for a handful of part-time developers to do this alone.
> Also, there is little danger that a piece of Elisp code will
> step outside of Emacs to do something naughty; whereas, with a CL
> editor, there is much more opportunity for a script to do something
> outside the scope of the editor.
This is danger but especially a major advantage. It allows much
better integration with Common Lisp than can be had with an external
editor. And Climacs was written primarily to be part of an IDE for
CL. I would prefer to address this problem by making current CL
implementations enforce the restrictions on the COMMON-LISP package
that seem to be designed to avoid disasters as a result of bad
application programs. Package locks are a start but not enough.
> Furthermore, you would be best to
> package a CL with the editor, since the capabilities of a given CL
> change with each version. (Witness that Debian 'sarge' comes with
> SBCL 0.8.16, which cannot run the Swank component of SLIME post-April
> 19, 2005.) So you have a size issue - Emacs is big, but a CL is not a
> tiny thing to be throwing around along with it.
Personally, I rather hope that the capabilities of CL implementations
will settle down so that we would not have to distribute CL with
Climacs. If we had to distribute a CL with Climacs, this would defeat
some of the purposes with Climacs, namely to be used with an IDE for
your preferred CL implementation.
> Do you have plans to address these issues?
I could answer "of course", but in reality there are no plans to do
anything whatsoever. All we have is a bunch of part-time developers
(who sometimes get full-time jobs and quit developing Climacs) who do
whatever they please, find interesting, and have time for.
Personally, I think Climacs is a very interesting project, in that I
think we have shown that a modern Emacs can be implemented with
relatively little effort (I don't think we have spent even a single
person-year on it yet, unless you count applications such as the
Tabcode editor built as Climacs applications). We have a very nice
(in my opinion) buffer protocol and several different implementations
of it that can function together. We also have a much better
infrastructure for syntax analysis of the buffer contents than Emacs
does, and quite a decent CL syntax module to show that. For Common
Lisp, our indentation code already does a better job than that of
Emacs.
Personally, I have no ambition for Climacs to ever do what Emacs
currently does, for the simple reason that many of the existing Elisp
applications such as dired, Gnus, VM, etc would be better implemented
as CLIM applications, possibly with Climacs used when an editor is
required. Rather, I see Climacs as part of a set of collaborating CL
and CLIM applications to run in a single image, and with tight
integration, allowing them to share data structures in core. I do
think that Climacs is a great base for a modern Emacs implementation
using a modern and great Lisp dialect.
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
Robert Strandh
> Bill Atkins <NOatki...@rpi.edu> writes:
>
> > I'm not aware of any effort on Elisp's part to prevent code from doing
> > damage to a machine.
>
> I was thinking more in terms of within the Lisp but outside of the
> editor. I'm not well-versed in elisp, but it seems to me that it
> would be easier to break the editor in CL than in elisp, given that at
> least part of Emacs is not written in elisp and thus at least part of
> it cannot be broken with elisp alone. I may be entirely wrong.
I think you probably are :-)
Seriously, the moment you decide to give your users the power to
modify the behavior of the application with the power of a programming
language like Lisp, you also make it possible for them to break it.
This is a feature and not a bug. You would not want this to happen
accidentally, of course, but I think it would be a serious mistake to
try to prevent your users from breaking certain parts of the editor
by making it impossible to adapt those parts to their own needs.
Tim X
> Sacha wrote:
>> He's got a point though,
>
> I don't think he really does.
>
> Before I start: yes, emacs is crufty in a lot of ways (horrible lisp
> dialect etc), yes it's left-field in lots of ways (odd key bindings for
> people coming from a Windowsoid background), yes it's big and
> complicated. Yes, yes yes.
>
>> as a newcomer to lisp, and windows user,
>> i found it pretty hard to have to learn emacs while learning lisp...
>> None of these two are trivial.
>
> Who said learning to program in a new language should be trivial? And
> do you *really* think that Emacs is the thing that's making it too hard
> to learn? Programming is a fairly intellectually hard activity, and if
> you're going to succeed at it then you probably won't be put off by
> something like Emacs - some time you're going to have to deal with
> J2EE, or Unix or something, and if you think that Emacs is hard &
> cruftily designed, then you have another think coming.
>
> I play the guitar: not, generally, very well, but well enough. Playing
> a musical instrument is kind of like programming: it's hard, and the
> tools you use are generally not perfectly designed. And two things are
> immediately apparent. Firstly people who try the guitar and complain
> because the strings are too tight, the hand position makes their wrists
> sore, it's just basically impossible to tune the thing right (really,
> it is) and any of the myriad of other things which are objectively
> wrong with guitars don't get very far. Secondly, of people who persist
> and through talent and hard work become great guitarists *very few*
> redesign the instrument. Not because it's a perfect design - it's
> clearly not - but because it's a good enough design and there are more
> important things to do, like playing music.
>
> Emacs is like a guitar: imperfect, hard to learn, but you can do great
> things with it. And, I'm glad to say, the vast majority of people who
> understand emacs well enough to change it realise that there isn't much
> point - not that such changes would not be a good thing, but because in
> the finite amount of time they have, changing emacs would be a less
> good thing than just getting on and using the flawed tool. (I'm also
> glad that some people do work on Emacs, just as I'm glad that there are
> people working on new guitar designs.)
>
>> I can't imagine any better way than emacs to frighten the newbie lisper.
>
> Anyone who wants to seriously look after Unix/Linux machines needs to
> be at least competent with vi, and if you think Emacs is frightening
> then, well. And lots of people do this, by the way. You should be
> glad that you don't have to learn ed any more.
>
Pretty well said.
The thing which keeps striking me about the moaning regarding emacs is
why the hell, if all these people find it so bad, none of them have
come up with a replacement. Its not like it cost them anything and
therefore they have some right to complain or that there isn't an
alternative editor.
Its very easy to sit back and criticise things, but if you really have
something valid to prove, go out and do it and stop bloody moaning.
and of course, if you don't like it and don't want to create an
alternative, well then just don't use it. There is no law that says
because you want to do lisp you have to use emacs. If you like another
tool use it.
Emacs may not be perfect and I've never heard anyone say it was. the
learning curve can be difficult and yes, you may have to re-think some
of the paradigms you have taken for granted. However, surely its
obvious that with power comes complexity and a requirement to learn
how to harness that power. I don't understand where the mindset comes
from that says a powerful tool like emacs should be as easy to use as
wordpad.
The same goes for Xah and his unix hating attitude. He puts in hours
of time writing about how awful it is and how it should be wiped from
the planet - yet it seems to be what he uses all the time. If he
thinks other operating systems are so superior, why doesn't he just
ignore what he doesn't like and just get on with what he does think is
good - thats certainly how I deal with MS windows.
Tim
--
tcross (at) rapttech dot com dot au
Tim X
> David Kastrup wrote:
>>
>> XEmacs is not Emacs.
>
> Um, yes, it is. It may not be whatever your little cult prefers to
> anoint, but that's a different issue, and I don't really care for cults
> anyway (Oh God, I just realised this is going to comp.emacs: I shall
> expect people with pitchforks and torches at the door any minute,
> chanting whatever slogan whoever it is you worship has blessed this
> week).
>
While I *think* I understand what your saying - ie "emacs" in the
generic sense refers to both Emacs and XEmacs (and microEmacs and
various other "emacs" clones), but since they have different code
bases, technically they are not the same thing. They do have a lot of similarity,
but also have significant enough differences that you find packages
which will run under both are full of code which tests what flavor
you are running under in order to select the appropriate function etc
and there are plenty of packages which will run under one flavor but
not the other.
I only mention this, apart from being pedantic, because many new users
find things confusing enough and the misconception that emacs and
xemacs are the same thing often creates confusion and problems that
further frustrate those who are already fairly overwhelmed. Lets not
add to their confusion if not necessary. Xemacs is *not* the X version
of emacs - it is a code fork that has evolved along its own lines, its
.emacs files are not compatible, it uses different subsystems and
functions, has different strengths and weaknesses, supports different
key binding syntax, has different standard 'built-in' features etc.
What it does have in common is the initial "emacs philosophy", uses
elisp as an extension tool and shares many of the same concepts - but
it is different. To some extent, you could draw an analagy to cars -
two different models have a lot of similar characteristics and operate
on similar principles - sometimes, you may be able to interchange some
parts, but they are not the same thing. You may have the same attitude
to them all - you could be someone who believes all cars are evil and
bicycles are superior because they are simple and easy to learn, but
this doesn't mean all cars are actually the same.
tim
Tim X
> One more thing (although I don't quite agree with the others...):
>
> Would it be so hard to make the emacs windows (besides shell-mode
> which is great as it is) look like any other modern application? I
> know it's just "aesthetic sugar", but to me (x)emacs looks just
> terribly ugly...
>
> Benjamin
What do you think of emacs 22 built with GTK rather than the older X
libraries? Is that more what you would consider "modern" or does it
have to be modern in the sense of MS Windows look and feel?
Personally, I like the simplicity of a basic emacs with toolbars
turned off.
Tim
David Kastrup
"Tim Bradshaw" <tfb+g...@tfeb.org> writes:
> David Kastrup wrote:
>>
>> XEmacs is not Emacs.
>
> Um, yes, it is. It may not be whatever your little cult prefers to
> anoint, but that's a different issue.
It is not. Emacs is what my "little cult" (Emacs developers and the
FSF as principal copyright holder of Emacs and probably largest single
copyright holder of XEmacs) is _maintaining_; anointment is
irrelevant. And you were complaining about Emacs' usability. The
Emacs developers are not responsible for XEmacs usability, in
particular when XEmacs developers choose to do things differently.
If XEmacs developers choose that it is ok to have an innocent XEmacs
get hanged occasionally while font locking, it is not the rope maker
who is responsible for the bad judgment.
David Kastrup
> What do you think of emacs 22 built with GTK rather than the older X
> libraries? Is that more what you would consider "modern" or does it
> have to be modern in the sense of MS Windows look and feel?
>
> Personally, I like the simplicity of a basic emacs with toolbars
> turned off.
Everybody I know turns the toolbars off, including myself. I still
find it very reasonable to have them on by default. Not for the sake
of "simplicity" (that's not really what Emacs is renowned for) but
screen estate.
David Kastrup
> What do you think of emacs 22 built with GTK rather than the older X
> libraries? Is that more what you would consider "modern" or does it
> have to be modern in the sense of MS Windows look and feel?
>
> Personally, I like the simplicity of a basic emacs with toolbars
> turned off.
Everybody I know turns the toolbars off, including myself. Not for
the sake of "simplicity" (that's not really what Emacs is renowned
for) but screen estate.
I still find it very reasonable to have them on by default, for
meeting beginners' needs.
Floyd L. Davidson
>Benjamin Teuber <bet...@web.de> writes:
>
>> One more thing (although I don't quite agree with the others...):
>>
>> Would it be so hard to make the emacs windows (besides shell-mode
>> which is great as it is) look like any other modern application? I
>> know it's just "aesthetic sugar", but to me (x)emacs looks just
>> terribly ugly...
>>
>> Benjamin
>
>What do you think of emacs 22 built with GTK rather than the older X
>libraries? Is that more what you would consider "modern" or does it
>have to be modern in the sense of MS Windows look and feel?
That is exactly the point. These folks are defining *modern* to
be whatever it is they have already learned. Whether it is
better implemented, better planned, or better philosophically
has nothing to do with their complaint.
Which of course makes the complaint useless.
>Personally, I like the simplicity of a basic emacs with toolbars
>turned off.
Which points up the simple fact that "emacs" (in most of its
many variations) allows people who want whatever they are
comfortable with to have it, even if it is not the *right* way
(i.e., best thought out) to use an editor. Adaptions like icon
driven toolbars are available. Providing them does *not*
interfere with implementing the best possible interface to an
editor. That is true of a toolbar even if it is turned on by
default (as long as turning it off is easy).
On the other hand I would *grossly* disagree with most of the
various suggestions for changing default key bindings! That
would interfere, and should be avoided. The fact that Microsoft
did not spend enough time designing a keyboard interface does
*not* mean that any version of emacs should revert to what
Microsoft uses, even if it is a more commonly used interface.
The emacs interface should *never* be guided by a popularity
contest amongst people who are unaware of the differences. It
should remain directed at providing the best possible interface,
even if it is not easy to learn as a "second language".
This is not to say that emacs cannot and will not be improved,
but those who complain need to realize that looking at what
Microsoft has done is *not* the direction towards improvement.
It was *intended* to be different for the mere purpose of being
different, not better.
--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) fl...@apaflo.com
John Thingstad
wrote:
> On the other hand I would *grossly* disagree with most of the
> various suggestions for changing default key bindings! That
> would interfere, and should be avoided. The fact that Microsoft
> did not spend enough time designing a keyboard interface does
> *not* mean that any version of emacs should revert to what
> Microsoft uses, even if it is a more commonly used interface.
>
The microsoft key inteface is part of the Common User Access Document
(CUA).
It was developed by IBM, not Microsoft. And they did spend the best part of
two years carefully thinking it out. That noone ever did this for
X-Windows,
now that is obvious.
With upteent window managers and people typically using software written
for
several you never know what you are going to get.
Every program on it's own in a sense defeats the point of a integrated
inteface.
> The emacs interface should *never* be guided by a popularity
> contest amongst people who are unaware of the differences. It
> should remain directed at providing the best possible interface,
> even if it is not easy to learn as a "second language".
>
People will have a easier time learning to use it if things work as the
expect.
Arrow keys, home, end etc.. It is visually intuetive to see what these keys
do. If they have to look up basic commands like moving a cursor that
alone would turn many away from the program.
> This is not to say that emacs cannot and will not be improved,
> but those who complain need to realize that looking at what
> Microsoft has done is *not* the direction towards improvement.
> It was *intended* to be different for the mere purpose of being
> different, not better.
>
Being different for it's own sake was never the point of Emacs.
It simply existed long before Windows or even X-Windows.
That Mac and Window's users have come to expect certain operations
to work is reasonable and indeed Emacs has come a long way in accomodating
them. I think they deserve praise for that.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
David Kastrup
> The microsoft key inteface is part of the Common User Access
> Document (CUA). It was developed by IBM, not Microsoft. And they
> did spend the best part of two years carefully thinking it out. That
> noone ever did this for X-Windows, now that is obvious.
Come off it. The X Window system is a network transparent hardware
interface, not a GUI. So it can hardly be blamed to not have any
default keybindings. That's not its job.
Alan Mackenzie
> "Tim Bradshaw" <tfb+g...@tfeb.org> writes:
>> David Kastrup wrote:
>>> XEmacs is not Emacs.
>> Um, yes, it is.
> It is a fork, so you can't blame the Emacs developers for the
> deficiencies in XEmacs. Enabling font-lock by default in a version
> that is clearly not fit for general use is not something that happened
> in Emacs. When Emacs development made the decision to enable it by
> default in future versions, _months_ of work were invested until the
> state was deemed tolerable. And XEmacs has an even earlier version of
> font-lock.
> So for the purpose of complaining about unusable defaults, you simply
> can't blame the Emacs developers, and it is extremely unfair to
> chastize Emacs over several postings and then mention in passing that
> you are actually talking about XEmacs, a completely different project.
"Emacs" does not always, or even usually, mean specifically "GNU Emacs"
and this newsgroup, comp.emacs, is intended for discussion of _all_
Emacs editors.
>> I used font lock on Xemacs on sub-100-MHz (probably sub 50MHz)
>> machines just fine, and before FSF Emacs *had* fonts (well,
>> technically I used it on lemacs of course).
> That's probably some entirely different code. Anyway, the problem
> with the XEmacs font lock code is that it does _not_ work "just fine"
> in all cases, merely in most.
The font locking in GNU Emacs also works "just fine" only in most cases.
As you will recall, there have been heated debates on emacs-devel in the
last few weeks about how best to fix some of the remaining problems.
> Whether this has been different at some previous time, no idea. But at
> the current point of time, XEmacs font-lock is trailing behind the
> Emacs code considerably.
"Considerably"? I don't know about that. It works just fine most of the
time.
> David Kastrup
--
Alan Mackenzie (Munich, Germany)
Email: aa...@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").
John Thingstad
I said the X-windows system, not the X protocol.
And yes, it was experimental and buildt to discover
what a GUI should behave like so it laid most decitions open.
Be that as it may. You now have Gnome, KDE, Motif..
so you never know what you are going to get..
A cludge..