Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[David Kastrup]

Lennart Borgman <address@hidden> writes:

> On Sat, Jan 18, 2014 at 11:02 AM, David Kastrup <address@hidden> wrote:
>
>> Lennart Borgman <address@hidden> writes:

>> > I guess that we are really discussing is if there is an advantage of
>> > such a setup. In the light of that there was a whole new editor
>> > (gedit) created I think there could have been a better route. Emacs
>> > could probably have provided everything that gedit gives.
>> >
>> > I also guess it would have been less work. And there would have been a
>> > larger community using and working on Emacs.
>>
>> The future of Emacs depends on people with an attention span and
>> perseverence sufficient for extending it.  Those are the people who are
>> most likely to be annoyed at the inconsistency of concepts and
>> operations of things like the full CUA mode (the one which uses
>> heuristics to decide whether to use C-x and C-c in the Emacs or the CUA
>> sense).
>
> Are you really sure you want to look down upon those that do not
> agree? ;-)

It's not a question on looking up or down.  Let me quote from the CUA
mode section in the Emacs manual:

    The command ‘M-x cua-mode’ sets up key bindings that are compatible with
    the Common User Access (CUA) system used in many other applications.

       When CUA mode is enabled, the keys ‘C-x’, ‘C-c’, ‘C-v’, and ‘C-z’
    invoke commands that cut (kill), copy, paste (yank), and undo
    respectively.  The ‘C-x’ and ‘C-c’ keys perform cut and copy only if the
    region is active.  Otherwise, they still act as prefix keys, so that
    standard Emacs commands like ‘C-x C-c’ still work.  Note that this means
    the variable ‘mark-even-if-inactive’ has no effect for ‘C-x’ and ‘C-c’
    (*note Using Region::).

       To enter an Emacs command like ‘C-x C-f’ while the mark is active,
    use one of the following methods: either hold ‘Shift’ together with the
    prefix key, e.g., ‘S-C-x C-f’, or quickly type the prefix key twice,
    e.g., ‘C-x C-x C-f’.

Now this is touted as a feature to make things _simple_ for people.  In
reality, _competent_ use of it requires _lots_ of learning and
surprises.  If I enable CUA mode and type C-h k C-x C-c, I read

    C-x C-c runs the command save-buffers-kill-terminal, which is an
    interactive compiled Lisp function in `files.el'.

    It is bound to C-x C-c, <menu-bar> <file> <exit-emacs>.

    (save-buffers-kill-terminal &optional ARG)

    Offer to save each buffer, then kill the current connection.
    If the current frame has no client, kill Emacs itself.

    With prefix ARG, silently save all file-visiting buffers, then kill.

    If emacsclient was started with a list of filenames to edit, then
    only these files will be asked to be saved.

    [back]

But if there is an active region, C-h k C-x prints

    C-x runs the command cua--prefix-override-handler, which is an
    interactive compiled Lisp function in `cua-base.el'.

    It is bound to C-c, C-x.

    (cua--prefix-override-handler ARG)

    Start timer waiting for prefix key to be followed by another key.
    Repeating prefix key when region is active works as a single prefix key.

    [back]

This kind of mode dependency is what Emacs proponents in the editor wars
tend to describe as a disadvantage of vi.

This kind of "do the expected thing" setup may delay the time until
cursory Emacs users will hit a wall of learning.  But when they do, the
wall is higher.

This puts a larger complexity gap between "simple users" and "power
users or programmers" who actually can work their tool with confidence.

I don't see that making Emacs fit the Gedit task space would have
yielded a result where Gedmacs users would have grown into active
participants of the Emacs universe.

In the long run, we need to make sure that Emacs remains comprehensible
to Emacs users.  That does not preclude changing keybindings and
concepts, but getting multiple concurrent warring keybindings and
concepts sorted by various heuristics is not the way to simplicity.

-- 
David Kastrup