basic question: going back to dired
Ben Aurel
This is my first post here, so I hope this is the right place for asking
beginner questions.
My question is simple: When I list some files in dired mode I select one
file to edit. Now how can I close this file and go back to dired without
closing emacs?
thanks
ben
Bastien
> My question is simple: When I list some files in dired mode I select one
> file to edit. Now how can I close this file and go back to dired without
> closing emacs?
Don't think in terms of "file". When editing a "file", you really edit
a buffer* containing the content of the file. To "close" the file
generally means to save the buffer and to kill the buffer.
If you just want to "go back" to dired, you just need to switch back to
the buffer containing the directory listing: C-x b RET
If you want to "close the file", then first save the buffer with C-x C-s
then kill the buffer with C-x k RET and you should be back to the buffer
containing the directory listing.
HTH,
* Press `C-x C-e' after the closing parenthesis to jump to the info page
describing the concept of "buffer" inside GNU Emacs:
(info "(emacs)Buffers")
--
Bastien
Xah
To close the file, use the menu “File‣Close”. Emacs doesn't have a
keyboard shortcut for this due the fact that emacs has build on the
1980's mindset and havn't modernized. But you can add one by putting
the following in your emacs preference file. (the file at “~/.emacs”):
(global-set-key (kbd "C-w") 'kill-this-buffer) ; close
This will let you press Ctrl+w to close the current file.
To switch to files or directories you have opened before, you can use
the menu “Buffers”. The “buffer” is term used in the 1980s. Today you
just call it “Tabs” or “workspace”.
So, for example, to switch to the previous tab, press Ctrl+x Ctrl+←.
(this is in the graphical menu Buffers too.)
For a tutorial that treats emacs with modern concepts and
terminologies, see:
http://xahlee.org/emacs/emacs.html
Xah
∑ http://xahlee.org/
☄
Xah
emacs's terminologies.
In particular, the term buffer is unsuitable and outdated. See the
following argument:
----------------------------
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 event 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”. (All modern
editors and IDEs use these terms, even though they are all buffers
too)
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, tabs, workspace, and keyboard
shortcuts”.
The reason emacs uses the technical terminologies throughout is
because when emacs started in the 1980s, there really isn't any other
text editors or even software applications. And, emacs users are all
computer scientists and programers.
Note that Emacs does officially recognize the term Keyboard Shortcut.
The following is a excerpt from glossary section of the official emacs
manual from emacs 22:
Keyboard Shortcut
A keyboard shortcut is a key sequence (q.v.) which invokes a
command. What some programs call "assigning a keyboard shortcut,"
Emacs calls "binding a key sequence." See `binding.'
-------------------
from “Modernization of Emacs”
http://xahlee.org/emacs/modernization.html
Xah
∑ http://xahlee.org/
☄
On Jul 21, 4:21 pm, Bastien <b...@altern.org> wrote:
Miles Bader
> My question is simple: When I list some files in dired mode I select one
> file to edit. Now how can I close this file and go back to dired without
> closing emacs?
C-x k RET
is one way.
[Don't pay too much attention to xahlee about keybindings -- he's
... kinda nuts on that issue...]
-MIles
--
We live, as we dream -- alone....
Bastien Guerry
> On Jul 21, 11:59 am, Ben Aurel <ben.au...@gmail.com> wrote:
>> hi
>> This is my first post here, so I hope this is the right place for asking
>> beginner questions.
>>
>> My question is simple: When I list some files in dired mode I select one
>> file to edit. Now how can I close this file and go back to dired without
>> closing emacs?
>
> To close the file, use the menu “File‣Close”. Emacs doesn't have a
> keyboard shortcut for this due the fact that emacs has build on the
> 1980's mindset and havn't modernized.
Or because the concept of "File" is not as central as the concept of
"buffer". It is not a question of being modern or not. In the 1980's
the notion of "file" already existed, and today, projects like OLPC are
putting it aside.
> (global-set-key (kbd "C-w") 'kill-this-buffer) ; close
Please don't suggest this.
`C-w' is for `kill-region' which is fundamental - see the manual
(info "(emacs)Killing")
When you're answering questions about Emacs, better to refer to the
manual as much as possible. At least more than your own tutorials,
which can give a biaised view about Emacs.
> The “buffer” is term used in the 1980s. Today you
> just call it “Tabs” or “workspace”.
Huh?
The notion of "buffer" might be emacs specific, but it's not 1980's.
The OP is asking about Emacs, not your own science fiction.
--
Bastien
Bastien Guerry
> I don't think its a good idea to teach or insist that people adopt
> emacs's terminologies.
Adopting Emacs terminology is not good per se, it's good because it
helps people adopt Emacs.
> In particular, the term buffer is unsuitable and outdated. See the
> following argument:
You're arguing like a lawyer: since you cannot change the law itself,
you're just trying to change the spirit of the law.
Please improve Emacs if you want to, it will be more constructive than
trying to change the "spirit" behind Emacs...
--
Bastien
Phil Carmody
> I don't think its a good idea to teach or insist that people adopt
> emacs's terminologies.
When discussing emacs? That's a rather bizarre thing to say.
> In particular, the term buffer is unsuitable and outdated. See the
> following argument:
>
> ----------------------------
>
> 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 event 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.
Blatant assertion I disagree with completely.
> As a user of a text editor, he works with files.
Blatant assertion I disagree with completely. As a user of a text
editor, I work with text. And I want it neatly buffered for me.
I may occasionally load some of the text from a file, and I may
occasionally save some of the text to a file, but the majority
of the buffers that I use never undergo either.
[SNIP - stuff I presume is either predicated upon your prior
unacceptable assertions, or introducing new ones.]
Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration
nak...@gmail.com
C-x k RET
closes a file. to switch between files you can use ibuffer
M-x ibuffer or you can bound it to a key.
(define-key global-map [(meta \])] 'ibuffer)
--
Nurullah Akkaya
Xah
> (global-set-key (kbd "C-w") 'kill-this-buffer) ; close
>
> This will let you press Ctrl+w to close the current file.
PS i forgot to mention, that Ctrl+w is emacs default shortcut to copy
text. So, if you set Close to Ctrl+w, then you should find another key
for Copy. You can set emacs to Copy by Ctrl+c, by going to the menu
“Options‣C-x/C-c/C-v Cut and Paste (CUA)”, Then use menu “Options‣Save
Options”.
For some details about these, see:
http://xahlee.org/emacs/emacs_make_modern.html
Xah
∑ http://xahlee.org/
☄
Juanma Barranquero
> Or because the concept of "File" is not as central as the concept of
> "buffer".
But Xah Lee is not arguing against the concept. He is arguing against
the terminology...
> The notion of "buffer" might be emacs specific, but it's not 1980's.
I don't think the notion of "buffer" is Emacs specific; as Xah Lee has
said, in other environments (editors, IDEs, etc.) they exist, it's
just that they exist under a different name ("workspace" being a nice
alternative).
Juanma
Juanma Barranquero
<thefatphi...@yahoo.co.uk> wrote:
> Xah <xah...@gmail.com> writes:
>> These terms are irrelevant to the users of a software application.
>
> Blatant assertion I disagree with completely.
In which way the use of terms like "keybinding" or "buffer" is
relevant to the *users* of a software application?
>> As a user of a text editor, he works with files.
>
> Blatant assertion I disagree with completely. As a user of a text
> editor, I work with text. And I want it neatly buffered for me.
> I may occasionally load some of the text from a file, and I may
> occasionally save some of the text to a file, but the majority
> of the buffers that I use never undergo either.
It is true that the user of a text editor works with text. It is also
true, I think, that most text is saved to a file, though nowadays I
suppose there's also a fair amount that is cut&paste'd into another
application, a web form, etc.
Emacs is not a text editor (exclusively): from eshell to dired to BBDB
to Gnus, many things can be done that do not match the text editor
profile; and for those, certainly many buffers are used that do not
correspond to a file in the filesystem. But I think it would be hard
to argue that, in its use as a *text editor*, common users have a
majority of buffers which are not associated to (and saved into) a
file at one point or another...
Juanma
Juanma Barranquero
> Adopting Emacs terminology is not good per se, it's good because it
> helps people adopt Emacs.
Adapting Emacs terminology to current conventions would perhaps be
good for the very same reason.
I'm not for or against changing Emacs' terminology. I think it would
be a huge amount of work. But I don't understand why some people
reacts as if the very idea is flawed. There's nothing sacred in
"buffer" and "keybinding" and "minibuffer", just history. The change
should be susceptible to rational (if perhaps a bit pointless)
discussion, because it is not hard to find good arguments for it;
"frame/window" vs "window/pane" is a good example.
Juanma
Phil Carmody
> On Tue, Jul 22, 2008 at 11:46, Phil Carmody
> <thefatphi...@yahoo.co.uk> wrote:
>> Xah <xah...@gmail.com> writes:
>
>>> These terms are irrelevant to the users of a software application.
>>
>> Blatant assertion I disagree with completely.
>
> In which way the use of terms like "keybinding" or "buffer" is
> relevant to the *users* of a software application?
I, as a user of the software application called "emacs"
must be familiar with that functions are bound to what
keys in order to use that software application.
For buffers, see below.
I'd have thought the above response would have been so bloody
obvious that I'm amazed you even bothered asking the question.
The only way I can see you not expecting such a response is
if you are of the opinion that I am not a user of emacs, or
that you think emacs is not a software application. Either of
which is equally bizarre.
>>> As a user of a text editor, he works with files.
>>
>> Blatant assertion I disagree with completely. As a user of a text
>> editor, I work with text. And I want it neatly buffered for me.
>> I may occasionally load some of the text from a file, and I may
>> occasionally save some of the text to a file, but the majority
>> of the buffers that I use never undergo either.
>
> It is true that the user of a text editor works with text. It is also
> true, I think, that most text is saved to a file, though nowadays I
> suppose there's also a fair amount that is cut&paste'd into another
> application, a web form, etc.
An absolute assertion is false as soon as one counter-example
is found. An absolute assertion was made. I provided a counter-
example. The assertion is therefore false. End of.
Juanma Barranquero
> And why should "shortcut" be more fitting than "keybinding"?
I don't know. I'm not even defending the idea that "shortcut" is more
fitting. If anything, I'm defending the idea that "keybinding" is not
very good, not because of any intrinsic quality or defect of the term
"keybinding", just because it is a bit too specifically emacsy for
something that many other programs allow, under a different name. The
best name is the one the users understand more easily (whichever it
may be).
> Emacs does lots more than text editing, and the term
> "buffer" fits fine for all the tasks, where term "file" doesn not.
The term "workspace" fits even better, don't you think? And, what does
think the average user who does intuitively know (I believe) what a
"work space" could be, but not necessarily what a "buffer" is?
> That is called "loosing generality", at least in Spanish, which you
> know.
In my Castilian Spanish it'd be more like "perder generalidad", but I
get your meaning ;-)
> You say that there are only historical reasons for sticking to Emacs
> terminology.
Sorry, but no, I didn't say that. I said:
> There's nothing sacred in
> "buffer" and "keybinding" and "minibuffer", just history.
Of course there are at least two reasons, other than history, to stick
with the statu quo: lack of resources, and existing users' resistance.
:)
I get the feeling that if Emacs had used "shortcut" and "workspace"
since the beginning of (Emacs) times, and the current trend were to
use "keybinding" and "buffer", some old Emacs hands would react
against the idea of change the very same way they do now.
> It's
> all about considering that users (and in particular a user able to deal with
> Emacs: this is not Notepad, ok?) can't deal with remembering what "buffer"
> means, which is nonsense.
Sorry, I don't buy that argument. Of course adopting a commonly used
terminology would help those that are not yet "able to deal with
Emacs". Standards (like the CUA C-x/C-c/C-v keyb... shortc...
whatevers) exist for a reason.
> Juanma (yeah, me too)
Not only that, we're both Juanma B.*
Juanma Ba.*
Thierry Volpiatto
> C-x k RET
Alternatively, you can use quit-window that allow to quit window without
killing buffer (with arg t, it will quit and kill buffer)
,----[ C-h f quit-window RET ]
| quit-window is an interactive compiled Lisp function in `window.el'.
|
|
| (quit-window &optional kill window)
|
| Quit the current buffer. Bury it, and maybe delete the selected frame.
| (The frame is deleted if it contains a dedicated window for the buffer.)
| With a prefix argument, kill the buffer instead.
|
| Noninteractively, if kill is non-nil, then kill the current buffer,
| otherwise bury it.
|
| If window is non-nil, it specifies a window; we delete that window,
| and the buffer that is killed or buried is the one in that window.
|
| [back]
`----
> closes a file. to switch between files you can use ibuffer
>
> M-x ibuffer or you can bound it to a key.
>
> (define-key global-map [(meta \])] 'ibuffer)
--
A + Thierry Volpiatto
Location: Saint-Cyr-Sur-Mer - France
Miles Bader
>> And why should "shortcut" be more fitting than "keybinding"?
>
> I don't know. I'm not even defending the idea that "shortcut" is more
> fitting. If anything, I'm defending the idea that "keybinding" is not
> very good, not because of any intrinsic quality or defect of the term
> "keybinding"
It's not that "keybinding" is somehow extra good, it's that "shortcut"
is unusually bad.
The name "shortcut" in most apps carries the implication that it's
somehow an unusual method of invoking something, which is only used in
rare circumstances for the absolute most heavily used commands (in these
apps, the "usual" method is a menu entry). This is not true in emacs --
keybindings are heavily used, and are "normal".
-Miles
--
Yo mama's so fat when she gets on an elevator it HAS to go down.
Nikolaj Schumacher
> I don't think its a good idea to teach or insist that people adopt
> emacs's terminologies.
I don't think its a good idea to teach or insist that people learn
French before going to Paris. French is a language that has been
adopted by France in the 1530s when there really weren't any other other
languages around, except big mainframe languages like Latin. In the
20th century English developed as a
> The reason emacs uses the technical terminologies throughout is
> because when emacs started in the 1980s, there really isn't any other
> text editors or even software applications. And, emacs users are all
> computer scientists and programers.
I think it's a ridiculous idea to teach someone English before going to
Paris. Of course English is spoken pretty much everywhere in the world,
and it would arguably easier to stay in Paris if the
regards,
Nikolaj Schumacher
Lennart Borgman (gmail)
Yes, the definition of "key binding" in Emacs is in itself quite good,
but that does not help new users that are used to the word "shortcut"
for similar things in other programs.
At least it did not help me.
Nikolaj Schumacher
premature sending. :)
Xah <xah...@gmail.com> wrote:
> I don't think its a good idea to teach or insist that people adopt
> emacs's terminologies.
I don't think its a good idea to teach or insist that people learn
French before going to Paris. French is a language that has been
adopted by France in the 1530s when there really weren't any other other
languages around, except big mainframe languages like Latin. In the
20th century English developed as a lingua franca, yet the French failed
to modernize. They use technical terms that don't make sense to the
non-linguist, like ^Ile de France. It can't even be spelled by a
modern-language system.
So, whenever friends of mine visit Paris, give them my favorite English
phrases book, so they'll get by. Teaching them words like "oui" would
only encourage the French...
Now seriously, Xah. You've posted that link to your website a lot
recently. And usually I don't mind, because it was at least somewhat
relevant. But there is a place for discussing enhancements to Emacs.
Beginner's questions aren't it. They don't even have an interest in
modernizing Emacs, because they could just as well start using a
"modern" editor in the first place. And those of us who used Emacs
long enough are apparently not bothered too much by the terminology to
change it. There's no need to bring it up again and again.
regards,
Nikolaj Schumacher
Nikolaj Schumacher
>> It's not that "keybinding" is somehow extra good, it's that "shortcut"
>> is unusually bad.
>>
>> The name "shortcut" in most apps carries the implication that it's
>> somehow an unusual method of invoking something, which is only used in
>> rare circumstances for the absolute most heavily used commands (in these
>> apps, the "usual" method is a menu entry). This is not true in emacs --
>> keybindings are heavily used, and are "normal".
>
> Yes, the definition of "key binding" in Emacs is in itself quite good,
> but that does not help new users that are used to the word "shortcut"
> for similar things in other programs.
>
> At least it did not help me.
Of course the term shortcuts is something reminiscent of GUI programs.
In a text editor menu entries like `compile' might have a shortcut, but
calling C-b a shortcut seems weird.
I don't think there even has to be a name for it ... Help says: "It is
bound to C-b, <left>.", which sounds reasonable. So what problems could
a new user have? I can think only of one: Finding out _how_ to configure
the keys.
I just took a look at Eclipse (because that happened to be installed)
and it doesn't talk about shortcuts in the preferences, either. It just
has a table with "command" and "key sequence" on a page called "Keys",
yet its easy to find, because it's in a central place.
Maybe custom should support keymaps, and M-x customize-keys could solve
that problem...
regards,
Nikolaj Schumacher
Dan Davison
> On Tue, Jul 22, 2008 at 13:50, Juanma <juanma_bellon> wrote:
>
>
> I don't know. I'm not even defending the idea that "shortcut" is more
> fitting. If anything, I'm defending the idea that "keybinding" is not
> very good, not because of any intrinsic quality or defect of the term
> something that many other programs allow, under a different name. The
> best name is the one the users understand more easily (whichever it
> may be).
Oh, I don't think I agree with that sort of lowest-common-denominator
linguistic relativism at all! That sort of attitude, combined with
neutral drift over time will result in a terrible, ugly, language with
no accuracy or etymological coherency whatsoever!
DAn
Lennart Borgman (gmail)
> Of course the term shortcuts is something reminiscent of GUI programs.
> In a text editor menu entries like `compile' might have a shortcut, but
> calling C-b a shortcut seems weird.
Maybe, but having manual entries in the index for "Shortcut" and "Key
Sequence" would perhaps help a little bit.
> I don't think there even has to be a name for it ... Help says: "It is
> bound to C-b, <left>.", which sounds reasonable. So what problems could
> a new user have?
My imagination and experience says me that they could have trouble
searching for things because of the terminology ;-)
> Maybe custom should support keymaps, and M-x customize-keys could solve
> that problem...
That would be great yes.
Juanma Barranquero
<thefatphi...@yahoo.co.uk> wrote:
> I, as a user of the software application called "emacs"
> must be familiar with that functions are bound to what
> keys in order to use that software application.
Which is *absolutely* unrelated to whether that relationship between
keystroke and function can be found in the manual and documentation
under "keybinding" or "shortcut" or "key assignment" or any other
name. Which is what was being discussed.
> An absolute assertion is false as soon as one counter-example
> is found. An absolute assertion was made. I provided a counter-
> example.
Oh, I don't think so. Go figure.
Juanma
Juanma Barranquero
> It's not that "keybinding" is somehow extra good, it's that "shortcut"
> is unusually bad.
Agreed. I don't like Xah Lee's proposals. But I think that he's right
that Emacs' use of outdated terminology sometimes hampers adoption by
new users.
Juanma
Phil Carmody
> On Tue, Jul 22, 2008 at 13:50, Phil Carmody
> <thefatphi...@yahoo.co.uk> wrote:
>
>> I, as a user of the software application called "emacs"
>> must be familiar with that functions are bound to what
>> keys in order to use that software application.
>
> Which is *absolutely* unrelated to whether that relationship between
> keystroke and function can be found in the manual and documentation
> under "keybinding" or "shortcut" or "key assignment" or any other
> name. Which is what was being discussed.
Well, if I didn't know what the keys did, I certainly would
look under 'k' for 'key' in the manual, and been prepared to
follow any lead that looked anything like 'key bindings' or
'kep mappings'. So the fact that I view them as key bindings
is entirely related to where I'd hope to find documentation
of them in the manual.
>> An absolute assertion is false as soon as one counter-example
>> is found. An absolute assertion was made. I provided a counter-
>> example.
>
> Oh, I don't think so. Go figure.
I figure that you should have stopped that first sentence after
only 4 words.
xraysm...@gmail.com
"keybinding" is a little weird and kinky, but "shortcut" is a blatant
lie in Emacs -- once I've managed to hit "Ctrl-Alt-Shift-Win*-x RET
butterfly", any pretense of saving time has gone out the window.
I use Emacs because I like how it feels; I use keybindings because
they remind me I'm alive...
*oh g-d, know you all know my dirty little platform secret :-(
But, seriously folks. Keybinding and shortcut keys -- roughly the
same. Now, shake hands.
--the Other michael
Juanma Barranquero
> Oh, I don't think I agree with that sort of lowest-common-denominator
> linguistic relativism at all! That sort of attitude, combined with
> neutral drift over time will result in a terrible, ugly, language with
> no accuracy or etymological coherency whatsoever!
Not linguistic relativism, but descriptivism against prescriptivism.
I'm firmly in the descriptivist side. I don't think a spoken, live
language can be "ugly", and accuracy and etymological coherency are
two ways of say stagnation.
Juanma
Phil Carmody
> On Tue, Jul 22, 2008 at 15:56, Juanma <juanma_bellon> wrote:
>
>> Well, maybe it's too "Unixy" (if I may), but then remove the "too" because
>> I'm in Linux.
>
> For software, being too ANYTHING is usually a drawback for new users
> coming from the complementary set of ANYTHING...
>
>> When I started
>> learningน Emacs, I had to learn what is a buffer, and if the manual had been
>> s/buffer/workspace/ all along, I would have had to learn what workspace
>> means just the same. Same effort, and buffer is easier to pronounce.
>
> The point is, "workspace" is used more often than "buffer" for the
> same concept, so even if that is your experience, it is reasonable to
> expect that it'll be different for many other people.
But 'workspace' has been used in a window-manager context for
longer than any of the modern IDEs that use the term have been
around. It also seems that some applications define the workspace
to be their entire window, inside which many MDI sub-windows
can reside. Both of these uses conflict with a usage where it
is synonymous to emacs' use of 'buffer'.
Juanma Barranquero
<thefatphi...@yahoo.co.uk> wrote:
> Well, if I didn't know what the keys did, I certainly would
> look under 'k' for 'key' in the manual, and been prepared to
> follow any lead that looked anything like 'key bindings' or
> 'kep mappings'.
Because these are self evident terms, of course.
> I figure that you should have stopped that first sentence after
> only 4 words.
Yes, why use logic when rudeness will suffice?
Juanma
Evans Winner
I'm not for or against changing Emacs' terminology. I
think it would be a huge amount of work. But I don't
understand why some people reacts as if the very idea is
flawed. There's nothing sacred in "buffer" and
"keybinding" and "minibuffer", just history. The change
should be susceptible to rational (if perhaps a bit
pointless) discussion, because it is not hard to find
good arguments for it; "frame/window" vs "window/pane"
is a good example.
The issue is not history or short-term convenience for new
users but precision. Emacs does not use workspaces or
panes, but buffers. A user who wants to write a little code
to do something useful needs to know that essentially the
same function that is used to open a file and write text in
it manually is what is used to create any buffer, even one
that never displays anything, has some processing go on in
it and then vanishes--that the display of data in a buffer
is a separate thing from the data structure itself; or why
some buffers are associated with files and others, like
completion buffers have no file associated with them, and
how to write programs that take advantage of the same
functionality.
A person who has been told that he is working with
``windows'' (meaning buffers in Emacs) is thus conceptually
crippled if he wants to do something that could be done with
buffers other than using them as windows. Xah Lee has
written about the danger of excessive use of jargon in
computer work and I generally agree with him, but even more
dangerous is the use of metaphor. A metaphor, like
``workspace'' only tells you as much about a thing as the
inventor of the metaphor wanted you to know, but makes it
impossible to extend your understanding past that.
If the term keybinding ought to be changed to anything it
should be rather something like input-binding (since
function execution can be triggered by any form of input,
not just keyboard presses) than ``shortcut'' or whatever
such woozy nonsense.
Phil Carmody
> On Tue, Jul 22, 2008 at 16:49, Phil Carmody
> <thefatphi...@yahoo.co.uk> wrote:
>
>> Well, if I didn't know what the keys did, I certainly would
>> look under 'k' for 'key' in the manual, and been prepared to
>> follow any lead that looked anything like 'key bindings' or
>> 'kep mappings'.
>
> Because these are self evident terms, of course.
Does that mean you now tacitly accept that what I posted was
related to what was being discussed? If so, your snipping
of the sentence that followed the above quote was most rude.
>> I figure that you should have stopped that first sentence after
>> only 4 words.
>
> Yes, why use logic when rudeness will suffice?
PKB.
Bastien Guerry
> On Tue, Jul 22, 2008 at 10:23, Bastien Guerry <b...@altern.org> wrote:
>
>> Or because the concept of "File" is not as central as the concept of
>> "buffer".
>
> But Xah Lee is not arguing against the concept. He is arguing against
> the terminology...
My sentence above was a reaction to Xah's sentence:
"Emacs doesn't have a keyboard shortcut for this due the fact that
emacs has build on the 1980's mindset and havn't modernized."
I think that the reason Emacs doesn't have a keybinding for "Close"
is because the concept of a buffer is more central to Emacs than the
concept of a file.
Open/Close is bound to file manipulation, and many buffer manipulations
are not related to files at all - think of dired, for example.
>> The notion of "buffer" might be emacs specific, but it's not 1980's.
>
> I don't think the notion of "buffer" is Emacs specific; as Xah Lee has
> said, in other environments (editors, IDEs, etc.) they exist, it's
> just that they exist under a different name ("workspace" being a nice
> alternative).
I don't think "buffer" and "workspaces" are synonymous, and I don't
think there is anything wrong with the current use of "buffer".
--
Bastien
Lennart Borgman (gmail)
> PKB.
If you want to be funny you have to explain ;-) I have no idea what PKB
stands for. I looked it up and it is right above PLS=please. But that
"Pot, Kettle, Black" sounds like some child song or something that
non-english natives like me never heard.
Bastien Guerry
> On Tue, Jul 22, 2008 at 10:26, Bastien Guerry <b...@altern.org> wrote:
>
>> Adopting Emacs terminology is not good per se, it's good because it
>> helps people adopt Emacs.
>
> Adapting Emacs terminology to current conventions would perhaps be
> good for the very same reason.
Yes, as long as the terminology matches the underlying concepts.
For example, replacing "buffer" by "workspace" in the manual would not
only be a huge work, it would also be misleading: because you would soon
have to deal with expectations that people already have with the notion
of "workspace". So instead of saying "A workspace in Emacs is like the
one you have in Eclipse, but there is a difference..." - why not stick
to history?
> I'm not for or against changing Emacs' terminology. I think it would
> be a huge amount of work. But I don't understand why some people
> reacts as if the very idea is flawed.
I do react about terminology because I think such a discussion is never
about terminology only. It's also about the concepts behind. If Emacs
were more file-centric, then I wouldn't understand why there is no
shortcut (sic!) to Open/Close.
> There's nothing sacred in "buffer" and "keybinding" and "minibuffer",
> just history. The change should be susceptible to rational (if perhaps
> a bit pointless) discussion, because it is not hard to find good
> arguments for it; "frame/window" vs "window/pane" is a good example.
Ok, history always comes with some arbitrary choice. But it's hard to
move from an arbitrary choice with a non-arbitrary reason.
--
Bastien
Bastien Guerry
> In which way the use of terms like "keybinding" or "buffer" is
> relevant to the *users* of a software application?
In the same way that the manual page (info "(Emacs)Buffers") is relevant
to the users. This is why I mentioned this page in my reply, I thought
it would be useful for the OP to know more about buffers.
> But I think it would be hard to argue that, in its use as a *text
> editor*, common users have a majority of buffers which are not
> associated to (and saved into) a file at one point or another...
Or maybe we can take this from another perspective?
How many users are complaining about the fact that it's not easy to open
and close a file with Emacs? As long as this is not a *major* problem,
let's not consider whether it's good or not to change Emacs terminology.
No?
--
Bastien
Bastien Guerry
> On Tue, Jul 22, 2008 at 14:34, Miles Bader <miles...@necel.com> wrote:
>
>> It's not that "keybinding" is somehow extra good, it's that "shortcut"
>> is unusually bad.
>
> Agreed. I don't like Xah Lee's proposals. But I think that he's right
> that Emacs' use of outdated terminology sometimes hampers adoption by
> new users.
Maybe, but we need more _facts_ about this.
We know what would be the cost of any terminology change (even the heat
of this discussion is a good indicator :) but we are not sure about the
benefit. I have a feeling this is just a bad bargain...
--
Bastien
Bastien Guerry
> Do you really think that C-x C-c is good and Alt-F4 is bad?
Yes :-) `C-x' is the prefix for fundamental functions, and obviously
`save-buffers-kill-terminal' is one of them. `C-c' is about quitting,
not only in Emacs. I cannot think of something better than `C-x C-c'.
Compared to this, Alt-F4 looks quite arbitrary to me.
Anyway, we forgot the OP. Maybe his opinion counts more than our "old
sport" rants!
--
Bastien
Xah
thought i just write one post.
• among the alternative terms for buffer: tabs, panel, window, work
space..., i think tabs is a good candidate. Originally i was thinking
where emacs used the term “buffer” in its manual, it could be replaced
by one of the term above depending on context. But i think “tabs”
would work for most. This can be coupled with incorporating the tabbar
mode into emacs by default. (done last month in Aquamacs)
• It doesn't take much work to make these changes. For the ones i
suggested in the modernization article, it would take just one single
elisp programer few hours to make all the suggested changes. Consider
all the little problems here and there that might turn up when
actually working into a final product, it might be a total of say, a
week's work.
• Note that in commercial orgs, major change that's a few order of
magnitude more difficult has done in response to the changing
industry. A good example is Apple computer, in its Motorola chip to
PPC in ~1995, Mac OS 9 to OSX in ~2001, and PPC to Intel chip in
~2006. (in the first couple of years of these changes, there are huge
resistance from mac communities, organized “Open Letters” opposition
sites to apple, huge number of online complaints, criticisms from Mac
magazines etc.)
• note that emacs's user base has eroded from perhaps more than 50%
market share among all editors/IDEs, to today maybe 10%, or perhaps
even less than 1% among all professional programers. (professional
programer here is defined as those who makes a living by coding; which
what we might call “inexperienced” programers such as those coding in
HTML/CSS, PHP, the millions of game scripters, CAD scripters and other
niches, scientists and engineers who write code as part of their work.
It's a bit hard to define but i think these people may actually be
more than 50% of professional programers. Most of these people, if
they post to newsgroup (if they knew what's a newsgroup at all), would
probably be flamed to death.)
• Emacs has kill-buffer, which asks users a buffer to kill, with a
default suggestion for the current buffer. The Close menu command runs
kill-this-buffer, which is what Close menu command is for in almost
every application in Mac, Windows, Linux. The kill-this-buffer command
closes the current buffer without asking (unless it is not saved, of
course). The kill-this-buffer does not have a shortcut by default.
The Close command doesn't have a default shortuct. In practice, i
think it induced a operation habit to have hundreds of past buffers
left open. The problem with leaving buffers is that it makes buffer
listing/switching facilities much less useful. This is rather common
complaint even among emacs old timers
(i myself, being somewhat a classic nerd, adopted wholly emacs's ways
and terms in the very beginning, using emacs in pure text terminal
only for the first 5 years. However, i do have a habit to always close
buffers once i've finished working with it. So, i always did C-k
Return and find it too many keystrokes. Only in recent years of elisp
study i had workaround with somewhat extensive self-made
customization)
• i do wish to keep gun.emacs.help to be very focused on technical Q&A
and avoid opinions oriented discussions. I enjoy reading
gnu.emacs.help that way, and i think comp.emacs can be more open to
discussions and opinion oriented posts. What made me reply here was
that posts that seems to want to emphasize the emacs ways as better
way, which in my opinion, prevents the modernization of emacs.
Xah
∑ http://xahlee.org/
☄
Phil Carmody
It's indeed short for "Pot calling the kettle black",
implying the recipient has a hypocritical attitude.
Bastien
> The kill-this-buffer does not have a shortcut by default.
Please suggest a keybinding for this command.
> The Close command doesn't have a default shortuct. In practice, i
> think it induced a operation habit to have hundreds of past buffers
> left open. The problem with leaving buffers is that it makes buffer
> listing/switching facilities much less useful.
I'm not under this impression. I think the listing (C-x C-b) facility
is useful because working on many buffers is permitted. And switching
(C-x b) is easy thanks to completion. Ido-mode can also help here.
> This is rather common complaint even among emacs old timers
References!
> Only in recent years of elisp study i had workaround with somewhat
> extensive self-made customization)
Maybe intensive customization leave each one of us with the impression
that his/her customization is the best for everyone and should be the
default. I personally don't think it's a good idea to rebind C-w, for
example.
> What made me reply here was that posts that seems to want to emphasize
> the emacs ways as better way, which in my opinion, prevents the
> modernization of emacs.
My post didn't contain such valuative considerations.
--
Bastien
Juanma Barranquero
> The issue is not history or short-term convenience for new
> users but precision. Emacs does not use workspaces or
> panes, but buffers.
Looking up "buffer", the closest meaning I find is:
"(computer science) a part of RAM used for temporary storage of data
that is waiting to be sent to a device; used to compensate for
differences in the rate of flow of data between components of a
computer system"
which is not exactly the meaning used in Emacs, because, as has been
pointed out, many "buffers" are used to store data that will never be
sent to a device.
Whether "workspace" is a better term or not is largely irrelevant; on
one hand, because the discussion is about whether better terms could
be used, not a defense of specific ones; and, on the other hand,
because, after emacs -Q,
(let ((x 0))
(mapatoms (lambda (sym)
(when (string-match-p "buffer" (symbol-name sym))
(setq x (1+ x)))))
x)
=> 660
so it will never be changed.
> A person who has been told that he is working with
> ``windows'' (meaning buffers in Emacs) is thus conceptually
> crippled if he wants to do something that could be done with
> buffers other than using them as windows.
I've never seen "window" suggested as a substitute of "buffer", but of
(Emacs) "frame", because what Emacs calls a frame is usually called a
window in most environments.
> A metaphor, like
> ``workspace'' only tells you as much about a thing as the
> inventor of the metaphor wanted you to know, but makes it
> impossible to extend your understanding past that.
"Buffer" is also a metaphor.
> If the term keybinding ought to be changed to anything it
> should be rather something like input-binding (since
> function execution can be triggered by any form of input,
> not just keyboard presses) than ``shortcut'' or whatever
> such woozy nonsense.
Something like it. But less obscure. And, for the record, I don't like
shortcut at all.
Juanma
Juanma Barranquero
> My sentence above was a reaction to Xah's sentence:
>
> "Emacs doesn't have a keyboard shortcut for this due the fact that
> emacs has build on the 1980's mindset and havn't modernized."
Even so, I don't think he was arguing against the *concept* of buffers.
> I don't think "buffer" and "workspaces" are synonymous, and I don't
> think there is anything wrong with the current use of "buffer".
We'll have to disagree, at least partially.
Juanma
Juanma Barranquero
> Yes, as long as the terminology matches the underlying concepts.
The underlying concept is called a "buffer" because... well, just
because it has always been called that on Emacs. "scratchpad" would
have been equally valid, or "workspace" (we're talking more than 20
years ago, before the current wave of IDEs), or "temporary store" or
who knows what.
> For example, replacing "buffer" by "workspace" in the manual would not
> only be a huge work, it would also be misleading: because you would soon
> have to deal with expectations that people already have with the notion
> of "workspace".
Why the fixation with "workspace"?
> So instead of saying "A workspace in Emacs is like the
> one you have in Eclipse, but there is a difference..." - why not stick
> to history?
We're bound to stick with history. But it is nice (and perhaps even
useful, in some way) to think what benefit would we gain by using a
more common terminology. At least that will compel us to choose more
adequate names for new features.
> I do react about terminology because I think such a discussion is never
> about terminology only. It's also about the concepts behind. If Emacs
> were more file-centric, then I wouldn't understand why there is no
> shortcut (sic!) to Open/Close.
I cannot speak on behalf of others, but certainly I'm talking
exclusively about terminology.
> Ok, history always comes with some arbitrary choice. But it's hard to
> move from an arbitrary choice with a non-arbitrary reason.
It's hard to move from an arbitrary, deeply ingrained choice, even if
it'd be useful to do so.
Juanma
Juanma Barranquero
> In the same way that the manual page (info "(Emacs)Buffers") is relevant
> to the users.
Well, yes, but that's a bit of circular reasoning. Of course the
current terminology is relevant, because it *is* the current
terminology, after all. That does not mean that the user cares about
the precise term, as long as s/he understands it.
> How many users are complaining about the fact that it's not easy to open
> and close a file with Emacs? As long as this is not a *major* problem,
> let's not consider whether it's good or not to change Emacs terminology.
>
> No?
I don't see the relevance of that question (my fault, I'm sure). I was
under the impression that the relevant question would be: "how much
difficult is for beginners to learn Emacs when they read about buffers
and frames and keybindings, instead of X and Y and Z?" [where X, Y and
Z are suitable terms commonly used in other environments]
Juanma
Juanma Barranquero
> We know what would be the cost of any terminology change (even the heat
> of this discussion is a good indicator :) but we are not sure about the
> benefit. I have a feeling this is just a bad bargain...
Not only I agree, but I've said it repeatedly.
Juanma
Xiao-Yong Jin
And I really don't like this whole "modernization" idea. I
believe those terms we use in emacs has a long history, as
well as those key bindings and others. Saying changes is
like driving everybody who has already adopt these
terminologies nuts. Customization is what emacs is.
Enforcing some kind of customization, which certain people
feels comfortable for themselves, is not what emacs should
be. What makes it worse is that certain people actually
think that their customization is far superior then everyone
else' and even want to call it "modernization". I think
most of the old users felt really intrusive when they found
that the transient-mark-mode was turned on by default.
Of course the emacs community welcomes new functionality.
There is already cua-mode. Personally, I will never use
it. But it is there for those people who want those so
called "modernized" behavior. I believe emacs is such a
thing that if you believe your "modernized-mode" is good,
you can release it as a elisp package and put it on the
wiki. You can advertise it here but there is absolutely no
point to debate about what kind of customization is good on
this mailing list/news group.
Back to the terminologies. I believe most of the people who
read English can understand those by reading info.
Introducing new terms, or so called "modernized" terms to
old emacs concepts is rather like shooting on your own foot.
And most importantly, we really don't want to cause any more
misunderstandings by using different terms to refer to same
thing.
Here is my opinion. People can have their own customization
or their own languages. But enforcing these personalized
thing on other people is simply nonsense.
Cheers,
Xiao-Yong
--
c/* __o/*
<\ * (__
*/\ <
Pascal J. Bourguignon
> I'm a normal emacs user who has been using it for 4 years.
> And I really don't like this whole "modernization" idea.
Don't worry. Xah Lee is just a nut making a lot of noise. Some would
say a troll, most already have kill-filed him.
Nobody is doing any "modernization" of emacs.
--
__Pascal Bourguignon__ http://www.informatimago.com/
COMPONENT EQUIVALENCY NOTICE: The subatomic particles (electrons,
protons, etc.) comprising this product are exactly the same in every
measurable respect as those used in the products of other
manufacturers, and no claim to the contrary may legitimately be
expressed or implied.
Bastien Guerry
> On Tue, Jul 22, 2008 at 18:53, Bastien Guerry <b...@altern.org> wrote:
>
>> Yes, as long as the terminology matches the underlying concepts.
>
> The underlying concept is called a "buffer" because... well, just
> because it has always been called that on Emacs. "scratchpad" would
> have been equally valid, or "workspace" (we're talking more than 20
> years ago, before the current wave of IDEs), or "temporary store" or
> who knows what.
But we're not discussing about what could have been done 20 years ago,
are we? Discussing the terminology today, my point is that it might be
risky to "import" some terms just because they are commonly used
elsewhere. If they give the right representation of the thing they
refer to, why not.
>> For example, replacing "buffer" by "workspace" in the manual would not
>> only be a huge work, it would also be misleading: because you would soon
>> have to deal with expectations that people already have with the notion
>> of "workspace".
>
> Why the fixation with "workspace"?
Because it's an example of what could seem to be a good candidate for
replacing buffer. But I think that the representations an Eclipse user
has of a workspace doesn't designate the notion of a buffer adequately.
> We're bound to stick with history. But it is nice (and perhaps even
> useful, in some way) to think what benefit would we gain by using a
> more common terminology. At least that will compel us to choose more
> adequate names for new features.
Sure - I'm just pointing possible pittfalls.
>> I do react about terminology because I think such a discussion is never
>> about terminology only. It's also about the concepts behind. If Emacs
>> were more file-centric, then I wouldn't understand why there is no
>> shortcut (sic!) to Open/Close.
>
> I cannot speak on behalf of others, but certainly I'm talking
> exclusively about terminology.
Okay, but terminology and concepts are often intertwingled.
That's all the fun of such discussions.
>> Ok, history always comes with some arbitrary choice. But it's hard to
>> move from an arbitrary choice with a non-arbitrary reason.
>
> It's hard to move from an arbitrary, deeply ingrained choice, even if
> it'd be useful to do so.
If it's too hard, it can't be that useful...
--
Bastien
Juanma Barranquero
> But we're not discussing about what could have been done 20 years ago,
> are we? Discussing the terminology today, my point is that it might be
> risky to "import" some terms just because they are commonly used
> elsewhere. If they give the right representation of the thing they
> refer to, why not.
Well, I'm discussing about what the consequences are of the choices of
20 years ago, and whether we should be careful in the future (now that
tabs and other IDE-like features are being discussed in emacs-devel).
> Because it's an example of what could seem to be a good candidate for
> replacing buffer. But I think that the representations an Eclipse user
> has of a workspace doesn't designate the notion of a buffer adequately.
OK, though I think that's giving too much credit to Eclipse.
> Sure - I'm just pointing possible pittfalls.
Yes. Thanks for rational, rudeness-free discussion.
> Okay, but terminology and concepts are often intertwingled.
> That's all the fun of such discussions.
;-)
> If it's too hard, it can't be that useful...
Exaggerating a bit (OK, a *lot*), that's like saying that solving the
world famines is not useful because it is hard.
Juanma
Lennart Borgman (gmail)
> Of course the emacs community welcomes new functionality.
> There is already cua-mode.
cua-mode and viper-mode are two examples of customizations that are
extremely good. I use them both.
> I believe emacs is such a
> thing that if you believe your "modernized-mode" is good,
> you can release it as a elisp package and put it on the
> wiki.
If you look into the details of the code you will find that it is often
not that easy. Making cua-mode and viper-mode good citizens in Emacs has
required quite a lot of efforts to make room for them.
Smaller, not that complicated packages (or perhaps rather packages that
does not interfer that much with other parts) can be created outside of
Emacs.
Larger efforts is very hard to do outside - if no one has been smart
enough to offer very good and flexible support inside Emacs. Some people
are able to work around those difficulties, but it looks very difficult
to me (mostly thinking about CEDET).
Bastien Guerry
>> How many users are complaining about the fact that it's not easy to open
>> and close a file with Emacs? As long as this is not a *major* problem,
>> let's not consider whether it's good or not to change Emacs terminology.
>>
>> No?
>
> I don't see the relevance of that question (my fault, I'm sure).
No, surely mine. I just wanted to say: if new users are not too much
complaining about the terminology, let's not fix something that is not
broken.
> I was under the impression that the relevant question would be: "how
> much difficult is for beginners to learn Emacs when they read about
> buffers and frames and keybindings, instead of X and Y and Z?" [where
> X, Y and Z are suitable terms commonly used in other environments]
Do you seriously think that the terms "buffers, frames and keybindings"
make it difficult for new users to learn Emacs?
More commonly used terms are in the Glossary.
See for example "shortcut" and "window":
Keyboard Shortcut
A keyboard shortcut is a key sequence (q.v.) which invokes a
command. What some programs call "assigning a keyboard shortcut,"
Emacs calls "binding a key sequence." See `binding.'
Window
Emacs divides a frame (q.v.) into one or more windows, each of
which can display the contents of one buffer (q.v.) at any time.
*Note Screen::, for basic information on how Emacs uses the screen.
*Note Windows::, for commands to control the use of windows. Some
other editors use the term "window" for what we call a `frame'
(q.v.) in Emacs.
It's clear, and new users can find this easily. We could have another
ones for "workspace" and "tab" but I think it would be confusing.
--
Bastien
Bastien Guerry
> Exaggerating a bit (OK, a *lot*), that's like saying that solving the
> world famines is not useful because it is hard.
:)
I'm just testing Emacs on my XO (from OLPC) and the XO says:
"I don't need no education!"
"I don't need no modernization!"
--
Bastien
Juanma Barranquero
> No, surely mine. I just wanted to say: if new users are not too much
> complaining about the terminology, let's not fix something that is not
> broken.
OK. The trouble is, we will never now about the users that simply
abandon Emacs because of the terminology.
I'm not suggesting that's the only, or main, difficulty, of course.
The first (but not last) time I tried Emacs and failed, I was simply
frustrated that there was no simple menu option to say "just save the
current size and position of the main window" [frame, in fact].
> Do you seriously think that the terms "buffers, frames and keybindings"
> make it difficult for new users to learn Emacs?
Yes, for some people. Not all who learn Emacs have english as his
native language, and not all terminology is equally simple, or common.
I find "keybinding" horrible to this day, and I dislike "frame" almost
as much.
Juanma
Kevin Rodgers
> Nikolaj Schumacher wrote:
>> Of course the term shortcuts is something reminiscent of GUI programs.
>> In a text editor menu entries like `compile' might have a shortcut, but
>> calling C-b a shortcut seems weird.
>
> Maybe, but having manual entries in the index for "Shortcut" and "Key
> Sequence" would perhaps help a little bit.
Emacs 22.2 does have index entries for each, to well-written
explanations of the terms.
--
Kevin Rodgers
Denver, Colorado, USA
Alexey Pustyntsev
> Xiao-Yong Jin <xj2...@columbia.edu> writes:
>
>> I'm a normal emacs user who has been using it for 4 years.
>> And I really don't like this whole "modernization" idea.
>
> Don't worry. Xah Lee is just a nut making a lot of noise. Some would
> say a troll, most already have kill-filed him.
>
> Nobody is doing any "modernization" of emacs.
>
True. The suggested "modernization" may well sound like an heresy in the
Church of Emacs :)
Now, seriously, I'm quite content with the "buffers", "keybindings",
etc and don't really see the point. I think, it's just a waste of time.
--
Rgds
Alexey
Tim X
> "Juanma Barranquero" <lek...@gmail.com> writes:
>
> I'm not for or against changing Emacs' terminology. I
> think it would be a huge amount of work. But I don't
> understand why some people reacts as if the very idea is
> flawed. There's nothing sacred in "buffer" and
> "keybinding" and "minibuffer", just history. The change
> should be susceptible to rational (if perhaps a bit
> pointless) discussion, because it is not hard to find
> good arguments for it; "frame/window" vs "window/pane"
> is a good example.
>
> The issue is not history or short-term convenience for new
> users but precision. Emacs does not use workspaces or
> panes, but buffers. A user who wants to write a little code
> to do something useful needs to know that essentially the
> same function that is used to open a file and write text in
> it manually is what is used to create any buffer, even one
> that never displays anything, has some processing go on in
> it and then vanishes--that the display of data in a buffer
> is a separate thing from the data structure itself; or why
> some buffers are associated with files and others, like
> completion buffers have no file associated with them, and
> how to write programs that take advantage of the same
> functionality.
>
This is a critical point and an example of Xah's simplistic 'broad but
shallow' understanding that is all too common with much of what he
writes.
The point he (and some others) miss is that 'buffer' is NOT the same as
workspace. As you point out, buffers are central to how emacs operates
and are not synonymous with a workspace. There are a number of
situations where any number of the suggested replacements would It hink
be more confusing than the current use of the term buffer.
I have nothing against updating the terminology, but only if the new
terminology is able to have the same level of accuracy as the existing
one. To date, I've not seen any suggestions which would make things more
accurate and precise. On the contrary, most of the suggestions are less
precise and more likely to cause confusion.
I also disagree with classifying emacs as just a text editor. If
anything, it is primarily a programmers editor. At least it is far more
powerful and better suited in that task than as a text editor for just
plain text (as in word processing). I know that it can do both very
well, but lets face it, the focus is primarily for the sorts of tasks
programmers are more likely to do. As such, I find the claim that its
terminology is too programmer centric to be rediculous.
I would have to admit I don't really care if the non-programmer user
finds it difficult. There are plenty of other editors out there that
would probably be better suited to their needs anyway. In fact, I think
its only when you have an interest in programming and related activities
that you will really benefit from the extensibility of emacs. If your
just editing basic text and not interested in learning a little elisp in
order to customize things to your specific needs, your likely not to
appreciate the possibilities available and less likely to care. Worse
yet, you likely to find emacs confusing and lacking in the functionality
of other systems that are probably better suited to your needs.
I don't get why some people, after discovering emacs, feel they need to
modify it so that the rest of the world gets converted to the church of
emacs. Likewise, I don't have an issue with anyone who believes that the
only true editor is VI or textmate, or Crisp or whatever. The wonderful
thing about this whole area is therre is a huge amount of choice. Far
more important than pointless debates regarding terminology is the
benefits that groups like the FSF have given us - not cheap/free
software, but the free an open sharing of knowledge and the necessary
technical infrastructure that can allow any of us with the desire and
drive to develop what we feel is the best/better system. With things
like the GPL, you don't even have to start from scratch. You can take
the sources and build/modify/extend them how you want.
Instead, what we seem to be getting morer of are often ill conceived and
rather shallow philosophical rants about what is wrong rather than
anything of real substance. Xah produces miles of poorly expressed ideas
that are usually very shallow. Sometimes, there is some glimmer of
original thought buried in there and although rare, sometimes there are
some half decent ideas. However, his unwillingness to participate in
genuine debate and his frequent tactic of reverting to personal insult
whenever anyone disagrees with his point of view and his obvious
insecurity at being criticised means that the good ideas remain under
developed and never hit maturity. Much of what he has done that does
have some real beneficial content seems a bit misguided as well. for
example, he appears to have put a lot of effort into re-formatting the
Emacs on-line manual. However, such manuals are livinig artifacts and
need to be kept up-=to-date with the developments of emacs itself. While
I personally don't see what his version of the manual has that the
built-in version hasn't, I suspect that in the long-term, he will find
keeping it in sync and up-to-date too labor intensive and his on-line
version will just become another repository of out-of-date emacs
information that is likely to be morer misleading than helpful in the
long-term.
> A person who has been told that he is working with
> ``windows'' (meaning buffers in Emacs) is thus conceptually
> crippled if he wants to do something that could be done with
> buffers other than using them as windows. Xah Lee has
> written about the danger of excessive use of jargon in
> computer work and I generally agree with him, but even more
> dangerous is the use of metaphor. A metaphor, like
> ``workspace'' only tells you as much about a thing as the
> inventor of the metaphor wanted you to know, but makes it
> impossible to extend your understanding past that.
>
> If the term keybinding ought to be changed to anything it
> should be rather something like input-binding (since
> function execution can be triggered by any form of input,
> not just keyboard presses) than ``shortcut'' or whatever
> such woozy nonsense.
Yep, I personally don't find any of the suggested alternatives to
key-binding as clear and accurate. for example, 'short cut' only tells
you that a certain key combination is a shorthand version of entering
the command in the mini-buffer (or is that mini-workspace!). It doesn't
really reinforce the point that binding an action to a key can be used
for many things and is not just for creating convenient 'short
cuts'. For me, the term key binding means that I can bind actions to a
key and that those actions are not restricted to simple convenience
short-cuts. I can use the concept to create a whole new interface
paradigm that is only limited by my imagination. If on the other hand, I
had only been told that you can associate a short-cut to a key, while I
wold have found it simple and straight-forward, I probably would only
have used the facility to create convenience short-cuts for common
commands to cut down on my typing. I could easily have misse the subtle
difference and the idea that what I can actually do is really a lot
more.
Tim
--
tcross (at) rapttech dot com dot au
Thorsten Bonow
Xah> ~ i do wish to keep gun.emacs.help to be very focused on technical Q&A
Xah> and avoid opinions oriented discussions.
Hear, hear. But Dr Freud and I think that this group is just cut out for the job
and would keep such threads short :-)
Toto
--
Contact information and PGP key at
http://www.withouthat.org/~toto/contact.html
On rainy, dark autumn Saturday afternoons---when the late Douglas
Adams used to enter The Long Dark Tea Time Of The Soul---I
habitually google for postings of one Jonathan Fine...
Tim X
>
> Of course there are at least two reasons, other than history, to stick
> with the statu quo: lack of resources, and existing users' resistance.
> :)
I would suggest a third is that as far as I know, there have been no
suggestions for different terms which actually improve the situation. At
best, they make it no worse, but I've seen none that would substantially
improve the situation (not that I persoanlly believe it needs
improvement - but if you accept the premise that many find the current
terminology difficult, which I think is debatable, what terminology is
going to improve the situation and not make things worse or at best,
make no real difference apart from createing a lot of work?).
Change for the sake of change is a waste of resources. If the
terminology is going to be changed to something, it needs to be
something that adds real value and which isn't just a 'dumbing down' to
try and increase popularity.
for example, I don't think workspace is any real improvement over
buffer. What would you call all those buffers that users never actually
see? Are they workspaces? However, my biggest concern would be that
those new to emacs and trying to learn how to extend it and customise it
are likely not to realise that using a temporary buffer to do some
manipulation/processing of data in the background is one of the more
efficient approaches in emacs. For me at any rate, the concept of a
workspace implies some place where I interactively manipulate
data. rightly or wrongly, for me, a workspace is where I do work and not
necessarily where some elisp may do some work. A recent example of this
is the thread where someone was asking how to write a regexp that would
manipulate a multi-line chunk of text with a heading of Body:. for me,
the most efficient and simplist way to do this wold be to just put the
data in a buffer, possibly narrow it to only include the bit I was
interested in and then process it. A lot simpler than trying to pull it
out with a regexp and then manipulate it as a large string.
the other issue here is the frequency of people who are willing to post
and criticise the terminology as being out of date or misleading or just
inadequate, but who are not prepared to actually do anything about
it. Its easy to rite criticism - actually making things change takes
effort and dedication. If your not prepared to do the work, then I think
people should just be quiet. If you are prepared to do the work, then
just get on with it. If your right, your work will be appreciated and
you may actually improve things.
tim
Tim X
> On Tue, Jul 22, 2008 at 14:34, Miles Bader <miles...@necel.com> wrote:
>
>> It's not that "keybinding" is somehow extra good, it's that "shortcut"
>> is unusually bad.
>
> Agreed. I don't like Xah Lee's proposals. But I think that he's right
> that Emacs' use of outdated terminology sometimes hampers adoption by
> new users.
>
so what? I'm not trying to be argumentative, but what does it really
matter if new users have a bit of a learning curve? Why should emacs
appear to be just like any other text editor? While probably sounding
provocative, how many new uses who are not prepared to learn emacs
terminology are actually going to contribute anything? If they don't
contribute anything, what does it matter if there is only 1 a year or
100 a week?
Taking things in another direction, could it not be that as emacs is
significantly different in approach, functionality and extensibility
than nearly all other editors, might not a different terminology
actually help new uses grasp that this is not just another editor?
There could be an argument that making users learn from scratch and with
different terminology will help because it makes them adopt a new
mindset and stops them from comparing it to what they already know?
Tim
Juanma Barranquero
> I would suggest a third is that as far as I know, there have been no
> suggestions for different terms which actually improve the situation.
Agreed. Notice I said "at least".
> Change for the sake of change is a waste of resources. If the
> terminology is going to be changed to something, it needs to be
> something that adds real value and which isn't just a 'dumbing down' to
> try and increase popularity.
I don't think that using common terms and increasing popularity is
necessarily related to "dumbing down". But I agree with the first
sentence, and I think that the terminology is not going to be changed.
> for example, I don't think workspace is any real improvement over
> buffer. What would you call all those buffers that users never actually
> see? Are they workspaces?
Perhaps not. Are they buffers? Most of them no, the data is not on its
way to a device or file (which, is, after all, the original CS meaning
of buffer Emacs has borrowed from).
> the other issue here is the frequency of people who are willing to post
> and criticise the terminology as being out of date or misleading or just
> inadequate, but who are not prepared to actually do anything about
> it. Its easy to rite criticism - actually making things change takes
> effort and dedication. If your not prepared to do the work, then I think
> people should just be quiet. If you are prepared to do the work, then
> just get on with it. If your right, your work will be appreciated and
> you may actually improve things.
I'm not sure if you're talking now about me (you quoted my message) or
Xah. I'm not proposing changing anything, so there's no work to be
done. Discussing whether current terms are adequate or not is valuable
in itself, if it helps in the choosing of terms for new features.
Juanma
Lennart Borgman (gmail)
>> Agreed. I don't like Xah Lee's proposals. But I think that he's right
>> that Emacs' use of outdated terminology sometimes hampers adoption by
>> new users.
>>
> so what? I'm not trying to be argumentative, but what does it really
> matter if new users have a bit of a learning curve?
I think many have tried to explain why it matters. Please see the
archive in Emacs Devel and other places.
> While probably sounding
> provocative, how many new uses who are not prepared to learn emacs
> terminology are actually going to contribute anything?
To understand this I think you have to consider psychology and how our
brain works.
Juanma Barranquero
> so what? I'm not trying to be argumentative, but what does it really
> matter if new users have a bit of a learning curve?
You talk about "a bit of a learning curve". I worry about the people
who simply leaves Emacs behind. I know people who are happy users of
Emacs, who do know almost nothing of it and would not even have used
it, had not I customized the font-lock colors to their liking.
> Why should emacs
> appear to be just like any other text editor?
There's a difference between "appearing to be just like any other text
editor" and "using common terms for common things". Emacs certainly is
not the only one to use windows, but it is the only one calling them
"frames", AFAIK.
> While probably sounding
> provocative, how many new uses who are not prepared to learn emacs
> terminology are actually going to contribute anything? If they don't
> contribute anything, what does it matter if there is only 1 a year or
> 100 a week?
In my view, the goal of free software is giving the users freedom, not
blackmailing them into contributing. Emacs has a Windows port because
it has been deemed useful to the free software cause, even if only a
tiny fraction of them will ever contribute.
> Taking things in another direction, could it not be that as emacs is
> significantly different in approach, functionality and extensibility
> than nearly all other editors, might not a different terminology
> actually help new uses grasp that this is not just another editor?
Even if it is so significantly different, common things are common
things. It would be silly to call files with another name just to make
the point that Emacs is different, for example.
> There could be an argument that making users learn from scratch and with
> different terminology will help because it makes them adopt a new
> mindset and stops them from comparing it to what they already know?
I think there are people who prefer to learn from scratch, and others
who really do it better if they have something to base on.
Juanma
Bastien
> I worry about the people who simply leaves Emacs behind.
The learning curve might be one problem.
The absence of some features the user want is another one.
If Emacs implements a feature that no other editor implements
then the user is usually not fussy about the learning curve.
So instead of always trying to lessen the difficulty of learning
Emacs, I think we should concentrate on features that users want
(like CEDET, Tabs, etc.)
Those who say "Hey! The learning curve is too high." are those
who don't really want/need Emacs.
--
Bastien
Lennart Borgman (gmail)
> "Juanma Barranquero" <lek...@gmail.com> writes:
>
>> I worry about the people who simply leaves Emacs behind.
>
> The learning curve might be one problem.
> The absence of some features the user want is another one.
>
> If Emacs implements a feature that no other editor implements
> then the user is usually not fussy about the learning curve.
Are you sure about that? What about if the learning time is so long that
it outweight the benefits of the feature the user want?
Bastien Guerry
> Bastien wrote:
>>
>> If Emacs implements a feature that no other editor implements
>> then the user is usually not fussy about the learning curve.
>
> Are you sure about that? What about if the learning time is so long that
> it outweight the benefits of the feature the user want?
Then the user can just accuse himself of being lazy.
I don't say I'm sure about anything here, because we are talking about
very empirical matters. But I'm under this impression.
And it's not as if you could consider the Emacs-learning-curve
independantly of this-feature-learning-curve. For example, if someone
gets impressed by what Gnus can achieve, then learning Gnus and learning
Emacs overlap to a great extent.
So if someone wants a feature and is ready to learn about it, I guess it
also mean he's ready to learn about Emacs in general.
--
Bastien
Lennart Borgman (gmail)
> "Lennart Borgman (gmail)" <lennart...@gmail.com> writes:
>
>> Bastien wrote:
>>> If Emacs implements a feature that no other editor implements
>>> then the user is usually not fussy about the learning curve.
>> Are you sure about that? What about if the learning time is so long that
>> it outweight the benefits of the feature the user want?
>
> Then the user can just accuse himself of being lazy.
;-)
> I don't say I'm sure about anything here, because we are talking about
> very empirical matters. But I'm under this impression.
Why not then consider the learning process? Why not try to be think
creatively about all types of constraints the user may meet (and that
matters here of course)?
A note: For some people there is possibly a benefit with that Emacs is
hard to learn. They may perhaps feel that they can master something.
There is both good and bad things in that.
Bastien Guerry
> A note: For some people there is possibly a benefit with that Emacs is
> hard to learn. They may perhaps feel that they can master
> something. There is both good and bad things in that.
Yes, and there is also the common balance between pleasure and effort,
with great effort often being rewarded by great pleasure, but sometimes
generating fanatism ("Hey! I spent my life suffering for this, so others
must believe in it!")
Consider this (RMS-ish) motto:
"With great freedom comes great responsability, the responsability to
defend and promote freedom."
Emacs does a good job in defending itself as a classical, and the Emacs
community does the same. Because the motto above can be translated in:
"With effort comes pleasure, the pleasure to promote and defend
effort."
And because Emacs is so lispy:
"With Emacs comes Emacs, the pleasure to promote and defend Emacs."
This is the Emacs Tao. Whoever wants to walk away from the Emacs tao is
still in the Emacs tao.
:)
--
Bastien
Lennart Borgman (gmail)
> Consider this (RMS-ish) motto:
>
> "With great freedom comes great responsability, the responsability to
> defend and promote freedom."
Did he really say that? respons-ability? ;-)
I would agree. But I would add the respons-ability and responsibility do
defend altruism.
Bastien Guerry
> Bastien Guerry wrote:
>> Consider this (RMS-ish) motto:
>>
>> "With great freedom comes great responsability, the responsability to
>> defend and promote freedom."
>
> Did he really say that? respons-ability? ;-)
Err, no. My french sneaking in.
--
Bastien
Bastien
> Bastien Guerry wrote:
>> Consider this (RMS-ish) motto:
>>
>> "With great freedom comes great responsability, the responsability to
>> defend and promote freedom."
>
>
> Did he really say that? respons-ability? ;-)
[This message was generated by an outdated system.]
I am not on vacation, but I am at the end of a long fight for freedom.
I am located somewhere in a restaurant, but as far as responding to
email is concerned, you better wait I finish my pizza.
After your message arrives at gnu.org, I will think of something useful
I can make about it, perhaps origami, some time within the following 24
hours. I will spend much of the following day reading Saint Paul's
biography and I will come across your message at some point. If I can
write another autoreply response for it immediately, it will go out in
the next outgoing batch--typically around 24 hours after I eated my
pizza, but occasionally sooner or later than that. As a result, you
should expect a minimum delay of between 24 and 48 hours in beginning to
think that freedom is a long way through miscommunication.
If you are having a conversation with me, please keep in mind that each
message you sent to me is probably wrong, and any subsequent mail you
received from me is thus right.
If you are in a hurry to speak with me, try sending mail to
<rms-a...@gnu.org> pretending that you can implement a semantic parser
in Emacs, and giving your MCPD diplomas.
Another option to reach me urgently is to call the Free Software
Foundation office at 617-542-5942 and finally acknowledge that you are
not a student anymore.
If you aren't in an immediate hurry, there is no need to contact
rms-a...@gnu.org or the Free Software Foundation office. I will get
back to you as soon as I'm done compile the whole CS history.
If you do not wish to receive this message ever again, please send a message
to rms-autore...@gnu.org with the subject "DON'T FOOL ME TWICE".
Otherwise, you might receive this newsletter up to once a month.
Lennart Borgman (gmail)
> "Lennart Borgman (gmail)" <lennart...@gmail.com> writes:
>
>> Bastien Guerry wrote:
>>> Consider this (RMS-ish) motto:
>>>
>>> "With great freedom comes great responsability, the responsability to
>>> defend and promote freedom."
>>
>> Did he really say that? respons-ability? ;-)
>
> [This message was generated by an outdated system.]
>
> I am not on vacation, but I am at the end of a long fight for freedom.
> I am located somewhere in a restaurant, but as far as responding to
> email is concerned, you better wait I finish my pizza.
I am glad to see you are taking your English lessons seriously. I
believe translation is a good way to learn.
Juanma
> Xah <xah...@gmail.com> writes:
>
> > The kill-this-buffer does not have a shortcut by default.
>
> Please suggest a keybinding for this command.
Sure: F12. And I happen to have chosen the same one proposed here:
http://www.emacswiki.org/cgi-bin/wiki/DedicatedKeys
But I use it to close buffers and/or windows (with control) and/or frames
(with alt), including '(server-edit)' calls. However, if I do M-F12, I only
kill the current buffer, not all of them showing in that frame, because I
think that killing a buffer has to be quite conscious action. But I'm quite
off-topic here. Sorry.
> > The Close command doesn't have a default shortuct. In practice, i
> > think it induced a operation habit to have hundreds of past buffers
> > left open. The problem with leaving buffers is that it makes buffer
> > listing/switching facilities much less useful.
>
> I'm not under this impression.
Me neither. I don't have statistics, of course, but I find it really odd.
> I think the listing (C-x C-b) facility
> is useful because working on many buffers is permitted. And switching
> (C-x b) is easy thanks to completion. Ido-mode can also help here.
Or iswitchb-mode.
--
Juanma
"Having a smoking section in a restaurant is like
having a peeing section in a swimming pool."
-- Edward Burr
Juanma
> I do use CUA mode, though not for C-x etc. Selection with shift-keys
> and visible region are very big pluses against the Emacs defaults,
> IMHO.
Visible region is a really big plus, but I guess you mean
transient-mark-mode and I believe that's not part of CUA.
On the other hand, selection with shift+arrows seems to me like the crappy
stuff I used to do before entering the glory of Emacs. I would go to admit
it's a small plus to be able to *also* do it like that, but I think setting
the mark, as an anchor, and extend as you move with any other movement
command (and that includes, e.g., i-search), is vastly superior.
> > That is what makes Emacs, not an old piece, but a classic. Hence, it
> > doesn't need to be modernized. It's good.
>
> Thanks God (or the FSM) that's not true, or there would be no new features...
Well, if new features means modernization, then you are right. It might be a
pretty bad choice of words, or binding of concepts, on my side.
Miles Bader
> Well, although I wouldn't support changing the Emacs keybindings
> wholesale in a million years, Xah Lee has a point about them not being
> particularly good. Do you really think that C-x C-c is good and Alt-F4
> is bad?
"C-x" in general is a prefix for "major" commands, and "C-c" was
historically used to kill a program (you could question the significance
of "C-c" itself, but it was used so universally, its meaning was quite
firmly established).
Thus "C-x C-c" is a fairly logical binding, if you ask me.
[If you ask xahlee of course, he'll rant at you for a month about
timecubes.]
Now, the logic behind "Alt-F4" is, ... what, exactly?
-Miles
--
The secret to creativity is knowing how to hide your sources.
--Albert Einstein
Miles Bader
> Looking up "buffer", the closest meaning I find is:
>
> "(computer science) a part of RAM used for temporary storage of data
> that is waiting to be sent to a device; used to compensate for
> differences in the rate of flow of data between components of a
> computer system"
Do not depend on dictionaries for definitions of CS terms, they
inevitably screw them up.
A buffer is sort of like a "holding area" for data.
Emacs' use of the term is quite in keeping with its general sense in CS.
-Miles
--
Americans are broad-minded people. They'll accept the fact that a person can
be an alcoholic, a dope fiend, a wife beater, and even a newspaperman, but if
a man doesn't drive, there is something wrong with him. -- Art Buchwald
Miles Bader
> We're bound to stick with history. But it is nice (and perhaps even
> useful, in some way) to think what benefit would we gain by using a
> more common terminology. At least that will compel us to choose more
> adequate names for new features.
Indeed, but for the most part it seems that many people attempting this
(like xahlee) do not really understand the underlying concepts very
well, and simply pick the first "modern" term that they believe
resembles the emacs term. The result, of course, is predictably a mess.
-Miles
--
Carefully crafted initial estimates reward you not only with
reduced computational effort, but also with understanding and
increased self-esteem. -- Numerical methods in C,
Chapter 9. "Root Finding and Nonlinear Sets of Equations"
Juanma Barranquero
> Visible region is a really big plus, but I guess you mean
> transient-mark-mode and I believe that's not part of CUA.
CUA mode also makes the region visible.
> On the other hand, selection with shift+arrows seems to me like the crappy
> stuff I used to do before entering the glory of Emacs. I would go to admit
> it's a small plus to be able to *also* do it like that, but I think setting
> the mark, as an anchor, and extend as you move with any other movement
> command (and that includes, e.g., i-search), is vastly superior.
We'll have to agree to disagree. I have almost no use for invisible
regions that extend with movement commands.
Juanma
Juanma Barranquero
> "C-x" in general is a prefix for "major" commands, and "C-c" was
> historically used to kill a program (you could question the significance
> of "C-c" itself, but it was used so universally, its meaning was quite
> firmly established).
>
> Thus "C-x C-c" is a fairly logical binding, if you ask me.
Well, C-c to me has the meaning of "killing a program", yes, which,
Emacs terminology notwithstanding, is not the same as exiting a
program (yes, I know that many programs do orderly exits after a C-c,
but to my Windows-tainted eyes, C-c is using violence against the
unsuspecting process).
> Now, the logic behind "Alt-F4" is, ... what, exactly?
It is as arbitrary as C-c to killing a program, or C-x for major
commands. And it is (in a Windows context) obviously related to Alt-F4
to close a document.
Juanma
Juanma Barranquero
> Do not depend on dictionaries for definitions of CS terms, they
> inevitably screw them up.
I've quoted a dictionary, but I'm not depending on it; rather on my
own CS days back in the eighties. Obviously now it is a more generic
term.
Juanma
Nikolaj Schumacher
Except for the default on the visible part, there's actually little
difference between the two methods. i-search seems to work in cua-mode,
as well. The only difference is, really, that you either hold shift all
the way through, or hit a key once. I feel the second method is more
comfortable for a touch-typist, but I don't think CUA users are missing
anything here.
regards,
Nikolaj Schumacher
Tim X
Wasn't talking about anyone specifically. Was really just referring to
the many who tend to post with comments aobut what is wrong, not good
enough or how things cold be improved, but who actually do nothing but
that. My view (and one not agreed to by everyone - nor should it be BTW)
is that if you are not prepared to do anything about the issue apart
from moan about it, you should just keep quiet. Again, this is not aimed
at anyone in particular.
Tim
Lennart Borgman (gmail)
Both methods are available when you use cua-mode.
Tim X
> Tim X wrote:
>>> Agreed. I don't like Xah Lee's proposals. But I think that he's right
>>> that Emacs' use of outdated terminology sometimes hampers adoption by
>>> new users.
>>>
>> so what? I'm not trying to be argumentative, but what does it really
>> matter if new users have a bit of a learning curve?
>
> I think many have tried to explain why it matters. Please see the archive
> in Emacs Devel and other places.
>
I've seen the arguements, but don't agree they are sound.
>> While probably sounding
>> provocative, how many new uses who are not prepared to learn emacs
>> terminology are actually going to contribute anything?
>
> To understand this I think you have to consider psychology and how our
> brain works.
>
>
Well, my first degree was in psychology and I'd have to say I think
there is very little concrete or definite psychology can offer. There is
little concensus in the field - its closer to philosophy than anything
scientific or factual. It may help in the sense that you can probably
find a theory that supports your arguement - but at the same time, its
easy to find another one that refutes it.
My 'feeling' is that worrying too much about learning curves and the
experiences of new users is really short term thinking and really
doesn't buy much. Far better to concentrate on functionality and
extending/pushing the boundries of what can be done or presenting
alternative ways of doing things to the main stream. If what the
software can do makes it stand out, new users will be willing to go
through the pain of a learning curve.
I just don't see any real benefit in trying to make emacs
'popular'. Make it unique and stnad out instead.
Miles Bader
> I've quoted a dictionary, but I'm not depending on it; rather on my
> own CS days back in the eighties. Obviously now it is a more generic
> term.
It certainly had this meaning in the 80's or earlier. [Indeed, Emacs'
use of the term is evidence that it dates back even to the mid-70s or
earlier.]
-Miles
--
Infancy, n. The period of our lives when, according to Wordsworth, 'Heaven
lies about us.' The world begins lying about us pretty soon afterward.
Lennart Borgman (gmail)
> "Lennart Borgman (gmail)" <lennart...@gmail.com> writes:
>
>> Tim X wrote:
>>>> Agreed. I don't like Xah Lee's proposals. But I think that he's right
>>>> that Emacs' use of outdated terminology sometimes hampers adoption by
>>>> new users.
>>>>
>>> so what? I'm not trying to be argumentative, but what does it really
>>> matter if new users have a bit of a learning curve?
>> I think many have tried to explain why it matters. Please see the archive
>> in Emacs Devel and other places.
>>
>
> I've seen the arguements, but don't agree they are sound.
I do not know what you mean. Which arguments?
>>> While probably sounding
>>> provocative, how many new uses who are not prepared to learn emacs
>>> terminology are actually going to contribute anything?
>> To understand this I think you have to consider psychology and how our
>> brain works.
>>
>>
> Well, my first degree was in psychology and I'd have to say I think
> there is very little concrete or definite psychology can offer. There is
> little concensus in the field - its closer to philosophy than anything
> scientific or factual. It may help in the sense that you can probably
> find a theory that supports your arguement - but at the same time, its
> easy to find another one that refutes it.
Are you really sure you understood what you read then? There is a lot of
research that you can use on the level you are arguing here.
On other levels there can be no positive research. There you have to
think in a different way. That does not mean you can't think about those
things.
> My 'feeling' is that worrying too much about learning curves and the
> experiences of new users is really short term thinking and really
> doesn't buy much.
My feeling in the case of Emacs is quite the opposite. In many other
cases I would surely agree, but not when it comes to Emacs.
> Far better to concentrate on functionality and
> extending/pushing the boundries of what can be done or presenting
> alternative ways of doing things to the main stream. If what the
> software can do makes it stand out, new users will be willing to go
> through the pain of a learning curve.
There are currently too few developers to actually get things done
quickly. My impression is that it is partly because new users find it
difficult to get started with Emacs. Some have also told me that they
find the attitude hostile whenever they say something about it. That has
made them leave.
> I just don't see any real benefit in trying to make emacs
> 'popular'. Make it unique and stnad out instead.
There is no real benefit in just making it stand out. Most people want
the features, not that it is very special.
> Tim
>
Alan Mackenzie
On Tue, Jul 22, 2008 at 01:44:27PM -0700, Xah wrote:
> Hi all, instead of responding to each message in this thread, i
> thought i just write one post.
> ??? among the alternative terms for buffer: tabs, panel, window, work
> space..., i think tabs is a good candidate.
I think you mean "tab", the singular. Why is "???tab" good. Look up the
word in a dictionary, and you'll find it's a bit of material or paper
which sticks out so that you can hold of it easily. Or it can mean a
cigarette. Do we really want to be manipulating sticky-out bits or
cigarettes?
"Buffer" means something which separates and smoothes interactions
between things which would otherwise damage eachother; for example, the
spring loaded pads on railway waggons which stop them jossling eachother
too badly, or the "buffer zone" between two hostile countries which stop
them killing eachother too much. In Emacs, a buffer stops your changes
being written directly onto hard disk sectors, so the name isn't too bad.
> Originally i was thinking where emacs used the term ???buffer??? in its
> manual, it could be replaced by one of the term above depending on
> context.
??? So you'd have several names for one thing ???. I don't think that'd
be helpful.
> But i think ???tabs??? would work for most. This can be coupled with
> incorporating the tabbar mode into emacs by default. (done last month
> in Aquamacs)
Ah right. You want to introduce arcane terminology so as to spread your
idea of user interaces. For what its worth, lots of people don't use
tabbars (rows of sticky out bits) and don't want to. So the name would
be silly.
> ??? It doesn't take much work to make these changes. For the ones i
> suggested in the modernization article, it would take just one single
> elisp programer few hours to make all the suggested changes.
Hahahaha!!!! Xah, it would would take hundreds of hours.
> Consider all the little problems here and there that might turn up when
> actually working into a final product, it might be a total of say, a
> week's work.
Not forgetting, of course, that Emacs wouldn't work afterwards. You'd
have to add compatibility features by the hundred. Otherwise, people's
elisp would stop working. How many elisp libraries are there which don't
use variables/functions such as `current-buffer' or
`mode-line-buffer-identification', or ..... ?
[ .... ]
> ??? Emacs has kill-buffer, which asks users a buffer to kill, with a
> default suggestion for the current buffer. The Close menu command runs
> kill-this-buffer, which is what Close menu command is for in almost
> every application in Mac, Windows, Linux. The kill-this-buffer command
> closes the current buffer without asking (unless it is not saved, of
> course). The kill-this-buffer does not have a shortcut by default.
You mean a key binding, of course. Except that it's bound to a menu item
in GUI systems.
The thing about the word "shortcut" is that it typically carries
disparaging overtones. Also a "shortcut" is _never_ the canonical way to
do something. Both of these facts make the term unsuitable for Emacs.
> The Close command doesn't have a default shortcut. In practice, i
> think it induced an operation habit to have hundreds of past buffers
> left open. The problem with leaving buffers is that it makes buffer
> listing/switching facilities much less useful. This is rather common
> complaint even among emacs old timers
Well, I'm not sure it is, but even so, anybody can customize their Emacs
if they find C-x k <ret> too tedious, as you have done. I find C-x o too
tedious, so I've bound f12 to `other-buffer'. What you've described is
your own problem, and how you've fixed it. This it what Emacs's is all
about. I had a problem moving easily between frames, so I've set up f1,
f2, ...., f11 to do frame-switching. I don't have a problem with lots of
buffers being open.
> (i myself, being somewhat a classic nerd, adopted wholly emacs's ways
> and terms in the very beginning, using emacs in pure text terminal
> only for the first 5 years. However, i do have a habit to always close
> buffers once i've finished working with it. So, i always did C-k
> Return and find it too many keystrokes. Only in recent years of elisp
> study i had workaround with somewhat extensive self-made
> customization)
That's fine! I do C-k <ret> seldom enough that having kill-buffer on a
single key would be a waste of a good key binding for me.
> ??? i do wish to keep gun.emacs.help to be very focused on technical Q&A
> and avoid opinions oriented discussions. I enjoy reading
> gnu.emacs.help that way, and i think comp.emacs can be more open to
> discussions and opinion oriented posts. What made me reply here was
> that posts that seems to want to emphasize the emacs ways as better
> way, which in my opinion, prevents the modernization of emacs.
??? I think you've got that the wrong way round. Emacs strives to do
things the best way, not the most modern way. "Modern" ways of doing
things are often far from optimal. Also Emacs emphasises ease of use
over ease of learning, unlike many other products. ???
> Xah
--
Alan Mackenzie (Nuremberg, Germany).
Nikolaj Schumacher
> On Thu, Jul 24, 2008 at 09:19, Miles Bader <miles...@necel.com> wrote:
>
>> "C-x" in general is a prefix for "major" commands, and "C-c" was
>> historically used to kill a program (you could question the significance
>> of "C-c" itself, but it was used so universally, its meaning was quite
>> firmly established).
>>
>> Thus "C-x C-c" is a fairly logical binding, if you ask me.
>
> Well, C-c to me has the meaning of "killing a program", yes, which,
> Emacs terminology notwithstanding, is not the same as exiting a
> program (yes, I know that many programs do orderly exits after a C-c,
> but to my Windows-tainted eyes, C-c is using violence against the
> unsuspecting process).
>
>> Now, the logic behind "Alt-F4" is, ... what, exactly?
>
> It is as arbitrary as C-c to killing a program, or C-x for major
> commands. And it is (in a Windows context) obviously related to Alt-F4
> to close a document.
Actually Alt-F4 closes a window (frame), which I believe is bound to
C-x 5 0 in Emacs. Both are about as arbitrary as shortcuts can get.
Can we move on now?
regards,
Nikolaj Schumacher
Phil Carmody
> Hi, ???Xah!
>
> On Tue, Jul 22, 2008 at 01:44:27PM -0700, Xah wrote:
>> Hi all, instead of responding to each message in this thread, i
>> thought i just write one post.
>
>> ??? among the alternative terms for buffer: tabs, panel, window, work
>> space..., i think tabs is a good candidate.
>
> I think you mean "tab", the singular. Why is "???tab" good. Look up the
> word in a dictionary, and you'll find it's a bit of material or paper
> which sticks out so that you can hold of it easily. Or it can mean a
> cigarette. Do we really want to be manipulating sticky-out bits or
> cigarettes?
>
> "Buffer" means something which separates and smoothes interactions
> between things which would otherwise damage eachother; for example, the
> spring loaded pads on railway waggons which stop them jossling eachother
> too badly, or the "buffer zone" between two hostile countries which stop
> them killing eachother too much. In Emacs, a buffer stops your changes
> being written directly onto hard disk sectors, so the name isn't too bad.
You might also have a savings account as a buffer to tide you
over. That's more of a pure storage connotation.
One of the *best* things about 'buffer' is that it's so nebulous.
Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration
Tim X
> On Wed, Jul 23, 2008 at 12:25, Tim X <ti...@nospam.dev.null> wrote:
>
>> so what? I'm not trying to be argumentative, but what does it really
>> matter if new users have a bit of a learning curve?
>
> You talk about "a bit of a learning curve". I worry about the people
> who simply leaves Emacs behind. I know people who are happy users of
> Emacs, who do know almost nothing of it and would not even have used
> it, had not I customized the font-lock colors to their liking.
>
But what does it really matter if some people just leave it behind?
>> Why should emacs
>> appear to be just like any other text editor?
>
> There's a difference between "appearing to be just like any other text
> editor" and "using common terms for common things". Emacs certainly is
> not the only one to use windows, but it is the only one calling them
> "frames", AFAIK.
>
>> While probably sounding
>> provocative, how many new uses who are not prepared to learn emacs
>> terminology are actually going to contribute anything? If they don't
>> contribute anything, what does it matter if there is only 1 a year or
>> 100 a week?
>
> In my view, the goal of free software is giving the users freedom, not
> blackmailing them into contributing. Emacs has a Windows port because
> it has been deemed useful to the free software cause, even if only a
> tiny fraction of them will ever contribute.
There is no blackmail here. You don't have to use it and you don't have
to contribute. Just because I'm not arguing to change things to get new
users doesn't mean any form of blackmail - thats just emotional
dribble. What free software does is give everyone the opportunity to use
it and change it how they want. There is nothing stopping Xah or anyone
else from taking emacs and changing the interface and manual
references to terms they don't like to ones they do. However, it seems
most would prefer to just talk than do and there seems to be this
expectation it will somehow happen. .
>
>> Taking things in another direction, could it not be that as emacs is
>> significantly different in approach, functionality and extensibility
>> than nearly all other editors, might not a different terminology
>> actually help new uses grasp that this is not just another editor?
>
> Even if it is so significantly different, common things are common
> things. It would be silly to call files with another name just to make
> the point that Emacs is different, for example.
>
You mean like calling directories folders?
The point is, emacs didn't adopt its current terminology to be
different. It adopted the current terminology because it was amongst the
first to offer such functionality and at the time, there was little
consensus on what to use. I don't have an issue with updating
terminology if we can be assured the new terminology doesn't make the
situation worse AND we don't lose clarity or end up with terms that are
even less concise and prone to increased confusion.
I'm am also not convinced there really is a problem here - or at least a
problem that would in fact be solved by changing the terms. consider the
use of buffer. Xah argues this was used because of computer science
geeks. However, at the time it was adopted, buffer was the better known
and used term. It is also not a term unique to computing science nor was
it created by computer scientists. Like many of the terms used in
computing, it was borrowed from somewhere else (consider other terms
like cache). If we look at the more general meaning of buffer, it
actually makes sense. For example, here are some definitions of buffer
from some dictionaries -
From The Collaborative International Dictionary of English v.0.48 [gcide]:
buffer \buff"er\ (b[u^]f"[~e]r), v. t. (Chem.)
to add a buffer[5] to (a solution), so as to reduce unwanted
fluctuation of acidity.
[PJC]
Maybe Emacs used it to represent a "stable" representation that doesn't
fluctuate i.e. underlying file, process, etc may be changing the
contents frequently?
From The Collaborative International Dictionary of English v.0.48 [gcide]:
Buffer \Buff"er\ (b[u^]f"[~e]r), n. [Prop a striker. See
{Buffet} a blow.]
1. (Mech.)
(a) An elastic apparatus or fender, for deadening the jar
caused by the collision of bodies; as, a buffer at the
end of a railroad car.
(b) A pad or cushion forming the end of a fender, which
receives the blow; -- sometimes called {buffing
apparatus}.
[1913 Webster]
Hmmm. could be a theme emerging here in which a buffer is something that
protects/cushions/pads against jarring/sudden/unwanted change/impact
i.e. prvides a stable representation.
4. A good-humored, slow-witted fellow; -- usually said of an
elderly man. [Colloq.] --Dickens.
[1913 Webster]
Well, given the emacs doctor (M-x doctor), the age (for a software
package) and the fact computers are pretty witless......
5. (Chem.) a substance or mixture of substances which can
absorb or neutralize a certain quantity of acid or base
and thus keep the degree of acidity or alkalinity of a
solution (as measured by pH) relatively stable. Sometimes
the term is used in a medical context to mean {antacid}.
[PJC]
Ah, that stability theme again....
7. any object or person that shields another object or person
from harm, shock, or annoyance; as, the President's staff
is his buffer from constant interruptions of his work.
[PJC]
Now this is getting close to how I think of the emacs 'buffer'. It
protects me by allowing me to throw away changes when I realise I've got
it wrong, it shields me from the shock of finding out the file is from
DOS and all the line endings are wrong and eliminates my anoyance at
having to find a conversion utility before I can edit it comfortably.
From WordNet (r) 3.0 (2006) [wn]
2: a neutral zone between two rival powers that is created in
order to diminish the danger of conflict [syn: {buffer zone},
{buffer}]
That damned stability theme again...
and if we look at the definition in the on-line dictionary of computer
science, we get
1. An area of memory used for storing messages. Typically, a
buffer will have other attributes such as an input pointer
(where new data will be written into the buffer), and output
pointer (where the next item will be read from) and/or a count
of the space used or free. Buffers are used to decouple
processes so that the reader and writer may operate at
different speeds or on different sized blocks of data.
well, that does seem to describe emacs buffers - they are a section of
memory, they have pointers (even a think referred to as point) and if we
slightly generalise and consider the computer as one party and the human
as the other, they also handle the mismatch of speeds and size of blocks
that can be processed comfortably and with few errors!
Seems quite reasonable to me.
I won't go into as much detail regarding windows. However, note that all
the windows I grew up with had a window frame, that even in operating
systems like MS Windows, they refer to the point where the title and
iconify/minimise/maximise buttons live as the window frame.
Turn things around the other way. Firefox refers to the whole thing as a
window and when they have multiple display areas within the display
window, they are called tabs. Emacs has multiple windows within a
frame. Which terminology is more consistent? Sure, you couuld argue
emacs possibly could have called the windows panes and called the fringe
the frame, but is it really that hard a concept to get? Is the
terminology so alien that one reading of the manual page wouldn't be
enough to explain it?
>> There could be an argument that making users learn from scratch and with
>> different terminology will help because it makes them adopt a new
>> mindset and stops them from comparing it to what they already know?
>
> I think there are people who prefer to learn from scratch, and others
> who really do it better if they have something to base on.
>
Agreed. So, what now? Do we have to try and cater for everyone? Do we
adopt terminology which may be proven wrong or which could likely become
outdated in the future anyway? Do we put effort into trying to stay
in-sync with evolving terminology trends or do we put energy into just
pushing the boundries of what can be done conceptually and technically?
I vote for the latter.
Tim X
> "Juanma Barranquero" <lek...@gmail.com> writes:
>
>> I worry about the people who simply leaves Emacs behind.
>
> The learning curve might be one problem.
> The absence of some features the user want is another one.
>
> If Emacs implements a feature that no other editor implements
> then the user is usually not fussy about the learning curve.
>
> So instead of always trying to lessen the difficulty of learning
> Emacs, I think we should concentrate on features that users want
> (like CEDET, Tabs, etc.)
>
> Those who say "Hey! The learning curve is too high." are those
> who don't really want/need Emacs.
Exactly. Well said.
Tim X
> On Tuesday 22 July 2008, Juanma Barranquero wrote:
>
>> I do use CUA mode, though not for C-x etc. Selection with shift-keys
>> and visible region are very big pluses against the Emacs defaults,
>> IMHO.
>
> Visible region is a really big plus, but I guess you mean
> transient-mark-mode and I believe that's not part of CUA.
>
> On the other hand, selection with shift+arrows seems to me like the crappy
> stuff I used to do before entering the glory of Emacs. I would go to admit
> it's a small plus to be able to *also* do it like that, but I think setting
> the mark, as an anchor, and extend as you move with any other movement
> command (and that includes, e.g., i-search), is vastly superior.
I have to agree here. I rarely use the mouse (in fact, my mouse is the
oldest bit of equipment connected to my system - it has no scroll whell
and I purchased it in about 1995!
for me, setting the mark and then using the other features, like
i-search or just next line to move to the end of whatever it is I want
to select is faster and easier than either the mouse or holding down
shift and moving my hands off the main keys to the arrow keys.
This raises the other point I haven't touched on (and won't now - not in
any depth). I'll only say that many of the so-called modernisation
features Xah and ohters have mentioned are often poor replacements for a
far superior mode that pre-dates the more popular method - its like VHS
versus Beta - just because its more popular and possibly better known,
it doesn't mean that its actually a better solution.
Tim X
> "Juanma Barranquero" <lek...@gmail.com> writes:
>> Well, although I wouldn't support changing the Emacs keybindings
>> wholesale in a million years, Xah Lee has a point about them not being
>> particularly good. Do you really think that C-x C-c is good and Alt-F4
>> is bad?
>
> "C-x" in general is a prefix for "major" commands, and "C-c" was
> historically used to kill a program (you could question the significance
> of "C-c" itself, but it was used so universally, its meaning was quite
> firmly established).
>
> Thus "C-x C-c" is a fairly logical binding, if you ask me.
>
> [If you ask xahlee of course, he'll rant at you for a month about
> timecubes.]
>
> Now, the logic behind "Alt-F4" is, ... what, exactly?
>
Exactly and in fact, more effort and less convenient to move your hands
of the "home keys" to get to F4.
Tim X
But don't forget its not just a comp sci term. In fact, comp sci
borrowed it from "normal" english. In my comp sci days, also in the 80s,
it still had the more generalised term that fits with how emacs uses
it.
Juanma Barranquero
> But what does it really matter if some people just leave it behind?
Well, it matters to me. At least when I see people that I *know* will
benefit from using Emacs.
I don't have to look far. At work, there's people doing daily tasks
with Perl scripts and a very old (circa 1985, perhaps older) non-free
MS-DOS text editor, MultiEdit. If they used Emacs (and a couple
hundred lines of elisp code I could write for them), they would save
*lots* of pain (believe me when I say that: I wrote the Perl scripts
and know pretty well the data workflow). But there's no way in the
world that they will invest the time to adapt to Emacs, because it is
too far removed from what they're used to. In despair, I've even had
pipe dreams of writing a limited emulation of MultiEdit 3.0 in Emacs
22.
Their fault? Of course. Still...
> There is no blackmail here. You don't have to use it and you don't have
> to contribute. Just because I'm not arguing to change things to get new
> users doesn't mean any form of blackmail - thats just emotional
> dribble.
Sorry if I offended you. What I meant is that whether people will
contribute or not bears no relation to whether we should try to make
Emacs easier to learn or not for newbies.
> You mean like calling directories folders?
You won't see me defending that choice, though FWIW I think that's
Apple at work, not Microsoft.
> The point is, emacs didn't adopt its current terminology to be
> different. It adopted the current terminology because it was amongst the
> first to offer such functionality and at the time, there was little
> consensus on what to use.
I know.
> I don't have an issue with updating
> terminology if we can be assured the new terminology doesn't make the
> situation worse AND we don't lose clarity or end up with terms that are
> even less concise and prone to increased confusion.
Window vs. frame is an example. Not that I'm proposing changing it, of course.
> If we look at the more general meaning of buffer, it
> actually makes sense. For example, here are some definitions of buffer
> from some dictionaries -
Yes, it makes sense, but it was stretching a metaphor (even if it
predates Emacs). Moreover, I see two partially contradictory defenses
of "buffer":
- that it is obviously a good term, whose meaning is quite easy to
grasp from previous meanings
- that it is a concept more-or-less specific of Emacs and so it
helps newbies to realize that they are not dealing with files or
workspaces or anything like that.
> Hmmm. could be a theme emerging here in which a buffer is something that
> protects/cushions/pads against jarring/sudden/unwanted change/impact
> i.e. prvides a stable representation.
Curious. I wouldn't consider stability as *the* defining factor of
Emacs buffers; temporary buffers are about fast, non-persistent
storage, not stability, for example.
> 1. An area of memory used for storing messages. Typically, a
> buffer will have other attributes such as an input pointer
> (where new data will be written into the buffer), and output
> pointer (where the next item will be read from) and/or a count
> of the space used or free. Buffers are used to decouple
> processes so that the reader and writer may operate at
> different speeds or on different sized blocks of data.
>
> well, that does seem to describe emacs buffers - they are a section of
> memory, they have pointers (even a think referred to as point) and if we
> slightly generalise and consider the computer as one party and the human
> as the other, they also handle the mismatch of speeds and size of blocks
> that can be processed comfortably and with few errors!
I think that's conflating the program's view of buffers with the human
one. I've never thought of buffer's contents as messages, and they are
not FIFO queues for data.
> Turn things around the other way. Firefox refers to the whole thing as a
> window and when they have multiple display areas within the display
> window, they are called tabs. Emacs has multiple windows within a
> frame. Which terminology is more consistent?
According to current trends, Firefox. If we started Emacs from
scratch, I bet we would call the frame "window", and the windows,
"tabs" (or "panes", depending of the specific details of the user
interface).
> Is the
> terminology so alien that one reading of the manual page wouldn't be
> enough to explain it?
Do you find difficult to use Windows (if you use it at all) because
the directories are, from the desktop POV, called "folders"? I'd bet
the answer is not, still you joked about because you think it is the
wrong term.
> Agreed. So, what now? Do we have to try and cater for everyone? Do we
> adopt terminology which may be proven wrong or which could likely become
> outdated in the future anyway?
As opposed to the terminology we use now, that has not become
outdated, you mean?
> I vote for the latter.
I'll abstain.
Juanma
Juanma Barranquero
> Those who say "Hey! The learning curve is too high." are those
> who don't really want/need Emacs.
That's an overgeneralization I cannot agree with.
Perhaps these are people who have limited time to spend and (their
fault, ours, or both) do not see the benefits of switching to Emacs,
while the difficulties are painfully evident.
Juanma
Juanma Barranquero
> I have to agree here. I rarely use the mouse
I'm not sure how one thing is related to the other. I use the keyboard
much more than the mouse, and always for selection. Still I prefer the
shift keys and a visible region to other ways to do it.
> I'll only say that many of the so-called modernisation
> features Xah and ohters have mentioned are often poor replacements for a
> far superior mode that pre-dates the more popular method
Yes. Often. At other times, it is only the old fashioned way to do it.
If transient-mark-mode is now t by default, for example, it's hard to
believe that the alternative is a "far superior mode". Let's call them
two different, equally valid worldviews.
> - its like VHS
> versus Beta - just because its more popular and possibly better known,
> it doesn't mean that its actually a better solution.
http://en.wikipedia.org/wiki/Videotape_format_war
It's not evident that Beta was superior, and it's not evident either
why one format won over the other(s). There were multiple factors at
play. Still, if Emacs turned to be the Beta of programmer editors,
technical excellence would be small consolation.
Juanma
Juanma Barranquero
> Exactly and in fact, more effort and less convenient to move your hands
> of the "home keys" to get to F4.
I find much easier to type Alt-F4 than C-x C-c.
Juanma
Juanma Barranquero
> But don't forget its not just a comp sci term. In fact, comp sci
> borrowed it from "normal" english. In my comp sci days, also in the 80s,
> it still had the more generalised term that fits with how emacs uses
> it.
As would have lots of other terms. That's what I'm saying: "buffer"
seems like the perfect match for Emacs
data-structures-for-temporary-storage-under-whatever-name because
we've been using it that way for 25+ years, not because it is the
only, or more fitting, or more appropriate term.
This conversation (not specifically with you Tim, I'm talking about
the thread) goes nowhere. I said that I'm not proposing to change
anything, but at the same time I *don't* believe there's anything
sacred on the terms used in Emacs today. They are the best just
because of long use and long familiarity. Which does not necessarily
apply to newbies.
Juanma
xraysm...@gmail.com
> On Thu, Jul 24, 2008 at 14:32, Tim X <t...@nospam.dev.null> wrote:
> > Exactly and in fact, more effort and less convenient to move your hands
> > of the "home keys" to get to F4.
>
> I find much easier to type Alt-F4 than C-x C-c.
>
> Juanma
The problem there, is that Alt-F4 is Windows only, and Emacs is not a
windows-only program. There is no Alt-F4 on the Mac, or on the OLPC XO
(it's reserved by the OS for something else). But in Emacs, on all of
them, there is C-x C-c.