Re: basic question: going back to dired

Re: basic question: going back to dired

[Xah]

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

☄

Re: basic question: going back to dired

[Bastien Guerry]

Xah <xahlee@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

Re: basic question: going back to dired

[Juanma Barranquero]

On Tue, Jul 22, 2008 at 10:23, Bastien Guerry <bzg@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

Re: basic question: going back to dired

[Bastien Guerry]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Tue, Jul 22, 2008 at 10:23, Bastien Guerry <bzg@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

Re: basic question: going back to dired

[Juanma Barranquero]

On Tue, Jul 22, 2008 at 18:46, Bastien Guerry <bzg@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

Re: basic question: going back to dired

[Xah]

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/

☄

Re: basic question: going back to dired

[Xah]

On Jul 22, 1:23 am, Bastien Guerry <b...@altern.org> wrote:
> 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.

Yes i agree that «When you're answering questions about Emacs, better
to refer to to the manual as much as possible.». However, i'm thinking
that some terms used in emacs can use improvement by adapting more
modern terms that has for one reason or another become standard among
Windows, Mac, Linux, which together accounts for perhaps 99% of
computer use.

In this thread, i suggest that the term “buffer” could be changed to
“tab”, “file”, “workspace” or something similar, and “keybinding” can
be changed to “keyboard shortcut” in any context that's not about
assiging a keyboard shortcut.

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

If we adapt the term keyboard shortcut instead of keybinding, it will
reduce one learning step. As for “assigning a keyboard shortcut”, the
act is more programing oriented or for advanced users, so i think
“creating a keybinding” or “bind a key” is still appropriate in emacs
and elisp doc.

The point is about reducing learning steps by using terms that most
people already understand.

You may argue that “keybinding” is more technically correct. However,
terminologies in the industry, may it be science or technology,
changes by various forces. Today, “keyboard shortcut” for good or bad
has become the dominant, universally understood term. Adopting it
wouldn't hurt emacs's power in anyway, nor i think cause any
confusion.

About the term “buffer”, it's more complex to explain. We can look at
it in another way. Almost all other text editing and IDE apps, they
don't use that term. MS VisualStudio, Apple's XCode, BBEdit, Eclipse,
TextMate, Microsoft Word...

If you look at these software, actually they are buffer too. How can
they not be buffers? However, they don't use that term, because the
term really is more forceful if you think of the app in terms of
implementation.

Similar situation occurs in other apps and terms, for example:
directory → folder, file manager → Desktop, pointing device → mouse
(what?? a rodent??), left button and right butten → first button and
second button, server and client → client and server in X, Windows and
Frames in most apps and html is Frames and Windows in emacs, copy/cut/
paste is kill-ring-save/kill-region/yank (huh??) etc.

If you look at detail, one may argue some are more technically
correct. But the point is that for whatever reasons, certain choice of
terms becomes the dominant, standard, ones. English itself and its
lexicon are largely inconsistent and down right weird. For example,
what's the logic of “OK”? What's the logic in double negatives like “I
aint't no gonna do it”? What's with “hell no!”. Some of these will get
grammarian and pundit's blood flying, but the fact is that for complex
social reasons, logic and technical merit is not the main force in how
usage changes. As Juanma Barranquero mentioned in this thread, there's
descriptive vs perscritive stances that's one of the main controversy
among English experts. This issue is so big that entire dictionary are
created as a result in this controversy (American Heritage Dict).

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

I'm somewhat a amature expert in linguistics, in particular lexicon
and terminology. I've actually wrote a lot about the issue of
terminologies. For some diverson, see:

• Politics and the English Language
http://xahlee.org/p/george_orwell_english.html

• Math Terminology and Naming of Things
http://xahlee.org/cmaci/notation/math_namings.html

• A Review of 3 Dictionaries
http://xahlee.org/Periodic_dosage_dir/bangu/dict_review.html

• English Vocabulary Compendium
http://xahlee.org/PageTwo_dir/Vocabulary_dir/vocabulary.html

  Xah
∑ http://xahlee.org/

☄

Re: basic question: going back to dired

[Michael Ekstrand]

Xah <xahlee@gmail.com> writes:
> In this thread, i suggest that the term “buffer” could be changed to
> “tab”, “file”, “workspace” or something similar, and “keybinding” can
> be changed to “keyboard shortcut” in any context that's not about
> assiging a keyboard shortcut.

I should probably know better than to dip my oar in the water here, but
I think that the term "buffer" cannot and should not be changed to any
of "tab", "file", or "workspace", largely by virtue of the fact that it
is not equivalent to any of the above.

It is not a tab.  If you have "tabs" going in Emacs (which XEmacs seems
to support in some fashion), or are in some other editor with tabs, they
are equivalent Emacs' "windows", not buffers.  You could view the same
buffer in multiple tabs.  What then?

It is not a file.  Sure, many buffers are backed by files.  But a large
number of the buffers I use (SVN/CVS/HG status buffers, dired buffers,
Gnus mail summary/group list buffers, the buffer in which I'm writing
this e-mail if it weren't for the fact that I'm using nnml, so each
message is a file, and I could go on) are not directly corresponding to
files.  So to use the term "file" instead of "buffer" would also be
incorrect.  Think of Info buffers for another example -- one buffer
views, in turn, pieces of many different files.

Finally, it is not a workspace.  Etymologically, workspace is the most
viable alternative presented, but the term workspace as commonly used by
other editing systems does not apply.  In Eclipse, for example,
"workspace" is a collection of projects, views, and settings -- one
working context.  In my limited and dated experience with Visual Studio,
it uses the term similarly.  This would be somewhat equivalent to an
Emacs session, but definitely not a buffer.

A  "buffer" is  a useful  term  referring to  a text  chunk, or  perhaps
alternatively an entity manipulable via a window.  If we replace it with
any of the  suggested replacement terms, we have a  term which ceases to
accurately describe  the item referred to.   Yes, it's a  new term.  But
Emacs  is a  complex, technical  tool, and  expecting users  to  do some
learning  (even of  terminology) is  a reasonable  thing.  I  would also
argue  that introducing (and  defining!) a  new term  for a  new concept
facilitates better and easier  understanding of the editor than applying
a  familiar  term to  something  that  it  doesn't accurately  describe.

Remember as  well, though, that most  other editors don't  even have the
concept that Emacs  calls a "buffer" -- they let you  edit files in tabs
and/or  windows  ("frames")  possibly  collected into  workspaces.   Why
should we apply  one of their terms inaccurately to  a concept that they
don't even possess?

If we want to banter about confusing terminology, there are some
reasonable targets ("window" and "frame" vs. "pane" and "window", for
example), but even there, the costs involved in changing are
significant.

- Michael

-- 
mouse, n: A device for pointing at the xterm in which you want to type.

Re: basic question: going back to dired

[Xah]

Hi Michael,

I think your post is well thought out.

I don't totally agree though. Most terminology issues is simply a
habituation. If you look at arbitrary software apps and terms, and
think about it detail, there are all sort of illogicalities.

For example, what's a Tab? What's a mouse? What the heck is a Desktop,
Folder? Of course they all work by analogy, but superior technical
terms exists for them.
(e.g. Tab can be buffer, mouse should be pointing device, desktop
should be file manager, folder should be dir)

However, you don't see people complain about the term Tabs in FireFox,
or mouse, or Folder in Apple circles, or Desktop in Mac/Windows/KDE/
Gnome.

The term buffer works great, but again consider from a outsider's
point of view. Apple's Xcode, Microsoft's VisualStudio, Eclispse and
JavaBeans IDE for java. These are major IDEs for programing. They
don't use “buffer”. BUT THEY ARE BUFFERS!!

The point is not about logical quality in the term, but more about
standard terminologies and universal adoption.

I think, that emacs's manual, can benefit by replacing the term buffer
in most places.

All right, i don't want to push this point. Let's drop it then. How
about we focuse on Keybinding vs Keyboard shortcut? Perhaps that is
more easier to accept among emacsers.

There are quite a lot technically questionable terms in emacs too. For
example, kill-ring-save, kill-region, yank, kill-buffer.

Why kill? death? Wouldn't delete or remove be better in some technical
sense? kill-buffer can be close-buffer or remove-buffer. kill-ring-
save could be kill-ring-append, kill-ring-push, kill-ring-add. And why
kill-ring? It's not really circular as in The Lord Of The Ring, nor is
it like mathematician's algebraic structure “ring”. How about text-
depository or data-depository instead of kill-ring?
Wait, better is buffer for kill-ring. After all, as so many emacsers
insists here, buffer is rather the correct technical term as it is a
temp storage!

Also, note the sense of kill in kill-region and kill-buffer are
incompatible. kill-region pushes text, while kill-buffer doesn't. So
there, there is a inconsistency!! Egadz, emacs is trying to dumb me
down.

There's no ends when we start to exam the logicality of terminologies,
may it in be computer software, or scientific jargons. A major force
in the shaping of terminology is just historical happenstance.

So, changing some criticial user-level terms in emacs manual so that
they are more universally recoginzed, would be beneficial because it
fixes one of the problem people complaints about emacs learning curve.
Yet, choose changes that are easy to do and doesn't hurt emacs in ANY
WAY. This is why, i think for example, switching the term keybinding
to keyboard shortcut in emacs manual would be a improvement. (not for
example, in elisp manual, because lots of lisp functions are tied to
old terms, and programing is one level deep then using emacs. Programs
understands things like obsolete functions and baggage in the
language. Again, some says this creates inconsistency, but i don't
think so in practice. If we nitpick we always will find inconsistency.
Hell, in Perl and unix, there's almost nothing that is consistent.)

  Xah
∑ http://xahlee.org/

☄

On Jul 31, 5:28 am, Michael Ekstrand <mich...@elehack.net> wrote:
> Xah<xah...@gmail.com> writes:
> > In this thread, i suggest that the term “buffer” could be changed to
> > “tab”, “file”, “workspace” or something similar, and “keybinding” can
> > be changed to “keyboard shortcut” in any context that's not about
> > assiging a keyboard shortcut.
>
> I should probably know better than to dip my oar in the water here, but
> I think that the term "buffer" cannot and should not be changed to any
> of "tab", "file", or "workspace", largely by virtue of the fact that it
> is not equivalent to any of the above.
>
> It is not a tab.  If you have "tabs" going in Emacs (which XEmacs seems
> to support in some fashion), or are in some other editor with tabs, they
> are equivalent Emacs' "windows", not buffers.  You could view the same
> buffer in multiple tabs.  What then?
>
> It is not a file.  Sure, many buffers are backed by files.  But a large
> number of the buffers I use (SVN/CVS/HG status buffers, dired buffers,
> Gnus mail summary/group list buffers, the buffer in which I'm writing
> this e-mail if it weren't for the fact that I'm using nnml, so each
> message is a file, and I could go on) are not directly corresponding to
> files.  So to use the term "file" instead of "buffer" would also be
> incorrect.  Think of Info buffers for another example -- one buffer
> views, in turn, pieces of many different files.
>
> Finally, it is not a workspace.  Etymologically, workspace is the most
> viable alternative presented, but the term workspace as commonly used by
> other editing systems does not apply.  In Eclipse, for example,
> "workspace" is a collection of projects, views, and settings -- one
> working context.  In my limited and dated experience with Visual Studio,
> it uses the term similarly.  This would be somewhat equivalent to an
> Emacs session, but definitely not a buffer.
>
> A  "buffer" is  a useful  term  referring to  a text  chunk, or  perhaps
> alternatively an entity manipulable via a window.  If we replace it with
> any of the  suggested replacement terms, we have a  term which ceases to
> accurately describe  the item referred to.   Yes, it's a  new term.  But
> Emacs  is a  complex, technical  tool, and  expecting users  to  do some
> learning  (even of  terminology) is  a reasonable  thing.  I  would also
> argue  that introducing (and  defining!) a  new term  for a  new concept
> facilitates better and easier  understanding of the editor than applying
> a  familiar  term to  something  that  it  doesn't accurately  describe.
>
> Remember as  well, though, that most  other editors don't  even have the
> concept that Emacs  calls a "buffer" -- they let you  edit files in tabs
> and/or  windows  ("frames")  possibly  collected into  workspaces.   Why
> should we apply  one of their terms inaccurately to  a concept that they
> don't even possess?
>
> If we want to banter about confusing terminology, there are some
> reasonable targets ("window" and "frame" vs. "pane" and "window", for
> example), but even there, the costs involved in changing are
> significant.
>
> - Michael
>
> --
> mouse, n: A device for pointing at the xterm in which you want to type.

Re: basic question: going back to dired

[Nikolaj Schumacher]

Michael Ekstrand <michael@elehack.net> wrote:

> It is not a tab.  If you have "tabs" going in Emacs (which XEmacs seems
> to support in some fashion), or are in some other editor with tabs, they
> are equivalent Emacs' "windows", not buffers.  You could view the same
> buffer in multiple tabs.  What then?

I don't think you're right here.  Looking at Firefox, for instance, tabs
there don't correspond to Emacs windows at all.  Each Firefox window has
a tab-bar that switch between several tabs, just as each Emacs window
can switch between several buffers.

If each tab-bar has the same set of tabs there would be no problem in
viewing the same tab (= buffer) in multiple windows.

Of course, Emacs doesn't have tab-bars.  So I agree, buffers aren't tabs.


regards,
Nikolaj Schumacher

Re: basic question: going back to dired

[Xah]

On Aug 1, 1:05 am, Nikolaj Schumacher <n_schumac...@web.de> wrote:
> Michael Ekstrand <mich...@elehack.net> wrote:
> > It is not a tab.  If you have "tabs" going in Emacs (which XEmacs seems
> > to support in some fashion), or are in some other editor with tabs, they
> > are equivalent Emacs' "windows", not buffers.  You could view the same
> > buffer in multiple tabs.  What then?
>
> I don't think you're right here.  Looking at Firefox, for instance, tabs
> there don't correspond to Emacs windows at all.  Each Firefox window has
> a tab-bar that switch between several tabs, just as each Emacs window
> can switch between several buffers.
>
> If each tab-bar has the same set of tabs there would be no problem in
> viewing the same tab (= buffer) in multiple windows.
>
> Of course, Emacs doesn't have tab-bars.  So I agree, buffers aren't tabs.

Emacs has tabs. See
http://www.emacswiki.org/cgi-bin/wiki/TabBarMode

i think it should be bundled with emacs and on by default on. But what
do i know?

  Xah
∑ http://xahlee.org/

☄

Re: basic question: going back to dired

[Ted Zlatanov]

On Fri, 1 Aug 2008 04:15:02 -0700 (PDT) Xah <xahlee@gmail.com> wrote: 

X> Emacs has tabs. See
X> http://www.emacswiki.org/cgi-bin/wiki/TabBarMode

X> i think it should be bundled with emacs and on by default on. But what
X> do i know?

There's been a lot of discussion about making Emacs more Eclipse-like in
terms of workspaces, tabs, and other organizational features.  This
transpired on the emacs-devel list and you should look through the
messages if you have the time (there's hundreds).  They specifically
addressed tabs, though the goal is to improve the overall experience,
not necessarily copy features and terminology from Eclipse.

Ted

Re: basic question: going back to dired

[Michael Ekstrand]

Nikolaj Schumacher <n_schumacher@web.de> writes:
> Michael Ekstrand <michael@elehack.net> wrote:
>
>> It is not a tab.  If you have "tabs" going in Emacs (which XEmacs seems
>> to support in some fashion), or are in some other editor with tabs, they
>> are equivalent Emacs' "windows", not buffers.  You could view the same
>> buffer in multiple tabs.  What then?
>
> I don't think you're right here.  Looking at Firefox, for instance, tabs
> there don't correspond to Emacs windows at all.  Each Firefox window has
> a tab-bar that switch between several tabs, just as each Emacs window
> can switch between several buffers.

It depends on how tabs are implemented and conceived of.  If that is how
they are done, you may be right.

When Vim added tabs, however, each frame (of which you could only have
one, actually) could have tabs, and each tab had a set of windows, and
each window could view a buffer.  Tabs behaved more like Emacs frames do
when on a terminal, except that there was a horizontal listing of them
at the top of the screen.

- Michael

-- 
mouse, n: A device for pointing at the xterm in which you want to type.
Confused by the strange files?  I cryptographically sign my messages.
For more information see <http://www.elehack.net/resources/gpg>.

Re: basic question: going back to dired

[Cor Gest]

The entity, AKA Michael Ekstrand <michael@elehack.net> wrote :
(selectively-snipped-or-not-P)

> When Vim added tabs, however, each frame (of which you could only have
> one, actually) could have tabs, and each tab had a set of windows, and
> each window could view a buffer.  Tabs behaved more like Emacs frames do
> when on a terminal, except that there was a horizontal listing of them
> at the top of the screen.

Put the tabs vertically opposite to the scrollbar and call them
'view drawers'. The confusion would be complete and the all would really have
their knickers in a bunch.

Cor 

-- 
  OSBBQ 2008 ::  13 September 2008 http://osbbq.nl.linux.org

(defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
                http://www.clsnet.nl/mail.php

Re: basic question: going back to dired

[Nikolaj Schumacher]

Xah <xahlee@gmail.com> wrote:

> However, i'm thinking
> that some terms used in emacs can use improvement by adapting more
> modern terms that has for one reason or another become standard among
> Windows, Mac, Linux, which together accounts for perhaps 99% of
> computer use.

I think many here actually agree.  It would be nice if windows and
frames were named the other way around.  Unfortunately they aren't.
What most people are refuting is the cost and benefit you claim.

> In this thread, i suggest that the term “buffer” could be changed to
> “tab”, “file”, “workspace” or something similar, and “keybinding” can
> be changed to “keyboard shortcut” in any context that's not about
> assiging a keyboard shortcut.

Tab makes only sense when you have a tab bar.
File is misleading, because there are many non-file buffers.
Workspace is a bad metaphor, because it implies a whole, not not parts.
I have one workspace at home, not a desk full of workspaces.

Buffer might not be the most intuitive term, but its the only one I know
that makes sense.  Maybe sheet would be appropriate, but I think that's
ambiguous, as well.

> If we adapt the term keyboard shortcut instead of keybinding, it will
> reduce one learning step. As for “assigning a keyboard shortcut”, the
> act is more programing oriented or for advanced users, so i think
> “creating a keybinding” or “bind a key” is still appropriate in emacs
> and elisp doc.
>
> The point is about reducing learning steps by using terms that most
> people already understand.
>
> Today, “keyboard shortcut” for good or bad has become the dominant,
> universally understood term. Adopting it wouldn't hurt emacs's power
> in anyway, nor i think cause any confusion.

I disagree that shortcut is the only term all people will understand.
Keybinding is quite frequently used outside of Emacs.  Even Microsoft
uses it occasionally[1].  I can't imagine anyone reading the word and not
knowing what it means out of context.  Some editors (e.g. Eclipse) don't
give it a name at all, they just say "keys" and give a list of bindings.
If people are smart enough to figure that out, keybinding should be even
easier.

If they can't find how to configure their keys (I believe I had the same
problem), it's because there is no place to do it.  You have to find out
what command (global-set-key) to use, where to put it (.emacs) and what
notation to use.  That's a much bigger hurdle.
(Although it teaches you quite a bit, as well.)

Either way, I think complete standardization is not necessary in
software.  Firefox uses File -> Quit, Eclipse uses File -> Exit.  Both
do their job and both are understandable.  I don't know which one is
dominant, because it doesn't matter.

> About the term “buffer”, it's more complex to explain. We can look at
> it in another way. Almost all other text editing and IDE apps, they
> don't use that term. MS VisualStudio, Apple's XCode, BBEdit, Eclipse,
> TextMate, Microsoft Word...
>
> If you look at these software, actually they are buffer too. How can
> they not be buffers? However, they don't use that term, because the
> term really is more forceful if you think of the app in terms of
> implementation.

If they don't use that term, maybe it's because they don't have the
concept.  Looking at Eclipse, I don't see a way to create an empty
"buffer", or to open a non-file buffer in the editing window.  I think
this "unified" representation of things is quite unique to Emacs.

> copy/cut/ paste is kill-ring-save/kill-region/yank (huh??) etc.

Kill and yank are outdated terms, I agree.  But they actually helped me
remember the keybindings.  That's worth something, too.

> If you look at detail, one may argue some are more technically
> correct. But the point is that for whatever reasons, certain choice of
> terms becomes the dominant, standard, ones. English itself and its
> lexicon are largely inconsistent and down right weird.

Exactly.  But that's no reason to go through all books and replace the
obscure terms with the dominant ones so that they're easier to read. :)

> What's the logic in double negatives like “I aint't no gonna do it”?

The logic behind a double negative is that it becomes a positive.  That
logic doesn't apply to this sentence, because it isn't English. :)


regards,
Nikolaj Schumacher

[1]: http://www.microsoft.com/downloads/details.aspx?familyid=e5f902a8-5bb5-4cc6-907e-472809749973&displaylang=en

Re: basic question: going back to dired

[Juanma]

On Thursday 31 July 2008, Xah wrote:
> what's the logic of “OK”?

For all I know, it comes from "0 Knock-outs" (from USA civil war times,
IIRC), i.e., all went really well.

But this is really off-topic.
-- 
Juanma

"Having a smoking section in a restaurant is like
 having a peeing section in a swimming pool."
       -- Edward Burr

Re: basic question: going back to dired

[Juanma Barranquero]

On Wed, Aug 6, 2008 at 22:38, Juanma <juanma_bellon@yahoo.es> wrote:

> For all I know, it comes from "0 Knock-outs" (from USA civil war times,
> IIRC), i.e., all went really well.

See http://en.wikipedia.org/wiki/Okay#Etymology

"0 knock-outs" is among the "Improbable or refuted etymologies".

   Juanma

Re: basic question: going back to dired

[Chris McMahan]

I seem to remember from my early school days it was a campaign slogan
for someone nick-named Kinderhook that went something like

Old Kinderhook is OK

- Chris

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Wed, Aug 6, 2008 at 22:38, Juanma <juanma_bellon@yahoo.es> wrote:
>
>> For all I know, it comes from "0 Knock-outs" (from USA civil war times,
>> IIRC), i.e., all went really well.
>
> See http://en.wikipedia.org/wiki/Okay#Etymology
>
> "0 knock-outs" is among the "Improbable or refuted etymologies".
>
>    Juanma
>
>

-- 
     (.   .)
  =ooO=(_)=Ooo=====================================
  Chris McMahan | first_initiallastname@one.dot.net
  =================================================

Re: basic question: going back to dired

[Tim X]

Juanma <juanma_bellon@yahoo.es> writes:

> On Thursday 31 July 2008, Xah wrote:
>> what's the logic of “OK”?
>
> For all I know, it comes from "0 Knock-outs" (from USA civil war times,
> IIRC), i.e., all went really well.
>
> But this is really off-topic.

I seem to remember it was originally from a presidential campaign -
possibly something like "It will be OK with LBJ". 

tim

-- 
tcross (at) rapttech dot com dot au

Re: basic question: going back to dired

[Miles Bader]

Ben Aurel <ben.aurel@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....

Re: basic question: going back to dired

[nakkaya]

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

Re: basic question: going back to dired

[Thierry Volpiatto]

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

Re: basic question: going back to dired

[Colin S. Miller]

Ben Aurel 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?
> 
> thanks
> 
> ben
> 
> 
> 

Ben,

C-x k RET   will close the current file
C-x C-j     will open the dired on the directory containing the current file.
If dired is already open but not visible for that directory, then the dired buffer
is made visible.

This will make emacs swap to dired, but the current file will remain open.
Pressing C-x b <filename> will allow you to swap to it.

In dired 'g' will force dired to reread the directory if it has changed.


Emacs allows you to have multiple files open at once. Unlike most editors
Emacs does not allocate a frame (child window in other editors' terminology).

Instead you create the frames you require and then display the buffers (files)
you wish to view at present in them. The undisplayed buffers will keep their contents
until you explicitly kill (close) them.

HTH,
Colin S. Miller

-- 
Replace the obvious in my email address with the first three letters of the hostname to reply.

Re: basic question: going back to dired

[Colin S. Miller]

Esteban Fornal wrote:
>
>
> 2008/7/27 Colin S. Miller <no-spam-thank-you@csmiller.demon.co.uk 
> <mailto:no-spam-thank-you@csmiller.demon.co.uk>>
>
>     C-x k RET   will close the current file
>     C-x C-j     will open the dired on the directory containing the
>     current file.
>     HTH,
>     Colin S. Miller
>
>     -- 
>     Replace the obvious in my email address with the first three
>     letters of the hostname to reply.
>
>
> Hello,
> This also is my first post here, My question is how view file name  
> list what match with regular expresions when I open file with C-x C-f 
> and press tab
>
> sorry my bad english and thanks.
You can either
1) Press C-x o to swap to the *completion* buffer, then press C-u C-s 
for regexp-search forward.
 From there press enter your regexp. Press C-s to search for the next 
match, RET twice to open the file.

2) Press RET with no file name to open the directory in dired, and then 
use C-U C-s as above.

