Why not add shift-slides?

Posted by Gary L. Matthews , Fri, Mar 07, 2003, 20:14:42   Forum

Dear Jean & friends,

Congratulations again on Fitaly 3 final release, especially with the new custom-slide semantics -- the "midnight suggestion".

Under the new protocol (which I very much like), directional slides by default produce the starting letter -- short for lower-case, long for upper-case. But for any given slide direction, you can redefine these, thereby producing 16 optional macros for each key. Since at least one slide -- south-long, for example -- needs to be reserved for the upper-case letter, this supposedly leaves 15 macros for each key.

But with all this room, I find it extremely limiting and arbitrary that I should have to enter an upper-case version, and a lower-case version, of any macro text that I want to use. Please consider the T key, along with, say, east slides: My current choices include tap-T for "t", shift-tap-T for "T", T-short-east for "the" and T-long-east for "towards". (This is based on Aaron's slide scheme, which, while admittedly complex, I'm using with increasing success and confidence.)

Here's the problem: If I'm using a short directional slide for one word, and the corresponding long slide for a different word -- HOW do I get those same words with the first letter in upper case? Obviously, I could define T-short-east as "the" and T-long-east as "The". But then I'd lose the long-east slide for any other purpose. Assuming I do this for every word I've assigned to a slide, my choices plummet to half what they were.

Why not solve this problem by adding a shift-slide state? That is, have T-short-east produce "the" and have SHIFT-T-short-east produce "The"? This seems to me to be a very natural solution. In other words, tap followed by any given slide, long or short, and the first letter of the result becomes capitalized -- regardless of how or whether macros are defined.

In the RC1 version, a custom slide produced one text-string, while tapping followed by the same slide produces a different one. Now, however, a shift-slide does nothing different from a slide. It seems to me that this frees up the shift-slides for a different use, and to me this seems a good one.

Here's an even wilder idea, but one I see as viable: Why not have shift-slides BY DEFAULT produce initial-caps versions of their unshifted slide counterparts -- BUT have these, too, be user-definable. That is, if I don't want shift-T-short-east to produce "The", I could go in an redefine this slide to produce "Tyrannasaurus Rex". There may be words I seldom if ever use in an initial-caps state. We already have a massive number of user-definable macros; this would roughly double the number. But there's no problem with that, is there?

Kind regards,

Gary Matthews

Edit | | | View All | |   | Current page | Author