basic question: going back to dired

194 views
Skip to first unread message

Ben Aurel

unread,
Jul 21, 2008, 2:59:11 PM7/21/08
to help-gn...@gnu.org
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?

thanks

ben

Bastien

unread,
Jul 21, 2008, 7:21:34 PM7/21/08
to help-gn...@gnu.org
Ben Aurel <ben....@gmail.com> writes:

> 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

unread,
Jul 22, 2008, 1:56:28 AM7/22/08
to

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

unread,
Jul 22, 2008, 2:04:13 AM7/22/08
to
I don't think its a good idea to teach or insist that people adopt
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

unread,
Jul 22, 2008, 3:14:30 AM7/22/08
to
Ben Aurel <ben....@gmail.com> writes:
> 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

unread,
Jul 22, 2008, 4:23:24 AM7/22/08
to help-gn...@gnu.org
Xah <xah...@gmail.com> writes:

> 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

unread,
Jul 22, 2008, 4:26:26 AM7/22/08
to help-gn...@gnu.org
Xah <xah...@gmail.com> writes:

> 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

unread,
Jul 22, 2008, 5:46:44 AM7/22/08
to
Xah <xah...@gmail.com> writes:
> 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

unread,
Jul 22, 2008, 6:58:44 AM7/22/08
to

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

unread,
Jul 22, 2008, 7:01:26 AM7/22/08
to
Xah wrote:
> (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

unread,
Jul 22, 2008, 7:13:23 AM7/22/08
to Bastien Guerry, help-gn...@gnu.org
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...

> 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

unread,
Jul 22, 2008, 7:22:20 AM7/22/08
to Phil Carmody, help-gn...@gnu.org
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?

>> 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

unread,
Jul 22, 2008, 7:29:27 AM7/22/08
to Bastien Guerry, help-gn...@gnu.org
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.

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

unread,
Jul 22, 2008, 7:50:29 AM7/22/08
to
"Juanma Barranquero" <lek...@gmail.com> writes:
> 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

unread,
Jul 22, 2008, 8:14:20 AM7/22/08
to help-gn...@gnu.org
On Tue, Jul 22, 2008 at 13:50, Juanma <juanma_bellon> wrote:

> 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

unread,
Jul 22, 2008, 8:12:49 AM7/22/08
to nak...@gmail.com, help-gn...@gnu.org
nak...@gmail.com writes:

> 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

unread,
Jul 22, 2008, 8:34:18 AM7/22/08
to
"Juanma Barranquero" <lek...@gmail.com> writes:
>> 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

unread,
Jul 22, 2008, 8:50:51 AM7/22/08
to Xah, help-gn...@gnu.org
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

> 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)

unread,
Jul 22, 2008, 8:52:14 AM7/22/08
to Miles Bader, help-gn...@gnu.org

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

unread,
Jul 22, 2008, 9:05:02 AM7/22/08
to Xah, help-gn...@gnu.org
My attempted witty answer is somewhat diminished by an accidental
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

unread,
Jul 22, 2008, 9:47:48 AM7/22/08
to Lennart Borgman (gmail), help-gn...@gnu.org, Miles Bader
"Lennart Borgman (gmail)" <lennart...@gmail.com> wrote:

>> 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

unread,
Jul 22, 2008, 9:56:56 AM7/22/08
to Juanma Barranquero, help-gn...@gnu.org
On Tue, Jul 22, 2008 at 02:14:20PM +0200, Juanma Barranquero wrote:
> On Tue, Jul 22, 2008 at 13:50, Juanma <juanma_bellon> wrote:
>
> > 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).

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)

unread,
Jul 22, 2008, 10:03:50 AM7/22/08
to Nikolaj Schumacher, help-gn...@gnu.org, Miles Bader
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.

> 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

unread,
Jul 22, 2008, 10:42:45 AM7/22/08
to Phil Carmody, help-gn...@gnu.org
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.

> 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

unread,
Jul 22, 2008, 10:44:40 AM7/22/08
to Miles Bader, help-gn...@gnu.org
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.

Juanma


Phil Carmody

unread,
Jul 22, 2008, 10:49:24 AM7/22/08
to
"Juanma Barranquero" <lek...@gmail.com> writes:
> 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

unread,
Jul 22, 2008, 10:50:52 AM7/22/08
to
On Jul 22, 10:03 am, "Lennart Borgman (gmail)"

"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

unread,
Jul 22, 2008, 11:07:24 AM7/22/08
to Dan Davison, help-gn...@gnu.org
On Tue, Jul 22, 2008 at 15:56, Dan Davison <dav...@stats.ox.ac.uk> wrote:

> 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

unread,
Jul 22, 2008, 11:25:21 AM7/22/08
to
"Juanma Barranquero" <lek...@gmail.com> writes:
> 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

unread,
Jul 22, 2008, 11:53:38 AM7/22/08
to Phil Carmody, help-gn...@gnu.org
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.

> 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

unread,
Jul 22, 2008, 12:13:19 PM7/22/08
to
"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.

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

unread,
Jul 22, 2008, 12:21:42 PM7/22/08
to
"Juanma Barranquero" <lek...@gmail.com> writes:
> 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

unread,
Jul 22, 2008, 12:46:41 PM7/22/08
to help-gn...@gnu.org
"Juanma Barranquero" <lek...@gmail.com> writes:

> 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)