PS,
I've replied to the group; you seem to have accidentally replied to me 
directly.

HTH,
Colin S. Miller

-- 
Replace the obvious in my email address with the first three letters of the hostname to reply.

Re: basic question: going back to dired

[Chris McMahan]

Juan Manuel Menéndez Bellón <juanma_bellon@yahoo.es> writes:

> --- El jue, 31/7/08, Juanma Barranquero <lekktu@gmail.com> escribió:
>
>> > I find C-x C-c really easy.
>> 
>> I don't find any control key combo "easy".
>> Perhaps I would find them a bit easier if I did the usual Caps Lock /
>> Ctrl switch, but I suspect it wouldn't be much of a difference.
>
> Of course, I'm not sure how it will feel for you, but I find it to be a
> very big difference. That switch moves the Ctrl key from a position that
> is unreachable with normal typing position and a fairly normal keyboard,
> to a position in the home row. You pass from needing to shift your whole
> arm to needing a minor pinky shift.
>
> I use Control more often than Caps Lock (by orders of magnitude, I'm
> sure), so I rather have the former in the home row.
>
> Best regards,
> -- 
> Juanma

I must agree wholeheartedly with Juanma. Until I remap the caps-lock
to control, I'm basically useless in Emacs. Once the change is made,
however, I can touch type and move around in emacs without even really
thinking about it. It becomes much easier!

- Chris

-- 
     (.   .)
  =ooO=(_)=Ooo=====================================
  Chris McMahan | first_initiallastname@one.dot.net
  =================================================

Re: basic question: going back to dired

[Xah]

> I must agree wholeheartedly with Juanma. Until I remap the caps-lock
> to control, I'm basically useless in Emacs. Once the change is made,
> however, I can touch type and move around in emacs without even really
> thinking about it. It becomes much easier!

I must say something about remapping Control to Cap Lock...

among tech geek circles, it's widely recommended like a dogma.
However, remapping Control to Cap Lock seriously violates some basic
ergonomic principles.

In touch typing, modifiers comes in pairs, such as Shift. The accepted
ergonomic way to press them is using one hand to press the modifier
and the other to press the other key.

You can see how by it is otherwise by disabling one of the Shift key.
With just one modifier, you are heavily handicapped. As a example, try
this exercise:

TYPE THIS SENTENCE WITH JUST ONE SHIFT KEY AND WITHOUT USING CAP LOCK.

Quickly, you'll see the pain.

Similar is with other modifier keys such as Alt and Ctrl. The reason
they are not noticed only because they are seldomly used. However, in
emacs, it is heavily used. So, by mapping Ctrl to the Cap Lock key,
you put a severe handicap by putting all work into the left pinky, and
restrict the number of keys you can comfortably use with Ctrl.

The reason that most still recommend it is because the Ctrl key is
traditionally on the corner of keyboard and rather difficult to press.
Also, many keyboards does not have right Ctrl. So, in a sense, Cap
Lock as Ctrl is a improvement. It is especially a good solution on
labtop keyboards.

There are 2 ways to remedy the problem of pressing of Ctrl.

One is to buy a good keyboard that has big Alt and Ctrl keys, and on
both side of the keyboard, and symmetrically placed with respect to
your thumbs when hands in home position. (some keyboards, such as
Apple's, has the right side modifiers far to the right, rendering them
unusable for touch type) Microsoft's ergonomic keyboard satisfies this
requirement (MS's ergo keyboards is quite popular, and in fact MS's
input devices is highly received. I haven't checked the facts, but i
think MS's input devices has the largest market share. The second now
is perhaps Logitech.).

The other way is to learn to type the corner Ctrl by pressing down
your palm or semi fist, instead of poking it with your pinky. This can
be easily done on most PC keyboards.

To see which is better, you can type this sentence and press Ctrl for
every letter. (do it outside of emacs) You can quickly find out which
way is better for you.

  Xah
∑ http://xahlee.org/

☄

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Xah wrote:
> In touch typing, modifiers comes in pairs, such as Shift. The accepted
> ergonomic way to press them is using one hand to press the modifier
> and the other to press the other key.


I would rather from an ergonomic view recommend "sticky keys/modifiers":

   http://www.emacswiki.org/cgi-bin/wiki/StickyModifiers

Re: basic question: going back to dired

[Xah]

On Jul 31, 7:35 am, "Lennart Borgman (gmail)"
<lennart.borg...@gmail.com> wrote:
> Xahwrote:
> > In touch typing, modifiers comes in pairs, such as Shift. The accepted
> > ergonomic way to press them is using one hand to press the modifier
> > and the other to press the other key.
>
> I would rather from an ergonomic view recommend "sticky keys/modifiers":
>
>    http://www.emacswiki.org/cgi-bin/wiki/StickyModifiers

Btw, emacs package for sticky modifier is not necessary on the Mac.

In the Mac, just go to your System Preference, click on the Universal
Access (i.e. for the handicapped), and there you can setup sticky keys
system wide.

Mac has this before OSX too, since about early 1990s i think. (Also,
you can swap any modifiers to any other in OSX. Just go to sys pref,
keyboard & mouse, keyboard, modifier. For more detail, see
How to Swap Modifier Keys on OS X
http://xahlee.org/emacs/osx_swapping_modifier_keys.html
)

On OSX, you can actually setup arbitrary commands to keys much like
how you rebind keys in emacs. (However, they only work in Cocoa apps
and not perfectly.). See

How To Create Your Own Keybinding In Mac Os X
 http://xahlee.org/emacs/osx_keybinding.html

-----------------

On Windows, i thought sticky key pref exist that are part of the
Windows OS, but i haven't used Windows for many years now. Doesn't it
exist as part of the OS, Lennart?

  Xah
∑ http://xahlee.org/

☄

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Xah wrote:
>> I would rather from an ergonomic view recommend "sticky keys/modifiers":
>>
>>    http://www.emacswiki.org/cgi-bin/wiki/StickyModifiers
> 
> Btw, emacs package for sticky modifier is not necessary on the Mac.
> 
> In the Mac, just go to your System Preference, click on the Universal
> Access (i.e. for the handicapped), and there you can setup sticky keys
> system wide.

Could you please enter that information on the wiki page?

Re: basic question: going back to dired

[Xah]

On Jul 31, 9:45 am, "Lennart Borgman (gmail)"
<lennart.borg...@gmail.com> wrote:
> Xahwrote:
> >> I would rather from an ergonomic view recommend "sticky keys/modifiers":
>
> >>    http://www.emacswiki.org/cgi-bin/wiki/StickyModifiers
>
> > Btw, emacs package for sticky modifier is not necessary on the Mac.
>
> > In the Mac, just go to your System Preference, click on the Universal
> > Access (i.e. for the handicapped), and there you can setup sticky keys
> > system wide.
>
> Could you please enter that information on the wiki page?

i didn't look at that page before, thinking it was a elisp package. It
actually is just a page telling people how sticky key can be setup on
different OSes. Perhaps you are mocking me, but it already has info on
OSX. :)

Gee, you have to post this publicly and waste all these emacs lover's
time? :)

You and your strange emacs setup are incredible. Btw, how did you set
Cap Lock to M-x in Windows? (i'd like to have that in osx too)

You DO realize that most emacs lovers here can't bear the mention of
Microsoft Windows right? and you want emacs to conform to Window's UI
standards. What a crime it is.

  Xah
∑ http://xahlee.org/

☄

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Xah wrote:
> On Jul 31, 9:45 am, "Lennart Borgman (gmail)"
> <lennart.borg...@gmail.com> wrote:
>> Xahwrote:
>>>> I would rather from an ergonomic view recommend "sticky keys/modifiers":
>>>>    http://www.emacswiki.org/cgi-bin/wiki/StickyModifiers
>>> Btw, emacs package for sticky modifier is not necessary on the Mac.
>>> In the Mac, just go to your System Preference, click on the Universal
>>> Access (i.e. for the handicapped), and there you can setup sticky keys
>>> system wide.
>> Could you please enter that information on the wiki page?
> 
> i didn't look at that page before, thinking it was a elisp package. It
> actually is just a page telling people how sticky key can be setup on
> different OSes. Perhaps you are mocking me, but it already has info on
> OSX. :)

No, rather myself. I thought it was not there.

> Gee, you have to post this publicly and waste all these emacs lover's
> time? :)
> 
> You and your strange emacs setup are incredible. Btw, how did you set
> Cap Lock to M-x in Windows? (i'd like to have that in osx too)

(setq w32-enable-caps-lock nil)
(global-set-key [capslock] 'execute-extended-command)

> You DO realize that most emacs lovers here can't bear the mention of
> Microsoft Windows right? and you want emacs to conform to Window's UI
> standards. What a crime it is.

Frustration that is not too big is supposed to make you grow 
psychologically ;-)

>   Xah
> ∑ http://xahlee.org/
> 
> ☄
> 

Re: basic question: going back to dired

[Sean Sieger]

Xah <xahlee@gmail.com> writes:

   Perhaps you are mocking me, but it already has info on
   OSX. :)

That wouldn't be Lennart's style; if you're thinking everyone's out
to get you, then they are.

   You and your strange emacs setup are incredible.

I appreciate Lennart's work everytime I have to start MS Windows.

   You DO realize that most emacs lovers here can't bear the mention of
   Microsoft Windows right? and you want emacs to conform to Window's UI
   standards. What a crime it is.

