[this post is a excerpt from
The Modernization of Emacs, Xah Lee, 2006-04 at
http://xahlee.org/emacs/modernization.html
]
The Modernization of Emacs
----------------------------------------
THE PROBLEM
Emacs is a great editor. It is perhaps the most powerful and most
versatile text editor. And, besides text editing, it also serves as a
email application, newsgroup application, ftp application, irc
application, web browser, shell interface, file management
application, programable calculator, calendar and personal info
management application, lisp language system, among other things.
These seemingly wild functionalities are employed in production daily
by a significant number of programers around the world. Some calls
emacs as a Operating System as a joke. (Technically it does not
qualify because a OS implies management of hardware.).
If emacs is such a great and powerful text editor why almost nobody
knows about it? Vast majority of people who need to write will be more
than happy to use editors other than emacs. Ask a Microsoft Windows
user. She'll be more than happy to use Microsoft Word↗. If he doesn't
have MS Word, he'll use NotePad↗ or WordPad↗. If he is a programer,
most will be more than happy to use any of other graphical editors on
the Windows platform or any of the Integrated development
environment↗. Same is true on other operating systems, and new editors
spring up here and there even though they don't have as much power or
flexibility as emacs. For example, there are NEdit, JEdit, Eclipse,
Xcode↗ , or the various associated with languages or third party
language software, such as Visual Basic or Borland C++.
Many reasons can be made out of this. For example, emacs is not
bundled on popular operating systems such as Windows or Mac, which are
used by some 99% of computer users worldwide. Windows and Mac both
have simple text editors bundled that will satisfy majority of
computer users, which are non-professional computer users. (NotePad
and WordPad on Windows, TextEdit↗ on Mac) For the few professional
computer users, a majority will need a easy to use, yet powerful
editor that also does styled text, formatting, and sundry light
publishing needs such as table layout, simple line graphics drawing,
embedded images, math formulas. They will choose and adopt Microsoft
Word for their needs. The tiny percentage that might be interested in
emacs, are programers. Even among professional programers, a majority
shy away from emacs.
A major difficulty among programers who do not use or like emacs, is
that emacs's user interface is rather esoteric, involving arcane
terminologies and keystrokes. This is in sharp contrast to the
thousands of software applications used today, where their User
Interface are similar and familiar to today's computer users.
----------------------------------------
THE COMMON USER INTERFACE
The following is a excerpt from the Wikipedia article on Common User
Access↗:
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].
* In Emacs, a file was opened with [Ctrl]+[x] followed by [Ctrl]+
[f] (for find-file).
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.
----------------------------------------
SIMPLE CHANGES
In the following, i describe some critical changes that are also very
easy to fix in emacs. If emacs officially adopt these changes, i think
it will make a lot people, at least programers, like emacs and choose
emacs as their text editor.
* Change the keyboard shortcut of Copy & Paste to ctrl-c and ctrl-
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.
* Change the terminology of “kill” to “cut”, and “yank” to
“paste”.
* Change the terminology of Meta key to Alt.
* 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/
Ever came to your mind that there are people (programmers and others)
who will not use emacs for their day-to-day work simply because they
have tools that suit them better for the work they have to do (Eclipse
for me, as an example)?
Except from that: I personally don't feel that your rantings are
interesting enough to qualify for a 4 groups X-post ... this sort of
article goes well into a blog, but not so much on programmers
newsgroups (which are used for Q&A imho).
On Jun 17, 6:46 pm, Philipp Leitner <···············@gmx.at> wrote:
> Ever came to your mind that there are people (programmers and others)
> who will not use emacs for their day-to-day work simply because they
> have tools that suit them better for the work they have to do (Eclipse
> for me, as an example)?
>
> Except from that: I personally don't feel that your rantings are
> interesting enough to qualify for a 4 groups X-post ... this sort of
> article goes well into a blog, but not so much on programmers
> newsgroups (which are used for Q&A imho).
You must be new here. Xah is a well-known self-important troll,
crossposting his mostly off-topic and/or controversial ramblings and
showing off his ignorance in a provocative condescending manner. Don't
waste resources by replying, he rarely follows up anyway.
For the love of dogs, Xah, try to keep up. Aquamacs is an Emacs
distribution that, which not there yet, is at least half way between
"classic" Emacs and a modern Mac UI. You sound ridiculous, like if
you were complaining about Windows not being really graphical, based
on experience with Windows-386 in the era when 95 was already around.
On Jun 17, 5:13 pm, Xah Lee <····@xahlee.org> wrote:
> [this post is a excerpt from
> The Modernization of Emacs, Xah Lee, 2006-04 athttp://xahlee.org/emacs/modernization.html
> ]
>
> The Modernization of Emacs
>
> ----------------------------------------
> THE PROBLEM
>
> Emacs is a great editor. It is perhaps the most powerful and most
> versatile text editor. And, besides text editing, it also serves as a
> email application, newsgroup application, ftp application, irc
> application, web browser, shell interface, file management
> application, programable calculator, calendar and personal info
> management application, lisp language system, among other things.
> These seemingly wild functionalities are employed in production daily
> by a significant number of programers around the world. Some calls
> emacs as a Operating System as a joke. (Technically it does not
> qualify because a OS implies management of hardware.).
>
> If emacs is such a great and powerful text editor why almost nobody
> knows about it? Vast majority of people who need to write will be more
> than happy to use editors other than emacs. Ask a Microsoft Windows
> user. She'll be more than happy to use Microsoft Word↗. If he doesn't
> have MS Word, he'll use NotePad↗ or WordPad↗. If he is a programer,
> most will be more than happy to use any of other graphical editors on
> the Windows platform or any of the Integrated development
> environment↗. Same is true on other operating systems, and new editors
> spring up here and there even though they don't have as much power or
> flexibility as emacs. For example, there are NEdit, JEdit, Eclipse,
> Xcode↗ , or the various associated with languages or third party
> language software, such as Visual Basic or Borland C++.
>
> Many reasons can be made out of this. For example, emacs is not
> bundled on popular operating systems such as Windows or Mac, which are
> used by some 99% of computer users worldwide. Windows and Mac both
> have simple text editors bundled that will satisfy majority of
> computer users, which are non-professional computer users. (NotePad
> and WordPad on Windows, TextEdit↗ on Mac) For the few professional
> computer users, a majority will need a easy to use, yet powerful
> editor that also does styled text, formatting, and sundry light
> publishing needs such as table layout, simple line graphics drawing,
> embedded images, math formulas. They will choose and adopt Microsoft
> Word for their needs. The tiny percentage that might be interested in
> emacs, are programers. Even among professional programers, a majority
> shy away from emacs.
>
> A major difficulty among programers who do not use or like emacs, is
> that emacs's user interface is rather esoteric, involving arcane
> terminologies and keystrokes. This is in sharp contrast to the
> thousands of software applications used today, where their User
> Interface are similar and familiar to today's computer users.
>
> ----------------------------------------
> THE COMMON USER INTERFACE
>
> The following is a excerpt from the Wikipedia article on Common User
> Access↗:
>
> 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].
>
> * In Emacs, a file was opened with [Ctrl]+[x] followed by [Ctrl]+
> [f] (for find-file).
>
> 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.
>
> ----------------------------------------
> SIMPLE CHANGES
>
> In the following, i describe some critical changes that are also very
> easy to fix in emacs. If emacs officially adopt these changes, i think
> it will make a lot people, at least programers, like emacs and choose
> emacs as their text editor.
>
> * Change the keyboard shortcut of Copy & Paste to ctrl-c and ctrl-
> 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.
>
> * Change the terminology of “kill” to “cut”, and “yank” to
> “paste”.
>
> * Change the terminology of Meta key to Alt.
>
> * 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/
On 17 ���, 19:13, Xah Lee <····@xahlee.org> wrote:
> In the following, i describe some critical changes that are also very
> easy to fix in emacs. If emacs officially adopt these changes, i think
> it will make a lot people, at least programers, like emacs and choose
> emacs as their text editor.
>
> * Change the keyboard shortcut of Copy & Paste to ctrl-c and ctrl-
> v as to be the same with all modern applications.
>
There is a CUA-mode.
> * Get rid of the *scratch* buffer.
>
I agree that it should be off by default. I hope that only a minority
of emacs users are emacs developers ;-)
> * Change the terminology of "kill" to "cut", and "yank" to
> "paste".
>
In my emacs 21 in menu it says just that.
> * Change the terminology of Meta key to Alt.
>
I guess emacs is not for PC only...
> * Make longlines-mode the default editor behavior for any file.
>
This is doubtful, but I agree that all modes (LaTeX etc) should at
least work correctly with longlines mode.
> * 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.
>
For me it opens R files with proper highlighting out-of-the-box -_-;
> * Reduce the use of the word "buffer" in the emacs documentation.
> Call it "opened file" or "unsaved document".
>
As far as I understand the concept of buffer is much much wider than
of "unsaved document" or "file". Should we call dired buffer as
"unsaved document"?
> Xah
> ····@xahlee.org
> http://xahlee.org/
>
> > * Reduce the use of the word "buffer" in the emacs documentation.
> > Call it "opened file" or "unsaved document".
>
> As far as I understand the concept of buffer is much much wider than
> of "unsaved document" or "file". Should we call dired buffer as
> "unsaved document"?
>
It is much wider, which is why it was used in the first place.
Considering most of Xah's article, I think an animated paperclip
(maybe in ASCII art) should be the top priority for emacs developers.
This would be an important step in modernizing emacs.
Leaving this aside, I'm also taking a wild guess that some *nices (not
just Linux distros, but also *BSD, Solaris etc.) could well provide a
binary package of emacs compiled with its GTK UI, besides those
they're already providing (nox and the ugly one for X). It's a fair
assumption to consider that not anyone has GTK, but it's common enough
to provide an alternative to that stumpy Xlib-based (I think :-\) UI
that's default in just about every binary package around. It's not
just that it looks ugly, it's also somewhat awkward at times.
Xah Lee <···@xahlee.org> writes:
> ----------------------------------------
> SIMPLE CHANGES
>
> In the following, i describe some critical changes that are also very
> easy to fix in emacs. If emacs officially adopt these changes, i think
> it will make a lot people, at least programers, like emacs and choose
> emacs as their text editor.
The problem with this line of thinking is that it aims to make Emacs
appeal to people -- I think it is rather the other way around.
Certain people appeal to Emacs: certain kinds of people like Emacs
and the way it is set up, and they change it to suit their needs.
Among your changes, I found none that made sense to me, a person who
used Unix before Windows became widely used. For people like me, who
always preferred Unix, changes like changing "buffer" to "opened file"
seem inefficient and unnecessary.
Sorry -- this totally falls flat. It won't make Emacs more widely
used. The only thing that will make Emacs more widely used is making
people aware of it; as soon as I became aware of Emacs (from reading
Wikipedia, ironically), I began using it and I knew I was stuck with
it. It's not even important for the survival of Emacs that it be more
widely used -- it was never important in the last thirty years of its
history, why should it be important now that Microsoft Word is so
widely used?
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
Joel J. Adamson wrote:
> Xah Lee <···@xahlee.org> writes:
>
>> ----------------------------------------
>> SIMPLE CHANGES
>>
>> In the following, i describe some critical changes that are also very
>> easy to fix in emacs. If emacs officially adopt these changes, i think
>> it will make a lot people, at least programers, like emacs and choose
>> emacs as their text editor.
>
> The problem with this line of thinking is that it aims to make Emacs
> appeal to people -- I think it is rather the other way around.
> Certain people appeal to Emacs: certain kinds of people like Emacs
> and the way it is set up, and they change it to suit their needs.
I worked for years as a special ed teacher and I learned that people have
different learning styles. It's not just learning, but it's perceiving and
working as well. Some people will always do better with a command line and
some will always do better with a GUI with point-and-click. That doesn't
mean one is smarter than the other or one is a true geek and one isn't.
It's just the way our brains are wired.
Emacs appeals to the type of personality that is often a hard core
programmer. It works for those that want to customize everything and have
full control over their environment AND do well with a command line rather
than a more visual and graphic environment. For those, emacs is probably
the best program for them.
Some people prefer to drive a Miata and some prefer a Dodge Ram. One isn't
better than the other, they're just different. Trying to make a Dodge Ram
look like a convertible so Miata lovers will want to use it is a waste.
It'll never be a Miata and the more people try to make it adaptable so it
can be one, the more they ruin what's special about it.
The more emacs is adapted for the non-technical, the more it'll lose what
makes it special and a good fit for programmers.
> Among your changes, I found none that made sense to me, a person who
> used Unix before Windows became widely used. For people like me, who
> always preferred Unix, changes like changing "buffer" to "opened file"
> seem inefficient and unnecessary.
It seems to me that is the kind of person emacs is written for. What will
it gain if a large number of non-technical people start using it in
a "non-emacs" mode?
> Sorry -- this totally falls flat. It won't make Emacs more widely
> used. The only thing that will make Emacs more widely used is making
> people aware of it; as soon as I became aware of Emacs (from reading
> Wikipedia, ironically), I began using it and I knew I was stuck with
> it. It's not even important for the survival of Emacs that it be more
> widely used -- it was never important in the last thirty years of its
> history, why should it be important now that Microsoft Word is so
> widely used?
Let those who need Word use it. To try to change emacs into something it
isn't is ignoring what makes it special.
Hal
From: Galen Boyer
Subject: Re: The Modernization of Emacs
Date:
Message-ID: <u7iq0vbi8.fsf@rcn.com>
On Mon, 18 Jun 2007, ········@partners.org wrote:
> The problem with this line of thinking is that it aims to make Emacs
> appeal to people -- I think it is rather the other way around.
> Certain people appeal to Emacs: certain kinds of people like Emacs
> and the way it is set up, and they change it to suit their needs.
Emacs will always be for people who like to be able to constantly fiddle
with their environments which continues to increase the efficiency with
which they perform their tasks, increasing the # of tasks they can
perform and therefore increasing the # of peers it would take to equal
the amount of work they alone perform. Most other environments will be
for those just trying to perform their tasks and staying even with the
average proficiency chart.
--
Galen Boyer
Galen Boyer <···········@yahoo.com> writes:
> On Mon, 18 Jun 2007, ········@partners.org wrote:
>
> > The problem with this line of thinking is that it aims to make Emacs
> > appeal to people -- I think it is rather the other way around.
> > Certain people appeal to Emacs: certain kinds of people like Emacs
> > and the way it is set up, and they change it to suit their needs.
>
> Emacs will always be for people who like to be able to constantly fiddle
> with their environments which continues to increase the efficiency with
> which they perform their tasks, increasing the # of tasks they can
> perform and therefore increasing the # of peers it would take to equal
> the amount of work they alone perform. Most other environments will be
> for those just trying to perform their tasks and staying even with the
> average proficiency chart.
>
> --
> Galen Boyer
"constantly fiddle"
I've used emacs since the 1980's. I've used it for text, xml, html
markups, programming in many languages, and natural languages. In a
few cases I've "fiddled" with the environment. I've even written a
"mode". But it has never been "constantly". One does the setup, and
then uses it day after day, year after year... until you have a new
need, in which case you re-tune your settings and then go back to
work.
"trying to perform their tasks...average proficiency"
Aye, there's the rub. As Fred Brooks and others repeatedly point out,
there is little room in programming for average proficiency.
I don't mind folks using any editor they want, as long as they are
proficient. In those cases, I have no problem doing Extreme
Programming with them -- code a bit, save, the other guy codes a bit.
But when someone uses vi and then forgets how to do block moves, or
uses eclipse and bogs down the session, or uses MS Notepad and can't
enforce language-specific indents, I get frustrated.
--
Harry George
PLM Engineering Architecture
On 19 Juni, 07:14, Harry George
>
> I've used emacs since the 1980's.
...
> --
> Harry George
> PLM Engineering Architecture
I've asked this question on an emacs forum and got no response, so I
presume the answer is no, but I see, Harry, that you're a veteran, so
maybe you've seen things few others have.
Have you ever seen an, "Extract method," function for emacs? Whereby
you highlight some lines of code, press a key, and the code is whisked
into its own method, with the appropriate method invocation left in
its place. If you could post a link, that'd be just champion.
.ed
--
www.EdmundKirwan.com - Home of The Fractal Class Composition
Ed wrote:
> On 19 Juni, 07:14, Harry George
>> I've used emacs since the 1980's.
> ...
>> --
>> Harry George
>> PLM Engineering Architecture
>
> I've asked this question on an emacs forum and got no response, so I
> presume the answer is no, but I see, Harry, that you're a veteran, so
> maybe you've seen things few others have.
>
> Have you ever seen an, "Extract method," function for emacs? Whereby
> you highlight some lines of code, press a key, and the code is whisked
> into its own method, with the appropriate method invocation left in
> its place. If you could post a link, that'd be just champion.
I googled about a bit and came up with
<http://bicyclerepair.sourceforge.net/>
linked from
<http://en.wikipedia.org/wiki/Refactoring>
I also looked at emacs's own "Info" pages and found this tidbit:
> `M-x c-beginning-of-defun'
> `M-x c-end-of-defun'
> Move point to the beginning or end of the current function or
> top-level definition. These are found by searching for the least
> enclosing braces. (By contrast, `beginning-of-defun' and
> `end-of-defun' search for braces in column zero.) If you are
> editing code where the opening brace of a function isn't placed in
> column zero, you may wish to bind `C-M-a' and `C-M-e' to these
> commands. *Note Moving by Defuns::.
>
> `M-a'
> Move point to the beginning of the innermost C statement
> (`c-beginning-of-statement'). If point is already at the beginning
> of a statement, move to the beginning of the preceding statement.
> With prefix argument N, move back N - 1 statements.
>
> In comments or in strings which span more than one line, this
> command moves by sentences instead of statements.
>
> `M-e'
> Move point to the end of the innermost C statement or sentence;
> like `M-a' except that it moves in the other direction
> (`c-end-of-statement').
You could, and I believe others have, create a macro to encapsulate these
actions with setting the mark and copying the region.
Here is a very promising-looking one that I found for C(**) and Java:
<http://xref-tech.com/speller/main.html>
GWMF.
--
Lew
On Jun 19, 9:21 pm, Ed <··········@hotmail.com> wrote:
>
> Have you ever seen an, "Extractmethod," function for emacs? Whereby
> you highlight some lines of code, press a key, and the code is whisked
> into its ownmethod, with the appropriatemethodinvocation left in
> its place. If you could post a link, that'd be just champion.
xrefactory does this. I tried it once. It's a bit pricey , though.
Thanks, all, for the answers.
But, Lew: GWMF?
- Gardner Winter Music Festival? (You have to love the black'n'white
photo on the right at: http://www.gwmf.org/)
- Generalized Whitening-Matched Filter?
- http://www.gwmf.com/ ?
- http://www.gwmf.de/host/ ?
- http://www.goatworld.com/gwmf.shtml ????
.ed
--
www.EdmundKirwan.com - Home of The Fractal Class Composition
Ed wrote:
> Thanks, all, for the answers.
>
> But, Lew: GWMF?
>
> - Gardner Winter Music Festival? (You have to love the black'n'white
> photo on the right at: http://www.gwmf.org/)
>
> - Generalized Whitening-Matched Filter?
>
> - http://www.gwmf.com/ ?
>
> - http://www.gwmf.de/host/ ?
>
> - http://www.goatworld.com/gwmf.shtml ????
Google was my friend.
--
Lew
On Jun 20, 1:59 am, ··················@gmail.com"
<·················@gmail.com> wrote:
> On Jun 19, 9:21 pm, Ed <··········@hotmail.com> wrote:
>
> > Have you ever seen an, "Extractmethod," function for emacs? Whereby
> > you highlight some lines of code, press a key, and the code is whisked
> > into its ownmethod, with the appropriatemethodinvocation left in
> > its place. If you could post a link, that'd be just champion.
>
> xrefactory does this. I tried it once. It's a bit pricey , though.
Someone is charging money for an emacs addon? Are they nuts? A lot of
people won't touch emacs with a ten foot pole, and emacs is free. How
many would actually pay for something that's useless without emacs?
Especially given the near-certainty that the price is almost pure
profit margin...
Harry George <··············@boeing.com> writes:
> I don't mind folks using any editor they want, as long as they are
> proficient. In those cases, I have no problem doing Extreme
> Programming with them -- code a bit, save, the other guy codes a
> bit. But when someone uses vi and then forgets how to do block
> moves, or uses eclipse and bogs down the session, or uses MS Notepad
> and can't enforce language-specific indents, I get frustrated.
My favorite killing offence is /* vi:set ts=4: */.
--
David Kastrup
David Kastrup wrote:
> My favorite killing offence is /* vi:set ts=4: */.
This is apparently the default setting in many of the so-called "IDE"s
today.. I think it's another unwelcome poison gift from the ignorant
M$FT world (I suspect some primitive Windoze IDE which couldn't
differentiate between TAB and indent probably offered the programmer
changing the tabwidth as the only method for changing indentation, and
then this method got stuck...)
F'up to comp.emacs.
On Tue, 19 Jun 2007 15:53:21 +0200, David Kastrup <···@gnu.org> wrote:
>Harry George <··············@boeing.com> writes:
>> I don't mind folks using any editor they want, as long as they are
>> proficient. In those cases, I have no problem doing Extreme
>> Programming with them -- code a bit, save, the other guy codes a bit.
>> But when someone uses vi and then forgets how to do block moves, or
>> uses eclipse and bogs down the session, or uses MS Notepad and can't
>> enforce language-specific indents, I get frustrated.
>
> My favorite killing offence is /* vi:set ts=4: */.
Apparently, we share at least part of that. My own favorite killing
offense is '/* vi:set ts=anything: */' :)
>>>>> Long count = 12.19.14.7.8; tzolkin = 7 Lamat; haab = 16 Zotz.
>>>>> I get words from the Allmighty Great Gnus that
>>>>> "GB" == Galen Boyer <···········@yahoo.com> writes:
GB> Most other environments will be for those just trying to perform
GB> their tasks and staying even with the average proficiency chart.
Alleluja, brother!
(just unleashed the power of the True One Editor surprising the rest
of the workgroup)
--
/\ ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
//--\| | \| | Integralista GNUslamico
\/ e coltivatore diretto di Software
A Cesare avrei detto di scrivermi a ·····@rat.vg
Here are some Frequently Asked Questions about The Modernization of
Emacs.
They are slightly lengthy, so i've separated each item per post. The
whole article can be found at
http://xahlee.org/emacs/modernization.html
------------
Q: The Terminology “buffer” and “keybinding” is good as they are.
A: 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, a programer “bind” a
keystroke to a command in a software application. The term “buffer”
refers to a abstract, temporary 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 reading files or writing to
files, for example, file management, ftp/sftp, shell, email, irc etc.,
the proper term can be “panel”, “window”, or “work area”.
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”.
Although concepts like “buffer” and “keybinding” are seemingly
interchangeable with “panel” or “keyboard shortcut”, but their
contexts set them apart. This is why in all modern software
application's user documentations, terms like “buffer” or “keybinding”
are not to be seen but “windows, panes, and keyboard shortcuts”.
The reason emacs uses the technical terminologies throughout is
because when emacs started in the 1970s, there really isn't any other
text editors or even software applications. And, Emacs users consists
of solely computer scientists and programers, and there are not many.
Changes in society are always resisted by old timers, but it is also a
main element behind progress. This terminology issue may seem trivial,
but its importance lies in making emacs palpable to the vast number of
people who ever need to use a computer to write.
Xah
···@xahlee.org
∑ http://xahlee.org/
Xah Lee <···@xahlee.org> writes:
> Here are some Frequently Asked Questions about The Modernization of
> Emacs.
>
> They are slightly lengthy, so i've separated each item per post. The
> whole article can be found at
>
> http://xahlee.org/emacs/modernization.html
> ------------
>
> Q: The Terminology “buffer” and “keybinding” is good as they are.
>
> A: 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, a programer “bind” a
> keystroke to a command in a software application. The term “buffer”
> refers to a abstract, temporary area for storing data, in the context
> of programing or computer science.
>
> These terms are irrelevant to the users of a software application.
Bologna.
Every computer user should see himself as a programmer.
> Changes in society are always resisted by old timers, but it is also a
> main element behind progress. This terminology issue may seem trivial,
> but its importance lies in making emacs palpable to the vast number of
> people who ever need to use a computer to write.
I'm a young-timer.
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest:
http://www.gnu.org/philosophy/sylvester-response.html
From: Giorgos Keramidas
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <87tzt3ihev.fsf@kobe.laptop>
On Tue, 19 Jun 2007 10:01:35 -0700, Xah Lee <···@xahlee.org> wrote:
> Here are some Frequently Asked Questions about The Modernization of
> Emacs.
>
> They are slightly lengthy, so i've separated each item per post. The
> whole article can be found at
>
> http://xahlee.org/emacs/modernization.html
> ------------
>
> Q: The Terminology “buffer” and “keybinding” is good as they are.
>
> A: 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, a programer “bind” a
> keystroke to a command in a software application. The term “buffer”
> refers to a abstract, temporary 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”.
No they are not. See you may have a real *file* on a disk somewhere,
which is called 'opened file' or even 'untitled file'. Now isn't it
confusing to think in terms of made-up descriptiors, just because the
term 'buffer' seems alien?
Educating the user to avoid confusion in this and other cases of made
up, 'user-friendly' descriptions is not a good enough answer. If you
can educate the user about this sort of fine distinction between files
stored on a disk somewhere and files which are figments of the
imagination of Emacs, then I can educate them about 'buffer' too and be
done with it all.
The main difference is that I get to do it today, without the need for
multi-thousand-line changes in the source and documentation of Emacs and
its thousands of plugins.
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m31wg6lre9.fsf@borud.not>
[Giorgos Keramidas <········@ceid.upatras.gr>]
|
| Educating the user to avoid confusion in this and other cases of made
| up, 'user-friendly' descriptions is not a good enough answer.
there are two types of "user friendly". there's "user friendly" and
then there is "beginner friendly" which is often mislabeled. the
latter is more important for applications which are to be used
casually. like utilities you only use once or twice per year -- those
need to be "beginner friendly".
for applications you are likely to use for prolonged periods of time
(like programming, video editing, music production etc), it does not
make sense to optimize for "beginner friendly". at least not at the
cost of making the application less "user friendly".
applications you spend a lot of time using are worth an investment in
learning how to use them. what creates friction in an application you
know reasonably well is when common tasks are fiddly. for instance,
while menus are often good for casual use and lower the initial
threshold for absolute beginners, depending heavily on menu navigation
becomes too fiddly if you are performing a certain task 2-3 times per
minute. it is not _user_ friendly.
Emacs is rather "user friendly", but not very "beginner friendly".
when I was first confronted with it, the sort of text editors I was
used to were Wordstar and derivatives of it. I was rather annoyed
that it didn't do what I expected, so I just used a different editor.
a few years later I bemoaned the fact that Emacs was so hard to use
during a conversation with a friend. he asked me if I had actually
made an effort to learn Emacs, which of course I hadn't. so I figured
I might as well give it a shot.
following the tutorial that comes with Emacs (and which is referred to
in the startup message) I spent a couple of hours one afternoon
learning the basics. already the next day I started using Emacs for
programming. the week after I had progressed to using it as my
newsreader (which I still do to this day) and eventually I started
reading my email in Emacs. perhaps two months after I had sat down to
learn Emacs I wrote my first Emacs extensions in Emacs Lisp. mostly
simple stuff to make common programming tasks easier.
I found Emacs to be user friendly, but in a different sense than the,
IMHO faulty definition, "beginner friendly". Emacs let me, as a user,
do more with less effort and provides a lot less friction than many
other developer tools I've used. at work I use it extensively, and we
have lots of neat extensions that really save a lot of time.
-Bj�
On Jun 20, 8:52 am, Bjorn Borud <··········@borud.no> wrote:
> I found Emacs to be user friendly, but in a different sense than the,
> IMHO faulty definition, "beginner friendly". Emacs let me, as a user,
> do more with less effort and provides a lot less friction than many
> other developer tools I've used. at work I use it extensively, and we
> have lots of neat extensions that really save a lot of time.
Being beginner-friendly doesn't have to be at the expense of power or
expert-user usability.
On the other hand, being actively beginner-hostile leads to nobody
adopting the tool. Then again, if you don't mind being the last
generation that'll ever use it, then I guess you're okay with that. If
it suits its existing users, the rest of us will just continue to use
something else.
I continue to suspect that there's an ulterior motive for making and
keeping certain software actively beginner-hostile; a certain macho
elitism also seen with light aircraft pilots and commented on at
www.asktog.com (exact URL escapes me; sorry).
From: Cor Gest
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <87wsxyffy6.fsf@telesippa.clsnet.nl>
Some entity, AKA Twisted <··········@gmail.com>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> On the other hand, being actively beginner-hostile leads to nobody
> adopting the tool. Then again, if you don't mind being the last
> generation that'll ever use it, then I guess you're okay with that. If
> it suits its existing users, the rest of us will just continue to use
> something else.
> I continue to suspect that there's an ulterior motive for making and
> keeping certain software actively beginner-hostile; a certain macho
> elitism also seen with light aircraft pilots and commented on at
> www.asktog.com (exact URL escapes me; sorry).
Of course! real tools are not for wannabees.
Just like there are a lot of people that have a shed full off the most
modern power-tools that money can buy from the local DIY-Market,
but cannot build a chickencoop if their life depended on it.
If you are to lazy to learn how to use any tool, it will not serve
you in any usefull manner.
But if you are to dumb to grok it, it's useless anyway.
Cor
--
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
The biggest problem LISP has, is that it does not appeal to dumb people
If that fails to satisfy read the HyperSpec, woman frig or Tuxoharata
mailpolicy @ http://www.clsnet.nl/mail.php
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <85zm2ufjpb.fsf@lola.goethe.zz>
Twisted <··········@gmail.com> writes:
> On the other hand, being actively beginner-hostile leads to nobody
> adopting the tool. Then again, if you don't mind being the last
> generation that'll ever use it, then I guess you're okay with
> that. If it suits its existing users, the rest of us will just
> continue to use something else.
>
> I continue to suspect that there's an ulterior motive for making and
> keeping certain software actively beginner-hostile; a certain macho
> elitism also seen with light aircraft pilots and commented on at
> www.asktog.com (exact URL escapes me; sorry).
You are babbling.
Emacs is amazingly beginner-friendly for the power and flexibility it
provides. You can sit a beginner at an Emacs session and have him
start editing and learning. You can't do the same, say, with vi or a
clone: the least you need is a vi helpsheet/cheat cup. With Emacs,
the help sheet is helpful but optional (most people would be eyed
strangely anyway if they kept a cheat barrel around at their
workplace).
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
On Jun 20, 4:35 pm, David Kastrup <····@gnu.org> wrote:
> Twisted <··········@gmail.com> writes:
> > On the other hand, being actively beginner-hostile leads to nobody
> > adopting the tool. Then again, if you don't mind being the last
> > generation that'll ever use it, then I guess you're okay with
> > that. If it suits its existing users, the rest of us will just
> > continue to use something else.
>
> > I continue to suspect that there's an ulterior motive for making and
> > keeping certain software actively beginner-hostile; a certain macho
> > elitism also seen with light aircraft pilots and commented on at
> >www.asktog.com(exact URL escapes me; sorry).
>
> You are babbling.
No, I am not. You, however, are being gratuitously insulting.
> Emacs is amazingly beginner-friendly for the power and flexibility it
> provides. [snip]
That's a joke, right? I tried it a time or two. Every time it was
rapidly apparent that doing anything non-trivial would require
consulting a cheat sheet. The printed-out kind, since navigating to
the help and back without already having the help displayed and open
to the command reference was also non-trivial.
Four hours of wasted time later, with zero productivity to show for
it, I deleted it. The same thing happened again, so it wasn't a bad
day or a fluke or a one-off or the particular version, either.
On Jun 20, 4:49 pm, Twisted <··········@gmail.com> wrote:
> On Jun 20, 4:35 pm, David Kastrup <····@gnu.org> wrote:
>
> > Twisted <··········@gmail.com> writes:
> > > On the other hand, being actively beginner-hostile leads to nobody
> > > adopting the tool. Then again, if you don't mind being the last
> > > generation that'll ever use it, then I guess you're okay with
> > > that. If it suits its existing users, the rest of us will just
> > > continue to use something else.
>
> > > I continue to suspect that there's an ulterior motive for making and
> > > keeping certain software actively beginner-hostile; a certain macho
> > > elitism also seen with light aircraft pilots and commented on at
> > >www.asktog.com(exactURL escapes me; sorry).
>
> > You are babbling.
>
> No, I am not. You, however, are being gratuitously insulting.
>
> > Emacs is amazingly beginner-friendly for the power and flexibility it
> > provides. [snip]
>
> That's a joke, right? I tried it a time or two. Every time it was
> rapidly apparent that doing anything non-trivial would require
> consulting a cheat sheet. The printed-out kind, since navigating to
> the help and back without already having the help displayed and open
> to the command reference was also non-trivial.
>
> Four hours of wasted time later, with zero productivity to show for
> it, I deleted it. The same thing happened again, so it wasn't a bad
> day or a fluke or a one-off or the particular version, either.
I agree with you in that emacs is not inherently nor universally
beginner friendly. However, if you are trying to make the claim that
it is impossible to pick it up quickly, then I no longer agree with
you.
I still have a good deal to learn, even of the basics, but I've toyed
with it casually for a little bit (a total of two hours at most, but
almost certainly less) and I already know enough that finding out how
to do anything else IS trivial. It's not a program whose controls
throw themselves at you, exactly, but with a touch of patience and a
genuine interest in learning, it's not too bad.
On Jun 20, 5:03 pm, Kaldrenon <·········@gmail.com> wrote:
> I still have a good deal to learn, even of the basics, but I've toyed
> with it casually for a little bit (a total of two hours at most, but
> almost certainly less) and I already know enough that finding out how
> to do anything else IS trivial. It's not a program whose controls
> throw themselves at you, exactly, but with a touch of patience and a
> genuine interest in learning, it's not too bad.
I don't know what software you're describing, but it's obviously not
emacs, unless there have been some HUGE changes to (at minimum) the
help and pane-navigation (er, excuse me, "window"-navigation)
controls...
My experiences (with emacs and with a lot of other supposedly-
superior, usually unix-heritage software) put me in mind of an
analogy: fumbling around in a strange house in the dark without a
flashlight, banging into furniture frequently, trying to find a light
switch, but it turns out the switches are all spring-loaded. For some
reason (saving electricity and fighting the war against global
warming?) if you go to start doing anything else the light goes off
again immediately -- so you have to stand there holding the switch,
memorize the contents of the room, and then quickly do whatever you
needed to do before your memory of the room's layout and where things
are fades! Then back to the switch, or trip and fumble your way to a
different room's switch...wash, rinse, repeat...
Nobody would actually design a home (or a workplace) like that in a
trillion years, global warming be damned. So why do people still
sometimes design software like that?
Oh and did I mention that these houses' layouts are also totally
strange, with the living room on the top floor and the kitchen in the
basement, or other things of that nature, so you can't transfer any
knowledge of conventional home designs to aid in your navigation
there...and they are even all different from one another, nevermind
"normal" houses...
BTW, is anyone else finding Google Groups especially ornery of late? I
get all of the following, recurrently:
* I enter one reply in a thread, and it works. Then I go to make a
second reply, and I get a text box like one uses to enter a reply,
except evidently read-only -- I can select text but there is no
blinking cursor.
* The fix seems to be to navigate off the page and back.
Unfortunately, that then pops up some dialog. I think GG is trying to
protect me from losing unsaved changes, except that there are
obviously no unsaved changes to the (read-only!) form for me to lose!
* The "back" button is wonky -- it seems to require hitting back
*twice* to go back *one* page to the previous page of the thread or to
the newsgroup's thread index, if already on the first (or only) page.
* After *that*, "forward" behaves sometimes normally and sometimes as
"forward and then click a reply link on some random post"??
* Submitting a post results in the form disappearing and being
replaced by "The post was entered successfully". Of course, if it
turns out to have NOT been all that successful as evidenced from
refreshing the page or using an external newsserver (I have found one
read-only one suitable for verifying that a posting succeeded and
propagated beyond GG's server), there's no way to get back to the form
to try to resubmit the text, or even to recover it to the clipboard to
paste into a fresh form for a fresh attempt. So far, it's never
actually lied and claimed a posting was successful that wasn't, but
there's a first time for everything, and we all know the track record
for QA in the software industry ... and the way one of the more common
failure modes of software is silent failure, claiming success on
failure, claiming failure on success, or claiming one failure when a
different failure happened! (All the various forms of diagnostics
failure...) I guess I have to pre-emptively copy the form contents to
the clipboard before clicking submit, and preserve the clipboard
contents pending verification, or risk catastrophic data loss, because
GG can't be arsed to make a decent interface, or even to leave well
enough alone and stop constantly changing it.
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <85ir9ifgtx.fsf@lola.goethe.zz>
Twisted <··········@gmail.com> writes:
> On Jun 20, 5:03 pm, Kaldrenon <·········@gmail.com> wrote:
>> I still have a good deal to learn, even of the basics, but I've toyed
>> with it casually for a little bit (a total of two hours at most, but
>> almost certainly less) and I already know enough that finding out how
>> to do anything else IS trivial. It's not a program whose controls
>> throw themselves at you, exactly, but with a touch of patience and a
>> genuine interest in learning, it's not too bad.
>
> I don't know what software you're describing, but it's obviously not
> emacs, unless there have been some HUGE changes to (at minimum) the
> help and pane-navigation (er, excuse me, "window"-navigation)
> controls...
So what version are you babbling about?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
On Jun 20, 5:37 pm, David Kastrup <····@gnu.org> wrote:
> ...spewing...babbling...
I won't dignify your insulting twaddle and random ad-hominem verbiage
with any more responses after this one. Something with actual logical
argumentation to rebut may be another matter of course.
One more GG issue: those stupid star ratings. So potentially
prejudicial. So easy to game, as evidenced by your managing to somehow
vote 82 times(!) against one of my posts in a matter of minutes. So
far I've found a less-impressive method to game them -- it's not hard
to get throwaway accounts elsewhere, send yourself there a gmail
invite, and create many GG accounts. Handy to get around their onerous
posting limits. Handy for stuffing the star-vote ballot boxes with
multiple votes, too, but there's no way I can see to generate 82 of
them that fast by that method, and that much logging in and out in
that short a time using different accounts but from just one IP
address is sure to come up on Google's radar somehow, with
unpredictable but probably bad results. How did you do it? I'm
guessing they stop the link for voting appearing as a usable link on
the page for a) your own posts and b) the ones you've voted for, but
the link's URL still works, so if you use a script to keep fetching
the appropriate URL ...
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <863b0lolaf.fsf@lola.quinscape.zz>
Twisted <··········@gmail.com> writes:
> On Jun 20, 5:37 pm, David Kastrup <····@gnu.org> wrote:
>> ...spewing...babbling...
>
> I won't dignify your insulting twaddle and random ad-hominem verbiage
> with any more responses after this one. Something with actual logical
> argumentation to rebut may be another matter of course.
>
> One more GG issue: those stupid star ratings. So potentially
> prejudicial. So easy to game, as evidenced by your managing to somehow
> vote 82 times(!) against one of my posts in a matter of minutes.
It has not occured to you that actually thousands of people read those
postings? And they are heavily crossposted to boot (redirecting
followup to comp.emacs, I would suggest everybody else do the same).
And you have really nothing worthwhile to contribute. So if there is
some rating system (I don't use Google Groups so can't tell) in place,
your postings would certainly be good candidates for downrating.
Not that this posting of mine is much better, and actually the
followup-to comp.emacs would indicate that this is about Emacs.
However, you have still not given any information about what, if any,
version of Emacs your very vaguely expressed experiences are supposed
to have come from.
> So far I've found a less-impressive method to game them -- it's not
> hard to get throwaway accounts elsewhere, send yourself there a
> gmail invite, and create many GG accounts.
And you wonder that people don't find it worthwhile reading you...
> Handy to get around their onerous posting limits. Handy for stuffing
> the star-vote ballot boxes with multiple votes, too, but there's no
> way I can see to generate 82 of them that fast by that method, and
> that much logging in and out in that short a time using different
> accounts but from just one IP address is sure to come up on Google's
> radar somehow, with unpredictable but probably bad results.
Uh, is there some monetary compensation for star ratings? Or what's
the deal? Really, if somebody can come up with a better group for
followups, feel free to direct there.
> How did you do it? I'm guessing they stop the link for voting
> appearing as a usable link on the page for a) your own posts and b)
> the ones you've voted for, but the link's URL still works, so if you
> use a script to keep fetching the appropriate URL ...
What a crazy obsession.
--
David Kastrup
From: Miles Bader
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <87myy1gqwk.fsf@catnip.gol.com>
Twisted <··········@gmail.com> writes:
> I won't dignify your insulting twaddle and random ad-hominem verbiage
> with any more responses after this one. Something with actual logical
> argumentation to rebut may be another matter of course.
Er, why don't you just answer his question (what version)? He's asking
for actual information, which will help us understand what you are
(trying) to to say.
If you continue to just make vague and unsupported (and rather hostile)
assertions, without examples, version numbers, or other concrete
information, do you expect anybody will continue listening to you?
-miles
--
The secret to creativity is knowing how to hide your sources.
--Albert Einstein
On Jul 12, 7:10 pm, Miles Bader <·····@gnu.org> wrote:
> Twisted <··········@gmail.com> writes:
> > I won't dignify your insulting twaddle and random ad-hominem verbiage
> > with any more responses after this one. Something with actual logical
> > argumentation to rebut may be another matter of course.
>
> Er, why don't you just answer his question (what version)? He's asking
> for actual information, which will help us understand what you are
> (trying) to to say.
>
> If you continue to just make vague and unsupported (and rather hostile)
> assertions, without examples, version numbers, or other concrete
> information, do you expect anybody will continue listening to you?
Some people can't let sleeping dogs lie I guess.
I can't remember the specific version after all these years. It may
have been 18 or 19 point something. As for "concrete information" this
thread is littered with fairly specific anecdotes. I know, I know;
anecdotes aren't really proof of anything. Got any better suggestions?
HCI stuff is a bit slippery to try to hang a rigorous theory and
quantitative facts upon. For most people, a crappy interface isn't
something they can precisely define, but they know it when they see it
(or at least try to use it).
Twisted <··········@gmail.com> writes:
> On Jun 20, 5:03 pm, Kaldrenon <·········@gmail.com> wrote:
>> I still have a good deal to learn, even of the basics, but I've toyed
>> with it casually for a little bit (a total of two hours at most, but
>> almost certainly less) and I already know enough that finding out how
>> to do anything else IS trivial. It's not a program whose controls
>> throw themselves at you, exactly, but with a touch of patience and a
>> genuine interest in learning, it's not too bad.
>
> I don't know what software you're describing, but it's obviously not
> emacs, unless there have been some HUGE changes to (at minimum) the
> help and pane-navigation (er, excuse me, "window"-navigation)
> controls...
We're talking about Emacs. In particular we're referring to
C-h t
C-h i
C-h ?
Or, since Emacs is customizable, for me it would be
<f1> t
<f1> i
<f1> ?
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest:
http://www.gnu.org/philosophy/sylvester-response.html
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <868xadl59a.fsf@lola.quinscape.zz>
········@partners.org (Joel J. Adamson) writes:
> Twisted <··········@gmail.com> writes:
>
>> On Jun 20, 5:03 pm, Kaldrenon <·········@gmail.com> wrote:
>>> I still have a good deal to learn, even of the basics, but I've toyed
>>> with it casually for a little bit (a total of two hours at most, but
>>> almost certainly less) and I already know enough that finding out how
>>> to do anything else IS trivial. It's not a program whose controls
>>> throw themselves at you, exactly, but with a touch of patience and a
>>> genuine interest in learning, it's not too bad.
>>
>> I don't know what software you're describing, but it's obviously not
>> emacs, unless there have been some HUGE changes to (at minimum) the
>> help and pane-navigation (er, excuse me, "window"-navigation)
>> controls...
>
> We're talking about Emacs. In particular we're referring to
>
> C-h t
> C-h i
> C-h ?
>
> Or, since Emacs is customizable, for me it would be
>
> <f1> t
> <f1> i
> <f1> ?
Huh? The latter are available by default on Emacs 22.1.
--
David Kastrup
David Kastrup <···@gnu.org> writes:
> ········@partners.org (Joel J. Adamson) writes:
>> Or, since Emacs is customizable, for me it would be
>>
>> <f1> t
>> <f1> i
>> <f1> ?
>
> Huh? The latter are available by default on Emacs 22.1.
Interesting, maybe I have a telepathetic connection with the
developers; either that or I just kept using the same .emacs when I
upgraded ;)
(I had to change this when I was using Emacs 21.4, since I started
using C-h for backspace)
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest:
http://www.gnu.org/philosophy/sylvester-response.html
From: Michal Nazarewicz
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <87tzt0rwwo.fsf@erwin.mina86.com>
Twisted <··········@gmail.com> writes:
> On Jun 20, 5:03 pm, Kaldrenon <·········@gmail.com> wrote:
>> I still have a good deal to learn, even of the basics, but I've toyed
>> with it casually for a little bit (a total of two hours at most, but
>> almost certainly less) and I already know enough that finding out how
>> to do anything else IS trivial. It's not a program whose controls
>> throw themselves at you, exactly, but with a touch of patience and a
>> genuine interest in learning, it's not too bad.
>
> I don't know what software you're describing, but it's obviously not
> emacs, unless there have been some HUGE changes to (at minimum) the
> help and pane-navigation (er, excuse me, "window"-navigation)
> controls...
I don't know about *your* version of Emacs but in *my* version one can
switch windows using mouse. I think that's pretty easy especially for
beginners who are used to Windows.
There was also a Help menu on menu bar but I disabled menu bar since
keybindings are more convenient for me.
--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>---<jid:mina86*chrome.pl>--ooO--(_)--Ooo--
On Jun 20, 4:49 pm, Twisted <··········@gmail.com> wrote:
> On Jun 20, 4:35 pm, David Kastrup <····@gnu.org> wrote:
> > Twisted <··········@gmail.com> writes:
> > > I continue to suspect that there's an ulterior motive for making and
> > > keeping certain software actively beginner-hostile; a certain macho
> > > elitism also seen with light aircraft pilots and commented on at
> > >www.asktog.com(exactURL escapes me; sorry).
>
> > You are babbling.
>
> No, I am not. You, however, are being gratuitously insulting.
I have that exact URL now -- http://www.asktog.com/columns/027InterfacesThatKill.html
The most relevant section is towards the bottom of the page.
Curiously, you can jump right to it with a text-find of the word
"girls".
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <85r6o6fhkb.fsf@lola.goethe.zz>
Twisted <··········@gmail.com> writes:
> On Jun 20, 4:49 pm, Twisted <··········@gmail.com> wrote:
>> On Jun 20, 4:35 pm, David Kastrup <····@gnu.org> wrote:
>> > Twisted <··········@gmail.com> writes:
>> > > I continue to suspect that there's an ulterior motive for making and
>> > > keeping certain software actively beginner-hostile; a certain macho
>> > > elitism also seen with light aircraft pilots and commented on at
>> > >www.asktog.com(exactURL escapes me; sorry).
>>
>> > You are babbling.
>>
>> No, I am not. You, however, are being gratuitously insulting.
>
> I have that exact URL now --
> http://www.asktog.com/columns/027InterfacesThatKill.html
Utterly unrelated to Emacs.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
On Jun 20, 5:21 pm, David Kastrup <····@gnu.org> wrote:
> Twisted <··········@gmail.com> writes:
> > On Jun 20, 4:49 pm, Twisted <··········@gmail.com> wrote:
> >> On Jun 20, 4:35 pm, David Kastrup <····@gnu.org> wrote:
> >> > Twisted <··········@gmail.com> writes:
> >> > > I continue to suspect that there's an ulterior motive for making and
> >> > > keeping certain software actively beginner-hostile; a certain macho
> >> > > elitism also seen with light aircraft pilots and commented on at
> >> > >www.asktog.com(exactURLescapes me; sorry).
>
> >> > You are babbling.
>
> >> No, I am not. You, however, are being gratuitously insulting.
>
> > I have that exact URL now --
> >http://www.asktog.com/columns/027InterfacesThatKill.html
>
> Utterly unrelated to Emacs.
I think it is quite relevant. Clunky computer interfaces may not be so
dramatically dangerous, but they certainly can hamper productivity.
Between Windows bugs and gratuitous misfeatures (e.g. DRM) and Unix
clunkiness, billions of dollars of potential productivity is lost
worldwide every *month*.
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <85myyufgwj.fsf@lola.goethe.zz>
Twisted <··········@gmail.com> writes:
> On Jun 20, 5:21 pm, David Kastrup <····@gnu.org> wrote:
>> Twisted <··········@gmail.com> writes:
>> > On Jun 20, 4:49 pm, Twisted <··········@gmail.com> wrote:
>> >> On Jun 20, 4:35 pm, David Kastrup <····@gnu.org> wrote:
>> >> > Twisted <··········@gmail.com> writes:
>> >> > > I continue to suspect that there's an ulterior motive for making and
>> >> > > keeping certain software actively beginner-hostile; a certain macho
>> >> > > elitism also seen with light aircraft pilots and commented on at
>> >> > >www.asktog.com(exactURLescapes me; sorry).
>>
>> >> > You are babbling.
>>
>> >> No, I am not. You, however, are being gratuitously insulting.
>>
>> > I have that exact URL now --
>> >http://www.asktog.com/columns/027InterfacesThatKill.html
>>
>> Utterly unrelated to Emacs.
>
> I think it is quite relevant. Clunky computer interfaces may not be
> so dramatically dangerous, but they certainly can hamper
> productivity.
But Emacs does not have a "clunky" interface.
> Between Windows bugs and gratuitous misfeatures (e.g. DRM) and Unix
> clunkiness, billions of dollars of potential productivity is lost
> worldwide every *month*.
You are spewing again.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
On Jun 20, 5:35 pm, David Kastrup <····@gnu.org> wrote:
> But Emacs does not have a "clunky" interface.
That's for the everyday novice-to-intermediate user to decide. Your
gnu.org email address (and attitude) clearly marks you as not a normal
user, and so your opinion doesn't count.
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <85abuufgoh.fsf@lola.goethe.zz>
Twisted <··········@gmail.com> writes:
> On Jun 20, 5:35 pm, David Kastrup <····@gnu.org> wrote:
>
>> But Emacs does not have a "clunky" interface.
>
> That's for the everyday novice-to-intermediate user to decide.
And they do.
> Your gnu.org email address (and attitude) clearly marks you as not a
> normal user, and so your opinion doesn't count.
Your email address and attitude marks you as an anonymous troll.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Robert Uhl
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3ejk5479k.fsf@latakia.dyndns.org>
Twisted <··········@gmail.com> writes:
>
>> But Emacs does not have a "clunky" interface.
>
> That's for the everyday novice-to-intermediate user to decide.
Why should the ignorant decide? Do you leave the decision of what great
art is to 3 year olds and their doting parents? Do you leave the
decision of what great food is to the ignorant, unwashed,
McDonald's-devouring masses? Why then do you leave the decision of
what's a useful interface to those with insufficient experience?
Emacs has a slight learning curve (so too did your Windows/Mac OS
interface conventions--you've just forgotten them), but it is easy to
use. A Windows or Mac OS text editor may have an easier learning curve,
but it'll never be as easy to use.
--
Robert Uhl <http://public.xdi.org/=ruhl>
I read [.doc files] with 'rm.' All you lose is the Microsoft-specific
font selections, the macro viruses and the luser babblings.
--Gary `Wolf' Barnes
From: Galen Boyer
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <ur6o4wpol.fsf@rcn.com>
On Thu, 21 Jun 2007, ·········@NOSPAMgmail.com wrote:
> but it is easy to use. A Windows or Mac OS text editor may have an
> easier learning curve, but it'll never be as easy to use.
This really is the biggest argument. Emacs takes more time to learn
than any other environment I've used. But, Emacs is the easiest to use
interface I've ever come across, by a very very wide margin.
--
Galen Boyer
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m37ipw82j7.fsf@borud.not>
[Robert Uhl <·········@NOSPAMgmail.com>]
|
| Why should the ignorant decide? Do you leave the decision of what great
| art is to 3 year olds and their doting parents? Do you leave the
| decision of what great food is to the ignorant, unwashed,
| McDonald's-devouring masses? Why then do you leave the decision of
| what's a useful interface to those with insufficient experience?
Robert does have a point; however, one needs to take into account that
it is very difficult to judge the quality of an interface if it is one
that is very familiar to you or if the inner workings are obvious to
you. this is why programmers often make bad UI designers: we are
intimately familiar with the inner workings, and to us it is okay if
the UI is just a thin layer on top of a system we've made.
(I'd say the web is a better showcase for this. there seems to be no
end to the number of websites that have awkward interaction modes.
nor do people seem particularly shy about adding "just one more" thing
to an already crowded interface -- because they're blind to the wall
of complexity it presents to the occasional user).
editors like Emacs is not something which is designed for the casual
user, so what the casual user thinks is irrelevant. (also note that
the definition of "casual user" has changed).
-Bj�
On Jun 21, 12:11 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> Twisted <··········@gmail.com> writes:
>
> >> But Emacs does not have a "clunky" interface.
>
> > That's for the everyday novice-to-intermediate user to decide.
>
> Why should the ignorant decide? Do you leave the decision of what great
> art is to 3 year olds and their doting parents?
Did I say it was for the "beginner" to decide? No, I said "novice-to-
intermediate".
How clunky versus usable an interface to a tool is is for those who
invest some, but not extraordinary amounts of, time into its use to
decide. If it requires years of mastery, it is clunky -- period. This
may be unavoidable if it's something involved in nuclear power plants,
delicate neurosurgery, or whatever. If it's a text editor, on the
other hand, it's clearly going to have superior competition in the
area of usability.
Besides, ANY interface that involves fumbling around in the dark
trying to find a light switch is clunky. You should be able to see
what the hell you're doing and navigate easily. Applications that not
only eschew normal methods of navigation of the interface, but force
you to fumble your way between the help and the task you're trying to
do, are definitely clunky. An analogy to a genuine emacs experience:
you enter a workshop with some raw materials and tools. Unfortunately
there's no big ceiling lights so you can just flip the switch by the
door and then always be able to see where everything is. Instead
there's little lights here and there by various specific tools and
storage areas, and in one area a map of the place with switches to
control the lights. So first you have to fumble around until you
happen upon the map/light controls. Then you need to (in the dark!)
hit the switch for the map/light control area itself. (Now you've
found the help and gotten it to be the active pane, er "window".) Now
you need to find the tool you want on the map -- OK, that was easy.
Now you turn on its light. Oh, hell -- the light on the map/light
controls has now gone out though! That also included the instructions
on using the specific tool. You can go to and use the one tool, if you
memorized those instructions, but then it's back to the darkness...
(You find the help on doing a particular thing, then can't get back to
the document to do it because of clunky navigation. So you go back to
the help on switching windows, and now you can flip back to the
document. Only you realize you can have the document and help open at
the same time, but the only time the document has focus is when the
help is open to "help on switching windows", which makes this rather
useless! You end up having to memorize the help, because *you can't
have arbitrary parts of the help and your document open side by side
and be working on the document*. All because you can't simply tab or
click to the document. At minimum, you have to *memorize* some arcane
key controls for switching panes ... er, "windows", that are totally
unintuitive and unlike what is normally used.
Oops. The interface design is a nightmare. The most basic requirement,
that it be easy to have the help open side by side with your document
and switch back and forth and navigate inside the help easily, is
broken. If you have to consult the help just to navigate the help or
to switch focus between document and help, then you're trapped, and
that is what happens with emacs.
I don't know why people keep harping about what version. It was
probably something in the low 20s, after an earlier try with one in
the upper teens. The interface never improved over that time -- the
biggest problem consistently being that whenever focus was
successfully transferred to the document window, the help window was
invariably open to the instructions for switching windows, so you
could never be doing something with the document and have the help for
that something available at a glance. Defeating the whole purpose of
having a help system. A separate printed manual would have been
better, if I could have spared the paper and toner, as I could hold
that off to one side of the monitor and flip through it and open it to
anywhere I wanted to, then go back to my document without even having
to think about it. Even though it would be at the price of no full-
text search capability -- not that I could ever get that to work in
emacs anyway. There was no apparent way to do a simple substring
search and click "next match" or "previous match" to navigate among
the hits...more arcane keypresses would be required, and as soon as it
showed you the first match inside the help, the keypress documentation
of course vanished.
As far as I can tell, it just is not and never was possible to get
started with emacs without a separate, outside-of-emacs cheat sheet,
or to be very productive at all without actually memorizing the damn
thing. Modern user interfaces require a minimum of memorization, most
of which is basic, standard stuff that is the same from one app to the
next, so you already know it all -- your clicks and double clicks,
your alt-tabs and alt-enter-for-properties etc.; application-specific
keyboard shortcuts can be learned as convenient. Infrequently used
commands you can stand to hunt for in menus. When you find you use one
frequently, you can try to learn the keyboard shortcut -- and you can
find it without even consulting the help, simply by finding the
command's menu item. Every time you want to use the command but can't
remember the shortcut you just find it in the menu and activate it
from there, and see the shortcut while you're at it, helping to
eventually memorize it. And the commonest sorts of File and Edit menu
items have near-universal shortcuts, the big variation tending to be
whether Redo is shift-ctrl-Z, ctrl-Y, nonexistent, or menu-only.
But you can start using it right away with low productivity, and
increase your productivity with proficiency and learning (optional)
shortcuts, chiefly those to the commands you happen to use a lot.
Not so emacs, or most other unix-heritage tools. Those you can't use
in any nontrivial way without ascending a sheer cliff of memorization
*first*, before doing a single useful thing.
One person elsewhere in this thread even went so far as to suggest
that to avoid having a similar hurdle with every application you just
use emacs for everything. If you like being claustrophobically trapped
in 80x24x8BPP instead of 1280x1024x32BPP, that may be your cup of tea.
Also if you like having zero productivity in every single task instead
of just one until you've scaled the El Capitan of user interfaces. On
the other hand, you can avoid having a similar hurdle with ANY
application by simply using standard GUI apps developed with Mac and
Windows users in mind. I hear they even have them for Unix now --
technically including everything written for MacOSX as well as modern
WMs on Linux and probably *BSD.
(Use emacs for everything? That's like suggesting I move all my tools
*into* that dark place with the screwy lighting system, rather than
*out*. Me, I'd rather just avoid that place, or if necessary bring in
a big bank of floodlights and install them, and the sensitive artiste
who originally architected it be damned. Which is what Xah started
this whole mess by suggesting, in effect.)
On Jun 22, 3:47 pm, Twisted <··········@gmail.com> wrote:
> If it requires years of mastery, it is clunky
Well, now you keep harping on this, but it's just not true.
I use vim myself, but for purposes of this argument it doesn't matter.
If you take the Vim tutorial and use the help (which appears in a
split window anytime you want it), you can use Vim like any other text
editor within a day or so, especially if you use Cream, which is set
up to hold your Windows hands and act like any other Windows text
editor on the surface. But if you use Vim for YEARS you get better and
faster and more efficient precisely BECAUSE of its arcane
capabilities. If you are going to keep your hands on the keyboard
where they belong, if you REALLY want to go fast, then there's no
alternative to having complex key commands, which become second nature
over time, and take the place of repetitive, totally inefficient
mousing around.
You might enjoy this. Especially the link to an old essay called
"Interface Zen"
http://tinyurl.com/2da3om
rd
From: Martin Gregorie
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <konvk4-oaq.ln1@zoogz.gregorie.org>
BartlebyScrivener wrote:
> On Jun 22, 3:47 pm, Twisted <··········@gmail.com> wrote:
>
>> If it requires years of mastery, it is clunky
>
> Well, now you keep harping on this, but it's just not true.
>
> I use vim myself, but for purposes of this argument it doesn't matter.
> If you take the Vim tutorial and use the help (which appears in a
> split window anytime you want it), you can use Vim like any other text
> editor within a day or so, especially if you use Cream, which is set
> up to hold your Windows hands and act like any other Windows text
> editor on the surface. But if you use Vim for YEARS you get better and
> faster and more efficient precisely BECAUSE of its arcane
> capabilities. If you are going to keep your hands on the keyboard
> where they belong, if you REALLY want to go fast, then there's no
> alternative to having complex key commands, which become second nature
> over time, and take the place of repetitive, totally inefficient
> mousing around.
>
> You might enjoy this. Especially the link to an old essay called
> "Interface Zen"
>
> http://tinyurl.com/2da3om
>
A good reference. Thanks.
I like Interface Zen - much sense there.
However, there's a case he missed, probably through never using a CAD
system. All the good ones can be driven either by mouse, or by
non-chorded key sequences or any combo the user likes. The essence of
CAD is very accurate pointing but all too many mice move slightly when
clicked. Fortunately a decent CAD system offers the possibility of
purely pointing with the mouse and doing everything else with the other
hand on the keyboard. The result is both fast and extremely accurate.
An interface design point that nobody has yet mentioned here is that
there are four different types of user that map onto a grid:
casual dedicated
untrained 1 2
expert 3 4
I first ran across grid this in "Design of Man-Computer Dialogs" by
James Martin and its been very useful in systems interface design.
The problem with almost all current GUIs is that they are aimed at types
1 and 3 users - this certainly applies to Windows, OS X and Gnome
desktops with the emphasis on type 1. vi and microEmacs, OTOH, are aimed
at type 3 and 4 users.
Where does emacs fit on this grid? My guess would be 3 and 4.
Its very difficult indeed to design an interface that suits both
untrained and expert users. About the closest I've seen have been
keyboard driven menu structures which have been designed so the user can
build their own "command sequences" that traverse menu levels without
showing the menus, as long as items are selected correctly from each
level. Many CAD systems approximate to this but I've yet to see a
graphical desktop, IDE, or editor menu structure that came close.
--
······@ | Martin Gregorie
gregorie. | Essex, UK
org |
On Jun 23, 10:36 am, Martin Gregorie <······@see.sig.for.address>
wrote:
> However, there's a case he missed, probably through never using a CAD
> system. All the good ones can be driven either by mouse, or by
> non-chorded key sequences or any combo the user likes. The essence of
> CAD is very accurate pointing but all too many mice move slightly when
> clicked. Fortunately a decent CAD system offers the possibility of
> purely pointing with the mouse and doing everything else with the other
> hand on the keyboard. The result is both fast and extremely accurate.
Actually, what I prefer in (2D and 3D) visual design apps is the
ability to snap to some kind of grid/existing vertices, and to zoom in
close. Then small imprecisions in mouse movement can be rendered
unimportant.
> An interface design point that nobody has yet mentioned here is that
> there are four different types of user that map onto a grid:
>
> casual dedicated
> untrained 1 2
> expert 3 4
>
> I first ran across grid this in "Design of Man-Computer Dialogs" by
> James Martin and its been very useful in systems interface design.
>
> The problem with almost all current GUIs is that they are aimed at types
> 1 and 3 users - this certainly applies to Windows, OS X and Gnome
> desktops with the emphasis on type 1. vi and microEmacs, OTOH, are aimed
> at type 3 and 4 users.
The problem of course being the complete exclusion of type 1 users.
Everyone starts out as type 1, and I don't think type 2 occurs in
practise. You'd have to be some kind of religious nut to be
"dedicated" while still "untrained", rather than only as a result of
experience. Apps that provide no traction for a type 1 user will not
see much adoption except in an environment of immersion, mentoring, or
desperation. I wonder which of the three explains the majority of
emacs users, and of vi users, and whether those prove to be the same
one. :) (Actually, there'll be a single or a small number of class-2
users: the original developers, who presumably became dedicated before
having much experience *using* the tool. Their experiences are
atypical however, and their knowledge of the internals probably means
they're type 4 by the time they actually use it to do more than debug
it. Unsurprisingly, never experiencing it as a type 1 themselves they
tend to be inconsiderate of future type 1 users...this is normal, and
requires effort to avoid, in much the way blinkered views of stuff and
seeing what you want to see can be normal, and efforts like using
double-blind studies may be needed to avoid bias in evaluating, say, a
new drug. That such efforts are needed should not be seen as
disparaging the programmer or the drug-studier, but as merely
reflecting human nature, and as a simple pragmatic requirement if one
is to maximize utility.)
> Its very difficult indeed to design an interface that suits both
> untrained and expert users.
One with a bog-standard UI but also a "console" or command prompt,
scripting language, and customizable bindings?
Funnily enough I can count the software I've seen with that range of
capabilities (so able to satisfy type 1, 3, AND 4 users) on one hand.
Here's the list, in fact:
ROM BASICs and QBasic (on any really ancient microcomputer, and old
pre-Windows PCs, respectively; the former came with printed manuals
and you could just run prepackaged software from disks very easily;
QBasic had mouse and menu support, but an immediate mode command line.
You might not count ROM BASICS as as friendly, due to the lack of
menus and such, but then at that time in history NOTHING had menus and
such! And comprehensive introductory use manuals came with those, and
with pre-Windows PCs (DOS also had a decent and easy to navigate help
system). Most other BASICs and programming environments more generally
lack an integrated environment with an immediate mode prompt. Eclipse
actually sort of does, but the evaluate line can't be used really
arbitrarily and I've found it touchy, and rarely use it.
Hypercard (found commonly on old Macs; had a command prompt you could
access to directly communicate to an interpreter).
Fractint (fractal graphics making software for old pre-Windows PCs;
had a similar prompt, accessed by typing 'g', but also had extensive
help and menus readily controlled by stock keyboard commands such as
the arrow keys, and later a Windows port with menus and mouse
support).
Quake and descendants (yes, the games. Easy to just use the menus and
play the game. Advanced users could hit ~ to drop down a console and
do a few things. Really advanced ones made config files to rebind
weapons and make chat macros to fire off a taunting sentence with a
single keystroke -- no more embarrassment getting fragged while typing
it in longhand in mid-game. Super-advanced ones got at the QuakeC and
made bots, flag-capture mode mods, and other enhancements and
utilities. And sometimes cheats.)
There's probably some more out there, but I've yet to see such
desirable things as:
* The paint program with the usual interface, except you can also do
stuff like hit ~ and type "resample files:c:\foo\*.jpg width:640
height:480 preserveAspectRatio:true doNotEnlarge:false"
* The word processor with the usual interface, except you can also do
stuff like hit ~ and type "format leftIndent 2 where paragraph begins
'Quotation: '"
* The word processor with the usual interface where I can define
logical styles, then change them in only one place and affect every
pre-existing occurrence retroactively.
* The word processor with the usual interface where I can also view an
underlying markup representation and hand-hack that, and which likely
has the capabilities of the first two as a direct consequence of the
implied architecture. Only please, proper functional markup, not
macros like LaTeX or (shudder) winword. I don't want it to be possible
for documents of dubious origin to make it start sneezing, or any of
the general ugliness that follows TeX around like its shadow.
Documents that look as nice when displayed and printed, sure, but just
as nice under the hood if you please.
* Something as powerful as Mathematica, but with a more
straightforward basic-use interface as well as access to a fancy
interpreter.
* The operating system where you can do powerful stuff with a command
line and a script or two, but can also get by without either. (Windows
fails the former. Linux fails the latter.)
* For that matter, the operating system whose GUI takes the concept
behind OLE to its logical conclusion, and lets the user separately
choose and configure their text editing, this-editing, that-editing,
whosit-viewing, and the like components, and those components are used
in building more complex applications. All the alternatives would of
course adhere to a common interface for a particular sort of
component, of course. (An OO language like Java lends itself to this,
what with interfaces and inheritance and dynamic class loading!)
When I run my browser and go to GG to make a post I'd get a text entry
field that was actually my choice in a box, with the usual
capabilities such as spellchecking available, and its own little menu
bar at the top and suchlike. I'd be able to save the contents to disk
without futzing around with the clipboard and launching Notepad, and
later reload, in case the web site was prone to eating the odd
submission. My Jave IDE would display code in the same editor (the
interface should therefore support the using application externally
driving coloring/highlighting, as well as jump-to-line and similar
capabilities). Of course the editor wouldn't itself be Java-aware,
which might not be useful, for example composing a usenet post.
Instead it would provide a variety of abilities to the embedding
application, which may or may not use them. What it would provide
being its particular internal search, spell check, key bindings, etc.
> About the closest I've seen have been
> keyboard driven menu structures which have been designed so the user can
> build their own "command sequences" that traverse menu levels without
> showing the menus, as long as items are selected correctly from each
> level. Many CAD systems approximate to this but I've yet to see a
> graphical desktop, IDE, or editor menu structure that came close.
The bog-standard alt, this, that sequences on Windows "come close";
they do make the menus display, but otherwise they do exactly what you
want, and you can ignore the menus blinking around in your peripheral
vision. When I go to save a file with unsaved changes my first
inclination is ctrl+S; if the app doesn't support that the very next
thing I try is alt, f, s, before resorting to the mouse.
From: Martin Gregorie
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <ej32l4-051.ln1@zoogz.gregorie.org>
Twisted wrote:
> On Jun 23, 10:36 am, Martin Gregorie <······@see.sig.for.address>
> wrote:
>
> Actually, what I prefer in (2D and 3D) visual design apps is the
> ability to snap to some kind of grid/existing vertices, and to zoom in
> close. Then small imprecisions in mouse movement can be rendered
> unimportant.
>
That might work for visual design apps, but it doesn't for CAD, where
you may want to point to an arbitrary position with a (scaled) accuracy
of microns.
The fact remains that mechanical mice do jump when you click them,
though optical mice are better in this respect.
> The problem of course being the complete exclusion of type 1 users.
>
Totally untrue. They are the people that all the standard GUIs are
designed for and some (e.g Mackintosh) are very fast to learn. The
exclusion is down to the way that the purveyors of GUIs keep spreading
bullshit about how any untrained person can use a computer and never
mess it up or loose data. Thats not true and never can be: a computer is
the most complex device the average person will own or use and is likely
to retain that title for the foreseeable future.
I grant you that type 2 users are rare, but I think flight simulators
may fit this case when used for training.
> One with a bog-standard UI but also a "console" or command prompt,
> scripting language, and customizable bindings?
>
Not really. What's needed is a single interface that can be used by
anybody from beginner to expert and that, in the case of an error, shows
precisely where it got, what caused the action to fail to complete and
that allows the user to continue from that point without having to
undo/redo the bits that were successful. Its not easy, but it can be done.
> ROM BASICs and QBasic (on any really ancient microcomputer, and old
> pre-Windows PCs, respectively; the former came with printed manuals
> and you could just run prepackaged software from disks very easily;
>
Hang on: you don't read manuals. You object to using tutorials and to
buying books, so its a bit precious to claim this example.
> * The word processor with the usual interface where I can define
> logical styles, then change them in only one place and affect every
> pre-existing occurrence retroactively.
>
Thats been in Word since DOS days and is part of OpenOffice. Its called
a "style sheet". The only WPs I've used that didn't use them were
Wordperfect, WordStar, DEC WPS+ and the Wang dedicated WP systems. All
were horrid to varying degrees, with Wordperfect and Wordstar tying for
worst.
> * The word processor with the usual interface where I can also view an
> underlying markup representation and hand-hack that,
>
You're thinking of Wordperfect and its 'Reveal Codes' function. That was
the worst idea I've ever seen in a WP, matched only by the illogically
arranged set of 12 function keys, each with 4 shifts.
> and which likely has the capabilities of the first two as a direct
> consequence of the implied architecture.
>
It didn't. 'Reveal codes' could only let you inspect the current
document. Unfortunately it was essential to use it because some input
sequences could completely mess up the formatting and the only way to
recover was via 'Reveal codes'. The effect was similar to making a data
entry clerk use a hex editor on a database to fix keyboarding errors.
NOTE: I'm not talking about secretaries using WordPerfect. Those that
used it hated it. I'm talking about the experience of IT professionals
writing structured text, e.g. system specifications.
> * The operating system where you can do powerful stuff with a command
> line and a script or two, but can also get by without either. (Windows
> fails the former. Linux fails the latter.)
>
Here you're talking about two different interfaces again. The nearest
I've seen to good solutions at OS level were the CL interface provided
by ICL's VME mainframes and IBM's AS/400 systems. The latter was
particularly good, with a single unified text screen interface which
provided help screens, menus and a command line. You could search for
and find commands via a menu structure, and then use form filling to
provide the arguments, with help available at any stage. If you were
writing a script the entire menu and form filling system was available
from within the text editor - but when you hit ENTER the completed
command was written into your script instead of being executed.
Both OS/400 and VME were very consistent in the way they assigned
command names and argument keywords. In both OSen it was possible to
think "if there's a command to do this it will be called BLAHBLAH", type
the name, hit the command completion key and have the argument entry
screen pop up ready to be filled in.
BTW, in both OSen this capability applied to user-written scripts and
programs as well as to the standard command set. Both could claim to be
object oriented: the VME command language was derived from Algol-68,
arguably the granddaddy of all OO programming languages.
> * For that matter, the operating system whose GUI takes the concept
> behind OLE to its logical conclusion, and lets the user separately
> choose and configure their text editing, this-editing, that-editing,
> whosit-viewing,
>
The AS/400 editor did exactly that. There was only one, but it swapped
personality to match the task and was language-aware as well as
application aware. It produced form-filling interfaces to help you write
command scripts. If you were writing a program it gave language-specific
prompts and could run syntax checks on each statement as it was entered.
If you didn't want any of that, it would just quietly accept input like
any other text editor.
> The bog-standard alt, this, that sequences on Windows "come close";
> they do make the menus display, but otherwise they do exactly what you
> want, and you can ignore the menus blinking around in your peripheral
> vision.
>
No they don't: you can't easily string them together to act as a single
command and the error diagnosis and reporting is remarkably poor. Same
goes for Gnome, so I'm not particularly bashing Windows here.
--
······@ | Martin Gregorie
gregorie. | Essex, UK
org |
On Jun 24, 8:10 am, Martin Gregorie <······@see.sig.for.address>
wrote:
> > Actually, what I prefer in (2D and 3D) visual design apps is the
> > ability to snap to some kind of grid/existing vertices, and to zoom in
> > close. Then small imprecisions in mouse movement can be rendered
> > unimportant.
>
> That might work for visual design apps, but it doesn't for CAD, where
> you may want to point to an arbitrary position with a (scaled) accuracy
> of microns.
I didn't mention that you should be able to zoom and make the grid
fine to whatever limit is reasonable given the application? The issue
being, how accurate is "accurate enough"? Pinpoint precision isn't
possible, unless it's an integer or a functionally derived value like
pi or some arithmetic result of that. Grids are good for getting
rational numbers exactly, and nothing will hit the irrational ones
exactly, save if you can enter a formula for it to use to compute the
point's location to any desired precision. A mouse click (sans grid)
will always introduce some error; the zoom level lets you limit the
magnitude of the error. So does a grid, and to zero if the desired
point is a grid vertex, and to half the grid size more generally.
> The fact remains that mechanical mice do jump when you click them,
> though optical mice are better in this respect.
Ultimately, the button has to be non-mechanical for this sort of thing
to really work. Or else not physically part of the mouse. Being able
to "click" from the keyboard makes sense given such requirements. So
does being able to snap to a grid.
> > The problem of course being the complete exclusion of type 1 users.
>
> Totally untrue.
I'm not talking about in general. I'm talking about the specific sorts
of unixy applications that are under discussion here. Those
emphatically cater solely to type-3s and type-4s, aside from newer
graphical apps for KDE and Gnome, which are emerging as a third group
of type-1-accessible tool alongside Mac applications and Windows
applications.
> Thats not true and never can be: a computer is
> the most complex device the average person will own or use and is likely
> to retain that title for the foreseeable future.
What about the fabrication devices? Oh, but I suppose the "foreseeable
future" has already ended by the time those trickle down to widespread
consumer use.
> I grant you that type 2 users are rare, but I think flight simulators
> may fit this case when used for training.
Anything you have to use to meet some important external goal, I
suppose. But most usually there are options. A programmer needs a text
editor but it need not be emacs. Jobs requiring the use of specific
software (for training, or just on the job) maybe, of which your
example is a subset.
> Not really. What's needed is a single interface that can be used by
> anybody from beginner to expert and that, in the case of an error, shows
> precisely where it got, what caused the action to fail to complete and
> that allows the user to continue from that point without having to
> undo/redo the bits that were successful. Its not easy, but it can be done.
Why do those who have the skills, talent, knowledge, and thus
capability to do this insist on making cruft like emacs then? I've
never seen a classic-unix tool that didn't barf unhelpful and
uninformative error messages at the drop of a hat (just like Windows!)
and present a piss-poor UI, or even no UI at all (unless "usage: blah
blah blah" qualifies as a UI, to which my response is one word. "Non-
interactive.") When the error messages are informative, they're still
cryptic, and only someone with knowledge of the software's internals
has a hope in hell of fixing the problem as a rule. Of course, the
number one rule of interface design is to speak the user's language
and the language of the problem domain, and remain mute (except to
developers invoking debug modes) about the implementation details and
the language of the solution domain. Especially given that a different
version of the same software, nevermind a different app with the same
usage, is probably going to use a different implementation anyway. One
exception can be to expose a specific scripting language for advanced
users to use to automate tasks. Emacs does this, and it's one thing I
don't have a problem with. As long as knowledge of its arcana is not
needed to either do straightforward stuff, or fix the errors that
occur attempting to do straightforward stuff, anyway. If the beginner
can safely ignore the thing's existence (e.g. the VB-based scripting
language in some office and paint programs) it's fine.
> > ROM BASICs and QBasic (on any really ancient microcomputer, and old
> > pre-Windows PCs, respectively; the former came with printed manuals
> > and you could just run prepackaged software from disks very easily;
>
> Hang on: you don't read manuals. You object to using tutorials and to
> buying books, so its a bit precious to claim this example.
The manuals came with the computers, at no additional charge. It was a
different time. This isn't going to be true of any separately-
purchased book or user-made printout concerning emacs. Also, the
manuals provided a basic introduction for the beginning user. A
traditional-unix-tool providing anything resembling that would
genuinely shock me.
> > * The word processor with the usual interface where I can define
> > logical styles, then change them in only one place and affect every
> > pre-existing occurrence retroactively.
>
> Thats been in Word since DOS days and is part of OpenOffice. Its called
> a "style sheet".
I distinctly remember Winword circa 2002 not being able to
retroactively change all of a bunch of like-formatted paragraphs
easily. Not without delving into VBscript or something, anyway.
> You're thinking of Wordperfect and its 'Reveal Codes' function. That was
> the worst idea I've ever seen in a WP, matched only by the illogically
> arranged set of 12 function keys, each with 4 shifts.
Why?
> It didn't. 'Reveal codes' could only let you inspect the current
> document. Unfortunately it was essential to use it because some input
> sequences could completely mess up the formatting and the only way to
> recover was via 'Reveal codes'. The effect was similar to making a data
> entry clerk use a hex editor on a database to fix keyboarding errors.
Oh, because the implementation (of "reveal codes" and of everything
else) was awful, not because of any intrinsic flaw in the idea itself.
Would you want to edit a Web page without being able to hand-hack the
HTML? Use a GUI builder for Swing without being able to hand-hack the
Java? Thought not.
[Snip description of an advanced-for-its-time interface]
What happened to the guys that did all this stuff after it became
obsolete? Microsoft offer them $300 grand a year to mop floors or sit
in on various board meetings without a vote or something to get them
out of the way, being unable to use their talents competently and
equally unable to stand having them work for a competitor, or worse,
contribute to open source? Or offer a mob type $100 grand once to
whack them maybe?
> > The bog-standard alt, this, that sequences on Windows "come close";
> > they do make the menus display, but otherwise they do exactly what you
> > want, and you can ignore the menus blinking around in your peripheral
> > vision.
>
> No they don't: you can't easily string them together to act as a single
> command and the error diagnosis and reporting is remarkably poor. Same
> goes for Gnome, so I'm not particularly bashing Windows here.
You can string them together manually, or use a keyboard macro
recording and playback tool (they exist, though one doesn't come
standard with Windows; I think maybe one does with MacOS). It would be
nice if straightforward macro recording was standard in Windows
though.
On the other hand, I've not always been 100% sure of that sort of
thing. Even seemingly straightforward search-and-replace can suffer
from Sorceror's Apprentice Syndrome even at the best of times. And if
the thing treats every individual replace as a separate undoable
action instead of the one batch-of-replaces, and has a buffer of only
10 undos, and 13 items match, and one of them was unexpected and
shouldn't have been replaced...
Macro capabilities might be a dream, but macros running amok are a
nightmare. Maybe a real programmability would be better. I think the
scripting language capabilities in some apps provide that, with more
ability to control and constrain it from going into Sorceror's
Apprentice mode, but every app tends to have its own scripting
language and API and no real introduction-to-scripting type stuff,
leading us back to "the emacs problem" -- an arcane interface that
begins and ends in midair, with nowhere for the beginning user to
climb aboard, and differing from application to application so
limiting the value of investing much time in any one of them versus if
a single universal one were used (say Lua, or even elisp, or even
*gag* VB...)
From: Martin Gregorie
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <onp4l4-s5g.ln1@zoogz.gregorie.org>
Twisted wrote:
> The manuals came with the computers, at no additional charge. It was a
> different time. This isn't going to be true of any separately-
> purchased book or user-made printout concerning emacs. Also, the
> manuals provided a basic introduction for the beginning user. A
> traditional-unix-tool providing anything resembling that would
> genuinely shock me.
>
Oh, so manuals are OK and you'll read them if they are dead trees that
came in the same box as the software, but not if they're HOWTOs, online
documentation or O'Reilly books?
> I distinctly remember Winword circa 2002 not being able to
> retroactively change all of a bunch of like-formatted paragraphs
> easily. Not without delving into VBscript or something, anyway.
>
So you didn't read the free but thick and stodgy Word manual? Styles and
style sheets have been in Word since Word for DOS 5. Changing a style
sheet has always affected all documents that reference it.
>
> Oh, because the implementation (of "reveal codes" and of everything
> else) was awful, not because of any intrinsic flaw in the idea itself.
>
If a word processor, which by definition is provides a WYSIWYG user
interface, can't produce perfectly formatted text by editing a
representation of the finished result then its a deeply flawed program
and not fit for purpose.
By providing 'Reveal codes' and by being designed in such a way as to
force its regular use, Wordperfect reveals itself as being no better
than nrof or tex - its like expecting a user to write postscript source
with a text editor and providing a separate window with a Postscript
viewer to see what the final result will look like.
> Would you want to edit a Web page without being able to hand-hack the
> HTML?
>
Of course not, but HTML isn't anything to do with WYSIWYG and any system
(Coldfusion, Front Page, HTML from Word) that pretends it is WYSIWG is
both useless and perpetrating a fraud.
> What happened to the guys that did all this stuff after it became
> obsolete?
>
It isn't obsolete despite going back a looong way. The hardware and
software was originally developed as Future Series (intended S/360
replacement), was canned in 1970 but resurfaced in the late 80s as
System/38. A second generation appeared as AS/400, was renamed to (I
think) Z-series and are now known as iSeries servers. Its good, reliable
kit and easy to work with if you don't mind programming in RPG.
I know of no better "one size fits all" interface design than that
provided by the OS/400 operating system. Its still called that. Its a
pity the interface style hasn't been emulated by others.
> It would be nice if straightforward macro recording was standard in Windows
> though.
>
It was standard with Win 3.1 and 3.11 and it was bloody useless. Most
people I know tried it once or twice before giving up and writing .BAT
files or putting up with RSI. The problem was that it recorded
keystrokes and mouse clicks. Even minor changes to the screen layout
made it fail and the macros couldn't be edited or parameterised nor made
to prompt for filenames, etc.
You can do better with Gnome, thanks to tcl, but I think most people go
straight to Ruby or stick to plain vanilla shell scripts.
--
······@ | Martin Gregorie
gregorie. | Essex, UK
org |
On Jun 25, 8:40 am, Martin Gregorie <······@see.sig.for.address>
wrote:
> Twisted wrote:
> > The manuals came with the computers, at no additional charge. It was a
> > different time. This isn't going to be true of any separately-
> > purchased book or user-made printout concerning emacs. Also, the
> > manuals provided a basic introduction for the beginning user. A
> > traditional-unix-tool providing anything resembling that would
> > genuinely shock me.
>
> Oh, so manuals are OK and you'll read them if they are dead trees that
> came in the same box as the software, but not if they're HOWTOs, online
> documentation or O'Reilly books?
I think I need to clarify. What I expect is that I can have the
application and the documentation open side by side, a) without
needing to use the application's own navigation methods to navigate to/
from or within the documentation given that that can create a
catch-22, and b) without paying extra.
If a printed manual comes with the thing, without paying extra, then
it clearly qualifies as such documentation.
If I have to print it myself it doesn't, because ink doesn't grow on
trees. Paper does, but they still manage to charge money for that too.
If I have to purchase the manual separately it likewise doesn't.
So the options are: printed manual that ships with the software at no
extra charge, or online documentation I can read "the normal way".
Emacs in control of the console has neither. (Emacs relegated to a
single terminal window on a graphical workstation may not have such a
big problem.)
Regardless, having to reach for the help every two minutes doesn't
enamor me of an application unless there's a darn good reason for it,
such as it's actually rocket science. 3D modeling I expect to be
tricky at times. Text editing should be just-sit-down-crack-knuckles-
and-do-it obviously.
> > Oh, because the implementation (of "reveal codes" and of everything
> > else) was awful, not because of any intrinsic flaw in the idea itself.
>
> If a word processor, which by definition is provides a WYSIWYG user
> interface, can't produce perfectly formatted text by editing a
> representation of the finished result then its a deeply flawed program
> and not fit for purpose.
First, I didn't claim the ideal WP was necessarily perfectly WYSIWYG.
On the other hand, even so it might be that hand-hacking the
underlying representation might in some cases be a faster way to
achieve a particular goal than doing it "the WYSIWYG way". You'd still
have a WYSIWYG preview available either way of course.
> > Would you want to edit a Web page without being able to hand-hack the
> > HTML?
>
> Of course not, but HTML isn't anything to do with WYSIWYG and any system
> (Coldfusion, Front Page, HTML from Word) that pretends it is WYSIWG is
> both useless and perpetrating a fraud.
Your quiet change from discussing word processing to discussing
WYSIWYG is interesting. Is that how you generally go about fighting
your verbal battles, by quietly shifting the specific thing under
debate to whatever would have made your opponent blatantly wrong IF
they had been talking about that thing instead of what they really
were?
> > What happened to the guys that did all this stuff after it became
> > obsolete?
>
> It isn't obsolete despite going back a looong way. The hardware and
> software was originally developed as Future Series (intended S/360
> replacement), was canned in 1970 but resurfaced in the late 80s as
> System/38. A second generation appeared as AS/400, was renamed to (I
> think) Z-series and are now known as iSeries servers. Its good, reliable
> kit and easy to work with if you don't mind programming in RPG.
Programming in role-playing game? And I meant my roguelike-filesystem-
interface suggestion at least partly in jest...
Anyway, obsolete or merely obscure, it obviously failed to hit the big
time since us ordinary joes are still mostly using various forms of
Windoze and wishing for something more reliable and secure that didn't
also have gratuitous user interface weirdnesses.
> I know of no better "one size fits all" interface design than that
> provided by the OS/400 operating system. Its still called that. Its a
> pity the interface style hasn't been emulated by others.
If it's so great, why hasn't it, and why hasn't OS/400 managed to
escape from persistent obscurity?
> It was standard with Win 3.1 and 3.11 and it was bloody useless. Most
> people I know tried it once or twice before giving up and writing .BAT
> files or putting up with RSI. The problem was that it recorded
> keystrokes and mouse clicks. Even minor changes to the screen layout
> made it fail and the macros couldn't be edited or parameterised nor made
> to prompt for filenames, etc.
In other words, the implementation was a dog. That doesn't refute the
basic concept's validity. If it recorded mouse actions by noting the
keyboard equivalents (e.g. recorded a file menu drop down and file
open click as alt, f, o given that the application has the usual
keybindings in the file menu), and provided ways for advanced users to
edit them and such ...
In response to the other postings of the last 24 hours or so I have
just two things to say:
1. Regarding someone saying I had "no clue how to do things in Unix"
when I noted that the inability to copy and paste graphics or other
non-ascii data between applications caused awkwardness, I don't see
any grounds there for an insulting response. If desktop environments
do provide some mechanism suitable for generic clipboard actions (the
basic X clipboard is clearly inadequate) then they do so unobviously,
and probably all differently from one another. Being able to do
serious work with graphics requires being able to move snippets of
graphics around handily without all the mechanics of explicitly saving
them all to various temporary files, and later remembering to delete
the files. More generally, if a common Windows workflow isn't
supported, then even if an alternative workflow is that is as
effective and efficient it would take some getting used to.
Interface-wise, the world has standardized on how Windoze (and the
Mac) does things. Breaking such defacto standards makes software
harder to use by the vast majority of likely new users.
2. Regarding these graphical derivatives (apparently plural) of emacs,
has nobody considered that this means that Xah had already won before
he'd even fired his shot? :P Someone obviously felt the need for a
more usable emacs and delivered one. In that case it's a fait
accompli. Criticisms leveled at original-emacs shouldn't bother users
of the graphical versions regardless. The one complaint might be that
both of us had out of date information and were fighting a war our
side had already won years ago. :)
Unless of course these are all klunky bolted-on GUIs of the sort all
too common when porting unix software to Windows or the Mac or for use
under X, which don't work quite right or are clearly poorly integrated
with the application's internals...about which I currently have no
information. And no, I'm not about to spend hours downloading half a
gig of bloated who-knows-what just to find out, tyvm. :)
On Jun 25, 10:01 pm, Twisted <··········@gmail.com> wrote:
> 2. Regarding these graphical derivatives (apparently plural) of emacs,
> has nobody considered that this means that Xah had already won before
> he'd even fired his shot?
You have no idea what Xah was talking about.
Xah knows the ONE TRUE EMACS has had GUI capability
since early 1980s.
To summarize:
Richard Stallman was the original author of the original Emacs,
but he wrote it while he was an employee of another company,
so that company owned his code.
Richard Stallman then quit the company, rewrote Emacs from
scratch, and this emacs is now sometimes called the GNU emacs.
GNU emacs (and forks of it) is the only emacs today.
GNU emacs is a continuous product from about 1980 to 2007:
Richard Stallman is still writing code for it even now.
GNU emacs will gladly use the GUI library on the system
if available. So GNU emacs will launch Windows file menus
on Windows, and will launch GTK file menu on Linux, etc.
GNU emacs will also run in a text mode window gladly.
I use it all the time when I'm connected to a remote system
via SSH.
GNU emacs starts out with an initial help screen every time you run
it.
Every time.
If you don't believe one (or more) fact, please point out which one,
and we can try to prove it.
- JackT
On Jun 26, 12:23 am, JackT <········@gmail.com> wrote:
> the ONE TRUE EMACS has had GUI capability
> since early 1980s.
Sorry, I meant early 1990s.
I believe it was 1993 or so (it is in the web page).
- JackT
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <853b0f8w59.fsf@lola.goethe.zz>
Twisted <··········@gmail.com> writes:
> 2. Regarding these graphical derivatives (apparently plural) of
> emacs,
Emacs is a graphical derivative of Emacs? What nonsense. The
canonical Emacs as distributed and copyrighted by the FSF is a GUI
application on a large number of platforms.
> has nobody considered that this means that Xah had already won
> before he'd even fired his shot? :P
It just means that you have no clue what Xah has been talking about.
Xah was concerned about keybindings and terminology. Never mind that
there are menus (with keyboard shortcuts displayed automatically),
toolbars, scrollbars, multiple frames, font support, mouse support and
so forth and so on. Xah knows this since he actually _uses_ Emacs.
> Someone obviously felt the need for a more usable emacs and
> delivered one. In that case it's a fait accompli. Criticisms leveled
> at original-emacs shouldn't bother users of the graphical versions
> regardless.
The graphical versions _are_ original Emacs.
> The one complaint might be that both of us had out of date
> information and were fighting a war our side had already won years
> ago. :)
You just have no clue what Xah has been talking about.
> Unless of course these are all klunky bolted-on GUIs of the sort all
> too common when porting unix software to Windows or the Mac or for
> use under X, which don't work quite right or are clearly poorly
> integrated with the application's internals...about which I
> currently have no information.
You have had no information about _anything_ right from the start.
> And no, I'm not about to spend hours downloading half a gig of
> bloated who-knows-what just to find out, tyvm. :)
You could start with the current NEWS file at
<URL:http://cvs.savannah.gnu.org/viewvc/emacs/etc/NEWS?root=emacs&view=markup&pathrev=EMACS_22_1>
which describes everything which is new in Emacs 22.1 (and will give
quite a few ideas about what has already been there in earlier
versions).
Of course, you'll whine together some excuse why you can't be bothered
getting some information about Emacs, never mind that you post several
dozens of embarrassing tirades that are completely based on nonsense
of your own imagination.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Martin Gregorie
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <foa7l4-2cp.ln1@zoogz.gregorie.org>
Twisted wrote:
>
> First, I didn't claim the ideal WP was necessarily perfectly WYSIWYG.
>
Maybe I should have clarified my viewpoint. When it comes to programs
that operate on the content of textual documents a word processor is
WYSIWYG by definition. Anything else is a text editor. You may have a
different view but that's mine.
> Your quiet change from discussing word processing to discussing
> WYSIWYG is interesting.
>
See above. We were actually discussing text editors whose formatting
capabilities (unless they are syntax-sensitive) are generally limited to
line wrapping and auto-indentation. You introduced more complex document
reformatting - something that I regard as a capability of word
processors rather than text editors.
> Programming in role-playing game? And I meant my roguelike-filesystem-
> interface suggestion at least partly in jest...
>
RPG is "Report Generating Program" in the context of programming
languages. The RPG language is horrid: its a bastardized, fixed column
assembler derivative that's been shoehorned into a typical report
generator's processing loop. Even PL/1 and COBOL shine as paragons of
programming language design by comparison.
> If it's so great, why hasn't it, and why hasn't OS/400 managed to
> escape from persistent obscurity?
>
A fair question. I don't know, but it probably has a lot to do with AIX
and the UNIX command shell with its great power but lack of consistency
in naming, etc.
> In other words, the implementation was a dog. That doesn't refute the
> basic concept's validity.
>
True, but doing better would be really hard because of all the
information and context that would need to be associated with every
mouse click in case it was needed to record a macro. At best it might
make macro recording tedious. At worst it could make the whole GUI
unresponsive.
--
······@ | Martin Gregorie
gregorie. | Essex, UK
org |
From: Andreas Eder
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <86645drtzw.fsf@eder.homelinux.net>
Hi Twisted,
>>>>> "Twisted" == Twisted <··········@gmail.com> writes:
Twisted> * The operating system where you can do powerful stuff with a command
Twisted> line and a script or two, but can also get by without either. (Windows
Twisted> fails the former. Linux fails the latter.)
Twisted> * For that matter, the operating system whose GUI takes the concept
Twisted> behind OLE to its logical conclusion, and lets the user separately
Twisted> choose and configure their text editing, this-editing, that-editing,
Twisted> whosit-viewing, and the like components, and those components are used
Twisted> in building more complex applications. All the alternatives would of
Twisted> course adhere to a common interface for a particular sort of
Twisted> component, of course. (An OO language like Java lends itself to this,
Twisted> what with interfaces and inheritance and dynamic
Twisted> class loading!)
Have a look at Genera, the OS of the Lisp Machines. It offers all
that and much more. Unfortunately it is almost non existent
nowadays.
'Andreas
--
Wherever I lay my .emacs, there's my $HOME.
From: ······@myrealbox.com
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <5eaptcF378d21U3@mid.individual.net>
In article <·······················@g4g2000hsf.googlegroups.com>,
Twisted <··········@gmail.com> wrote:
> On Jun 23, 10:36 am, Martin Gregorie <······@see.sig.for.address>
> wrote:
[ snip ]
> * The operating system where you can do powerful stuff with a command
> line and a script or two, but can also get by without either. (Windows
> fails the former. Linux fails the latter.)
About the latter -- it's hard for me to be sure, since for many
things something with a GUI is not my first choice of tool, but
my impression is that on "user-friendly" Linux distributions,
pretty much everything, including sysadmin stuff, can be done by
pointing and clicking, starting with the menus displayed on the
default desktop. Perhaps someone with more/different experience
can comment on how many things still require scripting or a
command line.
[ snip ]
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
On Jun 25, 5:20 pm, ······@myrealbox.com <······@myrealbox.com> wrote:
> In article <·······················@g4g2000hsf.googlegroups.com>,
>
> Twisted <··········@gmail.com> wrote:
> > On Jun 23, 10:36 am, Martin Gregorie <······@see.sig.for.address>
> > wrote:
>
> [ snip ]
>
> > * The operating system where you can do powerful stuff with a command
> > line and a script or two, but can also get by without either. (Windows
> > fails the former. Linux fails the latter.)
>
> About the latter -- it's hard for me to be sure, since for many
> things something with a GUI is not my first choice of tool, but
> my impression is that on "user-friendly" Linux distributions,
> pretty much everything, including sysadmin stuff, can be done by
> pointing and clicking, starting with the menus displayed on the
> default desktop.
With the latest stuff like Ubuntu, you're pretty much right ... until
something goes wrong. Windows has safe mode and System Restore and, if
push comes to shove, a recovery disk or partition. Linux has ... the
command line, or worse a GRUB or fsck prompt at startup. No access to
accessible, easy to browse help right when you need it most.
Blow away the partition with everything on it and reinstall? y/n _
Sometimes it's not that bad. Sometimes it's just some X thing needing
tweaking, or a particular thing elsewhere that's broken, but it
requires at minimum hand-hacking a .rc file and running some stuff in
a terminal window (aka command line, but with maybe more easily
available and navigable help, since at minimum you can open two side
by side and leave one open to the output of man or less).
Twisted wrote:
> With the latest stuff like Ubuntu, you're pretty much right ... until
> something goes wrong. Windows has .
[...]
> Linux has ... the
> command line, or worse a GRUB or fsck prompt at startup. No access to
> accessible, easy to browse help right when you need it most.
I suppose you never used Ubuntu's disc for anything but installing or
reformatting either, but that doesn't mean it's the only thing that
can be done with it. You can boot with it, have a working net
connection (or create it) and solve many problems in the comfort of
the full GUI, and with all the help available from the web.
As for the available help on Windows, I didn't know Windows Safe mode
let you connect to the Intertubes, or that its help was of any help in
those situations.
Really, if you have no idea, it's ok to refrain from posting.
--
Saludos
Adriano
On Jun 26, 2:01 am, Adriano Varoli Piazza <·······@gmail.com> wrote:
> Twisted wrote:
> > With the latest stuff like Ubuntu, you're pretty much right ... until
> > something goes wrong. Windows has .
> [...]
> > Linux has ... the
> > command line, or worse a GRUB or fsck prompt at startup. No access to
> > accessible, easy to browse help right when you need it most.
>
> I suppose you never used Ubuntu's disc for anything but installing or
> reformatting either, but that doesn't mean it's the only thing that
> can be done with it. You can boot with it, have a working net
> connection (or create it) and solve many problems in the comfort of
> the full GUI, and with all the help available from the web.
Ah, if you have a live CD this might indeed be possible. If you can
get it to mount your usual hdd partitions to go sniffing around the
configuration files that might be gummed up, and if doing this isn't
insanely complicated anyway.
A Windows restore CD or recovery partition doesn't do anything of the
sort, although a genuine install CD has a repair function, which can
among other things fix problems with the MBR and reinstall key Windoze
components on the hdd. If you can boot to safe mode you can fix most
things with System Restore, which simply lets you roll back the
configuration to before that ill-advised install, uninstall, driver
update, or whatever it was that hosed things. I've had to resort to it
exactly twice; once when firewall software b0rked the system on
install and put it in infinite-reboot mode (safe mode halted the loop)
and once when nVidia released some driver update that hosed the 3D
accelerator and screwed up the available graphics modes. System
Restore works by quietly backing up key files (DLLs, config files, and
suchlike) and registry trees when an installer is run and under some
other circumstances, including a manual instruction to create a save
point, which you can use before you try anything dodgy so you can roll
back to right before the attempt if it goes wrong. Ordinary document
files and the like aren't backed up or anything by this, however. If
they get hosed, they get hosed, although System Restore won't damage
them any more than it will back them up.
I've managed to fix driver and networking problems a few times, and
sometimes on someone else's computer, with and without system restore.
Most of the times if I've seen any flavor of unix misbehaving, it's
been find a bigger geek or resort to beads and rattles; it's been far
from obvious what the problem was from the error messages, let alone
what the fix was, and often the problem precluded access to any useful
tools or documentation simultaneously. A live CD might make that less
of an issue, though it would still be a pain if you had to keep using
it as a workaround for days while waiting for a mailing list or usenet
response explaining what the f*#! "bad zixflob in fuzzwangle.rc,
aborting" meant and how to fix it, especially as a system-wide search
didn't turn up any files named "fuzzwangle.rc" -- or whatever the
problem was. :)
[Insulting insinuation snipped]
Oh, sod off.
From: Matthias Buelow
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <5eclebF37uh5mU1@mid.dfncis.de>
Twisted wrote:
[...]
Hey dude,
get back to selling used cars and leave us computer geeks alone, will ya?
Thanks.
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <867ipqsshi.fsf@lola.quinscape.zz>
Matthias Buelow <···@incubus.de> writes:
> Twisted wrote:
>
> [...]
>
> Hey dude,
>
> get back to selling used cars and leave us computer geeks alone,
> will ya?
Well, how will his customers react to the stories about avoiding
Mercedes cars because of people getting hit in the face by the crank
start?
--
David Kastrup
Twisted wrote:
> You end up having to memorize the help, because *you can't
> have arbitrary parts of the help and your document open side by side
> and be working on the document*.
WTF? Of course you can. http://oldr.net/emacs_two_frames.png
> I don't know why people keep harping about what version.
Perhaps because essentially none of the crap you're spouting corresponds
to remotely recent versions of emacs they're are aware of. I'd be
increasingly dubious much applies to any previous versions either.
If everyone had such bizarre problems you describe yourself as having
with emacs, well, nobody would be using it. That is clearly not the
case. Of course, no one's pointing a gun at you and making you use it,
either - if you like notepad or joe or whatever, just use them instead.
From: Robert Uhl
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3hcoz2olj.fsf@latakia.dyndns.org>
Twisted <··········@gmail.com> writes:
>
> How clunky versus usable an interface to a tool is is for those who
> invest some, but not extraordinary amounts of, time into its use to
> decide. If it requires years of mastery, it is clunky -- period. This
> may be unavoidable if it's something involved in nuclear power plants,
> delicate neurosurgery, or whatever. If it's a text editor, on the
> other hand, it's clearly going to have superior competition in the
> area of usability.
Of course, emacs doesn't take years of mastery. It takes 30, 40
minutes. And a functioning intellect, of course.
Incidentally, a violin requires years of mastery, and is hardly cranky.
Granted, there are few people with the talent to play a violin well.
Maybe an automobile is a better example...
> Besides, ANY interface that involves fumbling around in the dark
> trying to find a light switch is clunky.
That sounds like vi, not emacs.
> Applications that not only eschew normal methods of navigation of the
> interface, but force you to fumble your way between the help and the
> task you're trying to do, are definitely clunky.
a) emacs doesn't 'eschew normal methods of navigation'; it's been doing
its own thing since before there _were_ Mac OS or Windows
b) I believe you've never used the emacs tutorial, which is quite
definitely designed for you _not_ to have to fumble around between
windows
> The interface never improved over that time -- the biggest problem
> consistently being that whenever focus was successfully transferred to
> the document window, the help window was invariably open to the
> instructions for switching windows, so you could never be doing
> something with the document and have the help for that something
> available at a glance.
That doesn't even make sense. Either your memory is faulty, you've
never actually used emacs (something I'm beginning to suspect more and
more) or you're just making things up. If I'm browsing the manual
online, I can switch from said manual to my document buffer without
making the manual scroll to the documentation for switch-to-buffer. In
fact, I am not aware of any package which auto-changes the *info* or
*Help* buffers to reflect the last keyboard command.
> Even though it would be at the price of no full- text search
> capability -- not that I could ever get that to work in emacs
> anyway. There was no apparent way to do a simple substring search and
> click "next match" or "previous match" to navigate among the
> hits...more arcane keypresses would be required, and as soon as it
> showed you the first match inside the help, the keypress documentation
> of course vanished.
Dude, you hit C-s; you're prompted for a search string; you hit C-s to
search for the next match. From line 899 of the tutorial:
>> Now type C-s to start a search. SLOWLY, one letter at a time,
type the word 'cursor', pausing after you type each
character to notice what happens to the cursor.
Now you have searched for "cursor", once.
>> Type C-s again, to search for the next occurrence of "cursor".
If you had actually, you know, actually _read_ it this would not be a
surprise. I hate to be rude, but I just don't see how you could ever
have actually done what you claim to have done.
> Infrequently used commands you can stand to hunt for in menus. When
> you find you use one frequently, you can try to learn the keyboard
> shortcut -- and you can find it without even consulting the help,
> simply by finding the command's menu item.
This is no different from emacs. There's a menu bar; it displays
commands and shortcuts next to them; one can learn to use them instead,
at one's own pace.
> Every time you want to use the command but can't remember the shortcut
> you just find it in the menu and activate it from there, and see the
> shortcut while you're at it, helping to eventually memorize it. And
> the commonest sorts of File and Edit menu items have near-universal
> shortcuts, the big variation tending to be whether Redo is
> shift-ctrl-Z, ctrl-Y, nonexistent, or menu-only.
You've actually hit on another advantage of emacs: consider emacs itself
as an operating system hosting multiple applications, in which the vast
majority of commands are the same. I can use the same text-editing
commands for reading & writing emails, reading & writing Usenet posts,
reading & writing code, browsing the web, organising my schedule and so
forth.
The vast majority of what we do on a computer is reading & writing
text--wouldn't it be cool to have a full-fledged text editing
environment always available for that sort of thing? Wouldn't it be
cool not to have one program implement search in one way, and another a
second way, and yet another a third? Wouldn't it be cool to have access
to a proper text editor when editing text on a web page?
> But you can start using it right away with low productivity, and
> increase your productivity with proficiency and learning (optional)
> shortcuts, chiefly those to the commands you happen to use a lot.
That's how I learnt emacs. I was 13, and had only ever used Mac
software up until that point. I had a fairly limited command set
(basically, C-x C-f, C-x C-s & C-x C-c).
> One person elsewhere in this thread even went so far as to suggest
> that to avoid having a similar hurdle with every application you just
> use emacs for everything. If you like being claustrophobically trapped
> in 80x24x8BPP instead of 1280x1024x32BPP, that may be your cup of tea.
Do you realise that emacs has a GUI these days? I'm writing this in a
70-line window, with gtk+ widgets. Which means full-resolution,
full-colour.
--
Robert Uhl <http://public.xdi.org/=ruhl>
A wealthy man is one who earns $100 a year more than his wife's sister's
husband. --H.L. Mencken
On Jun 23, 2:04 am, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> Of course, emacs doesn't take years of mastery. It takes 30, 40
> minutes.
I gave it twice that, and it failed to grow on me in that amount of
time.
> > Besides, ANY interface that involves fumbling around in the dark
> > trying to find a light switch is clunky.
>
> That sounds like vi, not emacs.
That sounds like any application where you need to read the help, but
"f1" does not bring up a separate help window, switchable with the
main one using alt-tab or the mouse, and navigable using arrows,
pageup, pagedn, and the mouse. The result of that is invariably that
when the document has the focus, the help is open to "help on
switching windows" rather than whatever you need it to be on once the
document has the focus. You can read the help on doing what you want
to do with the document, but to apply it you need to transfer focus
back to the document. If doing that isn't second-nature, you have to
navigate the help away from where you need it to get the focus back to
the document. Now the focus is on the document, but the help you need
isn't displayed next to it anymore. Frustrating? You can't begin to
imagine, I suspect. Apparently, some people are born somehow able to
avoid this problem without having to memorize one or the other piece
of help. You're clearly one of those. I am equally clearly NOT one of
those. Of course, if emacs let you keep THREE windows open and visible
at the same time, instead of being limited to one or a horizontally
split two ... and a cramped 80x10 or so each, at that ...
> > Applications that not only eschew normal methods of navigation of the
> > interface, but force you to fumble your way between the help and the
> > task you're trying to do, are definitely clunky.
>
> a) emacs doesn't 'eschew normal methods of navigation'; it's been doing
> its own thing since before there _were_ Mac OS or Windows
I'll admit that it didn't USED TO 'eschew normal methods of
navigation', but at a certain point in time there began to be 'normal
methods of navigation' and emacs naturally began eschewing them
promptly and has done so ever since.
> b) I believe you've never used the emacs tutorial, which is quite
> definitely designed for you _not_ to have to fumble around between
> windows
If I haven't, it must be the case that finding this tutorial (or even
discovering that it exists) was nontrivial, or it wasn't built into
emacs, one or the other. My memory is somewhat fuzzy after all these
years so you'll forgive me if I don't make a definite statement about
which. On the flip side, if I have, the tutorial can't have been all
it's cracked up to be. Especially given I can program Java
proficiently, including some fairly sophisticated network-using tools,
and clearly am not an idiot or untalented in technically demanding
areas involving substantial amounts of arcana. Of course, I might have
put more effort into learning effective Java; effort like that in
learning some language is necessary to being a programmer. Thanks to
modern editors and IDEs, putting a comparable amount into learning the
mere mechanics of operating a text editor is not necessary, and I
chose to spend the time and effort elsewhere, where it was necessary,
such as on learning a programming language.
The technical term for managing limited resources, such as time and
effort, first where needed and never where avoidable, is "efficiency",
in case you were unaware.
> > The interface never improved over that time -- the biggest problem
> > consistently being that whenever focus was successfully transferred to
> > the document window, the help window was invariably open to the
> > instructions for switching windows, so you could never be doing
> > something with the document and have the help for that something
> > available at a glance.
>
> That doesn't even make sense. Either your memory is faulty
Impossible
> you've never actually used emacs
Untrue
> or you're just making things up.
Also untrue, and you've just accused me of incompetence once and of
lying twice, which in a formerly civil discussion constitutes behavior
that I consider to be in poor taste.
> If I'm browsing the manual
> online, I can switch from said manual to my document buffer without
> making the manual scroll to the documentation for switch-to-buffer.
Apparently because you find the switch second nature, despite its not
being the obvious (which is ctrl-tab, to switch between documents in
an MDI app). Cheat sheet? Memorized with painstaking months of hard
effort? Thanks for proving my point, either way.
> In fact, I am not aware of any package which auto-changes the *info* or
> *Help* buffers to reflect the last keyboard command.
I didn't say it auto-changes. It manual-changes. The exact sequence of
events that causes this with a novice user being:
* Need to do X, and the usual command doesn't work (e.g. go to save
document and get search prompt)
* Now nothing much works (typing stuff bleeps), hit esc a bunch of
times
* Now it complains of hitting esc too many times, but typing into the
document at least works again
* OK, time to resort to *gulp* the help.
* Oh, great, now what did it do? I hit F1 and ...
* Eh. Try random stuff. Help starts with h. Alt-h? Ctrl-h? ...
* Oh, right. I seem to remember the help popping up unwanted when I
tried to backspace over a typo earlier, so I'll just do that.
* Hrm, now how to search the bloody thing?
* <Hours pass, some spent trying ctrl+f and ctrl+s, mostly
fruitlessly, followed by a load of scrolling>
* Ah. "How to do Foobar to your open document". Perfect!
* Oh crap. How do I do anything to my open document, when the focus is
on the help instead of the document?
* <Scrolling for ten minutes>
* Ah, I hit this. It worked!
* Oh, fudge. Where did "How to do Foobar to your open document" go?
The help's open to "How to switch windows". For shame.
* Switch back, scroll ... there it is.
* Crap, now I don't remember how to put the focus back on the document
window.
* More scrolling.
* Oh, fudge. Where did "How to do Foobar to your open document" go?
The help's open to "How to switch windows". For shame.
* <however many repetitions of the preceding 4 lines>
* Error: Stack overflow. Dumping core.
I trust you get the picture.
[snip]
Whoa, what did you just say? Page 899 of the ... good Christ. Er ...
Run! Flee! It's a monster! Head for the hills! Sound the civil defense
sirens, tornado TORNADO! *runs*
> > Infrequently used commands you can stand to hunt for in menus. When
> > you find you use one frequently, you can try to learn the keyboard
> > shortcut -- and you can find it without even consulting the help,
> > simply by finding the command's menu item.
>
> This is no different from emacs. There's a menu bar
What are you blithering about? Oh, great, now I'm using the term
"blithering". :P But ...
WHAT menu bar? We're discussing emacs. As in, a text-mode editor. As
in a cramped little 80x24 grid of letters, numbers, spaces, and
punctuation with no menus, no concept of a pointing device, and a bad
attitude.
Actually, the big thing the GUI and mouse did was rescue us from
escalating UI problems with tasks complex enough to require modes. You
needed either separate components with separate associated
functionality and a "focus" to move among them, or you needed commands
and keyboard-toggled modes. The former got you an emacs and the "can't
switch back from the help" syndrome, and the latter got you ...
something vile.
Until the GUI-with-pointing device, which made user control of a
"focus" a snap requiring virtually zero learning curve, and better
yet, what little learning there was being transferred readily across
applications. Unified windowing systems, with Macs and Windows,
cemented the victory of the pointing device over the problem of focus
management. Point at the thing you want to use next and click; that
simple. A child can do it. Using a GUI is like doing a job yourself,
such as washing the car. Using something from the dinosaur age,
especially afterwards, feels like sitting back and directing some
hired help. Help that happens to be blind as a bat as well as having
the usual poor grasp of English. "Left, Senor. Right, Senor. No not
THAT far right! Now you've gotten it all into the open drivers-side
window, and those documents I left on the front seat are ruined!"
Ouch. Yet trying to control old text-mode tools is pretty much exactly
the same, only the flawless English it speaks belies an even dodgier
grasp of same, or even the need to speak to it in some obscure dialect
of Greek full of "meta" instead...and it doesn't apologize when
there's a screwup a more hands-on interface would easily have
prevented.
If you want a job right, do it yourself. With a mouse, you can; no
need to speak an obscure variant of Swahili into a keyboard just to
get the focus to the document from the help or wherever. And to top it
off, every Windows app understands tab and alt-tab and most understand
ctrl-tab. Actually, the OS GUI components themselves understand alt-
tab, and the applications just get told the focus went elsewhere or
came back, making it one less area for application designers to screw
things up. (All too often, they screw up ctrl-tab in tabbed/MDI apps,
or screw up tab by using a dodgy tab order or controls with no visual
indication of focus, mind. And then you can just resort to the mouse,
rather than throw up your hands or find something non-electronic to
sob into so as to avoid ruining another $40 keyboard.)
> You've actually hit on another advantage of emacs: consider emacs itself
> as an operating system hosting multiple applications, in which the vast
> majority of commands are the same.
It's an "operating system" to precisely the extent Windows 3.1 was.
It's like Windows 3.1 in a number of other ways too, including size
and aesthetics, though not stability. Even more like its predecessor
DOSShell.
Take that however you wish.
At least Windows 3.1 had most apps have the same keys for the vast
majority of commands, and those were the right keys. Emacs has all the
applications have the vast majority of their commands use the same
WRONG keys. Including whatever you'd use to rebind them. And the help
you'd use to find out what the damn keys are in the first place. ;)
And let's not forget that to someone with a 17" LCD monitor and a
blisteringly fast graphics card, 80x24 text in a terminal emulator is
somewhat underwhelming, and doesn't provide anything like the
information density needed to make truly complex software interfaces
usable. The human optic nerves have about 100Mbps of bandwidth *each*;
that's a couple of ethernet cables directly into the cortex. Even a
large, high resolution, big-color-gamut display with a decent refresh
rate doesn't use more than a fraction of that capacity to deliver
information to the user, even when the display is used to maximum
advantage by the software to provide state information and navigation
cues (and document views!).
Those dim old greenly-glowing 80x24 terminals flickering at 20-odd Hz,
by contrast ... barely adequate to design their own replacements on,
though necessary for same. It's a good thing some people are
apparently very good at maintaining most of the state information in
their head that that tiny little box of text isn't displaying to them,
and "reading between the lines" to make use of even fairly complex
applications through such a tiny interface. Or those replacements
might never have been built.
> I can use the same text-editing
> commands for reading & writing emails, reading & writing Usenet posts,
> reading & writing code, browsing the web, organising my schedule and so
> forth.
I'm not sure that's such an advantage. Sometimes, unifying tasks too
much creates security holes, especially when some of those tasks are
network-facing and some are not. Some proposed or actual Windows
features result in an unclear boundary between "my computer" and "the
net out there", and that's bound to result in leaked passwords and
credit-card numbers and all manner of other accidental breaches, as
well as enable a variety of new social engineering attacks to
purposely compromise more of the same. Phishing and similar attacks
already pose a problem, but if the "phishing" looks like it's local
applications or content instead of online, it's even more likely to be
mistakenly trusted.
One sometimes wonders if Microsoft has more sinister motives than "get
rich with as shoddy and cheap a product as possible" in light of
things like this. I do hope the unified stuff you describe in emacs
isn't the open source equivalent. There's frank danger in making it
too easy to mix up local stuff and online stuff while at work at a
computer.
> The vast majority of what we do on a computer is reading & writing
> text--wouldn't it be cool to have a full-fledged text editing
> environment always available for that sort of thing?
Define "we". It can't be "people", because a substantial fraction of
people use computers heavily for image or even 3D manipulation, or
sound, rather than text, or a mixture with text not predominant, and a
much larger fraction use computers for absolutely nothing at all.
"Programmers" maybe. Even so, some people program from time to time
but do a lot of, say, image manipulation.
I expect even most programmers like to be able to see what the heck
they're doing, rather than resorting to fumbling around with a
flashlight or grunting terse instructions to a blind butler with an IQ
in the mid-zeros.
> Wouldn't it be cool not to have one program implement search in one way, and another a
> second way, and yet another a third? Wouldn't it be cool to have access
> to a proper text editor when editing text on a web page?
Search is usually ctrl+f, type something, hit enter in my experience.
And I can use any text editor I want to edit HTML.
> That's how I learnt emacs. I was 13, and had only ever used Mac
> software up until that point. I had a fairly limited command set
> (basically, C-x C-f, C-x C-s & C-x C-c).
That looks like three commands, although I can't be sure -- my Swahili
is a little rusty from years of disuse. ;)
I'd normally use at least eight -- open, save, quit, find/find next,
replace, cut, copy, and paste. That's not counting arrows, page up,
page down, del, backspace, and the like, and unixy tools don't let you
take even THOSE for granted. And if I needed more, add help. Add the
four arrows, page up, page down, delete-forwards, backspace, and help
to the original eight and we now have 17 commands. I seriously doubt
that your short chunk of Swahili up above encompasses all of them.
> Do you realise that emacs has a GUI these days? I'm writing this in a
> 70-line window, with gtk+ widgets. Which means full-resolution,
> full-colour.
What are you talking about? Clearly not emacs, which is a console app
for unix systems (with the inevitable MS-DOS ports and others). Some
sort of bastardized Windows port I suppose? I've seen the occasional
attempt at a Windows port of a unix tool, and the results are fairly
uniformly awful. Everything looks mostly right, and nothing works
quite right. They're often actually more unstable than native Windows
apps, probably because the porters don't know half as many of the
landmines littering the windoze APIs as real Windows application
programmers do (and *they* only know maybe half of the total, to judge
by the stability of even higher-quality Windows apps) and because they
are bolting on a thin layer of Windows widgets onto a core that works
in ways fundamentally alien to those same APIs. No real Windows app
dares to try spawning around 700 threads to service a request to copy
two lines of text to the clipboard, for example. :)
On Sun, 24 Jun 2007 04:57:20 -0000, Twisted <··········@gmail.com> tried to
confuse everyone with this message:
>On Jun 23, 2:04 am, Robert Uhl <·········@NOSPAMgmail.com> wrote:
>> Of course, emacs doesn't take years of mastery. It takes 30, 40
>> minutes.
>
>I gave it twice that, and it failed to grow on me in that amount of
>time.
>
>> > Besides, ANY interface that involves fumbling around in the dark
>> > trying to find a light switch is clunky.
>>
>> That sounds like vi, not emacs.
>
>That sounds like any application where you need to read the help, but
>"f1" does not bring up a separate help window, switchable with the
>main one using alt-tab or the mouse, and navigable using arrows,
>pageup, pagedn, and the mouse. The result of that is invariably that
>when the document has the focus, the help is open to "help on
>switching windows" rather than whatever you need it to be on once the
>document has the focus. You can read the help on doing what you want
>to do with the document, but to apply it you need to transfer focus
>back to the document. If doing that isn't second-nature, you have to
>navigate the help away from where you need it to get the focus back to
>the document. Now the focus is on the document, but the help you need
>isn't displayed next to it anymore. Frustrating? You can't begin to
>imagine, I suspect. Apparently, some people are born somehow able to
>avoid this problem without having to memorize one or the other piece
>of help. You're clearly one of those. I am equally clearly NOT one of
>those. Of course, if emacs let you keep THREE windows open and visible
>at the same time, instead of being limited to one or a horizontally
>split two ... and a cramped 80x10 or so each, at that ...
What an idiot. At least get yourt facts straight before posting such bullshit.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Timofei Shatrov wrote:
> What an idiot. At least get yourt facts straight before posting such
> bullshit.
I think at this stage it's quite reasonable to assume he's trolling, and
recycling old trolls, too. Certainly looks like someone very like him
used to haunt rec.games.roguelike.development as "Neo" and "Twisted
One", in the 2005 era. Of course, by bothering to point this out, I'm
giving him more attention, the recognition he presumably craves, my
bad.
http://groups.google.com/group/rec.games.roguelike.development/msg/6f0fac979ef1d117
"""
Message-ID: <······················@rogers.com>
Date: Tue, 22 Mar 2005 19:00:06 -0500
From: Twisted One <··········@gmail.invalid>
Emacs doesn't let you do that either. It lets you have exactly two
panes.
"""
http://groups.google.com/group/rec.games.roguelike.development/msg/cfd723fbdc4a93f8
"""
From: David Damerell <········@chiark.greenend.org.uk>
Date: 23 Mar 2005 13:22:00 +0000 (GMT)
Message-ID: <·········@news.chiark.greenend.org.uk>
Quoting Twisted One <··········@gmail.invalid>
>Emacs doesn't let you do that either. It lets you have exactly two
>panes.
No, this is completely false.
"""
... So, probably deliberately trolling, or just maybe a learning
difficulty - literally (corrected on multiple occasions, still
failed to learn).
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <85zm2petec.fsf@lola.goethe.zz>
Twisted <··········@gmail.com> writes:
> On Jun 23, 2:04 am, Robert Uhl <·········@NOSPAMgmail.com> wrote:
>
>> > Besides, ANY interface that involves fumbling around in the dark
>> > trying to find a light switch is clunky.
>>
>> That sounds like vi, not emacs.
>
> That sounds like any application where you need to read the help, but
> "f1" does not bring up a separate help window, switchable with the
> main one using alt-tab or the mouse, and navigable using arrows,
> pageup, pagedn, and the mouse.
Well, f1 brings up a prompt: f1 (type ? for further options)-
Typing ? brings up a separate window (and instructions how to scroll
it) with a variety of help options, among them the tutorial. If you
want a separate window, File/New Frame will give you that. Of course,
switchable with the main one using alt-tab or the mouse, and navigable
using arrows, pageup, pagedn and the mouse.
> The result of that is invariably that when the document has the
> focus, the help is open to "help on switching windows" rather than
> whatever you need it to be on once the document has the focus. You
> can read the help on doing what you want to do with the document,
> but to apply it you need to transfer focus back to the document. If
> doing that isn't second-nature, you have to navigate the help away
> from where you need it to get the focus back to the document.
Nonsense.
> Now the focus is on the document, but the help you need isn't
> displayed next to it anymore. Frustrating? You can't begin to
> imagine, I suspect. Apparently, some people are born somehow able to
> avoid this problem without having to memorize one or the other piece
> of help. You're clearly one of those. I am equally clearly NOT one
> of those. Of course, if emacs let you keep THREE windows open and
> visible at the same time, instead of being limited to one or a
> horizontally split two ...
Which it does...
> and a cramped 80x10 or so each, at that ...
Emacs frames can certainly be resized and repositioned at will using
the mouse...
You are really babbling a lot of nonsense that is, at best, somewhat
relevant for prehistoric versions of Emacs without GUI support.
Just shut up until you have installed and worked with a modern version
of Emacs.
> If I haven't, it must be the case that finding this tutorial (or
> even discovering that it exists) was nontrivial, or it wasn't built
> into emacs, one or the other. My memory is somewhat fuzzy after all
> these years so you'll forgive me if I don't make a definite
> statement about which.
"After all these years"... You really should not rely on 10-year old
memories about an application.
> On the flip side, if I have, the tutorial can't have been all it's
> cracked up to be. Especially given I can program Java proficiently,
Apparently, at the time you last looked at Emacs, Java did not yet
exist.
> including some fairly sophisticated network-using tools, and clearly
> am not an idiot or untalented in technically demanding areas
> involving substantial amounts of arcana.
Up to now you have not delivered any discourse that would warrant the
"clearly" in this sentence. Not that using Emacs involved
"substantial amounts of arcana".
> The technical term for managing limited resources, such as time and
> effort, first where needed and never where avoidable, is
> "efficiency", in case you were unaware.
Sure, but babbling about a system you have never seen in its present
state for 10 years, and consequently putting your foot in your mouth
in hundreds of postings requiring hours of times spread over several
months, when it would take all of 10 minutes to get your information
somewhat up to scratch, is called "stupidity", in case you were
unaware.
>> or you're just making things up.
>
> Also untrue, and you've just accused me of incompetence once and of
> lying twice, which in a formerly civil discussion constitutes
> behavior that I consider to be in poor taste.
Well, so what is it about you accusing people of lying that report
experiences about a system you have never looked at in its current
state? You even accused me of lying when I posted _screenshots_ from
a publicly accessible site, suspecting me of forgery.
>> If I'm browsing the manual online, I can switch from said manual to
>> my document buffer without making the manual scroll to the
>> documentation for switch-to-buffer.
>
> Apparently because you find the switch second nature, despite its
> not being the obvious (which is ctrl-tab, to switch between
> documents in an MDI app).
And which works fine when using Emacs frames. Look, you are making a
complete spectable of yourself. Get a current version of Emacs and
actually try it.
> Cheat sheet? Memorized with painstaking months of hard effort?
> Thanks for proving my point, either way.
You are babbling. Not that this is new.
>> In fact, I am not aware of any package which auto-changes the
>> *info* or *Help* buffers to reflect the last keyboard command.
>
> I didn't say it auto-changes. It manual-changes. The exact sequence of
> events that causes this with a novice user being:
> * Need to do X, and the usual command doesn't work (e.g. go to save
> document and get search prompt)
Try the File/Save menu.
> * Now nothing much works (typing stuff bleeps),
Typing letters will search (the I-search: prompt in the message area
is pretty obvious). Typing other stuff (like cursor keys) will abort
the search and do their normal work. Clicking with the mouse into the
main window will abort the search and reposition the cursor. Quite
easy.
> hit esc a bunch of times *
The splash screen already explains that C-g is used for aborting
operations.
> Now it complains of hitting esc too many times,
No, it says "Quit" since it has quit the search.
> but typing into the document at least works again * OK, time to
> resort to *gulp* the help. * Oh, great, now what did it do? I hit
> F1 and ... * Eh. Try random stuff.
No, F1 works fine for entering the help.
> Help starts with h. Alt-h? Ctrl-h? ... * Oh, right. I seem to
> remember the help popping up unwanted when I tried to backspace over
> a typo earlier, so I'll just do that. * Hrm, now how to search the
> bloody thing? * <Hours pass, some spent trying ctrl+f and ctrl+s,
> mostly fruitlessly, followed by a load of
> scrolling>
Well, what kind of help did you select? The tutorial explains about
Searching some point down in the document, certainly not requiring
hours of paging. But you could, of course, also click on the
Edit/Search menu. Or on the "Search" button in the toolbar: after
all, Emacs is a modern GUI application.
> * Ah. "How to do Foobar to your open document". Perfect!
> * Oh crap. How do I do anything to my open document, when the focus
> is on the help instead of the document?
> * <Scrolling for ten
> minutes> * Ah, I hit this. It worked! * Oh, fudge. Where did "How
> to do Foobar to your open document" go? The help's open to "How to
> switch windows". For shame. * Switch back, scroll ... there it is.
> * Crap, now I don't remember how to put the focus back on the
> document window. * More scrolling. * Oh, fudge. Where did "How to
> do Foobar to your open document" go? The help's open to "How to
> switch windows". For shame. * <however many repetitions of the
> preceding 4 lines> * Error: Stack overflow. Dumping core.
>
> I trust you get the picture.
Yes. You don't have a clue what you are talking about. Your
experience is, self-admitted, at least 10 years old and completely
irrelevant to the modern state of Emacs. And, of course, the "Stack
overflow. Dumping core." nonsense bears no relation to _any_ behavior
_any_ version of Emacs, prehistoric or not, ever showed.
> [snip]
>
> Whoa, what did you just say? Page 899 of the ... good Christ. Er ...
> Run! Flee! It's a monster! Head for the hills! Sound the civil
> defense sirens, tornado TORNADO! *runs*
You are getting delirious.
>> > Infrequently used commands you can stand to hunt for in
>> > menus. When you find you use one frequently, you can try to learn
>> > the keyboard shortcut -- and you can find it without even
>> > consulting the help, simply by finding the command's menu item.
>>
>> This is no different from emacs. There's a menu bar
>
> What are you blithering about? Oh, great, now I'm using the term
> "blithering". :P But ...
>
> WHAT menu bar? We're discussing emacs. As in, a text-mode editor. As
> in a cramped little 80x24 grid of letters, numbers, spaces, and
> punctuation with no menus, no concept of a pointing device, and a
> bad attitude.
We are discussing Emacs. An editor tightly integrated into the GUI
of, at choice, Windows, MacOSX, X11 Athena, X11 Gtk+, its own Lucid
widget set, with mouse navigation, toolbar, multiple resizable frames,
menubars, support of graphics, proportional and different-sized fonts
in the frame. The one displayed in the screenshots
<URL:http://www.gnu.org/software/auctex/screenshots.html> on the
AUCTeX web site.
You, on the other hand, are not "discussing Emacs" but talking
nonsense based on fuzzy memories of passing decade-old experiences
with an early predecessor.
> Actually, the big thing the GUI and mouse did was rescue us from
> escalating UI problems with tasks complex enough to require
> modes. You needed either separate components with separate
> associated functionality and a "focus" to move among them, or you
> needed commands and keyboard-toggled modes. The former got you an
> emacs and the "can't switch back from the help" syndrome,
> and the latter got you ... something vile.
Get an update. Emacs started supporting window systems with Emacs 19
(a very long time ago), at first just under X11. But current versions
of Emacs support all modern GUIs with all features they offer.
> Until the GUI-with-pointing device, which made user control of a
> "focus" a snap requiring virtually zero learning curve, and better
> yet, what little learning there was being transferred readily across
> applications. Unified windowing systems, with Macs and Windows,
> cemented the victory of the pointing device over the problem of
> focus management. Point at the thing you want to use next and click;
> that simple. A child can do it. Using a GUI is like doing a job
> yourself, such as washing the car. Using something from the dinosaur
> age, especially afterwards, feels like sitting back and directing
> some hired help. Help that happens to be blind as a bat as well as
> having the usual poor grasp of English. "Left, Senor. Right,
> Senor. No not THAT far right! Now you've gotten it all into the open
> drivers-side window, and those documents I left on the front seat
> are ruined!" Ouch. Yet trying to control old text-mode tools is
> pretty much exactly the same, only the flawless English it speaks
> belies an even dodgier grasp of same, or even the need to speak to
> it in some obscure dialect of Greek full of "meta" instead...and it
> doesn't apologize when there's a screwup a more hands-on interface
> would easily have prevented.
Again, you are babbling based on decade-old passing exposure to an
early predecessor of modern Emacs.
It is not like you have not been told a hundred times, over a duration
of several months. You could have downloaded, tried and _learnt_ a
modern version of Emacs in half the time you used for spewing about
it. You choose ignorance, and showing off what an idiot incapable of
rational behavior you are.
> If you want a job right, do it yourself. With a mouse, you can; no
> need to speak an obscure variant of Swahili into a keyboard just to
> get the focus to the document from the help or wherever. And to top
> it off, every Windows app understands tab and alt-tab and most
> understand ctrl-tab.
As does Emacs. Or rather, it does not need to. Instead it reacts,
like other applications, to the frame and focus switching commands
from the window system which in itself interprets alt-tab.
> Actually, the OS GUI components themselves understand alt- tab, and
> the applications just get told the focus went elsewhere or came
> back, making it one less area for application designers to screw
> things up. (All too often, they screw up ctrl-tab in tabbed/MDI
> apps, or screw up tab by using a dodgy tab order or controls with no
> visual indication of focus, mind. And then you can just resort to
> the mouse, rather than throw up your hands or find something
> non-electronic to sob into so as to avoid ruining another $40
> keyboard.)
And your point was?
> And let's not forget that to someone with a 17" LCD monitor and a
> blisteringly fast graphics card, 80x24 text in a terminal emulator is
> somewhat underwhelming, and doesn't provide anything like the
> information density needed to make truly complex software interfaces
> usable.
You are talking about Emacs 18, or (in a DOS box, likely) at best
Emacs 19.
[Rest of the nonsense assuming that Emacs is a terminal application
only deleted]
> Those dim old greenly-glowing 80x24 terminals flickering at 20-odd Hz,
> by contrast ... barely adequate to design their own replacements on,
> though necessary for same.
Again, you parade your incompetency even about the decade-old
experiences you choose to talk about. No terminal ever flickered at
less than 50Hz. The normal frequency for US built terminals was 60Hz.
> "Programmers" maybe. Even so, some people program from time to time
> but do a lot of, say, image manipulation.
>
> I expect even most programmers like to be able to see what the heck
> they're doing, rather than resorting to fumbling around with a
> flashlight or grunting terse instructions to a blind butler with an
> IQ in the mid-zeros.
The latter sounds like a description of you. Current versions of
Emacs 22 even offer browsing through directories with images (use the
image-dired function) and applying basic operations like rotating
them. Good for managing a photograph collection.
>> That's how I learnt emacs. I was 13, and had only ever used Mac
>> software up until that point. I had a fairly limited command set
>> (basically, C-x C-f, C-x C-s & C-x C-c).
>
> That looks like three commands, although I can't be sure -- my
> Swahili is a little rusty from years of disuse. ;)
>
> I'd normally use at least eight -- open, save, quit, find/find next,
> replace, cut, copy, and paste.
All of those are on the toolbar (not to mention in the menus).
> That's not counting arrows, page up, page down, del, backspace, and
> the like, and unixy tools don't let you take even THOSE for
> granted.
All of those work with Emacs.
> And if I needed more, add help. Add the four arrows, page up, page
> down, delete-forwards, backspace, and help to the original eight and
> we now have 17 commands. I seriously doubt that your short chunk of
> Swahili up above encompasses all of them.
All of that is available by clicking on icons, using scrollbars and
dedicated arrow/pageup/dn keys.
>> Do you realise that emacs has a GUI these days? I'm writing this
>> in a 70-line window, with gtk+ widgets. Which means
>> full-resolution, full-colour.
>
> What are you talking about? Clearly not emacs, which is a console
> app for unix systems (with the inevitable MS-DOS ports and
> others). Some sort of bastardized Windows port I suppose?
You are so clueless. Take a look at the web page for AUCTeX
<URL:http://www.gnu.org/software/auctex/screenshots.html>. That are
screenshots from a somewhat current version of Emacs.
> I've seen the occasional attempt at a Windows port of a unix tool,
> and the results are fairly uniformly awful. Everything looks mostly
> right, and nothing works quite right. They're often actually more
> unstable than native Windows apps, probably because the porters
> don't know half as many of the landmines littering the windoze APIs
> as real Windows application programmers do (and *they* only know
> maybe half of the total, to judge by the stability of even
> higher-quality Windows apps) and because they are bolting on a thin
> layer of Windows widgets onto a core that works in ways
> fundamentally alien to those same APIs. No real Windows app dares to
> try spawning around 700 threads to service a request to copy two
> lines of text to the clipboard, for example. :)
The Windows port of Emacs is full-quality and full-functionality and
tightly integrated with Windows' GUI. You can get it with an
installer from the EmacsW32 web page
<URL:http://ourcomments.org/Emacs/EmacsW32.html>, for example, or from
the main Emacs distribution site from the FSF.
You are babbling uninformed outdated nonsense, and have been pointed
to the relevant info dozens of times over months. Yet you choose to
stay ignorant and continue looking like an uneducatable idiot.
Uneducatable idiots should not choose to work in the computing
business since things move fast there, and uneducatability (and the
unwillingness to reevaluate decade-old experience) are plainly a
hinderance.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Martin Gregorie
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <0o42l4-t81.ln1@zoogz.gregorie.org>
Twisted wrote:
> At least Windows 3.1 had most apps have the same keys for the vast
> majority of commands, and those were the right keys. Emacs has all the
> applications have the vast majority of their commands use the same
> WRONG keys. Including whatever you'd use to rebind them. And the help
> you'd use to find out what the damn keys are in the first place. ;)
>
You're mis-remembering this.
Apple, first with the Lisa and then with the Mackintosh, had extremely
consistent menus, menu shortcuts and other key assignments. It was
possible to teach almost anybody to use them in 15 minutes flat. A major
reason for the consistency was the Programmer's Toolbox, a piece of ROM
that contained all the stuff an application needed to handle keyboard,
mouse and menus. It was there and easy to use, so of course all
applications programmers used it.
Windows 3 and 3.1 were the first usable Windows versions. Windows 1 and
2 were a bad jokes. Win/286 worked but had no applications. Win 3.x
worked a lot better. However, it lacked any equivalent of the
Programmers Toolbox and as a result the applications were anything but
consistent. MS applications were self-similar, but other apps used
wildly divergent ideas about menu structures, shortcuts and key
assignments. Compare 3.x versions of Word with Wordperfect, or the
Borland IDEs and this is obvious.
MS finally kicked applications providers into more-or-less consistency
but that wasn't before Win 95 appeared and they then spoilt the record
by arbitrary and capricious menu changes as each version of MS Office
appeared.
--
······@ | Martin Gregorie
gregorie. | Essex, UK
org |
From: Robert Uhl
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3odj5ym8h.fsf@latakia.dyndns.org>
Twisted <··········@gmail.com> writes:
>
> Of course, if emacs let you keep THREE windows open and visible at the
> same time, instead of being limited to one or a horizontally split two
> ... and a cramped 80x10 or so each, at that ...
I have two frames open right now: one 80x70, the other around 180x70
(characters, not pixels). One isn't split at all; the other is split
into four windows, horizontally and vertically.
> I'll admit that it didn't USED TO 'eschew normal methods of
> navigation', but at a certain point in time there began to be 'normal
> methods of navigation' and emacs naturally began eschewing them
> promptly and has done so ever since.
emacs has continued doing its own thing, mostly because that thing is
better. The CUA standards (there exists an emacs package if you really
want them) are broken and lame--I and most other don't wish to cripple
our text editor of choice.
> If I haven't, it must be the case that finding this tutorial (or even
> discovering that it exists) was nontrivial, or it wasn't built into
> emacs, one or the other.
When you start emacs in a text console, you see this:
Welcome to GNU Emacs, one component of the GNU/Linux operating system.
Type C-l to begin editing.
Get help C-h (Hold down CTRL and press h)
Emacs manual C-h r
Emacs tutorial C-h t Undo changes C-x u
Buy manuals C-h C-m Exit Emacs C-x C-c
Browse manuals C-h i
Activate menubar F10 or ESC ` or M-`
(`C-' means use the CTRL key. `M-' means use the Meta (or Alt) key.
If you have no Meta key, you may instead type ESC followed by the character.)
A GUI window shows a similar message. Note the 'Emacs tutorial' entry?
Or you could just go to the Help menu, then select 'Emacs Tutorial.'
>> If I'm browsing the manual online, I can switch from said manual to
>> my document buffer without making the manual scroll to the
>> documentation for switch-to-buffer.
>
> Apparently because you find the switch second nature, despite its not
> being the obvious (which is ctrl-tab, to switch between documents in
> an MDI app).
Clicking within the document's window isn't obvious?!?
> * OK, time to resort to *gulp* the help.
> * Oh, great, now what did it do? I hit F1 and ...
> * Eh. Try random stuff. Help starts with h. Alt-h? Ctrl-h? ...
> * Oh, right. I seem to remember the help popping up unwanted when I
> tried to backspace over a typo earlier, so I'll just do that.
Ha! f1 and C-h do the exact same thing. You've obviously not used emacs
this millennium.
> WHAT menu bar? We're discussing emacs. As in, a text-mode editor. As
> in a cramped little 80x24 grid of letters, numbers, spaces, and
> punctuation with no menus, no concept of a pointing device, and a bad
> attitude.
No, we're discussing emacs, a text editor which runs in both a GUI and a
text console. Which can display images. It's cool like that.
> At least Windows 3.1 had most apps have the same keys for the vast
> majority of commands, and those were the right keys. Emacs has all the
> applications have the vast majority of their commands use the same
> WRONG keys.
Neither is right nor wrong; you're just used to one. The emacs keys are
certainly more flexible and powerful, though. Some might consider them
right for that reason.
>> Wouldn't it be cool not to have one program implement search in one
>> way, and another a second way, and yet another a third? Wouldn't it
>> be cool to have access to a proper text editor when editing text on a
>> web page?
>
> Search is usually ctrl+f, type something, hit enter in my experience.
Unless you want regexp search. And if you want to find again it can be
interesting. And maybe the program defaults to case-sensitive or
case-insensitive search...
> And I can use any text editor I want to edit HTML.
You could use Notepad no doubt; you could also use a Turing machine. I
prefer to use a useful tool.
>> Do you realise that emacs has a GUI these days? I'm writing this in a
>> 70-line window, with gtk+ widgets. Which means full-resolution,
>> full-colour.
>
> What are you talking about? Clearly not emacs, which is a console app
> for unix systems (with the inevitable MS-DOS ports and others).
No, as I've said over and over and over again, emacs is not what you
think it is. It has a GUI; it has colours; it can display images; it
can use the native widget set. It can even be configured to use native
keybindings, although that way lies madness.
> Some sort of bastardized Windows port I suppose?
Hah! Dude, I don't use Windows--I've better things to do with my life.
--
Robert Uhl <http://public.xdi.org/=ruhl>
With weapons, we are citizens. Without them, we are subjects.
On Jun 24, 7:19 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> Twisted <··········@gmail.com> writes:
>
> > Of course, if emacs let you keep THREE windows open and visible at the
> > same time, instead of being limited to one or a horizontally split two
> > ... and a cramped 80x10 or so each, at that ...
>
> I have two frames open right now: one 80x70, the other around 180x70
> (characters, not pixels). One isn't split at all; the other is split
> into four windows, horizontally and vertically.
Then you're obviously not using the One True Emacs I am criticizing,
which is a console app. If we're not talking about the same piece of
software (and the one the fanatics evangelize about) then this is
pointless.
> emacs has continued doing its own thing, mostly because that thing is
> better. The CUA standards (there exists an emacs package if you really
> want them) are broken and lame--I and most other don't wish to cripple
> our text editor of choice.
"CUA standards"? I'm sorry, I don't speak Botswanan. If you mean
Windows standards like for cut, copy, and paste, "broken and lame" is
obviously in the eye in the beholder, and something 97% of computer
users are used to is the defacto standard, so it's the other 3% that
are "broken and lame". ;)
> When you start emacs in a text console, you see this:
>
> Welcome to GNU Emacs, one component of the GNU/Linux operating system.
>
> Type C-l to begin editing.
>
> Get help C-h (Hold down CTRL and press h)
> Emacs manual C-h r
> Emacs tutorial C-h t Undo changes C-x u
Really? That is not what I recall seeing. Are you talking about emacs-
the-text-mode-editor, or emacs-the-hybrid-somethingorother-when-you-
happen-to-run-it-from-the-command-prompt-on-unix? Because I've been
discussing the former.
> Buy manuals C-h C-m
How crass.
First I've seen anything open source/"free" software that makes sales
pitches at you. Mostly I've only seen that with closed-source Windows
"free"ware loaded with adware, and with shareware that nags you to
register or otherwise spend money with its author. And with actual
paid products, particularly those from Intuit which act as Intuit's
front-line salesmen by trying to constantly upsell you and sell stuff
to your friends and relatives. Er, thanks but no thanks. (I don't
personally spend a dime on any Intuit products. I unfortunately know
people who do. One version of some accounting software of theirs even
spammed all of a user's email contacts, by God. Where are those
Russian spammer-targeting hitmen when you need them?)
> Activate menubar F10 or ESC ` or M-`
Definitely not the stock text-mode emacs I've had my runins with in
the past, but some kind of hybrid or offshoot, then.
> Clicking within the document's window isn't obvious?!?
Clicking within the document's window is obvious but doesn't work,
unless you're using something other than vanilla emacs at least. It
did of course work in MS-DOS Edit, later versions.
> No, we're discussing emacs, a text editor which runs in both a GUI and a
> text console. Which can display images. It's cool like that.
No, we're discussing ... oh, nevermind. It looks like there are
several utterly different pieces of software that have one thing in
common - the name "emacs". Anyone can dodge or seem to rebut a
criticism of one of them by describing how another of them isn't like
that. :P
> > At least Windows 3.1 had most apps have the same keys for the vast
> > majority of commands, and those were the right keys. Emacs has all the
> > applications have the vast majority of their commands use the same
> > WRONG keys.
>
> Neither is right nor wrong; you're just used to one. The emacs keys are
> certainly more flexible and powerful, though. Some might consider them
> right for that reason.
The Windows keys are familiar to 97% of the population. Some might
consider them right for that reason.
This is also a change from your earlier position that they were, and I
quote, "broken and lame", assuming you mean the same stock Windoze
keybindings you meant with the cryptic term "CUA standards".
> > Search is usually ctrl+f, type something, hit enter in my experience.
>
> Unless you want regexp search. And if you want to find again it can be
> interesting.
I rarely want regexp search, and if I want it I can use Notetab, a
notepad replacement with tabbed MDI and yes, regexp search. A few tabs
and a space keypress to turn it on after ctrl+f.
As for "find again" hitting enter additional times is the usual
method, in Notetab, Notepad, and elsewhere.
> > And I can use any text editor I want to edit HTML.
>
> You could use Notepad no doubt; you could also use a Turing machine. I
> prefer to use a useful tool.
Painting it as a choice between Notepad and emacs is the fallacy of
false dichotomy. There's Notetab (useful, but non-free) and lots of
(sometimes free) other text editors (for Windows and for other
platforms).
Some specialize in HTML editing the way Eclipse's built-in editor
specializes in Java editing (and with plugins, can be made to
specialize in, say, C instead).
> No, as I've said over and over and over again, emacs is not what you
> think it is. It has a GUI; it has colours; it can display images; it
> can use the native widget set. It can even be configured to use native
> keybindings, although that way lies madness.
One thing I agree on regarding emacs is the phrase "that way lies
madness". I'm amending that belief to include participating in Usenet
discussions about emacs, as well as actually trying to use emacs.
Given that everyone seems to mean a distinct piece of software by the
term "emacs" it's a wonder anything coherent can be said about "emacs"
at all. Actually, the one constant to emerge in all of this is C-h
being associated with accessing the help in all of these various
emacses. And we all know that that results in backspace doing
surprising things for a text editor. :P
> Hah! Dude, I don't use Windows--I've better things to do with my life.
Xemacs then, or whatever they're calling the bolted-on-an-X-GUI-and-
the-rivet-job-shows-from-1000-paces version these days.
From: Robert Uhl
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3fy4gztrv.fsf@latakia.dyndns.org>
Twisted <··········@gmail.com> writes:
>
>> I have two frames open right now: one 80x70, the other around 180x70
>> (characters, not pixels). One isn't split at all; the other is split
>> into four windows, horizontally and vertically.
>
> Then you're obviously not using the One True Emacs I am criticizing,
> which is a console app.
No, the One True Emacs supports GUIs. It has since 1991. Take a look
at <http://linux.softpedia.com/screenshots/Emacs_2.png>.
>> emacs has continued doing its own thing, mostly because that thing is
>> better. The CUA standards (there exists an emacs package if you
>> really want them) are broken and lame--I and most other don't wish to
>> cripple our text editor of choice.
>
> "CUA standards"? I'm sorry, I don't speak Botswanan. If you mean
> Windows standards like for cut, copy, and paste, "broken and lame" is
> obviously in the eye in the beholder, and something 97% of computer
> users are used to is the defacto standard, so it's the other 3% that
> are "broken and lame". ;)
Popularity is no measure of goofness.
> No, we're discussing ... oh, nevermind. It looks like there are
> several utterly different pieces of software that have one thing in
> common - the name "emacs".
That is actually true. There's GNU emacs (the original and still the
best). There's XEmacs (a fork of the same). Then there are a myriad of
ancient emacsen, most particularly Gosling emacs.
However, the only two which matter are GNU emacs and XEmacs. Both have
supported a GUI for 16 years now. I don't have XEmacs installed, so I
cannot tell you if it has the tutorial. I would be truly surprised if
it didn't.
>> Neither is right nor wrong; you're just used to one. The emacs keys are
>> certainly more flexible and powerful, though. Some might consider them
>> right for that reason.
[snip]
> This is also a change from your earlier position that they were, and I
> quote, "broken and lame", assuming you mean the same stock Windoze
> keybindings you meant with the cryptic term "CUA standards".
Not really--they're broken and lame because they are less flexible and
powerful.
How 'bout you actually try using a modern emacs? It'll even support
your chosen operating system.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Better to teach a man to fish than to give him a fish. And if he can't
be bothered to learn to fish and starves to death, that's a good enough
outcome for me. --Steve VanDevender, 1 May 2000
Robert Uhl <·········@NOSPAMgmail.com> wrote:
+---------------
| However, the only two which matter are GNU emacs and XEmacs.
| Both have supported a GUI for 16 years now. I don't have
| XEmacs installed, so I cannot tell you if it has the tutorial.
| I would be truly surprised if it didn't.
+---------------
It does. And the default startup splash screen
tells you how to access it.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Jun 25, 12:32 am, Twisted <··········@gmail.com> wrote:
>
> It looks like there are
> several utterly different pieces of software that have one thing in
> common - the name "emacs"...
>
> > When you start emacs in a text console, you see this:
> >
> > Welcome to GNUEmacs, one component of the GNU/Linux operating system.
> > Get help C-h (Hold down CTRL and press h)
> > Emacsmanual C-h r
> > Emacstutorial C-h t Undo changes C-x u
>
> Really? That is not what I recall seeing. Are you talking aboutemacs-
> the-text-mode-editor, oremacs-the-hybrid-somethingorother-when-you-
> happen-to-run-it-from-the-command-prompt-on-unix? Because I've been
> discussing the former.
Everyone now uses http://www.gnu.org/software/emacs/
or a minor derivative of it.
Its official distribution FTP location is
http://ftp.gnu.org/pub/gnu/emacs/
And for the Windows port, the official FTP is here
http://ftp.gnu.org/pub/gnu/emacs/windows/
We don't care about the 1970 version of Emacs,
because of course back then there WAS NO GUI.
- JackT
From: Cor Gest
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <87wsxsam2w.fsf@telesippa.clsnet.nl>
Some entity, AKA JackT <········@gmail.com>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> We don't care about the 1970 version of Emacs,
> because of course back then there WAS NO GUI.
But if you are blind as bat, any 2007's GUI is useless.
Cor
--
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
The biggest problem LISP has, is that it does not appeal to dumb people
If that fails to satisfy read the HyperSpec, woman frig or Tuxoharata
mailpolicy @ http://www.clsnet.nl/mail.php
On Jun 25, 12:56 am, Cor Gest <····@clsnet.nl> wrote:
> Some entity, AKA JackT <········@gmail.com> wrote this mindboggling stuff:
> (selectively-snipped-or-not-p)
No need to be insulting.
>
> > We don't care about the 1970 version ofEmacs,
> > because of course back then there WAS NO GUI.
>
> But if you are blind as bat, any 2007's GUI is useless.
>
You may have missed part of the discussion.
Today's GNU emacs will still run with most of its features
(even keyboard-driven text-drawn menu) when you run
it on a GUI-less environment.
At the same time, today's GNU emacs, when run on a GUI,
will be able to pop up file-selection menus, display colors, etc. etc.
- JackT
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <86fy4gh5kk.fsf@lola.quinscape.zz>
Cor Gest <···@clsnet.nl> writes:
> Some entity, AKA JackT <········@gmail.com>,
> wrote this mindboggling stuff:
> (selectively-snipped-or-not-p)
>
>> We don't care about the 1970 version of Emacs,
>> because of course back then there WAS NO GUI.
>
> But if you are blind as bat, any 2007's GUI is useless.
Have you actually talked to a blind person about that? They often
prefer the GUI applications since they tend to interact better with
screen readers and the accessibility software available for the GUI's
toolkits. Sounds crazy, I know.
Anyway, Emacs plays in a league of its own for blind people due to
Emacspeak.
--
David Kastrup
From: ······@myrealbox.com
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <5eaqqlF36ga72U2@mid.individual.net>
In article <························@c77g2000hse.googlegroups.com>,
Twisted <··········@gmail.com> wrote:
> On Jun 24, 7:19 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
[ snip ]
> > emacs has continued doing its own thing, mostly because that thing is
> > better. The CUA standards (there exists an emacs package if you really
> > want them) are broken and lame--I and most other don't wish to cripple
> > our text editor of choice.
>
> "CUA standards"? I'm sorry, I don't speak Botswanan. If you mean
> Windows standards like for cut, copy, and paste,
Pretty much. "Common User Access". I thought this was a
well-known acronym in Windowsland, but I guess not. A Google
search on "CUA" finds the Wikipedia article as the second hit.
[ snip ]
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
From: ······@myrealbox.com
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <5eaqjmF36ga72U1@mid.individual.net>
In article <························@q75g2000hsh.googlegroups.com>,
Twisted <··········@gmail.com> wrote:
> On Jun 23, 2:04 am, Robert Uhl <·········@NOSPAMgmail.com> wrote:
[ snip ]
> Apparently because you find the switch second nature, despite its not
> being the obvious (which is ctrl-tab, to switch between documents in
> an MDI app). Cheat sheet? Memorized with painstaking months of hard
> effort? Thanks for proving my point, either way.
Not really ragging on you, however it seems, but this is a pet
peeve of mine, and I have a few minutes, and this thread is
already pretty much out of control, so ....
Painstaking months of hard effort? You know, I started out in
the days before GUIs, so I have experience with cheat sheets,
but I don't remember ever being given one and being told that
there would be a quiz in a week, or a month, or whatever.
Instead, I used the cheat sheet at first, and over the course
of the first few -- hours, weeks, I don't know -- found that I
needed it less and less, as the commands I actually used in my
daily work made their way into my memory. (Does that mean that
I didn't memorize all the commands on the cheat sheet? Maybe.
But the ones I didn't learn were ones I didn't need.)
To me it's similar to "memorizing" a phone number by dialing
it enough times that it makes its way into memory without
conscious effort. I suspect that not everyone's brain works
this way, and some people have to look it up every time.
For those people, I can understand why something without a
GUI could be a painful experience. "YMMV", maybe.
[ snip ]
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
On Jun 25, 5:32 pm, ······@myrealbox.com <······@myrealbox.com> wrote:
> To me it's similar to "memorizing" a phone number by dialing
> it enough times that it makes its way into memory without
> conscious effort. I suspect that not everyone's brain works
> this way, and some people have to look it up every time.
> For those people, I can understand why something without a
> GUI could be a painful experience. "YMMV", maybe.
You'll be happy to know then that my opinion is that the phone system
is archaic too. Exposing the numerical network addresses like that is
so 1970s; where's the phone version of DNS, given that the technology
to develop it is clearly there now, and (from my experiences with the
phone menus at some 800 numbers) even the technology for you to just
pick up the handset, say someone's name, and have it look them up and
ring them, possibly after being prompted to accept long distance
charges, reverse them, or cancel if it's LD. :)
We'll actually probably see a generation of friendlier phones RSN --
either regular phones, or because VoIP providers leapfrog them and
advance rapidly leaving the old telcos eating dust when these don't
advance their technology and interfaces.
Setting up and using voice mail or speed-dial keys still tends to be
*painful*. There's still an excuse for that with cell phones since you
can't put a more sophisticated interface onto something the size of a
credit card, but a phone that takes up a substantial chunk of desk
space really should have more than a tiny LCD screen and twelve tone
keys. The only reason nobody complains much is because they're so bog
standard everyone is used to them and knows how to operate them. If we
had modern internet and other services and someone tried to introduce
the touch-tone telephone system now, the market would reject it in a
heartbeat and pursue VoIP, and Techdirt would run a "Failures"
category article blaming the terrible UI and excessive fee structure.
The same sort of inertia that let the phone system survive mostly
unchanged over the last 20 years without improving its UI much keeps
some old unix tools beloved by those who mastered them, and of course
propels Windows, which has done some dumb things with its UI (and much
worse under the hood).
From: ······@myrealbox.com
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <5efpavF392efmU1@mid.individual.net>
In article <························@n2g2000hse.googlegroups.com>,
Twisted <··········@gmail.com> wrote:
> On Jun 25, 5:32 pm, ······@myrealbox.com <······@myrealbox.com> wrote:
> > To me it's similar to "memorizing" a phone number by dialing
> > it enough times that it makes its way into memory without
> > conscious effort. I suspect that not everyone's brain works
> > this way, and some people have to look it up every time.
> > For those people, I can understand why something without a
> > GUI could be a painful experience. "YMMV", maybe.
>
> You'll be happy to know then that my opinion is that the phone system
> is archaic too.
Happy? Not especially. Amused? Yes. One more, um, "eccentric"?
opinion, from someone with many of them.
[ snip ]
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3k5tqu5cl.fsf@borud.not>
[Twisted <··········@gmail.com>]
| On Jun 23, 2:04 am, Robert Uhl <·········@NOSPAMgmail.com> wrote:
| > Of course, emacs doesn't take years of mastery. It takes 30, 40
| > minutes.
|
| I gave it twice that, and it failed to grow on me in that amount of
| time.
then it just wasn't meant to be. stick to Notepad.
| If I haven't, it must be the case that finding this tutorial (or even
| discovering that it exists) was nontrivial, or it wasn't built into
| emacs, one or the other.
when Emacs on my machine starts it says the following:
Welcome to GNU Emacs, one component of a Linux-based GNU system.
Get help C-h (Hold down CTRL and press h)
Undo changes C-x u Exit Emacs C-x C-c
Get a tutorial C-h t Use Info to read docs C-h i
Ordering manuals C-h RET
Activate menubar F10 or ESC ` or M-`
(`C-' means use the CTRL key. `M-' means use the Meta (or Alt) key.
If you have no Meta key, you may instead type ESC followed by the
character.)
if you haven't found the tutorial, you haven't really tried very hard.
-Bj�
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m34pkyd90e.fsf@borud.not>
[Twisted <··········@gmail.com>]
| You end up having to memorize the help, because *you can't
| have arbitrary parts of the help and your document open side by side
| and be working on the document*. All because you can't simply tab or
| click to the document.
yes you can. you even have a lot of choice as to how you want to do
it and it even works on the simplest of text terminals (which is
useful when you are on the road and only have a computer with a
browser availabe and you've had the foresight to set up the Mindterm
SSH applet on a machine so you can log in and edit code from anywhere
in the world).
I use multiple frames on-screen most of the time. either to edit and
view multiple files at once or to edit different locations of the same
file. if you're a programmer it is often useful to be able to do
this. you can look at more than one file at the same time, have
documentation up on screen etc.
| At minimum, you have to *memorize* some arcane key controls for
| switching panes ... er, "windows", that are totally unintuitive and
| unlike what is normally used.
following the built-in tutorial in Emacs I understood how to
manipulate buffers and split windows in various ways. there are
basically three commands you need to know. one of them is used to
switch between active buffers in a given window, so it is not specific
to splitting.
it took me minutes to learn and within days I didn't even think about
what I was doing -- I was just using the features.
I think you fail to understand the approach. if you know an editor
like VI or Emacs properly you have a much bigger bag of tricks, that
are applicable to a wide range of scenarios, than what is encouraged
by GUI intensive editors. and you don't think of them as "tricks".
it is just the way you edit text.
| Oops. The interface design is a nightmare. The most basic requirement,
| that it be easy to have the help open side by side with your document
| and switch back and forth and navigate inside the help easily, is
| broken. If you have to consult the help just to navigate the help or
| to switch focus between document and help, then you're trapped, and
| that is what happens with emacs.
why don't you learn Emacs before you say what it can and can't do?
it is so frustrating to debate editors with people who haven't even
bothered to make a minimal effort to at least spend a day or two
learning it.
let's look at Word and word processing. how long does it take you to
learn Word properly? to understand how to efficiently edit large
documents, automate common tasks, use the built-in features for
helping you organize documents?
-Bj�
From: Edward Dodge
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m2k5tct0y0.fsf@gmail.com>
Twisted <··········@gmail.com> writes:
> Besides, ANY interface that involves fumbling around in the dark
> trying to find a light switch is clunky. You should be able to see
> what the hell you're doing and navigate easily. Applications that not
> only eschew normal methods of navigation of the interface, but force
> you to fumble your way between the help and the task you're trying to
> do, are definitely clunky. An analogy to a genuine emacs experience:
> you enter a workshop with some raw materials and tools. Unfortunately
> there's no big ceiling lights so you can just flip the switch by the
> door and then always be able to see where everything is. Instead
> there's little lights here and there by various specific tools and
> storage areas, and in one area a map of the place with switches to
> control the lights.
So -- what magical computer app illuminates the entire room and shows
you how to use everything at the flip of a switch? This brilliant
discovery would put Sam's, O'Reilly, the for-Dummies series, and
virtually every other computer book publisher out of business in weeks.
Naturally, this would include the publishers of books on "easy-to-use"
Microsoft products.
--
Edward Dodge
On Jul 7, 4:26 pm, Edward Dodge <············@gmail.com> wrote:
> So -- what magical computer app illuminates the entire room and shows
> you how to use everything at the flip of a switch? This brilliant
> discovery would put Sam's, O'Reilly, the for-Dummies series, and
> virtually every other computer book publisher out of business in weeks.
> Naturally, this would include the publishers of books on "easy-to-use"
> Microsoft products.
I don't know, but it sure as hell isn't emacs.
Twisted wrote:
Edward Dodge wrote:
>> So -- what magical computer app illuminates the entire room and shows
>> you how to use everything at the flip of a switch? This brilliant
>> discovery would put Sam's, O'Reilly, the for-Dummies series, and
>> virtually every other computer book publisher out of business in weeks.
>> Naturally, this would include the publishers of books on "easy-to-use"
>> Microsoft products.
>
> I don't know, but it sure as hell isn't emacs.
The reason you don't know, and Edward Dodge's point, is that there is no such
app, whether emacs or not.
--
Lew
On Jul 7, 6:12 pm, Lew <····@lewscanon.nospam> wrote:
> Twisted wrote:
> Edward Dodge wrote:
> >> So -- what magical computer app illuminates the entire room and shows
> >> you how to use everything at the flip of a switch? This brilliant
> >> discovery would put Sam's, O'Reilly, the for-Dummies series, and
> >> virtually every other computer book publisher out of business in weeks.
> >> Naturally, this would include the publishers of books on "easy-to-use"
> >> Microsoft products.
>
> > I don't know, but it sure as hell isn't emacs.
>
> The reason you don't know, and Edward Dodge's point, is that there is no such
> app, whether emacs or not.
Translation: since perfection is unattainable, we shouldn't even try,
and just foist upon our poor users whatever awkward and hard-to-learn
interface pops into our heads first?
Twisted wrote:
[...]
BASTA. Basta, cazzo (unprintable, Italian). Stop it. It wasn't funny
10 messages into your subthread, and it's even less fun now. It's
obvious you're trolling, but nevertheless, in the undescribably
improbable case you _are_ being serious:
a) Notepad is over there: --->*
b) If you do want to keep an antediluvian copy of emacs -probably
versioned in the negative numbers, for all you've said- please do. Do
be so kind as to send a copy, since it might be quite valuable as an
antique.
c) Powerful programming editors assume some willingness to learn their
interface. Deal.
d) Your capacity of denial is remarkable. Please do send us your
contact info, so that we may avoid dealing with you on a professional
basis.
--
killfile-ly yours,
Adriano
On Jul 8, 4:28 am, Adriano Varoli Piazza <·······@gmail.com> wrote:
> b) If you do want to keep an antediluvian copy of emacs -probably
> versioned in the negative numbers, for all you've said- please do. Do
> be so kind as to send a copy, since it might be quite valuable as an
> antique.
Judging by the existence of the newsgroup comp.emacs, emacs is indeed
considered by some to be a quite valuable antique. Otherwise why on
earth would it have an apparently fairly active newsgroup a full seven
years into the 21st century?
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <851wfivdtr.fsf@lola.goethe.zz>
Twisted <··········@gmail.com> writes:
> On Jul 8, 4:28 am, Adriano Varoli Piazza <·······@gmail.com> wrote:
>> b) If you do want to keep an antediluvian copy of emacs -probably
>> versioned in the negative numbers, for all you've said- please do. Do
>> be so kind as to send a copy, since it might be quite valuable as an
>> antique.
>
> Judging by the existence of the newsgroup comp.emacs, emacs is
> indeed considered by some to be a quite valuable antique. Otherwise
> why on earth would it have an apparently fairly active newsgroup a
> full seven years into the 21st century?
As opposed to your brain, Emacs has not undergone fossilization 10
years ago. While a newsgroup discussing your dim recollections of
Emacs would indeed be boring (apart from the amusement value of your
pomposity), a newsgroup discussing current (and evolving) versions and
use of Emacs has its place. And anyway, the language C has changed
much less in the last 10 years than Emacs has, and you'll still find
active discussion groups for that, too: it is still very much in use,
like Emacs.
As a note aside, you'd be hard put to find an editor that manages a
similar multitude of encodings as well as Emacs does. While it is to
be expected that in the long term utf-8-encoded Unicode is the way of
the future (and Emacs is going to focus more on that in future
versions, too), at the moment there are few editors which keep up with
the existing multitude of multibyte encodings as well as Emacs does.
Emacs also makes it fairly easy to input stuff without much hassle, so
you can easily write things like ἐν ἀρχῇ ἦν ὁ λόγος or каша гречневая.
So even if you don't like the user interface of Emacs from 10 years
ago and delight in assuming that it did not change in all that time,
there would be valid reasons for using it nevertheless.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <853azza0gy.fsf@lola.goethe.zz>
Twisted <··········@gmail.com> writes:
> On Jul 7, 6:12 pm, Lew <····@lewscanon.nospam> wrote:
>> Twisted wrote:
>> Edward Dodge wrote:
>> >> So -- what magical computer app illuminates the entire room and shows
>> >> you how to use everything at the flip of a switch? This brilliant
>> >> discovery would put Sam's, O'Reilly, the for-Dummies series, and
>> >> virtually every other computer book publisher out of business in weeks.
>> >> Naturally, this would include the publishers of books on "easy-to-use"
>> >> Microsoft products.
>>
>> > I don't know, but it sure as hell isn't emacs.
>>
>> The reason you don't know, and Edward Dodge's point, is that there is no such
>> app, whether emacs or not.
>
> Translation: since perfection is unattainable, we shouldn't even try,
> and just foist upon our poor users whatever awkward and hard-to-learn
> interface pops into our heads first?
I recommend you just shut up _until_ you have checked out a recent
version of Emacs. You just have no clue what you are talking about
and are still stuck in the eighties.
Emacs has an obvious "Help" toolbar button in the standard place, it
has a "Help" menu in the standard place, it reacts to presses of F1 by
delivering help, it has tooltips all over the mode line and for pretty
much every menu entry (and the menus are plenty and well-sorted for
doing the most-frequent tasks).
In addition, the quality of those help items is far above average.
But you would not know since you prefer babbling about some passing
decade-old experience. If you had invested half of the time using
Emacs you have invested for complaining about it, you'd at least have
a chance not to look like the totally pompous clueless idiot you do
now.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Twisted wrote:
> On Jul 7, 6:12 pm, Lew <····@lewscanon.nospam> wrote:
>> Twisted wrote:
>> Edward Dodge wrote:
>>>> So -- what magical computer app illuminates the entire room and shows
>>>> you how to use everything at the flip of a switch? This brilliant
>>>> discovery would put Sam's, O'Reilly, the for-Dummies series, and
>>>> virtually every other computer book publisher out of business in weeks.
>>>> Naturally, this would include the publishers of books on "easy-to-use"
>>>> Microsoft products.
>>> I don't know, but it sure as hell isn't emacs.
>> The reason you don't know, and Edward Dodge's point, is that there is no such
>> app, whether emacs or not.
>
> Translation: since perfection is unattainable, we shouldn't even try,
> and just foist upon our poor users whatever awkward and hard-to-learn
> interface pops into our heads first?
Nice rhetoric but completely twisted the point. Blaaaat!
--
Lew
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3ps32g973.fsf@borud.not>
[Twisted <··········@gmail.com>]
|
| Translation: since perfection is unattainable, we shouldn't even try,
| and just foist upon our poor users whatever awkward and hard-to-learn
| interface pops into our heads first?
uh, I think the point here is that some think it might be an idea to
force *their* idea of the ideal interface upon others, refusing to
understand that people might have their own preferences.
-Bj�
On Jul 8, 12:18 pm, Bjorn Borud <··········@borud.no> wrote:
> uh, I think the point here is that some think it might be an idea to
> force *their* idea of the ideal interface upon others, refusing to
> understand that people might have their own preferences.
I, for one, have a strong preference for interfaces that let me see
what the hell I'm doing and make it easy to find commands, navigate
the interface, navigate the help, and so forth, while making me resort
to reaching for that help as infrequently as reasonably achievable.
But that's just me.
From: Matthias Buelow
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <5fcv44F3c4l7eU1@mid.dfncis.de>
Twisted wrote:
> I, for one, have a strong preference for interfaces that let me see
> what the hell I'm doing and make it easy to find commands, navigate
> the interface, navigate the help, and so forth, while making me resort
> to reaching for that help as infrequently as reasonably achievable.
These are, of course, not unreasonable wishes. I assume you're
programming that software already, given that you're crossposting to
various programming-language newsgroups. Very well. We'll eagerly judge
you by what you'll come up with.
F'up-to: comp.emacs.
From: Robert Uhl
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3ir9h47dl.fsf@latakia.dyndns.org>
Twisted <··········@gmail.com> writes:
>
>> > I have that exact URL now --
>> >http://www.asktog.com/columns/027InterfacesThatKill.html
>>
>> Utterly unrelated to Emacs.
>
> I think it is quite relevant. Clunky computer interfaces may not be so
> dramatically dangerous, but they certainly can hamper productivity.
You're quite right. Windows/Mac user interfaces are so clunky that they
massively hamper productivity. Emacs, OTOH, enables it. For example,
C-s is search forward; C-r is search backward ('reverse'); C-M-s is
search forward for a regular expression; C-M-r is search backward for a
regular expression. A Windows or Mac editor would have C-s for save,
and that's it. It might have C-f for find, but it'd pop up a dialogue
instead of offering an interactive search, causing a mental context
switch. Searching would interrupt one's flow of thought rather than
being part of it.
> Between Windows bugs and gratuitous misfeatures (e.g. DRM) and Unix
> clunkiness, billions of dollars of potential productivity is lost
> worldwide every *month*.
You left out user refusal to learn...
--
Robert Uhl <http://public.xdi.org/=ruhl>
If I could sum up my life in one sentence, I think it would be: He was born, he
lived, and then he kept on living, much longer than anyone had ever lived
before, getting richer and richer and glowing with a bright white light.
--Deep Thoughts, by Jack Handey [1999]
On Jun 21, 10:09 am, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> You're quite right. Windows/Mac user interfaces are so clunky that they
> massively hamper productivity. Emacs, OTOH, enables it. For example,
> C-s is search forward; C-r is search backward ('reverse'); C-M-s is
> search forward for a regular expression; C-M-r is search backward for a
> regular expression. A Windows or Mac editor would have C-s for save,
> and that's it. It might have C-f for find, but it'd pop up a dialogue
> instead of offering an interactive search, causing a mental context
> switch. Searching would interrupt one's flow of thought rather than
> being part of it.
Being a primarily windows user, I have to question your assertion that
using ctrl-f for find causes a "mental context switch". For me, in 90%
of the windows applications, finding something is as simple as ctrl-f,
the phrase, hit enter. Not terribly different from your set of
commands. The biggest difference is that if I need to use a Find
feature I might not often use, I have a visual interface to all the
related search functions. On the other hand, a terminal program would
necessitate a memory search at best, or a trip to the help pages at
worst.
The best part of my windows knowledge is that it's transferable to
most (all?) of the applications I work with. Find is usually ctrl-f.
Undo is ctrl-z. Save is ctrl-s, yadda yadda. Such knowledge is rarely
transferable from terminal programs in my experience -- what may be
true for one program (emacs) is wildly different in another program
(vi), and useless in yet another (pico).
On the other hand, I can move from notepad to Word to Open Office to
Notepad++, based on the availability at the terminal I'm on, with
little difficulty.
For the record, I use VIM when in terminals. Emacs isn't available on
our *nix boxes.
Feel free to disagree with what I'm about to say. I know that this
thread would be far, FAR shorter if OP hadn't been instigating
disagreement, but so far most of the discourse has been polite, so I'm
going to say what I'm thinking.
I think there are far too many people in all camps (the Emacs camp,
the vi* camp, and the GUI/IDE/point-and-click-and-make-
everything-"user-friendly" camp) who look at this disagreement as a
debate in which they Are Right, and the members of the other two camps
Are Wrong. There are billions of people in this world, and even if you
ignore the ones who don't need to use a text editor or word processor
on a regular basis, you end up with a VERY large number of people. And
people are different. We think differently, we all have different
things that come to us naturally, different things that are tricky but
learn-able, and different things that we'll never be able to do
without a manual open in front of us.
There are a lot of people for whom emacs is easy to learn, logical to
use, and the way it is set up (or at least the way -they- set it up)
is so natural to them that they'll never be as productive anywhere
else. But there are also a lot of people for whom emacs doesn't click,
who can give it a genuine try but still not catch on, and even once
they learn enough to muddle through, they'll always work better in
Word, or in an IDE.
But I think there's something else to it, and it's part of why I think
the emacs faithful swear by it so fiercely, even if it does seem a
daunting tool to master.
I don't think anyone can make the argument that any (past or current)
graphics-based editor is as efficient when being used to its fullest
as a text-based editor. It's basic math - it takes measurably more
time to move a hand to the mouse, move/click the mouse, and more the
hand back to the touch-typing position than it does to execute even a
moderately complex series of keystrokes. Maybe not large amounts of
time -per action-, but it doesn't take too long for it to add up if
you spend a lot of time editing.
Contrast the time saved by not having to reposition one's hands, the
extensibility, and customization against the learning curve of an
interface that doesn't exactly throw its controls at the user, and
here's the conclusion I think results: graphical interfaces are -
easier- to develop some proficiency with, but proficiency with emacs
pays of far more in the long run.
And if you disagree with me, or if you think I expressed my point
poorly (I'm good that that), all you need to do is ask Steve Yegge his
thoughts on emacs.
-Andrew
On Jun 21, 2:10 pm, Kaldrenon <·········@gmail.com> wrote:
> I don't think anyone can make the argument that any (past or current)
> graphics-based editor is as efficient when being used to its fullest
> as a text-based editor. It's basic math - it takes measurably more
> time to move a hand to the mouse, move/click the mouse, and more the
> hand back to the touch-typing position than it does to execute even a
> moderately complex series of keystrokes. Maybe not large amounts of
> time -per action-, but it doesn't take too long for it to add up if
> you spend a lot of time editing.
>
> Contrast the time saved by not having to reposition one's hands, the
> extensibility, and customization against the learning curve of an
> interface that doesn't exactly throw its controls at the user, and
> here's the conclusion I think results: graphical interfaces are -
> easier- to develop some proficiency with, but proficiency with emacs
> pays of far more in the long run.
I have to point out, that this makes the assumption that the most oft-
used commands in a GUI editor are not as easily accessed from the
keyboard as they are in a terminal editor.
I took a moment to look at the gui editor which has been made
available to me, and short of the "remove leading spaces" commands, I
do not need to remove my hands from the keyboard if I do not want to.
Your statement holds true if, and only if, a user does not take full
advantage of the keyboard commands. But if we're talking about
experienced users in both cases, then that's not an issue, is it?
On Jun 21, 4:31 pm, Falcolas <········@gmail.com> wrote:
> Your statement holds true if, and only if, a user does not take full
> advantage of the keyboard commands. But if we're talking about
> experienced users in both cases, then that's not an issue, is it?
Granted. I suppose my claim should have been more specifically about
the means of interaction, and not about the tool being used. After
all, Emacs 22.1 has fairly complete point-and-click support, even
though I suspect more people use the keyboard as their primary input.
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3vedg6lwd.fsf@borud.not>
[Falcolas <········@gmail.com>]
|
| I took a moment to look at the gui editor which has been made
| available to me, and short of the "remove leading spaces" commands, I
| do not need to remove my hands from the keyboard if I do not want
| to.
well, that depends on the editing features you use. I use a lot of
features I am not consciously aware of, so if I were to list what I
require from an editor, I would have trouble enumerating them.
I can't even tell you what keys they are bound to because I just use
them instinctively. the same goes for VI. (VI having the added
benefit of a really systematic way to organize editing actions into a
sort of a matrix (a useful metaphor I was made aware of by an "expert
VI user" who showed me how to make some editing operations more
efficiently))
having people who are good at efficient editing show you some tricks
really pays off btw. I can't bear to watch other people edit text
because they are doing so much manual labor that could have been
avoided if they had just bothered to learn more effective editing
habits.
-Bj�
On 2007-06-21, Kaldrenon <·········@gmail.com> wrote:
> Feel free to disagree with what I'm about to say.
[...]
> And if you disagree with me, or if you think I expressed my point
> poorly....
I think you expressed it well. I'll add that using one does not
necessarilly exclude using the other. I tend to use whatever makes
the job easiest FOR ME! ...be it a gui or the command line. Also,
ease of learning emacs has absolutely zero to do with mental prowess
and not everyone using it is a code whiz. Except for some html and
shell scripting, I do almost zero developement because it bores me to
freakin' tears. That's not to say I can't like the command line and
emacs.
All types of user interface have their pros and cons and it's
senseless to limit one's self to one or the other. Some tasks benefit
from using both simultaneously, acad and gimp/p-shop being prime
examples. Sure, everyone loves the camaraderie of belonging to a
group. That's just being human. But, choosing a preference doesn't
require fanatical loyalty to the exclusion of all other options, or at
least it shouldn't. Use the one that's best for the job.
nb
> I don't think anyone can make the argument that any (past or current)
> graphics-based editor is as efficient when being used to its fullest
> as a text-based editor.
Clarifying - this part of the claim assumes a fairly similar feature
set, naturally.
From: Matthias Buelow
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <5e063mF35d3v6U1@mid.dfncis.de>
Kaldrenon wrote:
> I don't think anyone can make the argument that any (past or current)
> graphics-based editor is as efficient when being used to its fullest
> as a text-based editor.
Actually, I think the argument can be made:
``We’ve done a cool $50 million of R & D on the Apple Human Interface.
We discovered, among other things, two pertinent facts:
* Test subjects consistently report that keyboarding is faster than
mousing.
* The stopwatch consistently proves mousing is faster than
keyboarding.''
(from http://plan9.bell-labs.com/wiki/plan9/Mouse_vs._keyboard/index.html )
However, at least for me, heavy mousing is stressful to the wrist, so I
prefer to keep my hands on the keyboard (even though I use a trackball,
which greatly reduces the strain for me).
I also think that while intuitive cursor positioning and text selection
operations may be faster with a mouse, complex operations (like on the
shell or complex editor commands) are impractical through a pure
point+click interface.
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m31wg480r6.fsf@borud.not>
[Kaldrenon <·········@gmail.com>]
|
| I don't think anyone can make the argument that any (past or current)
| graphics-based editor is as efficient when being used to its fullest
| as a text-based editor. It's basic math - it takes measurably more
| time to move a hand to the mouse, move/click the mouse, and more the
| hand back to the touch-typing position than it does to execute even a
| moderately complex series of keystrokes. Maybe not large amounts of
| time -per action-, but it doesn't take too long for it to add up if
| you spend a lot of time editing.
a lot of IDE's are getting quite good and you don't have to mouse
around all that much. I think the main reason I stick to Emacs is
because I use it for a wider range of tasks -- not just programming.
also, the IDE's I've used in the past were sluggish and for some
reason the font-rendering was really hard to get right (if at
all). when you spend the majority of your waking hours editing text,
interactive response time and "editing ergonomics" matter a lot.
this reminds me that it is probably time to give IDEs another chance.
it has been a couple of years since the last time I tried a couple for
Java.
-Bj�
From: ······@myrealbox.com
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <5ear80F36ga72U3@mid.individual.net>
In article <··············@borud.not>,
Bjorn Borud <··········@borud.no> wrote:
[ snip ]
> a lot of IDE's are getting quite good and you don't have to mouse
> around all that much. I think the main reason I stick to Emacs is
> because I use it for a wider range of tasks -- not just programming.
>
> also, the IDE's I've used in the past were sluggish and for some
> reason the font-rendering was really hard to get right (if at
> all). when you spend the majority of your waking hours editing text,
> interactive response time and "editing ergonomics" matter a lot.
>
>
> this reminds me that it is probably time to give IDEs another chance.
> it has been a couple of years since the last time I tried a couple for
> Java.
>
A few words from someone else with a strong preference for "learn
one editor well and use it for all text editing" (though maybe
I should admit that my preference is for vim) ....:
I use Eclipse in teaching second-semester programming, mostly
because my department decided it was good to expose students to
command-line tools in CS1 and a "modern" IDE in CS2. In general
it's annoying not to have all those years of vi(m) experience
making things easy for me, and a lot of the features others find
wonderful I find annoying, *but*:
Eclipse has something that generates "import" statements with
a few keystrokes, and for me that's almost in the "killer app
[feature]" class. (Why do I strongly suspect that with the
right plug-ins emacs can do this too? :-) That would send
me searching for the Web site where vim macros are collected.)
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
[Followup-To: header set to comp.emacs]
blmblm myrealbox.com wrote:
> Eclipse has something that generates "import" statements with
> a few keystrokes, and for me that's almost in the "killer app
> [feature]" class. (Why do I strongly suspect that with the
> right plug-ins emacs can do this too? :-)
because emacs exposes its lisp system to the user, allowing one to add
basically any functionality one can come up with? ;-)
--
Joost Kremers ············@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
From: Chris Barts
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <f6eaf9$q2d$1@aioe.org>
······@myrealbox.com <······@myrealbox.com> wrote on Monday 25 June 2007
15:43 in comp.emacs <···············@mid.individual.net>:
>
> Eclipse has something that generates "import" statements with
> a few keystrokes, and for me that's almost in the "killer app
> [feature]" class.
This is a sign of a weak programming language, in my eyes: If you need
keystroke macros to enter boilerplate, you REALLY need a language that
allows you to package commonly-used idioms into macros. (See Common Lisp,
Scheme, Emacs Lisp, and, indeed, even Dylan. Python and Ruby almost solve
the same problem by providing a richer set of primitives, but they aren't
extensible.)
> (Why do I strongly suspect that with the
> right plug-ins emacs can do this too? :-) That would send
> me searching for the Web site where vim macros are collected.)
>
Inserting literal text in Emacs using keystroke macros is trivial. Inserting
more changeable boilerplate is a job for Emacs Lisp.
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
From: Robert Uhl
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3wsxv3nlp.fsf@latakia.dyndns.org>
Falcolas <········@gmail.com> writes:
>
> Being a primarily windows user, I have to question your assertion that
> using ctrl-f for find causes a "mental context switch". For me, in 90%
> of the windows applications, finding something is as simple as ctrl-f,
> the phrase, hit enter. Not terribly different from your set of
> commands. The biggest difference is that if I need to use a Find
> feature I might not often use, I have a visual interface to all the
> related search functions. On the other hand, a terminal program would
> necessitate a memory search at best, or a trip to the help pages at
> worst.
That's the advantage of a well-organised set of commands. If you want
to use regexp search, you have to look at the dialogue box and click on
a checkbox--which would be a context switch.
That's even assuming that your editor _offers_ regexp search. If emacs
didn't have it, I could add it, and it'd be just as much part of the
editor as if it were included...
> The best part of my windows knowledge is that it's transferable to
> most (all?) of the applications I work with. Find is usually ctrl-f.
> Undo is ctrl-z. Save is ctrl-s, yadda yadda. Such knowledge is rarely
> transferable from terminal programs in my experience -- what may be
> true for one program (emacs) is wildly different in another program
> (vi), and useless in yet another (pico).
Consistency is nice. That's be why the emacs are found throughout
Unix. In fact, for a long time Netscape used emacs bindings on Macs and
Windows. Among these bindings are C-a to go the beginning of a line,
C-e to go to the end, C-k to kill from point to the end of the line, M-b
and M-f to move forward and back by word and so forth.
It's Mac OS and Windows which are inconsistent. Emacs has been around
since they were mere glimmers in the eye of Jobs & Gates...
--
Robert Uhl <http://public.xdi.org/=ruhl>
Just because I'm not doing anything, doesn't mean I have nothing to do!
--Ellen Winnie
On Jun 22, 11:28 am, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> That's the advantage of a well-organised set of commands. If you want
> to use regexp search, you have to look at the dialogue box and click on
> a checkbox--which would be a context switch.
Again, you are assuming that the editor isn't set up in a way which
allows this to be done from the keyboard.
ctrl-f, alt-e, type, enter
> That's even assuming that your editor _offers_ regexp search. If emacs
> didn't have it, I could add it, and it'd be just as much part of the
> editor as if it were included...
One advantage I'm more than happy to cede to you - the current program
I use is closed source and not extensible. Though, I'm sure that there
are editors for windows/mac/xwindows which are as extensible as emacs.
> It's Mac OS and Windows which are inconsistent. Emacs has been around
> since they were mere glimmers in the eye of Jobs & Gates...
Inconsistent? I would have to disagree. They changed paradigms -
terminal text based interfaces to GUIs. You wouldn't expect a piece of
software built for a terminal to be backwards compatibility to punch
card interfaces, would you? Why would a GUI based program limit itself
to functionality as defined by a terminal application?
From: Robert Uhl
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3lkeb2q2s.fsf@latakia.dyndns.org>
Falcolas <········@gmail.com> writes:
>
>> It's Mac OS and Windows which are inconsistent. Emacs has been
>> around since they were mere glimmers in the eye of Jobs & Gates...
>
> Inconsistent? I would have to disagree. They changed paradigms -
> terminal text based interfaces to GUIs. You wouldn't expect a piece of
> software built for a terminal to be backwards compatibility to punch
> card interfaces, would you? Why would a GUI based program limit itself
> to functionality as defined by a terminal application?
You're making the assumption that Mac OS in 1984 offered some textual
capability (textual, since we're discussing text editing) which emacs
did not. It didn't.
--
Robert Uhl <http://public.xdi.org/=ruhl>
A: Top posting
Q: What's the most annoying thing about Usenet?
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <85ejk3azjr.fsf@lola.goethe.zz>
Falcolas <········@gmail.com> writes:
> On Jun 22, 11:28 am, Robert Uhl <·········@NOSPAMgmail.com> wrote:
>
>> It's Mac OS and Windows which are inconsistent. Emacs has been
>> around since they were mere glimmers in the eye of Jobs & Gates...
>
> Inconsistent? I would have to disagree. They changed paradigms -
> terminal text based interfaces to GUIs. You wouldn't expect a piece
> of software built for a terminal to be backwards compatibility to
> punch card interfaces, would you?
You are aware that the ubiquitous standard terminal width of 80
columns has been chosen to match the 80-column punch card standard?
> Why would a GUI based program limit itself to functionality as
> defined by a terminal application?
Emacs uses variable width fonts, can deal with a larger-than-8bit
variety of GUI-based input events and can display images. Take a look
at the screen shots for preview-latex
<URL:http://www.gnu.org/software/auctex/preview-latex.html>
illustrating WYSIWYG LaTeX editing in Emacs windows.
So what is your problem?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
On Jun 21, 12:09 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> Twisted <··········@gmail.com> writes:
>
> >> > I have that exact URL now --
> >> >http://www.asktog.com/columns/027InterfacesThatKill.html
>
> >> Utterly unrelated to Emacs.
>
> > I think it is quite relevant. Clunky computer interfaces may not be so
> > dramatically dangerous, but they certainly can hamper productivity.
>
> You're quite right. Windows/Mac user interfaces are so clunky that they
> massively hamper productivity.
This is a joke, right?
> Emacs, OTOH, enables it. For example,
> C-s is search forward; C-r is search backward ('reverse'); C-M-s is
> search forward for a regular expression; C-M-r is search backward for a
> regular expression.
Aside from the collision with the standard in the case of C-s (should
be save focused document if it has unsaved changes), these present no
problem. The inability to find and use them without memorizing all
those keystrokes does present a problem.
> A Windows or Mac editor would have C-s for save,
> and that's it. It might have C-f for find, but it'd pop up a dialogue
> instead of offering an interactive search, causing a mental context
> switch.
Eh? In other words, it works the way it's supposed to. That dialogue
will ordinarily be modeless but floating, so you can get it out of the
way or use it to navigate the document, then edit the document without
having to close the dialogue, and avoid the dialogue disappearing
behind other things. New search can be typed in at the drop of a hat.
Some editors have regular expression searches. All have a
straightforward substring search. Generally if there's anything in the
least arcane (e.g. regular expression searches) there's a ? button to
pop up help, which goes directly to the search help. You can read this
and tab back to the search dialogue with ease, and get them side by
side without any mess or fuss. Of course the dialog offers search
forward and usually search backward. And it normally also offers
search-AND-REPLACE, to boot.
Is this somehow not "interactive" enough for you? Versus having to
memorize a bunch of keys. It also means no esc-meta-alt-ctrl-shift BS,
as the document window needs to have only a few bindings, such as C-f
and C-s, and only the one (C-f) for search; all the search bindings in
the one window in emacs get replaced by just one binding in the
document window and a bunch applicable to the find dialogue. And the
find dialogue can be operated without knowing the bindings by mouse,
and the bindings can be seen directly in the find dialogue by
underlined letters on button labels (see that underlined N in "find
Next"? It means you can hit alt-N while the dialogue has focus,
followed by alt-tab to jump to the document with the next occurrence
selected, or alt-N repeatedly to jump to later occurrences until you
see the one you want, just in case you have rodent allergies).
It has useful key bindings. It is also wise enough to make learning
them optional, so you can learn the ones that speed up your most
common tasks and spare the effort otherwise, where it would consume
more time than it would eventually save you (less common tasks). With
an emacs type interface, you only get to ignore the key bindings for
commands you will NEVER use, rather than ones you use but
infrequently. Forgetting the latter means a trip to the help every
time, also.
> Searching would interrupt one's flow of thought rather than being part of it.
Where does this come from?
Twisted <··········@gmail.com> writes:
> On Jun 21, 12:09 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
>> Twisted <··········@gmail.com> writes:
>>
>> >> > I have that exact URL now --
>> >> >http://www.asktog.com/columns/027InterfacesThatKill.html
>>
>> >> Utterly unrelated to Emacs.
>>
>> > I think it is quite relevant. Clunky computer interfaces may not be so
>> > dramatically dangerous, but they certainly can hamper productivity.
>>
>> You're quite right. Windows/Mac user interfaces are so clunky that they
>> massively hamper productivity.
>
> This is a joke, right?
How do you call a Mac user interface that let a user work during 3
hours to do a simple modification to a MS-Word file that takes 15
seconds to do with emacs or a simple unix script?
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
On Jun 22, 3:06 pm, Pascal Bourguignon <····@informatimago.com> wrote:
> How do you call a Mac user interface that let a user work during 3
> hours to do a simple modification to a MS-Word file that takes 15
> seconds to do with emacs or a simple unix script?
Would you mind elaborating on *what* took 3 hours to do, as opposed to
just throwing around unquantified numbers? Would you also mind
explaining the user's familiarity with the tools they were using on
the mac?
It's just as easy for me to say that it took me 30 minutes to simply
exit emacs, and use that to justify that emacs, and by extension
Linux, is a terrible tool.
Falcolas <········@gmail.com> writes:
> On Jun 22, 3:06 pm, Pascal Bourguignon <····@informatimago.com> wrote:
>> How do you call a Mac user interface that let a user work during 3
>> hours to do a simple modification to a MS-Word file that takes 15
>> seconds to do with emacs or a simple unix script?
>
> Would you mind elaborating on *what* took 3 hours to do, as opposed to
> just throwing around unquantified numbers? Would you also mind
> explaining the user's familiarity with the tools they were using on
> the mac?
Anything that the user have to do repeatitively with the GUI, like
copy-and-paste, or reformating of a lot of paragraphs or table
entries, and which is done automatically by writting a one-liner
program in emacs or shell.
And they tried to put graphical user interfaces on scripting, it
doesn't work either. Programming is working with text, with verbs.
> It's just as easy for me to say that it took me 30 minutes to simply
> exit emacs, and use that to justify that emacs, and by extension
> Linux, is a terrible tool.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
On Jun 22, 4:12 pm, Pascal Bourguignon <····@informatimago.com> wrote:
> Anything that the user have to do repeatitively with the GUI, like
> copy-and-paste, or reformating of a lot of paragraphs or table
> entries, and which is done automatically by writting a one-liner
> program in emacs or shell.
So the tool they were using did not support macros? You're right, that
would suck. I'm guessing this is before you could expose the Unix
underpinnings on the mac.
I will agree that I do miss much of the standard shell utility when
working in windows. Fortunately, I am able to replace a lot of that
with well written python or perl scripts.
> And they tried to put graphical user interfaces on scripting, it
> doesn't work either. Programming is working with text, with verbs.
Recording macros could be considered a form of programming, which can
have nothing to do with any text. Granted, they're pretty dumb if you
don't manually modify them, but really, nothing is stopping you from
modifying them either. I can't count the number of times I've created
a macro to do repeated modification of a text file.
I guess ultimately I'm trying to argue the point that just because a
tool was written with a GUI or on Windows does not automatically make
it any less a productive tool than a text based terminal tool. Even in
windows, you can use the keyboard to do all of your work, if you learn
how (thanks to the magic of the alt key).
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3vedebtek.fsf@borud.not>
[Falcolas <········@gmail.com>]
|
| I guess ultimately I'm trying to argue the point that just because a
| tool was written with a GUI or on Windows does not automatically make
| it any less a productive tool than a text based terminal tool. Even in
| windows, you can use the keyboard to do all of your work, if you learn
| how (thanks to the magic of the alt key).
as I see it, the debate isn't whether GUI tools are inferior per se,
but whether Emacs is inferior since it has its own interaction
concepts that do not map 1:1 to GUI conventions of Windows and OSX.
the point I am trying to get across is that Emacs (and vi) is its own
niche, and that if you want to improve them, there are more important
things than fiddling around with superficial details (like keybindings
-- which you can customize to your own liking anyway).
for Emacs it would be far more helpful if the Lisp-implementation was
replaced with one that is more efficient and Common Lisp-like.
(indeed several friends of mine would like to see Emacs done in Common
Lisp, and I seem to have some memory of such a project existing
somewhere).
-Bj�
[ Newsgroups trimmed to comp.emacs & comp.lang.lisp. ]
On 2007-06-23, Bjorn Borud <··········@borud.no> wrote:
> for Emacs it would be far more helpful if the Lisp-implementation
> was replaced with one that is more efficient and Common Lisp-like.
I like Lispworks. Compiles to machine code on at least three
platforms, multi-threaded, reasonably Emacs-like (as near as *I* can
tell, at least; I'm a Vimmer from way back). Editor source included
with the Professional and Enterprise licenses. (Are you willing to
spend some $$ to optimize your editing experience? I was.)
And you get a commercial-class Common Lisp compiler thrown in to boot.
;)
One of these days I'll have to go through the license agreement in
detail and see if I can legally distribute binaries of an editor with
the compiler included.
-- Larry
Bjorn Borud wrote:
> [Falcolas <········@gmail.com>]
> |
> | I guess ultimately I'm trying to argue the point that just because a
> | tool was written with a GUI or on Windows does not automatically
> | make it any less a productive tool than a text based terminal tool.
> | Even in windows, you can use the keyboard to do all of your work, if
> | you learn how (thanks to the magic of the alt key).
>
> as I see it, the debate isn't whether GUI tools are inferior per se,
> but whether Emacs is inferior since it has its own interaction
> concepts that do not map 1:1 to GUI conventions of Windows and OSX.
I think it worthwile to point out again here that emacs does in fact
have a bitmapped, windowy GUI, has done for years - e.g.
http://oldr.net/emacshelp4.gif ...
Some people in this silly thread (not Bj�rn specifically) seem to be
labouring under the impression that it is solely a text-only
interface - "Mouse longcuts" exist for the most basic keyboard commands
when you're using emacs on a WIMP system like X11 or Microsoft Windows
(though you can turn them off to stop wasting screen real estate on
pretty-pretty once you know the keyboard commands)
> (indeed several friends of mine would like to see Emacs done in Common
> Lisp, and I seem to have some memory of such a project existing
> somewhere).
>
Climacs @
http://common-lisp.net/project/climacs/
From: Robert Uhl
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3lkea1868.fsf@latakia.dyndns.org>
Bjorn Borud <··········@borud.no> writes:
>
> for Emacs it would be far more helpful if the Lisp-implementation was
> replaced with one that is more efficient and Common Lisp-like.
> (indeed several friends of mine would like to see Emacs done in Common
> Lisp, and I seem to have some memory of such a project existing
> somewhere).
Agreed. Stallman got sidetracked by Scheme, which IMHO was a dead-end.
A Common Lisp emacs would be pretty sweet. There's a Climacs project,
but they're just focused on providing an editor, not on providing a
full-fledged emacs.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Cinder blocks: $100
Mortar: $30
A cask of amontillado: $300
The faint screams of a desperate PHB: priceless. --O. Schwarz
[ Newsgroups snipped to comp.emacs & c.l.l ]
On 2007-06-24, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> Bjorn Borud <··········@borud.no> writes:
>> for Emacs it would be far more helpful if the Lisp-implementation
>> was replaced with one that is more efficient and Common Lisp-like.
>> (indeed several friends of mine would like to see Emacs done in
>> Common Lisp, and I seem to have some memory of such a project
>> existing somewhere).
>
> Agreed. Stallman got sidetracked by Scheme, which IMHO was a
> dead-end. A Common Lisp emacs would be pretty sweet. There's a
> Climacs project, but they're just focused on providing an editor,
> not on providing a full-fledged emacs.
You could, you know, help out. Or use Lispworks. Just a thought.
From: Robert Uhl
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3veddynb3.fsf@latakia.dyndns.org>
Larry Clapp <·····@theclapp.org> writes:
>
>> Agreed. Stallman got sidetracked by Scheme, which IMHO was a
>> dead-end. A Common Lisp emacs would be pretty sweet. There's a
>> Climacs project, but they're just focused on providing an editor, not
>> on providing a full-fledged emacs.
>
> You could, you know, help out.
No, they're dead-set against an editor which does anything more than
edit text (philistines!); from
<http://common-lisp.net/project/climacs/>:
...we are not interested in:
* Mail and News readers (see mel and Hermes);
* A debugger (see the debugger pane of McCLIM);
* An inspector (see the inspector pane of McCLIM, affectionately
known as Clouseau);
* Dired, Bufed, Shell mode, Calendar and other functionality that is
best done as a CLIM pane or a separate CLIM application.
And they don't really want to run on a terminal, from what I can tell.
> Or use Lispworks.
It's not free, so I won't use it. Right now the only non-free software
I have is JungleDisk, but as soon as I get a nice round tuit (and get
CL-Ironclad and CL-S3 and Cl-WEBDAV working) I'm going to replace it.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Si jeunesse savait, si vieillesse pouvait
If youth only knew, if age only could
--Henri Estienne, 1531-98
From: Robert Strandh
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <6wwsxsp5bk.fsf@serveur5.labri.fr>
Robert Uhl <·········@NOSPAMgmail.com> writes:
> No, they're dead-set against an editor which does anything more than
> edit text (philistines!); from
> <http://common-lisp.net/project/climacs/>:
>
> ...we are not interested in:
>
> * Mail and News readers (see mel and Hermes);
>
> * A debugger (see the debugger pane of McCLIM);
>
> * An inspector (see the inspector pane of McCLIM, affectionately
> known as Clouseau);
>
> * Dired, Bufed, Shell mode, Calendar and other functionality that is
> best done as a CLIM pane or a separate CLIM application.
>
> And they don't really want to run on a terminal, from what I can tell.
I am the one who wrote those lines. The reason I don't think it is a
good idea to provide these tools within the Climacs framework is that
we have CLIM underneath, which Emacs doesn't have.
What I would like to see are independent applications that communicate
through CLIM. The effect would be the same as if they ran as Climacs
subsystems, but I think the architecture would be better with
independent applications. If you would like an Emacs look-and-feel of
those applications, you could for instance use the ESA library (for
Emacs-Style Application) which provides much of that look-and-feel.
--
Robert Strandh
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3vedau5rt.fsf@borud.not>
[Robert Uhl <·········@NOSPAMgmail.com>]
|
| Agreed. Stallman got sidetracked by Scheme, which IMHO was a
| dead-end.
too many people buying SICP and believing what they heard about it
being an important book. I too spent some time exploring Scheme, or
should I say, wasted some time, years ago, and nothing came of it
other than a profound irritation. these people seemed to be
completely disconnected from reality.
Scheme, and thus Guile, might have been a viable path if these people
had only been practical instead of stubbornly insisting on being odd.
| A Common Lisp emacs would be pretty sweet. There's a Climacs project,
| but they're just focused on providing an editor, not on providing a
| full-fledged emacs.
if nothing else, a proper Emacs in Common Lisp might give me a reason
to learn Lisp properly.
-Bj�
On Tue, 26 Jun 2007, Bjorn Borud wrote:
> [Robert Uhl <·········@NOSPAMgmail.com>]
> |
> | Agreed. Stallman got sidetracked by Scheme, which IMHO was a
> | dead-end.
>
> too many people buying SICP and believing what they heard about it
> being an important book. I too spent some time exploring Scheme, or
> should I say, wasted some time, years ago, and nothing came of it
> other than a profound irritation.
>
Did you expect something specific before starting to read that
book? Thats a failure. SICP is a book you should read just for pure
pleasure.
> these people seemed to be
> completely disconnected from reality.
Please don't write things like that without backing it up with some
reason.
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3odj1y9hb.fsf@borud.not>
["Kjetil S. Matheussen" <··············@notam02.no>]
|
| Did you expect something specific before starting to read that book?
| Thats a failure. SICP is a book you should read just for pure
| pleasure.
I was told by a lot of people I consider to be intelligent that this
book would change how I think about writing software. it didn't. I
didn't really know what to expect, but after reading it I did feel
that its importance was greatly exaggerated.
| > these people seemed to be
| > completely disconnected from reality.
|
| Please don't write things like that without backing it up with some
| reason.
well, for one, Scheme lacked proper libraries for doing everyday
things, so when I tried to use it I found myself writing a lot of
library code that I shouldn't have had to deal with. but it is quite
long ago, so things might have changed since then.
-Bj�
On Wed, 27 Jun 2007, Bjorn Borud wrote:
> | > these people seemed to be
> | > completely disconnected from reality.
> |
> | Please don't write things like that without backing it up with some
> | reason.
>
> well, for one, Scheme lacked proper libraries for doing everyday
> things, so when I tried to use it I found myself writing a lot of
> library code that I shouldn't have had to deal with. but it is quite
> long ago, so things might have changed since then.
>
Things have probably changed a little, but the stuff in SISC isn't
specific for scheme, although a schemish language is used in the book.
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3ir99wnld.fsf@borud.not>
["Kjetil S. Matheussen" <··············@notam02.no>]
|
| Things have probably changed a little, but the stuff in SISC isn't
| specific for scheme, although a schemish language is used in the book.
well, those are really two separate discussions: Scheme and whether
SICP is an important book or not.
-Bj�
From: Matthias Buelow
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <5efg6iF38nuukU1@mid.dfncis.de>
Bjorn Borud wrote:
> I was told by a lot of people I consider to be intelligent that this
> book would change how I think about writing software. it didn't. I
> didn't really know what to expect, but after reading it I did feel
> that its importance was greatly exaggerated.
I think it's basically a course book, for some CS courses at MIT that it
was originally used with, and that's it. It's not superb but ok, as far
as "lecture notes" go, a bit pretentious and a bit idiosyncratic,
probably due to being targeted mainly at students visiting a particular
course of lectures. I don't think it's supposed to be a general "how to
learn good programming"-style book although I don't think you've wasted
time reading it.
F'up-to: c.l.lisp.
On Jun 26, 10:52 am, Bjorn Borud <··········@borud.no> wrote:
> [Robert Uhl <·········@NOSPAMgmail.com>]
> |
> | Agreed. Stallman got sidetracked by Scheme, which IMHO was a
> | dead-end.
>
> too many people buying SICP and believing what they heard about it
> being an important book. I too spent some time exploring Scheme, or
> should I say, wasted some time, years ago, and nothing came of it
> other than a profound irritation. these people seemed to be
> completely disconnected from reality.
>
> Scheme, and thus Guile, might have been a viable path if these people
> had only been practical instead of stubbornly insisting on being odd.
Some people might say the same thing about emacs. A lot of unix tools
even. "Stubbornly insisting on being odd" appears to be a particularly
prevalent character flaw among the geeknoscenti.
On Wed, 27 Jun 2007 00:07:04 -0000, Twisted <··········@gmail.com> tried to
confuse everyone with this message:
>"Stubbornly insisting on being odd" appears to be a particularly
>prevalent character flaw among the geeknoscenti.
>
Oh the irony.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3ir99y9bf.fsf@borud.not>
[Twisted <··········@gmail.com>]
|
| Some people might say the same thing about emacs. A lot of unix tools
| even. "Stubbornly insisting on being odd" appears to be a particularly
| prevalent character flaw among the geeknoscenti.
I think you are missing the point. you may find Emacs (and UNIX) to
be odd, and you consistently parade this around as a reason not to
even make an honest attempt at understanding how to use it (them). if
the oddness still eclipses usefulness once you've made a proper
attempt at understanding a tool, then the oddness is a problem. Emacs
(and UNIX) don't exhibit these characteristics for a great number of
people.
-Bj�
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <85k5tvazza.fsf@lola.goethe.zz>
Pascal Bourguignon <···@informatimago.com> writes:
> Falcolas <········@gmail.com> writes:
>>
>> Would you mind elaborating on *what* took 3 hours to do, as opposed
>> to just throwing around unquantified numbers? Would you also mind
>> explaining the user's familiarity with the tools they were using on
>> the mac?
>
> Anything that the user have to do repeatitively with the GUI, like
> copy-and-paste, or reformating of a lot of paragraphs or table
> entries, and which is done automatically by writting a one-liner
> program in emacs or shell.
Actually, in Emacs the task more often than not is solved by using
C-h a or M-x apropos and then finding the command that already does
the job.
>> It's just as easy for me to say that it took me 30 minutes to
>> simply exit emacs, and use that to justify that emacs, and by
>> extension Linux, is a terrible tool.
Somebody who needs 30 minutes to find the File/Exit Emacs menu is not
qualified for reporting _any_ computing experience.
It is like letting yourself get a report about the points of violin
playing from somebody who has just had his first exposure to music,
incidentally in the form of a violin lesson.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3fy4k836a.fsf@borud.not>
[Twisted <··········@gmail.com>]
|
| I think it is quite relevant. Clunky computer interfaces may not be so
| dramatically dangerous, but they certainly can hamper productivity.
| Between Windows bugs and gratuitous misfeatures (e.g. DRM) and Unix
| clunkiness, billions of dollars of potential productivity is lost
| worldwide every *month*.
bah, UNIX is not user hostile; it is just selective about its
friends.
-Bj�
Bjorn Borud <··········@borud.no> wrote:
>
>bah, UNIX is not user hostile; it is just selective about its
>friends.
Right. My favorite Unix quote is from the same source (Dennis Ritchie):
Unix is the answer. You just have to phrase the
question very carefully.
--
Tim Roberts, ····@probo.com
Providenza & Boekelheide, Inc.
From: Matthias Buelow
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <5dtk4tF34jrimU1@mid.dfncis.de>
Twisted wrote:
> That's a joke, right? I tried it a time or two. Every time it was
> rapidly apparent that doing anything non-trivial would require
> consulting a cheat sheet. The printed-out kind, since navigating to
> the help and back without already having the help displayed and open
> to the command reference was also non-trivial.
Ah, yes.. we live in a time where no-one seems to have the patience to
read documentation anymore. Maybe that's why there is such a scarcity of
good documentation with many "modern" software packages.
Here's a nice one from Ken Thompson:
``I abhor a system designed for the "user", if that word is a coded
pejorative meaning "stupid and unsophisticated".''
On Jun 20, 5:22 pm, Matthias Buelow <····@incubus.de> wrote:
> Twisted wrote:
> > That's a joke, right? I tried it a time or two. Every time it was
> > rapidly apparent that doing anything non-trivial would require
> > consulting a cheat sheet. The printed-out kind, since navigating to
> > the help and back without already having the help displayed and open
> > to the command reference was also non-trivial.
>
> Ah, yes.. we live in a time where no-one seems to have the patience to
> read documentation anymore. Maybe that's why there is such a scarcity of
> good documentation with many "modern" software packages.
Emacs does have documentation. The problem is you have to already know
a load of emacs navigation oddities^Wkeyboard commands to get to and
use it.
Also, basic tasks should not require consulting the documentation,
unless the application genre is new to the user. Basic tasks requiring
the uninitiated to consult the documentation is okay in 3D modeling
apps, given the "uninitiated" have used none before. Basic tasks
requiring the uninitiated to consult the documentation is absolutely
ludicrous in a text editor.
I count "consulting the documentation" as one of those basic tasks,
along with the fundamental editing, saving, loading, and searching
functionality (including, of course, "searching the documentation").
> ``I abhor a system designed for the "user", if that word is a coded
> pejorative meaning "stupid and unsophisticated".''
Yeah, and I abhor the elitist systems that are designed with the
philosophy that anyone who hasn't mastered years of arcane
memorization and training in just that one idiosyncratic system is /
ipso facto/ "stupid and unsophisticated". Most of us 6 and a half
billion people have better uses for our time, such as buckling in and
being promptly productive, once we're out of high school or college,
and fully three and a quarter of us are at least as smart as average,
and so /ipso facto/ *not* "stupid and unsophisticated".
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <85ejk6fgqz.fsf@lola.goethe.zz>
Twisted <··········@gmail.com> writes:
> On Jun 20, 5:22 pm, Matthias Buelow <····@incubus.de> wrote:
>> Twisted wrote:
>> > That's a joke, right? I tried it a time or two. Every time it was
>> > rapidly apparent that doing anything non-trivial would require
>> > consulting a cheat sheet. The printed-out kind, since navigating to
>> > the help and back without already having the help displayed and open
>> > to the command reference was also non-trivial.
>>
>> Ah, yes.. we live in a time where no-one seems to have the patience to
>> read documentation anymore. Maybe that's why there is such a scarcity of
>> good documentation with many "modern" software packages.
>
> Emacs does have documentation. The problem is you have to already
> know a load of emacs navigation oddities^Wkeyboard commands to get
> to and use it.
Menus and toolbars exist.
> Also, basic tasks should not require consulting the documentation,
> unless the application genre is new to the user.
And they don't.
Really, what is the last version of Emacs you actually tried?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Matthias Buelow
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <5dtlavF34is51U1@mid.dfncis.de>
Twisted wrote:
> Emacs does have documentation. The problem is you have to already know
> a load of emacs navigation oddities^Wkeyboard commands to get to and
> use it.
Yes, like hitting the F1 key.
> Yeah, and I abhor the elitist systems that are designed with the
> philosophy that anyone who hasn't mastered years of arcane
> memorization and training in just that one idiosyncratic system is /
> ipso facto/ "stupid and unsophisticated". Most of us 6 and a half
> billion people have better uses for our time, such as buckling in and
> being promptly productive, once we're out of high school or college,
> and fully three and a quarter of us are at least as smart as average,
> and so /ipso facto/ *not* "stupid and unsophisticated".
Noone forces you to use either Unix or emacs (or vi, for that matter).
I don't really understand what your problem is.
Twisted <··········@gmail.com> writes:
> Yeah, and I abhor the elitist systems that are designed with the
> philosophy that anyone who hasn't mastered years of arcane
> memorization and training in just that one idiosyncratic system is /
> ipso facto/ "stupid and unsophisticated". Most of us 6 and a half
> billion people have better uses for our time, such as buckling in and
> being promptly productive, once we're out of high school or college,
> and fully three and a quarter of us are at least as smart as average,
> and so /ipso facto/ *not* "stupid and unsophisticated".
>
You see, though, the problem is that computers are *not* easy to use.
People only say that they've been made easy to use in order to *sell*
things. The number one commodity in the technology business (with a
huge profit-margin attached to it) is "user-friendly." And it's
baloney! No one in my office that uses one of these supposedly
user-friendly machines thinks that it's actually easy to use. They
slam their keyboards and throw their hands up *every* day.
The only solution that really works is for people to _learn_ how to
use computers, and to accept that it will be a challenge.
And as for the arcane commands needed to get to the help page, their
on the splash screen. Have you used Emacs recently?
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest:
http://www.gnu.org/philosophy/sylvester-response.html
On Jun 21, 11:06 am, ········@partners.org (Joel J. Adamson) wrote:
> And it's baloney! No one in my office that uses one of these supposedly
> user-friendly machines thinks that it's actually easy to use. They
> slam their keyboards and throw their hands up *every* day.
Because of bugs or the network going down or stuff like that, I'll
bet, not because they can't find out or remember how to do some basic
task.
That's entirely orthogonal to the issue of interface learning curve OR
interface ease-of-use. Emacs has deficiencies in both areas, if
principally the former. (For an example of the latter, consider
opening a file. Can't remember the exact spelling and capitalization
of the file name? Sorry, bud, you're SOL. Go find it in some other app
and memorize the name, then return to emacs. Now THAT is what I call
disruptive context switching. Meanwhile even the lowly Notepad
responds to "open" by displaying a list of text files and tools to
navigate the folder hierarchy without having to do it blind, while
still letting you blind-type a path if you remember it. And you can
also paste the path in from the clipboard. Unix systems don't even
*have* a proper system-wide clipboard and copy/paste capability. Under
X there's a weak, text-only imitation, which doesn't help you much
when you want to copy a selection from an image in a paint program and
paste it into a CAD or web-design or specialized image-manipulation
tool or whatever...you have to save it to a file and load it, which is
a pain in the butt and slowly clutters your hard drive with
"temporary" files you occasionally forget to delete.
> The only solution that really works is for people to _learn_ how to
> use computers, and to accept that it will be a challenge.
How much learning it takes can be varied by the programmer, however.
They can choose to make the learning curve steeply vertical at
takeoff, or they can make it start out shallow and climb steeply only
when the user desires expert functionality. (They can also, stupidly,
choose to leave out fancier functionality entirely, of course.)
As for bugs and other frustrations, better robustness in the key areas
of memory management and concurrency control is needed. Most serious
(especially crash-causing, data-losing, or data-corrupting) bugs
involve memory mismanagement and a lot more, as well as other serious
bugs, result from race conditions. These sorts of bugs are also
responsible for a lot of security holes -- buffer overrun exploits are
only possible against targets with memory management and input
validation bugs. Java apps, due to Java's memory management model, are
immune to these.
The Windows world may have a fair bit to learn from the Unix world
about software reliability and QA, and also about better supporting
task automation. But not about user interface design for when tasks
are done manually.
> And as for the arcane commands needed to get to the help page, their
> on the splash screen. Have you used Emacs recently?
Of course not. It's too hard to get started using it, so I gave up on
it years ago.
Twisted wrote:
> Of course not. It's too hard to get started using it, so I gave up on
> it years ago.
So wtf makes you think you're remotely qualified to comment about
emacs as it stands today? Idiot.
Twisted <··········@gmail.com> writes:
> The Windows world may have a fair bit to learn from the Unix world
> about software reliability and QA, and also about better supporting
> task automation. But not about user interface design for when tasks
> are done manually.
That's the point. Manual tasks have nothing to do in computers.
Computers are there to automatize tasks, not to give you more manual work.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <85sl8jb0bv.fsf@lola.goethe.zz>
Twisted <··········@gmail.com> writes:
> That's entirely orthogonal to the issue of interface learning curve
> OR interface ease-of-use. Emacs has deficiencies in both areas, if
> principally the former. (For an example of the latter, consider
> opening a file. Can't remember the exact spelling and capitalization
> of the file name? Sorry, bud, you're SOL. Go find it in some other
> app and memorize the name, then return to emacs. Now THAT is what I
> call disruptive context switching.
Again, you are talking nonsense out of ignorance. When you are _not_
using filename completion, any case entry on a case insensitive file
system will work (even when we are talking about a FAT/NT file system
mounted on Unix). And _when_ you are using filename completion, on
_those_ systems where case insensitive file names are standard
(DOS/Windows/VMS/MacOSX), Emacs will notice and replace stuff with the
proper case _when completing_ (in all other cases, there is no problem
in mixing up case in the context of case insensitive file systems).
If you want a different standard than that of your operating system,
customize the variable `read-file-name-completion-ignore-case'.
It would probably be most clever if Emacs completed case-independently
only on those parts of a file name which are on a case-independent
file system (or a case independent context) so that a file name like
····@box.gnu.org:/media/usbstick/Photos/nice.jpg
~~~~~~~~~~~ ~~~~~~~~~~~~~~~
would get case-insensitive completion just on the underlines areas.
In practice, it is actually more the users than the operating systems
which are or are not comfortable with the consequences of case
sensitivity, and so making the default depend on the default
convention of the system seems reasonable.
So please: before you continue spewing about a system you don't even
know, could you educate yourself about the state of affairs?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Robert Uhl
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3y7ia196d.fsf@latakia.dyndns.org>
Twisted <··········@gmail.com> writes:
>
> For an example of the latter, consider opening a file. Can't remember
> the exact spelling and capitalization of the file name? Sorry, bud,
> you're SOL. Go find it in some other app and memorize the name, then
> return to emacs.
Once again I am forced to wonder if you have _ever_ actually used
emacs. find-file has tab completion: hit tab without anything typed, and
it displays _everything_ in the directory; type a few characters to
narrow it down; hit tab to complete the filename and be done with it.
Or of course you could use directory mode, which enables you to navigate
around a directory tree, performing actions on files (including editing
them).
Then of course there's ido.el, which is even better: type a few
characters from anywhere in the name, and it displays files matching
those characters.
You've never actually run emacs, have you?
--
Robert Uhl <http://public.xdi.org/=ruhl>
The power of Satan is as nothing before the might of the Lord, so don't
go getting any ideas. --I Abyssinians 20:20
On Jun 23, 8:35 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> Twisted <··········@gmail.com> writes:
>
> > For an example of the latter, consider opening a file. Can't remember
> > the exact spelling and capitalization of the file name? Sorry, bud,
> > you're SOL. Go find it in some other app and memorize the name, then
> > return to emacs.
>
> Once again I am forced to wonder if you have _ever_ actually used
> emacs. find-file has tab completion: hit tab without anything typed, and
> it displays _everything_ in the directory; type a few characters to
> narrow it down; hit tab to complete the filename and be done with it.
>
> Or of course you could use directory mode, which enables you to navigate
> around a directory tree, performing actions on files (including editing
> them).
>
> Then of course there's ido.el, which is even better: type a few
> characters from anywhere in the name, and it displays files matching
> those characters.
Really? None of this happens if you just do the straightforward file-
open command, which should obviously at least provide a navigable
directory tree, but definitely does not. One sounds like it involves
managing a separate open window on each directory you're interested in
(versus having a file...open dialog that falls open to the last place
you'd left it and doesn't clutter up any space when you're not opening
a file); the other sounds like it involves actually installing a
plugin of some kind, which is obviously well beyond what a beginner
should need to do just to get a freaking directory listing. :) Tab
completion is a poor cousin to a real directory tree navigator, as I'm
sure most would agree. Even if it will show all matches to a partial
name instead of none, it's the textual equivalent of navigating a
directory tree made into menus instead of provided by a proper folder
view window. Windows users unfortunately have the experience
regularly: the notorious Start menu. You have to expand submenus to
find stuff, and you can't leave it idling to do something somewhere
else and come back to it because it's a menu. Moreover, clicking an
item may display a large number of items the next level down, which
runs into screen display space issues. Even a large video mode can't
hide the fact that menus weren't really designed to list hundreds of
sibling items or for scrolling or finding stuff in a large set of
files, unlike folder windows. I can only imagine the pain of trying to
navigate an equivalent way in an 80x25 box of text information. That
would be like navigating the Windows start menu from outside your
house by peeking through a keyhole and reaching through a window with
a repurposed straightened out coathanger. Clumsy AND the neighbors'll
see you and call the cops well before you find the item you're looking
for. :) (Navigating the Windows start menu in safe mode, at 640x480,
is about as close as most Windows users are ever likely to come to the
nightmare of opening a file in emacs when you don't already know its
exact path.)
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <85veddet6t.fsf@lola.goethe.zz>
Twisted <··········@gmail.com> writes:
> On Jun 23, 8:35 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
>> Twisted <··········@gmail.com> writes:
>>
>> > For an example of the latter, consider opening a file. Can't remember
>> > the exact spelling and capitalization of the file name? Sorry, bud,
>> > you're SOL. Go find it in some other app and memorize the name, then
>> > return to emacs.
>>
>> Once again I am forced to wonder if you have _ever_ actually used
>> emacs. find-file has tab completion: hit tab without anything typed, and
>> it displays _everything_ in the directory; type a few characters to
>> narrow it down; hit tab to complete the filename and be done with it.
>>
>> Or of course you could use directory mode, which enables you to navigate
>> around a directory tree, performing actions on files (including editing
>> them).
>>
>> Then of course there's ido.el, which is even better: type a few
>> characters from anywhere in the name, and it displays files matching
>> those characters.
>
> Really? None of this happens if you just do the straightforward file-
> open command, which should obviously at least provide a navigable
> directory tree, but definitely does not.
It definitely _does_ when you are using the mouse to open your file
dialog. Again, _try_ a current version of Emacs before showing your
ignorance.
[Other nonsensical speculation deleted]
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Robert Uhl
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3zm2pynhk.fsf@latakia.dyndns.org>
Twisted <··········@gmail.com> writes:
> On Jun 23, 8:35 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
>> Twisted <··········@gmail.com> writes:
>>
>> > For an example of the latter, consider opening a file. Can't remember
>> > the exact spelling and capitalization of the file name? Sorry, bud,
>> > you're SOL. Go find it in some other app and memorize the name, then
>> > return to emacs.
>>
>> Once again I am forced to wonder if you have _ever_ actually used
>> emacs. find-file has tab completion: hit tab without anything typed, and
>> it displays _everything_ in the directory; type a few characters to
>> narrow it down; hit tab to complete the filename and be done with it.
>>
>> Or of course you could use directory mode, which enables you to navigate
>> around a directory tree, performing actions on files (including editing
>> them).
>>
>> Then of course there's ido.el, which is even better: type a few
>> characters from anywhere in the name, and it displays files matching
>> those characters.
>
> Really? None of this happens if you just do the straightforward file-
> open command, which should obviously at least provide a navigable
> directory tree, but definitely does not.
The first does. Really, it does. Fire up emacs (which you've never
done before) and type C-x C-f. You will be presented with a prompt
something like 'Find file: ~/'; hit tab once; you'll see the message
'[Complete, but not unique]'; hit tab again and you will be presented a
list of all files in that directory.
> Tab completion is a poor cousin to a real directory tree navigator, as
> I'm sure most would agree.
I wouldn't. There are several directory navigators installed on this
machine, but I never use anything more than bash's tab completion.
If you like 'em, though, just select File:Visit New File. It gives you
a platform-default (gtk+, for me) file selector.
> Even if it will show all matches to a partial name instead of none,
> it's the textual equivalent of navigating a directory tree made into
> menus instead of provided by a proper folder view window. Windows
> users unfortunately have the experience regularly: the notorious Start
> menu. You have to expand submenus to find stuff, and you can't leave
> it idling to do something somewhere else and come back to it because
> it's a menu.
Nope, because of the way emacs works you can stop what you're doing, do
something else and come back to the minibuffer. As an example, while I
was typing the first paragraph, I had find-file running in the
minibuffer (I was checking for the exact prompts and phrases used).
> I can only imagine the pain of trying to navigate an equivalent way in
> an 80x25 box of text information.
Fortunately, folks brighter than you & I have imagined a nice way for
us. It pops up a new Emacs window (pane, if you prefer the terminology)
showing a list of all filenames. You could continue typing, or just
click on a filename in the window, or hit return while the cursor is on
a filename in that window.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Dilbert: Not more than ten minutes ago you beat a man senseless.
Alice: He was senseless before I beat him.
On 25 Jun., 00:52, Robert Uhl <·········@NOSPAMgmail.com> wrote:
You guys are all in the wrong newsgroups. Please stay in comp.emacs
when discussing Emacs. Don't cross post.
Not everyone is interested in Emacs discussions.
Thanks.
Follow-up set to comp.emacs.
On Jun 24, 6:52 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> > Really? None of [navigating a folder window analogue] happens if
> > you just do the straightforward file-open command, which should
> > obviously at least provide a navigable directory tree, but
> > definitely does not.
>
> The first does. Really, it does. Fire up emacs (which you've never
> done before) and type C-x C-f.
Whoa, Nellie. I seem to recall we were discussing the file-open
command.
That was something else, like C-x C-o or something. More apples-and-
oranges?
> You will be presented with a prompt
> something like 'Find file: ~/'; hit tab once; you'll see the message
> '[Complete, but not unique]'; hit tab again and you will be presented a
> list of all files in that directory.
Sounds clunky anyway. I don't need a bunch of keypresses to do the
equivalent in an Explorer-based file-open dialog in a native Windows
app. Just a double-click.
Emacs, with your C-x C-f:
C-x C-f tab tab ("Startofnameofdirectory somethingElse
otherstuff")
Startofname tab tab ("Subdirectory anotherSubdirectory")
Subd tab tab
Windows:
Alt, f, o ("Startofnameofdirectory somethingElse
otherstuff")
Click-click
or Startofname-down-enter ("Subdirectory anotherSubdirectory")
Click-click
or Subd-down-enter
Worst case (all keyboard): one fewer keypress. Best case (judicious
use of the mouse and smart hand placement, one by left alt and one on
the mouse): five TOTAL gestures.
In particular, C-x C-f tab tab is replaced by alt f o (four down to
three keypresses) or click file, click open (two instead of three
inputs, but you have to locate the File menu from halfway across the
screen with the pointer, so count it as three as well).
Being able to pick an item from a list just by touching the damn thing
instead of typing in a sufficiently long prefix is definitely an
advantage, and if a lot of things share the same 16-character prefix
in a particular directory, the emacs way starts to look SLOW.
Of course, there's an even faster Windows way, if you don't mind not
seeing lists of possible items:
Alt, f, o
Startofname-down-/-Subd-down-/
Straight to the subdirectory without waiting for it to display the
parent directory or the root. Same number of inputs. And of course
there's the super-fast
Alt, f, o, C-v, enter
if you happen to have the exact path in the clipboard already. I'd
like to see emacs do that, at least if the text to paste originated
outside emacs. (If I'm doing this in Winword's file open dialog it
could have originated in Notepad, Firefox, or just about anywhere
else, not just Winword.)
> If you like 'em, though, just select File:Visit New File. It gives you
> a platform-default (gtk+, for me) file selector.
Now we're talking about a graphical port instead of stock emacs
again. :P
> Nope, because of the way emacs works you can stop what you're doing, do
> something else and come back to the minibuffer.
After spending a while brushing up on my Tibetan, I may or may not
agree, but until I've got some real meaning out of your use of jargon
like "minibuffer", I'll have to pass on this one. Nonetheless, stuff
you can do but can't know you can do without learning Tibetan is
unlikely to be of much help to the average user. :)
> Fortunately, folks brighter than you & I have imagined a nice way for
> us. It pops up a new Emacs window (pane, if you prefer the terminology)
> showing a list of all filenames. You could continue typing, or just
> click on a filename in the window, or hit return while the cursor is on
> a filename in that window.
Back to discussing a graphical port again. Besides the apples and
oranges issue, this amounts to implementing a dodgy imitation of a
file open dialog anyway. Why bother with such an imitation when you
can use a natively-GUI editor written for your platform and get access
to the real thing?
From: Robert Uhl
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3k5tszu6b.fsf@latakia.dyndns.org>
Twisted <··········@gmail.com> writes:
>
>> > Really? None of [navigating a folder window analogue] happens if
>> > you just do the straightforward file-open command, which should
>> > obviously at least provide a navigable directory tree, but
>> > definitely does not.
>>
>> The first does. Really, it does. Fire up emacs (which you've never
>> done before) and type C-x C-f.
>
> Whoa, Nellie. I seem to recall we were discussing the file-open
> command. That was something else, like C-x C-o or something. More
> apples-and- oranges?
Fortunately, emacs has a facility to tell exactly what's bound to a key
sequence. C-h k (or f1 k, if you prefer)followed by that sequence will
display what's bound to it, and the documentation for that function.
C-h k C-x C-o yields:
C-x C-o runs the command delete-blank-lines
C-h k C-x o yields:
C-x o runs the command other-window
C-h k C-x C-f yields:
C-x C-f runs the command find-file
So you can see how cool emacs is, here's the entire output for C-x C-f,
demonstrating how the editor documents itself:
C-x C-f runs the command find-file
which is an interactive compiled Lisp function in `files.el'.
It is bound to <open>, C-x C-f, <menu-bar> <file> <new-file>.
(find-file filename &optional wildcards)
Edit file filename.
Switch to a buffer visiting file filename,
creating one if none already exists.
Interactively, the default if you just type RET is the current directory,
but the visited file name is available through the minibuffer history:
type M-n to pull it into the minibuffer.
Interactively, or if wildcards is non-nil in a call from Lisp,
expand wildcards (if any) and visit multiple files. You can
suppress wildcard expansion by setting `find-file-wildcards' to nil.
To visit a file without any kind of conversion and without
automatically choosing a major mode, use M-x find-file-literally.
>> You will be presented with a prompt
>> something like 'Find file: ~/'; hit tab once; you'll see the message
>> '[Complete, but not unique]'; hit tab again and you will be presented a
>> list of all files in that directory.
>
> Sounds clunky anyway. I don't need a bunch of keypresses to do the
> equivalent in an Explorer-based file-open dialog in a native Windows
> app. Just a double-click.
Generally, you need to scroll, too, as the Windows file widget doesn't
display a lot of files at once.
> Of course, there's an even faster Windows way, if you don't mind not
> seeing lists of possible items:
> Alt, f, o
> Startofname-down-/-Subd-down-/
How is this different from C-x C-f Startofname-tab-Subd-tab? Except
emacs saves you type slashes...
>> If you like 'em, though, just select File:Visit New File. It gives
>> you a platform-default (gtk+, for me) file selector.
>
> Now we're talking about a graphical port instead of stock emacs
> again. :P
That _is_ stock emacs, I assure you.
>> Fortunately, folks brighter than you & I have imagined a nice way for
>> us. It pops up a new Emacs window (pane, if you prefer the
>> terminology) showing a list of all filenames. You could continue
>> typing, or just click on a filename in the window, or hit return
>> while the cursor is on a filename in that window.
>
> Back to discussing a graphical port again.
It's not a port--it's emacs. And save for the click all of the above
works in both a GUI and a console. It's nice working the same way in
multiple places.
> Besides the apples and oranges issue, this amounts to implementing a
> dodgy imitation of a file open dialog anyway. Why bother with such an
> imitation when you can use a natively-GUI editor written for your
> platform and get access to the real thing?
Because it's nice having the same interface no matter what. Because
GUIs come and GUIs go (remember CDE? OpenView?), but emacs will always
be there. Because it's nice being able to fire up emacs and not care
what platform one is running on.
--
Robert Uhl <http://public.xdi.org/=ruhl>
prepBut nI vrbLike adjHungarian! qWhat's artThe adjBig nProblem?
-- Alec Flett
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m34pkuvkx6.fsf@borud.not>
[Twisted <··········@gmail.com>]
|
| Really? None of this happens if you just do the straightforward file-
| open command, which should obviously at least provide a navigable
| directory tree, but definitely does not.
well, if you insist on using Emacs in the most clumsy way possible,
then of course, not it won't be easy. it is very obvious to any Emacs
user that you haven't bothered learning Emacs at all. go away, troll.
-Bj�
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3abumvl23.fsf@borud.not>
[Robert Uhl <·········@NOSPAMgmail.com>]
|
| Once again I am forced to wonder if you have _ever_ actually used
| emacs. find-file has tab completion: hit tab without anything typed, and
| it displays _everything_ in the directory; type a few characters to
| narrow it down; hit tab to complete the filename and be done with
| it.
...and of course, in addition you have access to history so you can
easily find previous parameters and edit them. this makes it very
efficient when you need to fiddle about in deep directory trees in a
way no GUI can yet offer.
...and then there's bookmarking, which is very good for keeping a set
of files (and locations) handy for quick access.
-Bj�
On Jun 26, 10:37 am, Bjorn Borud <··········@borud.no> wrote:
> ...and of course, in addition you have access to history so you can
> easily find previous parameters and edit them. this makes it very
> efficient when you need to fiddle about in deep directory trees in a
> way no GUI can yet offer.
>
> ...and then there's bookmarking, which is very good for keeping a set
> of files (and locations) handy for quick access.
Good thing it has these. Bookmarking is quite natural and is THE way
in GUIs to cope with deep directory structures. Bookmarking in a GUI
is simple: you just open file-browser windows and park them in oft-
visited places, to flip to whenever needed. Multitasking window
systems are neat that way. Current versions of Windoze Explorer have a
history and back and forward navigation buttons reminiscent of a Web
browser, too.
None of them turn into as big a PITA when lots of files have a
lengthy, identical prefix either, which is a fairly common situation.
That only causes difficulty at all when some column or window is sized
too narrowly to show parts of the name past the prefix, forcing
scrolling. Resizing it is then easy, thanks to the GUI, so unless the
prefix is wide enough to cross the entire screen even if you set the
font size down to 3... contrast that with tab completion, where to
disambiguate you'll have to type the entire prefix and then part of
the rest, THEN hit tab. If the prefix is long, you might be saving 3
keystrokes reducing 47 to 44, a gain in productivity of about 7%, a
figure I'm sure you'll agree is somewhat underwhelming. Of course with
a GUI it's spot-the-right-file-and-click, and just as fast whether the
prefix is 4 characters long or 40.
From: Andreas Eder
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <86abuoaqyt.fsf@eder.homelinux.net>
Hi Twisted,
>>>>> "Twisted" == Twisted <··········@gmail.com> writes:
Twisted> That's entirely orthogonal to the issue of interface learning curve OR
Twisted> interface ease-of-use. Emacs has deficiencies in both areas, if
Twisted> principally the former. (For an example of the latter, consider
Twisted> opening a file. Can't remember the exact spelling and capitalization
Twisted> of the file name? Sorry, bud, you're SOL.
Wrong, ever heard about input completion?
Twisted> Go find it in some other app
Twisted> and memorize the name, then return to emacs.
Wrong. Do you know dired?
For even more ease of use use someting like ido, or icicles. It
runs rings about Editors like Notepad.
Twisted> Now THAT is what I call
Twisted> disruptive context switching. Meanwhile even the lowly Notepad
Twisted> responds to "open" by displaying a list of text files and tools to
Twisted> navigate the folder hierarchy without having to do it blind, while
Twisted> still letting you blind-type a path if you remember it. And you can
Twisted> also paste the path in from the clipboard.
You can do so in emacs as well.
Twisted> Unix systems don't even
Twisted> *have* a proper system-wide clipboard and copy/paste capability. Under
Twisted> X there's a weak, text-only imitation, which doesn't help you much
Twisted> when you want to copy a selection from an image in a paint program and
Twisted> paste it into a CAD or web-design or specialized image-manipulation
Twisted> tool or whatever...you have to save it to a file and load it, which is
Twisted> a pain in the butt and slowly clutters your hard drive with
Twisted> "temporary" files you occasionally forget to delete.
You obviously have no clue about working under Unix either.
'Andreas
--
Wherever I lay my .emacs, there's my $HOME.
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3ps3p9x1m.fsf@borud.not>
[Twisted <··········@gmail.com>]
|
| Emacs does have documentation. The problem is you have to already know
| a load of emacs navigation oddities^Wkeyboard commands to get to and
| use it.
that, or just start Emacs and follow the instructions that appear on
the screen.
indeed, I *am* aware that something demanding an attention span in
excess of 3 seconds is a bit of a tall order for most users today.
-Bj�
Matthias Buelow <···@incubus.de> writes:
>
> Here's a nice one from Ken Thompson:
>
> ``I abhor a system designed for the "user", if that word is a coded
> pejorative meaning "stupid and unsophisticated".''
That's a good one. It's going on my wall.
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest:
http://www.gnu.org/philosophy/sylvester-response.html
Matthias Buelow <···@incubus.de> writes:
>
> Here's a nice one from Ken Thompson:
>
> ``I abhor a system designed for the "user", if that word is a coded
> pejorative meaning "stupid and unsophisticated".''
That's a good one. It's going on my wall.
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest:
http://www.gnu.org/philosophy/sylvester-response.html
From: Robert Uhl
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3myyt47nq.fsf@latakia.dyndns.org>
Twisted <··········@gmail.com> writes:
>
>> Emacs is amazingly beginner-friendly for the power and flexibility it
>> provides. [snip]
>
> That's a joke, right? I tried it a time or two. Every time it was
> rapidly apparent that doing anything non-trivial would require
> consulting a cheat sheet. The printed-out kind, since navigating to
> the help and back without already having the help displayed and open
> to the command reference was also non-trivial.
C-h i, C-x b RET is non-trivial?!?
> Four hours of wasted time later, with zero productivity to show for
> it, I deleted it. The same thing happened again, so it wasn't a bad
> day or a fluke or a one-off or the particular version, either.
If you'd spent half an hour using the tutorial (helpfully displayed
right there when you start emacs), you could have saved three and a half
hours of wasted time. And you'd now be using an actual text editor,
which is often helpful.
--
Robert Uhl <http://public.xdi.org/=ruhl>
The cover art on the O'Reilly tome isn't meant to anthropomorphize
sendmail itself after all; it's actually a subliminal warning that
one'd need to be bats to want to use sendmail. --Anthony de Boer
["Followup-To:" header set to comp.emacs.]
> If you'd spent half an hour using the tutorial (helpfully displayed
> right there when you start emacs), you could have saved three and a half
> hours of wasted time. And you'd now be using an actual text editor,
> which is often helpful.
Your statement is obviously based on your assumption everyone has as
good a memory as you. Unfortunately, this is not always the case. I
came to emacs as a geezer with a less than sterling short term memory.
I got about 8 keystrokes into the tutorial before I was lost. I
finally had to start a cheat sheet. It's also a PIA to read a
tutorial and practice in another window until you know how to
open/close/juggle said windows. I never did get much from emacs'
tutorial. It also took me awhile to train my pinkies to reach for
that until-now-unused Ctrl key. No, using emacs is not trivial. It's
a learned skill that requires some effort. More for some than others.
In emacs', defense, it's a helluva lot more intuitive than vi, which
is a nightmare straight from Hell!
nb
On Jun 21, 12:03 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> Twisted <··········@gmail.com> writes:
>
> >> Emacs is amazingly beginner-friendly for the power and flexibility it
> >> provides. [snip]
>
> > That's a joke, right? I tried it a time or two. Every time it was
> > rapidly apparent that doing anything non-trivial would require
> > consulting a cheat sheet. The printed-out kind, since navigating to
> > the help and back without already having the help displayed and open
> > to the command reference was also non-trivial.
>
> C-h i, C-x b RET is non-trivial?!?
Let's change that so that you see it the way most human beings see it:
> > navigating to
> > the help and back without already having the help displayed and open
> > to the command reference was also non-trivial.
> Erh h, dhsd f hHE is non-trivial?
I'm sorry. I don't speak Chinese.
I trust I've made my point. Not only does it insist you learn a whole
other language (though I'm guessing it's not actually Chinese --
Greek, maybe), even when you know that's a bunch of keystrokes and
even what they are...
HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER
THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD TELL
THEM THOSE ARE THE KEYS TO REACH THE HELP?!
I suppose it just pops in there by divine inspiration? Or it's
supposed to be self-evident to anyone who has TRUE wisdom? Or maybe
it's just expected that you be mentored by an expert, who would know
that arcane incantation and could pass it on to a new student. Well
I've got news for you buddy -- there's no such thing as divine
inspiration, it's not self-evident, and most people can't afford (if
they could find) a tutor just to learn how to use A TEXT EDITOR.
Of course, Notepad is so easy to use it doesn't even need help,
despite which it's readily available. In case you forgot the bog-
standard (and therefore it IS self-evident) "F1" there's even a "Help"
menu in plain view as soon as you open a Notepad.
This is the lowly Notepad, which I'll freely admit is the rusty
bicycle of text editors, and it's much easier to use (including the
help) than the supposed Mercedes-Benz of editors.
[remainder snipped, apparently describing some piece of software that
presents you automatically with an emacs tutorial if you start emacs
while it's running. I've seen emacs a few times in my day but never
whatever unnamed piece of software is being referred to here...but it
does occur to me that a context-sensitive auto-popup cheat sheet tool
would be useful on the typical unix system!]
From: Cor Gest
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <87bqf7fwmg.fsf@telesippa.clsnet.nl>
Some entity, AKA Twisted <··········@gmail.com>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> On Jun 21, 12:03 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> > Twisted <··········@gmail.com> writes:
> >
> > >> Emacs is amazingly beginner-friendly for the power and flexibility it
> > >> provides. [snip]
> >
> > > That's a joke, right? I tried it a time or two. Every time it was
> > > rapidly apparent that doing anything non-trivial would require
> > > consulting a cheat sheet. The printed-out kind, since navigating to
> > > the help and back without already having the help displayed and open
> > > to the command reference was also non-trivial.
> >
> > C-h i, C-x b RET is non-trivial?!?
>
> Let's change that so that you see it the way most human beings see it:
>
> > > navigating to
> > > the help and back without already having the help displayed and open
> > > to the command reference was also non-trivial.
>
> > Erh h, dhsd f hHE is non-trivial?
>
> I'm sorry. I don't speak Chinese.
>
> I trust I've made my point. Not only does it insist you learn a whole
> other language (though I'm guessing it's not actually Chinese --
> Greek, maybe), even when you know that's a bunch of keystrokes and
> even what they are...
>
> HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER
> THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD TELL
> THEM THOSE ARE THE KEYS TO REACH THE HELP?!
What's your problem ?
Ofcourse a mere program-consumer would not look what was being
installed on his/her system in the first place ...
So after some trivial perusing what was installed and where :
WOW Look, MA ! .... it's all there!
lpr /usr/local/share/emacs/21.3/etc/refcard.ps
or your install-dir........^ ^
or your version.............................^
But then again buying the GNU-book from 'O Reilly would have solved it
in the utmost nicest possible of ways anyway.
Buying or printing the GNU-Emacs Reference Manual should do
quit a memorable job also.
But then again there allways will be people that cannot find their way to
the outhouse even when it stinks a mile a minute.
Cor
--
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
The biggest problem LISP has, is that it does not appeal to dumb people
If that fails to satisfy read the HyperSpec, woman frig or Tuxoharata
mailpolicy @ http://www.clsnet.nl/mail.php
On Jun 22, 6:32 pm, Cor Gest <····@clsnet.nl> wrote:
> > HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER
> > THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD TELL
> > THEM THOSE ARE THE KEYS TO REACH THE HELP?!
>
> What's your problem ?
>
> Ofcourse a mere program-consumer would not look what was being
> installed on his/her system in the first place ...
> So after some trivial perusing what was installed and where :
> WOW Look, MA ! .... it's all there!
>
> lpr /usr/local/share/emacs/21.3/etc/refcard.ps
> or your install-dir........^ ^
> or your version.............................^
So now we're expected to go on a filesystem fishing expedition instead
of just hit F1? One small step (backwards) for a man; one giant leap
(backwards) for mankind. :P
> But then again buying the GNU-book from 'O Reilly would have solved it
> in the utmost nicest possible of ways anyway.
So much for the "free" in "free software". If you can't actually use
it without paying money, whether for the software or for some book, it
isn't really free, is it? The book assumes the role of a copy
protection dongle*. Of course, if the book is under the usual sort of
copyright and not copyleft, so much for the "free as in speech" too,
and nevermind the "free as in beer".
* In fact, I not-too-fondly remember the days when a common copy
protection scheme was for software to periodically (or at least on
startup) insist that the user enter the first word on page N of the
manual, for various changing choices of N. Making the interface simply
unnavigable without the manual strikes me as nearly as effective. If
someone did decide to intentionally cripple the interface of some
"free" software and make a killing off a book de-facto required to use
it, it would be quite the racket. I hope the open source movement
would chew them to pieces and curse them in public though.
From: Cor Gest
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <877ipvfswe.fsf@telesippa.clsnet.nl>
Some entity, AKA ··········@gmail.com,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> On Jun 22, 6:32 pm, Cor Gest <····@clsnet.nl> wrote:
> > > HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER
> > > THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD TELL
> > > THEM THOSE ARE THE KEYS TO REACH THE HELP?!
> >
> > What's your problem ?
> >
> > Ofcourse a mere program-consumer would not look what was being
> > installed on his/her system in the first place ...
> > So after some trivial perusing what was installed and where :
> > WOW Look, MA ! .... it's all there!
> >
> > lpr /usr/local/share/emacs/21.3/etc/refcard.ps
> > or your install-dir........^ ^
> > or your version.............................^
>
> So now we're expected to go on a filesystem fishing expedition instead
> of just hit F1? One small step (backwards) for a man; one giant leap
> (backwards) for mankind. :P
that's M-` Escape-Backtick in a CLI, for you, thank you very much ...
Function-Keys do not work in in a vt100 terminal.
You really are that shallow, aren't you ? and lazy too, huh ?
> copyright and not copyleft, so much for the "free as in speech" too,
> and nevermind the "free as in beer".
Download & print the junk then.
Ofcourse you pay your ISP for the priviledge & give some treehuggers a
nervous brakedown in the process.
Cor
--
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
The biggest problem LISP has, is that it does not appeal to dumb people
If that fails to satisfy read the HyperSpec, woman frig or Tuxoharata
mailpolicy @ http://www.clsnet.nl/mail.php
Cor Gest <···@clsnet.nl> wrote:
>Some entity, AKA ··········@gmail.com,
>wrote this mindboggling stuff:
>
>> On Jun 22, 6:32 pm, Cor Gest <····@clsnet.nl> wrote:
>>
>> So now we're expected to go on a filesystem fishing expedition instead
>> of just hit F1? One small step (backwards) for a man; one giant leap
>> (backwards) for mankind. :P
>
>that's M-` Escape-Backtick in a CLI, for you, thank you very much ...
>Function-Keys do not work in in a vt100 terminal.
>
>You really are that shallow, aren't you ? and lazy too, huh ?
Boys, do you really not understand that this is a religious issue? You
can't use arguments and logic to convince someone to convert their
religion, and you can't use arguments and logic to convince someone to
change editors.
Editors are like underwear. We each have our own favorite brand, and
nothing you say will convince me to change mine. Editor, that is. I do
occasionally change my underwear.
--
Tim Roberts, ····@probo.com
Providenza & Boekelheide, Inc.
From: Cor Gest
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <87bqf6c1nq.fsf@telesippa.clsnet.nl>
Some entity, AKA Tim Roberts <····@probo.com>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> Boys, do you really not understand that this is a religious issue? You
> can't use arguments and logic to convince someone to convert their
> religion, and you can't use arguments and logic to convince someone to
> change editors.
Nah, nothing beats a nice flame-war on a slow fridaynight & a Pint
of Bitter, while it spares the fingers to keep on manipulating all those nice
keyboard-modifiers to nag the ignorati for an other day ... ;-)
Cor
--
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
The biggest problem LISP has, is that it does not appeal to dumb people
If that fails to satisfy read the HyperSpec, woman frig or Tuxoharata
mailpolicy @ http://www.clsnet.nl/mail.php
From: Matthias Buelow
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <5e50ltF356nbjU1@mid.dfncis.de>
Tim Roberts wrote:
> Editors are like underwear. We each have our own favorite brand, and
> nothing you say will convince me to change mine.
You really should have stopped here.... :)
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <851wg2h9hg.fsf@lola.goethe.zz>
Matthias Buelow <···@incubus.de> writes:
> Tim Roberts wrote:
>
>> Editors are like underwear. We each have our own favorite brand, and
>> nothing you say will convince me to change mine.
>
> You really should have stopped here.... :)
Well if "It stinks!" is not incentive enough for him to change his
underwear, what will?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Robert Uhl
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3ps3m18i3.fsf@latakia.dyndns.org>
··········@gmail.com writes:
>
> So now we're expected to go on a filesystem fishing expedition instead
> of just hit F1?
Interestingly enough, f1 _is_ bound to the help system in emacs. So's
C-h. So's the 'help' key.
--
Robert Uhl <http://public.xdi.org/=ruhl>
That's why I love VoIP. You don't get people phoning up to complain that the
network is down. --Peter Corlett
From: Giorgos Keramidas
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <873b0fhokz.fsf@kobe.laptop>
On Fri, 22 Jun 2007 23:08:02 -0000, ··········@gmail.com wrote:
>> lpr /usr/local/share/emacs/21.3/etc/refcard.ps
>> or your install-dir........^ ^
>> or your version.............................^
>
> So now we're expected to go on a filesystem fishing expedition instead
> of just hit F1? One small step (backwards) for a man; one giant leap
> (backwards) for mankind. :P
>
>> But then again buying the GNU-book from 'O Reilly would have solved it
>> in the utmost nicest possible of ways anyway.
>
> So much for the "free" in "free software". If you can't actually use
> it without paying money, whether for the software or for some book, it
> isn't really free, is it?
Please do not confuse the term 'free' in 'free software' with 'gratis'.
'Gratis', i.e. 'lacking a monetary price tag' is something *very*
different from the meaning of 'free' in 'free software'.
On Jun 25, 2:32 pm, Giorgos Keramidas <········@ceid.upatras.gr>
wrote:
> > So much for the "free" in "free software". If you can't actually use
> > it without paying money, whether for the software or for some book, it
> > isn't really free, is it?
>
> Please do not confuse the term 'free' in 'free software' with 'gratis'.
>
> 'Gratis', i.e. 'lacking a monetary price tag' is something *very*
> different from the meaning of 'free' in 'free software'.
Having to pay for the documentation, presumably because it's
copyrighted, doesn't strike me as much more "free as in speech" than
it is "free as in beer". Also being dependent on a particular
publisher for access to required documentation violates "free as in no
vendor lock-in", to boot. So anyone saying some "free" software is
unusable without such-and-such an O'Reilly book can go peddle the
software and the book somewhere where spammers are welcome. Being
locked in to O'Reilly being just as bad as being locked in to
Microsoft or Adobe.
From: Giorgos Keramidas
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <87lke7w1hf.fsf@kobe.laptop>
On Tue, 26 Jun 2007 07:40:55 -0000, Twisted <··········@gmail.com> wrote:
>On Jun 25, 2:32 pm, Giorgos Keramidas <········@ceid.upatras.gr>
>wrote:
>>> So much for the "free" in "free software". If you can't actually use
>>> it without paying money, whether for the software or for some book,
>>> it isn't really free, is it?
>>
>> Please do not confuse the term 'free' in 'free software' with 'gratis'.
>>
>> 'Gratis', i.e. 'lacking a monetary price tag' is something *very*
>> different from the meaning of 'free' in 'free software'.
>
> Having to pay for the documentation, presumably because it's
> copyrighted, doesn't strike me as much more "free as in speech" than
> it is "free as in beer".
You don't have to "pay for the documentation because it is copyrighted".
You can _download_ the Emacs manual in any format you are more
comfortable with.
See for example:
http://www.gnu.org/manual/manual.html
This page lists downloadable documentation in nicely formatted HTML or
PDF formats, which is available without any sort of monetary charge.
> Also being dependent on a particular publisher for access to required
> documentation violates "free as in no vendor lock-in", to boot. So
> anyone saying some "free" software is unusable without such-and-such
> an O'Reilly book can go peddle the software and the book somewhere
> where spammers are welcome. Being locked in to O'Reilly being just as
> bad as being locked in to Microsoft or Adobe.
Since you are not obliged to _pay_ for the O'Reilly version, this entire
paragraph is both meaningless and moot. Feel free to grab an online
copy of the manual, or install the documentation of Emacs using your
favorite distribution's packaging tools. There is absolutely no
"lock-in" anywhere near Emacs.
- Giorgos
From: Damien Kick
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <13frd6vtarbee75@corp.supernews.com>
Giorgos Keramidas wrote:
> On Fri, 22 Jun 2007 23:08:02 -0000, ··········@gmail.com wrote:
>> So much for the "free" in "free software". If you can't actually use
>> it without paying money, whether for the software or for some book, it
>> isn't really free, is it?
>
> Please do not confuse the term 'free' in 'free software' with 'gratis'.
>
> 'Gratis', i.e. 'lacking a monetary price tag' is something *very*
> different from the meaning of 'free' in 'free software'.
If you were referring to the "free" in "free Mumia Abu Jamal", I would
agree with you. I don't think anyone would imagine that this phrase
meant that someone was going to get Mumia Abu Jamal gratis. Like it or
not, "free software" referring to "free as in beer" is probably the most
common interpretation of the phrase for a native English speaker.
Admittedly, I do not have a "scientific" survey handy. However, I just
asked my wife--who has absolutely no interest in anything related to
programming, has never heard of the FSF, Eric Raymond, nor the
disagreement between those two camps, nor probably will she ever have an
interest--what she thinks I mean when I say "free software". After
getting over the "why are you asking such a stupid question" phase, the
first thing that jumped to her mind was "free as in beer". You can
stamp, growl, swagger, spit, curse, and bluster all you want on this
point, but millions of English speakers are going to ignore you anyway.
Lucky for most of them, they do not have to suffer the lectures of
sociopolitically motivated language mavens trying to "correct" them from
the error of mistaking the meaning of a phrase to be the normal meaning
of that phrase.
From: Ken Tilton
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <pmnLi.1684$hP.1048@newsfe12.lga>
Damien Kick wrote:
> Giorgos Keramidas wrote:
>
>> On Fri, 22 Jun 2007 23:08:02 -0000, ··········@gmail.com wrote:
>>
>>> So much for the "free" in "free software". If you can't actually use
>>> it without paying money, whether for the software or for some book, it
>>> isn't really free, is it?
>>
>>
>> Please do not confuse the term 'free' in 'free software' with 'gratis'.
>>
>> 'Gratis', i.e. 'lacking a monetary price tag' is something *very*
>> different from the meaning of 'free' in 'free software'.
Sure, but where does the infection thing come in? Suppose RMS publishes
a new library call add-42, whose api is add-42, inputs n, outputs n+42,
source left as an exercise, and Kenny decides he can use it, it is
great. Now if Kenny uses it in his commercial software, add-42 does not
somehow become less free to ride 'neath the starry skies above, don't
fence me in. But RMS wants Kenny's hide. Nothing Kenny wrote derived
from add-42, but RMS wants it all. Kenny happened to solve the traveling
salesman problem and protein-folding and passed the fricking Turing test
by using add-42 wherever he needed 42 added to a number, and RMS wants
credit and ownership and control of it all. He and his license shall
now dictate access and use of all that code. The handcuffs are on, and
they are inscribed "free".
No wonder the GPL has gone nowhere. Freely. RMS reasonably wanted that
add-42 not get co-opted, but that in no way necessitated the land grab
that is GPL. The GPL is a gratuitous reach only fancifully justified by
wanting to ensure that open source remain open. So this has nothing to
do with freedom in /any/ sense of the word, it has to do with a
political agenda opposed to the idea of private property.
kzo
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
Ken Tilton wrote:
> No wonder the GPL has gone nowhere.
Bwaahahahaha. Keep smokin' that crack, there.
> Freely. RMS reasonably wanted that
> add-42 not get co-opted, but that in no way necessitated the land grab
> that is GPL.
You (and probably KMP) are presuming the validity of copyright monopoly
law think. Others do not do that. Whenever you claim a copyright
monopoly, and enforce that monopoly, you're abridging others freedom.
It might currently be legal to do so, but "legal" and "right" are
different things.
So your beef is not _really_ with the GPL - it derives all its power
from copyright law. The GPL is really only valid while copyright law
is: If copyright law is reduced in power and reach, the GPL is too. So
if you don't like the GPL, push for weakened copyright law. Heh.
Supporters of copyright monopoly law *really* don't like this
double-bind of the GPL, of course, but that's by design.
Of course, the FSF are a bunch of moderates, these days you can support
your local Pirate Party, more information at
http://www.pp-international.net/
From: Klaus Schilling
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <87lkao8xgk.fsf@web.de>
Ken Tilton <···········@optonline.net> writes:
>
> Sure, but where does the infection thing come in? Suppose RMS
> publishes a new library call add-42, whose api is add-42, inputs n,
> outputs n+42, source left as an exercise, and Kenny decides he can use
> it, it is great. Now if Kenny uses it in his commercial software,
commercial software can be free as well, such as the GNU Ada compiler.
> add-42 does not somehow become less free to ride 'neath the starry
> skies above, don't fence me in. But RMS wants Kenny's hide. Nothing
> Kenny wrote derived from add-42, but RMS wants it all.
that's because it's immoral not to give it all
> Kenny happened
> to solve the traveling salesman problem and protein-folding and passed
> the fricking Turing test by using add-42 wherever he needed 42 added
> to a number, and RMS wants credit and ownership and control of it
> all. He and his license shall now dictate access and use of all that
> code. The handcuffs are on, and they are inscribed "free".
of course they are free
>
> No wonder the GPL has gone nowhere. Freely. RMS reasonably wanted that
> add-42 not get co-opted, but that in no way necessitated the land grab
> that is GPL. The GPL is a gratuitous reach only fancifully justified
> by wanting to ensure that open source remain open.
which is necessary in a moral culture.
Only an immoral culture may accept non-disclosure
> So this has nothing
> to do with freedom in /any/ sense of the word, it has to do with a
> political agenda opposed to the idea of private property.
>
private property is unethical
Klaus Schilling
On Sun, 30 Sep 2007 08:43:39 +0200, Klaus Schilling <···············@web.de>
tried to confuse everyone with this message:
>
>that's because it's immoral not to give it all
>
>which is necessary in a moral culture.
>Only an immoral culture may accept non-disclosure
>
>private property is unethical
>
I see the light! You really won me over with your preaching.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
From: Kamen TOMOV
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <uk5q5dey6.fsf@cybuild.com>
On Sun, Sep 30 2007, Klaus Schilling wrote:
> ...
> private property is unethical
How I craved to read that!
Viva la revolution!
��� ������� - ��� �������,
��� ������� - ��� �������!
The End justify the means!
Long live communism!
--
�����
> So this has nothing to
> do with freedom in /any/ sense of the word, it has to do with a
> political agenda opposed to the idea of private property.
Freedom is inherently political, you know. You're condemning the FSF
for being political, although the FSF's stated purpose is a political
one. How does that make any sense?
~ Matthias
From: Ken Tilton
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <t5XLi.109$kd4.32@newsfe12.lga>
Matthias Benkard wrote:
>>So this has nothing to
>>do with freedom in /any/ sense of the word, it has to do with a
>>political agenda opposed to the idea of private property.
>
>
> Freedom is inherently political, you know. You're condemning the FSF
> for being political, although the FSF's stated purpose is a political
> one.
Oh, I missed that. I just saw something about software should be shared
and programmers should be content with an hourly wage, not sales.
kt
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
From: Klaus Schilling
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <87zlz38fql.fsf@web.de>
Ken Tilton <···········@optonline.net> writes:
>
> Oh, I missed that. I just saw something about software should be
> shared
of course it should, as otherwise it would be immoral,
> and programmers should be content with an hourly wage, not
> sales.
>
only greedy creeps wouldn't be content
Klaus Schilling
From: Bruno Desthuilliers
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <47015723$0$9500$426a74cc@news.free.fr>
Ken Tilton a �crit :
>
>
> Matthias Benkard wrote:
>
>>> So this has nothing to
>>> do with freedom in /any/ sense of the word, it has to do with a
>>> political agenda opposed to the idea of private property.
>>
>> Freedom is inherently political, you know. You're condemning the FSF
>> for being political, although the FSF's stated purpose is a political
>> one.
>
> Oh, I missed that. I just saw something about software should be shared
> and programmers should be content with an hourly wage, not sales.
>
Nothing forces you to use GPL code, isn't it ? If that code was under a
proprietary licence, you would not use it without paying the price,
because then you'd be *stealing* code ? And since you have a deep
respect for intellectual property, copyright laws etc, you would not, by
any mean, *steal* code by not respecting the licence terms ? Do we agree
on this ? Yes ? Fine. Then how dare you complain about the fact that the
GPL don't let you steal code ? Don't you feel something like a
contradiction here ? Too bad that you can't have your cake and eat it too...
Ken Tilton wrote:
> Kenny happened to solve the traveling
> salesman problem and protein-folding and passed the fricking Turing test
> by using add-42 wherever he needed 42 added to a number, and RMS wants
> credit and ownership and control of it all.
That might be what RMS wants (or not, I've never asked him), but it
doesn't follow from the licence. What follows from the licence is that
you have to distribute the derived work as GPL _or not at all_. I
practice - if not in marketing terms - that's no more a land grab than a
proprietary licence saying "you can't use this to add your own numbers
to 42 at all and if you do we'll eat your brains".
The other consideration is that, and notwitshtanding any text to the
contrary in the GPL, it's not actually up to the copyright holder to
define what "derived work" means: it's for the court to decide that.
Now, I don't want to imply that courts are rational animals that can be
relied on to understand all the issues in technical cases like this (ha,
I slay myself) but really, if there's a reasonable concern that an
implementation of the major advances in computer science you describe
are legally derivative of someone's function that adds 42 to its
argument, your legal system is fucked. Redo from start.
-dan
On Tue, 02 Oct 2007 01:16:25 +0100, ···@telent.net wrote:
>Ken Tilton wrote:
>> Kenny happened to solve the traveling
>> salesman problem and protein-folding and passed the fricking Turing test
>> by using add-42 wherever he needed 42 added to a number, and RMS wants
>> credit and ownership and control of it all.
>
>That might be what RMS wants (or not, I've never asked him), but it
>doesn't follow from the licence. What follows from the licence is that
>you have to distribute the derived work as GPL _or not at all_. I
>practice - if not in marketing terms - that's no more a land grab than a
>proprietary licence saying "you can't use this to add your own numbers
>to 42 at all and if you do we'll eat your brains".
>
>The other consideration is that, and notwitshtanding any text to the
>contrary in the GPL, it's not actually up to the copyright holder to
>define what "derived work" means: it's for the court to decide that.
>Now, I don't want to imply that courts are rational animals that can be
>relied on to understand all the issues in technical cases like this (ha,
>I slay myself) but really, if there's a reasonable concern that an
>implementation of the major advances in computer science you describe
>are legally derivative of someone's function that adds 42 to its
>argument, your legal system is fucked. Redo from start.
Our [US] legal system is fucked ... more so with respect to patents,
but copyrights aren't far behind. The US Congress just revisited
patent law to make it less of a land grab - we'll have to wait and see
how the USPTO interprets the new rules - but copyright law has been
trending the other way (more grabbing) for a couple of decades now.
George
--
for email reply remove "/" from address
From: Frank Goenninger
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <fdlat6$c5f$03$1@news.t-online.com>
On 2007-09-29 01:27:04 +0200, Damien Kick <·····@earthlink.net> said:
> Giorgos Keramidas wrote:
>> On Fri, 22 Jun 2007 23:08:02 -0000, ··········@gmail.com wrote:
>>> So much for the "free" in "free software". If you can't actually use
>>> it without paying money, whether for the software or for some book, it
>>> isn't really free, is it?
>>
>> Please do not confuse the term 'free' in 'free software' with 'gratis'.
>>
>> 'Gratis', i.e. 'lacking a monetary price tag' is something *very*
>> different from the meaning of 'free' in 'free software'.
>
> If you were referring to the "free" in "free Mumia Abu Jamal", I would
> agree with you. I don't think anyone would imagine that this phrase
> meant that someone was going to get Mumia Abu Jamal gratis. Like it or
> not, "free software" referring to "free as in beer" is probably the
> most common interpretation of the phrase for a native English speaker.
> Admittedly, I do not have a "scientific" survey handy. However, I just
> asked my wife--who has absolutely no interest in anything related to
> programming, has never heard of the FSF, Eric Raymond, nor the
> disagreement between those two camps, nor probably will she ever have
> an interest--what she thinks I mean when I say "free software". After
> getting over the "why are you asking such a stupid question" phase, the
> first thing that jumped to her mind was "free as in beer". You can
> stamp, growl, swagger, spit, curse, and bluster all you want on this
> point, but millions of English speakers are going to ignore you anyway.
> Lucky for most of them, they do not have to suffer the lectures of
> sociopolitically motivated language mavens trying to "correct" them
> from the error of mistaking the meaning of a phrase to be the normal
> meaning of that phrase.
Fully true for non-native English speakers as well. Just did the "wife
test" also - she is a pure software user - and yes, free is "no money,
do what you want" and that's it.
I *never* use the term "free" if I don't want to imply "free beer"
(which is a Good Thing and as such highly valuated - ask any Bavarian).
Using "free" as by FSF or any other lawyer-style 6 pixel font printed
phrasing is pure perfidiousness.
Frank
--
Frank Goenninger
frgo(at)goenninger(dot)net
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
Frank Goenninger wrote:
> On 2007-09-29 01:27:04 +0200, Damien Kick <·····@earthlink.net> said:
>
>> If you were referring to the "free" in "free Mumia Abu Jamal", I would
>> agree with you. I don't think anyone would imagine that this phrase
>> meant that someone was going to get Mumia Abu Jamal gratis. Like it
>> or not, "free software" referring to "free as in beer" is probably the
>> most common interpretation of the phrase for a native English speaker.
>> Admittedly, I do not have a "scientific" survey handy. However, I
>> just asked my wife--who has absolutely no interest in anything related
>> to programming, has never heard of the FSF, Eric Raymond, nor the
>> disagreement between those two camps, nor probably will she ever have
>> an interest--what she thinks I mean when I say "free software". After
>> getting over the "why are you asking such a stupid question" phase,
>> the first thing that jumped to her mind was "free as in beer". You
>> can stamp, growl, swagger, spit, curse, and bluster all you want on
>> this point, but millions of English speakers are going to ignore you
>> anyway. Lucky for most of them, they do not have to suffer the
>> lectures of sociopolitically motivated language mavens trying to
>> "correct" them from the error of mistaking the meaning of a phrase to
>> be the normal meaning of that phrase.
>
> Fully true for non-native English speakers as well. Just did the "wife
> test" also - she is a pure software user - and yes, free is "no money,
> do what you want" and that's it.
>
> I *never* use the term "free" if I don't want to imply "free beer"
> (which is a Good Thing and as such highly valuated - ask any Bavarian).
> Using "free" as by FSF or any other lawyer-style 6 pixel font printed
> phrasing is pure perfidiousness.
>
I appearantly missed a lot of that conversation, but what is your point?
While I agree that the word "free" implies "free of monetary cost" to
many people societies, that is by no means set in stone (talk to native
americans, blacks, jews, palestinians, etc. about the word free, see
what they have to say).
But that aside: The word free with respect to the FSF and GPL have a
perfectly well defined meaning. People may misunderstand that from not
knowing the definition but that doesnt make it any less well defined.
Again, why this discussion?
/W
From: Frank Goenninger
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <fdtsfu$iq6$03$1@news.t-online.com>
On 2007-10-01 23:37:28 +0200, Wildemar Wildenburger
<···········@klapptsowieso.net> said:
> Frank Goenninger wrote:
>> On 2007-09-29 01:27:04 +0200, Damien Kick <·····@earthlink.net> said:
>>
>>> If you were referring to the "free" in "free Mumia Abu Jamal", I would
>>> agree with you. I don't think anyone would imagine that this phrase
>>> meant that someone was going to get Mumia Abu Jamal gratis. Like it or
>>> not, "free software" referring to "free as in beer" is probably the
>>> most common interpretation of the phrase for a native English speaker.
>>> Admittedly, I do not have a "scientific" survey handy. However, I just
>>> asked my wife--who has absolutely no interest in anything related to
>>> programming, has never heard of the FSF, Eric Raymond, nor the
>>> disagreement between those two camps, nor probably will she ever have
>>> an interest--what she thinks I mean when I say "free software". After
>>> getting over the "why are you asking such a stupid question" phase, the
>>> first thing that jumped to her mind was "free as in beer". You can
>>> stamp, growl, swagger, spit, curse, and bluster all you want on this
>>> point, but millions of English speakers are going to ignore you anyway.
>>> Lucky for most of them, they do not have to suffer the lectures of
>>> sociopolitically motivated language mavens trying to "correct" them
>>> from the error of mistaking the meaning of a phrase to be the normal
>>> meaning of that phrase.
>>
>> Fully true for non-native English speakers as well. Just did the "wife
>> test" also - she is a pure software user - and yes, free is "no money,
>> do what you want" and that's it.
>>
>> I *never* use the term "free" if I don't want to imply "free beer"
>> (which is a Good Thing and as such highly valuated - ask any Bavarian).
>> Using "free" as by FSF or any other lawyer-style 6 pixel font printed
>> phrasing is pure perfidiousness.
>>
> I appearantly missed a lot of that conversation, but what is your
> point? While I agree that the word "free" implies "free of monetary
> cost" to many people societies, that is by no means set in stone (talk
> to native americans, blacks, jews, palestinians, etc. about the word
> free, see what they have to say).
>
> But that aside: The word free with respect to the FSF and GPL have a
> perfectly well defined meaning. People may misunderstand that from not
> knowing the definition but that doesnt make it any less well defined.
>
> Again, why this discussion?
> /W
Well, I didn't start the discussion. So you should ask the OP about the
why. I jumped in when I came across the so often mentioned "hey, it's
all well defined" statement was brought in. I simply said that if that
"well-definedness" is against "common understanding" then I don't give
a damn about that clever definitions. Because I have to know that there
are such definitions - always also knowing that free is not really
free. It is such a good subject to discuss over and over and over
without ever reaching any conclusion or resolution because neither FSF
nor GNU nor the FREE as in FREE BEER defenders will change their mind.
So, wasting bandwith is the only real effect ... And hey, it's Usenet,
so wasting time and bandwith is part of the game.
Again, why this discussion - ah - I don't really know...
;-)
--
Frank Goenninger
frgo(at)goenninger(dot)net
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
From: Bent C Dalager
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <fdvn34$odf$1@orkan.itea.ntnu.no>
In article <···············@news.t-online.com>,
Frank Goenninger <····@goenninger.net> wrote:
>
>Well, I didn't start the discussion. So you should ask the OP about the
>why. I jumped in when I came across the so often mentioned "hey, it's
>all well defined" statement was brought in. I simply said that if that
>"well-definedness" is against "common understanding" then I don't give
>a damn about that clever definitions. Because I have to know that there
>are such definitions - always also knowing that free is not really
>free.
"Liberated" is a valid meaning of the word "free". The main problem is
that there aren't really any other words in the English language that
have the same meaning as the word "free" when it is wearing its
"liberated" hat. It is unfortunate that the word is overloaded with
multiple other meanings, one of which is so central in our modern
market oriented society that it tends to come to the forefront of
people's minds when the word is used. But that's just the way it is.
You work with the language you've got.
> It is such a good subject to discuss over and over and over
>without ever reaching any conclusion or resolution because neither FSF
>nor GNU nor the FREE as in FREE BEER defenders will change their mind.
I am quite sure they would be overjoyed if someone were to come up
with a decent replacement for the word "free" so as to disambiguate
the term. A number of people have tried pretty hard, however, and
failed. If you fancy yourself an accomplished wordsmith, any
suggestions are sure to be welcome.
Cheers
Bent D
--
Bent Dalager - ···@pvv.org - http://www.pvv.org/~bcd
powered by emacs
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <85ve9ov971.fsf@lola.goethe.zz>
···@pvv.ntnu.no (Bent C Dalager) writes:
> In article <···············@news.t-online.com>,
> Frank Goenninger <····@goenninger.net> wrote:
>>
>>Well, I didn't start the discussion. So you should ask the OP about the
>>why. I jumped in when I came across the so often mentioned "hey, it's
>>all well defined" statement was brought in. I simply said that if that
>>"well-definedness" is against "common understanding" then I don't give
>>a damn about that clever definitions. Because I have to know that there
>>are such definitions - always also knowing that free is not really
>>free.
>
> "Liberated" is a valid meaning of the word "free".
No. It is a valid meaning of the word "freed".
Xpost+Fup2 gnu.misc.discuss: this is not really relevant for most of
the touched Usenet groups.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Bent C Dalager
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <fdvnr8$odf$2@orkan.itea.ntnu.no>
In article <··············@lola.goethe.zz>, David Kastrup <···@gnu.org> wrote:
>···@pvv.ntnu.no (Bent C Dalager) writes:
>
>> In article <···············@news.t-online.com>,
>> Frank Goenninger <····@goenninger.net> wrote:
>>>
>>>Well, I didn't start the discussion. So you should ask the OP about the
>>>why. I jumped in when I came across the so often mentioned "hey, it's
>>>all well defined" statement was brought in. I simply said that if that
>>>"well-definedness" is against "common understanding" then I don't give
>>>a damn about that clever definitions. Because I have to know that there
>>>are such definitions - always also knowing that free is not really
>>>free.
>>
>> "Liberated" is a valid meaning of the word "free".
>
>No. It is a valid meaning of the word "freed".
Only if you're being exceedingly pedantic and probably not even
then. Webster 1913 lists, among other meanings,
Free
(...)
"Liberated, by arriving at a certain age, from the control
of parents, guardian, or master."
The point presumably being that having been "liberated", you are now
"free".
As I do not read gnu.misc.discuss, I reinstated the previous bunch.
Apologies to those who may be annoyed at this.
Cheers
Bent D
--
Bent Dalager - ···@pvv.org - http://www.pvv.org/~bcd
powered by emacs
On Wed, 3 Oct 2007 09:36:40 +0000 (UTC), ···@pvv.ntnu.no (Bent C
Dalager) wrote:
>In article <··············@lola.goethe.zz>, David Kastrup <···@gnu.org> wrote:
>>···@pvv.ntnu.no (Bent C Dalager) writes:
>>
>>> In article <···············@news.t-online.com>,
>>> Frank Goenninger <····@goenninger.net> wrote:
>>>>
>>>>Well, I didn't start the discussion. So you should ask the OP about the
>>>>why. I jumped in when I came across the so often mentioned "hey, it's
>>>>all well defined" statement was brought in. I simply said that if that
>>>>"well-definedness" is against "common understanding" then I don't give
>>>>a damn about that clever definitions. Because I have to know that there
>>>>are such definitions - always also knowing that free is not really
>>>>free.
>>>
>>> "Liberated" is a valid meaning of the word "free".
>>
>>No. It is a valid meaning of the word "freed".
>
>Only if you're being exceedingly pedantic and probably not even
>then. Webster 1913 lists, among other meanings,
>
>Free
>(...)
>"Liberated, by arriving at a certain age, from the control
>of parents, guardian, or master."
>
>The point presumably being that having been "liberated", you are now
>"free".
I don't think knowing the meaning of a word is being pedantic.
"Freed" is derived from "free" but has a different, though associated,
meaning. Words have meaning despite the many attempts by Generation X
to assert otherwise. Symbolism over substance has become the mantra
of the young.
The English language has degenerated significantly in the last 30
years. People (marketers in particular) routinely coin ridiculous new
words and hope they will catch on. I remember seeing a documentary
(circa 1990?) about changes in the English language. One part of the
program was about the BBC news and one of its editors, whom the staff
called the "protector of language", who checked the pronunciation of
words by the news anchors. The thing that struck me about this story
was the number of BBC newspeople who publicly admitted that they could
hardly wait for this man to retire so they could write and speak the
way they wanted rather than having to be "correct".
Dictionaries used to be the arbiters of the language - any word or
meaning of a word not found in the dictionary was considered a
colloquial (slang) use. Since the 1980's, an entry in the dictionary
has become little more than evidence of popularity as the major
dictionaries (OED, Webster, Cambridge, etc.) will now consider any
word they can find used in print.
George
--
for email reply remove "/" from address
From: Bent C Dalager
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <fe0mhm$c08$1@orkan.itea.ntnu.no>
In article <··································@4ax.com>,
George Neuner <·········@comcast.net> wrote:
>On Wed, 3 Oct 2007 09:36:40 +0000 (UTC), ···@pvv.ntnu.no (Bent C
>Dalager) wrote:
>
>>
>>Only if you're being exceedingly pedantic and probably not even
>>then. Webster 1913 lists, among other meanings,
>>
>>Free
>>(...)
>>"Liberated, by arriving at a certain age, from the control
>>of parents, guardian, or master."
>>
>>The point presumably being that having been "liberated", you are now
>>"free".
>
> (...)
>
>The English language has degenerated significantly in the last 30
>years.
> (...)
>
>Dictionaries used to be the arbiters of the language - any word or
>meaning of a word not found in the dictionary was considered a
>colloquial (slang) use. Since the 1980's, an entry in the dictionary
>has become little more than evidence of popularity as the major
>dictionaries (OED, Webster, Cambridge, etc.) will now consider any
>word they can find used in print.
Apparantly, you missed the part where I referred to the 1913 edition
of Webster. I have kept it in the quoted text above for your
convenience. I can assure you that 1913 is both more than 30 years ago
/and/ it is before 1980, in case that was in doubt.
Cheers
Bent D
--
Bent Dalager - ···@pvv.org - http://www.pvv.org/~bcd
powered by emacs
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <85sl4sqckf.fsf@lola.goethe.zz>
···@pvv.ntnu.no (Bent C Dalager) writes:
> In article <··································@4ax.com>,
> George Neuner <·········@comcast.net> wrote:
>>On Wed, 3 Oct 2007 09:36:40 +0000 (UTC), ···@pvv.ntnu.no (Bent C
>>Dalager) wrote:
>>
>>>
>>>Only if you're being exceedingly pedantic and probably not even
>>>then. Webster 1913 lists, among other meanings,
>>>
>>>Free
>>>(...)
>>>"Liberated, by arriving at a certain age, from the control
>>>of parents, guardian, or master."
>>>
>>>The point presumably being that having been "liberated", you are now
>>>"free".
Not as much "been" liberated, but "turned" liberated.
>>Dictionaries used to be the arbiters of the language - any word or
>>meaning of a word not found in the dictionary was considered a
>>colloquial (slang) use. Since the 1980's, an entry in the
>>dictionary has become little more than evidence of popularity as the
>>major dictionaries (OED, Webster, Cambridge, etc.) will now consider
>>any word they can find used in print.
>
> Apparantly, you missed the part where I referred to the 1913 edition
> of Webster. I have kept it in the quoted text above for your
> convenience. I can assure you that 1913 is both more than 30 years
> ago /and/ it is before 1980, in case that was in doubt.
But picking just a single word from a whole explanation of _one_
naming and declaring it as equivalent is not really being careful with
language at all.
And even when using a Thesaurus, it should be clear that the offered
alternatives are not supposed to or capable of capturing all nuances
of the keyword.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Bent C Dalager
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <fe0npc$cvq$1@orkan.itea.ntnu.no>
In article <··············@lola.goethe.zz>, David Kastrup <···@gnu.org> wrote:
>···@pvv.ntnu.no (Bent C Dalager) writes:
>
>Not as much "been" liberated, but "turned" liberated.
I expect that either way you split this hair, using "free" in the
sense of "possessing liberty" is still going to be quite reasonable.
>But picking just a single word from a whole explanation of _one_
>naming and declaring it as equivalent is not really being careful with
>language at all.
I have never claimed equivalence. What I have made claims about are
the properties of one of the meanings of a word. Specifically, my
claim is that "free" is a reasonable description of some one or some
thing that has been "liberated".
As an example, when a slave becomes a free man, this is not commonly
understood to mean that he now has a low or zero monetary cost.
>And even when using a Thesaurus, it should be clear that the offered
>alternatives are not supposed to or capable of capturing all nuances
>of the keyword.
I have never claimed to be providing a full definition of the word.
Indeed, I quite clearly conceded very early on that "free" is commonly
associated with what might otherwise be called "gratis" - that is
"free of charge".
My effort has been to point out that the word also has other meanings.
Cheers
Bent D
--
Bent Dalager - ···@pvv.org - http://www.pvv.org/~bcd
powered by emacs
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <85hcl8qaj7.fsf@lola.goethe.zz>
···@pvv.ntnu.no (Bent C Dalager) writes:
> In article <··············@lola.goethe.zz>, David Kastrup <···@gnu.org> wrote:
>>···@pvv.ntnu.no (Bent C Dalager) writes:
>>
>>Not as much "been" liberated, but "turned" liberated.
>
> I expect that either way you split this hair, using "free" in the
> sense of "possessing liberty" is still going to be quite reasonable.
>
>>But picking just a single word from a whole explanation of _one_
>>naming and declaring it as equivalent is not really being careful with
>>language at all.
>
> I have never claimed equivalence. What I have made claims about are
> the properties of one of the meanings of a word. Specifically, my
> claim is that "free" is a reasonable description of some one or some
> thing that has been "liberated".
But it suggests that the natural state would be the unfree state.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Bent C Dalager
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <fe0q7a$e42$1@orkan.itea.ntnu.no>
In article <··············@lola.goethe.zz>, David Kastrup <···@gnu.org> wrote:
>···@pvv.ntnu.no (Bent C Dalager) writes:
>
>> I have never claimed equivalence. What I have made claims about are
>> the properties of one of the meanings of a word. Specifically, my
>> claim is that "free" is a reasonable description of some one or some
>> thing that has been "liberated".
>
>But it suggests that the natural state would be the unfree state.
Would this be a good thing? Would it be a bad thing? What is your
point?
Cheers
Bent D
--
Bent Dalager - ···@pvv.org - http://www.pvv.org/~bcd
powered by emacs
Webster? WEBSTER. . . ?
Whatever happened to the Oxford English Dictionary ?
Seems to me the English have always spoken the definitive
English. . . that's why they call it ENGLISH.
rjack wrote:
> Webster? WEBSTER. . . ?
>
> Whatever happened to the Oxford English Dictionary ?
> Seems to me the English have always spoken the definitive
> English. . . that's why they call it ENGLISH.
What is in a name? A rose by any other name would still smell as sweet.
--
Lew
From: Bent C Dalager
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <fe10en$hmk$1@orkan.itea.ntnu.no>
In article <································@insightbb.com>,
rjack <·····@com> wrote:
>Webster? WEBSTER. . . ?
>
>Whatever happened to the Oxford English Dictionary ?
It suffers from not being in my "dict" installation I suppose.
>Seems to me the English have always spoken the definitive
>English. . . that's why they call it ENGLISH.
Unfortunately, these days English almost always means American English
and if you want British English you have to specify that explicitly.
But I don't actually think that the difference is significant to the
current controversy surrounding the interpretation of the word "free".
Cheers
Bent D
--
Bent Dalager - ···@pvv.org - http://www.pvv.org/~bcd
powered by emacs
Bent C Dalager wrote:
> In article <··············@lola.goethe.zz>, David Kastrup <···@gnu.org> wrote:
>> ···@pvv.ntnu.no (Bent C Dalager) writes:
>>
>>> I have never claimed equivalence. What I have made claims about are
>>> the properties of one of the meanings of a word. Specifically, my
>>> claim is that "free" is a reasonable description of some one or some
>>> thing that has been "liberated".
>> But it suggests that the natural state would be the unfree state.
>
> Would this be a good thing? Would it be a bad thing? What is your
> point?
"There's no easy way to be free."
"The price of freedom is eternal vigilance."
Freedom is not natural. It must be defended.
--
Lew
On Wed, 3 Oct 2007 18:20:38 +0000 (UTC), ···@pvv.ntnu.no (Bent C
Dalager) wrote:
>In article <··································@4ax.com>,
>George Neuner <·········@comcast.net> wrote:
>>On Wed, 3 Oct 2007 09:36:40 +0000 (UTC), ···@pvv.ntnu.no (Bent C
>>Dalager) wrote:
>>
>>>
>>>Only if you're being exceedingly pedantic and probably not even
>>>then. Webster 1913 lists, among other meanings,
>>>
>>>Free
>>>(...)
>>>"Liberated, by arriving at a certain age, from the control
>>>of parents, guardian, or master."
>>>
>>>The point presumably being that having been "liberated", you are now
>>>"free".
>>
>> (...)
>>
>>The English language has degenerated significantly in the last 30
>>years.
>> (...)
>>
>>Dictionaries used to be the arbiters of the language - any word or
>>meaning of a word not found in the dictionary was considered a
>>colloquial (slang) use. Since the 1980's, an entry in the dictionary
>>has become little more than evidence of popularity as the major
>>dictionaries (OED, Webster, Cambridge, etc.) will now consider any
>>word they can find used in print.
>
>Apparantly, you missed the part where I referred to the 1913 edition
>of Webster. I have kept it in the quoted text above for your
>convenience. I can assure you that 1913 is both more than 30 years ago
>/and/ it is before 1980, in case that was in doubt.
>
>Cheers
> Bent D
I didn't miss it. Your post was just an opportunity to rant.
George
--
for email reply remove "/" from address
George Neuner wrote:
> Symbolism over substance has become the mantra
> of the young.
"Symbolism: The practice of representing things by means of symbols or
of attributing symbolic meanings or significance to objects, events, or
relationships."
One might even suggest that all written language is based on the use of
words as symbols.
"Substance: (2)
a. Essential nature; essence.
b. Gist; heart."
"Mantra: A sacred verbal formula repeated in prayer, meditation, or
incantation, such as an invocation of a god, a magic spell, or a
syllable or portion of scripture containing mystical potentialities."
Perhaps the young people you're referring to are not the same young
people that I know, because I've never even heard of a religion whose
object of reverence is meta-level analysis of language.
Tell me, do you know what "hyperbole" means?
-dan "or 'rhetorical'"
On Wed, 03 Oct 2007 23:07:32 +0100, ···@telent.net wrote:
>George Neuner wrote:
>> Symbolism over substance has become the mantra
>> of the young.
>
>"Symbolism: The practice of representing things by means of symbols or
>of attributing symbolic meanings or significance to objects, events, or
>relationships."
>
>One might even suggest that all written language is based on the use of
>words as symbols.
>
>"Substance: (2)
> a. Essential nature; essence.
> b. Gist; heart."
>
>"Mantra: A sacred verbal formula repeated in prayer, meditation, or
>incantation, such as an invocation of a god, a magic spell, or a
>syllable or portion of scripture containing mystical potentialities."
>
>Perhaps the young people you're referring to are not the same young
>people that I know, because I've never even heard of a religion whose
>object of reverence is meta-level analysis of language.
The Christian Bible says "In the beginning was the Word, and the Word
was with God, and the Word was God." John 1:1. Theologians and
philosophers have been writing about it for quite a few centuries.
Or, how about politics? Another example from the Judeo-Christian
Bible (that is, from the Old Testament), politicking was the sin that
resulted in Lucifer's fall from God's grace.
[Yeah, I know the official story is that Lucifer's sin was envy.
Trust me ... I was there. God didn't have a clue until Lucifer went
and organized the rally to protest God's policy on human souls (back
then God trusted his angels and was not in the habit of reading their
minds). He didn't find out that Lucifer was behind the protests until
after Michael's police units had put down the riots. When it was all
over, God didn't care that Lucifer had been envious or prideful or
lustful ... He was simply pissed that Lucifer had protested His
policies.
Shortly after He outlawed beer in Heaven because many of the rioters
had been drunk. Then He started a program of wire-tapping without
warrants to spy on innocent angels. I was ready to leave when He
closed the pubs, the illegal wire-taps just clinched it.]
>Tell me, do you know what "hyperbole" means?
Yes I do.
George
--
for email reply remove "/" from address
From: Klaus Schilling
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <87fy0rovwb.fsf@web.de>
George Neuner <·········@comcast.net> writes:
>
> Or, how about politics? Another example from the Judeo-Christian
> Bible (that is, from the Old Testament), politicking was the sin that
> resulted in Lucifer's fall from God's grace.
that's not a God, but an inferior demiurge,
as correctly figured by Marcion
> [Yeah, I know the official story is that Lucifer's sin was envy.
the official story is thoroughly flawed.
of course Lucifer means carrier of light,
and thus has nothing to do with sin.
but the contrary.
Lucifer brings enlightenment to those people
who are enchained in the darkness of oppression and stupor
the demiurge imposed upon them.
Thus it's Plato who equalled the situation of
unenlightened mankind with that of prisoners in a dark cave.
Sin is the rejection of the light brought by
the carrier of light.
Same goes for those who have once seen the light of
the Symbolic Expressions, but continue rejoycing in
infix Syntax.
Klaus Schilling
George Neuner <·········@comcast.net> writes:
> On Wed, 3 Oct 2007 09:36:40 +0000 (UTC), ···@pvv.ntnu.no (Bent C
> Dalager) wrote:
>
>>In article <··············@lola.goethe.zz>, David Kastrup <···@gnu.org> wrote:
>>>···@pvv.ntnu.no (Bent C Dalager) writes:
>>>
>>>> In article <···············@news.t-online.com>,
>>>> Frank Goenninger <····@goenninger.net> wrote:
>>>>>
>>>>>Well, I didn't start the discussion. So you should ask the OP about the
>>>>>why. I jumped in when I came across the so often mentioned "hey, it's
>>>>>all well defined" statement was brought in. I simply said that if that
>>>>>"well-definedness" is against "common understanding" then I don't give
>>>>>a damn about that clever definitions. Because I have to know that there
>>>>>are such definitions - always also knowing that free is not really
>>>>>free.
>>>>
>>>> "Liberated" is a valid meaning of the word "free".
>>>
>>>No. It is a valid meaning of the word "freed".
>>
>>Only if you're being exceedingly pedantic and probably not even
>>then. Webster 1913 lists, among other meanings,
>>
>>Free
>>(...)
>>"Liberated, by arriving at a certain age, from the control
>>of parents, guardian, or master."
>>
>>The point presumably being that having been "liberated", you are now
>>"free".
>
> I don't think knowing the meaning of a word is being pedantic.
> "Freed" is derived from "free" but has a different, though associated,
> meaning. Words have meaning despite the many attempts by Generation X
> to assert otherwise. Symbolism over substance has become the mantra
> of the young.
>
> The English language has degenerated significantly in the last 30
> years. People (marketers in particular) routinely coin ridiculous new
> words and hope they will catch on. I remember seeing a documentary
> (circa 1990?) about changes in the English language. One part of the
> program was about the BBC news and one of its editors, whom the staff
> called the "protector of language", who checked the pronunciation of
> words by the news anchors. The thing that struck me about this story
> was the number of BBC newspeople who publicly admitted that they could
> hardly wait for this man to retire so they could write and speak the
> way they wanted rather than having to be "correct".
>
> Dictionaries used to be the arbiters of the language - any word or
> meaning of a word not found in the dictionary was considered a
> colloquial (slang) use. Since the 1980's, an entry in the dictionary
> has become little more than evidence of popularity as the major
> dictionaries (OED, Webster, Cambridge, etc.) will now consider any
> word they can find used in print.
>
Language is not a static 'set in stone' thing. It changes and while some
may find the changes unwelcome, it will change anyway. Although I have no
evidence to support it, I suspect that 'free' wold have been more commonly
associated with meanings other than 'free of cost' pre-capitalism. Checking
a few dictionaries seems to indicate that its meaning along the lines of
free from restriction, control, freedom, liberated etc is more in keeping
with its origins than an interpretation of free of cost and that even in
that context, it meant free from the restriction of having to be paid for.
The bottom line is that free has different meanings and if a group decides
to use that term and at the same time specify which context it means it to
apply, then I think that is reasonable. Ask your wife what she thinks is
meant by a free variable and she may say that it is a variable that has no
cost (as in free beer), This doesn't mean that its use is wrong or
incorrect.
I once asked RMS why he chose free, given the ambiguity it would cause,
over alternatives, such as freedom, liberated or even unrestricted. His
response was that at the time, free as in freedom was the concious
association they had and other associations and resulting ambiguity did not
occur to them until it was too late. This seems reasonable enough. If your
focus was to ensure that software was free from what you perceived to be
restrictions that would ultimately reduce your individual freedom, then
free fits. The fact this has led to confusion amongst consumers in a
capitalist based economy probably says as much about modern values and the
changing balance between consumerism compared to freedom than anything
else.
Tim
"The Americans are identical to the British in all respects except, of
course, language." Oscar Wilde
Giving English to an American is like giving sex to a child. He knows it's
important but he doesn't know what to do with it. Adam Cooper (19th
century)
"We (the British and Americans) are two countries separated by a common
language. G.B. Shaw
The Englishman commented to the American about the "curious"
way in which he pronounced so many words, such as schedule
(pronounced shedule). The American thought about it for a few
moments, then replied, "Perhaps it's because we went to
different shools!"
Englishman: Its maths not math because it is short for mathematics
American: Then you would say "Maths are fun"?
---
tcross (at) rapttech dot com dot au
Tim X wrote:
> "The Americans are identical to the British in all respects except, of
> course, language." Oscar Wilde
> "We (the British and Americans) are two countries separated by a common
> language. G.B. Shaw
> There is a well-known saying: Two nations separated by a common language. However, this phrase doesn't seem to have been positively recorded in this form by anyone.
>
> In The Canterville Ghost Oscar Wilde wrote:
>
> /We have really everything in common with America nowadays except, of course, language/
>
> In a 1951 book of quotations, and without attributing a source, George Bernard Shaw was credited with saying:
>
> /England and America are two countries separated by the same language/
>
> Even Dylan Thomas had his say in a radio talk in the early 50s:
>
> /[European writers and scholars in America are] up against the barrier of a common language/
>
> But where the original phrase came from, nobody knows, and it is probably simply incorrectly quoted.
<http://yedda.com/questions/origin_famous_sentence_quotations_8625651351715/>
--
Lew
From: John W. Kennedy
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <VIfNi.46$wm7.6@newsfe12.lga>
Tim X wrote:
> Although I have no
> evidence to support it, I suspect that 'free' wold have been more commonly
> associated with meanings other than 'free of cost' pre-capitalism.
C. S. Lewis has a whole chapter on "free", "liberal", "ελευθεριος",
"frank", etc., in "Studies in Words".
--
John W. Kennedy
"Those in the seat of power oft forget their failings and seek only the
obeisance of others! Thus is bad government born! Hold in your heart
that you and the people are one, human beings all, and good government
shall arise of its own accord! Such is the path of virtue!"
-- Kazuo Koike. "Lone Wolf and Cub: Thirteen Strings" (tr. Dana Lewis)
From: ···@nowhere.com
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <Xns99C252D1319CElhb123@140.99.99.130>
Wildemar Wildenburger <···········@klapptsowieso.net> wrote in
·····························@newsspool3.arcor-online.net:
> While I agree that the word "free" implies "free of monetary cost" to
> many people societies, that is by no means set in stone (talk to native
> americans, blacks, jews, palestinians, etc. about the word free, see
> what they have to say).
Words are defined by popular usage. In popular usage, the meaning of free
as an adjective depends on the context. If the adjective is applied to
people, it means the opposite of slavery or imprisonment. If it's applied
to something other than people, it means free as in beer.
For example, a dog with no owner, wandering freely (adverb), would not be
called a free dog (adjective), to mean possessing freedom. Free dog means
free as in beer. Likewise, in popular usage, free software means free as
in beer. People who use it with a different meaning are vainly trying to
change its meaning. But the meanings of words can't be arbitrarily
changed, just by dictating different meanings. The meaning has to be
adopted by popular usage, which free-as-in-GPL software has not been.
Therefore, I propose, using dog freedom as our logic, we call it stray
software.
From: Klaus Schilling
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <874ph0dd8x.fsf@web.de>
···@nowhere.com writes:
> Words are defined by popular usage.
no, that's nowhere near the case,
as already known by Plato in Kratylos.
Succumbing to popular usage is perverse and absurd.
Klaus Schilling
From: Damien Kick
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <13glppu3hknk597@corp.supernews.com>
Wildemar Wildenburger wrote:
> Frank Goenninger wrote:
>> On 2007-09-29 01:27:04 +0200, Damien Kick <·····@earthlink.net> said:
>>
>>> If you were referring to the "free" in "free Mumia Abu Jamal", I
>>> would agree with you. I don't think anyone would imagine that this
>>> phrase meant that someone was going to get Mumia Abu Jamal gratis.
>>> Like it or not, "free software" referring to "free as in beer" is
>>> probably the most common interpretation of the phrase for a native
>>> English speaker. [...]
>>
>> Fully true for non-native English speakers as well. Just did the "wife
>> test" also - she is a pure software user - and yes, free is "no money,
>> do what you want" and that's it.
I should have used the phrase "fluent English speaker"...
>> I *never* use the term "free" if I don't want to imply "free beer"
>> (which is a Good Thing and as such highly valuated - ask any
>> Bavarian). Using "free" as by FSF or any other lawyer-style 6 pixel
>> font printed phrasing is pure perfidiousness.
>>
> I appearantly missed a lot of that conversation, but what is your point?
> While I agree that the word "free" implies "free of monetary cost" to
> many people societies, that is by no means set in stone [...].
For some odd reason, this reminded me of an old episode of Mork & Mindy:
<blockquote
cite="http://www.salon.com/ent/movies/feature/1999/09/03/robin/">
What made Mork think eggs could fly? And yet when he tried to release
them from the tyranny of gravity ("Fly, be free!"), flinging them into
the air only to have them land with a soft thwack, it seemed like
nothing so much as a stroke of loopy brilliance.
</blockquote>
The term "free eggs" can only sensibly mean one thing, eggs which can be
obtained without an exchange of money. To think of it meaning anything
else--"fly, be free!"--is comedy (or not, depending on one's opinion of
Mork & Mindy). When Free Software Foundationistas try to insist on the
phrase "free software" meaning anything other than the obvious
interpretation of the term it is annoying (or not, depending on one's
opinion of RMS's skills as a wordsmith). I've got this great mental
image of some farcical Free Software Liberation Army running around,
removing hard drives from boxen, and throwing them in the air with the
moral imperative to "fly, be free!"
> But that aside: The word free with respect to the FSF and GPL have a
> perfectly well defined meaning. People may misunderstand that from not
> knowing the definition but that doesnt make it any less well defined.
This thread of conversation also popped into my head when I was waiting
in line at the Starbucks in the building in which I work. I've been
ordering a lot of Americanos lately. I always ask for a small Americano
and the person taking my order always calls out my drink as a "tall".
With respect to Starbucks, calling a beverage which comes in the
shortest cup used in the store a "tall" has a perfectly well defined
meaning. But that doesn't make it any less ridiculous. Of course, it
was mentioned elsewhere in this thread that context is important. And
it is. To use the Starbucks analogy, for someone to criticize Starbucks
because their tall drinks really are actually quite short would be
ignoring the significance of the context of Starbucks' abuse of the
English language. But, again, that doesn't make Starbuck's use of the
word any less ridiculous. However, at least at Starbucks, when I use
the "wrong" word, they don't start lecturing me. They know what I mean
and simply go ahead and translate it to Starbucks newspeak.
> Again, why this discussion?
Hello, Pot? This is the kettle. You are so black.
"Damien Kick" <·····@earthlink.net> wrote in message
····················@corp.supernews.com...
> This thread of conversation also popped into my head when I was waiting in
> line at the Starbucks in the building in which I work. I've been ordering
> a lot of Americanos lately. I always ask for a small Americano and the
> person taking my order always calls out my drink as a "tall". With respect
> to Starbucks, calling a beverage which comes in the shortest cup used in
> the store a "tall" has a perfectly well defined meaning. But that doesn't
> make it any less ridiculous. Of course, it was mentioned elsewhere in
> this thread that context is important. And it is. To use the Starbucks
> analogy, for someone to criticize Starbucks because their tall drinks
> really are actually quite short would be ignoring the significance of the
> context of Starbucks' abuse of the English language. But, again, that
> doesn't make Starbuck's use of the word any less ridiculous. However, at
> least at Starbucks, when I use the "wrong" word, they don't start
> lecturing me. They know what I mean and simply go ahead and translate it
> to Starbucks newspeak.
I, as a tall Americano, have always taken ordering the smallest espresso
beverage possible as something describing the preference of the orderer, as
opposed to the beverage itself.
--
wade ward
"Your boyfriend is not my boyfriend, doll."
On Fri, 28 Sep 2007 18:27:04 -0500, Damien Kick <·····@earthlink.net>
wrote, quoted or indirectly quoted someone who said :
>"free as in beer".
but does not "free beer" nearly always come with a catch or implied
obligation?
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
On Tue, 02 Oct 2007 03:38:08 GMT, Roedy Green
<···········@mindprod.com.invalid> wrote:
>On Fri, 28 Sep 2007 18:27:04 -0500, Damien Kick <·····@earthlink.net>
>wrote, quoted or indirectly quoted someone who said :
>
>>"free as in beer".
>
>but does not "free beer" nearly always come with a catch or implied
>obligation?
It means you have to bring the chips.
George
--
for email reply remove "/" from address
From: Damien Kick
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <13gj0neh59oks91@corp.supernews.com>
Roedy Green wrote:
> On Fri, 28 Sep 2007 18:27:04 -0500, Damien Kick <·····@earthlink.net>
> wrote, quoted or indirectly quoted someone who said :
>
>> "free as in beer".
>
> but does not "free beer" nearly always come with a catch or implied
> obligation?
I had been trying to find a good Nietzsche quote about the role of debt
in the relationship of a child to his or her parents but I could not
seem to find a good one. I did, however, find what I think to be an
interesting secondary source
<http://www.eurozine.com/articles/2007-09-20-neilson-en.html>:
<blockquote>
For Nietzsche, debt was linked to the problem of promising and
forgetting. It would be a mistake to underestimate the importance of the
etymological play that underlies his association of debts (Schulden)
with guilt (Schuld). As is well known, the Second Essay of On the
Genealogy of Morals argues that the feeling of guilt, of personal
obligation, has its origin in the contractual relationship between
creditor and debtor. "It was here", Nietzsche writes, "that one person
first measured himself against another". And he continues:
Perhaps our word "man" (manas) still expresses something of precisely
this feeling of self-satisfaction: man designated himself as the
creature that measures values, evaluates and measures, as the "valuating
animal as such".[1]
How today are we to understand these claims and Nietzsche's extension of
them into arguments about the role of debt in the relations between
parents and children or between man and the deity?
</blockquote>
Beer helps to eliminate debt by promoting forgetfulness.
On Oct 7, 9:07 pm, Damien Kick <·····@earthlink.net> wrote:
> Perhaps our word "man" (manas) still expresses something of precisely
> this feeling of self-satisfaction: man designated himself as the
> creature that measures values, evaluates and measures, as the "valuating
> animal as such".[1]
Don't both "man" and those words for measurement come ultimately from
words for "hand" (similarly to words like "manual", as in labor)? Our
clever hands with their opposable thumbs being considered a defining
characteristic. And our tool use thus derived. Handspans also having
been a common (if imprecise) early unit of measurement (along with
forearm-spans, as in cubits, strides, and foot-length, from which the
measurement in feet still derives its name).
······@gmail.com wrote:
> Don't both "man" and those words for measurement come ultimately from
> words for "hand" (similarly to words like "manual", as in labor)? Our
> clever hands with their opposable thumbs being considered a defining
> characteristic. And our tool use thus derived. Handspans also having
> been a common (if imprecise) early unit of measurement (along with
> forearm-spans, as in cubits, strides, and foot-length, from which the
> measurement in feet still derives its name).
For most humans, the length of their foot from heel to toe is nearly equal to
the length of their forearm elbow to wrist.
--
Lew
······@gmail.com wrote:
> Don't both "man" and those words for measurement come ultimately from
> words for "hand" (similarly to words like "manual", as in labor)?
no. "manual" is derived from latin "manus" meaning "hand". the word "man"
is related to (though not directly derived from) "mind", and the latin word
"mens", which means "mind".
--
Joost Kremers ············@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
On Oct 8, 7:32 am, Joost Kremers <············@yahoo.com> wrote:
> ······@gmail.com wrote:
> > Don't both "man" and those words for measurement come ultimately from
> > words for "hand" (similarly to words like "manual", as in labor)?
>
> no.
Do not bluntly contradict me in public.
> "manual" is derived from latin "manus" meaning "hand". the word "man"
> is related to (though not directly derived from) "mind", and the latin word
> "mens", which means "mind".
So you assert, but "man" bears a much closer resemblance to "manus"
than it does to "mens".
Or are you proposing that the plural word "men" came first? That would
be ... odd.
From: Matthias Buelow
Subject: Cantankerous trolliness ad infinitum, was: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <5n3fp4Ffvt8mU1@mid.dfncis.de>
··········@gmail.com wrote:
^^^^^^^^^^^^^^^^^^^^^
Is this some sport of yours to constantly create new gmail accounts and
spam Usenet?
> So you assert, but "man" bears a much closer resemblance to "manus"
> than it does to "mens".
This is irrelevant. Consult an etymological dictionary.
F'up-to: comp.lang.lisp, where I'm reading this.
On Oct 10, 4:11 am, Matthias Buelow <····@incubus.de> wrote:
>
> Is this some sport of yours to constantly create new gmail accounts and
> spam Usenet?
I am not a spammer. You, however, *are* a liar.
[snip remaining insults]
[correct newsgroups: header after attempted hijacking to make my
response disappear]
<··········@gmail.com> wrote:
> On Oct 8, 7:32 am, Joost Kremers <············@yahoo.com> wrote:
> > ······@gmail.com wrote:
> > > Don't both "man" and those words for measurement come ultimately from
> > > words for "hand" (similarly to words like "manual", as in labor)?
> >
> > no.
>
> Do not bluntly contradict me in public.
There are four lights!
From: Ken Tilton
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <kP9Pi.190$et6.172@newsfe12.lga>
··········@gmail.com wrote:
> On Oct 8, 7:32 am, Joost Kremers <············@yahoo.com> wrote:
>
>>······@gmail.com wrote:
>>
>>>Don't both "man" and those words for measurement come ultimately from
>>>words for "hand" (similarly to words like "manual", as in labor)?
>>
>>no.
>
>
> Do not bluntly contradict me in public.
I am reminded of my tai chi teacher in NYC, who used to come over to
correct me and say, "I used to do it that way."
Or, "What you are doing is good. What I do is...".
His school is very successful.
kenny
--
http://www.theoryyalgebra.com/
"Mother always told me, if you tell a lie,
always rehearse it. If it don't sound good
to you, it won't sound good to no one else."
- Satchel Paige
From: John W. Kennedy
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <CLwPi.2348$Yb2.747@newsfe12.lga>
··········@gmail.com wrote:
> Do not bluntly contradict me in public.
You are in grave need of professional psychiatric help.
Seek it now, if you do not wish your life to be ended three or four
years down the line by a police sniper.
--
John W. Kennedy
Read the remains of Shakespeare's lost play, now annotated!
http://pws.prserv.net/jwkennedy/Double%20Falshood/index.html
On Oct 11, 5:40 pm, "John W. Kennedy" <·······@attglobal.net> wrote:
> ··········@gmail.com wrote:
> > Do not bluntly contradict me in public.
>
> [insult deleted]
>
> [death threat deleted]
Insults and other such falsehoods will be deleted rather than repeated
and death threats will be reported to your internet service provider;
this is a public service provided by me for free.
Have a nice day. :)
From: Gian Uberto Lauri
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <87r6nzc9nu.fsf@mail.eng.it>
>>>>> "n" == nebulous99 <··········@gmail.com> writes:
n> On Jun 22, 6:32 pm, Cor Gest <····@clsnet.nl> wrote:
>> > HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO
>> ENTER > THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT
>> WOULD TELL > THEM THOSE ARE THE KEYS TO REACH THE HELP?!
>>
>> What's your problem ?
>>
>> Ofcourse a mere program-consumer would not look what was being
>> installed on his/her system in the first place ... So after some
>> trivial perusing what was installed and where : WOW Look, MA !
>> .... it's all there!
>>
>> lpr /usr/local/share/emacs/21.3/etc/refcard.ps or your
>> install-dir........^ ^ or your
>> version.............................^
n> So now we're expected to go on a filesystem fishing expedition
n> instead of just hit F1? One small step (backwards) for a man; one
n> giant leap (backwards) for mankind. :P
Waring, possible ID TEN T detected!
There's a program called find, not this intuitive but worth learning
It could solve the problem from the root with something like
find / -name refcard.ps -exec lpr {} \; 2> /dev/null
This line requires some brain and some learning, true, but the
documents should be on your HD, unless you avoided installing the man
to save space.
About the brain, you should have received like me a standard issue one
at least (or maybe a better one).
>> But then again buying the GNU-book from 'O Reilly would have solved
>> it in the utmost nicest possible of ways anyway.
n> So much for the "free" in "free software". If you can't actually
n> use it without paying money, whether for the software or for some
n> book, it isn't really free, is it?
GNU books ARE free, and come in both printed and electronic form.
No excuses.
BTW, buing a GNU book is a good way to finance FSF.
And from your too-lazy (ID TEN T like) point of view even freedom
itself is not free, since its defence has a cost.
--
/\ ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
//--\| | \| | Integralista GNUslamico
\/ e coltivatore diretto di Software
A Cesare avrei detto di scrivermi a ·····@rat.vg
On Jun 26, 6:06 am, Gian Uberto Lauri <····@spammer.impiccati.it>
wrote:
> >> > HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO
> >> ENTER > THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT
> >> WOULD TELL > THEM THOSE ARE THE KEYS TO REACH THE HELP?!
>
> >> What's your problem ?
>
> >> Ofcourse a mere program-consumer would not look what was being
> >> installed on his/her system in the first place ... So after some
> >> trivial perusing what was installed and where : WOW Look, MA !
> >> .... it's all there!
>
> >> lpr /usr/local/share/emacs/21.3/etc/refcard.ps or your
> >> install-dir........^ ^ or your
> >> version.............................^
>
> n> So now we're expected to go on a filesystem fishing expedition
> n> instead of just hit F1? One small step (backwards) for a man; one
> n> giant leap (backwards) for mankind. :P
[snipping some thinly-veiled insults and irrelevancies throughout]
> There's a program called find, not this intuitive but worth learning
>
> It could solve the problem from the root with something like
>
> find / -name refcard.ps -exec lpr {} \; 2> /dev/null
Let me get this straight.
In this corner, we have just about every Windows application ever
developed. When a user needs help, a click on the "help" menu or tap
of the F1 key is all it takes to obtain some. Sometimes the help is
not of the greatest quality, but that is another issue we won't
concern ourselves with here.
In the other corner, we have just about every Unix application ever
developed. When a user needs help, they may do such things as manually
explore the directories where the application was installed
(equivalent to rooting around in C:\Program Files\Appname for .hlp
files, because F1 didn't work and there was no "help" menu, if such a
thing ever happened on Windoze). Or alternatively it can just
magically come to them as a divinely inspired insight, or in a dream
or a burning bush or stone tablets from heaven or something, that
something useful might happen if the unlikely combination of symbols
"find / -name refcard.ps -exec lpr {} \; 2> /dev/null" were typed at
the console, which otherwise would obviously never occur to them. Even
if they knew the find tool and its syntax, it would still have to
somehow occur to them that "refcard.ps" might be a useful search
target. On Windows, if push came to shove, clicking Start->Search and
putting in ".hlp" and "C:\Program Files\Appname" would quickly find
any help files. If they were given the usual file extension. If not,
good luck, but most usually the help files would be named to end
with .hlp. Moreover, once found, a quick double click and they're in a
hypertext browser viewing the help. Unless I miss my guess, refcard.ps
would require mucking about installing and configuring Ghostscript and
GSView, which for Joe Winblows User is daunting enough. Trying to read
anything serious and navigate in GSView is no picnic either. A
hypertext browser it ain't. Adobe Acrobat Reader *might* be able to do
more with a .ps file, but it's proprietary. On a Unix box, if you
don't know exactly how to get some app viewing a .ps file and how to
navigate in it I'm guessing you're SOL. The original suggestion with
"lpr" implies printing it rather than viewing it online, which a)
costs money and b) requires configuring a printer and a Postscript
interpreter, given that unless the printer cost more than the
computer's CPU it surely won't natively grok Postscript. We're back to
configuring Ghostscript, only this time on the Unix box where I have
no doubt it's even more painful than it is on a Windoze box, as well
as configuring a printer on a Unix box, itself a recurring nightmare
of mine for years now since one night in the nineties when I got
caught in the crossfire between someone's Epson inkjet and their
Mandrake 7.somethingorother Linux.
Reexamining that "find" line it looks like it tries to automatically
"lpr" the file(s) found. That is cause for concern, since I can easily
see something like this going into Sorceror's Apprentice mode and
costing you a fortune in ink and paper if there's either a misspelling
or other mistake (easy enough to make in a complex arcane command line
like that one) or more "refcard.ps" matches than you expected there'd
be in the target directory and its descendants.
In article <························@o61g2000hsh.googlegroups.com>,
Twisted <··········@gmail.com> wrote:
...
>In the other corner, we have just about every Unix application ever
>developed. When a user needs help, they may do such things as manually
>explore the directories where the application was installed
>(equivalent to rooting around in C:\Program Files\Appname for .hlp
>files, because F1 didn't work and there was no "help" menu,
I just pressed F1 in a running session of a Emacs under Ubuntu Linux... it
brought up online help.
>if such a thing ever happened on Windoze).
Such things happen _all the time_ on Windows, particularly if you count
help menus that lead solely to useless About boxes.
This might be a moot point anyway, given the high number of people I've
met that don't even bother reading online help in the first place.
-Mike
--
http://www.mschaef.com
From: Gian Uberto Lauri
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <87ir9924l5.fsf@mail.eng.it>
>>>>> Long count = 12.19.14.7.16; tzolkin = 2 Cib; haab = 4 Tzec.
>>>>> I get words from the Allmighty Great Gnus that
>>>>> "T" == Twisted <··········@gmail.com> writes:
T> On Jun 26, 6:06 am, Gian Uberto Lauri <····@spammer.impiccati.it>
T> wrote:
>> >> > HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO
>> >> ENTER > THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP
>> THAT >> WOULD TELL > THEM THOSE ARE THE KEYS TO REACH THE HELP?!
>>
>> >> What's your problem ?
>>
>> >> Ofcourse a mere program-consumer would not look what was being
>> >> installed on his/her system in the first place ... So after
>> some >> trivial perusing what was installed and where : WOW Look,
>> MA ! >> .... it's all there!
>>
>> >> lpr /usr/local/share/emacs/21.3/etc/refcard.ps or your >>
>> install-dir........^ ^ or your >>
>> version.............................^
>>
n> So now we're expected to go on a filesystem fishing expedition
n> instead of just hit F1? One small step (backwards) for a man; one
n> giant leap (backwards) for mankind. :P
T> [snipping some thinly-veiled insults and irrelevancies throughout]
>> There's a program called find, not this intuitive but worth
>> learning
>>
>> It could solve the problem from the root with something like
>>
>> find / -name refcard.ps -exec lpr {} \; 2> /dev/null
T> Let me get this straight.
T> In this corner, we have just about every Windows application ever
T> developed. When a user needs help, a click on the "help" menu or
T> tap of the F1 key is all it takes to obtain some. Sometimes the
T> help is not of the greatest quality, but that is another issue we
T> won't concern ourselves with here.
Hmmm. I just activated the help hitting F1... WOHA, it says that if I
press k after F1 I get the description of what that key does...
T> In the other corner, we have just about every Unix application ever
T> developed. When a user needs help, they may do such things as
T> manually explore the directories where the application was
T> installed
Ever heard about the man command ? Is the first thing you learn to
do...
T> Or alternatively
T> it can just magically come to them as a divinely inspired insight,
If they are Windows user, I pity them, their brain could have been
damaged beyond repair.
They'll never be blessed by the idea that programs can do work for
them, and will bash restlessy their keyboard in antiquate sequences of
pre-automatic-controls tasks (as a reference, take a look to the
Metropolis movie)
T> or in a dream or a burning bush or stone tablets from heaven or
T> something, that something useful might happen if the unlikely
T> combination of symbols "find / -name refcard.ps -exec lpr {} \; 2>
T> /dev/null"
Nothing this divine. Just someone a bit more experienced than you are.
On the other hand I never seen such thing like a refcard, that's not
in the standard documentation system for such a modern toxic waste
like Word.
T> obviously never occur to them. Even if they knew the find tool and
T> its syntax, it would still have to somehow occur to them that
T> "refcard.ps" might be a useful search target.
Strange. I am *NOT* a native english speaker and I think my Q.I. tends
toward average from below, but refcard sound very useful to me, maybe
is short for "reference card" ?
T> came to shove, clicking Start->Search and putting in ".hlp" and
T> "C:\Program Files\Appname" would quickly find any help files.
I admit. find is less intuitive. But the stuff Windows comes with does
just that and nothing more. It will never suggest you that the long
boring task expecting you can be solved in a completely automatic
way with a little creative job.
T> most usually the help files would be named to end with
T> .hlp.
All, or that impaired of a O.S. could not understand they are help
files.
T> Moreover, once found, a quick double click and they're in a
T> hypertext browser viewing the help.
Emacs help was hypertextual when Dr. Watson plagued Windowd 3.11
users...
T> Unless I miss my guess,
T> refcard.ps would require mucking about installing and configuring
T> Ghostscript and GSView,
Splash, large miss.
You usually fire it to the local printer.
Uh, I understand. A Windows user could never have shared its HP720c
printer... Windows printer driver aren't known to be smart.
Not an Emacs flaw.
T> enough. Trying to read anything serious and navigate in GSView is
T> no picnic either.
A refcard, my dear, is something that goes on an A4/Letter sheet and
NEEDS NOT to be hypertextual.
T> Reader *might* be able to do more with a .ps file
With a PS file you can do just one thing, execute it. It's a program,
did you know ?
Ah, I never use Acroread. Xpdf does all the things really needed.
Uh, I forget. For Windows users getting a PDF out of a PS or HTML or
ASCII is not this easy unless they get some extra software (someone
ported CUPS to Windows ?). Again, not an Emacs fault.
T> On a Unix box, if you don't know exactly how to get
T> some app viewing a .ps file and how to navigate in it I'm guessing
T> you're SOL.
Stop guessing or all will know that all you know about Unix is that
is a 4 letter word, the first a capital U, the last an x.
On a Unix system either YOU are the sysadmin and know about all the
stuff you need to view, concot, print and bit-recycle PS files or
there's a sysadmin that did this for you. All with free (as in freedom)
stuff.
Most Unix users thinks that Word is a typewriter on steroids not worth
using due its poor output on paper, and are used to a typesetting
system that deals effortlessy with PS, PDF and so on. Uh, oh, Emacs
hypertextual manuals can be turned into a PS or PDF ready for a fine
professional printer...
T> The original suggestion with "lpr" implies printing it
T> rather than viewing it online, which a) costs money and b) requires
T> configuring a printer and a Postscript interpreter, given that
T> unless the printer cost more than the computer's CPU it surely
T> won't natively grok Postscript.
I will call you if I need some advice about cars. Maybe.
But not at all for computers.
refcard.ps is something you print and keep on a side when you start
using Emacs, as a REFERENCE for the key sequence, in the case you
forget some of them.
All the computer screen is devoted to your work, the sheet provides
some extra "real estate" for the help information, a sort of double
heading display. All you need to do is turn your eyes from the
monitor, maybe your eyes and read the informations. It coudl happen
that you need to flip the sheet. But you can keep both your work and
the help text "ready at your fingertips", and this is useful indeed:
you read the command keybinding, turn your eyes, type it and see the
result and/or continue your work.
Online viewing. Great deal.
Flip windows until you reach refcard. Read the command. Flip again
windows until you reach Emacs. Use the command (but you could have
forgot the key sequence - redo from start.
About money. Indeed ink/toner and paper costs. Electricity grows on
the spark tree so aboundant in our forests...
Configuring a printer. Yes you need to configure a printer. You need
it with Windows too. But if your Windows printer driver does not
handle PostScript (or if it does not let you share your printer) *now*
you are SOL. PostScript printing on a Windows system that does not
support PS is a pain in the ass.
But PostScript printing on my '80 Epson printwriter or my HP720c with
a Unix system with CUP is as easy as opening a browser, telling the
system I have a HP720c plugged to the parallel port and voil�.
And I can even share my HP720c.
P> We're back to configuring
T> Ghostscript, only this time on the Unix box where I have no doubt
T> it's even more painful than it is on a Windoze box, as well as
T> configuring a printer on a Unix box, itself a recurring nightmare
T> of mine for years now since one night in the nineties when I got
T> caught in the crossfire between someone's Epson inkjet and their
T> Mandrake 7.somethingorother Linux.
O poor boy. It was a job for someone else indeed.
In the same time I got an HP720c and it come with no other drivers
than Mac and Windows ones. I feared I was SOL when I readed of some
guy that wrote a small program that was able to convert certain gs
output to byte sequences good to pilot the HP720c.
It was *easy* to put this program in the pipeline in the "printer
driver" script.
And was *easy* insert a2ps to shoot plain text directly to the printer.
Before, I used an Epson pinwriter (24 pin head). Again, never had
problems (unless it was dead slow). On the other hand printing
directly some plain text under Windwos...
T> Reexamining that "find" line it looks like it tries to
T> automatically "lpr" the file(s) found.
Looks like ???? Hey, it doesn't look like, it's wat it's mean to do!
T> That is cause for concern,
T> since I can easily see something like this going into Sorceror's
T> Apprentice mode and costing you a fortune in ink and paper if
T> there's either a misspelling or other mistake (easy enough to make
T> in a complex arcane command line like that one) or more
T> "refcard.ps" matches than you expected there'd be in the target
T> directory and its descendants.
You are not one good for the computers, I see.
The good thing in bash is that I can use the history to recall a
command line. So you can first see what find finds, and then rerun the
program (search results get cached, so there's an incredible boost of
speed).
Second. When you learn how useful *is* find used that way, you *don't*
do the mispelling or other mistakes (as a smart person, you first do
the dryrun).
Ah, you'll start thinking that those who find find syntax arcane are
jackass... You need a little to realize it was not this easy in the
beginning. The dark side of power.
--
/\ ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
//--\| | \| | Integralista GNUslamico
\/ e coltivatore diretto di Software
A Cesare avrei detto di scrivermi a ·····@rat.vg
On Jun 27, 4:18 am, Gian Uberto Lauri <····@spammer.impiccati.it>
wrote:
[A very long, rambling, semi-coherent post]
> Strange. I am *NOT* a native english speaker and I think my Q.I. tends
> toward average from below...
That much is obvious.
> ...but refcard sound very useful to me, maybe is short for "reference card" ?
Yes, but you'd have to be some kind of clairvoyant to realize "I know!
I'll do a search for "refcard.ps" on the off chance someone happens to
have made a reference card, called it "refcard", and chose the
Postscript format to record it in!" out of the blue.
> I admit. find is less intuitive. But the stuff Windows comes with does
> just that and nothing more. It will never suggest you that the long
> boring task expecting you can be solved in a completely automatic
> way with a little creative job.
And with one little typo, it's hello Sorceror's Apprentice mode...
> Emacs help was hypertextual when Dr. Watson plagued Windowd 3.11
> users...
Dr. Watson just plagued this WinXP user. Please don't mention Dr.
Watson again for a while, for the love of Christ.
> Splash, large miss.
This is usenet, not Battleship.
> You usually fire it to the local printer.
Yes, if you have one and care to blow through reams of paper and
gallons of ink every month by printing everything you encounter
instead of reading it on the expensive LCD monitor you got for such
purposes.
> T> enough. Trying to read anything serious and navigate in GSView is
> T> no picnic either.
>
> A refcard, my dear, is something that goes on an A4/Letter sheet and
> NEEDS NOT to be hypertextual.
I was being more general.
> With a PS file you can do just one thing, execute it. It's a program,
> did you know ?
For which you need an interpreter. Such as Ghostscript. Which is a
pain to install and a bigger one to configure, even on Windoze.
> Uh, I forget. For Windows users getting a PDF out of a PS or HTML or
> ASCII is not this easy unless they get some extra software (someone
> ported CUPS to Windows ?). Again, not an Emacs fault.
I wouldn't know CUPS if it dropped on my head. I think the same can be
said of most of the 3 or 4 non-expert unix users in the world.
> Stop guessing or all will know that all you know about Unix is that
> is a 4 letter word...
Yeah. Unix is a four-letter word alright.
> All the computer screen is devoted to your work, the sheet provides
> some extra "real estate" for the help information, a sort of double
> heading display. All you need to do is turn your eyes from the
> monitor, maybe your eyes and read the informations. It coudl happen
> that you need to flip the sheet. But you can keep both your work and
> the help text "ready at your fingertips", and this is useful indeed:
> you read the command keybinding, turn your eyes, type it and see the
> result and/or continue your work.
One small step backwards for a man, one giant leap...
> About money. Indeed ink/toner and paper costs. Electricity grows on
> the spark tree so aboundant in our forests...
This intrigues my younger brother. He wants to know how many moons are
in the sky and what color the sun is that your planet orbits. He's at
that phase where he's fascinated by astronauts, tales of alien worlds,
and things like that, you see...
> But PostScript printing on my '80 Epson printwriter or my HP720c with
> a Unix system with CUP is as easy as opening a browser, telling the
> system I have a HP720c plugged to the parallel port and voil�.
I'll bet. Something tells me the catch lies somewhere in "a Unix
system with CUP". Unless it's in "browser" instead. Something tells me
we're not talking about something that resembles Firefox and makes
navigation easy and intuitive here.
> In the same time I got an HP720c and it come with no other drivers
> than Mac and Windows ones. I feared I was SOL when I readed of some
> guy that wrote a small program that was able to convert certain gs
> output to byte sequences good to pilot the HP720c.
>
> It was *easy* to put this program in the pipeline in the "printer
> driver" script.
>
> And was *easy* insert a2ps to shoot plain text directly to the printer.
*Easy*. Maybe if you know all about the guts of how the printing
subsystem of the OS works. I doubt it's anything like that easy for
joe random who just wants to hit "print" and print the document
already and not have to spend ages learning about the internals of the
operating system first. In Windows, you plug it in and pick it from a
dialog (or use a disc that comes with the printer to do setup) and
print something. Voila! Out pops a document into the tray; no mess, no
fuss. Getting out your wrench and going at the plumbing shouldn't be
necessary; any more than I'd want to move into a new home and find I
needed to break out the tools and mess with the plumbing before the
toilet would flush or the kitchen tap spout water.
> Ah, you'll start thinking that those who find find syntax arcane are
> jackass... You need a little to realize it was not this easy in the
> beginning. The dark side of power.
Once you start down the dark path, forever will it dominate your
destiny. Don't underestimate the power of the dark side!
On Wed, 27 Jun 2007 11:04:39 -0000, Twisted <··········@gmail.com> tried to
confuse everyone with this message:
>
>> With a PS file you can do just one thing, execute it. It's a program,
>> did you know ?
>
>For which you need an interpreter. Such as Ghostscript. Which is a
>pain to install and a bigger one to configure, even on Windoze.
>
Lie. Ghostscript works out of the box on Windows.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
On Jun 27, 8:26 am, ····@mail.ru (Timofei Shatrov) wrote:
> >For which you need an interpreter. Such as Ghostscript. Which is a
> >pain to install and a bigger one to configure, even on Windoze.
>
> Lie. Ghostscript works out of the box on Windows.
You're joking. First of all I am not a liar, and secondly, Ghostscript
and Ghostview are tricky to set up correctly. I know -- I've done it a
time or three. There's an arcane GUI configurator that isn't
exceptionally well designed, and once it's working it still wonks out
on maybe 1 in 10 .ps and .eps files you come across ... which is still
better than being able to view none of them, mind you. Nonetheless
there's a world of difference between the GS tools and say Adobe
Acrobat Reader in terms of setup and use; the latter you just run an
installer and then find a pdf to double-click; no other steps
necessary and it works every time. Of course, Adobe stuff is
proprietary, and acrord supports some types of evil DRM...
Twisted <··········@gmail.com> writes:
> On Jun 27, 8:26 am, ····@mail.ru (Timofei Shatrov) wrote:
>> >For which you need an interpreter. Such as Ghostscript. Which is a
>> >pain to install and a bigger one to configure, even on Windoze.
>>
>> Lie. Ghostscript works out of the box on Windows.
>
> You're joking. First of all I am not a liar, and secondly, Ghostscript
> and Ghostview are tricky to set up correctly. I know -- I've done it a
> time or three. There's an arcane GUI configurator that isn't
> exceptionally well designed, and once it's working it still wonks out
> on maybe 1 in 10 .ps and .eps files you come across ...
It's become clear that you have a different conception of what
consitutes "working" software.
> better than being able to view none of them, mind you. Nonetheless
> there's a world of difference between the GS tools and say Adobe
> Acrobat Reader in terms of setup and use; the latter you just run an
> installer and then find a pdf to double-click; no other steps
> necessary and it works every time. Of course, Adobe stuff is
> proprietary, and acrord supports some types of evil DRM...
It's also become clear that you have a different conception of what
constitutes using a computer.
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
*Joel's guide to sending attachments:
1. put all the files you want to send in a folder and archive the
folder using tar, then compress it with gzip or bzip2
2. please send me .pdf, .html, or text in place of Word documents:
http://www.gnu.org/philosophy/sylvester-response.html
*Did you know there's a FREE alternative to using word processors?
http://www.edafe.org/latex/
http://en.wikipedia.org/wiki/LaTeX
http://nitens.org/taraborelli/latex
Twisted <··········@gmail.com> wrote:
>
>On Jun 27, 8:26 am, ····@mail.ru (Timofei Shatrov) wrote:
>>
>> Lie. Ghostscript works out of the box on Windows.
>
>You're joking. First of all I am not a liar, and secondly, Ghostscript
>and Ghostview are tricky to set up correctly. I know -- I've done it a
>time or three. There's an arcane GUI configurator that isn't
>exceptionally well designed, and once it's working it still wonks out
>on maybe 1 in 10 .ps and .eps files you come across ...
You must have installed Ghostscript last in 1998. The current installer is
as painless as most open source installers are.
--
Tim Roberts, ····@probo.com
Providenza & Boekelheide, Inc.
From: Gian Uberto Lauri
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <874pkt1tp5.fsf@mail.eng.it>
>>>>> Long count = 12.19.14.7.16; tzolkin = 2 Cib; haab = 4 Tzec.
>>>>> I get words from the Allmighty Great Gnus that
>>>>> "T" == Twisted <··········@gmail.com> writes:
T> On Jun 27, 4:18 am, Gian Uberto Lauri <····@spammer.impiccati.it>
T> wrote:
T> [A very long, rambling, semi-coherent post]
>> Strange. I am *NOT* a native english speaker and I think my
>> Q.I. tends toward average from below...
T> That much is obvious.
So, did they never tell you "never argue with a fool, people could
misjudge who the fool is" ? And you stille replied to my post ?
--
/\ ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
//--\| | \| | Integralista GNUslamico
\/ e coltivatore diretto di Software
A Cesare avrei detto di scrivermi a ·····@rat.vg
From: Andreas Eder
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <86zm2ka0q5.fsf@eder.homelinux.net>
Hi Twisted,
>>>>> "Twisted" == Twisted <··········@gmail.com> writes:
Twisted> Let me get this straight.
Twisted> In this corner, we have just about every Windows application ever
Twisted> developed. When a user needs help, a click on the "help" menu or tap
Twisted> of the F1 key is all it takes to obtain some. Sometimes the help is
Twisted> not of the greatest quality, but that is another issue we won't
Twisted> concern ourselves with here.
Almost always when I really needed help in Windows, all it said
was: go ask your system administrator. Really helpful :-(
Twisted> In the other corner, we have just about every Unix application ever
Twisted> developed. When a user needs help, they may do such things as manually
Twisted> explore the directories where the application was installed
Twisted> (equivalent to rooting around in C:\Program Files\Appname for .hlp
Twisted> files, because F1 didn't work and there was no "help" menu, if such a
Twisted> thing ever happened on Windoze).
Ever heard of man pages? and info?
'Andreas
--
Wherever I lay my .emacs, there's my $HOME.
From: ······@myrealbox.com
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <5efrrmF37rfioU1@mid.individual.net>
In article <··············@mail.eng.it>,
Gian Uberto Lauri <·····@spammer.impiccati.it> wrote:
> >>>>> "n" == nebulous99 <··········@gmail.com> writes:
>
> n> On Jun 22, 6:32 pm, Cor Gest <····@clsnet.nl> wrote:
> >> > HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO
> >> ENTER > THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT
> >> WOULD TELL > THEM THOSE ARE THE KEYS TO REACH THE HELP?!
> >>
> >> What's your problem ?
> >>
> >> Ofcourse a mere program-consumer would not look what was being
> >> installed on his/her system in the first place ... So after some
> >> trivial perusing what was installed and where : WOW Look, MA !
> >> .... it's all there!
> >>
> >> lpr /usr/local/share/emacs/21.3/etc/refcard.ps or your
> >> install-dir........^ ^ or your
> >> version.............................^
>
> n> So now we're expected to go on a filesystem fishing expedition
> n> instead of just hit F1? One small step (backwards) for a man; one
> n> giant leap (backwards) for mankind. :P
>
> Waring, possible ID TEN T detected!
>
> There's a program called find, not this intuitive but worth learning
>
> It could solve the problem from the root with something like
>
> find / -name refcard.ps -exec lpr {} \; 2> /dev/null
Let's not make this any worse than it has to be ....
If I wanted to find files that might have documentation on emacs,
I wouldn't look for filename refcard.ps; I'd try either
locate emacs
(Linux only AFAIK, won't find recently-added files because it
searches against a database usually rebuilt once a day)
or
find / -name "*emacs*"
You are so right that "find" is worth learning, but I'm not sure
it's a tool I'd have mentioned in this particular discussion,
because it *does* take a bit of learning. I wasn't surprised at
all that you got the reply you did. :-)?
And as you mention downthread, any time you use "find" to execute
a command that might be costly (in terms of paper and ink in this
case), it's smart to first do a dry run to be sure the files it's
going to operate on are the ones you meant.
Whether "find" is better or worse than the GUI-based thing Windows
provides for searching for files .... I guess this is really
not the time or place to rant about the puppy, is it? (Yes,
I know you can make the animated character go away, something I
discovered just in time to avoid -- well, I'm not sure, but it
wouldn't have been good.)
[ snip ]
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <85odj7b07u.fsf@lola.goethe.zz>
Twisted <··········@gmail.com> writes:
> HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER
> THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD
> TELL THEM THOSE ARE THE KEYS TO REACH THE HELP?!
Because there is a menu called "HELP" and because the "standard"
keybinding for help, f1, brings up help?
Not to mention that there is an initial splash screen pointing this
out?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <85vedfgl4v.fsf@lola.goethe.zz>
Twisted <··········@gmail.com> writes:
> HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER
> THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD
> TELL THEM THOSE ARE THE KEYS TO REACH THE HELP?!
Because there is a menu called "HELP" and because the "standard"
keybinding for help, f1, brings up help? And because there is that
standard GNOME icon of a lifesaver which you can click?
Not to mention that there is an initial splash screen pointing most of
this out?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Robert Uhl
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3tzsy18m7.fsf@latakia.dyndns.org>
Twisted <··········@gmail.com> writes:
>
> HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER
> THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD TELL
> THEM THOSE ARE THE KEYS TO REACH THE HELP?!
Because WHEN YOU START EMACS IT DISPLAYS A MESSAGE TELLING YOU HOW TO
GET TO THE TUTORIAL. ONCE YOU'VE FOLLOWED THE TUTORIAL YOU KNOW
EVERYTHING YOU NEED TO KNOW.
If you had ever actually run emacs you'd know this.
> Of course, Notepad is so easy to use it doesn't even need help,
> despite which it's readily available. In case you forgot the bog-
> standard (and therefore it IS self-evident) "F1" there's even a "Help"
> menu in plain view as soon as you open a Notepad.
Any modern emacs comes with F1 configured to start the help system too.
Wow!
> [remainder snipped, apparently describing some piece of software that
> presents you automatically with an emacs tutorial if you start emacs
> while it's running. I've seen emacs a few times in my day but never
> whatever unnamed piece of software is being referred to here...
The message about the tutorial is displayed by a piece of software
called 'emacs.' It's the piece of software we've talking about this
entire time. It does this every time you start it. Every single time.
Without fail. Of course, if you somehow missed it, you could also go to
the menu titled, helpfully, 'Help'; the first item therein is 'Emacs
tutorial'; the second is 'Emacs tutorial (choose language).'
If you had ever actually run emacs you'd know this.
Do you think that Mercedes are awful cars because their engines don't
start when you turn the key in the ignition? Do you think homemade
burgers are disgusting because cheese doesn't melt on them?
--
Robert Uhl <http://public.xdi.org/=ruhl>
Using SWITCHAR in MS-DOS 2.0 was a kludge on top of a kludge, back in
the days before Microsoft kludge-stacking turned the OS into a game of
Jenga played with sweating dynamite sticks. --Steve VanDevender
From: Giorgos Keramidas
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <877iprhos9.fsf@kobe.laptop>
On Fri, 22 Jun 2007 21:51:34 -0000, Twisted <··········@gmail.com> wrote:
>> C-h i, C-x b RET is non-trivial?!?
[...]
> I'm sorry. I don't speak Chinese.
>
> I trust I've made my point. Not only does it insist you learn a whole
> other language (though I'm guessing it's not actually Chinese --
> Greek, maybe), even when you know that's a bunch of keystrokes and
> even what they are...
>
> HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER
> THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD TELL
> THEM THOSE ARE THE KEYS TO REACH THE HELP?!
No it's not Greek. I can assure you it isn't, because I *am* Greek.
Now, regarding your shouting about the keys, have you tried using a
recent GNU Emacs installation? The first thing that pops up when a new
user runs Emacs looks like this:
,-----------------------------------------------------------------------
| Welcome to GNU Emacs, a part of the GNU operating system.
|
| Type C-l to begin editing.
|
| Get help C-h (Hold down CTRL and press h)
| Emacs manual C-h r
| Emacs tutorial C-h t Undo changes C-x u
| Buy manuals C-h C-m Exit Emacs C-x C-c
| Browse manuals C-h i
| Activate menubar F10 or ESC ` or M-`
| (`C-' means use the CTRL key. `M-' means use the Meta (or Alt) key.
| If you have no Meta key, you may instead type ESC followed by the character.)
|
| GNU Emacs 22.1.50.2 (i386-unknown-freebsd7.0, X toolkit)
| of 2007-05-29 on kobe
| Copyright (C) 2007 Free Software Foundation, Inc.
|
| GNU Emacs comes with ABSOLUTELY NO WARRANTY; type C-h C-w for full details.
| Emacs is Free Software--Free as in Freedom--so you can redistribute copies
| of Emacs and modify it; type C-h C-c to see the conditions.
| Type C-h C-d for information on getting the latest version.
`-----------------------------------------------------------------------
Basic reading skills are necessary to parse this 'splash' screen, but it
shouldn't be too hard to read a few lines of text which guide you about
the proper key sequence to reach the tutorial, right?
> Of course, Notepad is so easy to use it doesn't even need help,
> despite which it's readily available. In case you forgot the bog-
> standard (and therefore it IS self-evident) "F1" there's even a "Help"
> menu in plain view as soon as you open a Notepad.
There's also a "Help" menu in plain sight when you fire up Emacs with an
X11 interface. I don't see why Notepad is special in any way here.
> This is the lowly Notepad, which I'll freely admit is the rusty
> bicycle of text editors, and it's much easier to use (including the
> help) than the supposed Mercedes-Benz of editors.
Isn't this always the case? The 'interface' of a tiny bicycle is
something which even very young kids can master pretty fast. On the
other hand, I'm relatively sure there's at least one valid reason we
don't let pre-school aged children drive around Mercedes-Benz cars,
isn't there?
On Jun 25, 2:28 pm, Giorgos Keramidas <········@ceid.upatras.gr>
wrote:
> > This is the lowly Notepad, which I'll freely admit is the rusty
> > bicycle of text editors, and it's much easier to use (including the
> > help) than the supposed Mercedes-Benz of editors.
>
> Isn't this always the case? The 'interface' of a tiny bicycle is
> something which even very young kids can master pretty fast. On the
> other hand, I'm relatively sure there's at least one valid reason we
> don't let pre-school aged children drive around Mercedes-Benz cars,
> isn't there?
And the myth of the bicycle being easy to learn persists. Did you know
that kids learn better than adults do? Why do kids pick up at least
one language without any conscious effort, while adults trying to
learn one more often struggle in night school?
I know people who find all kinds of vehicles easy to learn but never
mastered a bicycle (despite trying). People, plural, as in more than
one of them.
Anyway, I know which comes with a fatter manual -- the Benz...
From: Gian Uberto Lauri
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <87myync95b.fsf@mail.eng.it>
>>>>> Long count = 12.19.14.7.15; tzolkin = 1 Men; haab = 3 Tzec.
>>>>> I get words from the Allmighty Great Gnus that
>>>>> "T" == Twisted <··········@gmail.com> writes:
T> And the myth of the bicycle being easy to learn persists. Did you
T> know that kids learn better than adults do? Why do kids pick up at
T> least one language without any conscious effort, while adults
T> trying to learn one more often struggle in night school?
Mostly because they block themselves with strange fears and due bad
teaching, the "fear" of a test, the lack of fun, the "constriction",
all block adults learning new language.
Pick an over 30, overloaded with (often) frustrating work, and give
her an university level course in languages with grammars and/or
alphabets completly different from those she uses (yesss, I am
thinking of a woman, my wife...) like Arab (alphabet and some grammar)
and Turkish (its grammar sound lispish to my ears), and she'll go
ahead without "fatigue" and with flying colours.
Children pick up other language without any conscious effort because
either they learn it by using with parents, relatives and friends or
they are involved in a game-like style of learning.
Why else hacker prize fun this much ? :) :)
T> I know people who find all kinds of vehicles easy to learn but
T> never mastered a bicycle (despite trying). People, plural, as in
T> more than one of them.
Again, fear, or maybe, some malfunction in the balancing organs. But
fear mainly. You do not see what keeps a bike upright and running, you
have to trust that you can.
You can walk on a 4 inch wide stripe on a floor without problems, but
when it is a 4 inch wide bar some feet over the floor...
--
/\ ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
//--\| | \| | Integralista GNUslamico
\/ e coltivatore diretto di Software
A Cesare avrei detto di scrivermi a ·····@rat.vg
On Jun 26, 6:17 am, Gian Uberto Lauri <····@spammer.impiccati.it>
wrote:
> Children pick up other language without any conscious effort because
> either they learn it by using with parents, relatives and friends or
> they are involved in a game-like style of learning.
Actually, it's proven that there's a critical period for language
learning "coming naturally" that ends around age seven. Children
actually have enhanced learning abilities due to brain physiology and
plasticity.
> T> I know people who find all kinds of vehicles easy to learn but
> T> never mastered a bicycle (despite trying). People, plural, as in
> T> more than one of them.
>
> Again, fear, or maybe, some malfunction in the balancing organs. But
> fear mainly. You do not see what keeps a bike upright and running, you
> have to trust that you can.
Oh, come off it. One of those people is a physics professor, who knows
the mechanics of gyroscopic stability and things of that nature
backwards and forwards. And his sense of balance is fine -- he has no
trouble with that except when he's quite drunk. He told me the problem
was the bike tipping over before it could get up enough speed to
become stable. My own guess being there's a "knack" you may or may not
eventually get, for getting past that initial hurdle and getting it up
to speed when it becomes stable.
Of course, this "knack" isn't something found in any instruction
manual. I'm wondering if getting your head around unix arcana is also
dependent on an iffy "knack" where you "get it" and somehow know where
to look for documentation and problem fixes, despite everything having
its own idiosyncratic way, and "get" some sort of workflow trick
going, or you don't. Personally, the thing I always found most
irritating was the necessary frequent trips to the help. Even when the
help was easy to use (itself rare) that's a load of additional task
switching and crap. Of course, lots of the time the help was not easy
to use. Man pages and anything else viewed on a console, for example
-- generally you could not view it side by side with your work, but
instead interrupt the work, view it, try to memorize the one next
step, go back to your work, perform that next step, back to the help
to memorize another step ... that has all the workflow of a backed-up
sewer, yet until and unless the commands become second nature it's
what you're typically forced to do without a proper GUI. Navigating
also being a pain -- generally it's easy to get it to scroll down, or
exit; hard but usually possible to scroll up in case you overshoot;
and there's some arcane search capability, but it isn't
straightforward to use so you can't use it because you'd need to be
open to the help for the help viewer or other tool instead of the help
you're trying to search, and then your search would come up empty. The
searching-help instructions not being in the same help file as the
target of your search proves to be the final straw, and you throw up
your hands in disgust after going a few rounds with "thetool", "man
thetool", and "man man" and make an inch of progress in an hour, most
of it spent on typing, scrolling, or memorizing rather than on working
with "thetool".
Maybe the thing I really, REALLY deplore is simply having 99% of my
attention forced to deal with the mechanics of the job and the
mechanics of the help viewer and only 1% with the actual content of
the job, instead of the other way around.
On 2007-06-27, Twisted <··········@gmail.com> wrote:
> irritating was the necessary frequent trips to the help. Even when the
> help was easy to use (itself rare) that's a load of additional task
> switching and crap. Of course, lots of the time the help was not easy
> to use. Man pages and anything else viewed on a console, for example
On the plus side, you only have to learn it once. With new releases
of Windows/Office, more often than not, Bill n' The Boys rename
functions and hide them somewhere else in an attempt to make it look
like they actually did something, so you end up wasting a lot of time
relearning what you already knew. Talk about irritating!
nb
From: ······@myrealbox.com
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <5efqclF37fmubU1@mid.individual.net>
In article <························@w5g2000hsg.googlegroups.com>,
Twisted <··········@gmail.com> wrote:
[ snip ]
> I'm wondering if getting your head around unix arcana is also
> dependent on an iffy "knack" where you "get it" and somehow know where
> to look for documentation and problem fixes, despite everything having
> its own idiosyncratic way, and "get" some sort of workflow trick
> going, or you don't.
Well .... For me I think the crucial thing was having Unix experts
on tap when I was learning -- someone to answer my questions
patiently, and also to show me things I might not have found on
my own. Some combination of Usenet groups and books might have
served the same purpose.
I find Windows and its tools as frustrating as you seem to find
Unix, but I strongly suspect that being shown the ropes by someone
who understands and likes the system would help a lot. <shrug>
> Personally, the thing I always found most
> irritating was the necessary frequent trips to the help. Even when the
> help was easy to use (itself rare) that's a load of additional task
> switching and crap. Of course, lots of the time the help was not easy
> to use. Man pages and anything else viewed on a console, for example
> -- generally you could not view it side by side with your work, but
> instead interrupt the work, view it, try to memorize the one next
> step, go back to your work, perform that next step, back to the help
> to memorize another step ... that has all the workflow of a backed-up
> sewer, yet until and unless the commands become second nature it's
> what you're typically forced to do without a proper GUI.
[ I'm trying to imagine circumstances in which I would say "proper
GUI" and .... not succeeding. "Proper command line", now that
I say sometimes .... :-)? ]
About not being able to view help side by side with one's work,
though .... You probably haven't heard the joke about how a
window manager is a mechanism for having multiple xterms (terminal
windows) on the screen at the same time, and a mouse is a device
for selecting which one should have the focus? Well, I like it.
[ snip ]
> Maybe the thing I really, REALLY deplore is simply having 99% of my
> attention forced to deal with the mechanics of the job and the
> mechanics of the help viewer and only 1% with the actual content of
> the job, instead of the other way around.
Exactly my experience of trying to use MS Office tools to do quick
edits under time pressure.
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
······@myrealbox.com <······@myrealbox.com> writes:
> I find Windows and its tools as frustrating as you seem to find
> Unix, but I strongly suspect that being shown the ropes by someone
> who understands and likes the system would help a lot. <shrug>
I feel the same way about Windows being frustrating, however I find
that having a Windows "expert" around helps very little. Heck, *I*
was a Windows expert for as long as I was using it. I always found it
to be totally opaque. It always seemed like the only way to make
things work was to BUY something --- something that really offended
me. It became clear to me quickly that Windows is basically a
billboard on a CRT --- the help files only told me to buy stuff, or
how "fun and easy" it was to do something, without actually saying how
to do it. When I got XP and wanted to change my desktop theme ---
guess what? They decided to start charging for that too.
With Windows I never got it; with Unix of any kind (linux, SunOS,
etc), I have felt like I got it right away.
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
*Joel's guide to sending attachments:
1. put all the files you want to send in a folder and archive the
folder using tar, then compress it with gzip or bzip2
2. please send me .pdf, .html, or text in place of Word documents:
http://www.gnu.org/philosophy/sylvester-response.html
*Did you know there's a FREE alternative to using word processors?
http://www.edafe.org/latex/
http://en.wikipedia.org/wiki/LaTeX
http://nitens.org/taraborelli/latex
On 2007-06-25, Giorgos Keramidas <········@ceid.upatras.gr> wrote:
> X11 interface. I don't see why Notepad is special in any way here.
It's not. I discovered, quite by accident, wordpad is the superior
text editor in windows. It even properly formats those cryptic brag
pages crackers put in cracked software.
nb
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3y7id9x7i.fsf@borud.not>
[Twisted <··········@gmail.com>]
|
| Being beginner-friendly doesn't have to be at the expense of power or
| expert-user usability.
depends on your definition of "expert". :-)
| On the other hand, being actively beginner-hostile leads to nobody
| adopting the tool. Then again, if you don't mind being the last
| generation that'll ever use it, then I guess you're okay with that.
obviously I lie awake dreading the day this happens. on my tombstone
will say "here lies the last Emacs user on earth. M-x rip".
-Bj�rn
From: Giorgos Keramidas
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <87tzt01056.fsf@kobe.laptop>
On 21 Jun 2007 16:52:17 +0200, Bjorn Borud <··········@borud.no> wrote:
> on my tombstone will say
> "here lies the last Emacs user on earth. M-x rip".
Hahaha! Very good one :-)
On Jun 21, 10:52 am, Bjorn Borud <··········@borud.no> wrote:
> [Twisted <··········@gmail.com>]
> |
> | Being beginner-friendly doesn't have to be at the expense of power or
> | expert-user usability.
>
> depends on your definition of "expert". :-)
Well, admittedly, if your definition of "expert" is "elitist pig who
considers beginner-hostileness itself to be a required feature in
order for him to regard the software as usable", then you may be
right.
That sort of negative-sum thinking is alien to me. Software being easy
for beginners to get started using does not in and of itself detract
from its value to expert users. Only if they "value" such perverse
things as "being one of the exclusive club that can actually manage to
use this thing" does any of this make sense. That's a form of
artificial scarcity, and as I think I've mentioned before, artificial
scarcity is one of the more major roots of evil.
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3myyqbr6n.fsf@borud.not>
[Twisted <··········@gmail.com>]
|
| That sort of negative-sum thinking is alien to me. Software being easy
| for beginners to get started using does not in and of itself detract
| from its value to expert users.
the fact that you imply that this is my argument tells me that either
you have not paid attention, or you have a raging inferiority complex.
given the sum of your postings so far I'd say that you neither are,
nor consider yourself, a cerebral sort of person, so this narrows it
down somewhat (although not to the exclusion of you not having paid
attention).
-Bj�
On Jun 23, 11:56 am, Bjorn Borud <··········@borud.no> wrote:
> [Twisted <··········@gmail.com>]
> |
> | That sort of negative-sum thinking is alien to me. Software being easy
> | for beginners to get started using does not in and of itself detract
> | from its value to expert users.
>
> the fact that you imply that this is my argument tells me that either
> you have not paid attention, or you have a raging inferiority complex.
> given the sum of your postings so far I'd say that you neither are,
> nor consider yourself, a cerebral sort of person, so this narrows it
> down somewhat (although not to the exclusion of you not having paid
> attention).
That ... makes no sense. Sorry. Previously, I said:
> Being beginner-friendly doesn't have to be at the expense of power or
> expert-user usability
and you said that depended on the definition of "expert". Apparently
you believe there is a type of "expert" for whom beginner-friendly
software is intrinsically less usable than beginner-hostile software.
Given that beginner-friendliness does not preclude any kind of expert
level functionality being available (consider something configurable
enough that an advanced user can start it up and open an advanced-uses
window and immediately do advanced stuff, and a real expert can make
it start up with that window already open and focused by default), it
follows that these experts' perceptions of decreased usability are a
psychological result of simply knowing beginners can easily become
proficient in using basic functions of the software in question,
rather than a material result of some compromise necessarily made in
the software's design, as there is no such compromise that can't in
practise be avoided.
An expert who feels software is less suitable for his use *purely*
because the unwashed masses can actually use it to accomplish
something is quite obviously some type of elitist jerk.
I rest my case.
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m3ejjyu4vl.fsf@borud.not>
[Twisted <··········@gmail.com>]
|
| and you said that depended on the definition of "expert". Apparently
| you believe there is a type of "expert" for whom beginner-friendly
| software is intrinsically less usable than beginner-hostile
| software.
no, I was alluding to you thinking that posession of knowledge which
is considered rudimentary basics for Emacs somehow elevates the person
in question to an "expert". just because you have not, by your own
admission, been able to even locate the built-in tutorial, I don't
think your definition of "expert" is very relevant.
-Bj�
From: David Kastrup
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <86tzsurbjt.fsf@lola.quinscape.zz>
Bjorn Borud <··········@borud.no> writes:
> [Twisted <··········@gmail.com>]
> |
> | and you said that depended on the definition of "expert". Apparently
> | you believe there is a type of "expert" for whom beginner-friendly
> | software is intrinsically less usable than beginner-hostile
> | software.
>
> no, I was alluding to you thinking that posession of knowledge which
> is considered rudimentary basics for Emacs somehow elevates the person
> in question to an "expert". just because you have not, by your own
> admission, been able to even locate the built-in tutorial, I don't
> think your definition of "expert" is very relevant.
Since he did not ever download a copy of Emacs in the last 10 years
(and won't according to his own statements download anything or look
at any web page because his computer incompetency makes him incapable
of avoiding or detecting viruses) one can hardly blame him for not
finding the tutorial in software he did not download.
--
David Kastrup
From: ······@myrealbox.com
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <5e5tf4F30n9e0U1@mid.individual.net>
In article <··············@borud.not>,
Bjorn Borud <··········@borud.no> wrote:
> [Giorgos Keramidas <········@ceid.upatras.gr>]
> |
> | Educating the user to avoid confusion in this and other cases of made
> | up, 'user-friendly' descriptions is not a good enough answer.
>
> there are two types of "user friendly". there's "user friendly" and
> then there is "beginner friendly" which is often mislabeled. the
> latter is more important for applications which are to be used
> casually. like utilities you only use once or twice per year -- those
> need to be "beginner friendly".
Maybe this is an okay point at which to mention one of my favorite
bits of commentary on this subject. It's an interview with Leslie
Lamport (originator of LaTeX, among other things) in which he
talks about the needs of beginners versus the needs of experts,
and how the latter are often neglected:
http://research.microsoft.com/users/lamport/pubs/lamport-latex-interview.pdf
(Yes, he works (worked? but this seems current) for Microsoft.
Astonishing.)
Asked whether whether LaTeX is hard to use, he replies "It's easy
to use -- if you're one of the 2% of the population who thinks
logically and can read an instruction manual. [otherwise not]"
> for applications you are likely to use for prolonged periods of time
> (like programming, video editing, music production etc), it does not
> make sense to optimize for "beginner friendly". at least not at the
> cost of making the application less "user friendly".
>
> applications you spend a lot of time using are worth an investment in
> learning how to use them. what creates friction in an application you
> know reasonably well is when common tasks are fiddly. for instance,
> while menus are often good for casual use and lower the initial
> threshold for absolute beginners, depending heavily on menu navigation
> becomes too fiddly if you are performing a certain task 2-3 times per
> minute. it is not _user_ friendly.
Sing it, brother.
(I'm a vim fan myself, but my thinking is that these days emacs
and vi(m) people should be banding together against a common enemy
rather than carrying on the fine old tradition of arguing with
each other. We have in common a preference, maybe, for learning
one editor really well and using it for everything.)
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
From: Bjorn Borud
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Date:
Message-ID: <m37ipylsfj.fsf@borud.not>
[Xah Lee <···@xahlee.org>]
to be quite honest, your proposal seems to largely be based on
ignorance.
| A: 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, a programer �bind� a
| keystroke to a command in a software application. The term �buffer�
| refers to a abstract, temporary area for storing data, in the context
| of programing or computer science.
the term "buffer" is used extensively outside the computer science
domain, so it is not a CS only term. in an editor it is actually a
quite sensible name since it abstracts things a bit. for instance a
buffer need not be associated with a file. nor does it make any
assumptions about the way it is displayed (as opposed to "window" or
"tab").
| These terms are irrelevant to the users of a software application.
they are very relevant to me, and I am very much a user of Emacs. and
again, they provide good abstractions.
| As a user of a text editor, he works with files.
learn Emacs before you criticize it. your assumption is wrong. in
emacs you work on _buffers_. buffers often do not have files
associated with them.
| The terms �opened file� or �untitled file� are more appropriate than
| �buffer�. Since emacs is also used for many things beside reading
| files or writing to files, for example, file management, ftp/sftp,
| shell, email, irc etc., the proper term can be �panel�, �window�, or
| �work area�.
"panel" and "window" refer to UI-elements. the buffer concept does
not map 1:1 to any of these. substituting "work area" for "buffer"
doesn't seem like a better abstraction. especially not if you see it
in the context of how Emacs relates to buffer contents.
| 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�.
why? if anything the term "shortcut" seems to imply that there is a
primary route to executing the function in question -- which more
often than not isn't the case. "keybinding" is a more precise term.
| Although concepts like �buffer� and �keybinding� are seemingly
| interchangeable with �panel� or �keyboard shortcut�, but their
| contexts set them apart.
they are interchangeable only if you have no idea what you are talking
about. you obviously have not bothered to have a proper look at Emacs
and think these things through properly.
| This is why in all modern software application's user
| documentations, terms like �buffer� or �keybinding� are not to be
| seen but �windows, panes, and keyboard shortcuts�.
most "modern" editors are built on different premises than Emacs and
many have a far simpler view of the world. extremely few of them even
come close to Emacs in defining what is in practice an operating
environment for applications. it makes sense to refer to "windows"
when in fact you are referring to windows. it doesn't make sense to
call buffers "windows" in Emacs; because they are not.
| The reason emacs uses the technical terminologies throughout is
| because when emacs started in the 1970s, there really isn't any other
| text editors or even software applications.
the abstractions you mention are sensible ones independently of when
they were concieved. just because other people came along later and
used different abstractions, doesn't mean that the ones used in Emacs
are wrong, inferior or inappropriate. if you had bothered to
understand Emacs properly, you would have found that some of the
abstractions used make a lot of sense in an editor.
| Changes in society are always resisted by old timers, but it is also a
| main element behind progress.
I've been in the computer industry long enough to have seen quite a
few cycles of re-invention. each cycle you learn something about
which inventions were good and which were bad. a common thread if you
look at the survival rate of products and ideas is that it isn't
always the best product or idea that wins.
often something new comes along to replace something old. sometimes
it is better than what you had before, but often it is not really
better, just different.
a good example is the web and the applications we implement in terms
of the web. take forums for instance. in a strict technical sense,
web-based forums are inferior to NNTP-based forums. (I am sure you can
make the comparison yourself). yet NNTP-based discussion is not
growing at the same rate as web forums. the net has chosen its
preferred technology, and it wasn't because the web-based discussion
forums were so much more technically refined that the majority chose
them.
for my uses, web forums are a huge step back from NNTP.
| This terminology issue may seem trivial, but its importance lies in
| making emacs palpable to the vast number of people who ever need to
| use a computer to write.
why? Emacs is a tool. if you don't like it: use something else. it
is that simple.
-Bj�rn
Here are some Frequently Asked Questions about The Modernization of
Emacs.
They are slightly lengthy, so i've separated each item per post. The
whole article can be found at
http://xahlee.org/emacs/modernization.html
------------
Q: Why should emacs want to be popular and why should emacs change to
conform the majority? We don't want emacs to be popular. We want
people to adopt emacs, not emacs adopting people.
A: This attitude has plagued unix and computer geekers for decades. In
the early 1990s (DOS and unix), tech geekers would sneer at graphical
menus and mouse, with hordes of reasons how pure text interface, the
command line, and or keyboard operations are sufficient and superior
than graphical user interface or using a mouse. This seems ridiculous
today, but such online forum messages are common.
The reason for these type of attitude, is almost never a sensible
alternative view about the topic in discussion, but a show of machismo
and superiority complex. (perhaps more than 95% of online computing
forum users are males, and majority of them are aged under 25.) The
person who utters such opinion, made sure in the way he writes that he
is a expert in the “more difficult to use” method or tools and would
prefer things not to be “dumbed down”.
It is silly to retort “Why should emacs want to be popular?”. It is
like asking “why do you want to live longer?” when someone is picky
about healthy food, or “why should you want to look beautiful?” when
someone dresses up. We want to improve software, not taking the
attitude of “we are more complex and unique and superior and we want
to keep dummies out”.
In software design, occasionally we are tied down with a design
decision, such that it has a popular vs elegant aspect. For example,
suppose we are designing a set of keyboard shortcuts for emacs and we
are faced the question of whether to keep the copy/paste/undo/open etc
with the conventional C/V/Z/O etc keystrokes. Or, we can choose to
sacrifice user's familiarity of conventions but obtain a keyboard
shortcut set that is in some way more consistent, extensible, or
otherwise technically better.
If a design decision comes down to a pure popularity vs elegance and
everything else equal, then the decision might be based on our
philosophical dispositions or the software creator's ultimate goal.
However, it is not proper to pigeon-hole design issues into popularity
vs elegance.
Xah
···@xahlee.org
∑ http://xahlee.org/
Here are some Frequently Asked Questions about The Modernization of
Emacs.
They are slightly lengthy, so i've separated each item per post. The
whole article can be found at
http://xahlee.org/emacs/modernization.html
------------
Q: Emacs's ways are technically superior. It should not change.
A: Emac's user interface, when compared to modern software
application's user interface, is complex and unusual, however, there's
no basis whatsoever of it being actually a superior design with
regards to any sensible metrics. (in fact, much of emacs's user
interface are due to historical reasons. That is, how computers are in
1980s.)
For example, let's consider emacs's system of keyboard shortcuts. For
a keyboard shortcut system, we might judge its quality based on
several aspects. Here are some examples of consideration:
* Is it easy to learn? (is it familiar to most people?)
* Is it easy to type? (is most frequently used commands easy to
type?)
* Is it easy to remember?
* Are more frequently used commands have the easier-to-type
shortcuts that less frequently used commands?
* Are most frequently used commands all have a keyboard shortcut?
* Can the shortcut system somehow be consistent and extensible to
cover other user defined shortcuts?
Emacs's keyboard shortcuts system, somewhat satisfies the last aspect,
but do very bad with respect to all the others. Emacs keyboard
shortcuts are perhaps one of the most difficult to learn among
software, and is also one of the most difficult to remember. The worst
aspect of emacs's keyboard shortcuts, is that it is ergonomically
painful. (Many emacs-using programer celebrities have injured their
hands with emacs. (e.g. Richard Stallman, Jamie Zawinski), and emacs's
Cntl-x keyboard and Meta-x combinations are most cited as the major
turn-off to potential users among programers)
Computer keyboard is a hardware interface, and the mapping of commands
to the key press combinations can be considered from a Operation
Research point of view. The keyboard hardware itself can be designed
with consideration of ergonomics (that's why we have split and curved
keyboards), but consideration of what functions to map to what key
presses is also non-trivial if the software has large number of
functions or if the software is mission critical. Think of it this
way, consider a airplane cockpit, filled with knobs, dials, buttons,
and switches. Now, if your job is to map the airplane control
functions to these switches, what are the things to consider for a
optimal map?
If we take careful consideration on creating a keyboard shortcut
system for emacs, it is actually easy to create a system that are
purely superior in some technical sense than the ad-hoc Emacs's ways.
Aside from keyboard shortcuts system, Emacs's other user interfaces
are also questionable. For example, one major aspect of emacs
operation is that it uses a single window for multiple purposes and
files. Emacs is this way not because of a design decision, but rather
due to historical reasons. Computer resources in the 1980s are very
limited. When emacs is around, graphical system of showing “windows”
is not practically available, and the emacs's method of using the
screen (the textual-based-monitor) for presenting multiple tasks
(“buffers”) is actually a very advanced user interface design not
available in software of that era. When graphical systems becomes
practical in the 1990s, drawing a window takes a lot memory, and
opening multiple windows is slow and inpractical.
Modern software interface (say, post 2000) usually uses one window per
file (or task), and or show a tab if multiple task is to be
represented in a single window. However, in general, emacs doesn't
provide the tabs visual clue and still remained its old way of using a
single window for all files and tasks as its standard operation. As
far as user interface design is considered per se with respect to
today's computing standards, the emacs's way is inferior because it is
less intuitive. Arguably, emacs's operation methods may be more
efficient for expert users. 20 years ago, efficiency for expert users
may out weight the ease of use for majority of average users. But in
today computing era, computers are standard tools in every household,
efficiency and ease of use for general users is as important for
professional users. Even for professional users, it is openly
questionable that emacs's ways of operation induced by its default
user interface allows faster or more efficient operation than a user
interface based on modern software conventions.
Xah
···@xahlee.org
∑ http://xahlee.org/
Here are some Frequently Asked Questions about The Modernization of
Emacs.
They are slightly lengthy, so i've separated each item per post. The
whole article can be found at
http://xahlee.org/emacs/modernization.html
------------
Q: Aquamacs already does what you want.
A: Aquamacs is a emacs variant based on emacs, for Apple's Macintosh
computers, created in about 2004 by David Reitter. Aquamacs modifies
emacs so that its user interface follows modern (Mac OS X)
conventions. For example, copy, paste, undo shortcuts are cmd-c, cmd-
v, cmd-z. Open file is cmd-o, saving is cmd-s. Close window is cmd-w.
There is a redo command by default, with shortcut cmd-shift-z. By
following a modern user interface, almost all points mentioned in this
article are fixed in Aquamacs. For more info, see: Wikipedia Aquamacs↗
and Aquamac's home page at: Aquamacs.org ↗
As a emacs variant, it does help in spreading the idea that emacs user
interface should be modernized. However, a third-party variant
software is irrelevant to the modernization issue.
For example, suppose Microsoft Word remained with its DOS era command
line interface, for example, file is opened with [Esc] (to open the
menus), [T] (for Transfer), [L] (for Load). Suppose Microsoft hired a
third party to release a variant called MS AquaWord. This would not
help Microsoft Word the software itself, and is likely to complicate
the issue around Microsoft Word.
Xah
···@xahlee.org
∑ http://xahlee.org/
Why Emacs's Keyboard Shortcuts Are Painful
Xah Lee, 2007-07
A important aspect in designing keyboard shortcuts is to have keyboard
shortcuts for those most frequently used commands, and, the most
frequently used commands should have most easily-pressed keystrokes.
For example, they should be on the home row.
Emacs's keyboard shortcut set is very inefficient, largely because,
Emacs's keyboard shortcuts are designed with a keyboard that
practically has the Ctrl and Alt key positions swapped.
[image: Space Cadet keyboard]
above: The Space-cadet keyboard (Source↗, 2007-07) .
The common keyboard used around emacs era in the 1980s are those
keyboards from Lisp Machines↗. (see Space-cadet keyboard↗) The
keyboard on lisp machines have the Control key right besides the space
bar (similar to the position of Alt keys on PC keyboards), and Meta to
the left of Control. So, the Control key is right under the thumb, and
the Meta is secondary to Control. This is why, the shortcuts for the
most used commands in emacs involve the Control key instead of the
Meta key. (e.g. The cursor movements: C-p, C-n, C-f, C-b, C-a, C-e,
the cut/paste/undo C-w, C-y, C-/, the kill-line C-k, the mark C-SPC,
the search C-s.) Lisp Machine's keyboards fell out of use alone with
Lisp Machines. Since the 1990s, the IBM PC keyboard↗ (and its
decedents) becomes the most popular and is used by more than 99% of
personal computers today. The PC keyboard does not have Meta key but
have Alt instead, which is practically used as Meta for Emacs. The
Ctrl and Alt key's position are essentially swapped from the Control
and Meta on the Lisp Machine's keyboards. Emacs however, did not
change its keyboard shortcut set by switching the commands that are
mapped to the Control and Meta keys. This makes emacs keyboard
shortcuts very painful, and the frequent need to press the far-away
Control key makes the Emacs Pinky syndrome. (Many emacs-using
programer celebrities have injured their hands with emacs. (e.g.
Richard Stallman↗, Jamie Zawinski↗), and emacs's Ctrl and Meta
combinations are most cited as the major turn-off to potential users
among programers)
----------
This post is archived and updated at
http://xahlee.org/emacs/emacs_kb_shortcuts_pain.html
Xah
···@xahlee.org
∑ http://xahlee.org/
From: Alain Picard
Subject: Re: The Modernization of Emacs: keyboard shortcuts pain
Date:
Message-ID: <87lkd50wwh.fsf@memetrics.com>
[Note -- minimizing the cross posts to irrelevant groups]
Xah Lee <···@xahlee.org> writes:
> Why Emacs's Keyboard Shortcuts Are Painful
First of all, they're not called "shortcuts", they're
called "key bindings". And second of all: _are_ _they_ painful? :-)
> Emacs's keyboard shortcut set is very inefficient, largely because,
> Emacs's keyboard shortcuts are designed with a keyboard that
> practically has the Ctrl and Alt key positions swapped.
I remap the control key to where caps-lock mostly is (i.e. in the
vt-100 style position). I have been using emacs several hours a day
for, oh, 18 years now. I find the keyboard shortcut set to be
efficient and well designed. I'm sure I'm not alone amongst emacs
users to think so.
Now - remember: "Emacs is the extensible, CUSTOMIZABLE,
self-documenting real-time display editor." That means if you
think the keybindings are inefficient, change them.
[To the rest of the group: yes, I apologize for responding
to a well known troll. I just couldn't help myself. :-) ]
From: Kent M Pitman
Subject: Re: The Modernization of Emacs: keyboard shortcuts pain
Date:
Message-ID: <ur6mw9a1k.fsf@nhplace.com>
[ comp.lang.lisp only
http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
Alain Picard <············@memetrics.com> writes:
> Xah Lee <···@xahlee.org> writes:
>
> > Why Emacs's Keyboard Shortcuts Are Painful
> ...
> > Emacs's keyboard shortcut set is very inefficient, largely because,
> > Emacs's keyboard shortcuts are designed with a keyboard that
> > practically has the Ctrl and Alt key positions swapped.
> ...
> Now - remember: "Emacs is the extensible, CUSTOMIZABLE,
> self-documenting real-time display editor." That means if you
> think the keybindings are inefficient, change them.
Indeed. See particularly the second paragraph of my reply in:
http://groups.google.com/group/comp.lang.lisp/msg/31f3c0eab963b394
Xah Lee wrote:
�
Why Emacs's Keyboard Shortcuts Are Painful
http://xahlee.org/emacs/emacs_kb_shortcuts_pain.html
�
Alain Picard wrote:
�First of all, they're not called "shortcuts", they're called "key
bindings".�
"Keyboard Shortcuts", is the more well known and standard term.
"Keybindings", is almost unknown, except among Emacs users. The above
is the practical aspect. In a idealistic aspect, it is arguable that
the term "keyboard shortcuts" is better term too. For detailed
explaination about this issue, please see:
"The Modernization of Emacs", middle on "Q: The Terminology "buffer"
and "keybinding" is good as they are." at
http://xahlee.org/emacs/modernization.html
Xah wrote:
�Emacs's keyboard shortcut set is very inefficient...�
Alain wrote:
�I remap the control key to where caps-lock mostly is...�
This fix, while common, does not however fix the problem in any
satisfactory way for 2 reasons.
(1) It is still a key pressed by pinky, the least powerful and
flexible among the fingers. Further more, the particular movement is
difficult to execute and slow.
(2) The key does not come in pairs like other modifier keys. Pull out
one of the Shift key on your keyboard, and you'll realize why
frequently needed modifier keys comes in pairs.
A better remap solution for personal fix of this emacs problem, is to
switch the Alt and Ctrl keys.
Alain wrote:
�I have been using emacs several hours a day for, oh, 18 years now. I
find the keyboard shortcut set to be efficient and well designed.
[with the provision that the Ctrl key is situated to the left of the
key A] I'm sure I'm not alone amongst emacs users to think so.�
Whether Emacs keyboard shortcuts are well designed, can be assessed by
few methods:
(1) What the the common people think. (by statistical data, such as
surveys)
(2) How it scores using ergonomic criterions.
(3) By actual tests
For the common people's opinion, i think one widely cited reason
people don't like emacs is because its elaborate use of Ctrl, Meta
keys. Although this does not mean Emacs's shortcuts are not well
designed, but i think in fact it is the reason.
By ergonomic princiles, Emacs's keyboard shortcuts are not well
designed.
A simple method to realize that Emac's keyboard fails ergonomic
principles, is to note that the key choosen for a particular command,
is primarily based on the command name's first letter, not based on
the ease of operation of particular key.
For example, backward-char and backward-word, are two of the most
frequnetly used commands, and they are bind to shortcut combination
involving the key b. The keys b, on the QWERTY layout, involves using
the left hand's index finger to move to the middle of the keyboard. It
is one of the most costy key to press. (Emac's shortcuts set do not do
any better on Dvorak layout)
Asides from past statistical data and judgements based on ergonomic,
we can conduct actual tests. A practical way to carry this out, is to
have 2 groups of emacs users with at least 1 year of daily experience
and reasonably equal in touch typing skills. In one group, give them a
new keyboard shortcut set that has let's say the top 8 most frequently
used shortcuts remapped to the home row. Give them 3 monhts to get
used to this shortcut. Then, the 2 group can compete in editing tasks.
I assert that, Emacs's keyboard shortcuts are so ergonomically lousy,
to the degree that almost a random remap will have 50% chance being
more efficient in actual text editing tasks with it.
Further readings:
� Visual Map of Emacs's Default Keyboard Shortcuts
http://xahlee.org/emacs/emacs_kb_shortcuts.html
� Why Emacs's keyboard shortcuts are painful
http://xahlee.org/emacs/emacs_kb_shortcuts_pain.html
� How to avoid the Emacs Pinky problem
http://xahlee.org/emacs/emacs_pinky.html
� How to define keyboard shortcuts in emacs
http://xahlee.org/emacs/keyboard_shortcuts.html
� A Review of Microsoft Natural Keyboards
http://xahlee.org/Periodic_dosage_dir/t2/ms_keyboard.html
� Computer Keyboard Gallery and Ergonomics
http://xahlee.org/emacs/keyboards.html
Xah
···@xahlee.org
http://xahlee.org/
From: Matthias Buelow
Subject: Re: The Modernization of Emacs: keyboard shortcuts pain
Date:
Message-ID: <5gpqi9F3hs3uoU1@mid.dfncis.de>
In comp.lang.lisp Alain Picard <············@memetrics.com> wrote:
> I remap the control key to where caps-lock mostly is (i.e. in the
> vt-100 style position).
Just for the records... this can be achieved, for example, with
the following lines in .xmodmap (on X11/Unix):
remove Lock = Caps_Lock
keysym Caps_Lock = Control_L
add Control = Control_L
Some integrated GUIs like Gnome have a graphical tool to remap keys.
On Windows it's (as always) not directly supported and a pain to do but
possible through some arcane registry fiddling.
There's also Jamie Zawinski's fine xkeycaps tool for generating xmodmap
descriptions.
Here's my .Xmodmap:
========================================
clear lock
!move the control function to the caps lock key
keycode 66 = Control_L
!make the menu key the Caps_Lock key
keycode 117 = Caps_Lock
!move the menu function to the Left control key
keycode 37 = Menu
add lock = Caps_Lock
add control = Control_L
========================================
That remaps the control key to Caps Lock, and then switches Left
Control and the Menu key; so now Left Control is the Menu key and Menu
is Caps Lock (in terms of function). I changed this because I found
hitting Left Control to be far out of the way, and a lot of small
capitalized abbreviations are done only with my left hand. The only
problem with this is I hit the Menu key when I'm hitting the slash
key.
Joel
Matthias Buelow <···@incubus.de> writes:
> In comp.lang.lisp Alain Picard <············@memetrics.com> wrote:
>
>> I remap the control key to where caps-lock mostly is (i.e. in the
>> vt-100 style position).
>
> Just for the records... this can be achieved, for example, with
> the following lines in .xmodmap (on X11/Unix):
>
> remove Lock = Caps_Lock
> keysym Caps_Lock = Control_L
> add Control = Control_L
>
> Some integrated GUIs like Gnome have a graphical tool to remap keys.
> On Windows it's (as always) not directly supported and a pain to do but
> possible through some arcane registry fiddling.
>
> There's also Jamie Zawinski's fine xkeycaps tool for generating xmodmap
> descriptions.
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
http://www.gnu.org/philosophy/why-free.html
Xah Lee wrote:
�Why Emacs's Keyboard Shortcuts Are Painful
http://xahlee.org/emacs/emacs_kb_shortcuts_pain.html
�
Alain Picard wrote:
�... Now - remember: "Emacs is the extensible, CUSTOMIZABLE,
self-documenting real-time display editor." That means if you think
the keybindings are inefficient, change them. �
It is one thing to praise the software's merits, it's another to use
it as a quip as a execuse to nullify criticism or flaws.
A text editor software, by default, should at least have reasonable
keyboard shortcuts, regardless how users can or can not customize it.
As i indicated in the article, emacs keyboard shortcut set is the way
it is, is due to historical reasons, that it did not update with
changing keyboard hardware, and further, its is based on first letters
of commands and with little or no consideration of ergonomics.
A important aspect in designing a keyboard shortcut set, for a
application that has intensive, repetitive, prolonged human-machine
interaction (such as coding and text editing), is to consider
ergonomic principles. Specifically: allocate keyboard shortcuts for
the most frequently used commands, and, the top most frequently used
commands should have most easily-pressed keystrokes. For example, they
should be on the home row.
A long-time emacs user might think, "although your points seems valid,
but well i used emacs for over a decade, i never find any problems
with its shortcuts".
However, note that millions of people been using QWERTY for decades,
and vast majority never find a problem with it. Similarly, millions of
programers been coding C, C++, Java for years, they never find any
problems the lispers are saying about inexpressibility of these
languages.
The gist here is that, when a tool that practically works and is
widespread, it is difficult to see its flaws, even when presented with
a superior tool. For vast majority of professional programers, they
will not bother to look at lisp or functional programing languages.
They are doing "just fine" in their programing career. For vast
majority of computer keyboard users, they are not going to Switch to
Dvorak.
I assert, as i have in my previous articles, that emacs keyboard
shortcuts, is no better than a random shuffle of its keyboard
shortcuts, with respect to ergonomics or the efficiency (speed) it has
on the task of text editing.
The evidence i have presented on this is overwhelming (see references
below). Now, let us assume that it is true that emacs keyboard
shortcut set is one of the most worthless with respect to efficiency
and ergonomics. The question now is, what does this finding mean? What
do we learn from it? Or, what should emacs developers do, if anything?
I think there are few things worthy of note:
(1) No other major text editor software is any better at all.
(2) It doesn't matter that much. A FAR MORE importance issue related
to keyboarding ergonomics and efficiency, that has far more impact to
the world as well as emacs users, is the switch from QWERTY to Dvorak
keyboard layout.
Point (1) that "No other text editor software is any better at all."
is obvious. None of any text editors or word processors, actually goes
to ergonomic principles that far, to actually device keyboard
shortcuts based on finger positions.
They are quite reasonable too in the decision of not going that far.
In these editors, key-bound commands dedicated to text editing are
cursor movement commands of moving cursor to beginning/ending of char/
word/line/paragraph/screenful/file, and text changing commands of
select, copy, cut, undo and that's about it. (e.g. NotePad, WordPad,
Microsoft Word, SimpleText, TextEdit, BBEdit, Xcode). The text
selection operation is done with a mouse or shifted arrows keys. The
copy/cut/paste/undo are assigned to c/x/v/u keys with a modifier
(Control on Windows, Cmd on Mac). The cursor moving commands are
assigned to the arrow keys, backspace/delete keys, and or the Home/End/
PageUp/PageDown keys, possibly in combination with a modifier (Control/
Cmd/Alt). For text editing, these commands, together with mouse's
operations, seems sufficient in practice because the vast majority of
text-editing software (including word processors) employes no other.
The only major text editor that dedicate many more commands to
manipulate text, are vi and emacs. For example, in Emacs, besides the
common cursor moving commands of moving to beginning/ending of char/
word/line/paragraph/screenful/file", emacs also have moving by
sentence, recenter, move-to-window-line, tab-to-tab-stop, back-to-
indentation. But most importantly, all these commands has a keyboard
shortcuts on the alphanumeric main section of the keyboard, so users
do not have to move hands to the home/end/pageUp/pageDown section or
the arrow keys section. For commands that change text, common text
editor relies on just copy, cut, paste, and perhaps delete by word,
but emacs has "yank-pop (paste previous), mark-paragraph backward-kill-
word kill-word, kill-line, backward-kill-paragraph, kill-paragraph,
fill-paragraph, downcase-word/upcase-word (which are different than
the region version, which most editors have), transpose-chars,
transpose-words, indent-new-comment-line, zap-to-char, and all these
has a keyboard shortcut on the main section of the keyboard.
So, Emacs, in terms of the number of key-bound commands for cursor-
moving and text editing, is rather unique. The other major text editor
that dedicate a lot commands to moving cursor and editing text, is vi.
Vi uses a operation concept of command mode and editing mode, so is
not based on the normal concept of keyboard shortcuts of pressing
modifier key plus another key. (thus is not in the context of our
discussion about ergonomics keyboard shortcuts by key press
combinations. Its method of operation, with respect to efficiency of
text editing in comparison to emacs, is another subject matter. Its
keypress choice in the context of its modus operandi, with respect to
efficiency and ergonomics, in another subject matter.)
(Note here: although Emacs and vi are major text editors, but in terms
of actual, world wide, number of users in text editor market, they are
perhaps minor or trivial. With respect to all users of text editing
software (including word processors), emacs and vi together are
perhaps less that 1%. With respect to the market of text editors
(including IDEs such as Xcode, Visual Studio, Eclipse) used by IT
professionals (programers and sys admins), it is my guess that the
combined number of users of emacs and vi are less than 5%. The bizarre
popularity of vi and emacs, particularly in the phrase "vi vs emacs"
and its often irreverent discussion, is primarily a popularity of name
among tech geekers, a dead non-sequitor to kick up conversation or
break air. This misunderstanding of vi and emacs's actual market
penetration, as a piece of mis-information, is one of major damage in
spreading Emacs. (perhaps vi too, but personally don't care about
vi) )
In summary, Emacs is the only major editor that is unique in the way
it has a elaborate set of keyboard-bound, specialized cursor movement
and text editing commands. Now, taking this fact with respect to the
fact that emacs's keyboard shortcut set are grossly inefficient and
ergonomically painful, we can say that this flaw may practically be a
trivial, insignificant flaw, because, all other text editor for
programers doesn't even have such elaborate key-bound special commands
and in practice they work just fine. This seems to imply, that the
elaborate set of emacs's key-bound commands isn't that much important
for vast majority of text-editing tasks, consequently, emacs's
ergonomically painful shortcut set is moot.
However, note here that the fact remains, that emacs's keyboard
shortcut set are grossly inefficient and ergonomically painful. In the
general context of text editing and emacs using, it is insignificant
as explained above. But for those dedicate emacs users, many of which
have used emacs for years and wrote many elisp customization code, the
gross inefficiency of emacs's default keyboard shortcut can be a
significant issue. And for those emacs evangelizers who would like
see all programers use emacs, this is also a significant issue.
To these people, the question remains: should emacs change to fix this
keyboard-shortcut problem? Personally, i do not think so. For this
change, the primary consideration is cost and benefits. Emacs's
keyboard shortcuts has been rooted for 20+ years. Its shortcuts set
are firmly established in not just all emacs users, but as well as in
terminal applications (e.g. Bash) and many other applications have
adopted it too (e.g. Mathematica, Mac OS X's Mail, TextEdit, Xcode).
The effort of code change in emacs is trivial, but the social effect
of making this change, thwarting the 20+ years habit world-wide, is
major. The benefit of this change, as we analyzed above, is also
trivial with except to a few dedicated emacs hackers who must have
perfection in efficiency.
A far more important ergonomic change related to keyboarding, for
emacs users as well as all computer keyboard users, is switching
QWERTY to Dvorak. The ergonomic impact of this change would dwarf the
ergonomic issue of emacs's keyboard shortcuts. As we know, the change
from QWERTY to Dvorak keyboard layout is not likely to be adapted
anytime soon. Further, in terms of changes to be considered for the
modernization of emacs, there are many more urgent issues.
Further readings:
� Why Emacs's Keyboard Shortcuts Are Painful
http://xahlee.org/emacs_kb_shortcuts_pain.html
� Graphical Map of Emacs's Shortcuts
http://xahlee.org/emacs_kb_shortcuts.html
� Emacs Command Frequency
http://xahlee.org/command-frequency.html
� Defining Your Own Keyboard Shortcuts
http://xahlee.org/keyboard_shortcuts.html
� How To Avoid The Emacs Pinky Problem
http://xahlee.org/emacs_pinky.html
� A Review of Two Microsoft Ergonomic Keyboards
http://xahlee.org/Periodic_dosage_dir/t2/ms_keyboard.html
� Computer Keyboards Gallery and Ergonomics
http://xahlee.org/keyboards.html
� The Confusion of Emacs's Keystroke Representation
http://xahlee.org/keystroke_rep.html
� The Modernization of Emacs
http://xahlee.org/emacs/modernization.html
� A web comics introducting the history of Dvorak
http://www.dvzine.org/zine/index.html
� Wikipedia on Dvorak
http://en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard
� Wikipedia on commond Windows/Mac/Linux shortcuts
http://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts
Xah
···@xahlee.org
http://xahlee.org/
From: Alain Picard
Subject: Re: The Modernization of Emacs: keyboard shortcuts pain
Date:
Message-ID: <87myxedx45.fsf@memetrics.com>
Xah Lee <···@xahlee.org> writes:
> Alain Picard wrote:
>
> «... Now - remember: "Emacs is the extensible, CUSTOMIZABLE,
> self-documenting real-time display editor." That means if you think
> the keybindings are inefficient, change them. »
>
> It is one thing to praise the software's merits, it's another to use
> it as a quip as a execuse to nullify criticism or flaws.
It is not an excuse. It is a statement of the very essence
of the design of emacs.
I think the reason we are not going to agree is that you do
not realize that the implicit assumptions you are making
are not shared by myself (and, I surmise, most other emacs users).
Those assumptions have to do with what you consider ease of use,
and how it is slanted towards beginner users. I and others value
more highly ease of use, as slanted towards expert use. The other
assumption has to do with some "desire for popularity", which I
don't believe actually exists.
Your next example highlights this perfectly:
> However, note that millions of people been using QWERTY for decades,
> and vast majority never find a problem with it.
Other keyboard layouts have been invented, supposedly to remove
the deficiencies of the QWERTY layout. They have not become
popular. Why not?
Because the "problem" they attempt to solve is not, in fact,
in actual REAL use, a problem, and their adoption would cause
a world of grief and cost to real world actual users.
Another example: emacs comes with modes to make it more friendly
for users of distant lands; to wit the VI and EDT emulation modes.
And yet I would bet that, of users who have come from VI and EDT
and stayed, say, over a year, none of them use those emulation
modes any more. Why?
Because there are benefits in being part of a shared community.
The windows "shortcuts" that you would so eagerly want emacs
to embrace do not come from that community, and would thus
be of little or no benefits to it. And since it is not
the goal of the emacs user's community to make the tool more
widespread (its goal is to make emacs better FOR ITSELF), you
can see that you are fighting a lost cause.
> Similarly, millions of programers been coding C, C++, Java for
> years, they never find any problems the lispers are saying about
> inexpressibility of these languages.
This is simply wrong. In my professional career as a C++ programmer,
I would say that well over half of my colleagues railed at the
ludicrously difficult use and inexpressibility of that language.
Not coincidentally, in my opinion, this was the same half that
seemed to best understand the language and be able to use it
effectively. Have you programmed in one of those language,
I mean, professionally? As part of a team? And delivered a
product? I ask because from where I'm sitting, you put words
into the mouths of "millions of programmers" that I do not think
they would actually say.
> The gist here is that, when a tool that practically works and is
> widespread, it is difficult to see its flaws, even when presented with
> a superior tool.
This is true. But you are NOT proposing a superior tool, now, are you?
Simply a different one, with retraining costs.
> I assert, as i have in my previous articles, that emacs keyboard
> shortcuts, is no better than a random shuffle of its keyboard
> shortcuts, with respect to ergonomics or the efficiency (speed) it has
> on the task of text editing.
And I respond that the empirical evidence of thousands of happy, proficient
users clearly proves you wrong. No amount of "asserting" will make
that evidence go away.
> However, note here that the fact remains, that emacs's keyboard
> shortcut set are grossly inefficient and ergonomically painful. [SNIP]
> And for those emacs evangelizers who would like
> see all programers use emacs, this is also a significant issue.
I don't think there are really a large number of such people, but
if there are, and you are among them, here is what you must do:
* Use the CUSTOMIZABILITY of emacs to author a superior, more efficient,
less ergonomically painful set of key bindings.
* wrap that up in a library, say, ergonomic.el, and post it to
comp.source.emacs
* Document it's use and laud its virtues.
Then see how successful it becomes. In time, it may become
part of the emacs distribution, and may even become the preferred
set of bindings for emacs.
> To these people, the question remains: should emacs change to fix this
> keyboard-shortcut problem? Personally, i do not think so. For this
> change, the primary consideration is cost and benefits. Emacs's
> keyboard shortcuts has been rooted for 20+ years. Its shortcuts set
> are firmly established in not just all emacs users, but as well as in
> terminal applications (e.g. Bash) and many other applications have
> adopted it too (e.g. Mathematica, Mac OS X's Mail, TextEdit, Xcode).
I guess those bindings must not be as "grossly inefficient" and
unergonomic as you claim, for them to have been so assiduously copied.
--alain
--
Please read about why Top Posting
is evil at: http://en.wikipedia.org/wiki/Top-posting
and http://www.dickalba.demon.co.uk/usenet/guide/faq_topp.html
Please read about why HTML in email is evil at: http://www.birdhouse.org/etc/evilmail.html
The following article a extended version of previous post.
A HTML version can be found at
http://xahlee.org/emacs/emacs_kb_shortcuts_pain.html
-----------------------------------
WHY EMACS'S KEYBOARD SHORTCUTS ARE PAINFUL
Xah Lee, 2007-07
A important aspect in designing a keyboard shortcut set, for a
application that has intensive, repetitive, prolonged human-machine
interaction (such as coding and text editing), is to consider
ergonomic principles. Specifically: allocate keyboard shortcuts for
the most frequently used commands, and, the top most frequently used
commands should have most easily-pressed keystrokes. For example, they
should be on the home row.
This article shows why Emacs's keyboard shortcut set are the most
ergonomically unsound.
THE SWAPPING OF CONTROL AND META MODIFIERS
Emacs's keyboard shortcuts is very inefficient. The primary cause is
because, emacs's keyboard shortcuts are designed with a keyboard that
practically has the Ctrl and Alt key positions swapped.
Space Cadet keyboard
above: The Space-cadet keyboard (Source↗, 2007-07) .
The common keyboard used around emacs era in the 1980s are those
keyboards from Lisp Machines↗. (see Space-cadet keyboard↗) The
keyboard on lisp machines have the Control key right besides the space
bar (similar to the position of Alt keys on PC keyboards), and Meta to
the left of Control. So, the Control key is right under the thumb, and
the Meta is secondary to Control. This is why, the shortcuts for the
most used commands in emacs involve the Control key instead of the
Meta key. (e.g. The cursor movements: C-p, C-n, C-f, C-b, C-a, C-e,
the cut/paste/undo C-w, C-y, C-/, the kill-line C-k, the mark C-SPC,
the search C-s.) Lisp Machine's keyboards fell out of use alone with
Lisp Machines. Since the 1990s, the IBM PC keyboard↗ (and its
decedents) becomes the most popular and is used by more than 99% of
personal computers today. The PC keyboard does not have Meta key but
have Alt instead, which is practically used as Meta for emacs. The
Ctrl and Alt key's position are essentially swapped from the Control
and Meta on the Lisp Machine's keyboards. Emacs however, did not
change its keyboard shortcut set by switching the commands that are
mapped to the Control and Meta keys. This makes emacs keyboard
shortcuts very painful, and the frequent need to press the far-away
Control key makes the Emacs Pinky syndrome. (Many emacs-using
programer celebrities have injured their hands with emacs. (e.g.
Richard Stallman↗, Jamie Zawinski↗), and emacs's Ctrl and Meta
combinations are most cited as the major turn-off to potential users
among programers)
THE CHOICE OF KEYS
The shortcut's key choices are primarily based on first letter of the
commands, not based on key position and finger strength or ease of
pressing the key. For example, the single char cursor moving shortcuts
(C-p previous-line ↑, C-n next-line ↓, C-b backward-char ←, C-f
forward-char →) are scattered around the keyboard with positions that
are most difficult to press. (these shortcuts all together accounts
for 43% of all commands executed by a keyboard shortcut) Of these, the
most frequently used is C-n (next-line), which accounts for 20% of all
shortcut calls, but is assigned to the letter n, positioned in the
middle of the keyboard, which is one of the most costy key to press.
Similarly, the second most used among these is the C-p (previous-
line), accounting for 16% of all shortcut command calls, is located in
a position above the rigth hand's pinky, also one of the most costy
key to press.
(Here we assumes the QWERTY keyboard layout. On the Dvorak layout, it
is about as bad.)
OUTDATED COMMANDS
A significant portion of emacs's major shortcuts (those with M-«key»
or C-«key») are mapped to commands that are almost never used today.
Some of these occupies the most precious space (Home row with Meta:
e.g. M-s (center-line), M-j (indent-new-comment-line), M-k (kill-
sentence)). Most programer who have used emacs for years never use
these commands. For example:
digit-argument, M-1 to M-9
negative-argument, M--
move-to-window-line, M-r
center-line, M-s
transpose-words, M-t
tab-to-tab-stop, M-i
M-g prefix, M-g
indent-new-comment-line, M-j
tmm-menubar, M-'
zap-to-char, M-z
back-to-indentation, M-m
tags-loop-continue, M-,
find-tag, M-.
NO EMPLOYMENT OF THE SHIFT KEY
For historical reasons, emacs do not use any keybindings involving the
Shift with a letter. (e.g. there's no “meta shift a”, or “control
shift a”) This is so because in early computing environment, such key
combination cannot be distinguished, due to a practical combination of
ASCII↗, Computer terminal↗, telnet↗.
Today, however, employing the Shift key as part of a shortcut with
other modifiers is common and convenient. For example, on Mac OS X,
Undo and Redo are Cmd+Z and Cmd+Shift+Z, Save and Save As are Cmd+S
and Cmd+Shift+S. On Mac and Windows, moving to next/previous field/
window/application often use the Shift key for reversing direction. In
text editing on both Mac and Windows, a modifier key with a arrow key
will move cursor by word/paragraph, and with Shift down will select
them while moving.
Using the Shift key as a reverse operation is very easy to remember,
and doesn't take another precious shortcut letter. By not using the
Shift key, commands with a logical reverse operation necessarily have
to find other key space, and overall making the shortcut set more
difficult to remember, or scattered, or more difficult to press.
A FLAW IN KEYBINDING POLICY
Any major software, maintains a guide for the developers about the
choices of keyboard shortcuts, so that the shortcuts will be
consistant. Emacs has this in its Emacs Lisp manual: Elisp Manual: Key-
Binding-Conventions.
This guide, indicates that the only key space reserved for users to
define, are the function keys F5 to F9, and key stroke sequence
starting with Ctrl+c followed by a single letter key.
This is a severe restraint to the utility of customized shortcuts. F5
to F9 are only 6 keys. The key sequence starting with C-c followed by
a letter, is a difficult sequence to execute, and there are only 26
spaces there.
The function keys, F1 to F12, are very good candidates for user
defined shortcut space, similarly for the digit key shortcuts, 0 to 9.
These series of key space can be multiplied by any combination of
modifiers of Control, Meta, Shift. For example, a user might define
the them to insert various templates, headers/footers, a system of
customized HTML/XML tags. Or, she might assign them to various special
emacs modes such as dired, shell, ftp, email, calendar, calc,
*scratch*, make-frame-command (Open a new window), insert signature.
It seems too drastic a policy, to limit user defined keys to only F5
to F9, and key sequence of Control+c followed by a single letter key.
EPILOGUE: FAILURE TO CHANGE
Today, most commonly used keyboard shortcuts have been somewhat
informally standardized. For example, C/X/V is for Copy/Cut/Paste. O
is for Open. S is for Save, Shift-S is for Save As. P is for Print. F
is for Find/Search. Tab is for next, Shift tab for previous. These are
common conventions today in every application across Microsoft Windows
and Macintosh (and most Linuxes).
These shortcuts conventions are primarily brought about by Apple
Computer Inc's Human interface guidelines↗ and IBM's Common User
Access↗ in the 1990s.
In the early 1990s, DOS era software, each application has its own
scheme of shortcuts. The following is a excerpt from the Wikipedia
article on Common User Access↗:
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].
* In Emacs, a file was opened with [Ctrl]+[x] followed by [Ctrl]+
[f] (for find-file).
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.
Commercial software have updated themselves with time (or went
extinct), but emacs has not.
Xah
···@xahlee.org
∑ http://xahlee.org/
The following is a FAQ from emacs modernization
http://xahlee.org/emacs/modernization.html
Q: Emacs's undo is superior, because the prevalent Undo/Redo system
actually loss info.
A: Emac's undo is very confusing and does not have a Redo command. To
redo after a undo, people are told to type something then do a undo.
Long time emacs user argue that it is technically superior because it
lets user to revert to any possible state of the past.
A practical problem with the way of emacs undo is that it repeats the
states in the action record. In the prevalent undo model, the action
record is linear, and each entry is unique. A user can easily arrive
at a desired previous state using undo and redo. In emacs's model, it
traverses the queue back and forth (or add existing states to the
stack). It is hard for a user to know when to do undo or do "some
random typing followed by undo" to get to the state he wants. In
particular, once a person did more than once of "some random typing
followed by undo", the undo record becomes too convoluted for a person
to keep in mind and often the undo action becomes useless at that
point.
If you take a survey among programers who use emacs for at least 1
year, perhaps more than 90% are confused by emacs's undo model and do
not find it useful. If you take a survey of software users other than
emacs, i do not think anyone will report their software's undo lacks
something to be desired.
It is reasonable to argue, that people work better with a simple undo/
redo model. Undo is practically used to erase a mistake or doing a
simple one-time revision. Once a user did a sequence of undos and
redos, we can assume that he arrived at a satisfactory point and
intends to start fresh from that point. If he needs extra revision
control, a more proper mechanism, one that people actually use, is to
revert to the saved version.
Xah
···@xahlee.org
http://xahlee.org/
From: Alain Picard
Subject: Re: The Modernization of Emacs: keyboard shortcuts pain
Date:
Message-ID: <87k5s1lg27.fsf@memetrics.com>
Xah Lee <···@xahlee.org> writes:
> In particular, once a person did more than once of "some random
> typing followed by undo", the undo record becomes too convoluted for
> a person to keep in mind and often the undo action becomes useless
> at that point.
I think what you want is some sort of checkpointing. In emacs, this
is accomplished by saving your file when you arrive at your
checkpoint, then, if your undo queue becomes "too convoluted", you
can discard all changes with REVERT-BUFFER.
> If you take a survey among programers who use emacs for at least 1
> year, perhaps more than 90% are confused by emacs's undo model and do
> not find it useful.
FWIW, again, as an emacs user with 1+ years of usage, I don't find
emacs' undo confusing. I'm sure you'll want to add this datum to your
statistics... [I'd be interested to see how this poll was carried out!]
--ap
p.s. congrats for putting your money where your mouth is and publishing
your "improved" keybindings, BTW. I may not agree with your changes,
but by golly I sure respect you for actually DOING something about
the problems your perceive.
Alain Picard <············@memetrics.com> writes:
> FWIW, again, as an emacs user with 1+ years of usage, I don't find
> emacs' undo confusing. I'm sure you'll want to add this datum to your
> statistics... [I'd be interested to see how this poll was carried out!]
As an Emacs user with 13 years of usage, too many undo-redo cycles
definitely confuse me. Especially once you add in region undos.
--
Alan Shutko <···@acm.org> - I am the rocks.
Are you really crazy, or are you as good as you say you are? <M>
Dear Moron,
May i call you a moron?
No? But i'm gonna call you a moron anyway, because you are. You are a
motherfucking, ignorant, ass-pissing, fuckface moron.
Now, let me explain why the Emacs "Meta" term engenders large
confusion and is one of the primary obstacle for the progress of wide
spread adoption of Emacs by people, including programers.
First of all, you must have now understand where the terminology came
from. If not, please read
"Why Emacs's Keyboard Shortcuts Are Painful" at
http://xahlee.org/emacs_kb_shortcuts_pain.html
In short, it refers to a key on a obsolete keyboard popularly used at
Emacs's prime in the 1980s.
Now, with the origin aside, let me explain why it is a major problem
in furthering Emacs today.
The Meta key and the terminology, for all factual aspects, is a over a
decade years old obsolete thingy which Emacs kept using (like many
things in emacs, and non-commericial softwares such as many in unix).
Nobody in this fucking world understand what it is, except the
motherfucking computer geekers in particular the emacs fuckfaces like
yourself. And, worsening the problem, is the fact that those fuckfaces
who know what it is, really don't know where it came from (but now you
do because you've read my writing), yet holds some high air about its
superiority.
Perhaps, the only keyboard today that still has the Meta key is Sun
Microsystem's keyboards, which is essentially a esoteric keyboard.
99.99% of keyboard used by people around the world today on personal
computers as well as servers are decedents of IBM PC keyboard, which
does not have the Meta key.
Emacs can easily fix this obsolete key problem by changing primarily
just its documentation. But Emacs didn't do this. Instead, Emacs has
to tell users how Meta key can be or is mapped to the Alt key (which
calls the concept of key-mapping, immediately snub or thwart new
users), or how it can be pressed by pressing the Esc key first (adding
the confusion). This is, essentially, a i'm-holier-than-thou fucking
attitude.
Although this may seems like a trivial step for any programers, but
any such trivial extra step or inconvenience can cause major problems
to users from adapting the software.
If you are a businessman who are trying to market a software you write
(including those with a programer audience such as Eclipse or X-Code
or IDE), you will take great efforts to ensure that it fits the way
people work and think and taking the attitude of "you learn about my
history first".
Many reasons can be attributed to why Emacs didn't fix the obsolete
key problem. Emacs's primary author Richard Stallman is a stubborn ass
and is in general resistant to change for human factor issues (a
mundane characteristic, like most tech geekers). Also, it's not a
commercial software so it does not have viability pressure as in
commercial software. Not share holder will fire Stallman. And, Emacs
doesn't have a team of social experts to address or goad user
psychology issues. In modern software corporations, they have expert
that consult or study on the multi-discipline science of human factors
and is more and more essential for the success of a major software.
The practical consequence, of still using the Meta terminology and
pretending it still exist and the workaround by always starting by
saying there is/was a Meta key and is today can be mapped to Alt or
pressed by Esc first and prevent as if this is a great logical
soundness and flexibility, is that it actually hurt the spreading of
Emacs.
When a new user (such as a programer), in their busy schedule and
modern life, having motherfucking gazillion languages and technologies
he has to deal with or tempting him to join their factions, really
don't need to be snubbed by another layer of historical baggage. He
hear good things about Emacs, then he is snubbed with unnecessary
shits like M-x and C-x and Esc x instead of the universally understood
modern standard terms Alt+x and Ctrl+x, he is thwarted in his speed to
know Emacs better. Together with this, Emacs itself has lots of other
historical baggage in its 1 fucking thousand pages of manual of
verbosity (not counting another 900+ pages of Elisp manual), and with
propaganda littered throughout in the manual, naturally many
programers consciously or unconsciously back away from Emacs sans ill-
will.
But the real, true, nature of this misconception and misunderstanding
of the Meta key and terminology and consequently its persistent use in
Emacs today, is not that much due to lack of factual literature or
miscommunication. But, due to, the psychology of tech geeker like
fuckface yourself. It is a mixture of elitism, male aggression,
aspects, that kept fuckfaces like yourself insistently and perpetually
holt progress (like the unix and Linux fuckers).
If fuckfaces like yourself does not exist, Emacs would have long time
ago updated itself with time in technical details as well machine-
human relation aspects and would probably be as popular as Microsoft
World.
Xah
···@xahlee.org
http://xahlee.org/
Xah Lee wrote:
�... to reflect current usage, since that is the keyboard 99% of
personal computer users know.�
Brian Connoy wrote:
�If this constitutes major confusion, either Emacs is not what those
people ought to be learning, or you ought to rethink what constitutes
major confusion.�
Xah Lee wrote:
> No? But i'm gonna call you a moron anyway, because you are. You are a
> motherfucking, ignorant, ass-pissing, fuckface moron.
Glad to see *someone* is raising the standard of discourse on c.l.l...
-- JK
--
(declare (antichrist i) (anarchist i)) ; -- the sexp-pistols
JK <·········@kneuro.net> writes:
> Xah Lee wrote:
>
>> No? But i'm gonna call you a moron anyway, because you are. You are a
>> motherfucking, ignorant, ass-pissing, fuckface moron.
>
> Glad to see *someone* is raising the standard of discourse on c.l.l...
Glad to see *someone*, who is not in my killfile, quoting him so I get
to see his posts.
Tamas
[Xah Lee <···@xahlee.org>]
|
| ----------------------------------------
| SIMPLE CHANGES
if I were to suggest improvements to Emacs, the things you mention are
probably among the last things I'd even consider. the problem with
Emacs is not really the nomenclature or the keybindings. the problem
is that it needs to do what it already does better.
My frustration with Emacs has mostly been that Emacs-Lisp is a bit too
limiting. It is too slow and the codebase is a bit messy. or at
least it was the last time I tried to do something in Emacs-Lisp a
couple of years ago. it would also be beneficial if there was a more
proper and well-organized standard library for Emacs to make
developing Emacs applications easier.
for programmers, Emacs is a pretty good editor already, but there is a
bit of a threshold for extending Emacs.
-Bj�rn
Just so everyone's clear:
Nothing he has said makes much sense, if any.
He's talking about advocacy of something unique and powerful by -
making it less unique and powerful-. Not merely catering to the lowest
common denominator, but promoting something as better -by making it
worse-. Who does that?
Imagine that a man invents a vehicle that's far safer and more
maneuverable than any existing vehicle. Imagine that the increased
safety comes from the fact that it has five wheels. How incredibly
stupid would it be for that inventor to then say, "I'm going to
convince people to buy my new vehicle, which is safer thanks to this
fifth wheel. But in order to market it, I'll take the fifth wheel off,
so it's more familiar and comfortable for them."
I'm very, very new to emacs. I used it a little this past year in
college, but I didn't try at all to delve into its features. I'm
starting that process now, and frankly, the thought of it changing -
already- upsets me. I don't feel like the program ought to change in
order to accommodate me. I'm excited about the prospect of mastering
something new and different. The fewer resemblances to the common-
denominator, extra-friendly stuff I've worked with in the past, the
better.
Emacs' uniqueness may hurt its adoption rate, but it still has plenty
of users, who are all perfectly happy with how things are done.
-Andrew
Kaldrenon <·········@gmail.com> writes:
> I'm very, very new to emacs. I used it a little this past year in
> college, but I didn't try at all to delve into its features. I'm
> starting that process now, and frankly, the thought of it changing -
> already- upsets me. I don't feel like the program ought to change in
> order to accommodate me.
Actually, the "E" in "Emacs" stands for "extensible". Part of the
appeal of Emacs is that you can change it to accommodate you.
> I'm excited about the prospect of mastering something new and
> different. The fewer resemblances to the common- denominator,
> extra-friendly stuff I've worked with in the past, the better.
>
> Emacs' uniqueness may hurt its adoption rate, but it still has
> plenty of users, who are all perfectly happy with how things are
> done.
Oh, but Emacs is not TeX: it _is_ being developed further. And some
changes are done in order to synchronize Emacs with the "other world"
where the latter has been oversleeping. For example, Emacs 23 will
internally use utf-8/Unicode as its encoding when it has used
emacs-mule up to now, a multibyte code of its own.
In spirit, this will not change Emacs much, yet it will remove
other-world friction and make Emacs more obviously the incarnation of
editing descended into this world.
--
David Kastrup
On Jun 20, 9:28 am, David Kastrup <····@gnu.org> wrote:
> Kaldrenon <·········@gmail.com> writes:
> > I'm very, very new to emacs. I used it a little this past year in
> > college, but I didn't try at all to delve into its features. I'm
> > starting that process now, and frankly, the thought of it changing -
> > already- upsets me. I don't feel like the program ought to change in
> > order to accommodate me.
>
> Actually, the "E" in "Emacs" stands for "extensible". Part of the
> appeal of Emacs is that you can change it to accommodate you.
Well put. Perhaps I should have said that I don't feel like the
program ought to change to "accommodate" -everybody-.
I know that Emacs is still being worked on, is still growing and
changing, and also that, because of its extensibility, anyone can
change it as they wish. In fact, if the OP wants Emacs to behave the
way he describes, I'm sure it's doable. But my statement was that the
changes he suggests are things that should not be enforced
universally, because not only is there nothing wrong with the things
he suggests changing, but the idea of enforcing uniform changes is not
entirely in the spirit of Emacs.
Kaldrenon <·········@gmail.com> writes:
> On Jun 20, 9:28 am, David Kastrup <····@gnu.org> wrote:
>> Kaldrenon <·········@gmail.com> writes:
>> > I'm very, very new to emacs. I used it a little this past year in
>> > college, but I didn't try at all to delve into its features. I'm
>> > starting that process now, and frankly, the thought of it changing -
>> > already- upsets me. I don't feel like the program ought to change in
>> > order to accommodate me.
>>
>> Actually, the "E" in "Emacs" stands for "extensible". Part of the
>> appeal of Emacs is that you can change it to accommodate you.
>
> Well put. Perhaps I should have said that I don't feel like the
> program ought to change to "accommodate" -everybody-.
>
The point is that the responsibility to customize is on the user. All
the developers need to do is continue providing the most customizable
piece of software around. If we place the responsiblity to customize
on the developer, then he develops a piece of software customized for
himself; that wouldn't be Emacs.
Which brings me to another point: as someone already said, you could
fork the code and make all these changes, but then it would be
something else, it would stop being Emacs.
And it would stop being cool.
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest:
http://www.gnu.org/philosophy/sylvester-response.html
On Jun 20, 12:39 pm, ········@partners.org (Joel J. Adamson) wrote:
> The point is that the responsibility to customize is on the user.
Given that in its out-of-the-box configuration it's well-nigh unusable
without a printed-out "cheat sheet" of some kind, of the sort that
were supposed to have died out in the 80s, getting it customized poses
something of a catch-22 for anyone trying to get started using it.
Twisted <··········@gmail.com> writes:
> On Jun 20, 12:39 pm, ········@partners.org (Joel J. Adamson) wrote:
>> The point is that the responsibility to customize is on the user.
>
> Given that in its out-of-the-box configuration it's well-nigh unusable
> without a printed-out "cheat sheet" of some kind, of the sort that
> were supposed to have died out in the 80s, getting it customized poses
> something of a catch-22 for anyone trying to get started using it.
"Catch 22" is the right phrase here: just catch Emacs 22 and get
started. Its out-of-the-box configuration is quite sensible.
What was the last version you said you actually tried out?
--
David Kastrup
David Kastrup wrote:
> Twisted <··········@gmail.com> writes:
>
>> On Jun 20, 12:39 pm, ········@partners.org (Joel J. Adamson) wrote:
>>> The point is that the responsibility to customize is on the user.
>>
>> Given that in its out-of-the-box configuration it's well-nigh unusable
>> without a printed-out "cheat sheet" of some kind,
Unuseable for whom? I didn't need a cheat sheet after a couple of hours.
I could do everything many windows editors are capable of after a few
minutes, and my abilities kept growing after I learned all that more
limited editors have to offer. For me it's a matter of power. I've never
seen a windows editor that was as powerful so I choose to use an editor
that meets my needs.
I know many people who don't want much from an editor and they are
content to settle for less. That's ok, not everyone must use a powerful
editor. One size doesn't fit all. If notepad meets your needs, by all
means use it.
>>of the sort that
>> were supposed to have died out in the 80s,
Where did you find this idea? The wheel has been around since before the
80's and we still use the technology often.
new != modern != progress != better
Better or improved is always a combination of factors and age is rarely
a major consideration.
>> getting it customized poses
>> something of a catch-22 for anyone trying to get started using it.
>
> "Catch 22" is the right phrase here: just catch Emacs 22 and get
> started. Its out-of-the-box configuration is quite sensible.
>
> What was the last version you said you actually tried out?
Truth be told, I think some of the changes (toolbars, etc) could
probably have been left out for my purposes but I'm content that they can
be turned off.
>
Twisted <··········@gmail.com> writes:
>
> Given that in its out-of-the-box configuration it's well-nigh unusable
> without a printed-out "cheat sheet" of some kind, of the sort that
> were supposed to have died out in the 80s, getting it customized poses
> something of a catch-22 for anyone trying to get started using it.
I don't see that. C-h t is your friend if you're starting out. The
only keystrokes a user really needs to remember are C-x C-s and C-x C-c;
everything else simple text editing needs works as expected (arrow keys,
backspace and so forth). Granted, text-mode is friendlier than
fundamental-mode. Still, as a pico replacement emacs works well
enough--and as the user continue to works, he discovers more and more
functionality, eventually having a 10,000-line .emacs...
--
Robert Uhl <http://public.xdi.org/=ruhl>
Listening to someone who brews his own beer is like listening to a
religious fanatic talk about the day he saw the light.
--Ross Murray, Montreal Gazette, 1991
On Jun 21, 9:49 am, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> Twisted <··········@gmail.com> writes:
>
> > Given that in its out-of-the-box configuration it's well-nigh unusable
> > without a printed-out "cheat sheet" of some kind, of the sort that
> > were supposed to have died out in the 80s, getting it customized poses
> > something of a catch-22 for anyone trying to get started using it.
>
> I don't see that. C-h t is your friend if you're starting out. The
> only keystrokes a user really needs to remember are C-x C-s and C-x C-c;
> everything else simple text editing needs works as expected (arrow keys,
> backspace and so forth). Granted, text-mode is friendlier than
I'm not so sure C-h t is anybody's friend anymore. Every version of
Emacs that I've used since 1984 has supported the arrow and page up/
down keys. And every version of the tutorial that I've read (the
latest just a couple years back) insists on starting the user out with
C-f, C-b, C-p, C-n, C-V, and ESC-V, with some lame explanation like
"touch-typists shun the arrow and page keys, and besides, they might
not be supported on the next terminal you use." Like ESC, I suppose.
Furrfu.
Regards,
-=Dave
Twisted <··········@gmail.com> writes:
> On Jun 20, 12:39 pm, ········@partners.org (Joel J. Adamson) wrote:
>> The point is that the responsibility to customize is on the user.
>
> Given that in its out-of-the-box configuration it's well-nigh unusable
> without a printed-out "cheat sheet" of some kind, of the sort that
> were supposed to have died out in the 80s, getting it customized poses
> something of a catch-22 for anyone trying to get started using it.
Again, I have to point out that I had a different experience. I did
the tutorial, and somehow immediately I understood how to customize.
I don't remember having any difficulty with Emacs other than not
liking the way it looked -- that's because I was on Windows (I later
found out). I soon fixed that problem. I didn't need a cheat-sheet,
since the help files are _actually_ _helpful_ unlike those "Help"
(=advertising) files on most other pieces of software.
My point is that I'm the sort of person that has a mind set up for
Emacs. I had none of the difficulties that someone else might have,
who's used to other kinds of software.
However, I'll also point out that my wife has used Emacs a couple
times, and she's never done more than point and click with a computer,
and she's had no frustration whatsoever.
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest:
http://www.gnu.org/philosophy/sylvester-response.html
Joel J. Adamson wrote:
> My point is that I'm the sort of person that has a mind set up for
> Emacs. I had none of the difficulties that someone else might have,
> who's used to other kinds of software.
>
> However, I'll also point out that my wife has used Emacs a couple
> times, and she's never done more than point and click with a computer,
> and she's had no frustration whatsoever.
A new user of two hours' experience. A father of a six-year old whose child
hums along happily with emacs. A computer widow who "had no frustration
whatsoever" with it.
To the claim that "emacs is too hard for the beginner" we have a mounting pile
of steaming evidence that refutes. It may still be true that it is too hard
for some beginners, but then again the power cord can be too hard for some
people. (I used to help customers find the Big Red Switch when they first got
a computer. There were many who needed it.)
To the claim that emacs has arcane keystrokes comes the evidence that modern
revs have "normal" keystrokes like right-arrow, F1, Ctrl-End.
To the claim that the help is too hard to use comes the evidence that three
simple keystroke patterns are all one needs to know, and anecdotal evidence of
the help system's utility.
Some will refuse to face the truth. To the open-minded, let the facts speak
for themselves.
I bet Xah Les is all over smiles about how well his controversy bloomed.
--
Lew
On 2007-06-21, Lew <···@lewscanon.nospam> wrote:
> To the claim that "emacs is too hard for the beginner" we have a mounting pile
> of steaming evidence that refutes. It may still be true that it is too hard
> for some beginners......
I point them to jed. I, too, was overwhelmed by emacs, initially, but
can't stand vi so I had to do something. jed was my savior. It uses
many standard keys like backspace and the arrows, so newbs aren't so
confused. When I finally became comfortable with the std emacs
keystrokes I got O'Reilly's great book and ventured into emacs. Love
it. But, still a rank newb and still use jed and slrn a lot till I
can learn to configure emacs like I want it.
vi, the heart of evil!
nb
Lew wrote:
>> To the claim that "emacs is too hard for the beginner" we have a mounting pile
>> of steaming evidence that refutes. It may still be true that it is too hard
>> for some beginners......
notbob wrote:
> I point them to jed. I, too, was overwhelmed by emacs, initially, but
> can't stand vi so I had to do something. jed was my savior. It uses
> many standard keys like backspace and the arrows, so newbs aren't so
> confused.
You mean compared to the way emacs also uses the same "standard" keys, like
backspace and the arrows? How are the arrow keys in emacs more confusing than
the arrow keys in jed?
Your comment reads like you've missed most of this thread.
--
Lew
On 2007-06-21, Lew <···@lewscanon.nospam> wrote:
> Your comment reads like you've missed most of this thread.
This may be due to the fact I've missed most of this thread.
nb
Lew <···@lewscanon.nospam> writes:
> Joel J. Adamson wrote:
>> My point is that I'm the sort of person that has a mind set up for
>> Emacs. I had none of the difficulties that someone else might have,
>> who's used to other kinds of software.
>>
>> However, I'll also point out that my wife has used Emacs a couple
>> times, and she's never done more than point and click with a computer,
>> and she's had no frustration whatsoever.
>
> A new user of two hours' experience. A father of a six-year old whose
> child hums along happily with emacs. A computer widow who "had no
> frustration whatsoever" with it.
>
I'll add that the words "Oh, cool" came out of her mouth during one
Emacs session, as they did when I showed it to a coworker.
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest:
http://www.gnu.org/philosophy/sylvester-response.html
On Jun 21, 11:11 am, Lew <····@lewscanon.nospam> wrote:
> Joel J. Adamson wrote:
> > My point is that I'm the sort of person that has a mind set up for
> > Emacs. I had none of the difficulties that someone else might have,
> > who's used to other kinds of software.
>
> > However, I'll also point out that my wife has used Emacs a couple
> > times, and she's never done more than point and click with a computer,
> > and she's had no frustration whatsoever.
>
> A new user of two hours' experience. A father of a six-year old whose child
> hums along happily with emacs. A computer widow who "had no frustration
> whatsoever" with it.
>
> To the claim that "emacs is too hard for the beginner" we have a mounting pile
> of steaming evidence that refutes.
It's a steaming pile of something, of that I am sure, but I don't
think "evidence" is the word I'd use to describe it. The word I'm
thinking of IS eight letters long, but it starts with "b" instead of
"e"...
I find these anecdotes liberally sprinkled into this thread frankly
unbelievable. Either they are not using the same software I understand
"emacs" to refer to, or someone somewhere is simply lying. Or maybe
there's a bunch of prodigies around and they all picked now to pipe
up? We can't design software or any other tool to cater exclusively to
a handful of Mozarts, though, unless there's no reason to believe
anyone outside that small and exclusive club will ever have a use for
it.
> To the claim that the help is too hard to use comes the evidence that three
> simple keystroke patterns are all one needs to know, and anecdotal evidence of
> the help system's utility.
Utility is nothing without usability. In particular, no matter how
much useful content the help might have, the fact that when the
document window has the focus the help is always open to the section
on switching windows rather puts a crimp in the actual usability of
that information. The only times you can use it and the only times you
can read it are non-overlapping sets.
> Some will refuse to face the truth. To the open-minded, let the facts speak
> for themselves.
A few anecdotes prove nothing. A first year statistics 101 dropout
knows that much.
Twisted wrote:
> I find these anecdotes liberally sprinkled into this thread frankly
> unbelievable. Either they are not using the same software I understand
> "emacs" to refer to, or someone somewhere is simply lying.
So if someone provides evidence with which you disagree, you accuse them of lying.
There's no opportunity for reasoned discourse in the face of such tactics. Or
room for new information to combat one's prejudices.
--
Lew
Some entity, AKA Lew <···@lewscanon.nospam>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> There's no opportunity for reasoned discourse in the face of such
> tactics. Or room for new information to combat one's prejudices.
Nothing battles stupidity more effective than natural selection.
Cor
--
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
The biggest problem LISP has, is that it does not appeal to dumb people
If that fails to satisfy read the HyperSpec, woman frig or Tuxoharata
mailpolicy @ http://www.clsnet.nl/mail.php
Twisted wrote:
> I find these anecdotes liberally sprinkled into this thread frankly
> unbelievable.
If you'd spent as much time learning the software as you're ranting
about it, you could actually use it _and_ would get the additional
benefit of having avoided making a fool of yourself on Usenet. Of course
that would have been too easy, wouldn't it?
In article <························@z28g2000prd.googlegroups.com>,
Twisted <··········@gmail.com> wrote:
[ snip ]
> I find these anecdotes liberally sprinkled into this thread frankly
> unbelievable. Either they are not using the same software I understand
> "emacs" to refer to,
I think this may be the explanation. The other people's anecdotes
seem pretty plausible to me in the context of emacs as it currently
exists. You, however, appear to be talking about -- well, I'm not
quite sure, but perhaps emacs as it existed at some earlier point
in its history? The first emacs I used (in 1980-something) didn't
have a GUI either. But the ones currently available to me do.
> or someone somewhere is simply lying. Or maybe
> there's a bunch of prodigies around and they all picked now to pipe
> up? We can't design software or any other tool to cater exclusively to
> a handful of Mozarts, though, unless there's no reason to believe
> anyone outside that small and exclusive club will ever have a use for
> it.
[ snip ]
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
[Twisted <··········@gmail.com>]
|
| Given that in its out-of-the-box configuration it's well-nigh unusable
| without a printed-out "cheat sheet" of some kind, of the sort that
| were supposed to have died out in the 80s, getting it customized poses
| something of a catch-22 for anyone trying to get started using it.
indeed, not adhering to the half a dozen keybinding and menu
conventions that most newer applications use on OSX and Windows today
is not ideal UI design, but it doesn't really present that much of a
problem either; so it ends up being a non-issue to any regular user.
(actually, it isn't merely a case of changing some keybindings and
names -- the problem is that Emacs has a bunch of concepts that are
not easily mapped to trivial editor semantics, so it would be hard to
change without causing further confusion).
Emacs isn't really meant for the casual user and there are editors far
better suited for those who think spending an afternoon learning it is
too much. (compare to VI or VIM, which probably takes even a bit
longer to grasp, but which is beautifully practical once you
understand how it works. there's this good tech-talk given by Bram
Moolenaar available� on about text editing and VIM).
�) http://video.google.com/videoplay?docid=2538831956647446078
-Bj�
On Jun 20, 8:28 am, David Kastrup <····@gnu.org> wrote:
> Actually, the "E" in "Emacs" stands for "extensible". Part of the
> appeal of Emacs is that you can change it to accommodate you.
Actually, though Emacs is the epitome of extensibility, the "E" stands
for "Editor." "EMACS" is simply short for Editor MACroS, and was
originally implemented as a set of TECO macros.
There's also the joke that EMACS stands for Esc Meta Alt Ctrl Shift,
due to it's (often overwhelmingly) large and sometimes complex set of
keystroke combinations used to invoke various editing functions. This
view is usually put forth by the vi camp during editor wars.
Speaking of which, vi is a piece of wombat do. ;-)
Regards,
-=Dave
On Wed, 20 Jun 2007 23:33:29 +0100, Dave Hansen <····@hotmail.com> wrote:
> On Jun 20, 8:28 am, David Kastrup <····@gnu.org> wrote:
>> Actually, the "E" in "Emacs" stands for "extensible". Part of the
>> appeal of Emacs is that you can change it to accommodate you.
>
> Actually, though Emacs is the epitome of extensibility, the "E" stands
> for "Editor." "EMACS" is simply short for Editor MACroS, and was
> originally implemented as a set of TECO macros.
>
> There's also the joke that EMACS stands for Esc Meta Alt Ctrl Shift,
> due to it's (often overwhelmingly) large and sometimes complex set of
> keystroke combinations used to invoke various editing functions. This
> view is usually put forth by the vi camp during editor wars.
>
There are dozens of alternative interpretation for "EMACS".
http://www.gnu.org/fun/jokes/gnuemacs.acro.exp.html
My favourite:
Elsewhere Maybe All Commands are Simple
Dan.
--
Daniel Dyer
http//www.uncommons.org
From: ········@radom.zrz.tu-berlin.de
Subject: Re: The Modernization of Emacs
Date:
Message-ID: <5dv01oF36ms9vU1@mid.dfncis.de>
Dave Hansen <····@hotmail.com> wrote in comp.lang.perl.misc:
> Speaking of which, vi is a piece of wombat do. ;-)
You can have Emacs when you pry it from my cold hypertrophied
escape-pressing pinky!
Anno
On 2007-06-21, ········@radom.zrz.tu-berlin.de <········@radom.zrz.tu-berlin.de> wrote:
> You can have Emacs when you pry it from my cold hypertrophied
> escape-pressing pinky!
LOL!....
nb
In article <··············@lola.quinscape.zz>, David Kastrup <···@gnu.org>
wrote:
> Kaldrenon <·········@gmail.com> writes:
>
> > I'm very, very new to emacs. I used it a little this past year in
> > college, but I didn't try at all to delve into its features. I'm
> > starting that process now, and frankly, the thought of it changing -
> > already- upsets me. I don't feel like the program ought to change in
> > order to accommodate me.
>
> Actually, the "E" in "Emacs" stands for "extensible". Part of the
> appeal of Emacs is that you can change it to accommodate you.
Actually, the "E" in Emacs stands for "Editor". And the macs part stands
for "Macros". As in "Editor Macros". It started out as a bunch of macros
written in TECO.
Roy Smith <···@panix.com> writes:
> In article <··············@lola.quinscape.zz>, David Kastrup <···@gnu.org>
> wrote:
>
>> Kaldrenon <·········@gmail.com> writes:
>>
>> > I'm very, very new to emacs. I used it a little this past year in
>> > college, but I didn't try at all to delve into its features. I'm
>> > starting that process now, and frankly, the thought of it changing -
>> > already- upsets me. I don't feel like the program ought to change in
>> > order to accommodate me.
>>
>> Actually, the "E" in "Emacs" stands for "extensible". Part of the
>> appeal of Emacs is that you can change it to accommodate you.
>
> Actually, the "E" in Emacs stands for "Editor". And the macs part
> stands for "Macros". As in "Editor Macros". It started out as a
> bunch of macros written in TECO.
It's not like I did not know this. Don't ask me what got into my head
here.
--
David Kastrup
[Kaldrenon <·········@gmail.com>]
| Just so everyone's clear:
|
| Nothing he has said makes much sense, if any.
(it'd be good if you explicitly specify who "he" is since pronouns by
nature are extremely context sensitive, and in this context an
unattentive reader might think you are referring to me. thanks :-).
| Emacs' uniqueness may hurt its adoption rate, but it still has plenty
| of users, who are all perfectly happy with how things are done.
I don't see popularity as a goal in itself. I am selfish. I only
care what the software can do for me and I think that this is the only
way to write good software: make something you'd want to use
yourself.
-Bj�
On Jun 20, 9:09 am, Kaldrenon <·········@gmail.com> wrote:
> Imagine that a man invents a vehicle that's far safer and more
> maneuverable than any existing vehicle. Imagine that the increased
> safety comes from the fact that it has five wheels. How incredibly
> stupid would it be for that inventor to then say, "I'm going to
> convince people to buy my new vehicle, which is safer thanks to this
> fifth wheel. But in order to market it, I'll take the fifth wheel off,
> so it's more familiar and comfortable for them."
Imagine that a man invents a vehicle that's far safer and more
maneuverable than any existing vehicle. Imagine that the increased
safety comes from the fact that it has five wheels. Gratuitously, he
also has his own peculiar ideas regarding how one should control this
vehicle, and instead of giving it a normal car steering wheel, brake,
and gas pedal, he gives it two stick-like left and right throttle
controls, which can be pulled back to brake and even reverse the car,
pushed forwards to accelerate it, and positioned differently to cause
the vehicle to rotate -- even to rotate in place, obviating the need
for three-point turns and simplifying parallel parking somewhat.
Unfortunately, nobody used to a normal car is remotely comfortable
with these controls. They have a very steep learning curve and
numerous accidents result. It turns out there's even a conversion kit
available for replacing them with a normal steering wheel, brake, and
gas pedal, but getting the conversion kit without crashing on the way
to where you get it proves problematic because of the same unusual
controls you're trying to replace. All of the driving schools, of
course, teach the usual wheel-and-pedals method of controlling a motor
vehicle...
This seems to be a closer analogy with emacs versus normal Windows
text editors. Arguably even the weird controls are superior in some
way -- but only if you got used to them, which will never happen
because you'll abandon it for inability to be productive with it long
before that can happen, and also because the same clunky controls
hobble your access to the online help that would otherwise smooth the
path for you. The same problem plagues attempts to reconfigure the
controls to something more normal. And the computer-driving schools --
computer classes in ordinary school -- teach standard Windows UI
conventions (or their Macintosh equivalents, which correspond closely
to one another). If there is any formal training in emacs use, it's
effectively unobtainable due to obscurity and hard-to-findness,
geographical distance, expense, or even more than one of those
factors.
The above applies equally to vi and its derivatives, if not more so --
vi is like taking that same already-wacky car with the two separate
throttles and adding, in a fit of quaint nostalgia, the need to
actually crank-start its engine. ;)
Twisted wrote:
> This seems to be a closer analogy with emacs versus normal Windows
> text editors.
>
Windows text editors are not normal: most are devoid of all but the most
primitive functions and are further hampered by having an interface that
required frequent time wasting hand transfers from keyboard to mouse
because, if they provide keyboard equivalents at all, these are
remarkably unmemorable and/or undocumented.
Ask anybody who used early versions of Word and you'll hear just how
much faster Word for DOS 5 was than any of its Windows incarnations.
This was because all commands were keystrokes so a skilled typist could
keep both hands on the keyboard all the time. WinWord's interface is a
clunker by comparison.
As for documentation, lets look at vi. Not a great editor, but every
*nix variation has it installed and any fool can learn to use it in
about 2 hours flat and it does at least have good pattern matching.
Can't find its documentation? Never heard of manpages ("man vi") or
apropos ("apropos vi")? My copy of vi understands ":help" and tells you
so if you start it without any arguments.
Amongst its benefits are that you can do anything its capable of by
using only a standard QUERTY keyboard plus ESC - no function keys, etc
are needed - which can save your bacon if somebody misconfigured your
console or the computer is dieing. Beyond that it has user-configurable
KEY BINDINGS so you can also set it up to suit both yourself and that
fancy keyboard in front of you.
> Arguably even the weird controls are superior in some
> way -- but only if you got used to them,
>
You mean that Alt-Esc or Windows-e aren't weird? How long is it since
you tried to use Windows with a dead mouse? There are a set of arcane
keystrokes to replace anything you can do with a mouse but I bet 99% of
windows users don't know any of them apart from TAB and CTRL-ALT-DEL.
> The above applies equally to vi and its derivatives, if not more so --
> vi is like taking that same already-wacky car with the two separate
> throttles and adding, in a fit of quaint nostalgia, the need to
> actually crank-start its engine. ;)
>
If you can't learn enough vi to get by with in half a morning you're
probably well out of your depth here on comp.lang.java.programmer.
Oh, I forgot: you don't read manuals so you ARE out of your depth.
--
······@ | Martin Gregorie
gregorie. | Essex, UK
org |
> Windows text editors are not normal: most are devoid of all but the most
> primitive functions and are further hampered by having an interface that
> required frequent time wasting hand transfers from keyboard to mouse
> because, if they provide keyboard equivalents at all, these are
> remarkably unmemorable and/or undocumented.
well ultra-edit, textpad, source-insight etc. pp are better than that
(and run on windows)
Sascha Bohnenkamp wrote:
>> Windows text editors are not normal: most are devoid of all but the most
>> primitive functions and are further hampered by having an interface that
>> required frequent time wasting hand transfers from keyboard to mouse
>> because, if they provide keyboard equivalents at all, these are
>> remarkably unmemorable and/or undocumented.
>
> well ultra-edit, textpad, source-insight etc. pp are better than that
> (and run on windows)
I said MOST, not all!
To your list I'd add PFE and a Windows port of microEmacs, which has
almost nothing in common with EMACS except some key bindings.
But to return to your point: how many Windows users actually install the
editors we've listed? I bet most never get past Wordpad. I've even found
people using Word, of all things, to edit BAT files and program source.
I'd give long odds that Windows users who use editors other than Wordpad
are using the one that came with whatever IDE they've installed, simply
because integrated editors are much more common in Windows-only IDEs
that they are on *nixen. My guess is that this is because the standard
editors (Wordpad, edlin) are so bad.
--
······@ | Martin Gregorie
gregorie. | Essex, UK
org |
[Martin Gregorie <······@see.sig.for.address>]
|
| As for documentation, lets look at vi. Not a great editor, but every
| *nix variation has it installed and any fool can learn to use it in
| about 2 hours flat and it does at least have good pattern matching.
there's also the "info" system in Emacs, which not only covers Emacs
itself, but usually also a lot of documentation available for Emacs
extensions and other programs. again, this predates a lot of things
that people are used to today, so just because it seems (and sometimes
is) a bit more fiddly, it must necessarily be inferior.
the most common theme when people have to choose between products is
that they are not really comparing what it is like to use the products
like they were intended -- they are merely underlining that X is not
Y. for instance, Linux has come a long way in addressing the needs of
desktop users, yet some people refuse to use Linux because it doesn't
behave *exactly* like Windows (as if that was a worthwhile goal) and
they are too lazy or don't think they can manage, to learn a new
system.
-Bj�
Bjorn Borud wrote:
> [Martin Gregorie <······@see.sig.for.address>]
> |
> | As for documentation, lets look at vi. Not a great editor, but every
> | *nix variation has it installed and any fool can learn to use it in
> | about 2 hours flat and it does at least have good pattern matching.
>
> there's also the "info" system in Emacs, which not only covers Emacs
> itself, but usually also a lot of documentation available for Emacs
> extensions and other programs. again, this predates a lot of things
> that people are used to today, so just because it seems (and sometimes
> is) a bit more fiddly, it must necessarily be inferior.
>
I thought it might be in "info", like most GNUish things but I couldn't
check because I don't have it installed.
> for instance, Linux has come a long way in addressing the needs of
> desktop users, yet some people refuse to use Linux because it doesn't
> behave *exactly* like Windows (as if that was a worthwhile goal) and
> they are too lazy or don't think they can manage, to learn a new
> system.
>
Yep, and the same people think a command line is to be avoided at all
costs. "I mean, its so /last century/ and you can't do anything useful
with it anyway".
Obligatory OT comment: right now I have two xterm sessions open with
which I've been writing a Swing/JDBC app using nowt but a bash shell,
cvs, microEmacs and (of course) J2SE. I don't need no steenking IDE.
--
······@ | Martin Gregorie
gregorie. | Essex, UK
org |
Martin Gregorie <······@see.sig.for.address> writes:
> Bjorn Borud wrote:
> Yep, and the same people think a command line is to be avoided at all
> costs. "I mean, its so /last century/ and you can't do anything useful
> with it anyway".
Funny ;)
It's funny that people consider typing commands to be "old-fashioned"
because pointing with a mouse is the stone-age device; typing was only
invented in the 19th century ;)
Xerox PARC (not Apple nor MIcrosoft) excelled in helping computers fit
in to how people already lived, not the other way around.
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest:
http://www.gnu.org/philosophy/sylvester-response.html
Joel J. Adamson wrote:
> Xerox PARC (not Apple nor MIcrosoft) excelled in helping computers fit
> in to how people already lived, not the other way around.
>
I've never got my hands on a genuine Xerox. About the nearest to that I
managed was an ICL PERQ back in 1980, with a portrait-mode black and
white screen and a three button mouse. That was the first GUI I saw
(next was an Apple Lisa in 1984). The PERQ was dead easy to use after
about 5 minutes instruction.
--
······@ | Martin Gregorie
gregorie. | Essex, UK
org |
[Martin Gregorie <······@see.sig.for.address>]
|
| Yep, and the same people think a command line is to be avoided at all
| costs. "I mean, its so /last century/ and you can't do anything useful
| with it anyway".
I have a friend who is a carpenter. he switched to Linux a few years
ago because he was tired of how slow windows was and how easily it was
infested with malware. he really, really doesn't give a toss what it
says on the tin, he's a _user_ and that's it. to my surprise, finds
Linux as easy, if not easier to use, than windows. (he still has to
use windows for his invoicing system. everything else he does in
Linux).
I have observed similar opinions in other non-computer-freaks. people
who see the computer only as a tool and are only interested in getting
the job done. they have a surprising preference for Linux. (not many
of them have ever been exposed to OSX though, and I'd suspect they'd
prefer that since it is far more streamlined).
| Obligatory OT comment: right now I have two xterm sessions open with
| which I've been writing a Swing/JDBC app using nowt but a bash shell,
| cvs, microEmacs and (of course) J2SE. I don't need no steenking IDE.
I used J2SE, Ant, Emacs, Xterm, bash and Firefox as my main tools when
I wrote most of my production Java code. and it is not exactly what
you'd call "hobbyist projects" either. :-)
-Bj�
On Jun 22, 11:52 am, Bjorn Borud <··········@borud.no> wrote:
> [Martin Gregorie <······@see.sig.for.address>]
> |
> | Yep, and the same people think a command line is to be avoided at all
> | costs. "I mean, its so /last century/ and you can't do anything useful
> | with it anyway".
I think a command line can be useful as a way to directly talk to
something's brain. More GUI apps should have a command processor you
can access to do something arcane once in a while. The other thing a
command processor is good for is providing automation support.
Windows is definitely weak on allowing things like editors to be
embedded and used as components by other applications. OLE makes it
theoretically possible to e.g. use Winword in an IDE but who'd want
to? It also doesn't provide a system-wide way to select particular
components to do particular jobs -- the closest thing would be
splitting comctl32.dll into separate dlls for each common task or
dialog and allowing third-party drop-in replacements to be found in a
user-specific directory that override the defaults. That sort of
modularity and choice is alien to MS thought patterns however.
Combining the flexibility of componentry in Unix with the graphical
power of Windows might lead to something awesome ... which makes KDE
and Gnome things to keep eyes on in the future.
> I have observed similar opinions in other non-computer-freaks. people
> who see the computer only as a tool and are only interested in getting
> the job done. they have a surprising preference for Linux.
But not emacs, I'll bet. I think emacs appeals to people who like
dealing with the mechanics of emacs or fiddling with and extending the
darn thing. But most people just want to get the job done, and the
editor or other tools they use have to get out of the way and simply
let them work. If their attention keeps being dragged forcible from
THE JOB to THE TOOL and how to make this cantankerous thing do *this*?
then there is a problem. If I sit down at a windows text editor (or
even kwrite or similar) I can just focus on the job. Faced with emacs
or most other text-mode editors (but not MS-DOS Edit, interestingly)
the editor keeps intruding on my focus. Oops.
Elsewhere, you mentioned 3 second attention spans -- I think you'll
find people are much more willing to spend 3 hours of attention on
their task than 3 seconds on your favorite tool. When the tool
intrudes into the user's attention (either by misbehaving, e.g.
crashing, or by confounding the user as to how to do what they want to
do next), then a problem is evident.
Twisted wrote:
> If I sit down at a windows text editor (or
> even kwrite or similar) I can just focus on the job. Faced with emacs
> or most other text-mode editors (but not MS-DOS Edit, interestingly)
> the editor keeps intruding on my focus. Oops.
>
"emacs or most other text-mode editors" sounds very much like you
believe emacs works in a pure text mode too? It can, of course, and
that's a good thing, but that's certainly not how I usually use it -
it has a GUI, you know.
[Twisted <··········@gmail.com>]
|
| > I have observed similar opinions in other non-computer-freaks. people
| > who see the computer only as a tool and are only interested in getting
| > the job done. they have a surprising preference for Linux.
|
| But not emacs, I'll bet. I think emacs appeals to people who like
| dealing with the mechanics of emacs or fiddling with and extending the
| darn thing. But most people just want to get the job done, and the
| editor or other tools they use have to get out of the way and simply
| let them work.
no, Emacs is not among the applications they use. nor are any IDEs or
compilers. I don't think Emacs is that relevant to these users since
what they do is mostly word-processing, spreadsheets, mail and web
browsing. Emacs is not really targeted at Word processing as
such. (although that doesn't stop some people from thinking that it
would be a good idea to turn Emacs into a wordprocessing application
with support for graphics, mixed fonts etc.)
I use Emacs for creating documents, but this is very different since I
use LaTeX and I'm a programmer, so it is very conventient for me to
use a system that allows me to treat documents like code (with respect
to revision control systems etc). outside academia or the technical
community, not that many use LaTeX, but I have seen it in the past.
-Bj�
On Jun 17, 10:13 am, Xah Lee <····@xahlee.org> wrote:
> [this post is a excerpt from
> The Modernization of Emacs
> ----------------------------------------
> SIMPLE CHANGES
At the command line, change "emacs" to "gvim"
http://pinard.progiciels-bpi.ca/opinions/editors.html
rd
On Jun 20, 4:21 pm, BartlebyScrivener <············@gmail.com> wrote:
> On Jun 17, 10:13 am, Xah Lee <····@xahlee.org> wrote:
>
> > [this post is a excerpt from
> > The Modernization of Emacs
> > ----------------------------------------
> > SIMPLE CHANGES
>
> At the command line, change "emacs" to "gvim"
Out of the frying pan and into the fire...
On Jun 20, 3:53 pm, Twisted <··········@gmail.com> wrote:
> On Jun 20, 4:21 pm, BartlebyScrivener <············@gmail.com> wrote:
>
> > On Jun 17, 10:13 am, Xah Lee <····@xahlee.org> wrote:
>
> > > [this post is a excerpt from
> > > The Modernization of Emacs
> > > ----------------------------------------
> > > SIMPLE CHANGES
>
> > At the command line, change "emacs" to "gvim"
>
> Out of the frying pan and into the fire...
Nah.
http://www.debian-administration.org/polls/89
[BartlebyScrivener <············@gmail.com>]
|
| http://www.debian-administration.org/polls/89
this is hardly surprising. I use both editors. for most sysadmin
tasks I use vi(m). for programming i use Emacs.
in part out of old habit (most UNIX systems had vi installed) and
partly because vi(m) is faster (which makes it more suitable when you
just need to change a couple of lines in a file).
for programming I use Emacs since I have a gazillion extensions I use
while programming that I don't even think about anymore. from various
forms of automated text completion to syntax checking/highlighting, to
enforcing style guides, look up symbol relationships, compile, debug
etc.
so if the context was system administration, I'd vote for vi as
well. if the context was programming I'd vote Emacs.
-Bj�
Bjorn Borud <··········@borud.no> writes:
> [BartlebyScrivener <············@gmail.com>]
> |
> | http://www.debian-administration.org/polls/89
>
> this is hardly surprising. I use both editors. for most sysadmin
> tasks I use vi(m). for programming i use Emacs.
>
> in part out of old habit (most UNIX systems had vi installed) and
> partly because vi(m) is faster (which makes it more suitable when you
> just need to change a couple of lines in a file).
The idea is to start Emacs once and use it for everything.
> so if the context was system administration, I'd vote for vi as
> well. if the context was programming I'd vote Emacs.
You know you can use something like
C-x C-f /su::/etc/fstab RET
(or /sudo::/etc/fstab) in order to edit files as root in a normal
Emacs session?
--
David Kastrup
On 2007-06-21, David Kastrup <···@gnu.org> wrote:
> You know you can use something like
> C-x C-f /su::/etc/fstab RET
> (or /sudo::/etc/fstab) in order to edit files as root in a normal
> Emacs session?
As I understand it, this will only work for ver 22 and later or if
you have tramp(?) installed. I have 2.3.1 (no tramp) and all I get is:
ftp> open su
ftp: su: Unknown host
I'm looking at upgrading to 22 for a couple other features, too.
nb
notbob <······@nothome.com> writes:
> On 2007-06-21, David Kastrup <···@gnu.org> wrote:
>
>> You know you can use something like
>> C-x C-f /su::/etc/fstab RET
>> (or /sudo::/etc/fstab) in order to edit files as root in a normal
>> Emacs session?
>
> As I understand it, this will only work for ver 22 and later or if
> you have tramp(?) installed. I have 2.3.1 (no tramp) and all I get is:
>
> ftp> open su
> ftp: su: Unknown host
I should think that version 2.3.1 would not even try ftp. Is that on
Multics?
> I'm looking at upgrading to 22 for a couple other features, too.
You'll find that the last 30 years of development indeed make a
difference.
--
David Kastrup
On 2007-06-21, David Kastrup <···@gnu.org> wrote:
>
> I should think that version 2.3.1 would not even try ftp. Is that on
> Multics?
Slackware 10.1
nb
David Kastrup <···@gnu.org> writes:
> I should think that version 2.3.1 would not even try ftp. Is that
> on Multics?
Note that the GNU Emacs version jumped directly from 1.12 to 13.
See etc/ONEWS.1.
Bjorn Borud <··········@borud.no> writes:
>> so if the context was system administration, I'd vote for vi as
>> well. if the context was programming I'd vote Emacs.
David Kastrup wrote:
> You know you can use something like
> C-x C-f /su::/etc/fstab RET
> (or /sudo::/etc/fstab) in order to edit files as root in a normal
> Emacs session?
I've been using emacs for something like twenty years and never knew that before.
I like the built-in therapist in emacs.
--
Lew
Lew <···@lewscanon.nospam> writes:
> Bjorn Borud <··········@borud.no> writes:
>>> so if the context was system administration, I'd vote for vi as
>>> well. if the context was programming I'd vote Emacs.
>
> David Kastrup wrote:
>> You know you can use something like
>> C-x C-f /su::/etc/fstab RET
>> (or /sudo::/etc/fstab) in order to edit files as root in a normal
>> Emacs session?
>
> I've been using emacs for something like twenty years and never knew
> that before.
The package "tramp" will provide that (as well as editing files over
ssh, scp, rsync, telnet, plink...). It is already preinstalled in
Emacs 22.1, but can also be installed for earlier versions.
--
David Kastrup
I just tried it: works for me.
Joel
David Kastrup <···@gnu.org> writes:
> Lew <···@lewscanon.nospam> writes:
>
>> Bjorn Borud <··········@borud.no> writes:
>>>> so if the context was system administration, I'd vote for vi as
>>>> well. if the context was programming I'd vote Emacs.
>>
>> David Kastrup wrote:
>>> You know you can use something like
>>> C-x C-f /su::/etc/fstab RET
>>> (or /sudo::/etc/fstab) in order to edit files as root in a normal
>>> Emacs session?
>>
>> I've been using emacs for something like twenty years and never knew
>> that before.
>
> The package "tramp" will provide that (as well as editing files over
> ssh, scp, rsync, telnet, plink...). It is already preinstalled in
> Emacs 22.1, but can also be installed for earlier versions.
>
> --
> David Kastrup
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest:
http://www.gnu.org/philosophy/sylvester-response.html
On Jun 21, 10:48 am, Lew <····@lewscanon.nospam> wrote:
> Bjorn Borud <··········@borud.no> writes:
> >> so if the context was system administration, I'd vote for vi as
> >> well. if the context was programming I'd vote Emacs.
> David Kastrup wrote:
> > You know you can use something like
> > C-x C-f /su::/etc/fstab RET
> > (or /sudo::/etc/fstab) in order to edit files as root in a normal
> > Emacs session?
>
> I've been using emacs for something like twenty years and never knew that before.
>
> I like the built-in therapist in emacs.
I think both of Lew's sentences here speak volumes.
One about the difficulty even supposed expert users can have with
tasks and finding things out from the help system. (I take it unix has
also still not caught up to the windows world in the concept of a "tip
of the day"?)
And both of them, though especially the latter, regarding what a
feeping creature emacs is. I don't suppose there's also a kitchen sink
in there somewhere? Or is that just nethack?
PS you'll have to stop posting such a high volume here. I'm getting BS
from Google Groups about posting limits being exceeded again.
Apparently they've lowered it still further, from 25 in a 24 hour
period to 12 or so in a 24 hour period. Fuckers.
··········@gmail.com writes:
> PS you'll have to stop posting such a high volume here. I'm getting
> BS from Google Groups about posting limits being exceeded again.
Oh, but that just means that _YOU_ will have to stop posting such a
high volume here. Others are not affected. Though I have no doubt
they'll welcome a thinning out of this thread (followups directed to
comp.emacs for that reason).
> Apparently they've lowered it still further, from 25 in a 24 hour
> period to 12 or so in a 24 hour period. Fuckers.
How about making _summary_ answers then? Your whole contributions
boil down to "You must be lying. This can't be Emacs you are talking
about, since I know Emacs intimately because of having looked at an
old version of it for half an hour about 10 years ago." anyway. You
don't need to post this 12 times per day. You don't even need to post
this at all. It does not get any less stupid by repetition.
What _is_ sort of amusing is that years ago you already accused me of
forgery when I pointed you to the Emacs screenshots on the
preview-latex
<URL:http://www.gnu.org/software/auctex/preview-latex.html> page.
It appears that you still have not bothered educating yourself, years
after you were pretty much universally derided in comp.text.tex for
making a spectacle of your self-chosen ignorance.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
In article <··············@lola.goethe.zz>, David Kastrup <···@gnu.org> wrote:
> ··········@gmail.com writes:
[ snip ]
> It appears that you still have not bothered educating yourself, years
> after you were pretty much universally derided in comp.text.tex for
> making a spectacle of your self-chosen ignorance.
Ah, I *thought* this discussion was starting to sound familiar.
"This is where I came in"?
(Reverting to the original set of newsgroups on the purely selfish
grounds of not wanting to follow an additional newsgroup, comp.emacs,
in order to read any replies.)
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
··········@gmail.com writes:
>
> And both of them, though especially the latter, regarding what a
> feeping creature emacs is.
I like it. Every new version has great new abilities.
> I don't suppose there's also a kitchen sink in there somewhere? Or is
> that just nethack?
Check out nethack.el <http://www.nongnu.org/nethack-el/>. You can run
nethack within emacs. This, of course, means that there _is_ a kitchen
sink within emacs (when it's running nethack within itself)...
--
Robert Uhl <http://public.xdi.org/=ruhl>
I don't think the Java folks are nuts for what they've done. I just
don't like how hard they make certain simple and important things.
--Kent M. Pitman
David Kastrup <···@gnu.org> writes:
> You know you can use something like
> C-x C-f /su::/etc/fstab RET
> (or /sudo::/etc/fstab) in order to edit files as root in a normal
> Emacs session?
I did not know that. That will save me huge amounts of time. You're
my hero.
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest:
http://www.gnu.org/philosophy/sylvester-response.html
On Thu, 21 Jun 2007 13:02:18 -0400, ········@partners.org (Joel J. Adamson) wrote:
>David Kastrup <···@gnu.org> writes:
>> You know you can use something like
>> C-x C-f /su::/etc/fstab RET
>> (or /sudo::/etc/fstab) in order to edit files as root in a normal
>> Emacs session?
>
> I did not know that. That will save me huge amounts of time. You're
> my hero.
If you like `C-x C-f /sudo::...', then it may also please you to know
that Tramp supports other remote access methods too, i.e.:
C-x C-f /ftp:
C-x C-f /ssh:
and it lets Emacs edit files in remote locations, as long as you have a
valid set of username/password credentials for the remote host :-)
[David Kastrup <···@gnu.org>]
|
| The idea is to start Emacs once and use it for everything.
...which is fine as long as you are only fiddling around on one
machine or you have emacs windows running on all your machines.
for my main use, I do start Emacs just once though. for instance at
work my Emacs has been running for as long as the machine has been up.
| > so if the context was system administration, I'd vote for vi as
| > well. if the context was programming I'd vote Emacs.
|
| You know you can use something like
| C-x C-f /su::/etc/fstab RET
| (or /sudo::/etc/fstab) in order to edit files as root in a normal
| Emacs session?
sure, but often it is just simpler, while you are fiddling around in a
shell, to just fire up vi to do some quick editing than to bounce back
and forth between windows. it is usually quicker too if you have to
navigate deep directory trees -- if you're already in the directory
where the file is, it'd be fewer keystrokes to specify the file than
opening it in emacs. even with tab-completion.
also, I make extensive use of the readline and history features when
fiddling about in the shell. shells have a lot of context if you use
them effectively. context that isn't easy to transport between the
shell and emacs -- and it isn't really easy to explain either.
-Bj�
[Followup-To: header set to comp.emacs]
Bjorn Borud wrote:
> sure, but often it is just simpler, while you are fiddling around in a
> shell, to just fire up vi to do some quick editing than to bounce back
> and forth between windows. it is usually quicker too if you have to
> navigate deep directory trees -- if you're already in the directory
> where the file is, it'd be fewer keystrokes to specify the file than
> opening it in emacs. even with tab-completion.
well, ok, typing `emacsclient <filename>' requires more keystrokes than `vi
<filename>', but that's why i have an alias ec for it...
--
Joost Kremers ············@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
Bjorn Borud <··········@borud.no> writes:
>
> | The idea is to start Emacs once and use it for everything.
>
> ...which is fine as long as you are only fiddling around on one
> machine or you have emacs windows running on all your machines.
Tramp can be used to access files on other hosts. It even supports
multi-hop stuff like 'ssh to $HOST and su to root.'
One thing GNU emacs needs to support is the ability to open a new X or
terminal window via a command. I think Xemacs can already do this.
> also, I make extensive use of the readline and history features when
> fiddling about in the shell. shells have a lot of context if you use
> them effectively. context that isn't easy to transport between the
> shell and emacs -- and it isn't really easy to explain either.
M-x shell, or M-x terminal
--
Robert Uhl <http://public.xdi.org/=ruhl>
That's just 'mostly dead.' What we are concerned with here is 'Pining
for the Fjords' dead. --Mark Urbin
On 17 Jun., 17:13, Xah Lee <····@xahlee.org> wrote:
Yaawn!
> Xah
> ····@xahlee.org
> ∑http://xahlee.org/
Hmm I just had to think about the C64/Amiga etc. game "California
Games"... The game displayed a comment when the player broke his neck
the 13th time when BMXing:
"Geek of the week!"
Karsten