unread,
Jul 22, 2008, 12:51:18 PM7/22/08
to Phil Carmody, help-gn...@gnu.org
Phil Carmody wrote:
> 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

unread,
Jul 22, 2008, 12:53:40 PM7/22/08
to Juanma Barranquero, help-gn...@gnu.org
"Juanma Barranquero" <lek...@gmail.com> writes:

> 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

unread,
Jul 22, 2008, 12:58:34 PM7/22/08
to help-gn...@gnu.org
"Juanma Barranquero" <lek...@gmail.com> writes:

> 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

unread,
Jul 22, 2008, 1:06:02 PM7/22/08
to Juanma Barranquero, help-gn...@gnu.org, Miles Bader
"Juanma Barranquero" <lek...@gmail.com> writes:

> 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

unread,
Jul 22, 2008, 1:14:15 PM7/22/08
to help-gn...@gnu.org
"Juanma Barranquero" <lek...@gmail.com> writes:

> 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

unread,
Jul 22, 2008, 4:44:27 PM7/22/08
to
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. 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

unread,
Jul 22, 2008, 5:47:36 PM7/22/08
to

It's indeed short for "Pot calling the kettle black",
implying the recipient has a hypocritical attitude.

Bastien

unread,
Jul 22, 2008, 6:00:04 PM7/22/08
to Xah, help-gn...@gnu.org
Xah <xah...@gmail.com> writes:

> 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

unread,
Jul 22, 2008, 6:49:35 PM7/22/08
to Evans Winner, help-gn...@gnu.org
On Tue, Jul 22, 2008 at 18:13, Evans Winner <tho...@timbral.net> wrote:

> 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

unread,
Jul 22, 2008, 6:51:37 PM7/22/08
to Bastien Guerry, help-gn...@gnu.org
On Tue, Jul 22, 2008 at 18:46, Bastien Guerry <b...@altern.org> wrote:

> 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

unread,
Jul 22, 2008, 6:58:37 PM7/22/08
to Bastien Guerry, help-gn...@gnu.org
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.

> 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

unread,
Jul 22, 2008, 7:03:06 PM7/22/08
to Bastien Guerry, help-gn...@gnu.org
On Tue, Jul 22, 2008 at 18:58, Bastien Guerry <b...@altern.org> wrote:

> 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

unread,
Jul 22, 2008, 7:04:21 PM7/22/08
to Bastien Guerry, help-gn...@gnu.org, Miles Bader
On Tue, Jul 22, 2008 at 19:06, Bastien Guerry <b...@altern.org> wrote:

> 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

unread,
Jul 22, 2008, 7:21:27 PM7/22/08
to help-gn...@gnu.org
I'm a normal emacs user who has been using it for 4 years.
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

unread,
Jul 22, 2008, 7:36:16 PM7/22/08
to
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.


--
__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

unread,
Jul 22, 2008, 7:32:23 PM7/22/08
to help-gn...@gnu.org
"Juanma Barranquero" <lek...@gmail.com> writes:

> 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

unread,
Jul 22, 2008, 7:38:59 PM7/22/08
to Bastien Guerry, help-gn...@gnu.org
On Wed, Jul 23, 2008 at 01:32, Bastien Guerry <b...@altern.org> wrote:

> 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)

unread,
Jul 22, 2008, 7:43:49 PM7/22/08
to help-gn...@gnu.org
Xiao-Yong Jin wrote:
> 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

unread,
Jul 22, 2008, 7:49:54 PM7/22/08
to help-gn...@gnu.org
"Juanma Barranquero" <lek...@gmail.com> writes:

>> 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

unread,
Jul 22, 2008, 7:56:12 PM7/22/08
to help-gn...@gnu.org
"Juanma Barranquero" <lek...@gmail.com> writes:

> 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

unread,
Jul 22, 2008, 7:56:55 PM7/22/08
to Bastien Guerry, help-gn...@gnu.org
On Wed, Jul 23, 2008 at 01:49, Bastien Guerry <b...@altern.org> wrote:

> 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

unread,
Jul 22, 2008, 9:29:11 PM7/22/08
to help-gn...@gnu.org
Lennart Borgman (gmail) wrote:
> 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

unread,
Jul 23, 2008, 4:29:14 AM7/23/08
to help-gn...@gnu.org
p...@informatimago.com (Pascal J. Bourguignon) writes:

> 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

unread,
Jul 23, 2008, 5:46:38 AM7/23/08
to
Evans Winner <tho...@timbral.net> writes:

> "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

unread,
Jul 23, 2008, 5:57:32 AM7/23/08
to

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

unread,
Jul 23, 2008, 6:16:53 AM7/23/08
to
"Juanma Barranquero" <lek...@gmail.com> writes:

>
> 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

unread,
Jul 23, 2008, 6:25:01 AM7/23/08
to
"Juanma Barranquero" <lek...@gmail.com> writes:

> 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

unread,
Jul 23, 2008, 6:59:40 AM7/23/08
to help-gn...@gnu.org
On Wed, Jul 23, 2008 at 12:16, Tim X <ti...@nospam.dev.null> wrote:

> 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)

unread,
Jul 23, 2008, 7:09:13 AM7/23/08
to help-gn...@gnu.org
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.

> 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

unread,
Jul 23, 2008, 7:11:18 AM7/23/08
to help-gn...@gnu.org
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.

> 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

unread,
Jul 23, 2008, 7:39:50 AM7/23/08