But what you want GNU Emacs to conform to is the `right, honest way?'

basic question: going back to dired

[Ben Aurel]

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

Re: basic question: going back to dired

[Bastien]

Ben Aurel <ben.aurel@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

Re: basic question: going back to dired

[Xah]

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:
> Ben Aurel <ben.au...@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

Re: basic question: going back to dired

[Bastien Guerry]

Xah <xahlee@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

Re: basic question: going back to dired

[Juanma Barranquero]

On Tue, Jul 22, 2008 at 10:26, Bastien Guerry <bzg@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

Re: basic question: going back to dired

[Bastien Guerry]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Tue, Jul 22, 2008 at 10:26, Bastien Guerry <bzg@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

Re: basic question: going back to dired

[Juanma Barranquero]

On Tue, Jul 22, 2008 at 18:53, Bastien Guerry <bzg@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

Re: basic question: going back to dired

[Bastien Guerry]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Tue, Jul 22, 2008 at 18:53, Bastien Guerry <bzg@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

Re: basic question: going back to dired

[Juanma Barranquero]

On Wed, Jul 23, 2008 at 01:32, Bastien Guerry <bzg@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

Re: basic question: going back to dired

[Bastien Guerry]

"Juanma Barranquero" <lekktu@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

Re: basic question: going back to dired

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> We're bound to stick with history. But it is nice (and perhaps even
> useful, in some way) to think what benefit would we gain by using a
> more common terminology. At least that will compel us to choose more
> adequate names for new features.

Indeed, but for the most part it seems that many people attempting this
(like xahlee) do not really understand the underlying concepts very
well, and simply pick the first "modern" term that they believe
resembles the emacs term.  The result, of course, is predictably a mess.

-Miles

-- 
Carefully crafted initial estimates reward you not only with
reduced computational effort, but also with understanding and
increased self-esteem.         -- Numerical methods in C,
  Chapter 9. "Root Finding and Nonlinear Sets of Equations"

Re: basic question: going back to dired

[Evans Winner]

"Juanma Barranquero" <lekktu@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.

Re: basic question: going back to dired

[Juanma Barranquero]

On Tue, Jul 22, 2008 at 18:13, Evans Winner <thorne@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

Re: basic question: going back to dired

[Tim X]

Evans Winner <thorne@timbral.net> writes:

> "Juanma Barranquero" <lekktu@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

Re: basic question: going back to dired

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> Looking up "buffer", the closest meaning I find is:
>
> "(computer science) a part of RAM used for temporary storage of data
> that is waiting to be sent to a device; used to compensate for
> differences in the rate of flow of data between components of a
> computer system"

Do not depend on dictionaries for definitions of CS terms, they
inevitably screw them up.

A buffer is sort of like a "holding area" for data.

Emacs' use of the term is quite in keeping with its general sense in CS.

-Miles

-- 
Americans are broad-minded people.  They'll accept the fact that a person can
be an alcoholic, a dope fiend, a wife beater, and even a newspaperman, but if
a man doesn't drive, there is something wrong with him.  -- Art Buchwald

Re: basic question: going back to dired

[Juanma Barranquero]

On Thu, Jul 24, 2008 at 09:39, Miles Bader <miles.bader@necel.com> wrote:

> Do not depend on dictionaries for definitions of CS terms, they
> inevitably screw them up.

I've quoted a dictionary, but I'm not depending on it; rather on my
own CS days back in the eighties. Obviously now it is a more generic
term.

  Juanma

Re: basic question: going back to dired

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> I've quoted a dictionary, but I'm not depending on it; rather on my
> own CS days back in the eighties. Obviously now it is a more generic
> term.

It certainly had this meaning in the 80's or earlier.  [Indeed, Emacs'
use of the term is evidence that it dates back even to the mid-70s or
earlier.]

-Miles

-- 
Infancy, n. The period of our lives when, according to Wordsworth, 'Heaven
lies about us.' The world begins lying about us pretty soon afterward.

Re: basic question: going back to dired

[Tim X]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Thu, Jul 24, 2008 at 09:39, Miles Bader <miles.bader@necel.com> wrote:
>
>> Do not depend on dictionaries for definitions of CS terms, they
>> inevitably screw them up.
>
> I've quoted a dictionary, but I'm not depending on it; rather on my
> own CS days back in the eighties. Obviously now it is a more generic
> term.
>

But don't forget its not just a comp sci term. In fact, comp sci
borrowed it from "normal" english. In my comp sci days, also in the 80s,
it still had the more generalised term that fits with how emacs uses
it. 

Tim


-- 
tcross (at) rapttech dot com dot au

Re: basic question: going back to dired

[Juanma Barranquero]

On Thu, Jul 24, 2008 at 14:36, Tim X <timx@nospam.dev.null> wrote:

> But don't forget its not just a comp sci term. In fact, comp sci
> borrowed it from "normal" english. In my comp sci days, also in the 80s,
> it still had the more generalised term that fits with how emacs uses
> it.

As would have lots of other terms. That's what I'm saying: "buffer"
seems like the perfect match for Emacs
data-structures-for-temporary-storage-under-whatever-name because
we've been using it that way for 25+ years, not because it is the
only, or more fitting, or more appropriate term.

This conversation (not specifically with you Tim, I'm talking about
the thread) goes nowhere. I said that I'm not proposing to change
anything, but at the same time I *don't* believe there's anything
sacred on the terms used in Emacs today. They are the best just
because of long use and long familiarity. Which does not necessarily
apply to newbies.

  Juanma

Re: basic question: going back to dired

[Tim X]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Thu, Jul 24, 2008 at 14:36, Tim X <timx@nospam.dev.null> wrote:
>
>> But don't forget its not just a comp sci term. In fact, comp sci
>> borrowed it from "normal" english. In my comp sci days, also in the 80s,
>> it still had the more generalised term that fits with how emacs uses
>> it.
>
> As would have lots of other terms. That's what I'm saying: "buffer"
> seems like the perfect match for Emacs
> data-structures-for-temporary-storage-under-whatever-name because
> we've been using it that way for 25+ years, not because it is the
> only, or more fitting, or more appropriate term.
>
> This conversation (not specifically with you Tim, I'm talking about
> the thread) goes nowhere. I said that I'm not proposing to change
> anything, but at the same time I *don't* believe there's anything
> sacred on the terms used in Emacs today. They are the best just
> because of long use and long familiarity. Which does not necessarily
> apply to newbies.
>

Which is not that far from my position. Most of my comments are related
to Xah and others who believe it should be changed. I'm not arguing it
shouldn't be changed because its sacred or anything. My point is that I
a) don't believe its as bad as some like Xah argue and b) nobody has
come up with any alternatives that don't lose us more than they gain and
c) I'm not convinced that changing all the terminology would actually
change the number of new users who give up and don't bother because I
don't believe the terminology is the main thing that makes new users
give up. 

Tim

-- 
tcross (at) rapttech dot com dot au

Re: basic question: going back to dired

[William Case]

Hi all;

2¢

On Sat, 2008-07-26 at 14:38 +1000, Tim X wrote:
> "Juanma Barranquero" <lekktu@gmail.com> writes:
> 
> > On Thu, Jul 24, 2008 at 14:36, Tim X <timx@nospam.dev.null> wrote:
> >
> >> But don't forget its not just a comp sci term. In fact, comp sci
> >> borrowed it from "normal" english. In my comp sci days, also in the 80s,
> >> it still had the more generalised term that fits with how emacs uses
> >> it.
> >
> > As would have lots of other terms. That's what I'm saying: "buffer"
> > seems like the perfect match for Emacs
> > data-structures-for-temporary-storage-under-whatever-name because
> > we've been using it that way for 25+ years, not because it is the
> > only, or more fitting, or more appropriate term.
> >
> > This conversation (not specifically with you Tim, I'm talking about
> > the thread) goes nowhere. I said that I'm not proposing to change
> > anything, but at the same time I *don't* believe there's anything
> > sacred on the terms used in Emacs today. They are the best just
> > because of long use and long familiarity. Which does not necessarily
> > apply to newbies.
> >
> 
> Which is not that far from my position. Most of my comments are related
> to Xah and others who believe it should be changed. I'm not arguing it
> shouldn't be changed because its sacred or anything. My point is that I
> a) don't believe its as bad as some like Xah argue and b) nobody has
> come up with any alternatives that don't lose us more than they gain and
> c) I'm not convinced that changing all the terminology would actually
> change the number of new users who give up and don't bother because I
> don't believe the terminology is the main thing that makes new users
> give up. 
> 
> Tim
> 

I have heard and read this and similar conversations on the Emacs user
list and several other applications mailing lists over the last 3 years.
>From my personal experience both sides of the argument are right.  

New users find the terminology, extremely confusing and off putting.  It
takes a considerable amount of time to build up the concepts and
vocabulary to begin to understand how Emacs works; how to find your way
around 'help info'; and how to understand basic elipse variables and
functions.  On the other hand, the terminology used by Emacs is more
specific and accurate so that once a user becomes experienced, it is
much easier to find an answer and/or describe a problem with specialized
terminology.

With open source software, both points of view can be accommodated.  I
believe that the point of FOSS is that applications can be amended and
augmented so that all perspectives can be included. There is no need for
"my way or the highway".

As a case in point, "shortcut keys" should be included in the glossary
and the various indexes.  They simply need to be linked to the info
section on "key binding".  The actual section on key binding merely
needs an introductory sentence or two explaining why the term "key
binding" is used in Emacs and why it is a better term for how Emacs
works than the more common term "shortcut key".  Similarly the section
on "buffers" could be linked to "page", "window" and "file" with a
forwarding link to the sections that deal with how these terms
themselves (page,window and file) are used in Emacs.

As I think about it, only about 10 -15 terms would need such synonyms.
For the purists, I would like them to cast their minds back to the first
time they used Emacs.  The concepts behind the various terms was never
too difficult to grasp, but surely you remember the hours wasted and
utter frustration that you must have had in the beginning just trying to
find a way into the program and trying to execute the simplest command
when NOTHING was familiar.

-- 
Regards Bill;
Fedora 9, Gnome 2.22.3
Evo.2.22.3.1, Emacs 22.2.1

Re: basic question: going back to dired

[Tim X]

William Case <billlinux@rogers.com> writes:

> Hi all;
>
> 2¢
>
> On Sat, 2008-07-26 at 14:38 +1000, Tim X wrote:
>> "Juanma Barranquero" <lekktu@gmail.com> writes:
>> 
>> > On Thu, Jul 24, 2008 at 14:36, Tim X <timx@nospam.dev.null> wrote:
>> >
>> >> But don't forget its not just a comp sci term. In fact, comp sci
>> >> borrowed it from "normal" english. In my comp sci days, also in the 80s,
>> >> it still had the more generalised term that fits with how emacs uses
>> >> it.
>> >
>> > As would have lots of other terms. That's what I'm saying: "buffer"
>> > seems like the perfect match for Emacs
>> > data-structures-for-temporary-storage-under-whatever-name because
>> > we've been using it that way for 25+ years, not because it is the
>> > only, or more fitting, or more appropriate term.
>> >
>> > This conversation (not specifically with you Tim, I'm talking about
>> > the thread) goes nowhere. I said that I'm not proposing to change
>> > anything, but at the same time I *don't* believe there's anything
>> > sacred on the terms used in Emacs today. They are the best just
>> > because of long use and long familiarity. Which does not necessarily
>> > apply to newbies.
>> >
>> 
>> Which is not that far from my position. Most of my comments are related
>> to Xah and others who believe it should be changed. I'm not arguing it
>> shouldn't be changed because its sacred or anything. My point is that I
>> a) don't believe its as bad as some like Xah argue and b) nobody has
>> come up with any alternatives that don't lose us more than they gain and
>> c) I'm not convinced that changing all the terminology would actually
>> change the number of new users who give up and don't bother because I
>> don't believe the terminology is the main thing that makes new users
>> give up. 
>> 
>> Tim
>> 
>
> I have heard and read this and similar conversations on the Emacs user
> list and several other applications mailing lists over the last 3 years.
>>From my personal experience both sides of the argument are right.  
>
> New users find the terminology, extremely confusing and off putting.  It
> takes a considerable amount of time to build up the concepts and
> vocabulary to begin to understand how Emacs works; how to find your way
> around 'help info'; and how to understand basic elipse variables and
> functions.  On the other hand, the terminology used by Emacs is more
> specific and accurate so that once a user becomes experienced, it is
> much easier to find an answer and/or describe a problem with specialized
> terminology.
>
> With open source software, both points of view can be accommodated.  I
> believe that the point of FOSS is that applications can be amended and
> augmented so that all perspectives can be included. There is no need for
> "my way or the highway".
>
> As a case in point, "shortcut keys" should be included in the glossary
> and the various indexes.  They simply need to be linked to the info
> section on "key binding".  The actual section on key binding merely
> needs an introductory sentence or two explaining why the term "key
> binding" is used in Emacs and why it is a better term for how Emacs
> works than the more common term "shortcut key".  Similarly the section
> on "buffers" could be linked to "page", "window" and "file" with a
> forwarding link to the sections that deal with how these terms
> themselves (page,window and file) are used in Emacs.
>
> As I think about it, only about 10 -15 terms would need such synonyms.
> For the purists, I would like them to cast their minds back to the first
> time they used Emacs.  The concepts behind the various terms was never
> too difficult to grasp, but surely you remember the hours wasted and
> utter frustration that you must have had in the beginning just trying to
> find a way into the program and trying to execute the simplest command
> when NOTHING was familiar.

Actually, I didn't find it an issue at all. In fact, it was the very
first program I learnt after losing my sight over 10 years ago - before
that, I was a VI user. I switched to emacs because of the wonderful
emacspeak package. I'm also no genius and don't have any special ability
or great skill. However, I do have a process that has always served me
well with anything new, whether it be a new dvd player, television,
microwave or computer. The first thing I do is read the documentation
and if there is a tutorial, I run through it. This is what I did with
emacs and I found it to have the best and clearest tutorial and manual
of any software Ive ever used that has been put together prety much by
volunteers.

I have no issue with anything you have suggested, apart from the fact it
is largely done. If you look at the current emacs manual (CVS emacs -
not sure about older manuals), you will find it already has most, if not
all, your suggestions. Furthermore, many of the emacs maintainers have
frequently asked for contributions or for users to identify parts of the
manual they found confusing or lacking in some way. Despite all the
people who like to criticise emacs' terms, few seem to be prepared to
actually address whatever problems they see by contributing to the
documentation. This is probably my main issue (if I actually had one,
but I don't really). 

For example, a quick I search of the glossary for some of the terms
being mentioned in this thread came up with the following -

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

Buffer
     The buffer is the basic editing unit; one buffer corresponds to
     one text being edited.  You can have several buffers, but at any
     time you are editing only one, the `current buffer,' though
     several can be visible when you are using multiple windows (q.v.).
     Most buffers are visiting (q.v.) some file.  *Note Buffers::.

Frame
     A frame is a rectangular cluster of Emacs windows.  Emacs starts
     out with one frame, but you can create more.  You can subdivide
     each frame into Emacs windows (q.v.).  When you are using a window
     system (q.v.), all the frames can be visible at the same time.
     *Note Frames::.  Some other editors use the term "window" for this,
     but in Emacs a window means something else.

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.

Face
     A face is a style of displaying characters.  It specifies
     attributes such as font family and size, foreground and background
     colors, underline and strike-through, background stipple, etc.
     Emacs provides features to associate specific faces with portions
     of buffer text, in order to display that text as specified by the
     face attributes.  *Note Faces::.

Syntax Highlighting
     See `font lock.'

Font Lock
     Font Lock is a mode that highlights parts of buffer text according
     to its syntax.  *Note Font Lock::.

Line Wrapping
     See `filling.'

If anyone knows of terms they have encountered that are not obvious and
are not in the glossary, then write up the definition and submit it for
inclusion in the manual. 

Tim


-- 
tcross (at) rapttech dot com dot au

Re: basic question: going back to dired

[Phil Carmody]

Xah <xahlee@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

Re: basic question: going back to dired

[Juanma Barranquero]

On Tue, Jul 22, 2008 at 11:46, Phil Carmody
<thefatphil_demunged@yahoo.co.uk> wrote:
> Xah <xahlee@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

Re: basic question: going back to dired

[Juanma Barranquero]

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

Re: basic question: going back to dired

[Dan Davison]

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

Re: basic question: going back to dired

[Juanma Barranquero]

On Tue, Jul 22, 2008 at 15:56, Dan Davison <davison@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

Re: basic question: going back to dired

[Juanma Barranquero]

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.

> ¹ you *have* to learn Emacs if you want to use it.

Agreed. But an Emacs newbie already has a lot to learn; terminology in
the docs (of Emacs or any other software) can help, or hinder.

> it's not
> "more like": it's literal translation.

I've been a translator long enough to know that there are always many
ways to translate even the simplest thing...

> I didn't wonder if you'd get the
> meaning; I wondered if the rest of readers would. That might mean I need to
> "get out" of my own self a little more.

No need to take it seriously, I was tongue-in-cheek.

> You may be right here, because partially the point is that some of us find
> the change proposal pointless and poorly justified.

I find the change proposal poorly justified, too. As for pointless, I
don't really know.

> Interface consistency is a plus, but not the only factor.

Of course.

> There is a
> trade-off, which is why we have such discussions. I don't find the whole
> discussion senseless, but I am definitely against this proposal.

We're in violent agreement here.

> That makes no sense, because those chords are not good, no matter how many
> people use them.

Well, although I wouldn't support changing the Emacs keybindings
wholesale in a million years, Xah Lee has a point about them not being
particularly good. Do you really think that C-x C-c is good and Alt-F4
is bad?

> After all, Emacs is all about improving, because you can customize it so
> heavily. If you like CUA, you can get it.

I do use CUA mode, though not for C-x etc. Selection with shift-keys
and visible region are very big pluses against the Emacs defaults,
IMHO.

> That is what makes Emacs, not an
> old piece, but a classic. Hence, it doesn't need to be modernized. It's good.

Thanks God (or the FSM) that's not true, or there would be no new features...

> You win (lexicographically) :-)

A win is a win is a win. :-)

  Juanma

Re: basic question: going back to dired

[Bastien Guerry]

"Juanma Barranquero" <lekktu@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

Re: basic question: going back to dired

[Juanma]

On Tuesday 22 July 2008, Juanma Barranquero wrote:

> I do use CUA mode, though not for C-x etc. Selection with shift-keys
> and visible region are very big pluses against the Emacs defaults,
> IMHO.

Visible region is a really big plus, but I guess you mean
transient-mark-mode and I believe that's not part of CUA.

On the other hand, selection with shift+arrows seems to me like the crappy
stuff I used to do before entering the glory of Emacs. I would go to admit
it's a small plus to be able to *also* do it like that, but I think setting
the mark, as an anchor, and extend as you move with any other movement
command (and that includes, e.g., i-search), is vastly superior.

