h a l f b a k e r yThis product is not intended to diagnose, treat, cure or prevent any disease.
add, search, annotate, link, view, overview, recent, by name, best, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
The shift key is a holdover from the
original mechanical typewriter. (as is
QUERTY)
This change would have to be
implemented at the operating system level
(or at the application level in Windows,
where consistency is optional.)
To enter 'a' type [a]. To enter 'A' type
[a][shift].
Note:
That [shift] key was pressed alone,
while the cursor was after the 'a' that was
typed. In today's OS's pressing the shift
key alone does nothing, but keyboards will
send a key-press signal. (If you have a
keyboard that does not, then it will not
work with this hypothetical OS).
Place the cursor after 'and '. Type [shift].
The text is edited to 'And '. Type [shift]
again. The text is edited to 'AND '. Once
more, and you are back to 'and '.
Place the cursor after 'my big idea. '. Type
[shift]. The text is edited to 'My big idea. '.
Type [shift] again. The text is edited to 'My
Big Idea. '. Type [shift] again. The text is
edited to 'MY BIG IDEA. '. Once more, and
you are back to 'my big idea. '.
In those last two examples, note that the
cursor was placed after a space and after a
period-space, respectively.
A similar treatment of the other modifier
keys: control, alt, option, command, meta,
etc. frees them up to become more
powerful also.
RPN
http://www.calculator.org/RPN.html
[apnea, Aug 25 2008]
FORTH programming
http://zforth.com/
[apnea, Aug 25 2008]
[link]
|
| |
I too am very keen on both RPN and Forth. I'm trying to think of a flaw concerning the other keys. Actually, it's better than that. As an avid user of emacs, i appreciate that combinations of control, meta and shift can have groovy results which divest one of the necessity of wasting time with mice and the like. This system would increase the number of combinations, because one could go "shift, shift, shift" for one option, but given the others, the order in which the combinations were typed could make a difference as well, so "alt, shift, control" could bring about a different result than "shift, alt, control" or "control, alt, shift". Beyond that, pressing the same key twice could make a further difference. |
|
| |
It also makes me wonder about a text editor written in Forth. |
|
| |
Yes, very very nice indeed. |
|
| |
RPN is for people who can't plan ahead. |
|
| |
// at the application level in Windows, where consistency is optional // |
|
| |
How do I perform an editing command like copy and paste? Will everything be like vi where you have two modes? |
|
| |
And how do you expect for me to hit CTRL-ALT-BACKSPACE? This is a required command for operating in X-Windows. |
|
| |
Can I backspace over commands? Say I type CTRL-CTRL-... and then I realize I mistyped ALT.. do I just continue, CTRL-CTRL-ALT-BACKSPACE, or can you back up, CTRL - CTRL - ESC - BACKSPACE - I - ALT - BACKSPACE. |
|
| |
Does this mean the OS will have two modes as well, or will any application in focus need to wait and see if ALT follows CTRL to determine whether BACKSPACE may still yet follow and the application needs to hold off paying attention to CTRL and ALT, say if you have CTRL-ALT bound in an application? |
|
| |
Lastly, I would recommend that all cached modifiers be displayed somewhere, for those of us that grow forgetful between keystrokes. For instance, you hit CTRL and then someone shouts: "The beer has arrived!". Turning back to your keyboard, you may no longer be certain what mayhem may await any further keypress. |
|
| |
Thanks for your remarks, [mylodon].
Actually, for more than one modifier
key, I was thinking they would be
chorded to the extent that they are
now. CTRL-ALT-BACKSPACE would all
be pressed at the same time, but the
power comes from having it apply to a
single letter, a word, or more, and also
from the possibility of hitting CTRL-
ALT-BACKSPACE twice, or more. You
raised some serious problems with the
idea of completely un-chording the
modifier keys. Other problems with
having a sequence of modifier keys is
how does the computer know that you
have finished the sequence? So
definitely no caching of modifier
sequences. Each modifier or
combination of modifiers would be a
single command, which makes some
change to the system state, and
repeating a command would act on the
system state that resulted from the last
command. The shift key would cycle
through the capitalization modes, as I
described. 'i' CTRL could cycle between
italics and not italics, but it should
consume the 'i'.
"stress i CTRL" -> "<i>stress</i>" |
|
| |
Likewise 'x' CTRL for cut, would
consume the 'x' and the preceding
word. The spaces would be very
important. "take-mex CTRL" would
be
[command take-mex not recognized]
but "take-me x CTRL" would cut "take-
me" to the clipboard. |
|
| |
Specific modes should not be
necessary, unless they make sense for a
particular application. I certainly have
not worked out all the details of using a
text entry area as a push-down stack
for command names. |
|
| |
Another example could be
[filename] i SHIFT CTRL
which could be the Get-Info
command for that file. (CTRL working
on a lower-case 'i' is Make-italic, but
on upper-case 'I' is Get-info) |
|
| |
Of course these specific meanings for
the command names are just examples.
Working out a consistent user-friendly
set of commands is beyond the scope
of a half-baked idea. |
|
| |
And thanks, [8th of 7] and [19thly]. |
|
| |
[phoenix], RPN is for people who do not
want to unnecessarily consume valuable
planning-ahead neuron resources. So,
maybe we are not so well endowed with
those resources. Oh well. |
|
| |