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.
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.
Xah
···@xahlee.org
∑ http://xahlee.org/
From: Burton Samograd
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <87u091q3oj.fsf@gmail.com>
"Xah Lee" <···@xahlee.org> writes:
> 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
I agree with Burton on this one. It might be a good idea to distribute
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
From: Burton Samograd
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <87k69xpggl.fsf@gmail.com>
··············@gmail.com" <·············@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...
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).
--
burton samograd kruhft .at. gmail
kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com
Burton Samograd <············@gmail.com> writes:
> ··············@gmail.com" <·············@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.
From: Burton Samograd
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <87vethz71o.fsf@gmail.com>
Pascal Bourguignon <······@informatimago.com> writes:
> Burton Samograd <············@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...
--
burton samograd kruhft .at. gmail
kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com
> it's a bit daunting to the beginner to find
> 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.
Burton Samograd schrieb:
> ··············@gmail.com" <·············@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
"Xah Lee" <···@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.
> * 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.
>
Sounds great. Download the source, make the changes but do please keep
it to yourself.
Gregm
Greg Menke wrote:
> "Xah Lee" <···@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.
> > * 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.
> >
>
> Sounds great. Download the source, make the changes but do please keep
> it to yourself.
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.
Xah Lee wrote:
> 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
Ray Dillinger <····@sonic.net> writes:
> Xah Lee wrote:
>> 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.
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/>.
one bag of morons.
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
···@xahlee.org
∑ http://xahlee.org/
Xah Lee wrote:
> 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.
>
> 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.
Gah. You're basically pointing in more or less the right
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.
Xah Lee wrote:
> one bag of morons.
> 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
> ···@xahlee.org
> ∑ http://xahlee.org/
>
>
> Xah Lee wrote:
> > 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.
> >
> > 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.
Gah. You're basically pointing in more or less the right 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. 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.
Xah Lee wrote:
> one bag of morons.
> 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
> ···@xahlee.org
> ∑ http://xahlee.org/
>
>
> Xah Lee wrote:
> > 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.
> >
> > 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.
Gah. You're basically pointing in more or less the right 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. 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.
Xah Lee wrote:
> one bag of morons.
> 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
> ···@xahlee.org
> ∑ http://xahlee.org/
>
>
> Xah Lee wrote:
> > 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.
> >
> > 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.
"Tom Lord" <····@emf.net> writes:
> Knowing some of them, I can't accept "morons". Those who have
Three copies of a top-posted message ?
I think that I would agree with "moron" in this case.
"Xah Lee" <···@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?
-miles
--
Next to fried food, the South has suffered most from oratory.
-- Walter Hines Page
"Miles Bader" <·····@gnu.org> wrote in message
···················@catnip.gol.com...
> "Xah Lee" <···@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
"Sacha" <··@address.spam> writes:
>
> 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
Sacha wrote:
> "Miles Bader" <·····@gnu.org> wrote in message
> ···················@catnip.gol.com...
> > "Xah Lee" <···@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.
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.
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.
--tim
"Tim Bradshaw" <··········@tfeb.org> wrote in message
·····························@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
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. 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
"Tim Bradshaw" <··········@tfeb.org> writes:
> 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.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Alan Mackenzie
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <h47h1e.b8.ln@acm.acm>
David Kastrup <···@gnu.org> wrote on Tue, 11 Apr 2006 23:07:50 +0200:
> "Tim Bradshaw" <··········@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.
> David Kastrup
--
Alan Mackenzie (Munich, Germany)
Email: ····@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").
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...). 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?)
From: Alan Mackenzie
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <dkli1e.qa.ln@acm.acm>
Tim Bradshaw <··········@tfeb.org> wrote on 11 Apr 2006 15:27:52 -0700:
> 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?)
:-)
--
Alan Mackenzie (Munich, Germany)
Email: ····@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").
From: Alan Mackenzie
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <g7jg1e.b8.ln@acm.acm>
Sacha <··@address.spam> wrote on Tue, 11 Apr 2006 13:02:20 GMT:
> "Tim Bradshaw" <··········@tfeb.org> wrote in message
> ·····························@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: ····@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").
Alan Mackenzie <···@muc.de> writes:
> Sacha <··@address.spam> wrote on Tue, 11 Apr 2006 13:02:20 GMT:
>
>> "Tim Bradshaw" <··········@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
David Kastrup <···@gnu.org> writes:
> Alan Mackenzie <···@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
From: Alan Mackenzie
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <0l8h1e.b8.ln@acm.acm>
David Kastrup <···@gnu.org> wrote on Tue, 11 Apr 2006 21:17:30 +0200:
> Alan Mackenzie <···@muc.de> writes:
>> Sacha <··@address.spam> wrote on Tue, 11 Apr 2006 13:02:20 GMT:
>>> "Tim Bradshaw" <··········@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 (Munich, Germany)
Email: ····@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").
I think someone needs to be compared to hitler before we can put the
thread to rest.
--fj
From: Burton Samograd
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <87ek023d4u.fsf@gmail.com>
"funkyj" <······@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?
<duck>
--
burton samograd kruhft .at. gmail
kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com
Burton Samograd wrote:
> "funkyj" <······@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
··········@gmail.com writes:
> Burton Samograd wrote:
>> "funkyj" <······@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.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
"funkyj" <······@gmail.com> writes:
> 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?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
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.
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.
"funkyj" <······@gmail.com> writes:
> 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?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
David Kastrup <···@gnu.org> writes:
>> 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.
On 2006-04-11, David Kastrup <···@gnu.org> wrote:
> Alan Mackenzie <···@muc.de> writes:
>
>> Sacha <··@address.spam> wrote on Tue, 11 Apr 2006 13:02:20 GMT:
>>
>>> "Tim Bradshaw" <··········@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
I agree. Nothing is honed because that is not the way : the addition
of things may not break old things or steal their established hot keys etc.
> "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.
>
hehe : well said. But if you can lead, she is a hell of a mover..
On 2006-04-11, Alan Mackenzie <···@muc.de> wrote:
> Sacha <··@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
Sacha <··@address.spam> wrote:
+---------------
| "Tim Bradshaw" <··········@tfeb.org> wrote in message
| > 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. 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 <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
"Tim Bradshaw" <··········@tfeb.org> writes:
> 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
On 2006-04-13, Tim X <····@nospam.dev.null> wrote:
> "Tim Bradshaw" <··········@tfeb.org> writes:
>
>> 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.
Much as I love emacs and dont agree with "windowizing" it for newbies,
this is a pretty poor defence. If there is a common sense way of doing
something and a long winded convoluted way and the second option is
chosen then it really is a poor show to say "if you dont like it then
fix it yourself.". One of my favorite examples of emacs "elitist"
naming to confuse the foreigner or the newbie is "apropos" ... I mean,
did noone think to name this something different?
>
> 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.
If this was the attitude of most SW designers then no advances would
have been done and the world would be full of incompatible and highly
individualistic interpretations of what ought to be a common look and feel.
>
> 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.
Thats fair enough. emacs is addictive though :-;
>
> 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.
I would agree with you here. But unnecessary complexity is silly. Read
the manual : it still talks about C-v and stuff for moving around in a
buffer - outdated and outmoded IMO and very likely to frighten off
newbies who might otherwise, in the long run, have benefited from
emacs and maybe have even contributed back into the community.
>
> 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.
Using something regularly does not necessarily preclude a desire to see
it improve and increase its potential market share.
>
> Tim
>
--
Aspirat primo Fortuna labori.
From: Floyd L. Davidson
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <878xq64bml.fld@apaflo.com>
"Richard G. Riley" <······@gmail.com> wrote:
>
>I would agree with you here. But unnecessary complexity is silly. Read
>the manual : it still talks about C-v and stuff for moving around in a
>buffer - outdated and outmoded IMO and very likely to frighten off
>newbies who might otherwise, in the long run, have benefited from
>emacs and maybe have even contributed back into the community.
Can you explain what you mean? I'm missing something, because
while I may not agree with your other statements, it wasn't hard
to at least see your point. Tell me what is wrong the "talks
about C-v and stuff for moving around in a buffer"? Do you
disagree with keyboard sequences? With that particular key
binding? Or with teaching new users how to use it? I can't see
a lick of sense to such a statement...
>> 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.
>
>Using something regularly does not necessarily preclude a desire to see
>it improve and increase its potential market share.
True, but a non sequitur anyway. Neither does it preclude not
desiring to see any change or increase potential market share.
And none of that has *anything* to do with trolling by Xah, who
posts nothing but therapeutic noise anyway. Your statement
isn't any more logical than his are...
--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) ·····@apaflo.com
"Richard G. Riley" <······@gmail.com> writes:
> Much as I love emacs and dont agree with "windowizing" it for newbies,
> this is a pretty poor defence. If there is a common sense way of doing
> something and a long winded convoluted way and the second option is
> chosen then it really is a poor show to say "if you dont like it then
> fix it yourself.". One of my favorite examples of emacs "elitist"
> naming to confuse the foreigner or the newbie is "apropos" ... I mean,
> did noone think to name this something different?
http://www.m-w.com/cgi-bin/dictionary
http://www.cse.msu.edu/cgi-bin/man2html?apropos?1?/usr/man
Common usage and proper English are not "elitist" and are not unique
to Emacs. Do you have a particular word to suggest as being more
appropriate (or, so to speak, more apropos) to the task of this
command?
From: Floyd L. Davidson
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <878xq536n9.fld@apaflo.com>
David Kastrup <···@gnu.org> wrote:
>Ari Johnson <·········@gmail.com> writes:
>
>> Isn't it interesting that the vast majority of programmers and other
>> hackers work most efficiently with either Emacs or vi, and can't
>> stand to be without their favored editor?
>
>Most people could not stand stopping to breathe in Mexico City. That
>does not mean that the air is good there.
False logic. People cannot stand to stop breathing anywhere;
hence of course it actually says nothing in particular about
air in Mexico City.
However, the argument presented most often here has been that
since more people breath the air in Mexico City than any other
air that we should therefore all move to Mexico City to get air
that is obviously easier for children to breath.
But, I'll stick with *good* air, not *popular* air... because I
don't think the air in Mexico City is better nor do I think it
is actually easier for children to breath; plus I haven't been a
child, or even had any at home, for decades.
Same with Emacs key bindings. I don't agree that the proposed
changes are easier to learn, only more popular; which does not
affect my usage because what I want from Emacs is the most
efficient working environment. If it did take longer to learn,
and then has saved me time and effort for decades of use, I'm
happy.
In other words, I want good clean air to breath so that I can
live longer.
>> This isn't purposeful argumentativeness - it's a valid point. These
>> are not random cult followings.
>
>That Emacs is indispensible for a serious programmer does not sanctify
>every detail.
He didn't make any such claim, so why do you want to shoot that
dog.
--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) ·····@apaflo.com
On Sun, 16 Apr 2006 07:02:50 -0800, Floyd L. Davidson <·····@apaflo.com> said:
> David Kastrup <···@gnu.org> wrote:
>>Ari Johnson <·········@gmail.com> writes:
>>> Isn't it interesting that the vast majority of programmers and other
>>> hackers work most efficiently with either Emacs or vi, and can't
>>> stand to be without their favored editor?
>>
>>Most people could not stand stopping to breathe in Mexico City. That
>>does not mean that the air is good there.
>
> False logic. People cannot stand to stop breathing anywhere; hence of
> course it actually says nothing in particular about air in Mexico
> City.
That nothing in particular follows about "air quality" was exactly
Kastrup's point.
"Richard G. Riley" <······@gmail.com> writes:
> One of my favorite examples of emacs "elitist" naming to confuse the
> foreigner or the newbie is "apropos" ... I mean, did noone think to
> name this something different?
WTF does _that_ mean? Do you think that whoever thought up the name of
the command was somehow being _intentionally_ obfuscating?
> Using something regularly does not necessarily preclude a desire to see
> it improve and increase its potential market share.
Do you think that this hasn't been discussed before, many times (and at
often at great length)?
That's one of the reasons people react to Xah in such an abrupt manner
-- he's posted this kind of stuff before, in the same rather high-handed
and dismissive tone, with (apparently) zero recognition of existing
Emacs culture. I still don't know whether he's a troll, or just kind of
clueless, but it begins to grate after a while.
Most emacs users and developers simply disagree that Xah's
"recommendations" would be an improvement. Many recognize the potential
upside in accomodating newbies, but disagree that this is worth the
downside.
In particular, Emacs users tend to value a particular style of usage in
which Emacs is _not_ just another random program you use occasionally to
edit a file, but a sort of environment in which you're immersed. Given
such a style of usage, it's more important that one be proficient at
_Emacs_ (which has a well-honed, efficient, and consistent command set)
than it is that Emacs be trivially interchangeable with every random
windows app.
Furthermore, adding bindings like C-x/C-c/C-v _distorts_ the native
Emacs command set in rather pervasive ways, and makes it harder to use
Emacs in general. If you accept that emacs is an "important" program,
it's _far_ more efficient in the long run for newbies to simply learn
three new keybindings (gee, is that so hard?!?) than learn some kind of
confused mutant command set; sure if they do the latter they'll
quickly be able to copy and paste -- but they'll have a harder time
coming to grips with the _rest_ of Emacs, which is a much larger task!
You may not agree that this is a desirable mode of usage for Emacs, but
please recognize that the people who make the decisions about Emacs
development think it is.
-Miles
--
"Unless there are slaves to do the ugly, horrible, uninteresting work, culture
and contemplation become almost impossible. Human slavery is wrong, insecure,
and demoralizing. On mechanical slavery, on the slavery of the machine, the
future of the world depends." -Oscar Wilde, "The Soul of Man Under Socialism"
"Richard G. Riley" <······@gmail.com> writes:
> I have a reasonably decent command of the English language. "apropos"
> is not a word in common use. Relax.
"Apropos" is not a word that would be considered particularly
unusual and certainly not in any way confusing among the people I
converse with day to day. "Decent command of the English language" is
evidently in the eye of the beholder.
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)
In article <··············@Dagney.local>, Patrick May <···@spe.com> wrote:
>"Richard G. Riley" <······@gmail.com> writes:
>> I have a reasonably decent command of the English language. "apropos"
>> is not a word in common use. Relax.
>
> "Apropos" is not a word that would be considered particularly
>unusual and certainly not in any way confusing among the people I
>converse with day to day. "Decent command of the English language" is
>evidently in the eye of the beholder.
For what it's worth, as an emacs non-user[1] (I'm reading this in
comp.lang.scheme), as soon as I saw `apropos' I had a pretty good idea
what the command does. I can't think of any other short name for a
command that does the same thing that would also have that property.
(Admittedly, that probably has more to do with my knowledge of unix than
with my knowledge of the English language, but I didn't have to think too
hard about what it meant the first time I encountered it on unix either.)
dave
(vi user)
[1] From what I've heard, emacs is a great desktop environment, but I'm
not going to be trying it until they add a good lightweight editor.
--
Dave Vandervies ········@csclub.uwaterloo.ca
I have never seen Hungarian notation used properly by anyone, except
in threads discussing Hungarian notation.
--Richard Bos in comp.lang.c
From: Fredrik Bulow
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <877j5odyyq.fsf@gmail.com>
I think this discussion has gone a bit out of control. Xah is
obviously a newbie trying to learn Emacs and while learning he has
encountered a few thing that he thought were weird. Since he is a
newbie he can't do much about these things himself and therefor he
writes down a list with all the "problems" and submits the list to an
emacs forum where it will be brought to the attention of people who
can actually do something about these problems. Complaining that he
doesn't really contribute anything is silly since he can't. I think he
did the right thing and that should be encouraged, not punished.
Emacs is a niche editor for those who write lots of stuff and are
willing to put in the (arguably large) learning effort required
because they know it will pay back in the long run. Therefor making it
newbie friendly might not be the most important thing. However, I have
a feeling that there are lots of emacs conservatives who simply are
against all changes. This point of view makes sense when you have a
massive emacs knowledge and fear that if emacs changes you will be
confused by new key bindings, concept names etc. The viewpoints of
these people is motivated by a "fear of loss" and is counter
productive. I think it's great that every now and then a complete
newbie speaks up and say "these things confuse me" so that more
experienced users can be reminded of the newbie perspective when
writing mode manuals or implementing new features.
Fredrik Bulow <·············@gmail.com> writes:
> I think this discussion has gone a bit out of control. Xah is
> obviously a newbie trying to learn Emacs and while learning he has
> encountered a few thing that he thought were weird.
Xah is not a newbie; he is, in fact, rather proud of being a troll.
Jay
Its not fear of change that makes the emacs people grumpy, its that none
of the "changes" are actual work and instead with very few exceptions
can be trivially handled in a user's .emacs file. So the point we're
trying to make is that the user is free to set up their emacs however
they want.
If there are people that think newbies need a bit of help using Emacs (I
probably agree), then they are perfectly free to improve the help,
market their favorite .emacs or write howto's- there is no-one stopping
them. If they choose to contribute nothing more than complaints, then
why must they be taken especially seriously?
If, instead of complaining, Xah had said- "Look fellow emacs users, I've
always felt the default emacs is a bit of a trial for newbies. Here are
my new .emacs file and a couple new modes to set up Emacs how I think it
should be for newbies- and maybe also for skilled users who prefer this
sort of configuration. Could you please critique it and perhaps help me
lobby for its inclusion in the official distro?", then I think there
would be a much more positive response. Instead he "offers" his
uninformed opinions about how emacs "should" be, basically telling all
the experienced emacs users that their opinions and skills and
preferences are worthless.
Gregm
From: Fredrik Bulow
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <87k69npnhw.fsf@gmail.com>
Greg Menke <·············@toadmail.com> writes:
> If, instead of complaining, Xah had said- "Look fellow emacs users, I've
> always felt the default emacs is a bit of a trial for newbies. Here are
> my new .emacs file and a couple new modes to set up Emacs how I think it
> should be for newbies- and maybe also for skilled users who prefer this
> sort of configuration. Could you please critique it and perhaps help me
> lobby for its inclusion in the official distro?", then I think there
> would be a much more positive response. Instead he "offers" his
> uninformed opinions about how emacs "should" be, basically telling all
> the experienced emacs users that their opinions and skills and
> preferences are worthless.
>
> Gregm
Alright, the reason I wrote my previous article is that I thought that
Xah was a complete newbie and that some serious and un-just "newbie
bashing" was done by expert users and that annoyed me. If he's not a
newbie, he sould do more creatvie stuff than just complain in
newsgroups.
If you read my whoe article you see that the remedy I sugest is
writing better manuals and keeping newbies in mind when implementing
new features. Hardly a complete mess up of emacs!
A newbie shouldn't be taken especially seriously but neither should he
be punished and insulted for trying to help out; and that is what I
thought was happening. Perhaps I missjudged the situation...
Fredrik Bulow <·············@gmail.com> writes:
> I think this discussion has gone a bit out of control. Xah is
> obviously a newbie trying to learn Emacs and while learning he has
> encountered a few thing that he thought were weird. Since he is a
> newbie he can't do much about these things himself and therefor he
> writes down a list with all the "problems" and submits the list to an
> emacs forum where it will be brought to the attention of people who
> can actually do something about these problems. Complaining that he
> doesn't really contribute anything is silly since he can't. I think he
> did the right thing and that should be encouraged, not punished.
>
> Emacs is a niche editor for those who write lots of stuff and are
> willing to put in the (arguably large) learning effort required
> because they know it will pay back in the long run. Therefor making it
> newbie friendly might not be the most important thing. However, I have
> a feeling that there are lots of emacs conservatives who simply are
> against all changes. This point of view makes sense when you have a
> massive emacs knowledge and fear that if emacs changes you will be
> confused by new key bindings, concept names etc. The viewpoints of
> these people is motivated by a "fear of loss" and is counter
> productive. I think it's great that every now and then a complete
> newbie speaks up and say "these things confuse me" so that more
> experienced users can be reminded of the newbie perspective when
> writing mode manuals or implementing new features.
>
You don't seem to be familiar with Xah's fairly regular posts. I'd
suggest you go and look at his website and then consider if you still
agree with what you have written.
I also don't think most of the experienced users who are against
changing the defaults are doing so because they are afraid of change
or loss - emacs is wonderful because you can make changes relatively
easily and experienced users won't have any problems changing the
defaults back again. Experienced users are more likely gainst the
change because new users won't get to experience how efficient the
current setup can be. they will stick with the defaults and never
change. Leaving the current defaults means they will get to try it out
and after giving it a genuine go, will be in a position to make a real
assessment - if they decide they don't like it, they will have the
knowledge to change it by then and can easily do so, but just maybe
like many other users in the past, they will get use to the defaults
and then begin to see the benefits of an alternative approach.
Tim
--
tcross (at) rapttech dot com dot au
From: Fredrik Bulow
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <87u08qyk9n.fsf@gmail.com>
Tim X <····@nospam.dev.null> writes:
> Fredrik Bulow <·············@gmail.com> writes:
>
> You don't seem to be familiar with Xah's fairly regular posts. I'd
> suggest you go and look at his website and then consider if you still
> agree with what you have written.
No, I figured out how to read news about one week ago. :-)
> I also don't think most of the experienced users who are against
> changing the defaults are doing so because they are afraid of change
> or loss - emacs is wonderful because you can make changes relatively
> easily and experienced users won't have any problems changing the
> defaults back again. Experienced users are more likely gainst the
> change because new users won't get to experience how efficient the
> current setup can be. they will stick with the defaults and never
> change. Leaving the current defaults means they will get to try it out
> and after giving it a genuine go, will be in a position to make a real
> assessment - if they decide they don't like it, they will have the
> knowledge to change it by then and can easily do so, but just maybe
> like many other users in the past, they will get use to the defaults
> and then begin to see the benefits of an alternative approach.
Yeah, the cool thing with emacs is that you can turn it into whatever
you want. And yes, the defaults makes good sense actually. I once
installed some horrible package with alternative emacs configurations
(can't remember what it was called) and that made me appreciate the
defaults.
How user interfaces should and shouldn't work is a very interesting
question. Personally I think that something went terrible wrong with
mainstream computing when GUIs were introduced. Self-explaining
programs started breeding the attitude that "what you can do does not
depend on your knowledge but on what software you have". If you want
to make web pages you buy web page drawing program and if some feature
is missing in that program then you wait until someone else makes a
button for that thing. All tasks are split into the two categories
"trivial" and "impossible". It's also up to someone else to determine
what should be transfered to the "trivial" category. Users are only
suppose to click ok without reading to many messages and if an error
occurs they tend to say "it didn't work because I got an error message"
rather than actually reading the error message. A behavior that makes
sense since reading through an error message and fixing something
yourself seems non-trivial and is therefor probably impossible.
Emacs is a completely different type of user interface. When working
with emacs you determine which task should be trivial and which ones
shouldn't and what determines what is possible for you to make trivial
depends only on your knowledge. Emacs focuses on providing
functionality rather than functions (what a hell does that mean? I
mean, not providing an actual function button but rather providing
functions that can be used to make the thing you need sort of... oh
well..). I personally love this attitude and that's why I am learning
emacs. However, I believe that emacs is diverging more and more from
mainstream computing as Emacs is further and further refined and the
stupidification (is that a real word?) of mainstream computing
progresses. Actually I think this is the main reason why people go
berserk when reading the writings of Xah. They believe that
"modernization towards the newbie" sounds like a slogan for someone
who wants emacs to have a neat GUI where all the tasks that can be
done can be done trivially.
To be honest, the reason I started backing up Xah in the first place
was because I thought he was a newbie who tried to provide
constructive critique.
From: Galen Boyer
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <uy7xu9pq9.fsf@rcn.com>
On 16 Apr 2006, ····@emf.net wrote:
> What is *not* well thought out is the particular choices of
> keybindings. It's not *poorly* thought out -- it's just nothing
> special.
The fact that I can hit any prefix key and then C-h is pretty damn well
thought out!
--
Galen Boyer
Ari Johnson <·········@gmail.com> writes:
> David Kastrup <···@gnu.org> writes:
>
>> Ari Johnson <·········@gmail.com> writes:
>>
>>> Isn't it interesting that the vast majority of programmers and other
>>> hackers work most efficiently with either Emacs or vi, and can't
>>> stand to be without their favored editor?
>>
>> Most people could not stand stopping to breathe in Mexico City. That
>> does not mean that the air is good there.
>
> The difference is that being in Mexico City and breathing the air
> there are corequisites.
You can always move out. It might not be practical.
> Programming and using a subset of (Emacs vi) are not corequisites,
Don't kid yourself. You don't easily get tighter integration of
editor and debugger than by using the gud interface. Except if you
use an "IDE" with integrated toy editor.
> and yet somehow they go together so often that more is needed to
> explain them than the inapt analogy of breathing the air in Mexico
> City.
>>> This isn't purposeful argumentativeness - it's a valid point.
>>> These are not random cult followings.
>>
>> That Emacs is indispensible for a serious programmer does not
>> sanctify every detail.
>
> No, it does not. However, a serious programmer modifies it to fit
> his needs perfectly.
Like a serious contractor modifies the air condition at his work place
to fit his needs perfectly.
> That the defaults go unchanged as often as they do for serious
> programmers and long-time Emacsers shows that, while not necessarily
> sanctified, they are at least efficient enough to do the job.
You don't need efficiency to do some job.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
"Richard G. Riley" <······@gmail.com> writes:
>
> One of my favorite examples of emacs "elitist" naming to confuse the
> foreigner or the newbie is "apropos" ... I mean, did noone think to
> name this something different?
What's your suggestion? That _is_ the most appropriate English word to
use--or at least, I can think of none better (relevant? pertaining?).
I hardly think that the emacs developers can be blamed for illiteracy
amongst users...
> I would agree with you here. But unnecessary complexity is silly. Read
> the manual : it still talks about C-v and stuff for moving around in a
> buffer - outdated and outmoded IMO and very likely to frighten off
> newbies who might otherwise, in the long run, have benefited from
> emacs and maybe have even contributed back into the community.
I might agree with you if you were going on about C-f and C-b--but C-v
and M-v are _useful_. What would you prefer?
--
Robert Uhl <http://public.xdi.org/=ruhl>
To make laws that man cannot, and will not obey,
serves to bring all law into contempt. --E.C. Stanton
"Richard G. Riley" <······@gmail.com> writes:
> On 2006-04-16, Tim X <····@nospam.dev.null> wrote:
>> But who says the second converluted approach was selected? My point is
>> that if emacs does it badly, how is it that nobody has done it better?
>> If someone has done it better, then why aren't all these people who
>> are complaining about how emacs does it not using this better
>> solution.
>>
>> Your comment regarding apropos doesn't hold water. The term is very
>> appropriate to its purpose. The fact our vocabulary these days seems
>> to be less than it was 100 years ago is not sufficient justification
>> for reductionism in how we use words. Also note that apropos has been
>> used in other applications, including Unix for a long time.
>
> Both of your arguments above indicate a reluctance to change anything
> : which is why emacs is so cumbersome to so many. Dont get me wrong :
> I love it - but to say its "honed" is complete horse - its a giant.
>
>>
>> Can you propose another single word term which more accurately
>> reflects what the command does?
>
> Heres the miriam definition : could you explain how it fits the
> purpose clearly?
>
> Main Entry: 1ap·ro·pos
> Pronunciation: "a-pr&-'pO, 'a-pr&-"
> Function: adverb
> Etymology: French à propos, literally, to the purpose
> 1 : at an opportune time : SEASONABLY
> 2 : by way of interjection or further comment: with regard to the
> present topic
>
Think about what it does and the suitability seems to fit by my
reading. The apropos command provides a list of commands/variables
matching your regular expression - which you usually define according
to what you believe will match to the purpose you want to apply them
to. So, it provides a list of commands/variables to fit a certain
purpose.
The fact it also does this when you want and provides some
documentation/explination fits with it being available at an
'opportune time' and with 'interjection or further comment: with regard to the
> present topic'.
Sure, its not necessarily a word everyone uses day to day, but if we
restricted ourselves to only using words in common usage, things would
be even more confusing. How many of us used cache regularly before
computers?
My question is if its such a bad choice, come up with a better one
that doesn't create its own confusion. This BTW is my point when I
refer to how people should stop moaning about how unsatisfactory it is
and do something about it. It doesn't necessarily translate to "do it
yourself" - anyone is free to get others to help them do it. However,
it does mean stop moaning - either do something constructive or switch
to something different or accept things as they are, just don't moan
about it.
>>
>>>> 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.
>>>
>>> If this was the attitude of most SW designers then no advances would
>>> have been done and the world would be full of incompatible and highly
>>> individualistic interpretations of what ought to be a common look and feel.
>>>
>>
>> Why? Surely things would be more innovative and possibly even better
>> if SW designers actually strived to improve things rather than just
>> following the 'popular' approach. Sure, we possibly would have a
>> windows world with a lot more variation between apps, but at least
>>we
>
> whyt do you mean "more variation between apps"? Windows does, IMO,
> provide a far more concistent integration between apps than, say,
> Linux. I use both, Linux more.
>
I was following on from what you said and was saying that IF SW
developers tried to be innovative rather than following what was
popular, we would have more dieversity within the windows world for a
while - I was not saying there was diversity there as there clearly
isn't. Windows is locked into a single UI paradigm which is now
considered to be not just the "normal" way to do things, but also by
many the "right way".
>> are mor likely to see even better approaches emerge and eventually, a
>> standard based on preferred fuctionality rather than marketing and
>> market share would prevail.
>>
>>>>
>>>> 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.
>>>
>>> Thats fair enough. emacs is addictive though :-;
>>
>> Funny that. I wonder why such a poorly designed/implemented
>> application can become so addictive.
>
> You're being purposely argumentative. Its addictive because it has a
> lot of strengths and takes a lot of time to get used to : it makes it
> an aim or a goal to master it. No other deitor with the possible
> exception of vi has such a cult following.
>
Fair enough - probably was getting argumentative. I just find it
frustrating when people on one hand can recognise the power and
incredible flexibility of a system like emacs, but at the same time
criticise it for not having a simpler and more intuitive interface.
Firstly, I find the interface to be quite intuitive and don't see the
mess or kludge of things you seem to observe. I'm a big user of key
shortcuts and avoid the mouse as much as possible - the emacs
keybindings were the first I ever came across which had some easy to
follow pattern to them. the use of buffers instead of files makes
perfect sense because they are not all files and the use of frames and
windows makes as much sense as any other terminology - especially
considering I cannot think of many MS apps which have the same frame
concept.
Now, because some company has been very successful in marketing their
product and now dominates the desktop environment, we have people like
Xah coming out of the woodwork telling everyone that anything which
doesn't follow the MS interface style and terminology is wrong and
needs to be changed. Will we then change it in 20 years time again
when some other paradigm and terminology becomes popular? I'm mean,
really, one read of the emacs tutorial and this sort of stuff becomes
pretty clear - its not bloody rocket science.
There are some things I would like to see in a future emacs. I would
like to see it use a version of elisp which has better namespace
seperation or a better package space, but apart from that, I find it
pretty straight forward. It would be nice to have threading so that
long operations don't stop you from switching to another window/frame
and continuing to work and I'm really interested in how some of the
really innovative work relating to things like semantic will develop.
I'm not interested in the opinions of users who have spent an hour
playing with it telling me whats wrong with it when they haven't used
it long enough to see what is different about it and what is done
right.
Its interesting that I see few people moan about MS Office and all its
components - this has got to be one of the worst applications for
crappy interfaces I've used in a long time and its crappyness is not
limited to poor keybindings and unfamiliar terminology (though I think
its got plenty of that as well).
With emacs, I cannot see how you could make things better and not lose power or
flexibility. Sure, there has been some discussion in the past about
changing elisp to something else, but there is just too much really
good elisp out there to replace (the fact many of us are running
elisp written over 10+ years ago with no or little updating means
something must be going right).
>>
>>>
>>>>
>>>> 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.
>>>
>>> I would agree with you here. But unnecessary complexity is silly. Read
>>> the manual : it still talks about C-v and stuff for moving around in a
>>> buffer - outdated and outmoded IMO and very likely to frighten off
>>> newbies who might otherwise, in the long run, have benefited from
>>> emacs and maybe have even contributed back into the community.
>>>
>>
>> I was a newbie 10 years ago when I switched to emacs. However, I
>> didn't think twice about C-v being an issue or get even a little
>
> You surprise me. 99.99999999999% of users would have keyboards with
> arrow keys and page up/ down. They work in emacs. Document it in the
> tutorial.
Well, in fact, not all keyboards had easy access to pageUp/down or
even arrow keys - they may do now, but they didn't as little as 10
years ago.
I do have arrow keys and pgup/dwn and a numeric keypad etc. However, I
rarely use them. This is for the same reason I don't like using a
mouse. Moving your hands away from the main keyboard just slows you
down. Prior to emacs, I was a VI user and I didn't use the arrow keys
and pgup/dwn keys then either.
>
>> frustrated/scared about the differences. In fact, emacs was the very
>> first app I ever used where the keyboard shortcuts seemed to follow a
>> pattern rather than appearing somewhat random.
>>
>> At the time, I was given some very valuable advice by an old time
>> emacs user. Essentially, he said to me that while you could customize
>> almost anything within emacs, he advised me to use ti in a default
>> configuration for 6 months and then only make the customization I
>> really wanted. After 6 months, I realised the way it was setup with
>> its defaults were pretty good and very little customization was
>> required. Even now, after 10 years, most of my 'customization' has
>> been to make emacs fit with my work environment rather than make emacs
>> fit with my interface expectations.
>
> I would agree with that.
>
>>
>>>>
>>>> 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.
>>>
>>> Using something regularly does not necessarily preclude a desire to see
>>> it improve and increase its potential market share.
>>
>> Although I don't actually care about emacs' market share beyond there
>> being enough people involved to keep its evolution happening and I
>> agree that regular users should be thinking about ways to make it
>> better, I don't believe Xah falls into this catagory. The questions he
>> has asked on gnu.emacs.help show he has a very poor grasp of how it
>> works, how to configure it and what already exists. The bottom line is
>> that Xah doesn't like Unix and anything which can be associated with
>> it, including emacs. He therefore spends a lot of wasted time trying
>> to justify why its so poor, but has not a single original idea
>> regarding how to make things better. His thinking is shallow and
>
> He actually came up with a few suggestions. You appear unwilling or
> unable to recognise them. Another postre pointed out a version of
> emacs which has, funnily enough, implemented a fair few of them to
> make emacs accessible to those who are not willing to invest the time
> and effort to learn the base products strange ways.
>
thats a bit ironic - I think it was me who pointed out the easymacs
package etc.
I looked at Xah's post and I've checked out his website - he as next
to nothing in the way of good ideas - most are ill conceived and show
only very shallow thinking about the problem. Much of what he says is
based on FUD relating to things he really hasn't bothered spending the
time to get to understand. Essentilly, Xah is very much like a young
child - he has an inquisitive mind, but gets bored very quickly and
doesn't want to really put in much effort to understand things - if
its not bleedingly obvious in the first few hours or attempt at use,
he either writes it off or starts writing about what needs to be done
to make it work "in the modern world".
I'd be interested in know which of his ideas you thought were of any
merit?
>> ill-informed and merely the regurgitation of other peoples
>> ill-informed ideas. Essentially, I thinnk he is out of his depth and
>> lacks either the historical or technical background to appreciate why
>> certain design decisions were selected.
>>
>
> It is also eas to fall into the defensive mode : as you appear to have
> done. The fact that you are clearly an emacs adovate and familiar with
> the way it does things does not necessarily make them right NOW :
> times and interfaces do change. I am playing devils adovcate : I like
> emacs as it is.
>
I'm not a religious zelot regarding emacs and initially was forced to
use it and now use it simply because there is no other tool which
meets my needs. However, I've seen nothing put forward by Xah which
has any real benefit or which would make any real improvement.
>> Its very easy to rubbish things, but much much harder to offer better
>> alternatives. I would have some respect for Xah if he proposed well
>
> And also very eays to say "tough, if you dont like it then go and make
> it better yourself" ... :-;
>
True enough - but why not? If your going to rubbish how things are at
the moment I think its reasonable to suggest you back it up with
effort to do something about it rather than screaming into the
internet that some magic force should do it. The suggestions put
forward by Xah were not discounted because he was proposing change,
they were discounted because they had no benefit and were based on
misconception and misunderstanding of emacs with claims that had no
foundation in fact from someone who wanted to change something he was
unfamiliar with to become something he was familiar with - in the same
way that you can argue the problem is those who are familiar with how
it currently is are resistant to change, peole like Xah are just as
resistant to things which don't match with what they are familiar
with. As they are coming to the new system, I don't think its
unrreasonable to suggest that if they don't like it, then they should
be the ones to change it.
>> reasoned and researched alternatives, but he doesn't. All he does is
>> regurgitate a fairly uninformed opinion with no evidence of research
>> or deeper thought concerning the issues.
>>
>> Just to balance things up, there are things about emacs I think could
>> be better. However, the difference is that I've not been able to work
>> out alternatives which are better and don't have more negative side
>> effects. therefore, I keep them to myself and continue to think about
>> them from time to time. when I have something which I feel is a really
>> good alternative that is overall postive, I'll put it forward.
>> However, so far, either I'm not immaginative enough or simply not
>> smart enough to make things better overall.
>>
Tim
--
tcross (at) rapttech dot com dot au
Tim X wrote:
> "Richard G. Riley" <······@gmail.com> writes:
>
>> He actually came up with a few suggestions. You appear unwilling or
>> unable to recognise them. Another postre pointed out a version of
>> emacs which has, funnily enough, implemented a fair few of them to
>> make emacs accessible to those who are not willing to invest the time
>> and effort to learn the base products strange ways.
>>
>
> thats a bit ironic - I think it was me who pointed out the easymacs
> package etc.
>
> I looked at Xah's post and I've checked out his website - he as next
> to nothing in the way of good ideas - most are ill conceived and show
> only very shallow thinking about the problem. Much of what he says is
> based on FUD relating to things he really hasn't bothered spending the
> time to get to understand. Essentilly, Xah is very much like a young
> child - he has an inquisitive mind, but gets bored very quickly and
> doesn't want to really put in much effort to understand things - if
> its not bleedingly obvious in the first few hours or attempt at use,
> he either writes it off or starts writing about what needs to be done
> to make it work "in the modern world".
>
> I'd be interested in know which of his ideas you thought were of any
> merit?
There is merit toward doing things the same way as everyone else.
There's also merit in keeping things the same.
The first makes it easy to learn other apps in a *basic* way; you can
rely on certain things always being there and acting generally in one
way. The second prevents you from having to re-learn an app as the
popular interface changes. Both of these are useful; I know I
encountered initial difficulty learning Emacs because C-x/C-c/C-v/C-z
did not do what I expected. Now I use cua-mode, and everything works
out fine.
I think C-x/C-c/C-v/C-z/C-o/C-s/C-a/mouse-3 are here to stay. Every
application I've seen in the past ten years, other than Emacs, has the
same meaning for each of these keybindings. Using the same meaning as
other applications here would be a *good* thing.
On the other hand, there are common keybindings that are disagreed upon,
like for mouse-2 and C-y. Using the same meaning as other applications
do here would be a *bad* thing, as there is no commonly accepted
standard, so it'd be better not to change anything.
I think Xah is right that Emacs should provide a mode where
C-x/C-c/C-v/C-z/C-o/C-s/C-a/mouse-3 act as in every other app, and that
mode should be enabled *by default*. He is also right that there should
also be a menu entry (though not necessarily a keybinding) for Redo. It
would be nice if "window" could be renamed to "buffer-area" and "frame"
to "window", but I don't see that ever being feasible until Emacs has
proper namespace support.
All of Xah's other suggestions are pointless or not really thought out.
But don't discount everything Xah says just because he thinks the
*scratch* buffer should be eliminated or longlines-mode should be
enabled by default in every buffer. There are some good ideas in there
-- I think a longlines-code-mode would be really cool to have, and
making *scratch* start with buffers-offer-save=t would be nice.
-- MJF
M Jared Finder <·····@hpalace.com> writes:
>
> It would be nice if "window" could be renamed to "buffer-area" and
> "frame" to "window", but I don't see that ever being feasible until
> Emacs has proper namespace support.
window->pane, frame->window
--
Robert Uhl <http://public.xdi.org/=ruhl>
Nobody ever got fired for choosing Microsoft. Nobody ever looked stupid
for choosing Linux. --Jebediah21
M Jared Finder <·····@hpalace.com> writes:
> I think Xah is right that Emacs should provide a mode where
> C-x/C-c/C-v/C-z/C-o/C-s/C-a/mouse-3 act as in every other app, and that
> mode should be enabled *by default*.
No. Doing so would give complete newbies an easier first fifteen
minutes, but it would would interfere with the task of learning the
_rest_ of Emacs keybindings -- and the latter is a much harder (and more
important) task than the former.
Is it really that hard for people to learn _three_ new keybindings?!?
[It's not like a complete newbie is unable to function -- most that I've
observed simply use the menus at first, and slowly pick up whatever
keybindings they find useful.]
-Miles
--
We have met the enemy, and he is us. -- Pogo
M Jared Finder <·····@hpalace.com> writes:
> There is merit toward doing things the same way as everyone
> else. There's also merit in keeping things the same.
>
> The first makes it easy to learn other apps in a *basic* way; you
> can rely on certain things always being there and acting generally
> in one way. The second prevents you from having to re-learn an app
> as the popular interface changes. Both of these are useful; I know
> I encountered initial difficulty learning Emacs because
> C-x/C-c/C-v/C-z did not do what I expected. Now I use cua-mode, and
> everything works out fine.
>
> I think C-x/C-c/C-v/C-z/C-o/C-s/C-a/mouse-3 are here to stay. Every
> application I've seen in the past ten years, other than Emacs, has
> the same meaning for each of these keybindings. Using the same
> meaning as other applications here would be a *good* thing.
No. The mouse bindings of Emacs are _ingenious_. They obliterate the
need for C-x/C-c/C-v. They make it possible to actually get work
_done_ with the mouse without having to move back to the keyboard.
The purpose of Emacs is _editing_, not browsing (and where browsing is
involved, it does already make mouse-2 and lately mouse-1 work). And
so its mouse bindings should stay optimized for editing.
And it does an excellent job at that, better than anything else I know
(including XEmacs).
> I think Xah is right that Emacs should provide a mode where
> C-x/C-c/C-v/C-z/C-o/C-s/C-a/mouse-3 act as in every other app, and
> that mode should be enabled *by default*.
No. The default should not sacrifice usability.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
M Jared Finder <·····@hpalace.com> writes:
>
> There is merit toward doing things the same way as everyone else.
> There's also merit in keeping things the same.
>
> The first makes it easy to learn other apps in a *basic* way; you can
> rely on certain things always being there and acting generally in one
> way. The second prevents you from having to re-learn an app as the
> popular interface changes. Both of these are useful; I know I
> encountered initial difficulty learning Emacs because C-x/C-c/C-v/C-z
> did not do what I expected. Now I use cua-mode, and everything works
> out fine.
>
This is probably where we will disagree - I think the merit of doing
things the same way as everywhere else has limited and often over
stated benefits. This can be hard to justify if it also means we lose
any real innovation.
There are three main reasons why I don't agree with changing the
default or modifying emacs base key bindings -
1. The complaint everyone has surrounds the basic cut/copy/paste and
cursor movement keys. However, changing the current defaults will
create inconsistency with the underlying approach used in emacs
(yes, it actually does have a method to the maps). This will make
learning and becoming familiar with the other powerful key bindings
more difficult and it will becom eless likely new users will
realise this power exists. Note that for a long time, arrow keys,
pgup/pgdwn have worked anyway.
2. There is a lot of documentation and examples of how to bind keys
and change key bindings from the defaults, so lets leave them and
give the new user the opportunity to try something which many
consider superior to the common approach, but leave them with the
ability to change things if they don't like it.
3. There are already plenty of packages which can change key bindings
to whatever other common environment/editor the new user wants.
None of these should become the defualt as most of them do lose
some functionality or have inconsistency and most people don't
bother changing the defaults, so they won't know about the really
good key bindings which exist (they are in fact extremely good for
anyone who is a touch typest).
About the only thing which I'd be critical about regarding the key
bindings is that most keyborads have the control and meta keys in poor
positions. However, emacs cannot predict what keyborad somebody has
and on many systems, its fairly trivial to re-map control and meta to
other positions.
> I think C-x/C-c/C-v/C-z/C-o/C-s/C-a/mouse-3 are here to stay. Every
> application I've seen in the past ten years, other than Emacs, has the
> same meaning for each of these keybindings. Using the same meaning as
> other applications here would be a *good* thing.
>
Not when you view the whole range of keybindings and what impact this
would have on them. Sure, a lot of new users would find cutting,
copying pasting etc easier, but I suspect they would then find the
rest of the key bindings much harder to follow and emacs has a lot
more key bindings than most other programs.
If someone can come up with a consistent approach which can work as
well as the current one (or hopefully better), then put it forward. I
don't have a problem with changing default behavior, but only when
that change is going to give us real benefits and not lose us things.
There is a lot more at stake here than changing a few key bindings -
you also have to define a new methodology/approach to the key binding
model so that developers know what keys they can and cannot use in
their emacs apps.
> On the other hand, there are common keybindings that are disagreed
> upon, like for mouse-2 and C-y. Using the same meaning as other
> applications do here would be a *bad* thing, as there is no commonly
> accepted standard, so it'd be better not to change anything.
>
> I think Xah is right that Emacs should provide a mode where
> C-x/C-c/C-v/C-z/C-o/C-s/C-a/mouse-3 act as in every other app, and
> that mode should be enabled *by default*. He is also right that there
> should also be a menu entry (though not necessarily a keybinding) for
> Redo. It would be nice if "window" could be renamed to "buffer-area"
> and "frame" to "window", but I don't see that ever being feasible
> until Emacs has proper namespace support.
>
but why should these things be made the default? As already stated, I
can see more being lost in the long run doing this than any real
gains. The fact the new user can make these changes quite easily via
cua-mode or easymacs or any of the other packages that do similar
things makes changing the defaults even harder to justify IMO. You
could argue this information isn't easily available - but I'd say that
if a user wasn't capable of a basic google search and cannot work out
how to do it, then they are probably wasting their time with emacs
anyway.
> All of Xah's other suggestions are pointless or not really thought
> out. But don't discount everything Xah says just because he thinks the
> *scratch* buffer should be eliminated or longlines-mode should be
> enabled by default in every buffer. There are some good ideas in
> there -- I think a longlines-code-mode would be really cool to have,
> and making *scratch* start with buffers-offer-save=t would be nice.
>
I don't discount everything Xah says just because he says it (though I
would say I'd be right to do so 80% of the time). I discount Xah as
just meaningless white noise because he actually contributes nothing
substantial and is not interested in debating his claims. He comes
along and posts some personal rants with considerable amounts of abuse
and swearing and always demands everyone else fix what he perceives as
being wrong with the world, yet does nothing himself except send off
some post with his latest rant to a newsgroup.
--
tcross (at) rapttech dot com dot au
I've probably overzealously snipped your reply. If you feel I left
something important out, please put it back and mention what I overlooked.
Tim X wrote:
> M Jared Finder <·····@hpalace.com> writes:
>
>> There is merit toward doing things the same way as everyone else.
>> There's also merit in keeping things the same.
>>
>> The first makes it easy to learn other apps in a *basic* way; you can
>> rely on certain things always being there and acting generally in one
>> way. The second prevents you from having to re-learn an app as the
>> popular interface changes. Both of these are useful; I know I
>> encountered initial difficulty learning Emacs because C-x/C-c/C-v/C-z
>> did not do what I expected. Now I use cua-mode, and everything works
>> out fine.
>
> This is probably where we will disagree - I think the merit of doing
> things the same way as everywhere else has limited and often over
> stated benefits. This can be hard to justify if it also means we lose
> any real innovation.
I disagree. In Gnu Emacs, by default every single-character control
sequence from C-a to C-z as well as odd ones like ··@ is used for some
purpose. However, there are only 20 commands that I find myself using
often enough that I think they deserve having one letter bindings. All
the others are taking up keyboard real estate that is not needed.
It would not be difficult to cut some of the cruft in the key bindings
to find room for Control-X-prefix and mode-specific-command-prefix,
which would be stupid to eliminate. I'd suggest starting with
uncommonly used bindings like C-] (abort-recursive-edit) and C-z
(iconify-or-deiconify-frame).
> There are three main reasons why I don't agree with changing the
> default or modifying emacs base key bindings -
>
> 1. The complaint everyone has surrounds the basic cut/copy/paste and
> cursor movement keys. However, changing the current defaults will
> create inconsistency with the underlying approach used in emacs
> (yes, it actually does have a method to the maps). This will make
> learning and becoming familiar with the other powerful key bindings
> more difficult and it will becom eless likely new users will
> realise this power exists. Note that for a long time, arrow keys,
> pgup/pgdwn have worked anyway.
That's not true. You could still keep the patterns native to the
keybindings while moving around the keys the binding is on. If
forward-character was moved to only be on <right>, there's nothing
preventing M-<right> from being forward-word and C-M-<right> from being
forward-sexp. In fact, that's how recent CVS Gnu Emacs works.
And if, as an expert, you want to move forward-char to C-k, you can
easily move forward-word to M-k and forward-sexp to C-M-k.
> 2. There is a lot of documentation and examples of how to bind keys
> and change key bindings from the defaults, so lets leave them and
> give the new user the opportunity to try something which many
> consider superior to the common approach, but leave them with the
> ability to change things if they don't like it.
> 3. There are already plenty of packages which can change key bindings
> to whatever other common environment/editor the new user wants.
> None of these should become the defualt as most of them do lose
> some functionality or have inconsistency and most people don't
> bother changing the defaults, so they won't know about the really
> good key bindings which exist (they are in fact extremely good for
> anyone who is a touch typest).
NO! NO! NO!
You shouldn't expect the beginners to be modifying their init file from
the first day. Expecting a beginner to learn Emacs Lisp (the syntax)
AND learn Emacs Lisp (the library) AND learn the Emacs keybindings AND
learn Emacs terminology is expecting way too much. Leave editing
init-files to the intermediate to expert users.
A new user should start by learning the keybinding patterns
(C-navigation/M-navigation/C-M-navigation, C-find/C-M-find, etc.) and a
bit of terminology. Later on they can start customizing the keybindings
to suit them. Expecting any more is like taxing the poor more than the
rich because "the rich people earned their money".
<snip>
>> I think C-x/C-c/C-v/C-z/C-o/C-s/C-a/mouse-3 are here to stay. Every
>> application I've seen in the past ten years, other than Emacs, has the
>> same meaning for each of these keybindings. Using the same meaning as
>> other applications here would be a *good* thing.
>
> Not when you view the whole range of keybindings and what impact this
> would have on them. Sure, a lot of new users would find cutting,
> copying pasting etc easier, but I suspect they would then find the
> rest of the key bindings much harder to follow and emacs has a lot
> more key bindings than most other programs.
>
> If someone can come up with a consistent approach which can work as
> well as the current one (or hopefully better), then put it forward. I
> don't have a problem with changing default behavior, but only when
> that change is going to give us real benefits and not lose us things.
> There is a lot more at stake here than changing a few key bindings -
> you also have to define a new methodology/approach to the key binding
> model so that developers know what keys they can and cannot use in
> their emacs apps.
There would be no benefit to experts. Experts already have gotten used
to Emacs' bindings or have developed workarounds. But there'd be
minimal pain to experts as well -- any expert who would not be able to
add the 12 lines of Emacs Lisp to move the navigation commands back to
f/b/n/p is not really an expert. Emacs could even have
classic-keybindings-mode that uses the old keybindings, so it'd be only
one line to add.
There would be a huge benefit to beginners. A beginner expects the
cua-bindings and gets confused and frustrated when they don't work. So
if it's minimal pain for experts
<snip>
>> All of Xah's other suggestions are pointless or not really thought
>> out. But don't discount everything Xah says just because he thinks the
>> *scratch* buffer should be eliminated or longlines-mode should be
>> enabled by default in every buffer. There are some good ideas in
>> there -- I think a longlines-code-mode would be really cool to have,
>> and making *scratch* start with buffers-offer-save=t would be nice.
>>
>
> I don't discount everything Xah says just because he says it (though I
> would say I'd be right to do so 80% of the time). I discount Xah as
> just meaningless white noise because he actually contributes nothing
> substantial and is not interested in debating his claims. He comes
> along and posts some personal rants with considerable amounts of abuse
> and swearing and always demands everyone else fix what he perceives as
> being wrong with the world, yet does nothing himself except send off
> some post with his latest rant to a newsgroup.
I think Xah is good at raising problems from a end-user point of view.
His solutions are often the wrong fix, but the problems he raises are
almost always valid. Don't ignore his claims just because he swears a
lot and is not interested in debating them.
One of the problems he raised was with the *scratch* buffer. Xah said
"Things emacs need to change for modern world: ... * Get rid of the
*scratch* buffer." While this is not the a helpful description of the
problem with the *scratch* buffer (it doesn't give any rationale), there
are still problems with it. In particular I've encountered the
following problems:
* It starts in lisp-interaction-mode, which I have never ever used at
program startup.
* Even though the buffer starts out with "This buffer is for notes you
don't want to save", I rarely want to lose any notes I take.
Both of these could be easily addressed. Make *scratch* start in
fundamental-mode and with buffer-offer-save=t. That'd take what, 2
lines of code?
In fact, I'm gonna do this for just me right now.
-- MJF
M Jared Finder <·····@hpalace.com> writes:
>
> It would not be difficult to cut some of the cruft in the key bindings
> to find room for Control-X-prefix and mode-specific-command-prefix,
> which would be stupid to eliminate. I'd suggest starting with
> uncommonly used bindings like C-] (abort-recursive-edit) and C-z
> (iconify-or-deiconify-frame).
OTOH, I use C-j often, so I'd like to keep that, thanks.
Gregm
M Jared Finder <·····@hpalace.com> writes:
> It would not be difficult to cut some of the cruft in the key bindings
> to find room for Control-X-prefix and mode-specific-command-prefix,
> which would be stupid to eliminate. I'd suggest starting with
> uncommonly used bindings like C-] (abort-recursive-edit) and C-z
> (iconify-or-deiconify-frame).
When using Emacs without a window-system (ie in a terminal/xterm/whatever),
C-z doing suspend-emacs is what one would expect (and vi not suspending
on C-z means that one does have to learn the magic spell (or open/find
a second terminal) to kill it). (I agree that iconify-or-deiconify-frame
is pretty useless and I have actually even removed this binding.)
On most non-US keyboards combinations like C-], C-\, C-_ and
occasionally even ··@ range from inconvenient (one has to press one or
two additional modifier keys in addition to control and the character
proper) to even impossible altogether (I wasn't able to produce C-] or
C-\ at all with Mac Terminal and a Danish keyboard).
M Jared Finder <·····@hpalace.com> writes:
> I've probably overzealously snipped your reply. If you feel I left
> something important out, please put it back and mention what I
> overlooked.
>
> Tim X wrote:
>> M Jared Finder <·····@hpalace.com> writes:
>>
>>> There is merit toward doing things the same way as everyone else.
>>> There's also merit in keeping things the same.
>>>
>>> The first makes it easy to learn other apps in a *basic* way; you can
>>> rely on certain things always being there and acting generally in one
>>> way. The second prevents you from having to re-learn an app as the
>>> popular interface changes. Both of these are useful; I know I
>>> encountered initial difficulty learning Emacs because
>>> C-x/C-c/C-v/C-z
>>> did not do what I expected. Now I use cua-mode, and everything works
>>> out fine.
>> This is probably where we will disagree - I think the merit of doing
>> things the same way as everywhere else has limited and often over
>> stated benefits. This can be hard to justify if it also means we lose
>> any real innovation.
>
> I disagree. In Gnu Emacs, by default every single-character control
> sequence from C-a to C-z as well as odd ones like ··@ is used for some
> purpose. However, there are only 20 commands that I find myself using
> often enough that I think they deserve having one letter bindings.
> All the others are taking up keyboard real estate that is not needed.
And here is probably where we get to the core of the problem. Emacs is
used by a lot of people in a lot of different ways and for a lot of
different 'common' tasks - what I do every day is probably different
from what you do every day. How do we work out which keys to use and
which commands to bind to them for the 20 most commonly used? Also,
are you sure all the keys from C-a to C-z are used? All of mine are
now, but I cannot remember which ones I've bound myself and which ones
were there by default.
> It would not be difficult to cut some of the cruft in the key bindings
> to find room for Control-X-prefix and mode-specific-command-prefix,
> which would be stupid to eliminate. I'd suggest starting with
> uncommonly used bindings like C-] (abort-recursive-edit) and C-z
> (iconify-or-deiconify-frame).
Well, for me C-z would not be a loss, but C-] is something I use quite
often - which I think possibly supports my argument that its not that
easy to just change the defaults.
>
>> There are three main reasons why I don't agree with changing the
>> default or modifying emacs base key bindings -
>> 1. The complaint everyone has surrounds the basic cut/copy/paste and
>> cursor movement keys. However, changing the current defaults will
>> create inconsistency with the underlying approach used in emacs
>> (yes, it actually does have a method to the maps). This will make
>> learning and becoming familiar with the other powerful key bindings
>> more difficult and it will becom eless likely new users will
>> realise this power exists. Note that for a long time, arrow keys,
>> pgup/pgdwn have worked anyway.
>
> That's not true. You could still keep the patterns native to the
> keybindings while moving around the keys the binding is on. If
> forward-character was moved to only be on <right>, there's nothing
> preventing M-<right> from being forward-word and C-M-<right> from
> being forward-sexp. In fact, that's how recent CVS Gnu Emacs works.
>
Good god no!
While I don't mind duplicate bindings on the arrow keys for those who
want them, I would hate to see the main keyborad movement keys taken
away. This is exactly the point I was trying to make about difference
and innovation. Everyone I've ever known who has gotten use to the
main keyborad movement keys has rather than using the arrow keys and
mouse has grown to love the ease and speed of using those keys over
the arrow keys. If we make only the arrow keys the default movement
key bindings, few people are going to benefit from the discovery of
how more efficient things can be using just the main keyborad keys.
For a touch typist, they are far more efficient than lifting your
hands off the keyborad.
> And if, as an expert, you want to move forward-char to C-k, you can
> easily move forward-word to M-k and forward-sexp to C-M-k.
>
>> 2. There is a lot of documentation and examples of how to bind keys
>> and change key bindings from the defaults, so lets leave them and
>> give the new user the opportunity to try something which many
>> consider superior to the common approach, but leave them with the
>> ability to change things if they don't like it.
>
>> 3. There are already plenty of packages which can change key bindings
>> to whatever other common environment/editor the new user wants.
>> None of these should become the defualt as most of them do lose
>> some functionality or have inconsistency and most people don't
>> bother changing the defaults, so they won't know about the really
>> good key bindings which exist (they are in fact extremely good for
>> anyone who is a touch typest).
>
> NO! NO! NO!
>
> You shouldn't expect the beginners to be modifying their init file
> from the first day. Expecting a beginner to learn Emacs Lisp (the
> syntax) AND learn Emacs Lisp (the library) AND learn the Emacs
> keybindings AND learn Emacs terminology is expecting way too much.
> Leave editing init-files to the intermediate to expert users.
Stop over stating the issue! Customize means for the vast majority of
things, the user doesn't even need to look in or even edit their
.emacs file. Adding a new package is generally quite straight forward
- especially these days when many are packaged in various installable
formats. Even when their not, its pretty bloody straight forward.
> A new user should start by learning the keybinding patterns
> (C-navigation/M-navigation/C-M-navigation, C-find/C-M-find, etc.) and
> a bit of terminology. Later on they can start customizing the
> keybindings to suit them. Expecting any more is like taxing the poor
> more than the
> rich because "the rich people earned their money".
>
I agree thats exactly what a new user should do. In fact, I've already
stated in this thread that new users should refraim from changing
anything until after around 6 months use. This is exactly why I don't
think the defaults shold be changed - let the new user spend some time
learning how emacs is currently configured and its current defaults.
Then later, if they don't like them change them - this is how they
will get to experience the real benefits - going down the other route
of changing the defaults to suit what new users are use to will result
in a 'dumbing down' of things and most users will never try the
alternative and thererfore will never see the other perspective.
Leaving the defaults a they are will expose them to a different
approach - if they try it and don't like it, they can change it.
> <snip>
>
>>> I think C-x/C-c/C-v/C-z/C-o/C-s/C-a/mouse-3 are here to stay. Every
>>> application I've seen in the past ten years, other than Emacs, has the
>>> same meaning for each of these keybindings. Using the same meaning as
>>> other applications here would be a *good* thing.
>> Not when you view the whole range of keybindings and what impact
>> this
>> would have on them. Sure, a lot of new users would find cutting,
>> copying pasting etc easier, but I suspect they would then find the
>> rest of the key bindings much harder to follow and emacs has a lot
>> more key bindings than most other programs. If someone can come up
>> with a consistent approach which can work as
>> well as the current one (or hopefully better), then put it forward. I
>> don't have a problem with changing default behavior, but only when
>> that change is going to give us real benefits and not lose us things.
>> There is a lot more at stake here than changing a few key bindings -
>> you also have to define a new methodology/approach to the key binding
>> model so that developers know what keys they can and cannot use in
>> their emacs apps.
>
> There would be no benefit to experts. Experts already have gotten
> used to Emacs' bindings or have developed workarounds. But there'd be
> minimal pain to experts as well -- any expert who would not be able to
> add the 12 lines of Emacs Lisp to move the navigation commands back to
> f/b/n/p is not really an expert. Emacs could even have
> classic-keybindings-mode that uses the old keybindings, so it'd be
> only one line to add.
>
I was referring to developers who want to set defaults to something
expected by other emacs users. If you don't have a methodology for
doing this, then developers are left to their own devices and we will
end up with even less consistency within emacs itself.
Something which I've not mentioned so far is how impracticle making
these superficial changes would be. One of the main benefits of emacs
is the huge wealth of existing packages out there, many of which were
written years ago and while still working perfectly, don't actually
have a maintainer anymore. How would all of these packages get updated
to ensure consistency with this new 'newbie friendly' keybinding
approach?
> There would be a huge benefit to beginners. A beginner expects the
> cua-bindings and gets confused and frustrated when they don't work.
> So if it's minimal pain for experts
>
This is where your mistaken - who said it wold be minimal pain. It
would be a *major* pain for the existing user community, which I would
argue is probably more valuable to emacs than a few new users who may
or may not stick around. It would be a pain for developers as they
woldn't know which way to go with defaults and it would be a pain when
dealing with older packages which are no longer actively maintained.
> <snip>
>
>>> All of Xah's other suggestions are pointless or not really thought
>>> out. But don't discount everything Xah says just because he thinks the
>>> *scratch* buffer should be eliminated or longlines-mode should be
>>> enabled by default in every buffer. There are some good ideas in
>>> there -- I think a longlines-code-mode would be really cool to have,
>>> and making *scratch* start with buffers-offer-save=t would be nice.
>>>
>> I don't discount everything Xah says just because he says it (though
>> I
>> would say I'd be right to do so 80% of the time). I discount Xah as
>> just meaningless white noise because he actually contributes nothing
>> substantial and is not interested in debating his claims. He comes
>> along and posts some personal rants with considerable amounts of abuse
>> and swearing and always demands everyone else fix what he perceives as
>> being wrong with the world, yet does nothing himself except send off
>> some post with his latest rant to a newsgroup.
>
> I think Xah is good at raising problems from a end-user point of view.
> His solutions are often the wrong fix, but the problems he raises are
> almost always valid. Don't ignore his claims just because he swears a
> lot and is not interested in debating them.
>
I've seen many of his claims and I've looked at his web site. He has
nothing of worth to offer at any level that I've ever seen. I guess
some people are more easily impressed than others.
> One of the problems he raised was with the *scratch* buffer. Xah said
> "Things emacs need to change for modern world: ... * Get rid of the
> *scratch* buffer." While this is not the a helpful description of the
> problem with the *scratch* buffer (it doesn't give any rationale),
> there are still problems with it. In particular I've encountered the
> following problems:
>
> * It starts in lisp-interaction-mode, which I have never ever used at
> program startup.
> * Even though the buffer starts out with "This buffer is for notes you
> don't want to save", I rarely want to lose any notes I take.
>
Well, I do a bit of elisp debugging and sometimes just do a very
simple fast elisp function for a one off editing task and I find the
scratch buffer very useful for that. I also have my emacs running for
days and often put little snippets of information/notes in there which
I may want to reference later - essentially, I use it like I use to
use a whiteboard prior to learning emacs. There is lots of stuff I
just want to note temporarily and not clutter up my more permanent
notes, Even so, a change to its default mode and possibly even having
it save on quit is an insignificant change which I could easily live
with. However, I would not agree with Xah's original assertion that it
should just be gotten rid of.
I also don't understand why, if people don't like it, they don't just
ignore it - its not like its using up heaps of resources and it
doesn't really cause any problems - use it if you find it useful,
ignore it if you don't - whats the big deal.
Part of the problem with Xah's rants is he only ever sees things from
his own limited experience and always comes to the conclusion that its
the software or the operating system which is wrong - there is no
evidence of any recognition that his frustrations or difficulties
could actually be due to his own narrow experience/opinions/world
view. He reminds me of one of those programmers who always jump tot he
conclusion that a bug is due to a problem in a library they are using
or the OS or due to some weird virus - they look at everything else
before recognising the problem is with their own code. More
experienced programmers know right away that the odds are extremely
high that any bug they encounter is due to their own mistakes or
misunderstanding.
> Both of these could be easily addressed. Make *scratch* start in
> fundamental-mode and with buffer-offer-save=t. That'd take what, 2
> lines of code?
>
> In fact, I'm gonna do this for just me right now.
>
Funny, but I think the mode the scratch buffer starts in is controlled
by a customize variable - I'm sure in the past it actually use to
start in fundamental mode now that I think about it. I'd never really
given it any thought and assumed the fact it was now in lisp
interaction mode was because I had customized it that way.
The fact you can change it so easily still doesn't seem to add much
support for any argument to change the current default behavior.
However, feel free to put it forward to the gnu development team. As I
said, I'm not so worried about what happens to the scratch buffer as
long as its not removed. Changing key bindings, well thats a horse of
a different colour.
tim
--
tcross (at) rapttech dot com dot au
Again, I had to overzeallously snip.
My point mainly is:
I think your overestimating the capabilities of a beginner. I know from
personal experience that not enabling cua-mode by default severely cuts
back on the number of people who use Emacs. It is much easier for an
expert to change their keymap, while it is crazy to expect a beginner to
find out about `cua-mode' -- they're just learning! That's why I'd
expect cua-mode to be enabled by default. That just means every
existing user would have to add (cua-mode -1) to their init file. Is
that so insanely difficult?
Xah often brings up valid symptoms of actual problems, though his
solution sucks 99% of the time.
-- MJF
Tim X wrote:
> M Jared Finder <·····@hpalace.com> writes:
>> Tim X wrote:
>>>
>>> 2. There is a lot of documentation and examples of how to bind keys
>>> and change key bindings from the defaults, so lets leave them and
>>> give the new user the opportunity to try something which many
>>> consider superior to the common approach, but leave them with the
>>> ability to change things if they don't like it.
>>> 3. There are already plenty of packages which can change key bindings
>>> to whatever other common environment/editor the new user wants.
>>> None of these should become the defualt as most of them do lose
>>> some functionality or have inconsistency and most people don't
>>> bother changing the defaults, so they won't know about the really
>>> good key bindings which exist (they are in fact extremely good for
>>> anyone who is a touch typest).
>> NO! NO! NO!
>>
>> You shouldn't expect the beginners to be modifying their init file
>> from the first day. Expecting a beginner to learn Emacs Lisp (the
>> syntax) AND learn Emacs Lisp (the library) AND learn the Emacs
>> keybindings AND learn Emacs terminology is expecting way too much.
>> Leave editing init-files to the intermediate to expert users.
>
> Stop over stating the issue! Customize means for the vast majority of
> things, the user doesn't even need to look in or even edit their
> ..emacs file. Adding a new package is generally quite straight forward
> - especially these days when many are packaged in various installable
> formats. Even when their not, its pretty bloody straight forward.
How does the beginner know about customize?
How does the beginner know where to look in customize? (Remember,
they're a beginner, so they don't know about apropos-variable, or any of
the describe-* functions).
A beginner should not have to navigate customize early on -- they don't
even understand the technology to know what to search for. How would
they know to find something called `cua-mode'?
Recent CVS Emacs is much better in this regard. It has a cua-mode
option under the options menu, which is one of the first places I'd look
for such a thing.
<snip>
>> There would be a huge benefit to beginners. A beginner expects the
>> cua-bindings and gets confused and frustrated when they don't work.
>> So if it's minimal pain for experts
>>
>
> This is where your mistaken - who said it wold be minimal pain. It
> would be a *major* pain for the existing user community, which I would
> argue is probably more valuable to emacs than a few new users who may
> or may not stick around. It would be a pain for developers as they
> woldn't know which way to go with defaults and it would be a pain when
> dealing with older packages which are no longer actively maintained.
Again, recent CVS Emacs is much better. It has a keymap <remap> that
allows you to bind commands to wherever existing commands are instead of
actual keys on the keyboard. A mode no longer has to assume the
"standard" keymap and can just set <remap> <find-file> to provide a
replacement to find-file, wherever it is bound to.
I hope XEmacs copies this feature, as it is gets us 50% of the way to
where the actual keybindings don't matter.
>> <snip>
>>
>>>> All of Xah's other suggestions are pointless or not really thought
>>>> out. But don't discount everything Xah says just because he thinks the
>>>> *scratch* buffer should be eliminated or longlines-mode should be
>>>> enabled by default in every buffer. There are some good ideas in
>>>> there -- I think a longlines-code-mode would be really cool to have,
>>>> and making *scratch* start with buffers-offer-save=t would be nice.
>>>>
>>> I don't discount everything Xah says just because he says it (though
>>> I
>>> would say I'd be right to do so 80% of the time). I discount Xah as
>>> just meaningless white noise because he actually contributes nothing
>>> substantial and is not interested in debating his claims. He comes
>>> along and posts some personal rants with considerable amounts of abuse
>>> and swearing and always demands everyone else fix what he perceives as
>>> being wrong with the world, yet does nothing himself except send off
>>> some post with his latest rant to a newsgroup.
>> I think Xah is good at raising problems from a end-user point of view.
>> His solutions are often the wrong fix, but the problems he raises are
>> almost always valid. Don't ignore his claims just because he swears a
>> lot and is not interested in debating them.
>>
>
> I've seen many of his claims and I've looked at his web site. He has
> nothing of worth to offer at any level that I've ever seen. I guess
> some people are more easily impressed than others.
I guess. :)
>
>> One of the problems he raised was with the *scratch* buffer. Xah said
>> "Things emacs need to change for modern world: ... * Get rid of the
>> *scratch* buffer." While this is not the a helpful description of the
>> problem with the *scratch* buffer (it doesn't give any rationale),
>> there are still problems with it. In particular I've encountered the
>> following problems:
>>
>> * It starts in lisp-interaction-mode, which I have never ever used at
>> program startup.
>> * Even though the buffer starts out with "This buffer is for notes you
>> don't want to save", I rarely want to lose any notes I take.
>>
>
> Well, I do a bit of elisp debugging and sometimes just do a very
> simple fast elisp function for a one off editing task and I find the
> scratch buffer very useful for that. I also have my emacs running for
> days and often put little snippets of information/notes in there which
> I may want to reference later - essentially, I use it like I use to
> use a whiteboard prior to learning emacs. There is lots of stuff I
> just want to note temporarily and not clutter up my more permanent
> notes, Even so, a change to its default mode and possibly even having
> it save on quit is an insignificant change which I could easily live
> with. However, I would not agree with Xah's original assertion that it
> should just be gotten rid of.
>
> I also don't understand why, if people don't like it, they don't just
> ignore it - its not like its using up heaps of resources and it
> doesn't really cause any problems - use it if you find it useful,
> ignore it if you don't - whats the big deal.
Because it's the first thing you're presented with. When you run an
application that you think of as a text editor, and it starts up with an
empty text field, is it reasonable to expect people to *not* put their
text there? I don't think so.
>
> Part of the problem with Xah's rants is he only ever sees things from
> his own limited experience and always comes to the conclusion that its
> the software or the operating system which is wrong - there is no
> evidence of any recognition that his frustrations or difficulties
> could actually be due to his own narrow experience/opinions/world
> view. He reminds me of one of those programmers who always jump tot he
> conclusion that a bug is due to a problem in a library they are using
> or the OS or due to some weird virus - they look at everything else
> before recognising the problem is with their own code. More
> experienced programmers know right away that the odds are extremely
> high that any bug they encounter is due to their own mistakes or
> misunderstanding.
>
>
>> Both of these could be easily addressed. Make *scratch* start in
>> fundamental-mode and with buffer-offer-save=t. That'd take what, 2
>> lines of code?
>>
>> In fact, I'm gonna do this for just me right now.
>>
>
> Funny, but I think the mode the scratch buffer starts in is controlled
> by a customize variable - I'm sure in the past it actually use to
> start in fundamental mode now that I think about it. I'd never really
> given it any thought and assumed the fact it was now in lisp
> interaction mode was because I had customized it that way.
>
> The fact you can change it so easily still doesn't seem to add much
> support for any argument to change the current default behavior.
> However, feel free to put it forward to the gnu development team. As I
> said, I'm not so worried about what happens to the scratch buffer as
> long as its not removed. Changing key bindings, well thats a horse of
> a different colour.
>
> tim
>
>
>
>
From: ··········@core.com
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <87y7y4rp47.fsf@linux.site>
M Jared Finder <·····@hpalace.com> writes:
> Again, I had to overzeallously snip.
>
> My point mainly is:
>
> I think your overestimating the capabilities of a beginner. I know
> from personal experience that not enabling cua-mode by default
> severely cuts back on the number of people who use Emacs. It is much
> easier for an expert to change their keymap, while it is crazy to
> expect a beginner to find out about `cua-mode' -- they're just
> learning! That's why I'd expect cua-mode to be enabled by default.
> That just means every existing user would have to add (cua-mode -1) to
> their init file. Is that so insanely difficult?
>
> Xah often brings up valid symptoms of actual problems, though his
> solution sucks 99% of the time.
>
> -- MJF
>
> Tim X wrote:
> > M Jared Finder <·····@hpalace.com> writes:
> >> Tim X wrote:
> >>>
> >>> 2. There is a lot of documentation and examples of how to bind keys
> >>> and change key bindings from the defaults, so lets leave them and
> >>> give the new user the opportunity to try something which many
> >>> consider superior to the common approach, but leave them with the
> >>> ability to change things if they don't like it.
> >>> 3. There are already plenty of packages which can change key bindings
> >>> to whatever other common environment/editor the new user wants.
> >>> None of these should become the defualt as most of them do lose
> >>> some functionality or have inconsistency and most people don't
> >>> bother changing the defaults, so they won't know about the really
> >>> good key bindings which exist (they are in fact extremely good for
> >>> anyone who is a touch typest).
> >> NO! NO! NO!
> >>
> >> You shouldn't expect the beginners to be modifying their init file
> >> from the first day. Expecting a beginner to learn Emacs Lisp (the
> >> syntax) AND learn Emacs Lisp (the library) AND learn the Emacs
> >> keybindings AND learn Emacs terminology is expecting way too much.
> >> Leave editing init-files to the intermediate to expert users.
> > Stop over stating the issue! Customize means for the vast majority of
> > things, the user doesn't even need to look in or even edit their
> > ..emacs file. Adding a new package is generally quite straight forward
> > - especially these days when many are packaged in various installable
> > formats. Even when their not, its pretty bloody straight forward.
>
> How does the beginner know about customize?
> How does the beginner know where to look in customize? (Remember,
> they're a beginner, so they don't know about apropos-variable, or any
> of the describe-* functions).
>
> A beginner should not have to navigate customize early on -- they
> don't even understand the technology to know what to search for. How
> would they know to find something called `cua-mode'?
>
> Recent CVS Emacs is much better in this regard. It has a cua-mode
> option under the options menu, which is one of the first places I'd
> look for such a thing.
>
> <snip>
>
> >> There would be a huge benefit to beginners. A beginner expects the
> >> cua-bindings and gets confused and frustrated when they don't work.
> >> So if it's minimal pain for experts
> >>
> > This is where your mistaken - who said it wold be minimal pain. It
> > would be a *major* pain for the existing user community, which I would
> > argue is probably more valuable to emacs than a few new users who may
> > or may not stick around. It would be a pain for developers as they
> > woldn't know which way to go with defaults and it would be a pain when
> > dealing with older packages which are no longer actively maintained.
>
> Again, recent CVS Emacs is much better. It has a keymap <remap> that
> allows you to bind commands to wherever existing commands are instead
> of actual keys on the keyboard. A mode no longer has to assume the
> "standard" keymap and can just set <remap> <find-file> to provide a
> replacement to find-file, wherever it is bound to.
>
> I hope XEmacs copies this feature, as it is gets us 50% of the way to
> where the actual keybindings don't matter.
>
> >> <snip>
> >>
> >>>> All of Xah's other suggestions are pointless or not really thought
> >>>> out. But don't discount everything Xah says just because he thinks the
> >>>> *scratch* buffer should be eliminated or longlines-mode should be
> >>>> enabled by default in every buffer. There are some good ideas in
> >>>> there -- I think a longlines-code-mode would be really cool to have,
> >>>> and making *scratch* start with buffers-offer-save=t would be nice.
> >>>>
> >>> I don't discount everything Xah says just because he says it (though
> >>> I
> >>> would say I'd be right to do so 80% of the time). I discount Xah as
> >>> just meaningless white noise because he actually contributes nothing
> >>> substantial and is not interested in debating his claims. He comes
> >>> along and posts some personal rants with considerable amounts of abuse
> >>> and swearing and always demands everyone else fix what he perceives as
> >>> being wrong with the world, yet does nothing himself except send off
> >>> some post with his latest rant to a newsgroup.
> >> I think Xah is good at raising problems from a end-user point of view.
> >> His solutions are often the wrong fix, but the problems he raises are
> >> almost always valid. Don't ignore his claims just because he swears a
> >> lot and is not interested in debating them.
> >>
> > I've seen many of his claims and I've looked at his web site. He has
> > nothing of worth to offer at any level that I've ever seen. I guess
> > some people are more easily impressed than others.
>
> I guess. :)
>
> >
> >> One of the problems he raised was with the *scratch* buffer. Xah said
> >> "Things emacs need to change for modern world: ... * Get rid of the
> >> *scratch* buffer." While this is not the a helpful description of the
> >> problem with the *scratch* buffer (it doesn't give any rationale),
> >> there are still problems with it. In particular I've encountered the
> >> following problems:
> >>
> >> * It starts in lisp-interaction-mode, which I have never ever used at
> >> program startup.
> >> * Even though the buffer starts out with "This buffer is for notes you
> >> don't want to save", I rarely want to lose any notes I take.
> >>
> > Well, I do a bit of elisp debugging and sometimes just do a very
> > simple fast elisp function for a one off editing task and I find the
> > scratch buffer very useful for that. I also have my emacs running for
> > days and often put little snippets of information/notes in there which
> > I may want to reference later - essentially, I use it like I use to
> > use a whiteboard prior to learning emacs. There is lots of stuff I
> > just want to note temporarily and not clutter up my more permanent
> > notes, Even so, a change to its default mode and possibly even having
> > it save on quit is an insignificant change which I could easily live
> > with. However, I would not agree with Xah's original assertion that it
> > should just be gotten rid of.
> > I also don't understand why, if people don't like it, they don't just
> > ignore it - its not like its using up heaps of resources and it
> > doesn't really cause any problems - use it if you find it useful,
> > ignore it if you don't - whats the big deal.
>
> Because it's the first thing you're presented with. When you run an
> application that you think of as a text editor, and it starts up with
> an empty text field, is it reasonable to expect people to *not* put
> their text there? I don't think so.
>
> > Part of the problem with Xah's rants is he only ever sees things from
> > his own limited experience and always comes to the conclusion that its
> > the software or the operating system which is wrong - there is no
> > evidence of any recognition that his frustrations or difficulties
> > could actually be due to his own narrow experience/opinions/world
> > view. He reminds me of one of those programmers who always jump tot he
> > conclusion that a bug is due to a problem in a library they are using
> > or the OS or due to some weird virus - they look at everything else
> > before recognising the problem is with their own code. More
> > experienced programmers know right away that the odds are extremely
> > high that any bug they encounter is due to their own mistakes or
> > misunderstanding.
> >> Both of these could be easily addressed. Make *scratch* start in
> >> fundamental-mode and with buffer-offer-save=t. That'd take what, 2
> >> lines of code?
> >>
> >> In fact, I'm gonna do this for just me right now.
> >>
> > Funny, but I think the mode the scratch buffer starts in is
> > controlled
> > by a customize variable - I'm sure in the past it actually use to
> > start in fundamental mode now that I think about it. I'd never really
> > given it any thought and assumed the fact it was now in lisp
> > interaction mode was because I had customized it that way. The fact
> > you can change it so easily still doesn't seem to add much
> > support for any argument to change the current default behavior.
> > However, feel free to put it forward to the gnu development team. As I
> > said, I'm not so worried about what happens to the scratch buffer as
> > long as its not removed. Changing key bindings, well thats a horse of
> > a different colour. tim
> >
I'm probably the least technically-adept person in here, since I'm a
writer, not a programmer (as I've said a million times here). But,
while I probably have more sympathy with Xah's position than most
here, I don't see any point in changing the keybindings (or even the
name keybindings) to CUA by default.
Although it was sometimes frustrating, when I was learning Emacs I
just accepted the keybindings as they were, reasoning there was some
logic behind them that as a beginner I couldn't initially see. Plus,
philosophically, any particular keybinding is arbitrary. And,
obviously, since one of the big attractions at the time was the
prospect of doing everything by keyboard (much more efficient than
rodents) I realized keybindings had to be different to accommodate the
huge number of commands.
It's like trading your car for a George Jetson car. Things will work
differently. Accept it.
I do partly agree that longlines.el should be the default in text
mode, since I use it every day, in place of autofill-mode. But I can't
see the reason to make it the default everywhere. Programming is
different than writing books and such.
Getting rid of the scratch buffer? Why? If you don't use it--and I'm
not a lisper--then ignore it. Actually I've learned just enough lisp
to make a couple of macros that do some simple adding and subtracting
for certain arithmetic problems I encounter every week. So even a
writer can find a use for it.
I think there is some validity to the argument that long-time users
forget the struggles of newbies. I'm thinking that maybe the help
files should incorporate right at the beginning suggestions on how to
approach Emacs. Not glossing over the differences but explaining why
there are differences and that fact makes Emacs the best writing or
programming machine around. Explaining that Emacs is not
user-unfriendly, even at the beginning, but just different because it
has to be. Remember George Jetson's car.
Maybe when I've got time some day I'll look into doing that.
--Rod
______________________
Author of "Linux for Non-Geeks--Clear-eyed Answers for Practical
Consumers" and "Boring Stories from Uncle Rod." To reply by e-mail
take the second "o" out of the e-mail address.
··········@core.com writes:
>
> I think there is some validity to the argument that long-time users
> forget the struggles of newbies. I'm thinking that maybe the help
> files should incorporate right at the beginning suggestions on how to
> approach Emacs. Not glossing over the differences but explaining why
> there are differences and that fact makes Emacs the best writing or
> programming machine around. Explaining that Emacs is not
> user-unfriendly, even at the beginning, but just different because it
> has to be. Remember George Jetson's car.
>
This strikes me as a far more sensible approach to the new user issue
(assuming there is an issue). Improved documentation is always a good
thing and something all users would benefit from. Finding those with
the style and expressive ability to write about technical issues
clearly is another matter. Writing for people is *much* more difficult
than writing for machines!
Tim
--
tcross (at) rapttech dot com dot au
M Jared Finder <·····@hpalace.com> writes:
> Again, I had to overzeallously snip.
>
> My point mainly is:
>
> I think your overestimating the capabilities of a beginner. I know
> from personal experience that not enabling cua-mode by default
> severely cuts back on the number of people who use Emacs.
I'd say that is a good thing. Somebody who is incapable of looking
into an "Options" menu is not something who is going to be happy with
Emacs in the long run.
> It is much easier for an expert to change their keymap, while it is
> crazy to expect a beginner to find out about `cua-mode' -- they're
> just learning!
What do you think the menu entry is for?
> That's why I'd expect cua-mode to be enabled by default.
Wrong. CUA mode immensively complicates the learning of Emacs since
it meddles with keybindings in contorted and hard to understand ways.
It is an _expert_ mode for people who have hardwired keyboard
reflexes.
> That just means every existing user would have to add (cua-mode -1)
> to their init file. Is that so insanely difficult?
The default of Emacs should be configured for productivity, not some
ill-advised pseudo-compatibility.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
M Jared Finder <·····@hpalace.com> writes:
> Again, I had to overzeallously snip.
>
> My point mainly is:
>
> I think your overestimating the capabilities of a beginner. I know
> from personal experience that not enabling cua-mode by default
> severely cuts back on the number of people who use Emacs. It is much
> easier for an expert to change their keymap, while it is crazy to
> expect a beginner to find out about `cua-mode' -- they're just
> learning! That's why I'd expect cua-mode to be enabled by default.
> That just means every existing user would have to add (cua-mode -1) to
> their init file. Is that so insanely difficult?
>
Its not difficult - but my point is that doing so whill mean that new
users will never get the chance to experience the productivity gains
you can obtain from the existing configuration - they will not move
from CUA mode and will not see the potential of the current defaults.
and of course there are the other issues I mentioned regarding
development and consistency of approaches.
Tim
--
tcross (at) rapttech dot com dot au
Tim X <····@nospam.dev.null> writes:
> Part of the problem with Xah's rants is he only ever sees things
> from his own limited experience and always comes to the conclusion
> that its the software or the operating system which is wrong - there
> is no evidence of any recognition that his frustrations or
> difficulties could actually be due to his own narrow
> experience/opinions/world view. He reminds me of one of those
> programmers who always jump tot he conclusion that a bug is due to a
> problem in a library they are using or the OS or due to some weird
> virus - they look at everything else before recognising the problem
> is with their own code. More experienced programmers know right away
> that the odds are extremely high that any bug they encounter is due
> to their own mistakes or misunderstanding.
Anecdote: some program of mine would not work properly, miscalculating
addresses (this was at a time when real men programmed in assembly).
After searching my eyes blind in the source, I finally went into very
fine-grained step-by-step debugging. It turned out that a particular
arithmetic shift right command did not consistently manage to keep an
existing sign bit set. This was a working, stable system. I
exchanged the CPU (a Z80A CPU), and the problem was gone.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
+ David Kastrup <···@gnu.org>:
| Tim X <····@nospam.dev.null> writes:
|
|> More experienced programmers know right away
|> that the odds are extremely high that any bug they encounter is due
|> to their own mistakes or misunderstanding.
|
| Anecdote: some program of mine would not work properly, miscalculating
| addresses (this was at a time when real men programmed in assembly).
Don't get me started on the story of the HP LaserJet 4Si that we used
back in 1994, that had a flaky rmoveto operator. It was totally
consistent in the sense that any document triggering the bug always
did so in the same way, but it only affected one or two percent of all
documents. We would typically see a subscript displaced a couple
centimeters to the right of its proper position. Took me most of a
day to figure out what was going on: I essentially wrote a small
noninteractive debugger in PostScript and instrumented the problem
file with it. Once the problem was diagnosed, the fix was easy
enough:
userdict /rmoveto known {stop} if
serverdict begin
0 exitserver
userdict
/rmoveto
{ currentpoint 3 2 roll add 3 1 roll add exch moveto } bind readonly
put
But fun as these anecdotes are, they don't invalidate Tim's
point. Though a disturbingly high proportion of bugs that I have
encountered were due to other programmers' mistakes rather than my
own. Part of the cost of living in an open source world, it seems.
(Uh-oh, let's leave the lid on that particular can of worms.)
Let me hasten to add that GNU emacs has been one of the more trouble
free programs in this respect.
--
* 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
"Xah Lee" <···@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.
> [... 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.
Pascal Bourguignon wrote:
> "Xah Lee" <···@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.
From: =?UTF-8?B?RnJvZGUgw5hpam9yZA==?=
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <443A5F34.2030102@sim.no>
Xah Lee wrote:
> 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.
>
This has been available for quite some time. Just enable cua-mode: M-x
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"
On Mon, 10 Apr 2006 15:35:48 +0200, =?UTF-8?B?RnJvZGUgw5hpam9yZA==?=
<·····@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]
Xah Lee wrote:
> 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
M Jared Finder <·····@hpalace.com> writes:
> 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]
Miles Bader wrote:
> M Jared Finder <·····@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
M Jared Finder <·····@hpalace.com> writes:
> Miles Bader wrote:
> > M Jared Finder <·····@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?
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.
On Wed, 12 Apr 2006 05:15:26 +0200, Dale Henderson <······@hotpop.com>
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/
M Jared Finder <·····@hpalace.com> writes:
> Miles Bader wrote:
>> M Jared Finder <·····@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?
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.)
M Jared Finder writes:
> Miles Bader wrote:
>> M Jared Finder <·····@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
"Xah Lee" <···@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.
> * 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
> ···@xahlee.org
> � http://xahlee.org/
>
If we do what you say, emacs will just be a glorified M$ Notepad (TM
of course) clone.
--
Dushkin
http://www.dushkin.org/
+ ················@yahoo.com:
| 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
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
Ray Dillinger wrote:
> Let's take this and turn it on its head.
>
> 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.
It should be able to keep up when I type. Yes, I mean even with
font-lock turned on.
--tim
"Tim Bradshaw" <··········@tfeb.org> writes:
> 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"
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). 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
"Tim Bradshaw" <··········@tfeb.org> writes:
> 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.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
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).
>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
Tim Bradshaw <··········@tfeb.org> wrote:
+---------------
| 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!
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
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
Benjamin Teuber <······@web.de> writes:
>
> 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.'
Benjamin Teuber <······@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...
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.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Benjamin Teuber <······@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?
Personally, I like the simplicity of a basic emacs with toolbars
turned off.
Tim
--
tcross (at) rapttech dot com dot au
From: Floyd L. Davidson
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <87slohztoj.fld@apaflo.com>
Tim X <····@nospam.dev.null> wrote:
>Benjamin Teuber <······@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) ·····@apaflo.com
On Thu, 13 Apr 2006 11:55:08 +0200, Floyd L. Davidson <·····@apaflo.com>
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/
From: Floyd L. Davidson
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <87odz5zqo0.fld@apaflo.com>
"John Thingstad" <··············@chello.no> wrote:
>On Thu, 13 Apr 2006 11:55:08 +0200, Floyd L. Davidson
><·····@apaflo.com> 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.
Apparently not carefully enough. It was designed to implement a
monopolistic business plan... and the overall design strategy
worked (for Bill Gates instead of IBM, but...).
>That noone ever did this
>for X-Windows,
>now that is obvious.
Why would anyone do that for X? It does not use key bindings...
>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.
That doesn't make for very good logic. You are saying that once
a majority of people have adopted any given design, everyone
else should join in, regardless of whether it is a good design.
If the popularity was based on good design, I might agree... but
it virtually *never* is (and instead is almost always based on who
has the best marketing!).
>> 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.
The keyboard interface design should have a priority for easy
*usage*, not easy *learning*. Your suggestion is backwards and
leads to the kind of poor design others are advocating.
>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.
So you are saying that the example discussed earlier in this
thread was correct, where supposedly the <Home> key is a better
choice than C-a for beginning-of-line and <End> is a better
choice than C-e for end-of-line???? That is an very good
example of the backwards "intuitive" design advocated above.
The fact is that those key bindings become *reflexive* after
sufficient use. The highest priority is *not* whether it is
obvious to a beginner what they do, but how easily they can be
fingered by an expert.
Given that there is very little variation in keyboard location
and fingering for C-a and C-e, but there is a huge variation in
where the <Home> and <End> keys are located, it is absurd to use
the <Home> and <End> keys for commonly keyed commands.
And I would argue that those are very non-intuitive bindings
anyway, as it seems obvious that <Home> and <End> either apply
to the beginning and end of the screen display or the buffer
being displayed.
>> 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.
But that *is* what Microsoft has set out to do in many
instances, which was my point (though I may not have worded that
clearly enough).
>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.
And as long as Emacs does *not* give in to the type of
complaints that have been registered in this thread, they will
continue to deserve praise.
--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) ·····@apaflo.com
"John Thingstad" <··············@chello.no> writes:
> 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.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
On Thu, 13 Apr 2006 12:23:16 +0200, David Kastrup <···@gnu.org> wrote:
> "John Thingstad" <··············@chello.no> writes:
>
>> 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.
>
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..
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Floyd L. Davidson
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <87k69tzpv7.fld@apaflo.com>
"John Thingstad" <··············@chello.no> wrote:
>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..
A cludge??? How about a process that eventually ends up
providing the *right* solution, rather than the most
successfully marketed solution?
For example, I do not use Gnome, KDE, or Motif. I run X based
systems, using a very well honed FVWM configuration.
Your "cludge" is opportunity knocking...
--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) ·····@apaflo.com
"John Thingstad" <··············@chello.no> writes:
> On Thu, 13 Apr 2006 12:23:16 +0200, David Kastrup <···@gnu.org> wrote:
>
>> "John Thingstad" <··············@chello.no> writes:
>>
>>> 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.
>
> I said the X-windows system, not the X protocol.
I can read. And I can write, and you should be able to read what I
have written. I did not talk about the "X protocol".
> And yes, it was experimental and buildt to discover
> what a GUI should behave like so it laid most decitions open.
The X Window system is a network transparent hardware interface, not a
GUI. It does not interpret keystrokes, but makes them available. It
is not a "GUI with most decisions open", no more than flour is a "cake
with most decisions open". It is a network transparent hardware
interface.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
On Thu, 13 Apr 2006 12:55:31 +0200, David Kastrup <···@gnu.org> wrote:
> The X Window system is a network transparent hardware interface, not a
> GUI. It does not interpret keystrokes, but makes them available. It
> is not a "GUI with most decisions open", no more than flour is a "cake
> with most decisions open". It is a network transparent hardware
> interface.
>
Note that mwm, KDE, Gnome are all window managers written on to of
X-Windows a network transparent GUI toolkit..
You can call it a hardware interface if you like though that makes me
think of device drivers. Anyhow a server part which the application
connects to, and a client part which renders the graphics and connects
to the server allows you to run windows programs from several machines
on one client with ease.
No XLib, it is not like the Win32 API, it is more primitive.
Like a window is a rectangle on the screen to which you can add for
instance backingstore. If you want borders you have to draw them youself
in XLib.
To assign such behaviour you put a window manager on top.
(THAT handles key bindings.) Also you you add Library.
The first one I programmed used mwm, Xt and Motif widget set.
The last used KDE, Qt.
That clearer?
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"John Thingstad" <··············@chello.no> writes:
> On Thu, 13 Apr 2006 12:55:31 +0200, David Kastrup <···@gnu.org> wrote:
>
>> The X Window system is a network transparent hardware interface, not a
>> GUI. It does not interpret keystrokes, but makes them available. It
>> is not a "GUI with most decisions open", no more than flour is a "cake
>> with most decisions open". It is a network transparent hardware
>> interface.
>>
>
> Note that mwm, KDE, Gnome are all window managers written on to of
> X-Windows a network transparent GUI toolkit..
> You can call it a hardware interface if you like though that makes me
> think of device drivers.
Why "though"? This is very much what the X Window system provides: a
hardware abstraction layer, just that it is also network transparent.
Which implies that the client libraries usually access a separate
server which needs not be located on the same host.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Hi John,
>>>>> "John" == John Thingstad <··············@chello.no> writes:
John> The microsoft key inteface is part of the Common User Access Document
John> (CUA).
John> It was developed by IBM, not Microsoft. And they did spend the best part of
John> two years carefully thinking it out. That noone ever did this for
John> X-Windows,
John> now that is obvious.
X-Windows is not a GUI. It is just the mechanism, not the policy. And as
far as network transparent window-systems go X-Windows is fairly
decent. (Not that there is currently much competition.) In the
MS-Windows world they have to use a browser and web-apps to simulate
that.
John> With upteent window managers and people typically using software
John> written for
John> several you never know what you are going to get.
John> Every program on it's own in a sense defeats the point of a integrated
John> inteface.
Choice is a good thing (tm).
John> People will have a easier time learning to use it if things work as
John> the expect.
I don#t think that 'ease of learning' should be more important than
'ease of use'.
John> Arrow keys, home, end etc.. It is visually intuetive to see what these keys
John> do. If they have to look up basic commands like moving a cursor that
John> alone would turn many away from the program.
If people are that easily turned away from using emacs, then that is
probably a goot thing :-)
'Andreas
--
Wherever I lay my .emacs, there's my $HOME.
Floyd L. Davidson wrote:
> Tim X <····@nospam.dev.null> wrote:
>> 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?
I didn't see the GTK build yet - sounds nice...
And of course I didn't talk about the latter...
> 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.
Ha, it feels great to be put in your
another-silly-emacs-critic-who-knows-nothing scheme...
Although I wouldn't consider myself an expert, I use emacs for quite a
while and I really love its power and extensibility.
I don't want any f***in change to functionality - so stop your
prejudices - just ugly scrollbars etc. are disturbing me a bit...
> Which of course makes the complaint useless.
The useless post was yours...
Tim X <····@nospam.dev.null> writes:
> 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, Kriemhildstr. 15, 44793 Bochum
Tim X <····@nospam.dev.null> writes:
> 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.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
David Kastrup wrote:
> Tim X <····@nospam.dev.null> writes:
>
> > 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.
I use the toolbar sometimes when browsing Info files. If you want to
read Info pages the same way as web pages, i.e. with a mouse, then it's
very useful. Reading info this was is useful if you have to copy its
contents into another application, which sometimes happens.
Rob Warnock wrote:
> 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;}
Rob Warnock wrote:
>
> 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!
A long time ago someone posted a proof (well, an informal one I guess)
that vi was turing-equivalent (and not vim or something, the original
vi). So it really does have all these things, if a bit obscurely.
So I revise my plan. I am now implementing teco in vi, possibly via
intermidiate PDP-10 and applescript emulation layers.
--tim
"Tim Bradshaw" <··········@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.
> 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, Kriemhildstr. 15, 44793 Bochum
David Kastrup wrote:
> "Tim Bradshaw" <··········@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/
Pascal Costanza <··@p-cos.net> writes:
> David Kastrup wrote:
> > "Tim Bradshaw" <··········@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
Greg Menke <·············@toadmail.com> writes:
> Pascal Costanza <··@p-cos.net> writes:
>
>> David Kastrup wrote:
>> > "Tim Bradshaw" <··········@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.
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.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
David Kastrup <···@gnu.org> writes:
> Greg Menke <·············@toadmail.com> writes:
>
> > Pascal Costanza <··@p-cos.net> writes:
> >
> >> David Kastrup wrote:
> >> > "Tim Bradshaw" <··········@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.
>
> 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.
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
Greg Menke wrote:
> 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)
Greg Menke <·············@toadmail.com> writes:
> 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
_`\(,_
(_)/ (_) --- ---
Edward Dodge <····@foo.bar> writes:
> Greg Menke <·············@toadmail.com> writes:
>
> > 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.
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
David Kastrup wrote:
> Greg Menke <·············@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.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
From: Alan Mackenzie
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <bb0l1e.2b.ln@acm.acm>
David Kastrup <···@gnu.org> wrote on Wed, 12 Apr 2006 11:01:01 +0200:
> "Tim Bradshaw" <··········@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: ····@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").
Alan Mackenzie <···@muc.de> writes:
> David Kastrup <···@gnu.org> wrote on Wed, 12 Apr 2006 11:01:01 +0200:
>> "Tim Bradshaw" <··········@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.
What about "for the purpose of complaining about unusable defaults"
did you not understand?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
David Kastrup wrote:
> 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.
The point I was trying to make is that neither font-lock, nor XEmacs is
the problem (because I use very similar versions of both on other
machines, including much slower machines (like 2-300MHz Suns), where
they are just fine): the problem is the mac port, which has absolutely
grim performance. And, well, that's not suprising, because it's not X
- it's not even Windows - so hardly any people are working on it.
That's why all the mac Emacs ports suck (and really why almost all
versions of free software applications with GUIs (which have existences
off the mac) suck on the mac).
But the *actual* point was that what I'd like emacs to do is to be a
bit faster on one of the platforms I use. In particular, I don't want
all the make-it-more-fashionable crap, or if I do, I consider it hugely
less important than almost anything else.
--tim
"Tim Bradshaw" <··········@tfeb.org> writes:
> David Kastrup wrote:
>
>> 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.
>
> The point I was trying to make is that neither font-lock, nor XEmacs is
> the problem (because I use very similar versions of both on other
> machines, including much slower machines (like 2-300MHz Suns), where
> they are just fine): the problem is the mac port, which has absolutely
> grim performance.
Sigh. Font lock performance does not change between platforms.
> And, well, that's not suprising, because it's not X - it's not even
> Windows - so hardly any people are working on it.
Which must be why Emacs (as opposed to XEmacs) has a pretty thoroughly
maintained MacOSX branch, as well as two separate packagings by
external developers. Get real.
> That's why all the mac Emacs ports suck (and really why almost all
> versions of free software applications with GUIs (which have
> existences off the mac) suck on the mac).
Too bad that the Emacs ports are functional. It is just the XEmacs
port which is unbearable.
> But the *actual* point was that what I'd like emacs to do is to be a
> bit faster on one of the platforms I use. In particular, I don't
> want all the make-it-more-fashionable crap, or if I do, I consider
> it hugely less important than almost anything else.
You have to decide at one point of time whether you are talking about
Emacs or XEmacs, so that the right people get motivated to rush to
your aid.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
"Tim Bradshaw" <··········@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, Kriemhildstr. 15, 44793 Bochum
"Tim Bradshaw" <··········@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, 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
--
tcross (at) rapttech dot com dot au
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
From: Bill Atkins
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <87veteqyb8.fsf@rpi.edu>
"Tom Lord" <····@emf.net> writes:
> 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
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.
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
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.
--
* 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
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> 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, Kriemhildstr. 15, 44793 Bochum
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> 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.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Christophe Rhodes
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <sqirpeo5ar.fsf@cam.ac.uk>
[ not scheme: note followups, and apologies to readers in c.l.s if
this comes across the wrong way ]
"Tom Lord" <····@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
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
Christophe Rhodes <·····@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?
From: Bill Atkins
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <87mzeqtjlk.fsf@rpi.edu>
Ari Johnson <·········@gmail.com> writes:
> [...]
> 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
Bill Atkins <············@rpi.edu> writes:
> Ari Johnson <·········@gmail.com> writes:
>
>> [...]
>> 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.
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.
Ari Johnson <·········@gmail.com> writes:
> Bill Atkins <············@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.
--
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.
---------------------------------------------------------------------
I was not going to bring up Climacs, because it is not ready for
prime time, but Christophe did, so now I feel I should comment.
Ari Johnson <·········@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 <·······@labri.fr> writes:
> 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.
I would personally find it useful if Climacs had a non-graphical
interface, as does Emacs. However, I think that this feature would so
substantially get in the way of your actual project that I completely
understand why it is not a consideration. I guess I'm just jealous of
all the Linux people who have a free CLIM. :)
Ari Johnson <·········@gmail.com> writes:
> Robert Strandh <·······@labri.fr> writes:
>
> > 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.
>
> I would personally find it useful if Climacs had a non-graphical
> interface, as does Emacs. However, I think that this feature would so
> substantially get in the way of your actual project that I completely
> understand why it is not a consideration. I guess I'm just jealous of
> all the Linux people who have a free CLIM. :)
I still make use of non-gui emacs all the time, particularly when
bandwidth or latency challenged. I'm probably being old fashioned,
but I'd like to see that kind of functionality continued.
To me this discussion sounds sort of like comparing plan9 to unix.
Many people think that plan9 is superior, to the point of plan9
functionality being ported into more mainstream unix-like systems.
However, unix-like systems continue to work well enough to hold on to
their "market share" of OS users and implementors. It seems to me
that the same kind of thing is happening with emacs.
Best regards,
--Bruce
--
Robert "Bruce" Carleton
Robert Bruce Carleton <···@hakuhale.net> writes:
> I still make use of non-gui emacs all the time, particularly when
> bandwidth or latency challenged. I'm probably being old fashioned,
> but I'd like to see that kind of functionality continued.
I agree, and I use Emacs like that all the time, in particular for
reading my email at a distance.
--
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.
---------------------------------------------------------------------
Ari Johnson <·········@gmail.com> writes:
> I would personally find it useful if Climacs had a non-graphical
> interface, as does Emacs. However, I think that this feature would so
> substantially get in the way of your actual project that I completely
> understand why it is not a consideration. I guess I'm just jealous of
> all the Linux people who have a free CLIM. :)
Actually, a TTY backend for McCLIM has been considered, and I think
that's the right way to get Climacs to run in an ordinary terminal
or terminal emulator.
--
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.
---------------------------------------------------------------------
Christophe Rhodes <·····@cam.ac.uk> writes:
>
> "Tom Lord" <····@emf.net> writes:
>
>> 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?
IIRC, doesn't the Climacs project wish to avoid the path of emacs and
instead focus simply on being a text editor? This wouldn't really jive
with Mr. Lord's desire for a general-purpose application framework...
--
Robert Uhl <http://public.xdi.org/=ruhl>
We might have inherited the might of the British Navy, but everyone else
seems to have inherited the class. --Tom Uhl, USN
Robert Uhl <·········@NOSPAMgmail.com> writes:
> IIRC, doesn't the Climacs project wish to avoid the path of emacs and
> instead focus simply on being a text editor? This wouldn't really jive
> with Mr. Lord's desire for a general-purpose application framework...
In my opinion, Emacs provides a framework for applications simply
because no other such framework existed at the time. Now we have
CLIM/McCLIM, which does a great job supplying such a framework.
--
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 <·······@labri.fr> writes:
>
>> IIRC, doesn't the Climacs project wish to avoid the path of emacs and
>> instead focus simply on being a text editor? This wouldn't really
>> jive with Mr. Lord's desire for a general-purpose application
>> framework...
>
> In my opinion, Emacs provides a framework for applications simply
> because no other such framework existed at the time. Now we have
> CLIM/McCLIM, which does a great job supplying such a framework.
I disagree. The vast majority of the tasks performed with a computer
involve reading and writing text (yes, some people create graphics, but
they are a relatively small fraction of the computer-using population).
Given that we're all reading & writing text constantly, it makes sense
for all text viewing & editing to take place within a consistent and
uniform environment--and thus that it take place within one environment.
Emacs provides this environment: C-v always scrolls down; C-g always
gets me out of whatever predicament I've gotten myself into. In some
ways it really is like an OS which hosts many applications--the only
thing is that they can each access one another's internals very easily.
I suppose that this is a good amount of the attraction of a Lisp OS,
come to think of it.
Anyway, CLIM supplies an arcane, painful to learn framework whereas that
of emacs is straightforward and easy to get started with. I hardly
think that one can substitute for the other.
--
Robert Uhl <http://public.xdi.org/=ruhl>
The word denoting a young lady who must be returned to her father's
house at the end of the evening eventually changes from 'date' to
'babysitter.' --Anthony de Boer
Robert Uhl <·········@NOSPAMgmail.com> writes:
> Robert Strandh <·······@labri.fr> writes:
> >
> > In my opinion, Emacs provides a framework for applications simply
> > because no other such framework existed at the time. Now we have
> > CLIM/McCLIM, which does a great job supplying such a framework.
>
> Given that we're all reading & writing text constantly, it makes sense
> for all text viewing & editing to take place within a consistent and
> uniform environment--and thus that it take place within one environment.
Sure, this is fine. However, many of the applications that are
implemented in the Emacs environment do not even need to edit the
text, and do not need the concept of an Emacs buffer to display their
contents. In my opinion, the main part of a text editor is about
efficiently managing incremental changes to a buffer, incrementally
parsing the contents after such modifications, and displaying
incremental changes efficiently.
> Emacs provides this environment: C-v always scrolls down; C-g always
> gets me out of whatever predicament I've gotten myself into.
Yes. In fact I abstracted out this particular aspect of Climacs into
the ESA (Emacs-Style Application) library, which is now also used for
completely different applications such as the Gsharp score editor and
the dired application. The ESA library also contains things like
numeric argument handling, keyboard macros, minibuffer management, and
more. I find it very useful not to tie this together with text
editing, though.
> In some
> ways it really is like an OS which hosts many applications--the only
> thing is that they can each access one another's internals very easily.
> I suppose that this is a good amount of the attraction of a Lisp OS,
> come to think of it.
Yes, and that is also the reason I am using CLIM for that.
> Anyway, CLIM supplies an arcane, painful to learn framework whereas that
> of emacs is straightforward and easy to get started with. I hardly
> think that one can substitute for the other.
Really? CLIM is an extremely rich and flexible framework for writing
collaborating applications. I guess ESA is proof of this; it shows
that you can replace the default CLIM command loop without giving up
presentation types, and the other goodies of CLIM.
--
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.
---------------------------------------------------------------------
From: Christophe Rhodes
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <sq7j5qo0er.fsf@cam.ac.uk>
[ note f'ups: limited relevance to emacs by now ]
Robert Uhl <·········@NOSPAMgmail.com> writes:
> I disagree. The vast majority of the tasks performed with a computer
> involve reading and writing text (yes, some people create graphics, but
> they are a relatively small fraction of the computer-using population).
Many, many people deal with sound and images these days, at least
recreationally. Most people who use digital cameras, people with
portable MP3 players, those downloading or making podcasts, not to
mention amateur use of their computers as sound recorders, mixing
desks, synthesizers, score editors... people also use their computers
to prepare tax returns, multimedia presentations (not that that's
necessarily a good thing ;-); typeset scientific papers with
equations, tables or figures in them; share their calendars with other
members of their office; telephone each other, trade stocks... the
list goes on.
Where does your assertion about the vast majority of tasks come from,
and how is it relevant even if it is true? The existence of even a
small minority of "tasks" which are not well modelled by the
text-in-a-buffer paradigm does not invalidate that paradigm in its
entirety, but it does invalidate that paradigm's claim to be able to
model everything.
> Given that we're all reading & writing text constantly, it makes sense
> for all text viewing & editing to take place within a consistent and
> uniform environment--and thus that it take place within one environment.
This, on the other hand, is quite a reasonable claim; consistency, for
similar actions, probably assists in learning applications of
non-trivial complexity.
> Emacs provides this environment: C-v always scrolls down; C-g always
> gets me out of whatever predicament I've gotten myself into.
It does that by convention. There is nothing preventing a piece of
code globally rebinding C-v or C-g to scroll-up or repeat; I am not
arguing that there should necessarily be, only that your perfectly
stable environment isn't that way by divine fiat nor even by
intelligent design of the emacs environment itself, but by the social
context in which it has evolved.
> Anyway, CLIM supplies an arcane, painful to learn framework whereas that
> of emacs is straightforward and easy to get started with. I hardly
> think that one can substitute for the other.
For the user of emacs (CLIM) or for the developer of software to run
on emacs (CLIM)? Not that it matters much to me, though some (see
upthread passim :-) might dispute that emacs is straightforward and
easy to start with; I dispute your characterisation of CLIM, though I
am happy to concede that the availability of CLIM didactic material is
far more limited than for emacs, and suspect that this might have
bearing on your perception.
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
> [ note f'ups: limited relevance to emacs by now ]
>
> Robert Uhl <·········@NOSPAMgmail.com> writes:
>
>> I disagree. The vast majority of the tasks performed with a computer
>> involve reading and writing text (yes, some people create graphics, but
>> they are a relatively small fraction of the computer-using population).
>
> Many, many people deal with sound and images these days, at least
> recreationally.
I don't deny that--but that's not, I believe, the majority of use. And
_viewing_ images and _hearing_ sounds can be handled pretty
satisfactorily with a text viewer--it's the editing which doesn't mesh.
> people also use their computers to prepare tax returns
Which are composed of numbers, which are characters, which are text.
Emacs offers as good an interface to editing a tax return as the web app
I recently used.
> typeset scientific papers with equations, tables or figures in them
I think that a text+ editor can handle that pretty well. Those are all
still, at heart, dealing with characters.
> share their calendars with other members of their office; telephone
> each other, trade stocks... the list goes on.
And I think that all that still works with a text editor: calendars are
just characters; telephone numbers are just numbers; stocks are named
with text, their info is text. A good hypertext-aware editor can handle
all that, viz. emacs-w3m.
> Where does your assertion about the vast majority of tasks come from,
> and how is it relevant even if it is true?
Sheer assertion:-)
But I can say from professional experience that the vast majority of
business computer use is viewing text with some pretty pictures added.
> The existence of even a small minority of "tasks" which are not well
> modelled by the text-in-a-buffer paradigm does not invalidate that
> paradigm in its entirety, but it does invalidate that paradigm's claim
> to be able to model everything.
I don't think that I claimed that it could model _everything_, nor that
anyone who advocates the kitchen-sink emacs style claims such--merely
that it models the common case.
Certainly, if one wishes to edit an audio file then one needs a
specialised editor. But if one is sending email, writing proposals or
viewing product documentation, then a text editor can handle one's needs.
>> Anyway, CLIM supplies an arcane, painful to learn framework whereas
>> that of emacs is straightforward and easy to get started with. I
>> hardly think that one can substitute for the other.
>
> For the user of emacs (CLIM) or for the developer of software to run
> on emacs (CLIM)?
The developer. Writing elisp is pretty easy--I've even written a little
major mode to deal with my blog postings--writing CLIM code is...rather
less so. Much of this is because emacs already handles all of the
annoying, niggling little stuff for one, and one can just dive in and
start working on one's problem.
If Climacs would provide the same environment, then it would be much
easier to dive into...
> Not that it matters much to me, though some (see upthread passim :-)
> might dispute that emacs is straightforward and easy to start with; I
> dispute your characterisation of CLIM, though I am happy to concede
> that the availability of CLIM didactic material is far more limited
> than for emacs, and suspect that this might have bearing on your
> perception.
I'll admit that's part of it--but seriously, I've not found too many
good introductions to learning how to write good emacs lisp. But to
learn how to write a few elisp extensions to do a common task is
relatively easy, while figuring out how to do much with CLIM is...not.
I tried to like CLIM, I really did.
And if Climacs would try to be as extensible as emacs, then maybe I
could slowly dip my toes in, as I can with emacs!
--
Robert Uhl <http://public.xdi.org/=ruhl>
I once did a dd if=bootdisk.img of=/dev/hda. Luckily, /dev/hda had
Windows 95 and a swap partition on it. /dev/hdb was where Linux lived.
Nothing important was lost. --PD
From: Christophe Rhodes
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <sq64l8fxq0.fsf@cam.ac.uk>
Robert Uhl <·········@NOSPAMgmail.com> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
>> [ note f'ups: limited relevance to emacs by now ]
>>
>> Robert Uhl <·········@NOSPAMgmail.com> writes:
>>
>>> I disagree. The vast majority of the tasks performed with a computer
>>> involve reading and writing text (yes, some people create graphics, but
>>> they are a relatively small fraction of the computer-using population).
>>
>> Many, many people deal with sound and images these days, at least
>> recreationally.
>
> I don't deny that--but that's not, I believe, the majority of use.
Well, OK, but that's not what you said either; you said "the majority
of tasks", not "the majority of time spent". I disagree with your
rationalization of everything as a sequence of characters; I think
that that kind of reductionism is unhelpful and limiting.
> And _viewing_ images and _hearing_ sounds can be handled pretty
> satisfactorily with a text viewer--it's the editing which doesn't
> mesh.
"pretty satisfactorily" or "very well"? Why aim for just
satisfactory? Emacs is very, very good at what it does well; why
shoehorn it into an adequate application somewhere where it doesn't
quite fit?
>> people also use their computers to prepare tax returns
>
> Which are composed of numbers, which are characters, which are text.
> Emacs offers as good an interface to editing a tax return as the web app
> I recently used.
>
>> typeset scientific papers with equations, tables or figures in them
>
> I think that a text+ editor can handle that pretty well. Those are all
> still, at heart, dealing with characters.
>
>> share their calendars with other members of their office; telephone
>> each other, trade stocks... the list goes on.
>
> And I think that all that still works with a text editor: calendars are
> just characters; telephone numbers are just numbers; stocks are named
> with text, their info is text. A good hypertext-aware editor can handle
> all that, viz. emacs-w3m.
Yes, all of these things /can/ be done with a text editor. But some
of them can be done /better/ once you are liberated from "everything
is a stream of characters", or even a hypertext-aware stream of
characters.
>>> Anyway, CLIM supplies an arcane, painful to learn framework whereas
>>> that of emacs is straightforward and easy to get started with. I
>>> hardly think that one can substitute for the other.
>>
>> For the user of emacs (CLIM) or for the developer of software to run
>> on emacs (CLIM)?
>
> The developer. Writing elisp is pretty easy--I've even written a little
> major mode to deal with my blog postings--writing CLIM code is...rather
> less so. Much of this is because emacs already handles all of the
> annoying, niggling little stuff for one, and one can just dive in and
> start working on one's problem.
I still think that you're thinking at the wrong level. You could
consider CLIM as somewhat analogous to the X11 protocol -- mechanism,
not policy, though it does provide more mechanisms to do more things.
A small CLIM application will inherit some kind of default policy --
e.g. an interactor pane, mouse click sensitivity -- but no coherent
whole, that is true, just as small X11 applications have no coherent
policy.
To begin to codify one useful policy, between CLIM and Climacs there
is something called -- coincidence of coincidences -- "Emacs-Style
Application". This does not (yet) provide an integrated environment
with everything coherent, but it does provide certain things which are
likely to be common across emacs-style applications: buffer handling,
file writing, a top-level loop with support for numeric arguments,
keyboard macros, and C-g as an abort gesture. You might think that
this is an artificial distinction, but it turns out that there are (at
least) three applications using ESA out there: not just climacs, but
also a file manager and a score editor (try doing /that/ with just
text; it's still possible -- see lilypond -- but it's unbearably
painful).
>> Not that it matters much to me, though some (see upthread passim :-)
>> might dispute that emacs is straightforward and easy to start with; I
>> dispute your characterisation of CLIM, though I am happy to concede
>> that the availability of CLIM didactic material is far more limited
>> than for emacs, and suspect that this might have bearing on your
>> perception.
>
> I'll admit that's part of it--but seriously, I've not found too many
> good introductions to learning how to write good emacs lisp. But to
> learn how to write a few elisp extensions to do a common task is
> relatively easy, while figuring out how to do much with CLIM is...not.
> I tried to like CLIM, I really did.
One of emacs' great features is its self-documenting and incremental
nature. I'll try that again. Two of emacs' great features are its
self-documenting nature and incremental customizeability; for the
programmer, this adds up to the kind of discoverability that turns
users into developers. Making an analogous system is likely to be
important for all emacs-style applications, to harness the power of
the users to help themselves become more efficient.
> And if Climacs would try to be as extensible as emacs, then maybe I
> could slowly dip my toes in, as I can with emacs!
So maybe instead you want to look at ESA and its clients, to see if
that helps. While it's unlikely that Climacs itself will ever
prohibit the kind of extensibility you are talking about ("I know,
I'll write a spreadsheet for emacs") I doubt that it will encourage it
either -- though if you haven't seen it already you might want to look
at the slidemacs mode for what is possible under the current
framework. However, if you can identify bits of climacs that might
better be generalized and considered emacs-style, then that would
certainly be of value.
Cheers,
Christophe
Robert Uhl <·········@NOSPAMgmail.com> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>>
>> "Tom Lord" <····@emf.net> writes:
>>
>>> 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?
>
> IIRC, doesn't the Climacs project wish to avoid the path of emacs and
> instead focus simply on being a text editor? This wouldn't really jive
> with Mr. Lord's desire for a general-purpose application framework...
I thought a big part of the aim of the project was to create an editor
which was able to take things like text highlighting to the 'next
level'. That is, instead of being restricted to working purely on a
regexp syntax level, start to be able to work on a semantic and
interpreted level to provide a more advanced environment able to give
the programmer more sophisticated support. Much of this can only be
achieved with an editor that has a lisp interpreter 'built-in".
Tim
--
tcross (at) rapttech dot com dot au
From: Galen Boyer
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <ur73m9p5r.fsf@rcn.com>
On 12 Apr 2006, ····@emf.net wrote:
>
> 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.
Sure, one can immediately be productive with Windows apps. But, a year
later, that same person is only slightly better with their tool than
they were when they started. In a years time, a new Emacs user is far
more efficient with Emacs than they were when they started with Emacs,
and they have just scratched the surface of what this wonderful journey
brings to them. It will never be easy to learn, because there is just
way too much one can learn.
--
Galen Boyer
From: Hadron Quark
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <j921i3-9ka.ln1@l.h.c>
"Galen"posted on 2006-04-25:
> On 12 Apr 2006, ····@emf.net wrote:
>>
>> 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.
>
> Sure, one can immediately be productive with Windows apps. But, a year
> later, that same person is only slightly better with their tool than
> they were when they started. In a years time, a new Emacs user is
>far
Because they learnt everything they *needed* to do quickly :)
> more efficient with Emacs than they were when they started with Emacs,
> and they have just scratched the surface of what this wonderful journey
> brings to them. It will never be easy to learn, because there is just
> way too much one can learn.
>
Which is why a lot of people dont use it : they have no wish to use
emacs as an OS and application library! Yes emacs rocks when its
configured right : yes its brilliant when you can configure it and do
some lisp. Not its not brilliant that it took me a day to get cedet
and ecb working properly for multiple logins or that it took me 3 days
to get a dictionary/thesaurus working properly in conjunction with a
translation tool.
emacs is great : but lets never think its easy :) Like everything its
easy when you know how : and that "when you know how" is, in my
experience, the stumbling block to many people embracing emacs with
the love and attention that it deserves.
Now I have emacs configured and working well it terrifies me that I might
not have backed everything up properly and might need to go through the
whole setup process again in the event of a system failure...
Hadron Quark <···········@gmail.com> writes:
> "Galen"posted on 2006-04-25:
>
> > On 12 Apr 2006, ····@emf.net wrote:
>
> emacs is great : but lets never think its easy :) Like everything its
> easy when you know how : and that "when you know how" is, in my
> experience, the stumbling block to many people embracing emacs with
> the love and attention that it deserves.
So emacs's disadvantage is that complex tools are hard to learn? Where
did you find that they are ever simple?
> Now I have emacs configured and working well it terrifies me that I might
> not have backed everything up properly and might need to go through the
> whole setup process again in the event of a system failure...
Just copy your .emacs file to a usb thumb drive and you're done, even on
a Windows machine. Try and save your Windows app configuration in some
useful & simple way other than dumping the entire registry to a text
file, along will whichever .ini files the app might use. So emacs is
bad in some way on this issue?
Gregm
From: Hadron Quark
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <7rc1i3-lh9.ln1@l.h.c>
"Greg"posted on 2006-04-25:
>
> Hadron Quark <···········@gmail.com> writes:
>
>> "Galen"posted on 2006-04-25:
>>
>> > On 12 Apr 2006, ····@emf.net wrote:
>>
>> emacs is great : but lets never think its easy :) Like everything its
>> easy when you know how : and that "when you know how" is, in my
>> experience, the stumbling block to many people embracing emacs with
>> the love and attention that it deserves.
>
> So emacs's disadvantage is that complex tools are hard to learn? Where
> did you find that they are ever simple?
No. easy tools can be hard to learn in emacs. Also, often, hard to
configure. Caveat : I'm a supporter and user of emacs. It doesnt mean
one has to be blind to its obvious learning hurdle. Complex tools can
and often are made easy to use in other apps : not all emacs tools are
difficult - but they are often tricky : emacs requires a paradigm
shift. When you are there then emacs is heaven.
>
>
>> Now I have emacs configured and working well it terrifies me that I might
>> not have backed everything up properly and might need to go through the
>> whole setup process again in the event of a system failure...
>
> Just copy your .emacs file to a usb thumb drive and you're done, even on
> a Windows machine. Try and save your Windows app configuration in
>some
Do you have any idea how wrong you are on this? Different emacs apps
install in different emacs places. They require changes to different
emacs config files. often newer versions require adding extra lines to
start.site.el, or addition of 50xxxx.el files in site-start.d. Often
they are not compatible with Xemacs but are with 22.04 etc etc
etc. Its is a myth that just copying your .emacs saves your
configuration and install base.
> useful & simple way other than dumping the entire registry to a text
> file, along will whichever .ini files the app might use. So emacs is
> bad in some way on this issue?
Not bad : complicated. And complicated isnt necessary a bad thing when
its complicated for a reason. And generally, in all fairness, that is
the case. Nothing is for free.
>
> Gregm
>
--
%
Hadron Quark <···········@gmail.com> writes:
> "Greg"posted on 2006-04-25:
> >
> > Hadron Quark <···········@gmail.com> writes:
> >
> >> "Galen"posted on 2006-04-25:
>
> >> Now I have emacs configured and working well it terrifies me that I might
> >> not have backed everything up properly and might need to go through the
> >> whole setup process again in the event of a system failure...
> >
> > Just copy your .emacs file to a usb thumb drive and you're done, even on
> > a Windows machine. Try and save your Windows app configuration in
> >some
>
> Do you have any idea how wrong you are on this? Different emacs apps
> install in different emacs places. They require changes to different
> emacs config files. often newer versions require adding extra lines to
> start.site.el, or addition of 50xxxx.el files in site-start.d. Often
> they are not compatible with Xemacs but are with 22.04 etc etc
> etc. Its is a myth that just copying your .emacs saves your
> configuration and install base.
Works for me and I've been hacking my .emacs for getting on 10 years
now. The only stuff thats outside .emacs is my vm and gnus folders.
Whenever I bring up a new *nix machine, .emacs is the only thing I copy
over. Whenever I change my main machine, my whole home directory goes
so again there is no problem.
As far as customizing the emacs installation itself, I agree with you.
I have a couple customized .el's banging around myself, CM'ed outside
the emacs tree. I find Emacs a contrived interface for some things, so
I just use better suited (and faster) apps for those things, and skip
the installation hacking to gain portability. I also stick with FSF
emacs, xemacs having pissed me off once too often.
I think your backing up issue is probably a symptom of insufficient
configuration management.
Gregm
From: Hadron Quark
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <osh1i3-a4b.ln1@l.h.c>
"Greg"posted on 2006-04-25:
> As far as customizing the emacs installation itself, I agree with you.
> I have a couple customized .el's banging around myself, CM'ed outside
> the emacs tree. I find Emacs a contrived interface for some things,
> so
Mine is in the emacs tree. But the emacs tree is not for the faint
hearted IMO.
> I just use better suited (and faster) apps for those things, and skip
> the installation hacking to gain portability. I also stick with FSF
> emacs, xemacs having pissed me off once too often.
To this day I dont know if this is xemacs or not : it seems to run in
a shell.
GNU Emacs 21.4.1 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2005-05-03 on rothera, modified by Debian
Synaptic says emacs21 is installed and xemacs21 isnt : so I guess
not. Yet M-x emacs version gives the string above which indicates X is
in use - so I suppose its normal emacs with just enough for it to "run
under X" as opposed to it being XEmacs? is this right?
>
> I think your backing up issue is probably a symptom of insufficient
> configuration management.
>
> Gregm
--
%
Hadron Quark <···········@gmail.com> writes:
> "Greg"posted on 2006-04-25:
>
>> As far as customizing the emacs installation itself, I agree with you.
>> I have a couple customized .el's banging around myself, CM'ed outside
>> the emacs tree. I find Emacs a contrived interface for some things,
>> so
>
> Mine is in the emacs tree. But the emacs tree is not for the faint
> hearted IMO.
>
>> I just use better suited (and faster) apps for those things, and skip
>> the installation hacking to gain portability. I also stick with FSF
>> emacs, xemacs having pissed me off once too often.
>
> To this day I dont know if this is xemacs or not : it seems to run in
> a shell.
>
> GNU Emacs 21.4.1 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2005-05-03 on rothera, modified by Debian
>
> Synaptic says emacs21 is installed and xemacs21 isnt : so I guess
> not. Yet M-x emacs version gives the string above which indicates X is
> in use - so I suppose its normal emacs with just enough for it to "run
> under X" as opposed to it being XEmacs? is this right?
>
>>
>> I think your backing up issue is probably a symptom of insufficient
>> configuration management.
>>
>> Gregm
>
>
> --
> %
Just some clarification - emacs and xemacs are completely different
and as each year goes by, seem to resemble each other less and less.
From what you have posted, you are running emacs 21.4, not xemacs.
This issues you have raised regarding emacs and emacs 'apps' being
scattered all over the place is definitely an issue with your
configuration management. Emacs has very very few requirements on
where things are installed - all that stuff with /etc/emacs,
/etc/emacs21 site-start etc is something done by your Linux
distribution and absolutely *nothing* to do with emacs. In fact, you
can (and I use to) run all my emacs stuff out of my ome directory.
In fact, it wasn't so long ago that installing emacs under Linux did
pretty much nothing with respect to configuration - it just installed
the basic emacs software. Most distributions didn't have all the add
on bits, you had to chase those down and install them yourself.
Note that Greg is correct in that any problems you are having with
backing up your emacs configuration is about how you are managing it
and not due to complexities in emacs itself. A few rules of thumb
which will possibly help -
1. Don't change/edit anything in /etc/emacs, /etc/emacs21,
site-start.el etc. Only make changes to your own .emacs file.
2. If you install an emacs add-on by hand (ie not a Deb package), then
decide on a scheme and stick to it. The only thing emacs needs to
know about add ons is where to find them (i.e. add the directory to
your .emacs file load-path setting).
3. There are some minor exceptions - vm uses .vm and possibly
.vm-windows. w3m uses .w3m etc. However, all your configuration
should be done in your home directory - think about Linux as a
multi-user environment - thats how it is designed. In such
environments, you don't want personal configuration options being
set on a global level that can affect all users. Such
configurations should be put in your home directory.
4. Never run as root unless you have no choice (i.e. installing new
packages, shutting down (though there are workarounds for that as
well), doing low level system configuration etc). When you do have
to use root, use things like sudo - this will ensure you don't
shoot yourself in the foot - plenty of sys admins (including myself
once) learn this the hard way. I once did a rm -rf * from the root
partition when cleaning up a system, after a very long day and
forgetting I was logged in as root! However, I know a lot of very
experienced and smarter people who have done as bad and worse, so
feel I'm in pretty good company!
Tim
--
tcross (at) rapttech dot com dot au
Tim X <····@nospam.dev.null> writes:
> Hadron Quark <···········@gmail.com> writes:
>
>> "Greg"posted on 2006-04-25:
>>
>>> As far as customizing the emacs installation itself, I agree with you.
>>> I have a couple customized .el's banging around myself, CM'ed outside
>>> the emacs tree. I find Emacs a contrived interface for some things,
>>> so
>>
>> Mine is in the emacs tree. But the emacs tree is not for the faint
>> hearted IMO.
>>
>>> I just use better suited (and faster) apps for those things, and skip
>>> the installation hacking to gain portability. I also stick with FSF
>>> emacs, xemacs having pissed me off once too often.
>>
>> To this day I dont know if this is xemacs or not : it seems to run in
>> a shell.
>>
>> GNU Emacs 21.4.1 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2005-05-03 on rothera, modified by Debian
>>
>> Synaptic says emacs21 is installed and xemacs21 isnt : so I guess
>> not. Yet M-x emacs version gives the string above which indicates X is
>> in use - so I suppose its normal emacs with just enough for it to "run
>> under X" as opposed to it being XEmacs? is this right?
>>
>>>
>>> I think your backing up issue is probably a symptom of insufficient
>>> configuration management.
>>>
>>> Gregm
>>
>>
>> --
>> %
>
> Just some clarification - emacs and xemacs are completely different
> and as each year goes by, seem to resemble each other less and less.
> From what you have posted, you are running emacs 21.4, not xemacs.
>
> This issues you have raised regarding emacs and emacs 'apps' being
> scattered all over the place is definitely an issue with your
> configuration management. Emacs has very very few requirements on
> where things are installed - all that stuff with /etc/emacs,
> /etc/emacs21 site-start etc is something done by your Linux
> distribution and absolutely *nothing* to do with emacs. In fact, you
> can (and I use to) run all my emacs stuff out of my ome directory.
Fine : in a one person installation.
>
> In fact, it wasn't so long ago that installing emacs under Linux did
> pretty much nothing with respect to configuration - it just installed
> the basic emacs software. Most distributions didn't have all the add
> on bits, you had to chase those down and install them yourself.
I dont understand your point. It has nothing to do with the issue at
hand : installing lisp files in a linux multi user environment.
>
> Note that Greg is correct in that any problems you are having with
> backing up your emacs configuration is about how you are managing it
> and not due to complexities in emacs itself. A few rules of thumb
> which will possibly help -
>
> 1. Don't change/edit anything in /etc/emacs, /etc/emacs21,
> site-start.el etc. Only make changes to your own .emacs file.
You dont have a multi user installation : it is easy if you are a one
man show.
>
> 2. If you install an emacs add-on by hand (ie not a Deb package), then
> decide on a scheme and stick to it. The only thing emacs needs to
> know about add ons is where to find them (i.e. add the directory to
> your .emacs file load-path setting).
See above. Also note that the things we install (through debian
packages) also take different paths to installing : this was my point in
how it can be confusing to know the *best* way to do it.
>
> 3. There are some minor exceptions - vm uses .vm and possibly
hmm. Minor exceptions? Most emacs extensions that you want "latest
versions for are not in debian packages. They are are .el files.
> .vm-windows. w3m uses .w3m etc. However, all your configuration
> should be done in your home directory - think about Linux as a
> multi-user environment - thats how it is designed. In such
Linus is a multiuser environment : hence the difficulty in knowing hos
*best* to install extensions you want open to all logins. There are a
myriad of ways of doing it. and a *lot* of emacs addons are hacks from
lisp experts who dont really offer suported ways of how to install it
for the best.
> environments, you don't want personal configuration options being
> set on a global level that can affect all users. Such
> configurations should be put in your home directory.
>
> 4. Never run as root unless you have no choice (i.e. installing new
> packages, shutting down (though there are workarounds for that as
eh? Where did this come from? You must sudo to root to install things
for multi-user access. Hence my comment on the complexity of the emacs
linux tree. And it is complicated : for someone who wants to use a "more
powerful editor". I use emacs as a C and an ADA development environment.
> well), doing low level system configuration etc). When you do have
> to use root, use things like sudo - this will ensure you don't
I know.
> shoot yourself in the foot - plenty of sys admins (including myself
> once) learn this the hard way. I once did a rm -rf * from the root
> partition when cleaning up a system, after a very long day and
> forgetting I was logged in as root! However, I know a lot of very
> experienced and smarter people who have done as bad and worse, so
> feel I'm in pretty good company!
Personally I always use sudo.
>
> Tim
>
> --
> tcross (at) rapttech dot com dot au
--
lithp : syntax error
Hadron Quark <···········@gmail.com> writes:
> Tim X <····@nospam.dev.null> writes:
>
> > Hadron Quark <···········@gmail.com> writes:
> >
> >> "Greg"posted on 2006-04-25:
> >
> > Note that Greg is correct in that any problems you are having with
> > backing up your emacs configuration is about how you are managing it
> > and not due to complexities in emacs itself. A few rules of thumb
> > which will possibly help -
> >
> > 1. Don't change/edit anything in /etc/emacs, /etc/emacs21,
> > site-start.el etc. Only make changes to your own .emacs file.
>
> You dont have a multi user installation : it is easy if you are a one
> man show.
>
Nope, config management done reasonably well handles multiuser just
fine. Not that its rocket science either but you have to choose your
tools and use them. This may require forming your own emacs distro so
you can cm the whole thing and handle merges from the official source
trees. This is the non-fun PITA aspect of managing systems that is so
often ignored.
Again, if backup is the problem, then your cm and backup procedures need
enhancement. OTOH there are perhaps other aspects of the deploying
additional packages into emacs that are not cm issues.
Gregm
Greg Menke <·············@toadmail.com> writes:
> Hadron Quark <···········@gmail.com> writes:
>
>> Tim X <····@nospam.dev.null> writes:
>>
>> > Hadron Quark <···········@gmail.com> writes:
>> >
>> >> "Greg"posted on 2006-04-25:
>> >
>> > Note that Greg is correct in that any problems you are having with
>> > backing up your emacs configuration is about how you are managing it
>> > and not due to complexities in emacs itself. A few rules of thumb
>> > which will possibly help -
>> >
>> > 1. Don't change/edit anything in /etc/emacs, /etc/emacs21,
>> > site-start.el etc. Only make changes to your own .emacs file.
>>
>> You dont have a multi user installation : it is easy if you are a one
>> man show.
>>
>
> Nope, config management done reasonably well handles multiuser just
> fine. Not that its rocket science either but you have to choose your
What do you mane "nope"? Are you serisouly telling me its as easy for
multi-user as it is just to hack one huge .emacs without resorting to
root?
I must disagree.
> tools and use them. This may require forming your own emacs distro so
and forming ones own emacs distro isn't tricky?
> you can cm the whole thing and handle merges from the official source
> trees. This is the non-fun PITA aspect of managing systems that is so
> often ignored.
Lets get this right : I am a user of an editor/programming environment
(eg emacs) - and you are suggesting that I should "cm" the whole thing
and take care of merging source trees? All well and good if willing to
learn all this : and this is the crux of the matter. It is *not*
trivially easy no matter what some people say - if you think that
managing and merging elisp source trees is easy then fair play.
>
> Again, if backup is the problem, then your cm and backup procedures need
> enhancement. OTOH there are perhaps other aspects of the deploying
> additional packages into emacs that are not cm issues.
I'm not sure what you mean. Clearly if there are "issues" then one needs
"enhancements" - thats hardly rocket science. Just what do you mean by
"cm" here : do you mean a supported, distributed config management
application or the more woolly "configuration management" which
translates as "remembering where things are"?
>
> Gregm
--
lithp : syntax error
Hadron Quark <···········@gmail.com> writes:
> Greg Menke <·············@toadmail.com> writes:
>
> > Hadron Quark <···········@gmail.com> writes:
> >
> >> Tim X <····@nospam.dev.null> writes:
> >>
> >> > Hadron Quark <···········@gmail.com> writes:
> >> >
> >> >> "Greg"posted on 2006-04-25:
> >> >
> >> > Note that Greg is correct in that any problems you are having with
> >> > backing up your emacs configuration is about how you are managing it
> >> > and not due to complexities in emacs itself. A few rules of thumb
> >> > which will possibly help -
> >> >
> >> > 1. Don't change/edit anything in /etc/emacs, /etc/emacs21,
> >> > site-start.el etc. Only make changes to your own .emacs file.
> >>
> >> You dont have a multi user installation : it is easy if you are a one
> >> man show.
> >>
> >
> > Nope, config management done reasonably well handles multiuser just
> > fine. Not that its rocket science either but you have to choose your
>
> What do you mane "nope"? Are you serisouly telling me its as easy for
> multi-user as it is just to hack one huge .emacs without resorting to
> root?
>
> I must disagree.
I am not telling you about working with big .emacs files, I'm talking
about config management as applied to backing up a customized emacs
distribution. I think it is likely that a lot of your distro
customization could be mitigated by a more complex .emacs however.
> > tools and use them. This may require forming your own emacs distro so
>
> and forming ones own emacs distro isn't tricky?
I never said it wasn't.
> > you can cm the whole thing and handle merges from the official source
> > trees. This is the non-fun PITA aspect of managing systems that is so
> > often ignored.
>
> Lets get this right : I am a user of an editor/programming environment
> (eg emacs) - and you are suggesting that I should "cm" the whole thing
> and take care of merging source trees? All well and good if willing to
> learn all this : and this is the crux of the matter. It is *not*
> trivially easy no matter what some people say - if you think that
> managing and merging elisp source trees is easy then fair play.
I never said it was easy. I did say that config management is a pain in
the butt and that it is necessary and often neglected.
> >
> > Again, if backup is the problem, then your cm and backup procedures need
> > enhancement. OTOH there are perhaps other aspects of the deploying
> > additional packages into emacs that are not cm issues.
>
> I'm not sure what you mean. Clearly if there are "issues" then one needs
> "enhancements" - thats hardly rocket science. Just what do you mean by
> "cm" here : do you mean a supported, distributed config management
> application or the more woolly "configuration management" which
> translates as "remembering where things are"?
The former.
Gregm
Hadron Quark <···········@gmail.com> writes:
> Tim X <····@nospam.dev.null> writes:
>
>> Hadron Quark <···········@gmail.com> writes:
>>
>>> "Greg"posted on 2006-04-25:
>>>
>>>> As far as customizing the emacs installation itself, I agree with you.
>>>> I have a couple customized .el's banging around myself, CM'ed outside
>>>> the emacs tree. I find Emacs a contrived interface for some things,
>>>> so
>>>
>>> Mine is in the emacs tree. But the emacs tree is not for the faint
>>> hearted IMO.
>>>
>>>> I just use better suited (and faster) apps for those things, and skip
>>>> the installation hacking to gain portability. I also stick with FSF
>>>> emacs, xemacs having pissed me off once too often.
>>>
>>> To this day I dont know if this is xemacs or not : it seems to run in
>>> a shell.
>>>
>>> GNU Emacs 21.4.1 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2005-05-03 on rothera, modified by Debian
>>>
>>> Synaptic says emacs21 is installed and xemacs21 isnt : so I guess
>>> not. Yet M-x emacs version gives the string above which indicates X is
>>> in use - so I suppose its normal emacs with just enough for it to "run
>>> under X" as opposed to it being XEmacs? is this right?
>>>
>>>>
>>>> I think your backing up issue is probably a symptom of insufficient
>>>> configuration management.
>>>>
>>>> Gregm
>>>
>>>
>>> --
>>> %
>>
>> Just some clarification - emacs and xemacs are completely different
>> and as each year goes by, seem to resemble each other less and less.
>> From what you have posted, you are running emacs 21.4, not xemacs.
>>
>> This issues you have raised regarding emacs and emacs 'apps' being
>> scattered all over the place is definitely an issue with your
>> configuration management. Emacs has very very few requirements on
>> where things are installed - all that stuff with /etc/emacs,
>> /etc/emacs21 site-start etc is something done by your Linux
>> distribution and absolutely *nothing* to do with emacs. In fact, you
>> can (and I use to) run all my emacs stuff out of my ome directory.
>
> Fine : in a one person installation.
>
>>
>> In fact, it wasn't so long ago that installing emacs under Linux did
>> pretty much nothing with respect to configuration - it just installed
>> the basic emacs software. Most distributions didn't have all the add
>> on bits, you had to chase those down and install them yourself.
>
> I dont understand your point. It has nothing to do with the issue at
> hand : installing lisp files in a linux multi user environment.
>
firstly, I don't remember seeing anything about a multi-user
environment in the original post. The complaint was centered around
the concern that it was near impossible to ensure all the emacs
configuration information was adequately backed up and a strong
impression was given (if not explicitly stated) that it was an
individuals emacs configuration that was being referred to. I seem to
even remember a mention to an explicit reference to Something like
"I'm concerned my emacs configuration which I've been
tuning/developing for months/years (I cannot remember the exact
wording) may not be fully backed up.
If we are talking about system configuration issues, then thats
another league and a completely different issue. Linux has
configuration stuff in many places - most of it under /etc, but not
all of it. If your talking system configuration, then the argument
that emacs is worse than anything else has no basis either and if your
a sys admin and you do not have a clear idea of exactly what is being
backed up and when, then you would be a pretty bloody poor sys admin.
>>
>> Note that Greg is correct in that any problems you are having with
>> backing up your emacs configuration is about how you are managing it
>> and not due to complexities in emacs itself. A few rules of thumb
>> which will possibly help -
>>
>> 1. Don't change/edit anything in /etc/emacs, /etc/emacs21,
>> site-start.el etc. Only make changes to your own .emacs file.
>
> You dont have a multi user installation : it is easy if you are a one
> man show.
>
I've been administering multi-user emacs installations for over 15
years. Currently, I'm administering a Debian system. In the last 5
years, I cannot think of a single instance where I have had to modify
the default system wide Debian emacs configuration scripts (those
which are in /etc/emacs, /etc/emacs21, /etc/emacs-snapshot etc.
If I did need to make a global change which wold affect all users,
then I would modify one of the global setup files, but all of that is
automatically backed up each night and backups are on a three month
rotation with a full backup once per week and an incremental backup on
the other nights. I can therefore retrieve any version of any global
configuration/setup file going back three months.
>>
>> 2. If you install an emacs add-on by hand (ie not a Deb package), then
>> decide on a scheme and stick to it. The only thing emacs needs to
>> know about add ons is where to find them (i.e. add the directory to
>> your .emacs file load-path setting).
>
> See above. Also note that the things we install (through debian
> packages) also take different paths to installing : this was my point in
> how it can be confusing to know the *best* way to do it.
Give some examples. I don't understand what you mean about different
paths. Debian's installation and policies make all of this extremely
clear. All I can assume about the paths is in reference to the
mechanism Debian uses to allow you to run multiple versions of emacs
on the same system at the same time - its very simple and straight
forward and works well if you take the time to understand how Debian
does it. It is a bit more complicaed, but being able to run multiple
versions of emacs and xemacs on the same box can be complex and Debian
solves the problem in a nice and quite elegant way.
Again, the main point is this is not due to anything specific to emacs
and in fact proves how flexible emacs is with respect to how it is
configured.
>>
>> 3. There are some minor exceptions - vm uses .vm and possibly
>
> hmm. Minor exceptions? Most emacs extensions that you want "latest
> versions for are not in debian packages. They are are .el files.
Well, firstly that depends on what version of Debian your running. I
do have a couple of emacs packages which are not in deb format and
which I've installed from tar balls, but thats not an issue.
Installing emacs packages from tar files with just .el files in them
is pretty straight forward, but again, this has nothing to do with the
original argument that emacs configurations were difficult to backup
and the response that if you have problems backing up emacs
configuration, the problem is with your configuration management and
not with emacs. Nothing you have responded with has changed this.
>>> .vm-windows. w3m uses .w3m etc. However, all your configuration
>> should be done in your home directory - think about Linux as a
>> multi-user environment - thats how it is designed. In such
>
> Linus is a multiuser environment : hence the difficulty in knowing hos
> *best* to install extensions you want open to all logins. There are a
> myriad of ways of doing it. and a *lot* of emacs addons are hacks from
> lisp experts who dont really offer suported ways of how to install it
> for the best.
>
Examples? My experience with emacs add-ons has been that if the add-on
is worth using, it has had a reasonable default for its configuration.
In 15 years, I can only think of a couple of minor instances in which
a package was difficult to configure and in each case, this was
because it was a very old package which had not been actively
maintained, so some work was required to get it working with newer versions.
>> environments, you don't want personal configuration options being
>> set on a global level that can affect all users. Such
>> configurations should be put in your home directory.
>>
>> 4. Never run as root unless you have no choice (i.e. installing new
>> packages, shutting down (though there are workarounds for that as
>
> eh? Where did this come from? You must sudo to root to install things
> for multi-user access. Hence my comment on the complexity of the emacs
> linux tree.
Which part of "...unless you have no choice (i.e. installing new
packages,..." did you have trouble understanding?
>And it is complicated : for someone who wants to use a "more
> powerful editor". I use emacs as a C and an ADA development environment.
>
This came from the fact it seemed from your original comments that you
have very limited system administration experience and running as root
when not necessary is a common mistake of those who don't have much
experience - it was meant as a cautionary note.
My original point is that this is still nothing to do with emacs. The
complexities you are referring to are solely due to how Debian has
decided to layout the emacs installation - nothing within emacs
requires this structure. Given what you get as a result, Debian has
done an excellent job - the fact you are not familiar with the
advantages of there approach doesn't automatically mean it is too
complex.
>> well), doing low level system configuration etc). When you do have
>> to use root, use things like sudo - this will ensure you don't
>
> I know.
>
>> shoot yourself in the foot - plenty of sys admins (including myself
>> once) learn this the hard way. I once did a rm -rf * from the root
>> partition when cleaning up a system, after a very long day and
>> forgetting I was logged in as root! However, I know a lot of very
>> experienced and smarter people who have done as bad and worse, so
>> feel I'm in pretty good company!
>
> Personally I always use sudo.
>
Good. However, sometimes, su - is also needed, the trick is knowing
when.
--
tcross (at) rapttech dot com dot au
Tim X <····@nospam.dev.null> writes:
> Hadron Quark <···········@gmail.com> writes:
>
>> Tim X <····@nospam.dev.null> writes:
>>
>>> Hadron Quark <···········@gmail.com> writes:
>>>
>>>> "Greg"posted on 2006-04-25:
>>>>
>>>>> As far as customizing the emacs installation itself, I agree with you.
>>>>> I have a couple customized .el's banging around myself, CM'ed outside
>>>>> the emacs tree. I find Emacs a contrived interface for some things,
>>>>> so
>>>>
>>>> Mine is in the emacs tree. But the emacs tree is not for the faint
>>>> hearted IMO.
>>>>
>>>>> I just use better suited (and faster) apps for those things, and skip
>>>>> the installation hacking to gain portability. I also stick with FSF
>>>>> emacs, xemacs having pissed me off once too often.
>>>>
>>>> To this day I dont know if this is xemacs or not : it seems to run in
>>>> a shell.
>>>>
>>>> GNU Emacs 21.4.1 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2005-05-03 on rothera, modified by Debian
>>>>
>>>> Synaptic says emacs21 is installed and xemacs21 isnt : so I guess
>>>> not. Yet M-x emacs version gives the string above which indicates X is
>>>> in use - so I suppose its normal emacs with just enough for it to "run
>>>> under X" as opposed to it being XEmacs? is this right?
>>>>
>>>>>
>>>>> I think your backing up issue is probably a symptom of insufficient
>>>>> configuration management.
>>>>>
>>>>> Gregm
>>>>
>>>>
>>>> --
>>>> %
>>>
>>> Just some clarification - emacs and xemacs are completely different
>>> and as each year goes by, seem to resemble each other less and less.
>>> From what you have posted, you are running emacs 21.4, not xemacs.
>>>
>>> This issues you have raised regarding emacs and emacs 'apps' being
>>> scattered all over the place is definitely an issue with your
>>> configuration management. Emacs has very very few requirements on
>>> where things are installed - all that stuff with /etc/emacs,
>>> /etc/emacs21 site-start etc is something done by your Linux
>>> distribution and absolutely *nothing* to do with emacs. In fact, you
>>> can (and I use to) run all my emacs stuff out of my ome directory.
>>
>> Fine : in a one person installation.
>>
>>>
>>> In fact, it wasn't so long ago that installing emacs under Linux did
>>> pretty much nothing with respect to configuration - it just installed
>>> the basic emacs software. Most distributions didn't have all the add
>>> on bits, you had to chase those down and install them yourself.
>>
>> I dont understand your point. It has nothing to do with the issue at
>> hand : installing lisp files in a linux multi user environment.
>>
>
> firstly, I don't remember seeing anything about a multi-user
> environment in the original post. The complaint was centered around
> the concern that it was near impossible to ensure all the emacs
> configuration information was adequately backed up and a strong
> impression was given (if not explicitly stated) that it was an
> individuals emacs configuration that was being referred to. I seem to
Sorry if you got that impression.
> even remember a mention to an explicit reference to Something like
> "I'm concerned my emacs configuration which I've been
> tuning/developing for months/years (I cannot remember the exact
> wording) may not be fully backed up.
Well, that doesnt alter anything really since I did mention the system directories.
>
> If we are talking about system configuration issues, then thats
> another league and a completely different issue. Linux has
I'm not : im talking about emacs configuration. But admittedly under
debian. There are a lot of potential places to add/tweak - this is all
I am saying. It can be confusing to know where best and how best to
configure things. e.g add 55xyz.el into site-start.d?
Where this automatzically appends loadpaths and require's?
or in site-start.el? or in all individual .emacs files? It is tricky IMO.
> configuration stuff in many places - most of it under /etc, but not
> all of it. If your talking system configuration, then the argument
> that emacs is worse than anything else has no basis either and if your
> a sys admin and you do not have a clear idea of exactly what is being
> backed up and when, then you would be a pretty bloody poor sys admin.
Possibly I over laboured the backup point. Clearly any idiot can ensure
a full system backup - I probably more meant to make the point that the
plethora of potential customisation points in the emacs world can and
does make it tricky to know where best to customise and how best to
keep track of those customisations.
>
>>>
>>> Note that Greg is correct in that any problems you are having with
>>> backing up your emacs configuration is about how you are managing it
>>> and not due to complexities in emacs itself. A few rules of thumb
>>> which will possibly help -
>>>
>>> 1. Don't change/edit anything in /etc/emacs, /etc/emacs21,
>>> site-start.el etc. Only make changes to your own .emacs file.
>>
>> You dont have a multi user installation : it is easy if you are a one
>> man show.
>>
>
> I've been administering multi-user emacs installations for over 15
> years. Currently, I'm administering a Debian system. In the last 5
> years, I cannot think of a single instance where I have had to modify
> the default system wide Debian emacs configuration scripts (those
> which are in /etc/emacs, /etc/emacs21, /etc/emacs-snapshot etc.
Then how did you customise emacs for all users? Please tell me : maybe I
hav missed something. I dont see how you can customise a system of any
kind for multi-user without rooting around in the system directories
such as /usr and /etc.
>
> If I did need to make a global change which wold affect all users,
> then I would modify one of the global setup files, but all of that is
> automatically backed up each night and backups are on a three month
I dont wish to discuss the backup : the system wide changes are not
different to the HOME changes. Its more developing a concistent
methodology for emacs changes - maybe I will learn amore about this as
the days go on. As it is, there are loads of potential customization
points - and I'm never quite sure which one to use.
> rotation with a full backup once per week and an incremental backup on
> the other nights. I can therefore retrieve any version of any global
> configuration/setup file going back three months.
>
>>>
>>> 2. If you install an emacs add-on by hand (ie not a Deb package), then
>>> decide on a scheme and stick to it. The only thing emacs needs to
>>> know about add ons is where to find them (i.e. add the directory to
>>> your .emacs file load-path setting).
>>
>> See above. Also note that the things we install (through debian
>> packages) also take different paths to installing : this was my point in
>> how it can be confusing to know the *best* way to do it.
>
> Give some examples. I don't understand what you mean about different
> paths. Debian's installation and policies make all of this extremely
> clear. All I can assume about the paths is in reference to the
I think you're being purposely argumentative. If it was "perfectly
clear" then this and similar threads wouldnt occur. I suspect that the
fact you have been an emacs administrator for 15 years makes you
impervious to any potential faults or complications.
> mechanism Debian uses to allow you to run multiple versions of emacs
> on the same system at the same time - its very simple and straight
> forward and works well if you take the time to understand how Debian
> does it. It is a bit more complicaed, but being able to run multiple
> versions of emacs and xemacs on the same box can be complex and Debian
> solves the problem in a nice and quite elegant way
How is debian special from other linuxes? Do you have a pointer/url please?
>
> Again, the main point is this is not due to anything specific to emacs
> and in fact proves how flexible emacs is with respect to how it is
> configured.
>
>>>
>>> 3. There are some minor exceptions - vm uses .vm and possibly
>>
>> hmm. Minor exceptions? Most emacs extensions that you want "latest
>> versions for are not in debian packages. They are are .el files.
>
> Well, firstly that depends on what version of Debian your running. I
There are loads of el changes out there which are not in
debian packages. Regardless of the debian version.
> do have a couple of emacs packages which are not in deb format and
> which I've installed from tar balls, but thats not an issue.
Yes it is. Its the MAIN issue. e.g where best to put things and keep
track of them for (e.g) backup purpose.
>
> Installing emacs packages from tar files with just .el files in them
> is pretty straight forward, but again, this has nothing to do with the
> original argument that emacs configurations were difficult to backup
Yes it does. Since the last things I installed (el files) werent in
instabble packages - they were just a bunch of files.
> and the response that if you have problems backing up emacs
> configuration, the problem is with your configuration management and
> not with emacs. Nothing you have responded with has changed this.
Possibly we are at crossing paths here : you seem determined to
concentrate on the "backing up part". Whereas the "backing up" part I
meant as a potential issue because of the plethora of possibilities in
configuring an emacs system which is built of a hotch potch of debian
packages and straghtforward .el files.
>
>>>> .vm-windows. w3m uses .w3m etc. However, all your configuration
>>> should be done in your home directory - think about Linux as a
>>> multi-user environment - thats how it is designed. In such
>>
>> Linus is a multiuser environment : hence the difficulty in knowing hos
>> *best* to install extensions you want open to all logins. There are a
>> myriad of ways of doing it. and a *lot* of emacs addons are hacks from
>> lisp experts who dont really offer suported ways of how to install it
>> for the best.
>>
>
> Examples? My experience with emacs add-ons has been that if the add-on
> is worth using, it has had a reasonable default for its configuration.
> In 15 years, I can only think of a couple of minor instances in which
> a package was difficult to configure and in each case, this was
> because it was a very old package which had not been actively
> maintained, so some work was required to get it working with newer
> versions.
Most emacs stuff is stable : there is a lot being developed too. There is
a lot of stuff requiring cross app compatability which then clashes with
the debian packages. I'm not making this up you know. Go and install,
say cedet. Latest version. Not rocket science, but not trivial either.
>
>
>>> environments, you don't want personal configuration options being
>>> set on a global level that can affect all users. Such
>>> configurations should be put in your home directory.
>>>
>>> 4. Never run as root unless you have no choice (i.e. installing new
>>> packages, shutting down (though there are workarounds for that as
>>
>> eh? Where did this come from? You must sudo to root to install things
>> for multi-user access. Hence my comment on the complexity of the emacs
>> linux tree.
>
> Which part of "...unless you have no choice (i.e. installing new
> packages,..." did you have trouble understanding?
None of it: I just wondered why you felt the need to state the bleeding
obvious. This thread wasnt about sudo issues : it was about best ways of
configuring emacs on debian in a concistent and reproducible manner.
>
>>And it is complicated : for someone who wants to use a "more
>> powerful editor". I use emacs as a C and an ADA development environment.
>>
>
> This came from the fact it seemed from your original comments that you
> have very limited system administration experience and running as root
> when not necessary is a common mistake of those who don't have much
> experience - it was meant as a cautionary note.
>
> My original point is that this is still nothing to do with emacs. The
Fair enough.
> complexities you are referring to are solely due to how Debian has
> decided to layout the emacs installation - nothing within emacs
> requires this structure. Given what you get as a result, Debian has
> done an excellent job - the fact you are not familiar with the
> advantages of there approach doesn't automatically mean it is too
> complex.
I am very aware of the advantages : I also am aware of the
disadvantages. As a not too naive user of systems for many years, I
stand by the fact that the debian emacs directory hierarchies are
confusing - possibly due to the flexibility they provide. But confusing nonetheless.
>
>>> well), doing low level system configuration etc). When you do have
>>> to use root, use things like sudo - this will ensure you don't
>>
>> I know.
>>
>>> shoot yourself in the foot - plenty of sys admins (including myself
>>> once) learn this the hard way. I once did a rm -rf * from the root
>>> partition when cleaning up a system, after a very long day and
>>> forgetting I was logged in as root! However, I know a lot of very
>>> experienced and smarter people who have done as bad and worse, so
>>> feel I'm in pretty good company!
>>
>> Personally I always use sudo.
>>
>
> Good. However, sometimes, su - is also needed, the trick is knowing
> when.
What trick?
>
>
> --
> tcross (at) rapttech dot com dot au
I guess there isnt really much more to say : you think its easy and I
disagree.
Maybe I'm, what was the phrase from the other poster, "stupid"? :-)
Hadron Quark <···········@gmail.com> writes:
> Tim X <····@nospam.dev.null> writes:
>
>> Hadron Quark <···········@gmail.com> writes:
>>
>>> Tim X <····@nospam.dev.null> writes:
>>>
>>>> Hadron Quark <···········@gmail.com> writes:
>>>>
>>>>> "Greg"posted on 2006-04-25:
>>>>>
>>
>> firstly, I don't remember seeing anything about a multi-user
>> environment in the original post. The complaint was centered around
>> the concern that it was near impossible to ensure all the emacs
>> configuration information was adequately backed up and a strong
>> impression was given (if not explicitly stated) that it was an
>> individuals emacs configuration that was being referred to. I seem to
>
> Sorry if you got that impression.
>
>> even remember a mention to an explicit reference to Something like
>> "I'm concerned my emacs configuration which I've been
>> tuning/developing for months/years (I cannot remember the exact
>> wording) may not be fully backed up.
>
> Well, that doesnt alter anything really since I did mention the system directories.
>
Actually, I feel it does make a difference. The way you
customize/configure emacs depends on whether your doing it as a site
administrator or you are doing it as an individual user. Your
reference to the system directories gave me the impression you were
customizing/modifying these files for individual configuration needs
rather than system (i.e. multi-user) needs.
What I was trying to say is that for a system being used by just an
individual, don't modify the system files at all. Do all your
configuration in your .emacs file.
If it is a system wide configuration for multiple users and assuming
you are using a Debian system, avoid changing the system config files
for debian managed packages unless you have a very very good reason.
While deb will handle this fine, the Debian default configs are pretty
sane and suitable for most setups. Changing them means each time there
is an upgrade, you have to merge in your changes and any changes in
the new files.
If the add-on is not a Debian package, then install it under
/usr/local. You can use any scheme you want, but I prefer to follow
the Debian emacs policies - partially because I have multiple machines
to look after, so I create a deb package and partly so that other
admins only have to know one general approach. I find its good to put
any additional software which didn't come as part of the distro in
/usr/local, which I also make as its own partition. Then, if
necessary, I can do a complete re-install of the linux distro, even
low level formatting of partitions (except /usr/local and /home) and
can then know I have a truely clean install without having to redo all
my hand installed software.
>>
>> If we are talking about system configuration issues, then thats
>> another league and a completely different issue. Linux has
>
> I'm not : im talking about emacs configuration. But admittedly under
> debian. There are a lot of potential places to add/tweak - this is all
> I am saying. It can be confusing to know where best and how best to
> configure things. e.g add 55xyz.el into site-start.d?
> Where this automatzically appends loadpaths and require's?
> or in site-start.el? or in all individual .emacs files? It is tricky IMO.
>
But this is my point about the Debian policies - all this is explained
in them and so you can easily find out and not remain confused.
You can follow a basic rule of thumb -
1. If the package configuration does not vary between emacsen
versions, then stick it in /etc/emacs/site-start.d. Use an
appropriate number in the filename so that it is not loaded until
any prerequisites are loaded.
2. If the package requires different configuraiton depending on the
emacsen version, then put config files in each of the version
dependent directories for which you want this pacakge available
e.g. /etc/emacs21/site-start.d, /etc/xemcas21/site-start.d etc.
3. Put the source files in the site-lisp directory corresponding to
the version of emacsen you will be running and want to have the
package available. Debian would use /usr/share/emacs/site-lisp or
/usr/share/emacs21/site-lisp. For non-deb packages, I tend to use
/usr/local/share/emacs/site-lisp and
/usr/local/share/emacs21/site-lisp.
>> configuration stuff in many places - most of it under /etc, but not
>> all of it. If your talking system configuration, then the argument
>> that emacs is worse than anything else has no basis either and if your
>> a sys admin and you do not have a clear idea of exactly what is being
>> backed up and when, then you would be a pretty bloody poor sys admin.
>
> Possibly I over laboured the backup point. Clearly any idiot can ensure
> a full system backup - I probably more meant to make the point that the
> plethora of potential customisation points in the emacs world can and
> does make it tricky to know where best to customise and how best to
> keep track of those customisations.
>
I can understand how it may seem confusing, especially under Debian.
However, as I've mentioned, this is due to how Debian has done it and
nothing to do with emacs. This was the original point I was trying to
make - its not the emacs world or emacs developers that have created
what you find to be a confusing configuration environment. If you
wanted to, you could just have a single directory and put everything
in sub directories below it (you only need the sub dirs to avoid file
name conflicts between packages). If you look into the emacs
documentation, you will find there is in fact only two configuration
files which emacs bothers with. All this other stuff and multiple
config files is done by the people putting the linux distro together
and not something required by emacs.
>>
>>>>
>>>> Note that Greg is correct in that any problems you are having with
>>>> backing up your emacs configuration is about how you are managing it
>>>> and not due to complexities in emacs itself. A few rules of thumb
>>>> which will possibly help -
>>>>
>>>> 1. Don't change/edit anything in /etc/emacs, /etc/emacs21,
>>>> site-start.el etc. Only make changes to your own .emacs file.
>>>
>>> You dont have a multi user installation : it is easy if you are a one
>>> man show.
>>>
>>
>> I've been administering multi-user emacs installations for over 15
>> years. Currently, I'm administering a Debian system. In the last 5
>> years, I cannot think of a single instance where I have had to modify
>> the default system wide Debian emacs configuration scripts (those
>> which are in /etc/emacs, /etc/emacs21, /etc/emacs-snapshot etc.
>
> Then how did you customise emacs for all users? Please tell me : maybe I
> hav missed something. I dont see how you can customise a system of any
> kind for multi-user without rooting around in the system directories
> such as /usr and /etc.
>
Probably already explained above, but at the risk of reptition....
1. I've found with emacs backages in deb format, the defaults are
fine.
2. For packages not in deb format, I put them under /usr/local and
follow the same strategy as debian. This way, all my hand crafted
configuration is in one place.
>> If I did need to make a global change which wold affect all users,
>> then I would modify one of the global setup files, but all of that is
>> automatically backed up each night and backups are on a three month
>
> I dont wish to discuss the backup : the system wide changes are not
> different to the HOME changes. Its more developing a concistent
> methodology for emacs changes - maybe I will learn amore about this as
> the days go on. As it is, there are loads of potential customization
> points - and I'm never quite sure which one to use.
this was the aspect I was attempting to clarify for you. Hopefully
what is above makes it a bit clearer.
>>> rotation with a full backup once per week and an incremental backup on
>> the other nights. I can therefore retrieve any version of any global
>> configuration/setup file going back three months.
>>
>>>>
>>>> 2. If you install an emacs add-on by hand (ie not a Deb package), then
>>>> decide on a scheme and stick to it. The only thing emacs needs to
>>>> know about add ons is where to find them (i.e. add the directory to
>>>> your .emacs file load-path setting).
>>>
>>> See above. Also note that the things we install (through debian
>>> packages) also take different paths to installing : this was my point in
>>> how it can be confusing to know the *best* way to do it.
>>
>> Give some examples. I don't understand what you mean about different
>> paths. Debian's installation and policies make all of this extremely
>> clear. All I can assume about the paths is in reference to the
>
> I think you're being purposely argumentative. If it was "perfectly
> clear" then this and similar threads wouldnt occur. I suspect that the
> fact you have been an emacs administrator for 15 years makes you
> impervious to any potential faults or complications.
>
I'm not at all trying to be argumentative - I asked for examples
because I wasn't clear what you were talking about with reference to
debian emacs packages using different paths. It has a clearly defined
methodology. I was trying to understand what it is in particular you
find confusing to see if I could help. If you didn't read it that way,
thats unfortunate, but not worth worrying about.
>> mechanism Debian uses to allow you to run multiple versions of emacs
>> on the same system at the same time - its very simple and straight
>> forward and works well if you take the time to understand how Debian
>> does it. It is a bit more complicaed, but being able to run multiple
>> versions of emacs and xemacs on the same box can be complex and Debian
>> solves the problem in a nice and quite elegant way
>
> How is debian special from other linuxes? Do you have a pointer/url please?
>
Its funny, I actually get the feeling your trying to be argumentative
and not really taking in what I've attempted to express. Debian is
different because the whole way emacs is configured under a debian
distribution is specific to debian - again, this issue you brought up
about emacs configuration being difficult is nothing to do with eamcs
- its Debian which has set this up. Other Linux distributions do it
differently. If yo want to read about it, go to the Debian site and
find the policies for building emacs packages. Its all very clearly
laid out there.
>>
>> Again, the main point is this is not due to anything specific to emacs
>> and in fact proves how flexible emacs is with respect to how it is
>> configured.
>>
>>>>
>>>> 3. There are some minor exceptions - vm uses .vm and possibly
>>>
>>> hmm. Minor exceptions? Most emacs extensions that you want "latest
>>> versions for are not in debian packages. They are are .el files.
>>
>> Well, firstly that depends on what version of Debian your running. I
>
> There are loads of el changes out there which are not in
> debian packages. Regardless of the debian version.
>
True. However, for a multi-user site, most of the ones you would want
are in Debian packages. I covered the ones that are not above.
>> do have a couple of emacs packages which are not in deb format and
>> which I've installed from tar balls, but thats not an issue.
>
> Yes it is. Its the MAIN issue. e.g where best to put things and keep
> track of them for (e.g) backup purpose.
>
I thought backup wasn't an issue? Again, for non-deb installs, you can
do it however you want in whatever way suits your maintenance
methodology best. Emacs does not impose any restrictions on this - it
just has to be able to find the files through its load path.
>>
>> Installing emacs packages from tar files with just .el files in them
>> is pretty straight forward, but again, this has nothing to do with the
>> original argument that emacs configurations were difficult to backup
>
> Yes it does. Since the last things I installed (el files) werent in
> instabble packages - they were just a bunch of files.
>
So? Again, you can do it however you want.
>> and the response that if you have problems backing up emacs
>> configuration, the problem is with your configuration management and
>> not with emacs. Nothing you have responded with has changed this.
>
Well, if you really read what I have written and thought about it you
would see that its nothing to do with emacs. It is 100% to do with how
you manage your configuration because emacs lets you do it how you
want. If you don't like the way Debian does it, then make up your own
scheme.
> Possibly we are at crossing paths here : you seem determined to
> concentrate on the "backing up part". Whereas the "backing up" part I
> meant as a potential issue because of the plethora of possibilities in
> configuring an emacs system which is built of a hotch potch of debian
> packages and straghtforward .el files.
>
I thought backup was the issue because of the original statement that
you were concerned that after months of configuring your system, you
didn't know for sure if all your configuration changes were being
backed up - this is purely and simply and configuration management
issue and as emacs has next to no requirements on how you do the
configuration - it just has to be told to read in the file (and there
are numerous ways to do that from writing elsip functions, command
line switches and the site init file).
>>
>>>>> .vm-windows. w3m uses .w3m etc. However, all your configuration
>>>> should be done in your home directory - think about Linux as a
>>>> multi-user environment - thats how it is designed. In such
>>>
>>> Linus is a multiuser environment : hence the difficulty in knowing hos
>>> *best* to install extensions you want open to all logins. There are a
>>> myriad of ways of doing it. and a *lot* of emacs addons are hacks from
>>> lisp experts who dont really offer suported ways of how to install it
>>> for the best.
>>>
>>
>> Examples? My experience with emacs add-ons has been that if the add-on
>> is worth using, it has had a reasonable default for its configuration.
>> In 15 years, I can only think of a couple of minor instances in which
>> a package was difficult to configure and in each case, this was
>> because it was a very old package which had not been actively
>> maintained, so some work was required to get it working with newer
>> versions.
>
> Most emacs stuff is stable : there is a lot being developed too. There is
> a lot of stuff requiring cross app compatability which then clashes with
> the debian packages. I'm not making this up you know. Go and install,
> say cedet. Latest version. Not rocket science, but not trivial either.
>
I don't remember saying any of it was trivial - it is straight forward
and simply takes the time to do it.
>>
>>
>>>> environments, you don't want personal configuration options being
>>>> set on a global level that can affect all users. Such
>>>> configurations should be put in your home directory.
>>>>
>>>> 4. Never run as root unless you have no choice (i.e. installing new
>>>> packages, shutting down (though there are workarounds for that as
>>>
>>> eh? Where did this come from? You must sudo to root to install things
>>> for multi-user access. Hence my comment on the complexity of the emacs
>>> linux tree.
>>
>> Which part of "...unless you have no choice (i.e. installing new
>> packages,..." did you have trouble understanding?
>
> None of it: I just wondered why you felt the need to state the bleeding
> obvious. This thread wasnt about sudo issues : it was about best ways of
> configuring emacs on debian in a concistent and reproducible manner.
>
You might have found it bleeding obvious, but from the things you had
written it was not at all obvious what knowledge or experience you
had. Still, your comment of me being argumentative now seems somewhat
ironic.
>>
>>>And it is complicated : for someone who wants to use a "more
>>> powerful editor". I use emacs as a C and an ADA development environment.
>>>
>>
>> This came from the fact it seemed from your original comments that you
>> have very limited system administration experience and running as root
>> when not necessary is a common mistake of those who don't have much
>> experience - it was meant as a cautionary note.
>>
>> My original point is that this is still nothing to do with emacs. The
>
> Fair enough.
>
>> complexities you are referring to are solely due to how Debian has
>> decided to layout the emacs installation - nothing within emacs
>> requires this structure. Given what you get as a result, Debian has
>> done an excellent job - the fact you are not familiar with the
>> advantages of there approach doesn't automatically mean it is too
>> complex.
>
> I am very aware of the advantages : I also am aware of the
> disadvantages. As a not too naive user of systems for many years, I
> stand by the fact that the debian emacs directory hierarchies are
> confusing - possibly due to the flexibility they provide. But confusing nonetheless.
>
I don't disagree - again, your original premise was that emacs was
difficult to configure and my response was that its not emacs, it is
the way Debian has done it. However, there are a lot of advantages to
how they have done it which I think justify the apparent confusion you
have experienced. I'd now go further and say that your confusion is
easily remedied if you look at the Debian package policy for emacsen.
It actually is not complicated once you bother to try and understand
what they are trying to achieve and how it works.
>>
>>>> well), doing low level system configuration etc). When you do have
>>>> to use root, use things like sudo - this will ensure you don't
>>>
>>> I know.
>>>
>>>> shoot yourself in the foot - plenty of sys admins (including myself
>>>> once) learn this the hard way. I once did a rm -rf * from the root
>>>> partition when cleaning up a system, after a very long day and
>>>> forgetting I was logged in as root! However, I know a lot of very
>>>> experienced and smarter people who have done as bad and worse, so
>>>> feel I'm in pretty good company!
>>>
>>> Personally I always use sudo.
>>>
>>
>> Good. However, sometimes, su - is also needed, the trick is knowing
>> when.
>
> What trick?
The tric of knowing when of course!
>
>>
>>
>> --
>> tcross (at) rapttech dot com dot au
>
> I guess there isnt really much more to say : you think its easy and I
> disagree.
>
> Maybe I'm, what was the phrase from the other poster, "stupid"? :-)
No, I wouldn't have said you were stupid. With no effort and only a
cursory glance, it can look complicated. the point is it actually is
very straight-forward and easy once you bother to find out what the
methodology underlying the Debian design is.
--
tcross (at) rapttech dot com dot au
Hadron Quark <···········@gmail.com> writes:
> "Greg"posted on 2006-04-25:
> > Just copy your .emacs file to a usb thumb drive and you're done, even on
> > a Windows machine. Try and save your Windows app configuration in
> >some
>
> Do you have any idea how wrong you are on this? Different emacs apps
> install in different emacs places. They require changes to different
> emacs config files. often newer versions require adding extra lines to
> start.site.el, or addition of 50xxxx.el files in site-start.d. Often
> they are not compatible with Xemacs but are with 22.04 etc etc
> etc. Its is a myth that just copying your .emacs saves your
> configuration and install base.
That's the extremely convoluted Debian setup, it seems. It's weird and
scary, and tends to break or behave badly in odd ways. Building Emacs
from scratch and maintaining your site-lisp directories manually is
a /whole/ lot easier, especially since Debian collects the sources to
a whole lot of packages, so you don't need to hunt them down yourself.
(I'm not an expert Emacs nor Debian admin, but I've used them both for
10+ years, and maintained an Emacs installation for a couple of
hundred users for a number of years. The Debian Emacs setup on my
single-user box is a whole lot more convoluted than what we used for
4 OS's on 3 hardware platforms.)
',mr
--
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_
rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:
> Hadron Quark <···········@gmail.com> writes:
>> "Greg"posted on 2006-04-25:
>> > Just copy your .emacs file to a usb thumb drive and you're done, even on
>> > a Windows machine. Try and save your Windows app configuration in
>> >some
>>
>> Do you have any idea how wrong you are on this? Different emacs apps
>> install in different emacs places. They require changes to different
>> emacs config files. often newer versions require adding extra lines to
>> start.site.el, or addition of 50xxxx.el files in site-start.d. Often
>> they are not compatible with Xemacs but are with 22.04 etc etc
>> etc. Its is a myth that just copying your .emacs saves your
>> configuration and install base.
>
> That's the extremely convoluted Debian setup, it seems. It's weird and
> scary, and tends to break or behave badly in odd ways. Building Emacs
I'm relieved to hear someone saying that. I thought I was going nuts for
a minute : especially with an emacs admin of 15 years telling me how
obvious it all was and how he configures multi-user emacs installations
without having a single problem because of how simple debian makes
it. Frankly I think the debian directory setup for emacs is
understandable, but far from trivial.
>>>>> "Hadron" == Hadron Quark <···········@gmail.com> writes:
Hadron> Frankly I think the debian directory setup for emacs is
Hadron> understandable, but far from trivial.
The Debian system is not simple but this is mostly because it solves a
complex task, that of having a set of emacs libraries that runs across
a range of emacs implementations. The Debian handling of Common Lisp
isn't exactly trivial either and has gone through a number of
evolutions in order to get the right shape.
The important part, however, is that to the casual user, it really is
rock&roll from the outset. All of the complexity is for the package
maintainer to sort out.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Christian Lynbech <·········@defun.dk> writes:
>>>>>> "Hadron" == Hadron Quark <···········@gmail.com> writes:
>
> Hadron> Frankly I think the debian directory setup for emacs is
> Hadron> understandable, but far from trivial.
>
> The Debian system is not simple but this is mostly because it solves a
> complex task, that of having a set of emacs libraries that runs across
> a range of emacs implementations. The Debian handling of Common Lisp
> isn't exactly trivial either and has gone through a number of
> evolutions in order to get the right shape.
>
> The important part, however, is that to the casual user, it really is
> rock&roll from the outset. All of the complexity is for the package
> maintainer to sort out.
>
Exactly. The trick is not to modify the debian provided config/init
scripts for the emacs packages unless you find a really good reason
to. If you find one of them doesn't work correctly, its a bug and
needs to be reported to the package maintainer.
For emacs packages you install yourself, you can either follow
debian's approach or, if your users only run one flavor of emacs, a
much simpler structure.
The issue of configuration then becomes simply configuring the
non-debian emacs add ons and your personal .emacs. The whole thing
then becomes as simple or as complex as you want.
Tim
--
tcross (at) rapttech dot com dot au
Tim X <····@nospam.dev.null> writes:
> Christian Lynbech <·········@defun.dk> writes:
>
>>>>>>> "Hadron" == Hadron Quark <···········@gmail.com> writes:
>>
>> Hadron> Frankly I think the debian directory setup for emacs is
>> Hadron> understandable, but far from trivial.
>>
>> The Debian system is not simple but this is mostly because it solves a
>> complex task, that of having a set of emacs libraries that runs across
>> a range of emacs implementations. The Debian handling of Common Lisp
>> isn't exactly trivial either and has gone through a number of
>> evolutions in order to get the right shape.
>>
>> The important part, however, is that to the casual user, it really is
>> rock&roll from the outset. All of the complexity is for the package
>> maintainer to sort out.
>>
> Exactly. The trick is not to modify the debian provided config/init
> scripts for the emacs packages unless you find a really good reason
> to. If you find one of them doesn't work correctly, its a bug and
> needs to be reported to the package maintainer.
About the last 6 out of 7 things I installed were not in a debian
package.
>
> For emacs packages you install yourself, you can either follow
> debian's approach or, if your users only run one flavor of emacs, a
> much simpler structure.
What dont you understand? There as posters here telling you that its not
trivial to do that and you simply ignore that?
I love emacs : but how either of you can say "emacs is easy from day
one" is beyond me.
>
> The issue of configuration then becomes simply configuring the
> non-debian emacs add ons and your personal .emacs. The whole thing
> then becomes as simple or as complex as you want.
Yet again you choose to ignore the multiple user scenario, which, while
not impossible, can be confusing in debian. *Confusing* not impossible.
>
> Tim
>
>
> --
> tcross (at) rapttech dot com dot au
--
lithp : syntax error
Hadron Quark <···········@gmail.com> writes:
> Tim X <····@nospam.dev.null> writes:
>
>> Christian Lynbech <·········@defun.dk> writes:
>>
>>>>>>>> "Hadron" == Hadron Quark <···········@gmail.com> writes:
>>>
>>> Hadron> Frankly I think the debian directory setup for emacs is
>>> Hadron> understandable, but far from trivial.
>>>
>>> The Debian system is not simple but this is mostly because it solves a
>>> complex task, that of having a set of emacs libraries that runs across
>>> a range of emacs implementations. The Debian handling of Common Lisp
>>> isn't exactly trivial either and has gone through a number of
>>> evolutions in order to get the right shape.
>>>
>>> The important part, however, is that to the casual user, it really is
>>> rock&roll from the outset. All of the complexity is for the package
>>> maintainer to sort out.
>>>
>> Exactly. The trick is not to modify the debian provided config/init
>> scripts for the emacs packages unless you find a really good reason
>> to. If you find one of them doesn't work correctly, its a bug and
>> needs to be reported to the package maintainer.
>
> About the last 6 out of 7 things I installed were not in a debian
> package.
>
>>
>> For emacs packages you install yourself, you can either follow
>> debian's approach or, if your users only run one flavor of emacs, a
>> much simpler structure.
>
> What dont you understand? There as posters here telling you that its not
> trivial to do that and you simply ignore that?
>
No, I have not ignored it. You continue not to comprehend what I have
said because you simply don't want to. I'll restate things again. This
is my last post on the issue as I cannot be bothered trying to assist
you by clarifying your misunderstanding on the difference between a
distribution imposed methodology and that of emacs.
1. The Debian way of configuring emacs does appear to be complex, but
in fact is quite straight forward if you bother to read the
available documentation in the emacs policies on how emacsen
packages are to be installed.
2. 99% of the time, you do not need to modify the Debian config
scripts for emacs add-on packages
3. If you have to install an emacs add-on which is not in a debian
package, you DO NOT HAVE TO FOLLOW THE DEBIAN DEFINED CONFIGURATION
POLICY. You can do it using any methodology you want.
4. If you do not run multiple different versions of emacs, the way you
install an emacs add-on is greatly simplified and involves three
basic steps
1. Unpack the *.el files into a directory that is either already in
the emacs load-path or add the directory to the load-path. This
can be added in either the emacs site-init.el file or left for
users to add into the personal .emacs file - the choice depends
on how you want to manage your system.
2. Depending on the package, it may be worth compiling the *.el
files into .elc files. This can be tricky if there are lots of
dependencies and it may be necessary to compile things in a
certain order. However, in 15 years of managing emacs add-on
packages, I have not seen a single emacs add-on which was
complex to build that didn't have a makefile which did all the
work for you. All you need to do is type make (sometimes you
make need to do run configure for larger emacs add-ons which use
autoconf etc).
3. Create a init/config file. Many emacs add-ons don't even need
one of these and the defaults are fine. This file is usually
very simple. Now, the important bit which you continually refuse
to take in...
The init file for your package can be called by either the
standard emacs sit-init.el file or you can tell users who want
to start/run that package to source the file from their personal
.emacs. Thats TWO possible points you need to worry about, not
the nightmare of configuration directories you keep refering to.
That seems pretty straight forward to me. I guess our measure of
difficulty is different.
> I love emacs : but how either of you can say "emacs is easy from day
> one" is beyond me.
>
Never ever said it was. In fact, if you go through emacs newsgroup
archives, you will find posts from me going back many years talking to
new users and attempting to assist them to deal with the tough
learning curve. There is a paradigm shift which many users find
difficult, but once the penny drops, its very straight forward.
I got involved in this thread when you made the statement, which I
assumed was informed and realise now was based on ignorance, that
emacs was difficult to configure because of a confusing hierarchy of
configuration directories and paths. I merely pointed out that this
was not emacs, but due to Debian and have pointed out in a couple of
posts that emacs actually only knows about a couple of configuration
files which are clearly documented in the manual. I went further to
point out that Debian's approach is clearly laid out in their package
policy which is available on their web site and that for non-deb
packages, you do NOT have to follow the complex debian way of things,
especially if you don't run multiple different versions of emacs. In
these situations, things are a lot simpler and very straight forward
(regardless of whether you are talking a multi-user or single user system).
>> The issue of configuration then becomes simply configuring the
>> non-debian emacs add ons and your personal .emacs. The whole thing
>> then becomes as simple or as complex as you want.
>
> Yet again you choose to ignore the multiple user scenario, which, while
> not impossible, can be confusing in debian. *Confusing* not impossible.
>
I should have said above as I've said in other posts responding to
this topic) that you can put the configuration in either the
site-init.el file or have it called by that file or you can just let
users put it in the .emacs file. In fact, you are often better off
letting people put it in their .emacs file even on a multi-user system
because not everyone wants to run all the same packages and why would
they want a slower load time loading packages they are not interrested
in just because some over zelous sys admin has set things up badly.
Given that initially in this thread, you didn't even know what emacs
you were running and given you didn't understand the difference
between emacs and xemacs and the fact despite numerous requests for
examples you have not given any example of emacs packages which are
difficult and complex to configure (except for a vague referenced to
cedet, which has no significant installation issue apart from
requiring other emacs add-ons, which can be a pain due to the time
needed to do all the add-ons, but is trivial otherwise), I now suspect
that all you really want to do is moan and are not actually interested
in assistance or help to understand how easy it actually all is.
--
tcross (at) rapttech dot com dot au
Tim X <····@nospam.dev.null> writes:
> Hadron Quark <···········@gmail.com> writes:
>
>> Tim X <····@nospam.dev.null> writes:
>>
>>> Christian Lynbech <·········@defun.dk> writes:
>>>
>>>>>>>>> "Hadron" == Hadron Quark <···········@gmail.com> writes:
>>>>
>>>> Hadron> Frankly I think the debian directory setup for emacs is
>>>> Hadron> understandable, but far from trivial.
>>>>
>>>> The Debian system is not simple but this is mostly because it solves a
>>>> complex task, that of having a set of emacs libraries that runs across
>>>> a range of emacs implementations. The Debian handling of Common Lisp
>>>> isn't exactly trivial either and has gone through a number of
>>>> evolutions in order to get the right shape.
>>>>
>>>> The important part, however, is that to the casual user, it really is
>>>> rock&roll from the outset. All of the complexity is for the package
>>>> maintainer to sort out.
>>>>
>>> Exactly. The trick is not to modify the debian provided config/init
>>> scripts for the emacs packages unless you find a really good reason
>>> to. If you find one of them doesn't work correctly, its a bug and
>>> needs to be reported to the package maintainer.
>>
>> About the last 6 out of 7 things I installed were not in a debian
>> package.
>>
>>>
>>> For emacs packages you install yourself, you can either follow
>>> debian's approach or, if your users only run one flavor of emacs, a
>>> much simpler structure.
>>
>> What dont you understand? There as posters here telling you that its not
>> trivial to do that and you simply ignore that?
>>
>
> No, I have not ignored it. You continue not to comprehend what I have
> said because you simply don't want to. I'll restate things again. This
> is my last post on the issue as I cannot be bothered trying to assist
> you by clarifying your misunderstanding on the difference between a
> distribution imposed methodology and that of emacs.
>
> 1. The Debian way of configuring emacs does appear to be complex, but
This is not what you said earlier if I recall correctly.
> in fact is quite straight forward if you bother to read the
> available documentation in the emacs policies on how emacsen
> packages are to be installed.
Sigh. All relative to how much work is required to get a result I
suppose.
>
> 2. 99% of the time, you do not need to modify the Debian config
> scripts for emacs add-on packages
I never said you did : you said that. I was referring to EL files. And
the debian package installation varies between packages too in how it
installs modules. It is NOT easy and obvious to anyone without a degree
in emacs as you appear to have. Other posters have concurred.
>
> 3. If you have to install an emacs add-on which is not in a debian
> package, you DO NOT HAVE TO FOLLOW THE DEBIAN DEFINED CONFIGURATION
> POLICY. You can do it using any methodology you want.
>
> 4. If you do not run multiple different versions of emacs, the way you
> install an emacs add-on is greatly simplified and involves three
> basic steps
>
> 1. Unpack the *.el files into a directory that is either already in
> the emacs load-path or add the directory to the load-path. This
> can be added in either the emacs site-init.el file or left for
> users to add into the personal .emacs file - the choice depends
> on how you want to manage your system.
Sigh. I know. I mentioned these as two of the options : there are also
debian specific ways - that is what I said was complicated. There is no
apparent common concensus. How can you not see that this can lead to
confusion? I know why, but I will refrain from saying it. As for cross
dependencies : its might not be emacs itself, per se, but the plethora
of hacked el files on the web can make it very difficult to align versions.
>
> 2. Depending on the package, it may be worth compiling the *.el
> files into .elc files. This can be tricky if there are lots of
> dependencies and it may be necessary to compile things in a
> certain order. However, in 15 years of managing emacs add-on
15 years again ... I'm so impressed.
> packages, I have not seen a single emacs add-on which was
> complex to build that didn't have a makefile which did all the
> work for you. All you need to do is type make (sometimes you
> make need to do run configure for larger emacs add-ons which use
> autoconf etc).
On your system. Would you like to comment on how easy it is or isnt
under debian? But at least we get there : you think it is perfectly
simple and error free to determine compilation order and to "make"
things. A lot of new users might disagree. But we are agreed that good
things might take time to learn.
>
> 3. Create a init/config file. Many emacs add-ons don't even need
> one of these and the defaults are fine. This file is usually
> very simple. Now, the important bit which you continually refuse
> to take in...
>
> The init file for your package can be called by either the
> standard emacs sit-init.el file or you can tell users who want
> to start/run that package to source the file from their personal
> .emacs. Thats TWO possible points you need to worry about, not
> the nightmare of configuration directories you keep refering to.
>
> That seems pretty straight forward to me. I guess our measure of
> difficulty is different.
You clearly fail to see how the "flexibility" leads to problems in
knowing how best to do things.
>
>
>> I love emacs : but how either of you can say "emacs is easy from day
>> one" is beyond me.
>>
> Never ever said it was. In fact, if you go through emacs newsgroup
> archives, you will find posts from me going back many years talking to
> new users and attempting to assist them to deal with the tough
> learning curve. There is a paradigm shift which many users find
> difficult, but once the penny drops, its very straight forward.
Aha, so people do find things difficult? There is a reason for that. And
its not so much a paradigm shift as an accumulation of a lot of
knowledge. A small shift maybe.
>
> I got involved in this thread when you made the statement, which I
> assumed was informed and realise now was based on ignorance, that
Aha. Natural order rearing its ugly head ...
> emacs was difficult to configure because of a confusing hierarchy of
> configuration directories and paths. I merely pointed out that this
> was not emacs, but due to Debian and have pointed out in a couple of
> posts that emacs actually only knows about a couple of configuration
It was emacs under debian. And clearly debian have done this to address
something in a multi user, multi version OS.
And if you reread it again : you will see that I was right. because of
the debian directories, emacs is difficult to configure in a concistent
and clear manner IMO. difficult : not impossible.
> files which are clearly documented in the manual. I went further to
> point out that Debian's approach is clearly laid out in their package
> policy which is available on their web site and that for non-deb
> packages, you do NOT have to follow the complex debian way of things,
I guess that anything that is "on a web" or "in a book" is immediately
trivial for you. For me and posisbly others, it is not.
> especially if you don't run multiple different versions of emacs. In
> these situations, things are a lot simpler and very straight forward
> (regardless of whether you are talking a multi-user or single user
> system).
I know about the debian hierarchy, I know how I can
reference el files. But is NOT TRIVIAL and it can be
difficult. Primarily because the different packages put things in
different places. Different el files need to go in different places and
have special ordering. You think it is *easy* because of your "15 years
of being an emacs admin" : does it not cross your mind that for others
it is not so? Can you not see that? I think not.
>
>>> The issue of configuration then becomes simply configuring the
>>> non-debian emacs add ons and your personal .emacs. The whole thing
>>> then becomes as simple or as complex as you want.
>>
>> Yet again you choose to ignore the multiple user scenario, which, while
>> not impossible, can be confusing in debian. *Confusing* not impossible.
>>
>
> I should have said above as I've said in other posts responding to
> this topic) that you can put the configuration in either the
> site-init.el file or have it called by that file or you can just let
> users put it in the .emacs file. In fact, you are often better off
> letting people put it in their .emacs file even on a multi-user system
> because not everyone wants to run all the same packages and why would
> they want a slower load time loading packages they are not interrested
> in just because some over zelous sys admin has set things up badly.
Thats fair enough.
>
> Given that initially in this thread, you didn't even know what emacs
> you were running and given you didn't understand the difference
> between emacs and xemacs and the fact despite numerous requests for
Who said I didnt understand the difference? I never installed
"xemacs" specifically , but run an x-windows desktop, is it not
reasonable to consider that "xemacs" is run as a proxy for emacs? I dont
know : its all a bit confusing - especially when my emacs-version
included references to "X-Toolkits" etc.
You make the same mistake as a lot of clever clog gurus : you refuse to
accept that not everyone has the time or the desire to accumulate
peripheral knowledge not directly required to do a job of work.
> examples you have not given any example of emacs packages which are
> difficult and complex to configure (except for a vague referenced to
> cedet, which has no significant installation issue apart from
> requiring other emacs add-ons, which can be a pain due to the time
> needed to do all the add-ons, but is trivial otherwise), I now suspect
You even back me up. Now my examples are "vague". LOL. And "trivial"
again. It must be this 15 years again eh?
Trivial for me is "install", not sudo'ing to root and wondering where
the hell the files should go.
> that all you really want to do is moan and are not actually interested
> in assistance or help to understand how easy it actually all is.
>
Arrogance overload. No where did you try and help (until last
post) : only to belittle and blow your own trumpet. So we are in
agreement : no more on this subject - and for me, no more at all from you.
As a footnote, with help from other posters, I have acquired a wonderful
working development environment. I used emacs on Convex systems years
ago and its great to be using it again. This is not a rant against
emacs: far from it.
>
>
> --
> tcross (at) rapttech dot com dot au
--
lithp : syntax error
Hadron Quark <···········@gmail.com> writes:
> Tim X <····@nospam.dev.null> writes:
>
>> 2. 99% of the time, you do not need to modify the Debian config
>> scripts for emacs add-on packages
>
> I never said you did : you said that. I was referring to EL
> files. And the debian package installation varies between packages
> too in how it installs modules. It is NOT easy and obvious to anyone
> without a degree in emacs as you appear to have. Other posters have
> concurred.
A degree in Emacs does not help: there is sort of a consensus between
core developers of Emacs and XEmacs that they compile their own
Emacsen because they don't understand the Debian Emacs policy.
In fact, a degree in Emacs is downright detrimental: Emacs' load-path
search order and arrangement and the byte-compilation commands are
_based_ on the premise that .el-files and .elc-files are in the same
directory. All of this is completely broken in Debian's Emacs
layouts. If you use the diagnostics like M-x list-load-path-shadows
RET, you get gazillions of conflicts displayed.
Emacs does not understand what Debian is doing with it, and the Emacs
developers and users don't understand it.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
David Kastrup <···@gnu.org> writes:
> Hadron Quark <···········@gmail.com> writes:
>
>> Tim X <····@nospam.dev.null> writes:
>>
>>> 2. 99% of the time, you do not need to modify the Debian config
>>> scripts for emacs add-on packages
>>
>> I never said you did : you said that. I was referring to EL
>> files. And the debian package installation varies between packages
>> too in how it installs modules. It is NOT easy and obvious to anyone
>> without a degree in emacs as you appear to have. Other posters have
>> concurred.
>
> A degree in Emacs does not help: there is sort of a consensus between
> core developers of Emacs and XEmacs that they compile their own
> Emacsen because they don't understand the Debian Emacs policy.
>
> In fact, a degree in Emacs is downright detrimental: Emacs' load-path
> search order and arrangement and the byte-compilation commands are
> _based_ on the premise that .el-files and .elc-files are in the same
> directory. All of this is completely broken in Debian's Emacs
> layouts. If you use the diagnostics like M-x list-load-path-shadows
> RET, you get gazillions of conflicts displayed.
>
> Emacs does not understand what Debian is doing with it, and the Emacs
> developers and users don't understand it.
This I can believe. Unfortunately, in the real world "emacs not
configuring well in debian" is for me (using debian) the same as "emacs
is hard to configure". I should really replace "hard" with "confusing at
times".
>
> --
> David Kastrup, Kriemhildstr. 15, 44793 Bochum
--
lithp : syntax error
From: Alan Mackenzie
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <dmhh3e.qd.ln@acm.acm>
David Kastrup <···@gnu.org> wrote on Tue, 02 May 2006 13:09:57 +0200:
> A degree in Emacs does not help: there is sort of a consensus between
> core developers of Emacs and XEmacs that they compile their own Emacsen
> because they don't understand the Debian Emacs policy.
> In fact, a degree in Emacs is downright detrimental: Emacs' load-path
> search order and arrangement and the byte-compilation commands are
> _based_ on the premise that .el-files and .elc-files are in the same
> directory. All of this is completely broken in Debian's Emacs layouts.
I had a problem with Debian's setup: It had installed a content free
site-start.el file, high up on the load-list, so as to frustrate and
irritate me by preventing Emacs loading my real site-start.el. Took me
half an hour to diagnose this.
> If you use the diagnostics like M-x list-load-path-shadows RET, you get
> gazillions of conflicts displayed.
Hey, I didn't know about this command. I wish I had've done about 5
years ago. It's brilliant. Thanks, David!
> Emacs does not understand what Debian is doing with it, and the Emacs
> developers and users don't understand it.
> --
> David Kastrup, Kriemhildstr. 15, 44793 Bochum
--
Alan Mackenzie (Munich, Germany)
Email: ····@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").
>>>>> "Hadron" == Hadron Quark <···········@gmail.com> writes:
Hadron> About the last 6 out of 7 things I installed were not in a debian
Hadron> package.
I am getting confused. In what way is the Debian emacs add-on package
strategy complicating installation of non-Debian packaged emacs add-ons?
Hadron> I love emacs : but how either of you can say "emacs is easy from day
Hadron> one" is beyond me.
Emacs is a rather complex application. Getting to know all of the
parts takes a very lomng time. Even more so, some add-on packages such
as GNUS carries huge amounts of functionality which also can demand a
lot of energy and time to set up and use.
But, again, I fail to see that this is futher complicated by Debian. I
would greatly appreciate an example as I am really curious.
If I am included in the "either of you" referred to above, let me just
say that what I was driving at was that IMHO installing (say) the
Debian GNUS package is easy (at least no more difficult than Debian
package in general). You point to "gnus" and press `install' and in a
short while you have access to a recent and common version of "gnus"
that will work across the handfull of emacs variations supported by
Debian. Now configuring and utilising is quite another matter but you
face that no matter how you install it.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
From: ·······@at.BioStrategist.dot.dot.com
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <e2krnb$351$1@reader1.panix.com>
The thing about emacs is you can work at speed-of-thought.
Too many Windows apps are dumbed down.
User friendly is for stupid users.
- = -
Vasos-Peter John Panagiotopoulos II, Reagan Mozart Pindus BioStrategist
http://ourworld.compuserve.com/homepages/vjp2/vasos.htm
---{Nothing herein constitutes advice. Everything fully disclaimed.}---
[Ignore http://lynx.browser.org/ noncompliant web sites]
[Regulation begets corruption] [Urb Sprawl confounds terror]
[Homeland Security means private firearms not lazy obstructive guards]
·······@at.BioStrategist.dot.dot.com writes:
> The thing about emacs is you can work at speed-of-thought.
>
> Too many Windows apps are dumbed down.
>
> User friendly is for stupid users.
User-friendly is also good for:
- Casual users
- Occasional users
- Non-programmers
- Users with less computer experience
- Users with better things to do than learn Emacs
I know many people for whom user-friendly is mandatory. Very few of
them are stupid.
Ari Johnson <·········@gmail.com> writes:
> ·······@at.BioStrategist.dot.dot.com writes:
>
>> The thing about emacs is you can work at speed-of-thought.
>>
>> Too many Windows apps are dumbed down.
>>
>> User friendly is for stupid users.
>
> User-friendly is also good for:
> - Casual users
> - Occasional users
> - Non-programmers
> - Users with less computer experience
> - Users with better things to do than learn Emacs
>
> I know many people for whom user-friendly is mandatory. Very few of
> them are stupid.
Perhaps true - but then again, emacs obviously isn't the right tool
for people like this - why have a high performance car which you only
drive to the shops for milk and bread?
Emacs is complex because it is extremely powerful. If you don't need
the power, then don't use it. If you do want that power, then you have
to learn how to use the tool. You cannot get powerful customizable
tools able to be configured to work how you want and have it do so out
of the box because there is too much variation in what people do. This
will have to wait until we have really really intelligent mind reading
software which is able to work out what you need autonomously - until
then, either use something simple or be prepared to face a learning
curve while you gain the power available with emacs.
Tim
--
tcross (at) rapttech dot com dot au
Tim X <····@nospam.dev.null> writes:
> Ari Johnson <·········@gmail.com> writes:
>
>> ·······@at.BioStrategist.dot.dot.com writes:
>>
>>> The thing about emacs is you can work at speed-of-thought.
>>>
>>> Too many Windows apps are dumbed down.
>>>
>>> User friendly is for stupid users.
>>
>> User-friendly is also good for:
>> - Casual users
>> - Occasional users
>> - Non-programmers
>> - Users with less computer experience
>> - Users with better things to do than learn Emacs
>>
>> I know many people for whom user-friendly is mandatory. Very few of
>> them are stupid.
>
> Perhaps true - but then again, emacs obviously isn't the right tool
> for people like this - why have a high performance car which you only
> drive to the shops for milk and bread?
People like what? people that want easy things to be easy? Please.
>
> Emacs is complex because it is extremely powerful. If you don't need
> the power, then don't use it. If you do want that power, then you have
> to learn how to use the tool. You cannot get powerful customizable
Lots of things are powerful. Including your analogy : a performace
car. But there is still a steering wheel, a clutch etc. No need to
reinvent the wheel ... to extend your analogy.
> tools able to be configured to work how you want and have it do so out
> of the box because there is too much variation in what people do. This
True.
> will have to wait until we have really really intelligent mind reading
> software which is able to work out what you need autonomously - until
> then, either use something simple or be prepared to face a learning
> curve while you gain the power available with emacs.
No one doubts the power of emacs : it doesnt mean that the "simple"
things need to be obfuscated,
>
> Tim
>
> --
> tcross (at) rapttech dot com dot au
--
lithp : syntax error
Hadron Quark <···········@gmail.com> writes:
> Tim X <····@nospam.dev.null> writes:
>
> >
> > Perhaps true - but then again, emacs obviously isn't the right tool
> > for people like this - why have a high performance car which you only
> > drive to the shops for milk and bread?
>
> People like what? people that want easy things to be easy? Please.
And what easy things in Emacs are hard to do?
There are file and edit menus with the standard sorts of things in
them. You can navigate with the arrow keys or the mouse. You use the
mouse to select text.
The only thing that, out-of-the-box, isn't like other editors is that
typing doesn't replace selected text. To get that behavior you have to
change a configuration.
> > Emacs is complex because it is extremely powerful. If you don't need
> > the power, then don't use it. If you do want that power, then you have
> > to learn how to use the tool. You cannot get powerful customizable
>
> Lots of things are powerful. Including your analogy : a performace
> car. But there is still a steering wheel, a clutch etc. No need to
> reinvent the wheel ... to extend your analogy.
OK. And as shown above, all of those standard things are present in
Emacs. (Oh, by the way, what is the "clutch" thing of which you
speak?)
> > tools able to be configured to work how you want and have it do so out
> > of the box because there is too much variation in what people do. This
>
> True.
>
> > will have to wait until we have really really intelligent mind reading
> > software which is able to work out what you need autonomously - until
> > then, either use something simple or be prepared to face a learning
> > curve while you gain the power available with emacs.
>
> No one doubts the power of emacs : it doesnt mean that the "simple"
> things need to be obfuscated,
What simple things are hard?
I will grant you that the keyboard shortcuts don't match what have
become the Mac and Windows conventions. At least on the Mac, though,
you can make the mapping match, because Emacs doesn't use the Command
key.
The issue with changing those is that it would seriously mess with the
minds of the millions of existing Emacs users, who expect the
control-... keys to do what they expect. Besides, Emacs was here long
before Windows. :-P
--
Thomas A. Russ, USC/Information Sciences Institute
From: Galen Boyer
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <ufyjzvjju.fsf@rcn.com>
On Tue, 25 Apr 2006, ·········@gmail.com wrote:
> ·······@at.BioStrategist.dot.dot.com writes:
>
>> The thing about emacs is you can work at speed-of-thought.
>>
>> Too many Windows apps are dumbed down.
>>
>> User friendly is for stupid users.
>
> User-friendly is also good for:
> - Casual users
> - Occasional users
> - Non-programmers
> - Users with less computer experience
> - Users with better things to do than learn Emacs
So, then let them use something suited for them.
> Very few of them are stupid.
No, I know multitudes of non-emacs users and developers. Some are
stupid, some aren't. To me, the tool I use is something that, in and of
itself, I find a pleasure to use. Most developers I know are enamored
with the language they are coding, such as java combined with eclipse.
These guys don't have to spend hours/days/weeks "learning" their tool.
They open eclipse and are off and running. Most of what I hear is that
it is configurable and as powerful as Emacs, but I have watched many and
none do anything more than out of the box stuff. But, these guys also
code great java applications. They are not stupid by any means.
Eclipse is a big reason they can be so proud and paid so handsomely for
their craft.
But, to me, the coding language and application environment is really
the means for me to get better at Emacs, because, at the end of the day,
I really think I love programming because I love to program in Emacs.
And that is really my thought is that I love Emacs more than I love java
or Oracle's fantastic database engine and sqlplus's simplistic power, or
XML's sexy power, or source control's organization of my codebase, or
ant's capabilities for builds or ... I really love to bring all of
these things together better and better and better each and everyday
because I use Emacs to do that.
--
Galen Boyer
Galen Boyer <···········@yahoo.com> writes:
> On Tue, 25 Apr 2006, ·········@gmail.com wrote:
>> ·······@at.BioStrategist.dot.dot.com writes:
>>
>>> The thing about emacs is you can work at speed-of-thought.
>>>
>>> Too many Windows apps are dumbed down.
>>>
>>> User friendly is for stupid users.
>>
>> User-friendly is also good for:
>> - Casual users
>> - Occasional users
>> - Non-programmers
>> - Users with less computer experience
>> - Users with better things to do than learn Emacs
>
> So, then let them use something suited for them.
>
>> Very few of them are stupid.
>
> No, I know multitudes of non-emacs users and developers. Some are
> stupid, some aren't. To me, the tool I use is something that, in and
> of
Judged by who?
> itself, I find a pleasure to use. Most developers I know are enamored
> with the language they are coding, such as java combined with eclipse.
> These guys don't have to spend hours/days/weeks "learning" their tool.
Yes they do. Eclipse is quite a paradigm shift from other IDEs.
> They open eclipse and are off and running. Most of what I hear is
> that
No they are not. Thats why it comes with very good tutorials which guide
the programmer through project creation and maintenance.
> it is configurable and as powerful as Emacs, but I have watched many
> and
True. More so.
> none do anything more than out of the box stuff. But, these guys also
> code great java applications. They are not stupid by any means.
> Eclipse is a big reason they can be so proud and paid so handsomely for
> their craft.
Eclipse supports their craft : its not the reason to be proud of the end result.
>
> But, to me, the coding language and application environment is really
> the means for me to get better at Emacs, because, at the end of the day,
> I really think I love programming because I love to program in Emacs.
> And that is really my thought is that I love Emacs more than I love
> java
Wow : thats a whole lotta loving going on here.
> or Oracle's fantastic database engine and sqlplus's simplistic power, or
> XML's sexy power, or source control's organization of my codebase, or
> ant's capabilities for builds or ... I really love to bring all of
> these things together better and better and better each and everyday
> because I use Emacs to do that.
You seem to confuse user friendliness with reduced functionality : this
is only the case when "stupid" people implement the user friendliness.
>
> --
> Galen Boyer
--
lithp : syntax error
From: Galen Boyer
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <uwtdbt6na.fsf@rcn.com>
On Thu, 27 Apr 2006, ···········@gmail.com wrote:
> You seem to confuse user friendliness with reduced functionality :
> this is only the case when "stupid" people implement the user
> friendliness.
So, is your point that the Emacs developers are stupid people?
--
Galen Boyer
Galen Boyer <···········@yahoo.com> writes:
> On Thu, 27 Apr 2006, ···········@gmail.com wrote:
>
>> You seem to confuse user friendliness with reduced functionality :
>> this is only the case when "stupid" people implement the user
>> friendliness.
>
> So, is your point that the Emacs developers are stupid people?
>
> --
> Galen Boyer
Most certainly not : I seem to recall that it was you accusing people
who wanted an app to be user friendly as "stupid".
My last line was taking a swipe at your inability to accept that things
can be highly functional and user friendly - and this is even without
taking emacs into account.
I disagree strongly with your assertion that "user friendly apps
are for stupid people".
Emacs doesnt strive for user friendliness : is strives for power. Most
things it does are for a reason - my point is that its not necessrily
"obvious" how to best use it - even for "non stupid" people.
From: Galen Boyer
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <uodymtqhe.fsf@rcn.com>
On Thu, 27 Apr 2006, ···········@gmail.com wrote:
> Galen Boyer <···········@yahoo.com> writes:
>
>> On Thu, 27 Apr 2006, ···········@gmail.com wrote:
>>
>>> You seem to confuse user friendliness with reduced functionality :
>>> this is only the case when "stupid" people implement the user
>>> friendliness.
>>
>> So, is your point that the Emacs developers are stupid people?
>>
>> --
>> Galen Boyer
>
> Most certainly not : I seem to recall that it was you accusing people
> who wanted an app to be user friendly as "stupid".
You are completely mistaken.
> My last line was taking a swipe at your inability to accept that
> things can be highly functional and user friendly - and this is even
> without taking emacs into account.
When did I ever say that the two things were mutually exclusive?
> I disagree strongly with your assertion that "user friendly apps
> are for stupid people".
When did I say this?
> Emacs doesnt strive for user friendliness : is strives for power.
I would disagree. It strives for a "perfect" experience, which is a
blend of both.
> Most things it does are for a reason - my point is that its not
> necessrily "obvious" how to best use it - even for "non stupid"
> people.
Yes, this is true.
--
Galen Boyer
Galen Boyer <···········@yahoo.com> writes:
> On Thu, 27 Apr 2006, ···········@gmail.com wrote:
>> Galen Boyer <···········@yahoo.com> writes:
>>
>>> On Thu, 27 Apr 2006, ···········@gmail.com wrote:
>>>
>>>> You seem to confuse user friendliness with reduced functionality :
>>>> this is only the case when "stupid" people implement the user
>>>> friendliness.
>>>
>>> So, is your point that the Emacs developers are stupid people?
>>>
>>> --
>>> Galen Boyer
>>
>> Most certainly not : I seem to recall that it was you accusing people
>> who wanted an app to be user friendly as "stupid".
>
> You are completely mistaken.
>
>> My last line was taking a swipe at your inability to accept that
>> things can be highly functional and user friendly - and this is even
>> without taking emacs into account.
>
> When did I ever say that the two things were mutually exclusive?
>
My news server wont restore to past thread : if I am mistaken then I
apologise.
>
> I would disagree. It strives for a "perfect" experience, which is a
> blend of both.
Since perfection is different for different people then I would disagree
here. It strives for power : and gives the ability to customise through
groups and lisp.
>
>> Most things it does are for a reason - my point is that its not
>> necessrily "obvious" how to best use it - even for "non stupid"
>> people.
>
> Yes, this is true.
>
> --
> Galen Boyer
--
lithp : syntax error
From: Hadron Quark
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <hvc1i3-lh9.ln1@l.h.c>
········@at.BioStrategist.dot.dot.com"posted on 2006-04-25:
> The thing about emacs is you can work at speed-of-thought.
>
> Too many Windows apps are dumbed down.
>
> User friendly is for stupid users.
I dont think I ever read such a dumb defence.
1) emacs is a windows app too.
2) loads of linux apps are "dumbed down too".
3) there are loads of windows apps which are not dumbed down.
and as for "user friendly is for stupid users" : well,I dont think I
really need to comment.
emacs is a great piece of SW but to be blind to the learning hurdle
required is plain "dumb" :) ...
>
>
>
> - = -
> Vasos-Peter John Panagiotopoulos II, Reagan Mozart Pindus BioStrategist
> http://ourworld.compuserve.com/homepages/vjp2/vasos.htm
> ---{Nothing herein constitutes advice. Everything fully disclaimed.}---
> [Ignore http://lynx.browser.org/ noncompliant web sites]
> [Regulation begets corruption] [Urb Sprawl confounds terror]
> [Homeland Security means private firearms not lazy obstructive guards]
>
--
%
+ Hadron Quark <···········@gmail.com>:
| emacs is a great piece of SW but to be blind to the learning hurdle
| required is plain "dumb" :) ...
If you really need the power of emacs, then the time spent learning it
is worthwhile. If not, well there are simpler editors. I am all for
making emacs easier to learn, but not if it makes it harder to use.
An excellent example is disabled commands: This stops newbies from
getting hopelessly confused, while experienced hands just enable the
commands and get on with their work.
--
* 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
From: Fredrik Bulow
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <87psj5klgn.fsf@gmail.com>
Someone was complaining to me a while a go that emacs is stuck with
old and bad names. He tought that kill sounds like "dead for ever" and
shouldn't be used for "cut & paste". Therefor I think everyone should
have the following line in their .emacs.
(fset 'revive 'yank)
/Fredrik
In article <··············@l.h.c>, Hadron Quark <···········@gmail.com> wrote:
> "Galen"posted on 2006-04-25:
>
>emacs is great : but lets never think its easy :) Like everything its
>easy when you know how : and that "when you know how" is, in my
>experience, the stumbling block to many people embracing emacs with
>the love and attention that it deserves.
I learned enough to be able to edit with it via
the rms-"TUTORIAL": "C-h t".
That was sufficient, that essential 1% of emacs.
David
From: Galen Boyer
Subject: Re: the Modernization of Emacs
Date:
Message-ID: <u64jxe8xg.fsf@rcn.com>
On Mon, 22 May 2006, ·······@panix.com wrote:
> In article <··············@l.h.c>, Hadron Quark
> <···········@gmail.com> wrote:
>> "Galen"posted on 2006-04-25:
>>
>>emacs is great : but lets never think its easy :) Like everything its
>>easy when you know how : and that "when you know how" is, in my
>>experience, the stumbling block to many people embracing emacs with
>>the love and attention that it deserves.
>
> I learned enough to be able to edit with it via
> the rms-"TUTORIAL": "C-h t".
>
> That was sufficient, that essential 1% of emacs.
Yes. But most Emacs users I know don't know how to get Emacs to teach
them Emacs. Thats really the big leap one needs to take. Take the time
to learn how to ask Emacs questions and you will have no problem
learning Emacs.
--
Galen Boyer
Folks,
Please consider this, and talk to emacs developers about it.
If emacs do these things, perhaps emacs's user base will increase 5
fold in the next couple of years. Emacs oldtimers and elisp hackers
wouldn't have to change their working habits a bit. And, the increased
user base will be tremendous help in the continued emacs development
and growth.
Xah
···@xahlee.org
∑ http://xahlee.org/
Xah Lee wrote:
> 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.
>
> 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.
Why should we "consider" this when setting up your idiosyncratic
preferences is a trivial matter of modifying your own .emacs file?
And where is the data to back up your "5 fold" increase?
Gregm
"Xah Lee" <···@xahlee.org> writes:
> Folks,
>
> Please consider this, and talk to emacs developers about it.
>
> If emacs do these things, perhaps emacs's user base will increase 5
> fold in the next couple of years. Emacs oldtimers and elisp hackers
> wouldn't have to change their working habits a bit. And, the increased
> user base will be tremendous help in the continued emacs development
> and growth.
>
> Xah
> ···@xahlee.org
> ∑ http://xahlee.org/
>
>
> Xah Lee wrote:
> > 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.
> >
> > 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.
Greg Menke wrote:
> Why should we "consider" this when setting up your idiosyncratic
> preferences is a trivial matter of modifying your own .emacs file?
The problem is the default themselves being inappropriate. An
experienced user can easily change the default once they are
experienced. The problem is the unusable defaults presented to the new
user, who by virtue of being a beginner is unable to change them.
In this I agree with Xah, though I disagree with some of the things he
thinks need changing.
> And where is the data to back up your "5 fold" increase?
I don't think it would help that much either.
"Rob Thorpe" <·············@antenova.com> writes:
> Greg Menke wrote:
> > Why should we "consider" this when setting up your idiosyncratic
> > preferences is a trivial matter of modifying your own .emacs file?
>
> The problem is the default themselves being inappropriate. An
> experienced user can easily change the default once they are
> experienced. The problem is the unusable defaults presented to the new
> user, who by virtue of being a beginner is unable to change them.
Then Xah should feel free to set up his own bizarre Emacs configuration,
publish it on the web and be the savior of emacs newbies everywhere. I
fail to see why his issues require work on anyone else's part.
Greg
Greg Menke <·············@toadmail.com> writes:
> "Rob Thorpe" <·············@antenova.com> writes:
>
>> Greg Menke wrote:
>> > Why should we "consider" this when setting up your idiosyncratic
>> > preferences is a trivial matter of modifying your own .emacs file?
>>
>> The problem is the default themselves being inappropriate. An
>> experienced user can easily change the default once they are
>> experienced. The problem is the unusable defaults presented to the new
>> user, who by virtue of being a beginner is unable to change them.
>
> Then Xah should feel free to set up his own bizarre Emacs configuration,
> publish it on the web and be the savior of emacs newbies everywhere. I
> fail to see why his issues require work on anyone else's part.
>
Exactly. In fact, there are already packages out there which will
change the default configuration to something someone else believes is
better for beginners - I think there is a package called something
like easymacs or something similar which tries to do exactly that.
What gets on my nerves about Xah's posting is that all he does is
complain about how bad things are, but doesn't actually make any real
contribution. As you say, he should make the changes and then just
publish them.
Tim
--
tcross (at) rapttech dot com dot au
Tim X wrote:
> Greg Menke <·············@toadmail.com> writes:
>
> > "Rob Thorpe" <·············@antenova.com> writes:
> >
> >> Greg Menke wrote:
> >> > Why should we "consider" this when setting up your idiosyncratic
> >> > preferences is a trivial matter of modifying your own .emacs file?
> >>
> >> The problem is the default themselves being inappropriate. An
> >> experienced user can easily change the default once they are
> >> experienced. The problem is the unusable defaults presented to the new
> >> user, who by virtue of being a beginner is unable to change them.
> >
> > Then Xah should feel free to set up his own bizarre Emacs configuration,
> > publish it on the web and be the savior of emacs newbies everywhere. I
> > fail to see why his issues require work on anyone else's part.
> >
>
> Exactly. In fact, there are already packages out there which will
> change the default configuration to something someone else believes is
> better for beginners - I think there is a package called something
> like easymacs or something similar which tries to do exactly that.
There is, but the problem is that it is very unlikely that beginners
will look for or find such a thing. When I started using Emacs it
didn't even occur to me that there was a version hanging around with an
easier setup (and at the time there wasn't).
Beginners are much more likely (probably by a factor of >100) to have
heard of Emacs than of Easymacs. So most of them will never find the
version setup for them.
(Even if they are aware of it they may well reject it. How many times
have you seen a programmer attempt to learn a version of a program
specifically setup for beginners. Normally programmers avoid things
like that, seeing them as insulting their intelligence, even if they
aren't.)
> What gets on my nerves about Xah's posting is that all he does is
> complain about how bad things are, but doesn't actually make any real
> contribution. As you say, he should make the changes and then just
> publish them.
Yes, that would certainly be useful.
"Rob Thorpe" <·············@antenova.com> writes:
> Tim X wrote:
> > Greg Menke <·············@toadmail.com> writes:
> >
> > > "Rob Thorpe" <·············@antenova.com> writes:
> > >
> > >> Greg Menke wrote:
> > >> > Why should we "consider" this when setting up your idiosyncratic
> > >> > preferences is a trivial matter of modifying your own .emacs file?
> > >>
> > >> The problem is the default themselves being inappropriate. An
> > >> experienced user can easily change the default once they are
> > >> experienced. The problem is the unusable defaults presented to the new
> > >> user, who by virtue of being a beginner is unable to change them.
> > >
> > > Then Xah should feel free to set up his own bizarre Emacs configuration,
> > > publish it on the web and be the savior of emacs newbies everywhere. I
> > > fail to see why his issues require work on anyone else's part.
> > >
> >
> > Exactly. In fact, there are already packages out there which will
> > change the default configuration to something someone else believes is
> > better for beginners - I think there is a package called something
> > like easymacs or something similar which tries to do exactly that.
>
> There is, but the problem is that it is very unlikely that beginners
> will look for or find such a thing. When I started using Emacs it
> didn't even occur to me that there was a version hanging around with an
> easier setup (and at the time there wasn't).
Then Xah should make his super-duper-newbie-helper emacs mode and lobby
to get it put into the emacs distro, with obvious newbie-apparent links
in the Scratch buffer for example. If its as useful as he says it is
then it would be widely popular.
> Beginners are much more likely (probably by a factor of >100) to have
> heard of Emacs than of Easymacs. So most of them will never find the
> version setup for them.
Lots of newbies look at the help document a few times, a link to
"Xahmacs" mode would be appropriate there. Its entirely up to Xah, not
the emacs community.
> (Even if they are aware of it they may well reject it. How many times
> have you seen a programmer attempt to learn a version of a program
> specifically setup for beginners. Normally programmers avoid things
> like that, seeing them as insulting their intelligence, even if they
> aren't.)
>
Newbie modes aren't an insult to intelligence, they're just inefficient.
Newbie mode is supposed to be that way so the basics can be learned.
Once thats achieved, then the users moves more efficient modes if
they're interested in learning & efficiency- otherwise they stay in
newbie mode.
Gregm
Keyboard shortcuts and other enhancements have been done to Aquamacs.
It's main focus is to modify emacs to conform to apple's human
interface guidelines. See http://www.aquamacs.org
Some Notes about Terminology
The terminology “buffer” or “keybinding”, are technical terms
having to do with software programing. The term “keybinding” refers
to the association of a keystroke with a command in a technical,
software application programing context. That is to say, one “bind”
a keystroke to a command in a application framework. The term
“buffer” refers to a temporary abstract area for storing data, in
the context of programing or computer science.
These terms are irrelevant to the users of a software application.
As a user of a text editor, he works with files. The terms “opened
file” or “untitled file” are more appropriate than “buffer”.
Since emacs is also used for many things beside files, for example,
file management, ftp/sftp, shell, email, irc etc., the proper term can
be “work area”, “work space”, or simply “window”.
And, the term “keyboard shortcut” refers to typing of a
key-combination to activate a command. It is also more appropriate than
“binding” or “keybinding”.
Adapting these terms will not only increase emacs popularity, but are
in fact more correct if we really want to tech geek about it.
----
This post is archived at:
http://xahlee.org/emacs/modernization.html
Xah
···@xahlee.org
∑ http://xahlee.org/
"Xah Lee" <···@xahlee.org> writes:
> Adapting these terms will not only increase emacs popularity, but are
> in fact more correct if we really want to tech geek about it.
You're deluding yourself Xah.
-Miles
--
We live, as we dream -- alone....
Some entity AKA Alan Mackenzie <···@muc.de>
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> Anyhow, congratulations on starting a thread which has gone on to 150
> articles. :-)
ah, well it's a holyday-weekend, so why not have a little fun.
For there can't hardly be anything more usefull to do except chasing
easter-bunnies anyway.
Cor
--
I do NOT use any Windows(TM) products, therefore
I do NOT fear mail from strangers http://www.clsnet.nl/mail.html
If everything else failed to satisfy you, try reading The Frign' Manual
(defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
Cor Gest wrote:
> Some entity AKA Alan Mackenzie <···@muc.de>
> wrote this mindboggling stuff:
>
> (selectively-snipped-or-not-p)
>
> > Anyhow, congratulations on starting a thread which has gone on to 150
> > articles. :-)
>
> ah, well it's a holyday-weekend, so why not have a little fun.
> For there can't hardly be anything more usefull to do except chasing
> easter-bunnies anyway.
>
> Cor
>
>
> --
> I do NOT use any Windows(TM) products, therefore
> I do NOT fear mail from strangers http://www.clsnet.nl/mail.html
> If everything else failed to satisfy you, try reading The Frign' Manual
> (defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
Don't compare unix to Windows. That's not fair.
Don't compare emacs to notepad. That's completly mad!
I'm using emacs for 2 years and I'm programming since 2 years.
I'm very pleased by the status-quo! Thank you!
Common User Access (CUA) is a set of guidelines for the user interface
to personal computer operating systems and computer programs, developed
by IBM starting in 1987 as part of their Systems Application
Architecture. Used originally in the OS/2 and Microsoft Windows
operating systems, parts of the CUA standard are now implemented in
programs for other operating systems, including Mac OS X and Unix and
in Java AWT and Swing.
The CUA contains standards for the operation of dialog boxes, menus and
keyboard shortcuts that have become so influential that they are
implemented today by many programmers who have never read the CUA.
Some of these standards can be seen in the operation of Windows itself
and DOS-based applications like the MS-DOS 5 full-screen text editor
EDIT. CUA hallmarks include:
* A menu bar across the top of the window;
* All operations could be done with either the mouse or the
keyboard;
* Menus opened by pressing the Alt key plus the underlined letter
of the menu name; alt on its own activated the menu bar;
* Menu commands which require further information are indicated by
a suffixed ellipsis ("...");
* Options are requested using dialog boxes;
* Navigation within fields in dialog boxes is by cursor key;
navigation between fields is by pressing [Tab] or [Shift]+[Tab] to go
backwards;
* Dialog boxes should have a "Cancel" button, activated by pressing
the [Esc] key, which discards changes, and an "OK" button, activated by
pressing [Return];
* The program should have online help, with a Help menu as the last
option on the menu bar; context-sensitive help should be summoned by
pressing the [F1] function key;
* The first menu should be called "File" and contain operations for
handling files, quitting the program and so on; the next is called
"Edit" and contains cut, copy, paste commands; the next is "View";
* The Cut command is [Shift]+[Del]; Copy is [Ctrl]+[Ins]; Paste is
[Shift]+[Ins];
* The size of a window can be changed with by dragging one of the
8-segments of the border.
CUA was a detailed specification and set strict rules about how
applications should look and function. Its aim was in part to bring
about harmony between MS-DOS applications, which until then had
implemented totally different user interfaces.
Examples:
* In WordPerfect, the command to open a file was [F7], [3].
* In Lotus 1-2-3, a file was opened with [/] (to open the menus),
[W] (for Workspace), [R] (for Retrieve).
* In Microsoft Word, a file was opened with [Esc] (to open the
menus), [T] (for Transfer), [L] (for Load).
* In WordStar, it was [Ctrl]+[K]+[O].
Some programs used [Esc] to cancel an action, some used it to complete
one; WordPerfect used it to repeat a character. Some programs used
[End] to go to the end of a line, some used it to complete filling in a
form. [F1] was often help but in WordPerfect that was [F3]. [Ins]
sometimes toggled between overtype and inserting characters, but some
programs used it for "paste".
Thus, every program had to be learned individually and its complete
user interface memorized. It was a sign of expertise to have learned
the UIs of dozens of applications, since a novice user facing a new
program would find their existing knowledge of a similar application
absolutely no use whatsoever.
This detailed specification drew some of its inspiration from Apple
Computer's lavishly detailed Human Interface Guidelines. The Apple HIG
is a detailed book specifying exactly how software for the Apple
Macintosh computer should look and function. When it was first written,
the Mac was new and GUI software was a novelty, so Apple took great
pains to ensure that programs would conform to a single shared look and
feel. CUA had a similar aim, but faced the more difficult task of
trying to impose this retroactively on an existing, thriving but
chaotic industry.
However, CUA did not only cover DOS applications; it was also the
standard to which the user interface of Windows was designed, as well
as that for OS/2 applications - both text-mode and the Presentation
Manager GUI - and IBM mainframes which conformed to the Systems
Application Architecture. Thus CUA was more than just an attempt to
rationalise DOS applications - it was part of a larger scheme to bring
together, rationalise and harmonize the overall functions of software
across IBM's entire computing range, from microcomputers to mainframes,
their UIs, functioning, communications and storage protocols. As this
encompassed PCs and compatibles, it extended to the entire PC industry
- which is perhaps part of the reason it was not completely successful.
The third edition of CUA took a radical departure from the first two by
introducing the object-oriented workplace. This changed the emphasis of
the users interactions to be the data (documents, pictures, and so on)
that the user worked on. The emphasis on applications was removed with
the intention of making it much easier to use than other systems.
The workplace was adopted by Microsoft in the 1995 version of Windows.
Critically the Start menu was introduced which removed the emphasis on
an object-oriented desktop.
-----------------
The above is from
http://en.wikipedia.org/wiki/Common_User_Access
And it is of interest.
Xah
···@xahlee.org
∑ http://xahlee.org/
"Xah Lee" <···@xahlee.org> writes:
> And it is of interest.
Not really.
-miles
--
Next to fried food, the South has suffered most from oratory.
-- Walter Hines Page