> > That is what makes Emacs, not an old piece, but a classic. Hence, it
> > doesn't need to be modernized. It's good.
> 
> Thanks God (or the FSM) that's not true, or there would be no new features...

Well, if new features means modernization, then you are right. It might be a
pretty bad choice of words, or binding of concepts, on my side.
-- 
Juanma

"Having a smoking section in a restaurant is like
 having a peeing section in a swimming pool."
       -- Edward Burr

Re: basic question: going back to dired

[Juanma Barranquero]

On Thu, Jul 24, 2008 at 03:38, Juanma <juanma_bellon@yahoo.es> wrote:

> Visible region is a really big plus, but I guess you mean
> transient-mark-mode and I believe that's not part of CUA.

CUA mode also makes the region visible.

> On the other hand, selection with shift+arrows seems to me like the crappy
> stuff I used to do before entering the glory of Emacs. I would go to admit
> it's a small plus to be able to *also* do it like that, but I think setting
> the mark, as an anchor, and extend as you move with any other movement
> command (and that includes, e.g., i-search), is vastly superior.

We'll have to agree to disagree. I have almost no use for invisible
regions that extend with movement commands.

  Juanma

Re: basic question: going back to dired

[Nikolaj Schumacher]

"Juanma Barranquero" <lekktu@gmail.com> wrote:

> On Thu, Jul 24, 2008 at 03:38, Juanma <juanma_bellon@yahoo.es> wrote:
>
>> On the other hand, selection with shift+arrows seems to me like the crappy
>> stuff I used to do before entering the glory of Emacs. I would go to admit
>> it's a small plus to be able to *also* do it like that, but I think setting
>> the mark, as an anchor, and extend as you move with any other movement
>> command (and that includes, e.g., i-search), is vastly superior.
>
> We'll have to agree to disagree. I have almost no use for invisible
> regions that extend with movement commands.

Except for the default on the visible part, there's actually little
difference between the two methods.  i-search seems to work in cua-mode,
as well.  The only difference is, really, that you either hold shift all
the way through, or hit a key once.  I feel the second method is more
comfortable for a touch-typist, but I don't think CUA users are missing
anything here.

regards,
Nikolaj Schumacher

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Nikolaj Schumacher wrote:
> "Juanma Barranquero" <lekktu@gmail.com> wrote:
> 
>> On Thu, Jul 24, 2008 at 03:38, Juanma <juanma_bellon@yahoo.es> wrote:
>>
>>> On the other hand, selection with shift+arrows seems to me like the crappy
>>> stuff I used to do before entering the glory of Emacs. I would go to admit
>>> it's a small plus to be able to *also* do it like that, but I think setting
>>> the mark, as an anchor, and extend as you move with any other movement
>>> command (and that includes, e.g., i-search), is vastly superior.
>> We'll have to agree to disagree. I have almost no use for invisible
>> regions that extend with movement commands.
> 
> Except for the default on the visible part, there's actually little
> difference between the two methods.  i-search seems to work in cua-mode,
> as well.  The only difference is, really, that you either hold shift all
> the way through, or hit a key once.  I feel the second method is more
> comfortable for a touch-typist, but I don't think CUA users are missing
> anything here.


Both methods are available when you use cua-mode.

Re: basic question: going back to dired

[Juanma]

On Thursday 24 July 2008, Juanma Barranquero wrote:
> On Thu, Jul 24, 2008 at 03:38, Juanma <juanma_bellon@yahoo.es> wrote:
> 
> > On the other hand, selection with shift+arrows seems to me like the crappy
> > stuff I used to do before entering the glory of Emacs. I would go to admit
> > it's a small plus to be able to *also* do it like that, but I think setting
> > the mark, as an anchor, and extend as you move with any other movement
> > command (and that includes, e.g., i-search), is vastly superior.
> 
> We'll have to agree to disagree. I have almost no use for invisible
> regions that extend with movement commands.

But they aren't invisible! Nowadays, not even by default.

(setq transient-mark-mode¹ t)

¹ this is independent from CUA, whatever are the capabilities of that
package.

Extending the region without the need to keep Shift pressed is awesome. You
really have to try it. There's no coming back from that. Guaranteed.
-- 
Juanma

"Having a smoking section in a restaurant is like
 having a peeing section in a swimming pool."
       -- Edward Burr

Re: basic question: going back to dired

[Juanma Barranquero]

On Thu, Jul 24, 2008 at 23:43, Juanma <juanma_bellon@yahoo.es> wrote:

> But they aren't invisible! Nowadays, not even by default.
>
> (setq transient-mark-mode¹ t)

I had transient-mark-mode set to t for a while, and then I switched to
using CUA mode

> ¹ this is independent from CUA, whatever are the capabilities of that
> package.

Not quite. I have cua-highlight-region-shift-only set to t.

> Extending the region without the need to keep Shift pressed is awesome. You
> really have to try it. There's no coming back from that. Guaranteed.

Why do you assume I haven't tried it?

  Juanma

Re: basic question: going back to dired

[Juanma]

On Thursday 24 July 2008, Juanma Barranquero wrote:
> > Extending the region without the need to keep Shift pressed is awesome. You
> > really have to try it. There's no coming back from that. Guaranteed.
> 
> Why do you assume I haven't tried it?

Two reasons:

1) You said: "I have almost no use for invisible regions that extend with
movement commands". It sounded just as if you hadn't tried transient mark
mode.

2) A gut feeling, that if you had used the set-mark method and extend the
region with search or browse commands, you wouldn't want to use "the other"
method (shift+arrows). But I see it's possible that some people actually
prefer that.
-- 
Juanma

"Having a smoking section in a restaurant is like
 having a peeing section in a swimming pool."
       -- Edward Burr

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Juanma wrote:
> 2) A gut feeling, that if you had used the set-mark method and extend the
> region with search or browse commands, you wouldn't want to use "the other"
> method (shift+arrows). But I see it's possible that some people actually
> prefer that.

My gut feeling tells me you did not look into the possibility that one 
can use both ... ;-)

Re: basic question: going back to dired

[Juanma]

On Friday 25 July 2008, Lennart Borgman (gmail) wrote:
> Juanma wrote:
> > 2) A gut feeling, that if you had used the set-mark method and extend the
> > region with search or browse commands, you wouldn't want to use "the other"
> > method (shift+arrows). But I see it's possible that some people actually
> > prefer that.
> 
> My gut feeling tells me you did not look into the possibility that one 
> can use both ... ;-)

Actually I did, but the way (the other) Juanma said it¹ made me think he was
simply unaware of transient-mark-mode. I know it would be odd, but there are
many odd things going on in this discussion. And, of course, oddity is
subjective.

¹ "I do use CUA mode, though not for C-x etc. Selection with shift-keys and
visible region are very big pluses against the Emacs defaults, IMHO."

One of the odd things was that about opening a file in Emacs being
difficult. I wonder why is that. Specially now that, in addition to aaaaall
the rest, you can drag'n'drop from a bunch of window managers into Emacs.
-- 
Juanma

"Having a smoking section in a restaurant is like
 having a peeing section in a swimming pool."
       -- Edward Burr

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Juanma wrote:
> One of the odd things was that about opening a file in Emacs being
> difficult. I wonder why is that. Specially now that, in addition to aaaaall
> the rest, you can drag'n'drop from a bunch of window managers into Emacs.

The difficulties are in the details. You kind of use your body memory 
when doing such things. On Windows the menus does not work from the 
keyboard as in other programs by default and that defeats the body memory.

Re: basic question: going back to dired

[Juanma]

On Friday 25 July 2008, Lennart Borgman (gmail) wrote:
> The difficulties are in the details. You kind of use your body memory 
> when doing such things. On Windows the menus does not work from the 
> keyboard as in other programs by default and that defeats the body memory.

Menus? What menus?

If you hate C-x C-f you can rebind it (C-o in CUA, right?), you can use the
"disk key" as provided by disk.el, you have dired, or you get Windows
Explorer calling ... what was that? gnuclientw.exe? I think that's what I
used. I just browsed folders with Windows Explorer and pressed Enter on a
file, or 2*clicked it, or drag'n'dropped it into Emacs.

In Emacs, and this is just an opinion, activating menus from keyboard is a
corner-case, not a normal (as in "frequently performed") procedure. But, if
that's your procedure, fine. But then, I don't think it's Emacs making it
difficult ...
-- 
Juanma

"Having a smoking section in a restaurant is like
 having a peeing section in a swimming pool."
       -- Edward Burr

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Juanma wrote:
> On Friday 25 July 2008, Lennart Borgman (gmail) wrote:
>> The difficulties are in the details. You kind of use your body memory 
>> when doing such things. On Windows the menus does not work from the 
>> keyboard as in other programs by default and that defeats the body memory.
> 
> Menus? What menus?
> 
> If you hate C-x C-f you can rebind it (C-o in CUA, right?), you can use the
> "disk key" as provided by disk.el, you have dired, or you get Windows
> Explorer calling ... what was that? gnuclientw.exe? I think that's what I
> used. I just browsed folders with Windows Explorer and pressed Enter on a
> file, or 2*clicked it, or drag'n'dropped it into Emacs.
> 
> In Emacs, and this is just an opinion, activating menus from keyboard is a
> corner-case, not a normal (as in "frequently performed") procedure. But, if
> that's your procedure, fine. But then, I don't think it's Emacs making it
> difficult ...

And what does this help if the new user presses Alt-F to open the file menu?

Re: basic question: going back to dired

[Tim X]

Juanma <juanma_bellon@yahoo.es> writes:

> On Tuesday 22 July 2008, Juanma Barranquero wrote:
>
>> I do use CUA mode, though not for C-x etc. Selection with shift-keys
>> and visible region are very big pluses against the Emacs defaults,
>> IMHO.
>
> Visible region is a really big plus, but I guess you mean
> transient-mark-mode and I believe that's not part of CUA.
>
> On the other hand, selection with shift+arrows seems to me like the crappy
> stuff I used to do before entering the glory of Emacs. I would go to admit
> it's a small plus to be able to *also* do it like that, but I think setting
> the mark, as an anchor, and extend as you move with any other movement
> command (and that includes, e.g., i-search), is vastly superior.

I have to agree here. I rarely use the mouse (in fact, my mouse is the
oldest bit of equipment connected to my system - it has no scroll whell
and I purchased it in about 1995!

for me, setting the mark and then using the other features, like
i-search or just next line to move to the end of whatever it is I want
to select is faster and easier than either the mouse or holding down
shift and moving my hands off the main keys to the arrow keys. 

This raises the other point I haven't touched on (and won't now - not in
any depth). I'll only say that many of the so-called modernisation
features Xah and ohters have mentioned are often poor replacements for a
far superior mode that pre-dates the more popular method - its like VHS
versus Beta - just because its more popular and possibly better known,
it doesn't mean that its actually a better solution. 

Tim

-- 
tcross (at) rapttech dot com dot au

Re: basic question: going back to dired

[Juanma Barranquero]

On Thu, Jul 24, 2008 at 14:30, Tim X <timx@nospam.dev.null> wrote:

> I have to agree here. I rarely use the mouse

I'm not sure how one thing is related to the other. I use the keyboard
much more than the mouse, and always for selection. Still I prefer the
shift keys and a visible region to other ways to do it.

> I'll only say that many of the so-called modernisation
> features Xah and ohters have mentioned are often poor replacements for a
> far superior mode that pre-dates the more popular method

Yes. Often. At other times, it is only the old fashioned way to do it.
If transient-mark-mode is now t by default, for example, it's hard to
believe that the alternative is a "far superior mode". Let's call them
two different, equally valid worldviews.

> - its like VHS
> versus Beta - just because its more popular and possibly better known,
> it doesn't mean that its actually a better solution.

http://en.wikipedia.org/wiki/Videotape_format_war

It's not evident that Beta was superior, and it's not evident either
why one format won over the other(s). There were multiple factors at
play. Still, if Emacs turned to be the Beta of programmer editors,
technical excellence would be small consolation.

  Juanma

Re: basic question: going back to dired

[Tim X]

"Juanma Barranquero" <lekktu@gmail.com> writes:

>
> http://en.wikipedia.org/wiki/Videotape_format_war
>
> It's not evident that Beta was superior, and it's not evident either
> why one format won over the other(s). There were multiple factors at
> play. Still, if Emacs turned to be the Beta of programmer editors,
> technical excellence would be small consolation.
>

I disagree. If you had anything to do with professional recording and or
broadcasting, you would have found that BETA was by far the preferred
choice. In fact, up until digital really took over, nearly every
broadcasting and recording studio I worked in used BETA. 

Technical excellence and how relevant it is depends on the user
base. For me and the work I do, it is critical and I will select
technical excellence over popularity any day.

Tim


-- 
tcross (at) rapttech dot com dot au

Re: basic question: going back to dired

[Sean Sieger]

Tim X <timx@nospam.dev.null> writes:

   I disagree. If you had anything to do with professional recording and or
   broadcasting, you would have found that BETA was by far the preferred
   choice. In fact, up until digital really took over, nearly every
   broadcasting and recording studio I worked in used BETA. 

Uh-huh, and then Digital BETA, here in NYC at a national broadcast
house.

Re: basic question: going back to dired

[Juanma Barranquero]

On Sat, Jul 26, 2008 at 04:23, Tim X <timx@nospam.dev.null> wrote:

> If you had anything to do with professional recording and or
> broadcasting, you would have found that BETA was by far the preferred
> choice.

I don't doubt that, but there could be multiple causes, among them the
fact that Beta had initially better image quality (and once you build
momentum in some industry, conservation law applies ;-)

But at some point, Beta players were not better than VHS players, at
least at the home use level. And "technically better" is not only
measured by image quality; it's been stated many times that the users
preferred longer recording time (which is, after all, another
technical parameter).

  Juanma

Re: basic question: going back to dired

[Phil Carmody]

"Juanma Barranquero" <lekktu@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'.

Phil
-- 
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration

Re: basic question: going back to dired

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> Well, although I wouldn't support changing the Emacs keybindings
> wholesale in a million years, Xah Lee has a point about them not being
> particularly good. Do you really think that C-x C-c is good and Alt-F4
> is bad?

"C-x" in general is a prefix for "major" commands, and "C-c" was
historically used to kill a program (you could question the significance
of "C-c" itself, but it was used so universally, its meaning was quite
firmly established).

Thus "C-x C-c" is a fairly logical binding, if you ask me.

[If you ask xahlee of course, he'll rant at you for a month about
timecubes.]

Now, the logic behind "Alt-F4" is, ... what, exactly?

-Miles

-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: basic question: going back to dired

[Juanma Barranquero]

On Thu, Jul 24, 2008 at 09:19, Miles Bader <miles.bader@necel.com> wrote:

> "C-x" in general is a prefix for "major" commands, and "C-c" was
> historically used to kill a program (you could question the significance
> of "C-c" itself, but it was used so universally, its meaning was quite
> firmly established).
>
> Thus "C-x C-c" is a fairly logical binding, if you ask me.

Well, C-c to me has the meaning of "killing a program", yes, which,
Emacs terminology notwithstanding, is not the same as exiting a
program (yes, I know that many programs do orderly exits after a C-c,
but to my Windows-tainted eyes, C-c is using violence against the
unsuspecting process).

> Now, the logic behind "Alt-F4" is, ... what, exactly?

It is as arbitrary as C-c to killing a program, or C-x for major
commands. And it is (in a Windows context) obviously related to Alt-F4
to close a document.

  Juanma

Re: basic question: going back to dired

[Nikolaj Schumacher]

"Juanma Barranquero" <lekktu@gmail.com> wrote:

> On Thu, Jul 24, 2008 at 09:19, Miles Bader <miles.bader@necel.com> wrote:
>
>> "C-x" in general is a prefix for "major" commands, and "C-c" was
>> historically used to kill a program (you could question the significance
>> of "C-c" itself, but it was used so universally, its meaning was quite
>> firmly established).
>>
>> Thus "C-x C-c" is a fairly logical binding, if you ask me.
>
> Well, C-c to me has the meaning of "killing a program", yes, which,
> Emacs terminology notwithstanding, is not the same as exiting a
> program (yes, I know that many programs do orderly exits after a C-c,
> but to my Windows-tainted eyes, C-c is using violence against the
> unsuspecting process).
>
>> Now, the logic behind "Alt-F4" is, ... what, exactly?
>
> It is as arbitrary as C-c to killing a program, or C-x for major
> commands. And it is (in a Windows context) obviously related to Alt-F4
> to close a document.

Actually Alt-F4 closes a window (frame), which I believe is bound to
C-x 5 0 in Emacs.  Both are about as arbitrary as shortcuts can get.
Can we move on now?


regards,
Nikolaj Schumacher

Re: basic question: going back to dired

[Tim X]

Miles Bader <miles.bader@necel.com> writes:

> "Juanma Barranquero" <lekktu@gmail.com> writes:
>> Well, although I wouldn't support changing the Emacs keybindings
>> wholesale in a million years, Xah Lee has a point about them not being
>> particularly good. Do you really think that C-x C-c is good and Alt-F4
>> is bad?
>
> "C-x" in general is a prefix for "major" commands, and "C-c" was
> historically used to kill a program (you could question the significance
> of "C-c" itself, but it was used so universally, its meaning was quite
> firmly established).
>
> Thus "C-x C-c" is a fairly logical binding, if you ask me.
>
> [If you ask xahlee of course, he'll rant at you for a month about
> timecubes.]
>
> Now, the logic behind "Alt-F4" is, ... what, exactly?
>
Exactly and in fact, more effort and less convenient to move your hands
of the "home keys" to get to F4.

Tim


-- 
tcross (at) rapttech dot com dot au

