Emacs cua-mode Problems
Emacs cua-mode Problems
This page discuss some issues about emacs cua-mode. In particular, problems in naming.
On const451 [const…@gmail.com] wrote:
Is there a plugin that uses standard key shortcuts for text manipulation such as Ctrl-C, Ctrl-V, Ctrl-Z, etc.? I think they are faster to use than the default shortcuts in emacs.
I run Ubuntu Lucid (newbie).
You can turn on cua-mode by 【Alt+x cua-mode】.
Or you can install the ErgoEmacs Keybinding, then it'll also support standard Open, Close, Save, Save As, New… shortcuts, about 7 of them.
The Naming of cua-mode
Emacs's cua-mode, is named after the IBM's Common User Accesss standard. However, according to Wikipedia IBM Common User Access the IBM CUA standard does not say cut/copy/paste are X C V keys. Quote:
The Cut command is Shift+Del; Copy is Ctrl+Ins; Paste is Shift+Ins;
The Z X C V keys for undo/cut/copy/paste is popularized by Apple starting in mid 1980s and by early 1990s it is widely known in the then new Desktop Publishing field.
Emacs's naming of cua-mode is very bad. Because:
- CUA name is not intuitive. Very few people know what CUA means. Among all people who makes a living by coding, i'd say less than 0.05% know what CUA means. Personally, i own and use Mac daily since 1991 to today, started my programing career in 1995, read ALL issues of Macworld , MacUser magazines in the 1990s till they closed doors. I never heard of CUA until using a GUI based emacs on the Mac in about 2005 (i use emacs daily in a text terminal since 1998).
- Emacs's cua-mode's behavior is not IBM's CUA standard at all. All it does is basically just the X C V keys, and these may not even be part of IBM's CUA.
Why was it named cua-mode?
Emacs's developers named it cua-mode probably because of a ego/cult problem. They needed a name for this widely needed mode, but naming it anything that might relate to Microsoft Windows or Apple is a political problem for the Free Software Foundation.
(note: Richard Stallman HATES Microsoft and also HATES Apple. GNU's stance against Microsoft is well known, from GNU/Richard's writings especially in 1990s. Richard has published several essays that advise programers to avoid mentioning the term Microsoft, as a political tactic for advancing GNU, and this is well known. Throughout 1990s, GNU boycotted Apple partly because Apple sued Microsoft for copying Apple's GUI interface. This boycott is officially ceased in around 1995. See: “End of Apple Boycott” from gnu.org GNU's Bulletin, vol. 1 no. 18 )
Better Naming
The cua-mode is probably better named XCV-mode or copy-paste-key-mode, and the menu name should be “XCV keys for Cut/Copy/Paste”. The mode name change is too late now, but the menu name change can still be done. The name “XCV keys for Cut/Copy/Paste” does not relate to any commercial organization, and is easy for people to understand what it means, and it more accurately describes what cua-mode do.
See also: Emacs Menu Usability Problem.
Missing Redo and Other Common Keys
The cua-mode also does not support Redo. (you'll need to installed the redo mode package) The conventional Redo is also frequently requested feature.
Nor does cua-mode support the other 8 standard shortcuts in practice: New “n”, Open “o”, Close “w”, Save “s”, Save As “Shift+s”, Select All “a”, Print “p”, Find “f”. These keys and Redo are standard across Microsoft/Mac/Linuxes today.
Intuitive Terminologies vs Emacs Conventions
plug-in/add-on vs library/package
On 2010-06-19, Evans Winner [tho…@unm.edu] wrote:
By the way, and just for your information, Emacs users typically do not call Emacs Lisp packages "plugins." More often they call them libraries or packages.
Calling it plug-in is not emacs convention but i think is very good terminology. It is intuitive, and widely used. For example, web browsers use the term plug-ins since ~1995. Mathematica, calls the language's packages/libraries as plug-ins or add-ons, when in a user/application context. Firefox also clarified a bit in their terminology of plug-in vs add-on about 1 or 2 years ago. For example: plug-in are those like Java, Flash, QuickTime engines, while add-on often are user interface oriented utilities.
Plug-in and add-on are intuitive terms that anyone can easily understand what they mean just by the words themselfs. While, package, library, module, are more oriented to software engineering in a technical context.
Keybinding vs Keyboard Shortcut
If the code implements a major or minor mode, they typically call it a "mode." They also usually don't use the term "shortcut," possibly because that seems to imply some other manner of input that is privileged over use of the keyboard. The phrase "key binding" is more often used, because that is what you do: you bind a function to a key or key combination.
Similar to the library/package/module vs plug-in/add-on argument, same applies here. The term “Keyboard shortcut” or “hotkey” is suitable in the context of users using a software application, while keybinding is suitable for programing and software engineering.
Keyboard shortcut is a better term also because it is the term used in Microsoft, Mac OS X, Linuxes today.
“keybinding” is in fact technically not correct in the user application context. When you press a key to invoke a command, you are not binding a key. Nor does it make sense to say that you are invoking or activating a “keybinding”. You are using a KEY that has a keybinding. The gist is that it is a user interface convenience, a sort of alias, therefore: shortcut, a shortcut through the keyboard, thus “keyboard shortcut”, is better than keybinding.
These distinctions are important.
I'm writing this because it is common in emacs community to bother new users about these kinda things. When the issue is about some technical aspects, such as elisp macros vs keyboard macros, such that using the wrong term leads to wrong results or confusion, then it is good. However, when fuzzing about a terminology that has little practical impact other than political, then i think it's harmful to emacs's health. It just turns away users and keep brewing the emacs cult. 〔see Emacs: Have You Read Emacs Manual? (2010)〕
Emacs Modernization
- Emacs Modernization: Simple Changes Emacs Should Adopt
- Why Emacs Keys are Painful
- Emacs: Problems of the Scratch Buffer
- Emacs Modernization: Meta Key Notation
- Emacs Menu Usability Problem
- Emacs Mode Line Problem
- Emacs cua-mode Problems
- Emacs: Inconsistency of Search Features
- Problems of grep in Emacs
- Emacs: Usability Problems of Mode Documentation
- Problems of Emacs Manual
- Emacs Manual Sucks by Examples
- Emacs: kill-buffer Induces Buffer Accumulation
- Emacs Spell Checker Problems
- Emacs: Form Feed ^L Problem
- Emacs: Single Key to Delete Whole Line
- Emacs HTML Mode Sucks
- Emacs Does Not Support Viewing Images Files In Windows
- Emacs Should Adopt HTML as Texinfo Replacement
- Emacs Should Support HTML Mail
- Problems of Emacs's “man” Command
- Emacs Lisp Mode Syntax Coloring Problem
- Emacs AutoHotkey Mode Problems
- Elisp: Ban Syntax Table
- Emacs: Make elisp-index-search use Current Symbol
- Emacs GNU Texinfo Problems; Invalid HTML
- A Record of Frustration in IT Industry; Disappearing FSF URLs, 2006
- Emacs Manual Node Persistency Issues
- Emacs: dired-do-query-replace-regex Replace ALL (fixed)
- Problems of Emacs Supporting Obsolete Systems
- Elisp: Function to Copy/Delete a Dir Recursively (fixed)
- Thoughts on Common Lisp Scheme Lisp Based Emacs
- Text Editors Popularity and Market Research
- Text Editor's Cursor Movement Behavior (emacs, vi, Notepad++)
- Emacs: Usability Problems of Letter-Case Changing Commands
- Emacs Select Word Command Problem
- Emacs: Search Current Word 🚀
- Emacs fill-paragraph Problem