The Modernization of Emacs: terminology buffer and keybinding

[Twisted]

On Jun 24, 6:52 pm, Robert Uhl <eadmun... at NOSPAMgmail.com> wrote:
> > Really? None of [navigating a folder window analogue] happens if
> > you just do the straightforward file-open command, which should
> > obviously at least provide a navigable directory tree, but
> > definitely does not.
>
> The first does.  Really, it does.  Fire up emacs (which you've never
> done before) and type C-x C-f.

Whoa, Nellie. I seem to recall we were discussing the file-open
command.
That was something else, like C-x C-o or something. More apples-and-
oranges?

> You will be presented with a prompt
> something like 'Find file: ~/'; hit tab once; you'll see the message
> '[Complete, but not unique]'; hit tab again and you will be presented a
> list of all files in that directory.

Sounds clunky anyway. I don't need a bunch of keypresses to do the
equivalent in an Explorer-based file-open dialog in a native Windows
app. Just a double-click.

Emacs, with your C-x C-f:
C-x C-f tab tab             ("Startofnameofdirectory somethingElse
otherstuff")
Startofname tab tab         ("Subdirectory anotherSubdirectory")
Subd tab tab

Windows:
Alt, f, o                   ("Startofnameofdirectory somethingElse
otherstuff")
Click-click
  or Startofname-down-enter ("Subdirectory anotherSubdirectory")
Click-click
  or Subd-down-enter

Worst case (all keyboard): one fewer keypress. Best case (judicious
use of the mouse and smart hand placement, one by left alt and one on
the mouse): five TOTAL gestures.

In particular, C-x C-f tab tab is replaced by alt f o (four down to
three keypresses) or click file, click open (two instead of three
inputs, but you have to locate the File menu from halfway across the
screen with the pointer, so count it as three as well).

Being able to pick an item from a list just by touching the damn thing
instead of typing in a sufficiently long prefix is definitely an
advantage, and if a lot of things share the same 16-character prefix
in a particular directory, the emacs way starts to look SLOW.

Of course, there's an even faster Windows way, if you don't mind not
seeing lists of possible items:
Alt, f, o
Startofname-down-/-Subd-down-/

Straight to the subdirectory without waiting for it to display the
parent directory or the root. Same number of inputs. And of course
there's the super-fast
Alt, f, o, C-v, enter
if you happen to have the exact path in the clipboard already. I'd
like to see emacs do that, at least if the text to paste originated
outside emacs. (If I'm doing this in Winword's file open dialog it
could have originated in Notepad, Firefox, or just about anywhere
else, not just Winword.)

> If you like 'em, though, just select File:Visit New File.  It gives you
> a platform-default (gtk+, for me) file selector.

Now we're talking about a graphical port instead of stock emacs
again. :P

> Nope, because of the way emacs works you can stop what you're doing, do
> something else and come back to the minibuffer.

After spending a while brushing up on my Tibetan, I may or may not
agree, but until I've got some real meaning out of your use of jargon
like "minibuffer", I'll have to pass on this one. Nonetheless, stuff
you can do but can't know you can do without learning Tibetan is
unlikely to be of much help to the average user. :)

> Fortunately, folks brighter than you & I have imagined a nice way for
> us.  It pops up a new Emacs window (pane, if you prefer the terminology)
> showing a list of all filenames.  You could continue typing, or just
> click on a filename in the window, or hit return while the cursor is on
> a filename in that window.

Back to discussing a graphical port again. Besides the apples and
oranges issue, this amounts to implementing a dodgy imitation of a
file open dialog anyway. Why bother with such an imitation when you
can use a natively-GUI editor written for your platform and get access
to the real thing?