Re: basic question: going back to dired

[Juanma Barranquero]

On Thu, Jul 24, 2008 at 14:32, Tim X <timx@nospam.dev.null> wrote:

> Exactly and in fact, more effort and less convenient to move your hands
> of the "home keys" to get to F4.

I find much easier to type Alt-F4 than C-x C-c.

  Juanma

Re: basic question: going back to dired

[xraysmalevich]

On Jul 24, 10:31 am, "Juanma Barranquero" <lek...@gmail.com> wrote:
> On Thu, Jul 24, 2008 at 14:32, Tim X <t...@nospam.dev.null> wrote:
> > Exactly and in fact, more effort and less convenient to move your hands
> > of the "home keys" to get to F4.
>
> I find much easier to type Alt-F4 than C-x C-c.
>
>   Juanma

The problem there, is that Alt-F4 is Windows only, and Emacs is not a
windows-only program. There is no Alt-F4 on the Mac, or on the OLPC XO
(it's reserved by the OS for something else). But in Emacs, on all of
them, there is C-x C-c.

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

xraysmalevich@gmail.com wrote:
> On Jul 24, 10:31 am, "Juanma Barranquero" <lek...@gmail.com> wrote:
>> On Thu, Jul 24, 2008 at 14:32, Tim X <t...@nospam.dev.null> wrote:
>>> Exactly and in fact, more effort and less convenient to move your hands
>>> of the "home keys" to get to F4.
>> I find much easier to type Alt-F4 than C-x C-c.
>>
>>   Juanma
> 
> The problem there, is that Alt-F4 is Windows only, and Emacs is not a
> windows-only program. There is no Alt-F4 on the Mac, or on the OLPC XO
> (it's reserved by the OS for something else). But in Emacs, on all of
> them, there is C-x C-c.

That of course might make Alt-F4 much harder to type on those other 
system, but it does not prevent that on Windows some people find it 
easier to type ;-)

Re: basic question: going back to dired

[Juanma Barranquero]

On Thu, Jul 24, 2008 at 17:19,  <xraysmalevich@gmail.com> wrote:

> The problem there, is that Alt-F4 is Windows only, and Emacs is not a
> windows-only program. There is no Alt-F4 on the Mac, or on the OLPC XO
> (it's reserved by the OS for something else). But in Emacs, on all of
> them, there is C-x C-c.

Yes. And the point is? I don't think anyone is proposing to switch to Alt-F4...

  Juanma

Re: basic question: going back to dired

[Eli Zaretskii]

> From: xraysmalevich@gmail.com
> Date: Thu, 24 Jul 2008 08:19:14 -0700 (PDT)
> 
> On Jul 24, 10:31 am, "Juanma Barranquero" <lek...@gmail.com> wrote:
> > On Thu, Jul 24, 2008 at 14:32, Tim X <t...@nospam.dev.null> wrote:
> > > Exactly and in fact, more effort and less convenient to move your hands
> > > of the "home keys" to get to F4.
> >
> > I find much easier to type Alt-F4 than C-x C-c.
> >
> >   Juanma
> 
> The problem there, is that Alt-F4 is Windows only

Actually, Alt-F4 is a widely used "close current window" operation on
many windowing environments.  Maybe not on the Mac, but it surely
isn't confined to MS-Windows alone.

Re: basic question: going back to dired

[Tim X]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Thu, Jul 24, 2008 at 14:32, Tim X <timx@nospam.dev.null> wrote:
>
>> Exactly and in fact, more effort and less convenient to move your hands
>> of the "home keys" to get to F4.
>
> I find much easier to type Alt-F4 than C-x C-c.
>

Are you a touch typist? I find C-x C-c really easy. I just hold down the
control with my right pinky and then just c and then x with the second
and third fingers of my left hand. What I like is my hands are pretty
much still on the home keys row. With any of the function keys, I have
to move my hand up to them, moving away from the home keys. 

I use a standard qwerty keyboard. For anyone using divorak or some other
keyborad layout, milage may vary. However, in general, I think moving
away from the home row/keys usually reduces speed and is less
convenient. (likewise, I use to like the VI movement keys because I
could easily move around the buffer without having to move off the main
keyborad. I use to find the need to hit ESC to change modes a bit
annoying for the same reasons. 

Tim


-- 
tcross (at) rapttech dot com dot au

Re: basic question: going back to dired

[Juanma Barranquero]

On Sat, Jul 26, 2008 at 06:33, Tim X <timx@nospam.dev.null> wrote:

> Are you a touch typist?

Yes.

> I find C-x C-c really easy.

I don't find any control key combo "easy". Perhaps I would find them a
bit easier if I did the usual Caps Lock / Ctrl switch, but I suspect
it wouldn't be much of a difference.

> However, in general, I think moving
> away from the home row/keys usually reduces speed and is less
> convenient.

While programming or doing other everyday computer tasks, I don't find
typing speed a significant parameter. It doesn't worry me the least
bit to spend a few fractions of a second moving my fingers out the
center row.

  Juanma

Re: basic question: going back to dired

[Juan Manuel Menéndez Bellón]

--- El jue, 31/7/08, Juanma Barranquero <lekktu@gmail.com> escribió:

> > I find C-x C-c really easy.
> 
> I don't find any control key combo "easy".
> Perhaps I would find them a bit easier if I did the usual Caps Lock /
> Ctrl switch, but I suspect it wouldn't be much of a difference.

Of course, I'm not sure how it will feel for you, but I find it to be a
very big difference. That switch moves the Ctrl key from a position that
is unreachable with normal typing position and a fairly normal keyboard,
to a position in the home row. You pass from needing to shift your whole
arm to needing a minor pinky shift.

I use Control more often than Caps Lock (by orders of magnitude, I'm
sure), so I rather have the former in the home row.

Best regards,
-- 
Juanma

"Having a smoking section in a restaurant is like
having a peeing section in a swimming pool."
      -- Edward Burr



      ______________________________________________ 
Enviado desde Correo Yahoo! La bandeja de entrada más inteligente.

Re: basic question: going back to dired

[Tim X]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Sat, Jul 26, 2008 at 06:33, Tim X <timx@nospam.dev.null> wrote:
>
>> Are you a touch typist?
>
> Yes.
>
>> I find C-x C-c really easy.
>
> I don't find any control key combo "easy". Perhaps I would find them a
> bit easier if I did the usual Caps Lock / Ctrl switch, but I suspect
> it wouldn't be much of a difference.
>

Probably not. I find control sequences no more difficult than shift
sequences. (actually, I would like to move the shift lock away from the
shift key as I do sometimes accidentaly hit shift lock). 

I guess it can depend on the size of your hands and the type of keyboard
you have. I do find some keyboards more difficult to use than others,
but not so much due to the layout as the size of the keys, the pressure
and 'feel' of the keys, the incline level etc. Over many years, I've
also found the chair and table height are critical. I've also noticed
that people who seem to have problems with ctl, shift etc also tend to
hold their hands/fingers in a fairly flat way. I use to play a lot of
piano in my youth and my teacher taught me that you should hold your
hands/fingers on the keyboard as if you had an orange under the palm of
the hand. In this shape, the tips of your fingers hit the keys rather
than the flatter pad part of the finger. 

>> However, in general, I think moving
>> away from the home row/keys usually reduces speed and is less
>> convenient.
>
> While programming or doing other everyday computer tasks, I don't find
> typing speed a significant parameter. It doesn't worry me the least
> bit to spend a few fractions of a second moving my fingers out the
> center row.
>

Well, I guess everyone's milage can differ, which is what makes it hard
to reach agreement in debates like this. I work as a programmer, but I
would say nearly half my time is spent writing text as opposed to code
(design docs, project submissions, instruction manuals etc). I agree
that when coding, typing speed isn't as critical.

Tim 

-- 
tcross (at) rapttech dot com dot au

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Tim X wrote:
> (actually, I would like to move the shift lock away from the
> shift key as I do sometimes accidentaly hit shift lock). 


In Emacs I do that. I have very little use for Caps Lock in Emacs, 
especially since I use Viper (where it can be very disturbing).

I use Caps Lock for M-x.

Re: basic question: going back to dired

[Thierry Volpiatto]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Tim X wrote:
>> (actually, I would like to move the shift lock away from the
>> shift key as I do sometimes accidentaly hit shift lock). 
>
>
> In Emacs I do that. I have very little use for Caps Lock in Emacs,
> especially since I use Viper (where it can be very disturbing).
>
> I use Caps Lock for M-x.
Hi Lennart and all!
So what is your entry in xmodmaprc for (keycode 66?) to map M-x ?


-- 
A + Thierry Volpiatto
Location: Saint-Cyr-Sur-Mer - France

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Thierry Volpiatto wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> Tim X wrote:
>>> (actually, I would like to move the shift lock away from the
>>> shift key as I do sometimes accidentaly hit shift lock). 
>>
>> In Emacs I do that. I have very little use for Caps Lock in Emacs,
>> especially since I use Viper (where it can be very disturbing).
>>
>> I use Caps Lock for M-x.
 >
> Hi Lennart and all!
> So what is your entry in xmodmaprc for (keycode 66?) to map M-x ?

I would be glad to help you, but I am using Emacs on MS Windows.

Re: basic question: going back to dired

[Thierry Volpiatto]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Thierry Volpiatto wrote:
>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>
>>> Tim X wrote:
>>>> (actually, I would like to move the shift lock away from the
>>>> shift key as I do sometimes accidentaly hit shift lock). 
>>>
>>> In Emacs I do that. I have very little use for Caps Lock in Emacs,
>>> especially since I use Viper (where it can be very disturbing).
>>>
>>> I use Caps Lock for M-x.
>>
>> Hi Lennart and all!
>> So what is your entry in xmodmaprc for (keycode 66?) to map M-x ?
>
> I would be glad to help you, but I am using Emacs on MS Windows.
>
Oh! yes i forget that, it's was just by curiosity, my Caps Lock is
Control here on Gentoo.
Thank you anyway!
-- 
A + Thierry Volpiatto
Location: Saint-Cyr-Sur-Mer - France

Re: basic question: going back to dired

[Sacha Chua]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

Hello, all!

>> I use Caps Lock for M-x.
> Hi Lennart and all!
> So what is your entry in xmodmaprc for (keycode 66?) to map M-x ?

Hmm, excellent idea. Here's my xmodmaprc:

clear Lock
keycode 66 = F13

and relevant .emacs bit:

(global-set-key [f13] 'execute-extended-command)

Sacha
-- 
Sacha Chua
Working on the Wicked Cool Emacs book
http://sachachua.com

Re: basic question: going back to dired

[Thierry Volpiatto]

Sacha Chua <sacha@sachachua.nospam.example.com> writes:

> Spam detection software, running on the system "tux.homenetwork", has
> identified this incoming email as possible spam.  The original message
> has been attached to this so you can view it (if it isn't spam) or label
> similar future email.  If you have any questions, see
> the administrator of that system for details.
>
> Content preview:  Thierry Volpiatto <thierry.volpiatto@gmail.com> writes: Hello,
>    all! >> I use Caps Lock for M-x. > Hi Lennart and all! > So what is your
>   entry in xmodmaprc for (keycode 66?) to map M-x ? [...] 
>
> Content analysis details:   (4.3 points, 3.5 required)
>
>  pts rule name              description
> ---- ---------------------- --------------------------------------------------
>  1.4 DATE_IN_PAST_03_06     Date: is 3 to 6 hours before Received: date
>  2.9 RCVD_IN_XBL            RBL: Received via a relay in Spamhaus XBL
>                             [199.232.76.165 listed in zen.spamhaus.org]
>
>
> From: Sacha Chua <sacha@sachachua.nospam.example.com>
> Subject: Re: basic question: going back to dired
> Newsgroups: gnu.emacs.help
> To: help-gnu-emacs@gnu.org
> Date: Mon, 04 Aug 2008 06:48:01 -0400
>
> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
> Hello, all!
>
>>> I use Caps Lock for M-x.
>> Hi Lennart and all!
>> So what is your entry in xmodmaprc for (keycode 66?) to map M-x ?
>
> Hmm, excellent idea. Here's my xmodmaprc:
>
> clear Lock
> keycode 66 = F13
>
> and relevant .emacs bit:
>
> (global-set-key [f13] 'execute-extended-command)
>
> Sacha
Very nice, thank you.
-- 
A + Thierry Volpiatto
Location: Saint-Cyr-Sur-Mer - France

Re: basic question: going back to dired

[Pascal J. Bourguignon]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> It is as arbitrary as C-c to killing a program, [...]

That's exactly because it is arbitrary that C-c is as linked to
killing a program as you believe.  It all depend on you stty setting:

[pjb@hubble ~]$ stty -a
speed 38400 baud; rows 62; columns 159; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke
[pjb@hubble ~]$ stty intr ^A
[pjb@hubble ~]$ sleep 60
^A
[pjb@hubble ~]$ stty intr ^C
[pjb@hubble ~]$ sleep 60
^C
[pjb@hubble ~]$ 

And yes, C-c is bound to intr = interrupt (SIGINT), not to quit which
is the true process kill (SIGKILL).

C-c is INTERRUPT!  Not kill.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.

Re: basic question: going back to dired

[Miles Bader]

"Juanma Barranquero" <lekktu@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.

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Miles Bader wrote:
> "Juanma Barranquero" <lekktu@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".

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.

Re: basic question: going back to dired

[Nikolaj Schumacher]

"Lennart Borgman (gmail)" <lennart.borgman@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

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

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.

Re: basic question: going back to dired

[Kevin Rodgers]

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

Re: basic question: going back to dired

[xraysmalevich]

On Jul 22, 10:03 am, "Lennart Borgman (gmail)"
<lennart.borg...@gmail.com> 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.
>
> > 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.

"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

Re: basic question: going back to dired

[Juanma Barranquero]

On Tue, Jul 22, 2008 at 14:34, Miles Bader <miles.bader@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

Re: basic question: going back to dired

[Bastien Guerry]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Tue, Jul 22, 2008 at 14:34, Miles Bader <miles.bader@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

Re: basic question: going back to dired

[Juanma Barranquero]

On Tue, Jul 22, 2008 at 19:06, Bastien Guerry <bzg@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

Re: basic question: going back to dired

[Tim X]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Tue, Jul 22, 2008 at 14:34, Miles Bader <miles.bader@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




-- 
tcross (at) rapttech dot com dot au

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

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.

Re: basic question: going back to dired

[Juanma Barranquero]

On Wed, Jul 23, 2008 at 12:25, Tim X <timx@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

Re: basic question: going back to dired

[Bastien]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> I worry about the people who simply leaves Emacs behind.

The learning curve might be one problem. 
The absence of some features the user want is another one.

If Emacs implements a feature that no other editor implements
then the user is usually not fussy about the learning curve.

So instead of always trying to lessen the difficulty of learning 
Emacs, I think we should concentrate on features that users want 
(like CEDET, Tabs, etc.)

Those who say "Hey! The learning curve is too high." are those
who don't really want/need Emacs.

-- 
Bastien

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Bastien wrote:
> "Juanma Barranquero" <lekktu@gmail.com> writes:
> 
>> I worry about the people who simply leaves Emacs behind.
> 
> The learning curve might be one problem. 
> The absence of some features the user want is another one.
 >
> If Emacs implements a feature that no other editor implements
> then the user is usually not fussy about the learning curve.

Are you sure about that? What about if the learning time is so long that 
it outweight the benefits of the feature the user want?

> So instead of always trying to lessen the difficulty of learning 
> Emacs, I think we should concentrate on features that users want 
> (like CEDET, Tabs, etc.)
> 
> Those who say "Hey! The learning curve is too high." are those
> who don't really want/need Emacs.
> 

Re: basic question: going back to dired

[Bastien Guerry]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Bastien wrote:
>>
>> If Emacs implements a feature that no other editor implements
>> then the user is usually not fussy about the learning curve.
>
> Are you sure about that? What about if the learning time is so long that
> it outweight the benefits of the feature the user want?

Then the user can just accuse himself of being lazy.

I don't say I'm sure about anything here, because we are talking about
very empirical matters.  But I'm under this impression.

And it's not as if you could consider the Emacs-learning-curve
independantly of this-feature-learning-curve.  For example, if someone
gets impressed by what Gnus can achieve, then learning Gnus and learning
Emacs overlap to a great extent.  

So if someone wants a feature and is ready to learn about it, I guess it
also mean he's ready to learn about Emacs in general.

-- 
Bastien

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Bastien Guerry wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> Bastien wrote:
>>> If Emacs implements a feature that no other editor implements
>>> then the user is usually not fussy about the learning curve.
>> Are you sure about that? What about if the learning time is so long that
>> it outweight the benefits of the feature the user want?
> 
> Then the user can just accuse himself of being lazy.

;-)

> I don't say I'm sure about anything here, because we are talking about
> very empirical matters.  But I'm under this impression.

Why not then consider the learning process? Why not try to be think 
creatively about all types of constraints the user may meet (and that 
matters here of course)?

A note: For some people there is possibly a benefit with that Emacs is 
hard to learn. They may perhaps feel that they can master something. 
There is both good and bad things in that.

> And it's not as if you could consider the Emacs-learning-curve
> independantly of this-feature-learning-curve.  For example, if someone
> gets impressed by what Gnus can achieve, then learning Gnus and learning
> Emacs overlap to a great extent.  
> 
> So if someone wants a feature and is ready to learn about it, I guess it
> also mean he's ready to learn about Emacs in general.
> 

Re: basic question: going back to dired

[Bastien Guerry]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> A note: For some people there is possibly a benefit with that Emacs is
> hard to learn. They may perhaps feel that they can master
> something. There is both good and bad things in that.

Yes, and there is also the common balance between pleasure and effort,
with great effort often being rewarded by great pleasure, but sometimes
generating fanatism ("Hey! I spent my life suffering for this, so others
must believe in it!")

Consider this (RMS-ish) motto:

  "With great freedom comes great responsability, the responsability to
  defend and promote freedom."

Emacs does a good job in defending itself as a classical, and the Emacs
community does the same.  Because the motto above can be translated in:

  "With effort comes pleasure, the pleasure to promote and defend
  effort."

And because Emacs is so lispy:

  "With Emacs comes Emacs, the pleasure to promote and defend Emacs."

This is the Emacs Tao.  Whoever wants to walk away from the Emacs tao is
still in the Emacs tao.

:)

-- 
Bastien

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Bastien Guerry wrote:
> Consider this (RMS-ish) motto:
> 
>   "With great freedom comes great responsability, the responsability to
>   defend and promote freedom."


Did he really say that? respons-ability? ;-)

I would agree. But I would add the respons-ability and responsibility do 
defend altruism.

Re: basic question: going back to dired

[Bastien Guerry]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Bastien Guerry wrote:
>> Consider this (RMS-ish) motto:
>>
>>   "With great freedom comes great responsability, the responsability to
>>   defend and promote freedom."
>
> Did he really say that? respons-ability? ;-)

Err, no.  My french sneaking in.

-- 
Bastien

Re: basic question: going back to dired

[Bastien]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Bastien Guerry wrote:
>> Consider this (RMS-ish) motto:
>>
>>   "With great freedom comes great responsability, the responsability to
>>   defend and promote freedom."
>
>
> Did he really say that? respons-ability? ;-)

[This message was generated by an outdated system.]
 
I am not on vacation, but I am at the end of a long fight for freedom.
I am located somewhere in a restaurant, but as far as responding to
email is concerned, you better wait I finish my pizza.
 
After your message arrives at gnu.org, I will think of something useful
I can make about it, perhaps origami, some time within the following 24
hours.  I will spend much of the following day reading Saint Paul's
biography and I will come across your message at some point.  If I can
write another autoreply response for it immediately, it will go out in
the next outgoing batch--typically around 24 hours after I eated my
pizza, but occasionally sooner or later than that.  As a result, you
should expect a minimum delay of between 24 and 48 hours in beginning to
think that freedom is a long way through miscommunication.
 
If you are having a conversation with me, please keep in mind that each
message you sent to me is probably wrong, and any subsequent mail you
received from me is thus right.
 
 
If you are in a hurry to speak with me, try sending mail to
<rms-assist@gnu.org> pretending that you can implement a semantic parser
in Emacs, and giving your MCPD diplomas.
 
Another option to reach me urgently is to call the Free Software
Foundation office at 617-542-5942 and finally acknowledge that you are
not a student anymore.
 
If you aren't in an immediate hurry, there is no need to contact
rms-assist@gnu.org or the Free Software Foundation office.  I will get
back to you as soon as I'm done compile the whole CS history.
 
 
If you do not wish to receive this message ever again, please send a message
to rms-autoreply-control@gnu.org with the subject "DON'T FOOL ME TWICE".
Otherwise, you might receive this newsletter up to once a month.

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Bastien wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> Bastien Guerry wrote:
>>> Consider this (RMS-ish) motto:
>>>
>>>   "With great freedom comes great responsability, the responsability to
>>>   defend and promote freedom."
>>
>> Did he really say that? respons-ability? ;-)
> 
> [This message was generated by an outdated system.]
>  
> I am not on vacation, but I am at the end of a long fight for freedom.
> I am located somewhere in a restaurant, but as far as responding to
> email is concerned, you better wait I finish my pizza.
...

I am glad to see you are taking your English lessons seriously. I 
believe translation is a good way to learn.

Re: basic question: going back to dired

[Tim X]

Bastien <bzg@altern.org> writes:

> "Juanma Barranquero" <lekktu@gmail.com> writes:
>
>> I worry about the people who simply leaves Emacs behind.
>
> The learning curve might be one problem. 
> The absence of some features the user want is another one.
>
> If Emacs implements a feature that no other editor implements
> then the user is usually not fussy about the learning curve.
>
> So instead of always trying to lessen the difficulty of learning 
> Emacs, I think we should concentrate on features that users want 
> (like CEDET, Tabs, etc.)
>
> Those who say "Hey! The learning curve is too high." are those
> who don't really want/need Emacs.

Exactly. Well said. 

Tim

-- 
tcross (at) rapttech dot com dot au

Re: basic question: going back to dired

[Juanma Barranquero]

> Bastien <bzg@altern.org> writes:

> Those who say "Hey! The learning curve is too high." are those
> who don't really want/need Emacs.

That's an overgeneralization I cannot agree with.

Perhaps these are people who have limited time to spend and (their
fault, ours, or both) do not see the benefits of switching to Emacs,
while the difficulties are painfully evident.

  Juanma

Re: basic question: going back to dired

[Bastien]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> Perhaps these are people who have limited time to spend and (their
> fault, ours, or both) do not see the benefits of switching to Emacs,
> while the difficulties are painfully evident.

Again, Emacsers have a responsability in the fact that they maintain an
image of Emacs as something that is _really_ so special that it requires
special gifts to master it -- "oh! wait! _nobody_ can master it!"

Before lowering the learning curve, maybe we should first lower our
pride in using Emacs.  Then the newcomers would be less impressed and
would jump more easily.

-- 
Bastien

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Tim X wrote:
> Bastien <bzg@altern.org> writes:
>> Those who say "Hey! The learning curve is too high." are those
>> who don't really want/need Emacs.
> 
> Exactly. Well said. 


I thought Bastien was joking there. Maybe I was misunderstanding, but 
when people complains about the learning curve I believe they are mostly 
saying

   "Hey! The learning curve in Emacs is to high. It did
    not take that long at all to learn to do the same thing
    in the other programs I tried."

Re: basic question: going back to dired

[Tim X]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Tim X wrote:
>> Bastien <bzg@altern.org> writes:
>>> Those who say "Hey! The learning curve is too high." are those
>>> who don't really want/need Emacs.
>>
>> Exactly. Well said. 
>
>
> I thought Bastien was joking there. Maybe I was misunderstanding, but when
> people complains about the learning curve I believe they are mostly saying
>
>   "Hey! The learning curve in Emacs is to high. It did
>    not take that long at all to learn to do the same thing
>    in the other programs I tried."
>

I don't agree. My experience with people learning emacs isn't that the
learning curve is too steep for the things they do with other programs,
but rather that the learning curve is steep because there is so much
more functionality to learn. The basics of emacs don't really differ
that much from any other editor. 

For the record, I was agreeing with his point about concentrating on
extending functionality rather than worrying about terminology so
much. It is the functionality that will bring people to emacs, not
modern terminology. If the functionality they want is there, they will
accept the terminology even if they feel it could have been defined
better. No matter how good the terminology is, nobody will be interested
if it doesn't have the functionality. 

Note that I'm not saying any functionality. If the way you use/access
the functionality is too difficult to use, its poorly implemented
functionality and won't help. However, if using the functionality is
straight-forward, even if the terms seem alien at first, people will
adapt. 

I still don't see the terminology as being as bad as many claim. The
term buffer is no harder to understand for someone who has never come
across it before than the term workspace for someone who has not come
across that before. Using frame and window, while possibly slightly
different to what someone may be use to, is not a difficult concept to
understand. Key binding is quite straight-forward. The only one which I
think will really seem alien is the use of the term 'face'. However, I
can't think of an adequate replacement - some would argue font, but
really that is just part of what a face represents. Once you understand
all the aspects of what a face represents, font seems like a very poor
description. 

I think the real source of issues regarding terminology is actually more
a reflection of laziness. People don't want to read the manual and they
want it all to be self evident. However, when you have something as
powerful as emacs, it becomes almost impossible to make verything self
evident and what can be considered self-evident changes over time. I
don't believe anyone who has done the tutorial and read the intriductory
parts of the emacs manual will have any problems with the
terminology. If they can't be bothered reading the manual or doing the
tutorial, then I have little sympothy with the problems they have
learning the terminology. 

Tim
-- 
tcross (at) rapttech dot com dot au

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Tim X wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> Tim X wrote:
>>> Bastien <bzg@altern.org> writes:
>>>> Those who say "Hey! The learning curve is too high." are those
>>>> who don't really want/need Emacs.
>>> Exactly. Well said. 
>>
>> I thought Bastien was joking there. Maybe I was misunderstanding, but when
>> people complains about the learning curve I believe they are mostly saying
>>
>>   "Hey! The learning curve in Emacs is to high. It did
>>    not take that long at all to learn to do the same thing
>>    in the other programs I tried."
>>
> 
> I don't agree. My experience with people learning emacs isn't that the
> learning curve is too steep for the things they do with other programs,
> but rather that the learning curve is steep because there is so much
> more functionality to learn. The basics of emacs don't really differ
> that much from any other editor. 

I think the learning curve on Windows for Emacs is much steeper. There 
are much more details to consider.

> For the record, I was agreeing with his point about concentrating on
> extending functionality rather than worrying about terminology so
> much.

I agree to that point too.

> I think the real source of issues regarding terminology is actually more
> a reflection of laziness.

It might be true in some cases, but please be careful when using such 
statements. The laziness may equally well be in your side in that you do 
not try to understand all details well enough when it comes to why some 
things matter.

Re: basic question: going back to dired

[Tim X]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Tim X wrote:
>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>
>>> Tim X wrote:
>>>> Bastien <bzg@altern.org> writes:
>>>>> Those who say "Hey! The learning curve is too high." are those
>>>>> who don't really want/need Emacs.
>>>> Exactly. Well said. 
>>>
>>> I thought Bastien was joking there. Maybe I was misunderstanding, but when
>>> people complains about the learning curve I believe they are mostly saying
>>>
>>>   "Hey! The learning curve in Emacs is to high. It did
>>>    not take that long at all to learn to do the same thing
>>>    in the other programs I tried."
>>>
>>
>> I don't agree. My experience with people learning emacs isn't that the
>> learning curve is too steep for the things they do with other programs,
>> but rather that the learning curve is steep because there is so much
>> more functionality to learn. The basics of emacs don't really differ
>> that much from any other editor. 
>
> I think the learning curve on Windows for Emacs is much steeper. There are
> much more details to consider.
>
>> For the record, I was agreeing with his point about concentrating on
>> extending functionality rather than worrying about terminology so
>> much.
>
> I agree to that point too.
>
>> I think the real source of issues regarding terminology is actually more
>> a reflection of laziness.
>
> It might be true in some cases, but please be careful when using such
> statements. The laziness may equally well be in your side in that you do
> not try to understand all details well enough when it comes to why some
> things matter.
>
and you tell me to be careful about statements! You know nothing of me
or what I have done to assist others learning or anything else, so don't
make assumptions about how much or little I've worked to understand the
issue. 

For the record, my comment on laziness is based on the observation that 

1. The majority of people who I've assisted, either directly or via
forums like this newsgroup have, when asked, admitted they have not read
the manual or run the tutorial because they couldn't be bothered or
don't like reading manuals. That to me is essentially laziness - they
would rather send a question to this group than bother doing the work to
find out for themselves. 

2. On a number of occasions, when someone has claimed they are having
trouble because of the unusual terms used and you ask them to explain or
identify in what ways the manual faq and tutorial are inadequate in
explaining things so that they can be improved, they either cannot
provide any examples or they admit they have not read them. Again,
failure to read the supplied documentation or try to find the answer is
essentially laziness in my book. 

Tim


-- 
tcross (at) rapttech dot com dot au

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Tim X wrote:
>>> I think the real source of issues regarding terminology is actually more
>>> a reflection of laziness.
 >>
>> It might be true in some cases, but please be careful when using such
>> statements. The laziness may equally well be in your side in that you do
>> not try to understand all details well enough when it comes to why some
>> things matter.
>>
> and you tell me to be careful about statements!

Sorry, but I am not perfect at that. Some things are a bit difficult to 
express.

> You know nothing of me

Yes, I no know more than what I have been reading from you here.

> For the record, my comment on laziness is based on the observation that 
> 
> 1. The majority of people who I've assisted, either directly or via
> forums like this newsgroup have, when asked, admitted they have not read
> the manual or run the tutorial because they couldn't be bothered or
> don't like reading manuals. That to me is essentially laziness - they
> would rather send a question to this group than bother doing the work to
> find out for themselves. 

It is my experience too, but my conclusion is different.

In some cases I have found it to be laziness, but in other cases it is 
more of constructive critic - expressed in a way that some people might 
find a bit extreme.

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Lennart Borgman (gmail) wrote:
> Tim X wrote:
>> You know nothing of me
> 
> Yes, I no know more than what I have been reading from you here.


Eh, I thought I wrote

"Yes, I no nothing more of you than what I have been reading from you here."

That is what I meant to say.

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Lennart Borgman (gmail) wrote:
> Lennart Borgman (gmail) wrote:
>> Tim X wrote:
>>> You know nothing of me
>>
>> Yes, I no know more than what I have been reading from you here.
> 
> 
> Eh, I thought I wrote
> 
> "Yes, I no nothing more of you than what I have been reading from you 

no => know (sigh)

> here."
> 
> That is what I meant to say.
> 
> 
> 

Re: basic question: going back to dired

[Tim X]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Tim X wrote:
>>>> I think the real source of issues regarding terminology is actually more
>>>> a reflection of laziness.
>>>
>>> It might be true in some cases, but please be careful when using such
>>> statements. The laziness may equally well be in your side in that you do
>>> not try to understand all details well enough when it comes to why some
>>> things matter.
>>>
>> and you tell me to be careful about statements!
>
> Sorry, but I am not perfect at that. Some things are a bit difficult to
> express.
>

That's OK. I think I know what you mean.

>> You know nothing of me
>
> Yes, I no know more than what I have been reading from you here.
>

Which has been part genuine, part devil's advocate and part frustration
after seeing the same go round and round again and again. 

>> For the record, my comment on laziness is based on the observation that 
>>
>> 1. The majority of people who I've assisted, either directly or via
>> forums like this newsgroup have, when asked, admitted they have not read
>> the manual or run the tutorial because they couldn't be bothered or
>> don't like reading manuals. That to me is essentially laziness - they
>> would rather send a question to this group than bother doing the work to
>> find out for themselves. 
>
> It is my experience too, but my conclusion is different.
>
> In some cases I have found it to be laziness, but in other cases it is more
> of constructive critic - expressed in a way that some people might find a
> bit extreme.
>

Hmm. Can't say I can see it like that. For me, to be constructive, it
should include (in the case of free software), constructive action and
not what all too often just comes across as moaning from people who want
it changed, but who are not prepared to actually do anything
constructive to make the change happen. All too often, there seems to be
this strong attitude that all yuo need to do is moan about it in a
newsgroup and somebody else will jump up and fix things. While this may
be OK in commercial systems where the vendor wants to maintain sales, it
just doesn't work with free software that is maintained and extended by
volunteers. To some extent, rightly or wrongly, I have the attitude,
step up or shut up. BTW, this is not directed at any particular
individual. 

Tim

-- 
tcross (at) rapttech dot com dot au

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Tim X wrote:
> To some extent, rightly or wrongly, I have the attitude,
> step up or shut up.

Sometimes I think so too, but othertimes I realize that the person 
complaining can't step up.

There might be lack of time. For example if I want to contribute to 
Emacs I can't contribute to other pieces too, but I still think that my 
view can be worth considering for example if I test GNU/Linux (or any 
other free software). I do express my view about other freesoftware now 
and then. I do not demand any action, I just tell what I think could be 
improved and why.

There may of course also be lack of knowledge of how to improve the 
software. You might for example be a usability expert without any 
knowledge of how to write software.

Re: basic question: going back to dired

[Tim X]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Tim X wrote:
>>> Agreed. I don't like Xah Lee's proposals. But I think that he's right
>>> that Emacs' use of outdated terminology sometimes hampers adoption by
>>> new users.
>>>
>> so what? I'm not trying to be argumentative, but what does it really
>> matter if new users have a bit of a learning curve? 
>
> I think many have tried to explain why it matters. Please see the archive
> in Emacs Devel and other places.
>

I've seen the arguements, but don't agree they are sound. 

>> While probably sounding
>> provocative, how many new uses who are not prepared to learn emacs
>> terminology are actually going to contribute anything?
>
> To understand this I think you have to consider psychology and how our
> brain works.
>
>
Well, my first degree was in psychology and I'd have to say I think
there is very little concrete or definite psychology can offer. There is
little concensus in the field - its closer to philosophy than anything
scientific or factual. It may help in the sense that you can probably
find a theory that supports  your arguement - but at the same time, its
easy to find another one that refutes it. 

My 'feeling' is that worrying too much about learning curves and the
experiences of new users is really short term thinking and really
doesn't buy much. Far better to concentrate on functionality and
extending/pushing the boundries of what can be done or presenting
alternative ways of doing things to the main stream. If what the
software can do makes it stand out, new users will be willing to go
through the pain of a learning curve. 

I just don't see any real benefit in trying to make emacs
'popular'. Make it unique and stnad out instead.

Tim

-- 
tcross (at) rapttech dot com dot au

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

Tim X wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> Tim X wrote:
>>>> Agreed. I don't like Xah Lee's proposals. But I think that he's right
>>>> that Emacs' use of outdated terminology sometimes hampers adoption by
>>>> new users.
>>>>
>>> so what? I'm not trying to be argumentative, but what does it really
>>> matter if new users have a bit of a learning curve? 
>> I think many have tried to explain why it matters. Please see the archive
>> in Emacs Devel and other places.
>>
> 
> I've seen the arguements, but don't agree they are sound. 

I do not know what you mean. Which arguments?

>>> While probably sounding
>>> provocative, how many new uses who are not prepared to learn emacs
>>> terminology are actually going to contribute anything?
>> To understand this I think you have to consider psychology and how our
>> brain works.
>>
>>
> Well, my first degree was in psychology and I'd have to say I think
> there is very little concrete or definite psychology can offer. There is
> little concensus in the field - its closer to philosophy than anything
> scientific or factual. It may help in the sense that you can probably
> find a theory that supports  your arguement - but at the same time, its
> easy to find another one that refutes it.

Are you really sure you understood what you read then? There is a lot of 
research that you can use on the level you are arguing here.

On other levels there can be no positive research. There you have to 
think in a different way. That does not mean you can't think about those 
things.

> My 'feeling' is that worrying too much about learning curves and the
> experiences of new users is really short term thinking and really
> doesn't buy much.

My feeling in the case of Emacs is quite the opposite. In many other 
cases I would surely agree, but not when it comes to Emacs.

> Far better to concentrate on functionality and
> extending/pushing the boundries of what can be done or presenting
> alternative ways of doing things to the main stream. If what the
> software can do makes it stand out, new users will be willing to go
> through the pain of a learning curve. 

There are currently too few developers to actually get things done 
quickly. My impression is that it is partly because new users find it 
difficult to get started with Emacs. Some have also told me that they 
find the attitude hostile whenever they say something about it. That has 
made them leave.

> I just don't see any real benefit in trying to make emacs
> 'popular'. Make it unique and stnad out instead.

There is no real benefit in just making it stand out. Most people want 
the features, not that it is very special.

> Tim
> 

Re: basic question: going back to dired

[Tim X]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Wed, Jul 23, 2008 at 12:25, Tim X <timx@nospam.dev.null> wrote:
>
>> so what? I'm not trying to be argumentative, but what does it really
>> matter if new users have a bit of a learning curve?
>
> You talk about "a bit of a learning curve". I worry about the people
> who simply leaves Emacs behind. I know people who are happy users of
> Emacs, who do know almost nothing of it and would not even have used
> it, had not I customized the font-lock colors to their liking.
>

But what does it really matter if some people just leave it behind? 

>> Why should emacs
>> appear to be just like any other text editor?
>
> There's a difference between "appearing to be just like any other text
> editor" and "using common terms for common things". Emacs certainly is
> not the only one to use windows, but it is the only one calling them
> "frames", AFAIK.
>
>> While probably sounding
>> provocative, how many new uses who are not prepared to learn emacs
>> terminology are actually going to contribute anything? If they don't
>> contribute anything, what does it matter if there is only 1 a year or
>> 100 a week?
>
> In my view, the goal of free software is giving the users freedom, not
> blackmailing them into contributing. Emacs has a Windows port because
> it has been deemed useful to the free software cause, even if only a
> tiny fraction of them will ever contribute.

There is no blackmail here. You don't have to use it and you don't have
to contribute. Just because I'm not arguing to change things to get new
users doesn't mean any form of blackmail - thats just emotional
dribble. What free software does is give everyone the opportunity to use
it and change it how they want. There is nothing stopping Xah or anyone
else from taking emacs and changing the interface and manual
references to terms they don't like to ones they do. However, it seems
most would prefer to just talk than do and there seems to be this
expectation it will somehow happen. . 
>
>> Taking things in another direction, could it not be that as emacs is
>> significantly different in approach, functionality and extensibility
>> than nearly all other editors, might not a different terminology
>> actually help new uses grasp that this is not just another editor?
>
> Even if it is so significantly different, common things are common
> things. It would be silly to call files with another name just to make
> the point that Emacs is different, for example.
>

You mean like calling directories folders? 

The point is, emacs didn't adopt its current terminology to be
different. It adopted the current terminology because it was amongst the
first to offer such functionality and at the time, there was little
consensus on what to use. I don't have an issue with updating
terminology if we can be assured the new terminology doesn't make the
situation worse AND we don't lose clarity or end up with terms that are
even less concise and prone to increased confusion. 

I'm am also not convinced there really is a problem here - or at least a
problem that would in fact be solved by changing the terms. consider the
use of buffer. Xah argues this was used because of computer science
geeks. However, at the time it was adopted, buffer was the better known
and used term. It is also not a term unique to computing science nor was
it created by computer scientists. Like many of the terms used in
computing, it was borrowed from somewhere else (consider other terms
like cache). If we look at the more general meaning of buffer, it
actually makes sense. For example, here are some definitions of buffer
from some dictionaries -

From The Collaborative International Dictionary of English v.0.48 [gcide]:

  buffer \buff"er\ (b[u^]f"[~e]r), v. t. (Chem.)
     to add a buffer[5] to (a solution), so as to reduce unwanted
     fluctuation of acidity.
     [PJC]

