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