The emacs ergonomic keybinding project is now on Google Code.
See:
http://code.google.com/p/ergoemacs/
http://xahlee.org/emacs/ergonomic_emacs_keybinding.html
Thanks for any comments and suggestions.
Xah
∑ http://xahlee.org/
☄
"Xah Lee" <······@gmail.com> wrote...
> The emacs ergonomic keybinding project is now on Google Code.
> http://code.google.com/p/ergoemacs/
> http://xahlee.org/emacs/ergonomic_emacs_keybinding.html
>
> Thanks for any comments and suggestions.
Hello Xah, what do you think of a different approach to this that brings in
a ready-made set of users: vim-like keys for getting better ergonomics?
(Without going to viper.)
Thought you might be interested in hearing about this: I'm doing my own
version of something similar, but trying to reuse vim keybinding
finger-memory as much as possible.
I don't like viper b/c it takes you more completely out of a normal emacs
interaction, and I want to preserve the good aspects of emacs interaction as
much as possible. So I've tried to come up with a compromise that makes
emacs more ergonomic while not stomping on important default keybindings and
still retaining a normal emacs interaction. For instance, I will not stomp
on C-x - that's too important.
So far working well enough that I feel I can now edit with pretty good
comfort to my fingers.
Of course I have no place for C-x, C-c, C-v for another reason: Ctrl is much
harder to press for me than Alt, so I do not consider C-x ergonomic.
So, for example, M-j means down one line. M-k means up one line, M-l means
right and M-h means left. This also means I can just hold down Alt on the
left side of the keyboard and pretend I'm in vim with my right hand, when
using these keys.
But it's much more than those 4. It's maybe 20-30 keybindings, I'd
estimate, including ones to emulate "visual mode" commands.
So far it doesn't seem to have alot of conflicts with *useful* things,
though it does conflict with some fairly useless emacs functionality (I
tried to evaluate every bit of default keybindings, though this is not
complete yet in all the modes I may care about).
It also works the same on xemacs or emacs.
On Jan 22, 7:36 pm, "wlcna" <·····@nospam.invalid> wrote:
> "Xah Lee" <······@gmail.com> wrote...
> > The emacs ergonomic keybinding project is now on Google Code.
> >http://code.google.com/p/ergoemacs/
> >http://xahlee.org/emacs/ergonomic_emacs_keybinding.html
>
> > Thanks for any comments and suggestions.
>
> Hello Xah, what do you think of a different approach to this that brings in
> a ready-made set of users: vim-like keys for getting better ergonomics?
> (Without going to viper.)
>
> Thought you might be interested in hearing about this: I'm doing my own
> version of something similar, but trying to reuse vim keybinding
> finger-memory as much as possible.
>
> I don't like viper b/c it takes you more completely out of a normal emacs
> interaction, and I want to preserve the good aspects of emacs interaction as
> much as possible. So I've tried to come up with a compromise that makes
> emacs more ergonomic while not stomping on important default keybindings and
> still retaining a normal emacs interaction. For instance, I will not stomp
> on C-x - that's too important.
>
> So far working well enough that I feel I can now edit with pretty good
> comfort to my fingers.
>
> Of course I have no place for C-x, C-c, C-v for another reason: Ctrl is much
> harder to press for me than Alt, so I do not consider C-x ergonomic.
>
> So, for example, M-j means down one line. M-k means up one line, M-l means
> right and M-h means left. This also means I can just hold down Alt on the
> left side of the keyboard and pretend I'm in vim with my right hand, when
> using these keys.
>
> But it's much more than those 4. It's maybe 20-30 keybindings, I'd
> estimate, including ones to emulate "visual mode" commands.
>
> So far it doesn't seem to have alot of conflicts with *useful* things,
> though it does conflict with some fairly useless emacs functionality (I
> tried to evaluate every bit of default keybindings, though this is not
> complete yet in all the modes I may care about).
>
> It also works the same on xemacs or emacs.
Maybe you can give us the file ? I am interested in what you do.
Thanks
Cédric
<···············@gmail.com> wrote...
> Maybe you can give us the file ? I am interested in what you do.
Thanks, I doubt many other emacs users are, though maybe I'm wrong as they
do seem like a somewhat diverse group, connecting to emacs for a wide
variety of reasons. Like me, I'm basically only using emacs b/c it can
serve as an IDE to gcc.
But yeah, I can upload what I've settled on so far; give me a day or so.
I'd upload very simple stuff probably, like just the "global-set-key" things
I've settled on right now instead of my whole startup file, but maybe I'll
just do the whole file because there's some routines in there that are
helpful too... But you can see whatever it's worth for you. Mostly it's
been a matter of deciding what to use and I've been exclusively using
global-set-key, which doesn't always work if the mode overrides a key, but
I've been fortunate that all these keys seem to work in info mode, c-mode
and lisp mode just the same, so the global thing seems to be fine for I
think all of the ones I'm using.
It's lucky for me that emacs has alot of really almost entirely useless key
combinations in the Alt- combinations, perhaps partly because of course
Windows has its own ideas as to what should happen when you hit Alt, and
emacs of course violates that, and I imagine probably people don't really
want to step on those in case someday emacs is to work better with Windows.
Maybe that's it? But for now I'm utilizing Alt heavily and that using Alt
becomes "the key" to it working without much conflict because there aren't
many useful keys there to worry about. At least that's the way it seems so
far. Ctrl would be more problematic.
I have to tell you though these are fairly untested and I haven't used these
all that much because frankly I don't particularly like emacs still compared
to vim as an editor, not to mention I have basic difficulties that at this
point will reduce emacs to still just a very secondary editor for me, though
it's a little bit more livable now. I love the fact that emacs is an
environment rather than "just an editor," where vim is just an editor, and
that's why I'm sticking it out with emacs and will continue to...
So have another post a bit later.
On Jan 22, 10:36 am, "wlcna" <·····@nospam.invalid> wrote:
> "Xah Lee" <······@gmail.com> wrote...
> > The emacs ergonomic keybinding project is now on Google Code.
> >http://code.google.com/p/ergoemacs/
> >http://xahlee.org/emacs/ergonomic_emacs_keybinding.html
>
> > Thanks for any comments and suggestions.
>
> Hello Xah, what do you think of a different approach to this that brings in
> a ready-made set of users: vim-like keys for getting better ergonomics?
> (Without going to viper.)
>
> Thought you might be interested in hearing about this: I'm doing my own
> version of something similar, but trying to reuse vim keybinding
> finger-memory as much as possible.
>
> I don't like viper b/c it takes you more completely out of a normal emacs
> interaction, and I want to preserve the good aspects of emacs interaction as
> much as possible. So I've tried to come up with a compromise that makes
> emacs more ergonomic while not stomping on important default keybindings and
> still retaining a normal emacs interaction. For instance, I will not stomp
> on C-x - that's too important.
>
> So far working well enough that I feel I can now edit with pretty good
> comfort to my fingers.
>
> Of course I have no place for C-x, C-c, C-v for another reason: Ctrl is much
> harder to press for me than Alt, so I do not consider C-x ergonomic.
>
> So, for example, M-j means down one line. M-k means up one line, M-l means
> right and M-h means left. This also means I can just hold down Alt on the
> left side of the keyboard and pretend I'm in vim with my right hand, when
> using these keys.
>
> But it's much more than those 4. It's maybe 20-30 keybindings, I'd
> estimate, including ones to emulate "visual mode" commands.
>
> So far it doesn't seem to have alot of conflicts with *useful* things,
> though it does conflict with some fairly useless emacs functionality (I
> tried to evaluate every bit of default keybindings, though this is not
> complete yet in all the modes I may care about).
>
> It also works the same on xemacs or emacs.
vi was lucky. The primarily, if not only, keys choices that deserve to
be called ergonomic for vi is the single char cursor movements being j
k l h.
h j k l
← ↓ ↑ →
these are the most frequently used commands (roughly
40% of all command calls). vi was lucky because the keyboard vi was
developed on, the ADM-3A terminal, has these keys as cursor movers
with arrows labels on them.
http://en.wikipedia.org/wiki/Vi
http://en.wikipedia.org/wiki/ADM3A
However, ergonomically speaking,
H J K L is inferior to a inverted T layout for arrows:
I
J K L
The reasons are:
• Both has one key that's not a home key. It's the H and I. However, H
is a noticably more costy to press than I, since H involves shift the
whole hand a bit, while I is extending the middle finger, the longest
finger. (when testing which key being more ergonomic, you can test
yourself by pressing the keys repeatedly say 100 times or until you
notice tiredness. It wouldn't be the same for everyone but gives a
good indication.)
• The arrow arrangement ← ↓ ↑ → is less intuitive than a inverted T.
If arrows are to be arranged on a line, modern study indicates that ↓
↑ ← → is more natural, and this is commonly adopted in many labtops or
keyboards that doesn't have a separate pad for arrow keys. (↓ ↑ ← →
on jkl; would be a improvement because up/down arrows are
significantly used more than left/right. check my website for the
stats)
I thought of using ↓ ↑ ← → on jkl; with alt down for emacs in my map.
But desided inverted T is slightly better. With jkl; , the pinky is
put to use heavily. (try pressing ←→ with l; few hundred times.) With
inverted T, the 3 fingers work on ←↓→. Also, there's some ease of
adoption with inverted T because the keys corresponds to the movement
like the physical arrow key section. Also, one can add on to it with
Shift for example for page up/down, or moving to doc's beginning/
ending.
Besides ergonomic aspect, there is also aspect for what people already
know. If a lot people already know vi, and it might be good to adopt
these arrow to emacs when redesigning emacs arrow keys. Sacrificing
some perfection with easy adoption. But i didn't find vi to be widely
adopted. Vi, together with emacs, today are used perhaps by less than
0.5% of professional computer programers. (i.e. those who's main
income came from programing)
For your mapping, you might also consider a version for Dvorak.
As soon as i posted the ergoemacs keys on google code, people are
complaining that i don't have a colemak version. Technically, if you
check website studies (i know at least 2 good sites), Colemak is
something like 1% better than dvorak. (if you switch tested text,
different language, or measuring different aspect of what's meant by
“better”, it all changes) However, looking at the Colemak site, it
appears to me the author is mostly concerned about putting his name
forward (his name is Colemak). I think introducing Colemak is rather a
deservice. (one person sent me a elisp for Colemak, i've put it up for
those interested)
Keyboard layout designing is one of those things lots of whacky
hobbiest do, such as constructed language (for humans, e.g. lojan),
computer languages. If you do some research, you'll find some weird
ones out there, each usually claim better, either seriously or as I
DID IT TOO. I've seen ones that comes with elaborate report or
academic thesis as why they are better. The report appears to me a
sales pitch. Some are patented.
Xah
∑ http://xahlee.org/
☄
On Jan 22, 12:55 pm, Xah Lee <······@gmail.com> wrote:
> • The arrow arrangement ← ↓ ↑ → is less intuitive than a inverted T.
> If arrows are to be arranged on a line, modern study indicates that ↓
> ↑ ← → is more natural, and this is commonly adopted in many labtops or
> keyboards that doesn't have a separate pad for arrow keys. (↓ ↑ ← →
> on jkl; would be a improvement because up/down arrows are
> significantly used more than left/right. check my website for the
> stats)
i thought i make a mistake in stating the paragraph in my previous
post.
because if vi changed its:
h j k l
← ↓ ↑ →
to
j k l ;
↓ ↑ ← →
i thought it would be worse. But in the process of writing this
“correction”, i dig up my numbers... it turns out, the change would
possibly only be marginally worse, if at all.
The distribution for the single char cursor moving commands with
respect to their total is this:
↓ 0.444362017804
↑ 0.350834569733
→ 0.123330860534
← 0.0814725519288
From the above, you can see that the up/down is heavily used by far
among the arrow commands. In either setup, the up/down arrow placement
are the same. The diff is with the left/right. You'll note the right
arrow cmd is used just slightly more. In the vi default setup, the
right arrow cmd is ring finger. In the new setup with “jkl;”, the
right arrow becomes pinky. So, it is worse, however, the left arrow is
better in the new, because it is on the home key while vi default has
it on h, which is a biggish punishment involving slight shift of hand
or lateral move of index finger.
For some detail of the stat, see:
• Emacs's Command Frequency
http://xahlee.org/emacs/command-frequency.html
you can download the command-frequency.el there to compile your own
usage stat.
Xah
∑ http://xahlee.org/
☄
On Jan 22, 10:36 am, "wlcna" <·····@nospam.invalid> wrote:
> "Xah Lee" <······@gmail.com> wrote...
> > The emacs ergonomic keybinding project is now on Google Code.
> >http://code.google.com/p/ergoemacs/
> >http://xahlee.org/emacs/ergonomic_emacs_keybinding.html
>
> > Thanks for any comments and suggestions.
>
> Hello Xah, what do you think of a different approach to this that brings in
> a ready-made set of users: vim-like keys for getting better ergonomics?
> (Without going to viper.)
in my previous post, i indicate how vi's default setup for the arrows
is inferior to a inverted T setup, or a linear setup but using
j k l ;
↓ ↑ ← →
instead of
h j k l
← ↓ ↑ →
However, the interesting point about vi is its so-called mode oriented
editing method. Namely, you toggle between a editing mode and command
mode. At any moment, you are in one of these mode. In editing mode,
you type to insert letters. While the command mode, whatever you type
is taken as a command for cursor moving, deleting text, searching, or
anything else.
Overall, i think this not a sustainable method for text editors,
mostly because it is not intuitive. This mode-based operation
effectively rules out vast majority of users, leaving it for elite
programer only.
The question now is, among elite programers, who are willing to spend
a lot time to adopt methods for the sake of efficiency, is mode-based
operation more efficient than the more standard operation?
i haven't done much research on this... here's some thoughts:
• it is my feeling that mode based has lots of problems as a
interface... it's hard to carry over with consistancy over diverse
tasks like opening different files, split windows, switch windows/
panes/frames... for example, let's say you are in command mode. Now,
in command mode you simply press delete key to delete or cursor key to
move. In a sense, it is inconsistant. Rather, one might have again 2
modes while in command mode to be more consistant overall.
• vi being the way it is, is largely due to history, not some concious
decision of design over all possibilities. Historical reasons over
concious explicit design is so for much of unix, including emacs. More
specifically, vi being that way is because it was a improvement over
“line editor”.
People simply adopted historical baggages, often without thinking, to
the point that the habituation made them think that whatever they
adopted should be the proper or superior way. When you look at things
scientifically, much of it has no basis. Change are often brought on
by later generations, who chooses or think whatever is best in their
own personal experience, and the previous generation's things mostly
didn't enter their consciousness. This is often how society and
technology things evolve. Often, the old timers tend to sneer at these
new generation or youngsters as being trivial fashion, until
themselves gradually die out. This applies not just to computer
software, but to lots of things... math notations, roman numeral →
arabic number notation, slider rule or abacus → electronic calculator,
credit cards, typewriters → word-processor machine → word-processor
software, ... of course this doesn't imply whatever new kid on the
block things are best... nor are they often better, but does
illustrate the mentalities of many who insist the “emacs way”, “lisp
way”, “mouse is for sissies”, “ascii should be used for mail”, “plain
text should be used for mail”, anti-MIME movement, anti web based
email movement, “websites with graphics are stupid”, “CSS/Javascript
web sites are stupid”, “IM chat are fashionable stupidity”, “flash
website and youtube are worthless shit”... these happens in the recent
past 15 years roughly in chronigical order, and some old tech geekers
still think that way, really. (for example, in 2008, there are several
number of flame war threads on gnu.emacs.help, insisting html mail is
stupid or emacs sholdn't support it. And in emacs dev list, you can
see some claim that youtube/flash is worthless shit that clog
networks. And every few months you see geekers bitch about using
unicode in newsgroup and insist ascii should be used.)
Xah
∑ http://xahlee.org/
☄
here's my own usage of emacs commands.
From 2008-08-30 to 2009-01-23.
here's a list of the top 30 most used commands.
1119668 45.96% self-insert-command
203404 8.35% next-line
148571 6.10% previous-line
146318 6.01% forward-word
116557 4.78% backward-word
46370 1.90% delete-backward-char
44569 1.83% isearch-printing-char
41315 1.70% forward-char
36771 1.51% backward-char
36692 1.51% backward-kill-word
33890 1.39% newline
22912 0.94% save-buffer
22247 0.91% yank
18696 0.77% mwheel-scroll
18031 0.74% kill-line
16647 0.68% close-current-buffer
13485 0.55% move-beginning-of-line
13029 0.53% scroll-up
11420 0.47% isearch-forward
11380 0.47% isearch-other-meta-char
10840 0.44% kill-word
10363 0.43% set-mark-command
10349 0.42% isearch-repeat-forward
10256 0.42% find-file
10037 0.41% execute-extended-command
9328 0.38% move-cursor-next-pane
9012 0.37% forward-paragraph
8715 0.36% scroll-down
8612 0.35% delete-char
7776 0.32% backward-paragraph
7370 0.30% undo
compared to my previous stat compilation with 2 other emacs users
http://xahlee.org/emacs/command-frequency.html
(smaller data points)
i think that the top 10 most used commands are probably the same for
vast majority emacs users, and the ordering & distribution for the top
10 commands is prob roughly the same too.
Xah
∑ http://xahlee.org/
☄
"Xah Lee" <······@gmail.com> wrote...
> On Jan 22, 10:36 am, "wlcna" <·····@nospam.invalid> wrote:
> > Hello Xah, what do you think of a different approach to this that brings
> > in
> > a ready-made set of users: vim-like keys for getting better ergonomics?
>
> However, the interesting point about vi is its so-called mode oriented
> ...
Hey Xah!
> Overall, i think this not a sustainable method for text editors,
> mostly because it is not intuitive. This mode-based operation
> effectively rules out vast majority of users, leaving it for elite
> programer only.
>
Just FYI, my customizations to emacs leave it non-mode-based of course, but
command keys similar to vim regular keys. These command keys are all "two
handers" in the sense that you have to hold down alt with say left hand and
hit the key with the right (or vice-versa), or at least that's how I use
them.
Anyone can learn anything if it's useful and worthy of learning (excluding
pathological cases). Vi/vim are used by programmers exclusively because the
rest of the world does not deal with pure text files. Programmers
exclusively deal with pure text files, so are in the market for a pure text
editor. Rest of the world isn't.
> The question now is, among elite programers, who are willing to spend
> a lot time to adopt methods for the sake of efficiency, is mode-based
> operation more efficient than the more standard operation?
Yeah, that's a good question.
> i haven't done much research on this... here's some thoughts:
>
> • it is my feeling that mode based has lots of problems as a
> interface... it's hard to carry over with consistancy over diverse
> tasks like opening different files, split windows, switch windows/
> panes/frames... for example, let's say you are in command mode. Now,
> in command mode you simply press delete key to delete or cursor key to
> move. In a sense, it is inconsistant. Rather, one might have again 2
> modes while in command mode to be more consistant overall.
>
I don't entirely understand the above, but you do know that you don't use
cursor keys in vi/vim - that's the whole point you might say.
But if you mean that in vim the "j" key can mean "move cursor down one line"
or it can mean "j," that's not a huge problem. Just like Ctrl-x can mean
cut, but x means "x." People have no problem with that. In vi/vim because
of the modes you have this learning curve though because "j" means
"different things at different times" issue, but that is essentially
resolved by "command mode" being the default mode when using vim. I.e.
experienced users always return to command mode after typing something in,
and always therefore know they are in command mode unless they are at this
very moment typing text in.
> • vi being the way it is, is largely due to history, not some concious
> decision of design over all possibilities. Historical reasons over
> concious explicit design is so for much of unix, including emacs. More
> specifically, vi being that way is because it was a improvement over
> “line editor”.
>
But that doesn't assess its worth as an editing method.
Historical chance is an argument about arbitrary conventions, right? But
vi/vim is entirely alone in its category of mode-based text editing (so far
as I know), and as such vim has no competitors and so whether its
conventions are good or bad is somewhat irrelevant since there is no
competition with different conventions.
It comes down to your original question - is mode-based editing more
efficient.
There can be no doubt that it is better at a wide variety of editing tasks.
> People simply adopted historical baggages, often without thinking, to
> the point that the habituation made them think that whatever they
> adopted should be the proper or superior way. When you look at things
A command-mode editor is just a completely different beast. It's not an
"arbitrary convention" like File menu = F1 that you can just toss in the
garbage dump. It's a different idea of how an editor works. To those who
say it has great value, it's a completely different idea of what an editor
*should be.*
> scientifically, much of it has no basis. Change are often brought on
> by later generations, who chooses or think whatever is best in their
> own personal experience, and the previous generation's things mostly
> didn't enter their consciousness. This is often how society and
> technology things evolve.
OK. That doesn't argue value though. Clearly ignorant sons might take a
new path that is a stupid path.
In the tech world to this point, there isn't generally even time to consider
these things since change happens so quickly.
But the question here is relative merit and value to human beings, not who
is on the right bandwagon.
> Often, the old timers tend to sneer at these
> new generation or youngsters as being trivial fashion, until
> themselves gradually die out.
This is a bandwagon argument again. You have to argue merit.
Now in the tech world, the avoid the "old timers" bandwagon argument you
make usually is correct, since change happens so quickly. But that doesn't
mean you can apply that argument to anything that has some history.
> This applies not just to computer
> software, but to lots of things... math notations, roman numeral ?
> arabic number notation, slider rule or abacus ? electronic calculator,
> credit cards, typewriters ? word-processor machine ? word-processor
> software, ... of course this doesn't imply whatever new kid on the
> block things are best... nor are they often better, but does
> illustrate the mentalities of many who insist the “emacs way”, “lisp
> way”, “mouse is for sissies”, “ascii should be used for mail”, “plain
> text should be used for mail”, anti-MIME movement, anti web based
> email movement, “websites with graphics are stupid”, “CSS/Javascript
> web sites are stupid”, “IM chat are fashionable stupidity”, “flash
> website and youtube are worthless shit”... these happens in the recent
> past 15 years roughly in chronigical order, and some old tech geekers
> still think that way, really.
You're talking about the difficulty of changing habits in adults I'd say and
"it's hard to teach an old dog new tricks."
That's not the same argument as the worth of particular old things versus
the worth of particular new things.
Lumping them together amounts to a "bandwagon" advertisement strategy.
Admittedly in the tech world, many old things fall by the wayside.
But occasionally the youngest generation rediscovers valuable things of the
oldest generation that have been lost by ignorant sons.
> (for example, in 2008, there are several
> number of flame war threads on gnu.emacs.help, insisting html mail is
> stupid
I believe html mail is annoying unless you're sending me pictures of
something or specifically need html for some reason.
Now don't get me wrong: when you *need* styled text or pictures, html in
email is fantastic.
But especially in this day of reading email on compact devices with tiny
screens, there's alot of sense in simple text unless you really need html.
> or emacs sholdn't support it. And in emacs dev list, you can
Perhaps emacs should stop being an email reader. If it doesn't support
html, makes it difficult nowadays. Emacs really can't afford more bloat and
having a full-blown html browser in it. And then html mail as a default
when there's no particular need for it is a little annoying. I haven't used
the emacs mail reader today, but I gather it's a bit irrelevant because of
html mail. Not so for newsgroups though, where text should still reign, in
my view. But even with newsgroups, I could see the argument for converting
the entire world of newsgroups over to html. Might bring in more people. I
can see some of these newsgroups have very little content now. In a way
that's nice actually, because there is "enough" content and not too much and
spam doesn't seem such a big problem, but of course it's a danger too that
newsgroups die out.
> see some claim that youtube/flash is worthless shit that clog
> networks.
Youtube as a particular thing is mostly garbage, just like most TV is
garbage, and always will be garbage. Old timers or new timers who say TV is
garbage are not wrong. Youtube is 95% garbage, but the 5% you can't
dismiss, and youtube is here to stay, garbage or not.
But as to the networks, it's back to the "changing habits" argument perhaps.
Network admins don't like having to accomodate large amounts of new
bandwidth, especially ones with questionable worth.
> And every few months you see geekers bitch about using
> unicode in newsgroup and insist ascii should be used.)
Newsgroups are still for pure text in my view, but I agree with you that
unicode should be standardized. But perhaps in some very friendly to ascii
way, like UTF8.
Back to the general argument though, I've been a "true believer" in
bitmapped displays and mouses since they started and remember the times when
most of the world wasn't.
And I have switched to using vim from using other GUI editors for plain
text.
Vim as pure text editor kicks ass on anything else I've used and learning it
has been a significant addition to my life, even beyond programming.
Emacs has the ability to add to people's lives too in additional ways, due
to being an environment rather than just an editor.
And with emacs if you don't like the way it works, you can more easily than
any other editor change things.
ASIDE:
Now one problem is that customization in emacs does have limits unlike the
myth that everything can be changed, because the entire editor is not
implemented in lisp, and for some things you run into the dreaded
"implemented in C source code."
I personally have found this and it's limiting my ability to use emacs. One
small example is sending the WM_SYSCOMMAND message. Emacs let's you send
this window message, but with a tight glove over what you can do, only
allowing you to supply one argument when the message has two, preventing you
from doing many useful things. I would think it would be in the spirit of
emacs to let you send any native win32 windows message to the frame window
that the user wants to. This could easily be accomplished. It would lead
to danger in the sense that the elisp programmer is not in a position to
supply some of the argumetn values, but who cares, it would open up the
system. Crashes would be the editor user's problem who is trying to mess
with these things. And obviously sending win32 messages would only work on
windows. But you already have things in emacs that only work on windows,
like sending that WM_SYSCOMMAND message, which emacs does let you do. But
opening up the system for the editor user. That's the spirit of emacs.
Even if it means the editor user can crash emacs.
A better foundation might benefit emacs, but the foundation there seems
"OK." Nothing is perfect.
> Xah
> http://xahlee.org/
On 2009-01-23, Xah Lee <······@gmail.com> wrote:
> However, the interesting point about vi is its so-called mode oriented
> editing method. Namely, you toggle between a editing mode and command
> mode. At any moment, you are in one of these mode. In editing mode,
> you type to insert letters. While the command mode, whatever you type
> is taken as a command for cursor moving, deleting text, searching, or
> anything else.
It's better to regard vi as a state machine that starts in a /single/ initial
state and accepts various kinds of commands, some of which consist of an
arbitrary amount of input that must be terminated by <Esc> or <Enter>. Of
course it has state transitions while accepting those and other commands.
Any problem with the modality is a self-inflicted one, by users who do not
terminate their commands to return to the initial state.
So in vi, if you begin an insert command by typing <i>, but then
don't complete it by typing <Esc>, of course it stays in a state
where it accepts more input for that command. Seasoned vi users
finish their inserts by hitting <Esc> as a matter of habit.
Likewise, if you start a command in Emacs, but don't finish it, then it stays
in a ``mode'' where it expects you to finish the command, just like vi. The
same is true of every text editor in existence which has some commands that
consist of multiple characters that must be collected. If you type just the
prefix of such a command, then the editor sits there, waiting for the suffix.
What happens in Emacs if you type C-x, and then go to the washroom
and come back, having forgotten that you typed C-x? Is it not in a state,
i.e. mode, such that if you now type C-c, it will terminate, which will not
happen if you type C-c in the initial state?
Your clue is that there is a "C-x" displayed at the bottom of the screen,
if you happen to notice. Well, your vi editor perhaps also has a newbie mode
in which a reminder is displayed in the status line that you are in the middle
of a command, like ":set showmode" in Vim.
Oh the pitiful ignorance of those who complain about vi ``modes''.
To have no stateful behavior in an editor would require all commands to be
single keystrokes (or chords with modifiers like Ctrl, Alt, etc). This may be
practical in a purely GUI text editor that doesn't have a convenient keyboard
shortcut for everything (and is therefore horribly inefficient to use for
advanced users). Oh, and that GUI editor better not have any modal dialogs,
otherwise it's modal, just like vi. E.g. invoke a modal find/replace dialog,
and you have to dismiss it before you can run other commands or enter text.
But of course I'm just sticking up for the fucking unix establishment
fuckheads, right Xah? :)