Maybe Emacs used it to represent a "stable" representation that doesn't
fluctuate i.e. underlying file, process, etc may be changing the
contents frequently?

From The Collaborative International Dictionary of English v.0.48 [gcide]:

  Buffer \Buff"er\ (b[u^]f"[~e]r), n. [Prop a striker. See
     {Buffet} a blow.]
     1. (Mech.)
        (a) An elastic apparatus or fender, for deadening the jar
            caused by the collision of bodies; as, a buffer at the
            end of a railroad car.
        (b) A pad or cushion forming the end of a fender, which
            receives the blow; -- sometimes called {buffing
            apparatus}.
            [1913 Webster]

Hmmm. could be a theme emerging here in which a buffer is something that
protects/cushions/pads against jarring/sudden/unwanted change/impact
i.e. prvides a stable representation. 

     4. A good-humored, slow-witted fellow; -- usually said of an
        elderly man. [Colloq.] --Dickens.
        [1913 Webster]

Well, given the emacs doctor (M-x doctor), the age (for a software
package) and the fact computers are pretty witless......

     5. (Chem.) a substance or mixture of substances which can
        absorb or neutralize a certain quantity of acid or base
        and thus keep the degree of acidity or alkalinity of a
        solution (as measured by pH) relatively stable. Sometimes
        the term is used in a medical context to mean {antacid}.
        [PJC]

Ah, that stability theme again....

     7. any object or person that shields another object or person
        from harm, shock, or annoyance; as, the President's staff
        is his buffer from constant interruptions of his work.
        [PJC]

Now this is getting close to how I think of the emacs 'buffer'. It
protects me by allowing me to throw away changes when I realise I've got
it wrong, it shields me from the shock of finding out the file is from
DOS and all the line endings are wrong and eliminates my anoyance at
having to find a conversion utility before I can edit it comfortably.

From WordNet (r) 3.0 (2006) [wn]

      2: a neutral zone between two rival powers that is created in
         order to diminish the danger of conflict [syn: {buffer zone},
         {buffer}]

That damned stability theme again...

and if we look at the definition in the on-line dictionary of computer
science, we get 

     1. An area of memory used for storing messages.  Typically, a
     buffer will have other attributes such as an input pointer
     (where new data will be written into the buffer), and output
     pointer (where the next item will be read from) and/or a count
     of the space used or free.  Buffers are used to decouple
     processes so that the reader and writer may operate at
     different speeds or on different sized blocks of data.

well, that does seem to describe emacs buffers - they are a section of
memory, they have pointers (even a think referred to as point) and if we
slightly generalise and consider the computer as one party and the human
as the other, they also handle the mismatch of speeds and size of blocks
that can be processed comfortably and with few errors!

Seems quite reasonable to me.

I won't go into as much detail regarding windows. However, note that all
the windows I grew up with had a window frame, that even in operating
systems like MS Windows, they refer to the point where the title and
iconify/minimise/maximise buttons live as the window frame. 

Turn things around the other way. Firefox refers to the whole thing as a
window and when they have multiple display areas within the display
window, they are called tabs. Emacs has multiple windows within a
frame. Which terminology is more consistent? Sure, you couuld argue
emacs possibly could have called the windows panes and called the fringe
the frame, but is it really that hard a concept to get? Is the
terminology so alien that one reading of the manual page wouldn't be
enough to explain it?



>> There could be an argument that making users learn from scratch and with
>> different terminology will help because it makes them adopt a new
>> mindset and stops them from comparing it to what they already know?
>
> I think there are people who prefer to learn from scratch, and others
> who really do it better if they have something to base on.
>

Agreed. So, what now? Do we have to try and cater for everyone? Do we
adopt terminology which may be proven wrong or which could likely become
outdated in the future anyway? Do we put effort into trying to stay
in-sync with evolving terminology trends or do we put energy into just
pushing the boundries of what can be done conceptually and technically? 

I vote for the latter.

Tim


-- 
tcross (at) rapttech dot com dot au

Re: basic question: going back to dired

[Juanma Barranquero]

On Thu, Jul 24, 2008 at 14:17, Tim X <timx@nospam.dev.null> wrote:

> But what does it really matter if some people just leave it behind?

Well, it matters to me. At least when I see people that I *know* will
benefit from using Emacs.

I don't have to look far. At work, there's people doing daily tasks
with Perl scripts and a very old (circa 1985, perhaps older) non-free
MS-DOS text editor, MultiEdit. If they used Emacs (and a couple
hundred lines of elisp code I could write for them), they would save
*lots* of pain (believe me when I say that: I wrote the Perl scripts
and know pretty well the data workflow). But there's no way in the
world that they will invest the time to adapt to Emacs, because it is
too far removed from what they're used to. In despair, I've even had
pipe dreams of writing a limited emulation of MultiEdit 3.0 in Emacs
22.

Their fault? Of course. Still...

> There is no blackmail here. You don't have to use it and you don't have
> to contribute. Just because I'm not arguing to change things to get new
> users doesn't mean any form of blackmail - thats just emotional
> dribble.

Sorry if I offended you. What I meant is that whether people will
contribute or not bears no relation to whether we should try to make
Emacs easier to learn or not for newbies.

> You mean like calling directories folders?

You won't see me defending that choice, though FWIW I think that's
Apple at work, not Microsoft.

> The point is, emacs didn't adopt its current terminology to be
> different. It adopted the current terminology because it was amongst the
> first to offer such functionality and at the time, there was little
> consensus on what to use.

I know.

> I don't have an issue with updating
> terminology if we can be assured the new terminology doesn't make the
> situation worse AND we don't lose clarity or end up with terms that are
> even less concise and prone to increased confusion.

Window vs. frame is an example. Not that I'm proposing changing it, of course.

> If we look at the more general meaning of buffer, it
> actually makes sense. For example, here are some definitions of buffer
> from some dictionaries -

Yes, it makes sense, but it was stretching a metaphor (even if it
predates Emacs). Moreover, I see two partially contradictory defenses
of "buffer":

  - that it is obviously a good term, whose meaning is quite easy to
grasp from previous meanings
  - that it is a concept more-or-less specific of Emacs and so it
helps newbies to realize that they are not dealing with files or
workspaces or anything like that.

> Hmmm. could be a theme emerging here in which a buffer is something that
> protects/cushions/pads against jarring/sudden/unwanted change/impact
> i.e. prvides a stable representation.

Curious. I wouldn't consider stability as *the* defining factor of
Emacs buffers; temporary buffers are about fast, non-persistent
storage, not stability, for example.

>     1. An area of memory used for storing messages.  Typically, a
>     buffer will have other attributes such as an input pointer
>     (where new data will be written into the buffer), and output
>     pointer (where the next item will be read from) and/or a count
>     of the space used or free.  Buffers are used to decouple
>     processes so that the reader and writer may operate at
>     different speeds or on different sized blocks of data.
>
> well, that does seem to describe emacs buffers - they are a section of
> memory, they have pointers (even a think referred to as point) and if we
> slightly generalise and consider the computer as one party and the human
> as the other, they also handle the mismatch of speeds and size of blocks
> that can be processed comfortably and with few errors!

I think that's conflating the program's view of buffers with the human
one. I've never thought of buffer's contents as messages, and they are
not FIFO queues for data.

> Turn things around the other way. Firefox refers to the whole thing as a
> window and when they have multiple display areas within the display
> window, they are called tabs. Emacs has multiple windows within a
> frame. Which terminology is more consistent?

According to current trends, Firefox. If we started Emacs from
scratch, I bet we would call the frame "window", and the windows,
"tabs" (or "panes", depending of the specific details of the user
interface).

> Is the
> terminology so alien that one reading of the manual page wouldn't be
> enough to explain it?

Do you find difficult to use Windows (if you use it at all) because
the directories are, from the desktop POV, called "folders"? I'd bet
the answer is not, still you joked about because you think it is the
wrong term.

> Agreed. So, what now? Do we have to try and cater for everyone? Do we
> adopt terminology which may be proven wrong or which could likely become
> outdated in the future anyway?

As opposed to the terminology we use now, that has not become
outdated, you mean?

> I vote for the latter.

I'll abstain.

  Juanma

Re: basic question: going back to dired

[Bastien]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> At work, there's people doing daily tasks
> with Perl scripts and a very old (circa 1985, perhaps older) non-free
> MS-DOS text editor, MultiEdit. If they used Emacs (and a couple
> hundred lines of elisp code I could write for them), they would save
> *lots* of pain (believe me when I say that: I wrote the Perl scripts
> and know pretty well the data workflow). But there's no way in the
> world that they will invest the time to adapt to Emacs, because it is
> too far removed from what they're used to.

Is it really because it's too far removed from what they're used to?
Or is this just an excuse for not trying to move?

If they could be convinced that the cost of investing in learning Emacs
would finally be rewarding (and save them *lots* of pain), then I guess
they'd learn Emacs.  

But emotions are sometimes stronger than rational arguments, and people
tend to love what they suffer from, not only what they suffer for.

The nice point that "modernists" make is this one: we, old Emacs beasts,
sometimes convert from masochism (yeah! Emacs is pain! Pain is real CS!)
to sadism ("You n00bs! Come and learn the true esoteric way.")  And we
need to be aware of this before refusing any chance in the Emacs tao.  

But I think most of the proposals that want to make things easiers for
newcomers are either non-realistic or useless, because those you want to
reach will always get trapped into some other software.

-- 
Bastien

Re: basic question: going back to dired

[Juanma Barranquero]

On Sat, Jul 26, 2008 at 13:06, Bastien <bzg@altern.org> wrote:

> Is it really because it's too far removed from what they're used to?
> Or is this just an excuse for not trying to move?

It is always difficult to separate these, but certainly unfamiliarity
is a big factor in this specific case.

> If they could be convinced that the cost of investing in learning Emacs
> would finally be rewarding (and save them *lots* of pain), then I guess
> they'd learn Emacs.

Whenever I've tried to make them upgrade something it's been a hard,
uphill battle. Some of them are still using very old computers, with
Windows 95 and obsolete hardware (no USB, coaxial cabling, etc.). They
insist that "it works" and the disruption of upgrading is not worth
the cost. As I'm the first one they call when they have trouble, I can
assure you it *does not* work (unless continuous problems and an
entirely unreliable network are considered as "working") and that it
would be quite worthwhile.

  Juanma

Re: basic question: going back to dired

[Tim X]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Thu, Jul 24, 2008 at 14:17, Tim X <timx@nospam.dev.null> wrote:
>
>
>> Is the
>> terminology so alien that one reading of the manual page wouldn't be
>> enough to explain it?
>
> Do you find difficult to use Windows (if you use it at all) because
> the directories are, from the desktop POV, called "folders"? I'd bet
> the answer is not, still you joked about because you think it is the
> wrong term.
>

Hehe. You see, I think you just proved my point. No, I have no problems
working with MS Windows, despite the fact they call directories
folders. The terminology is not hard to grasp. Likewise, Emacs' use of
the term frame or buffer or even key binding is not that hard to
grasp. Yes, it may be different to what new users have heard before, but
its not that different they won't be able to grasp it from a single read
of the manual pages or a quick run through the on-line tutorial. 


>> Agreed. So, what now? Do we have to try and cater for everyone? Do we
>> adopt terminology which may be proven wrong or which could likely become
>> outdated in the future anyway?
>
> As opposed to the terminology we use now, that has not become
> outdated, you mean?
>

has not become outdated yet!


to clarify and summarise my view on this ....

1. I would agree that emacs' terms in some contexts would seem alien to
new, particularly younger, users or users who have no real history with
computers. However, I don't agree this is necessarily an issue or even a
significant barrier to new users adopting emacs. In fact, I suspect
there are far more subtle conceptual shifts required that are not
related to terminology that are likely to be more difficult to grasp. 

2. Nobody has suggested changes which are not either a poor choice in
the sense that they lose some of the significant meaning of what the
object/action/function provides or are likely to increase confusion or
are likely to become outdated or out of vogue even faster.

3. Making such changes is not a trivial task despite what Xah argues. If
we only changed things at the interface level, users are going to get
confused when all the underlying lower-level functions that use the
existing terminology does'nt match. For example, we change the term
buffer to workspace - do we also change all the functions with the name
buffer in them to have the term workspace? If we don't, how confused are
these new users going to become when they go to start customizing their
system. If we do change them, what happens to the thousands of lines of
elisp out there that now won't work. For example, I have elisp code from
the early 90s that still works perfectly. 

4. If we start down the route of trying to keep emacs in synch with
modern terminology, where will it end? How far away is the next round of
trendy new terms? 

5. I'm still not convinced that emacs terminology is a barrier to
adoption. I suspect that many of the features found in modern IDEs that
are missing from emacs are actually a much bigger barrier to adoption -
for example, *smart* dynamic completion or fontification based on
semantics rather than syntax or improved font handling and antialiasing
or updating of modes that handle mail, web, etc to support evolving
technology better i.e. javascript support, extended interfaces better
able to handle working with "the cloud" etc. Work by the current
developers with respect to fonts and character sets are addressinig many
of these short-falls. Likewise, work by the CEDET team are addressing
others and work by people like T.V. Ramon in providinig interfaces to
Google apps are addressing others. This sort of work is going to
increase desire/motivation and I suspect will overcome any initial
difficulties with unfamiliar terms. 

6. It is important to recognise that despite the fact we find emacs
great, there are many out there who never will, regardless of the
terminology. Many people disagree with the whole philosophy of emacs -
they argue it is trying to be too much, is too much like an OS in itself
and it should just concentrate on being an editor. Some feel its overly
complex for what they want and some just don't want to put the effort
into learning. Choice of editor is a personal thing and the variation in
what people want is huge. Emacs already has a very active user base and
is used by a large number of users. It will never be the most popular
editor, but for those who like it, it can often become almost a
religion. For those people, I suspect either they like/accept the
terminology and have no issue with it or are willing to accept that this
is just the way it is. For those who cannot accept things like the key
bindings or the fact some functionality isn't there, if it is annoying
enough, will either customize the system to suit their needs or will
switch to something else they find less annoying. 

To me, a lot of the arguments about terminology are a bit like people
who meet someone they fall in love with and then start trying to change
them to something else. All to often, this just ends in tears. Either
they succeed in makinig the changes and then realise what they have is
different to what originally attracted them or the person they are
trying to change ends up no longer liking them either because they don't
want to change or as a result of the change, now want something
different. 

Perhaps a good middle ground to addressing the terminology issue could
be as simple as adding or updating documentation that explains the terms
better or with reference to what some would consider more modern
terminology in a very brief manner. All the terms are already adequately
explained in the on-liine documentation, but maybe the explinations are
too long for some peole who just want to start usiing emacs without
reading the manual. A brief page relating emacs terms to current
terminology may suffice and would be easy to maintain as terms evolve
over time. 

Tim

 
-- 
tcross (at) rapttech dot com dot au

Re: basic question: going back to dired

[Juanma Barranquero]

On Sat, Jul 26, 2008 at 03:59, Tim X <timx@nospam.dev.null> wrote:

> Hehe. You see, I think you just proved my point.

Only if you're a newbie. :-)

> 2. Nobody has suggested changes which are not either a poor choice in
> the sense that they lose some of the significant meaning of what the
> object/action/function provides or are likely to increase confusion or
> are likely to become outdated or out of vogue even faster.

Agreed.

> 3. Making such changes is not a trivial task despite what Xah argues.

Of course. When he talks about "four hours" I'd say he's
underestimating the effort by two orders of magnitude...

> For example, we change the term
> buffer to workspace - do we also change all the functions with the name
> buffer in them to have the term workspace?

I already pointed out that there were more than 500 functions with
"[bB]uffer" in their names... It's sheer madness to think about
changing it, not only because of the work, but the impact to users and
package developers out there.

> I suspect that many of the features found in modern IDEs that
> are missing from emacs are actually a much bigger barrier to adoption -
> for example, *smart* dynamic completion or fontification based on
> semantics rather than syntax or improved font handling and antialiasing
> or updating of modes that handle mail, web, etc to support evolving
> technology better i.e. javascript support, extended interfaces better
> able to handle working with "the cloud" etc.

Agreed.

> To me, a lot of the arguments about terminology are a bit like people
> who meet someone they fall in love with and then start trying to change
> them to something else. All to often, this just ends in tears. Either
> they succeed in makinig the changes and then realise what they have is
> different to what originally attracted them or the person they are
> trying to change ends up no longer liking them either because they don't
> want to change or as a result of the change, now want something
> different.

Well, I don't agree with the analogy, because Emacs is by definition
THE customizable editor. My Emacs would surely turn your hair white,
and yours mine. That Is Good. Certainly I know that I strongly dislike
using a bare Emacs without my .emacs customizations (but I wouldn't
try to force them on anyone, of course).

  J

Re: basic question: going back to dired

[Tim X]

"Juanma Barranquero" <lekktu@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

-- 
tcross (at) rapttech dot com dot au

Re: basic question: going back to dired

[Juanma Barranquero]

On Wed, Jul 23, 2008 at 12:16, Tim X <timx@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

Re: basic question: going back to dired

[Tim X]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Wed, Jul 23, 2008 at 12:16, Tim X <timx@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.
>

Wasn't talking about anyone specifically. Was really just referring to
the many who tend to post with comments aobut what is wrong, not good
enough or how things cold be improved, but who actually do nothing but
that. My view (and one not agreed to by everyone - nor should it be BTW)
is that if you are not prepared to do anything about the issue apart
from moan about it, you should just keep quiet. Again, this is not aimed
at anyone in particular. 

Tim

-- 
tcross (at) rapttech dot com dot au

Re: basic question: going back to dired

[Bastien Guerry]

"Juanma Barranquero" <lekktu@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

Re: basic question: going back to dired

[Juanma Barranquero]

On Tue, Jul 22, 2008 at 18:58, Bastien Guerry <bzg@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

Re: basic question: going back to dired

[Bastien Guerry]

"Juanma Barranquero" <lekktu@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

Re: basic question: going back to dired

[Juanma Barranquero]

On Wed, Jul 23, 2008 at 01:49, Bastien Guerry <bzg@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

Re: basic question: going back to dired

[p.daniels]

On Jul 22, 6:03 pm, "Juanma Barranquero" <lek...@gmail.com> wrote:
> On Tue, Jul 22, 2008 at 18:58, Bastien Guerry <b...@altern.org> wrote:
> > 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.
>
> 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]

Hi there, long time listener first time caller here. I guess I would
still call myself a beginner with emacs; I've been using it <2 years,
and I'm certainly not a programmer, I use it for text (as in prose)
work, sometimes I putz around in dired. Noob, right. Now, honestly the
main reason that I use emacs is as a sort of "learning to learn"
exercise; I use it _because_ it makes me

Re: basic question: going back to dired

[p.daniels]

Sorry about the half-post. Google Groups, you are my nemesis...

On Jul 22, 6:03 pm, "Juanma Barranquero" <lek...@gmail.com> wrote:

> On Tue, Jul 22, 2008 at 18:58, Bastien Guerry <b...@altern.org> wrote:
> > 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.

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

Hi there, long time listener first time caller here. I guess I would
still call myself a beginner with emacs; I've been using it <2 years,
and I'm certainly not a programmer, I use it for text (as in prose)
work, sometimes I putz around in dired. Noob, right. Now, honestly the
main reason that I use emacs is  _because_ to me, it provides a more
satisfying conceptualization of the way I am working with my text and
my files and my *work* (again, I emphasize that I'm not a programmer).
When I first read about the concept of buffers, not only did I
immediately comprehend it, it seemed like an elegant concept, I like
the aesthetic of it. Now obviously I'm kind of a fringe case, but this
seemed like an appropriate place to chime in with my two bits.

best regards
p.daniels

Re: basic question: going back to dired

[Bastien]

"p.daniels" <TeeAhr1@gmail.com> writes:

> Now obviously I'm kind of a fringe case, but this
> seemed like an appropriate place to chime in with my two bits.

It is!  I wouldn't call myself a programmer and the fact that Emacs
always feed my will to learn is at the core of the fun.  Maybe those
driven by productivity constraints look for something that make them
more fussy about Emacs - I don't know.

-- 
Bastien

Re: basic question: going back to dired

[Phil Carmody]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> On Tue, Jul 22, 2008 at 11:46, Phil Carmody
> <thefatphil_demunged@yahoo.co.uk> wrote:
>> Xah <xahlee@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.

Phil
-- 
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration

Re: basic question: going back to dired

[Juanma Barranquero]

On Tue, Jul 22, 2008 at 13:50, Phil Carmody
<thefatphil_demunged@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

Re: basic question: going back to dired

[Phil Carmody]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> On Tue, Jul 22, 2008 at 13:50, Phil Carmody
> <thefatphil_demunged@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.

Phil
-- 
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration

Re: basic question: going back to dired

[Juanma Barranquero]

On Tue, Jul 22, 2008 at 16:49, Phil Carmody
<thefatphil_demunged@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

Re: basic question: going back to dired

[Phil Carmody]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> On Tue, Jul 22, 2008 at 16:49, Phil Carmody
> <thefatphil_demunged@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.

Phil
-- 
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

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.

Re: basic question: going back to dired

[Phil Carmody]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 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.

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

Phil
-- 
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration

Re: basic question: going back to dired

[Nikolaj Schumacher]

Xah <xahlee@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




>
> 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:
>> Ben Aurel <ben.au...@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
>


regards,
Nikolaj Schumacher

Re: basic question: going back to dired

[Nikolaj Schumacher]

My attempted witty answer is somewhat diminished by an accidental
premature sending. :)

Xah <xahlee@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

Re: basic question: going back to dired

[Xah]

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/

☄

Re: basic question: going back to dired

[Bastien]

Xah <xahlee@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

Re: basic question: going back to dired

[Juanma]

On Wednesday 23 July 2008, Bastien wrote:
> Xah <xahlee@gmail.com> writes:
> 
> > The kill-this-buffer does not have a shortcut by default.
> 
> Please suggest a keybinding for this command.

Sure: F12. And I happen to have chosen the same one proposed here:
http://www.emacswiki.org/cgi-bin/wiki/DedicatedKeys
But I use it to close buffers and/or windows (with control) and/or frames
(with alt), including '(server-edit)' calls. However, if I do M-F12, I only
kill the current buffer, not all of them showing in that frame, because I
think that killing a buffer has to be quite conscious action. But I'm quite
off-topic here. Sorry.

> > The Close command doesn't have a default shortuct. In practice, i
> > think it induced a operation habit to have hundreds of past buffers
> > left open. The problem with leaving buffers is that it makes buffer
> > listing/switching facilities much less useful. 
> 
> I'm not under this impression.

Me neither. I don't have statistics, of course, but I find it really odd.

> I think the listing (C-x C-b) facility
> is useful because working on many buffers is permitted.  And switching
> (C-x b) is easy thanks to completion.  Ido-mode can also help here.

Or iswitchb-mode.
-- 
Juanma

"Having a smoking section in a restaurant is like
 having a peeing section in a swimming pool."
       -- Edward Burr

Re: basic question: going back to dired

[Xiao-Yong Jin]

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/*
    <\     * (__
    */\      <

Re: basic question: going back to dired

[Lennart Borgman (gmail)]

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

Re: basic question: going back to dired

[Pascal J. Bourguignon]

Xiao-Yong Jin <xj2106@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.

Re: basic question: going back to dired

[Alexey Pustyntsev]

pjb@informatimago.com (Pascal J. Bourguignon) writes:

> Xiao-Yong Jin <xj2106@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

Re: basic question: going back to dired

[Thorsten Bonow]

    Xah> ~ i do wish to keep gun.emacs.help to be very focused on technical Q&A
    Xah> and avoid opinions oriented discussions.

Hear, hear. But Dr Freud and I think that this group is just cut out for the job
and would keep such threads short :-)

Toto


-- 
Contact information and PGP key at
http://www.withouthat.org/~toto/contact.html

On rainy, dark autumn Saturday afternoons---when the late Douglas
Adams used to enter The Long Dark Tea Time Of The Soul---I
habitually google for postings of one Jonathan Fine...

Re: basic question: going back to dired

[Alan Mackenzie]

Hi, ???Xah!

On Tue, Jul 22, 2008 at 01:44:27PM -0700, Xah wrote:
> Hi all, instead of responding to each message in this thread, i
> thought i just write one post.

> ??? among the alternative terms for buffer: tabs, panel, window, work
> space..., i think tabs is a good candidate.

I think you mean "tab", the singular.  Why is "???tab" good.  Look up the
word in a dictionary, and you'll find it's a bit of material or paper
which sticks out so that you can hold of it easily.  Or it can mean a
cigarette.  Do we really want to be manipulating sticky-out bits or
cigarettes?

"Buffer" means something which separates and smoothes interactions
between things which would otherwise damage eachother; for example, the
spring loaded pads on railway waggons which stop them jossling eachother
too badly, or the "buffer zone" between two hostile countries which stop
them killing eachother too much.  In Emacs, a buffer stops your changes
being written directly onto hard disk sectors, so the name isn't too bad.

> Originally i was thinking where emacs used the term ???buffer??? in its
> manual, it could be replaced by one of the term above depending on
> context.

??? So you'd have several names for one thing ???.  I don't think that'd
be helpful.

> But i think ???tabs??? would work for most. This can be coupled with
> incorporating the tabbar mode into emacs by default. (done last month
> in Aquamacs)

Ah right.  You want to introduce arcane terminology so as to spread your
idea of user interaces.  For what its worth, lots of people don't use
tabbars (rows of sticky out bits) and don't want to.  So the name would
be silly.

> ??? It doesn't take much work to make these changes. For the ones i
> suggested in the modernization article, it would take just one single
> elisp programer few hours to make all the suggested changes.

Hahahaha!!!!  Xah, it would would take hundreds of hours.

> Consider all the little problems here and there that might turn up when
> actually working into a final product, it might be a total of say, a
> week's work.

Not forgetting, of course, that Emacs wouldn't work afterwards.  You'd
have to add compatibility features by the hundred.  Otherwise, people's
elisp would stop working.  How many elisp libraries are there which don't
use variables/functions such as `current-buffer' or
`mode-line-buffer-identification', or ..... ?

[ .... ]

> ??? Emacs has kill-buffer, which asks users a buffer to kill, with a
> default suggestion for the current buffer. The Close menu command runs
> kill-this-buffer, which is what Close menu command is for in almost
> every application in Mac, Windows, Linux. The kill-this-buffer command
> closes the current buffer without asking (unless it is not saved, of
> course). The kill-this-buffer does not have a shortcut by default.

You mean a key binding, of course.  Except that it's bound to a menu item
in GUI systems.

The thing about the word "shortcut" is that it typically carries
disparaging overtones.  Also a "shortcut" is _never_ the canonical way to
do something.  Both of these facts make the term unsuitable for Emacs.

> The Close command doesn't have a default shortcut. In practice, i
> think it induced an operation habit to have hundreds of past buffers
> left open. The problem with leaving buffers is that it makes buffer
> listing/switching facilities much less useful. This is rather common
> complaint even among emacs old timers

Well, I'm not sure it is, but even so, anybody can customize their Emacs
if they find C-x k <ret> too tedious, as you have done.  I find C-x o too
tedious, so I've bound f12 to `other-buffer'.  What you've described is
your own problem, and how you've fixed it.  This it what Emacs's is all
about.  I had a problem moving easily between frames, so I've set up f1,
f2, ...., f11 to do frame-switching.  I don't have a problem with lots of
buffers being open.

> (i myself, being somewhat a classic nerd, adopted wholly emacs's ways
> and terms in the very beginning, using emacs in pure text terminal
> only for the first 5 years. However, i do have a habit to always close
> buffers once i've finished working with it. So, i always did C-k
> Return and find it too many keystrokes. Only in recent years of elisp
> study i had workaround with somewhat extensive self-made
> customization)

That's fine!  I do C-k <ret> seldom enough that having kill-buffer on a
single key would be a waste of a good key binding for me.

> ??? i do wish to keep gun.emacs.help to be very focused on technical Q&A
> and avoid opinions oriented discussions. I enjoy reading
> gnu.emacs.help that way, and i think comp.emacs can be more open to
> discussions and opinion oriented posts. What made me reply here was
> that posts that seems to want to emphasize the emacs ways as better
> way, which in my opinion, prevents the modernization of emacs.

??? I think you've got that the wrong way round.  Emacs strives to do
things the best way, not the most modern way.  "Modern" ways of doing
things are often far from optimal.  Also Emacs emphasises ease of use
over ease of learning, unlike many other products.  ???

>   Xah

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: basic question: going back to dired

[Phil Carmody]

Alan Mackenzie <acm@muc.de> writes:
> Hi, ???Xah!
>
> On Tue, Jul 22, 2008 at 01:44:27PM -0700, Xah wrote:
>> Hi all, instead of responding to each message in this thread, i
>> thought i just write one post.
>
>> ??? among the alternative terms for buffer: tabs, panel, window, work
>> space..., i think tabs is a good candidate.
>
> I think you mean "tab", the singular.  Why is "???tab" good.  Look up the
> word in a dictionary, and you'll find it's a bit of material or paper
> which sticks out so that you can hold of it easily.  Or it can mean a
> cigarette.  Do we really want to be manipulating sticky-out bits or
> cigarettes?
>
> "Buffer" means something which separates and smoothes interactions
> between things which would otherwise damage eachother; for example, the
> spring loaded pads on railway waggons which stop them jossling eachother
> too badly, or the "buffer zone" between two hostile countries which stop
> them killing eachother too much.  In Emacs, a buffer stops your changes
> being written directly onto hard disk sectors, so the name isn't too bad.

You might also have a savings account as a buffer to tide you
over. That's more of a pure storage connotation.

One of the *best* things about 'buffer' is that it's so nebulous.

Phil
-- 
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration

Re: basic question: going back to dired

[Xah]

Xah Lee wrote:
«I don't think its a good idea to teach or insist that people adopt
emacs's terminologies.»

Some people say that if you want to use emacs, you have to use emacs's
terminologies.

Yes that is true.

However, some terms are interchangable between emacs and other apps,
and some emacs terminology still can use some change to adopt the
changing world.

For example, if you are learning calculus, and you got confused by the
terminology of abscissa and ordinate. I say to you, that's just old
terms for x-axis and y-axis. However, there are still math professors,
who insist on the name abscissa and ordinate. The term x-axis and y-
axis, to them, is dumb'd down, not-general, technically incorrect.

This thread is over 100 now. In the coming days, i'll reply and give
reasons on why i think emacs are better to adapt new terms for buffer
and keybinding in its user manual.

Thanks for all the thoughts.

  Xah
∑ http://xahlee.org/

☄


On Jul 22, 5:50 am, Nikolaj Schumacher <n_schumac...@web.de> wrote:
> 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