Comments on \defineshortcut

Comments on \defineshortcut

[Giuseppe Bilotta]

Hello, I'm playing with shortcuts now, and I found some limitations on the
current implementation.

It's impossible to re-define shortcuts other than <>; the reason is that, once I
issue

\defineshortcut [()][a][style=\overstrike]

I cannot issue

\defineshortcut [()][b][style=\underline]

later because an "undefined control sequence" error is issued.

(the problem is not present for <> because for them you can use

\defineshortcut [a][style=\overstrike]
\defineshortcut [b][style=\underline]

and <> do no appear again)

Second problem: ligs fail in some cases (if I \defineshortcut
[--][o][style\overstrike] then the following lines misses a few beats:

it seems -o:to work- well--does it?---really?

Third problem: math fails too:

$(a+b)/(a-c-d)_{a+b}$

with -- and ++ defined as shortcuts fail (not on parenthesis, if I make those
active too; depends on the fact that parenthesis are delimiters in math mode?)

(possibily this depends on shortcuts not being nestable); the latter is maybe
more important.

Giuseppe Bilotta

Using Microsoft products is like
having sex without condoms---but
much less pleasurable

Re: Comments on \defineshortcut

[Hans Hagen]

At 01:16 PM 2/1/01 +0100, Giuseppe Bilotta wrote:
>Hello, I'm playing with shortcuts now, and I found some limitations on the
>current implementation.
>
>It's impossible to re-define shortcuts other than <>; the reason is that,
once I
>issue
>
>\defineshortcut [()][a][style=\overstrike]
>
>I cannot issue
>
>\defineshortcut [()][b][style=\underline]
>
>later because an "undefined control sequence" error is issued.

\def\dodefineshortcut[#1][#2][#3]%
  {\ifthirdargument
     \ConvertConstantAfter\doifelse{#1}{}
       {\dododefineshortcut[<>][#2][#3]}
       {\dododefineshortcut[#1][#2][#3]}%
   \else\ifsecondargument
     \dododefineshortcut[<>][#1][#2]%
   \else
     \dododefineshortcut[<>][][#1]%
   \fi\fi}

\defineshortcut [()][a][commando=\overbar]  test (a:bc) test
\defineshortcut [()][b][commando=\underbar] test (b:abc) test

>Second problem: ligs fail in some cases (if I \defineshortcut
>[--][o][style\overstrike] then the following lines misses a few beats:
>
>it seems -o:to work- well--does it?---really?

see it this way: in --- the first - picks up everything uuntil the next -
so the third - triggers a new - which cannot find its matching - 

>Third problem: math fails too:
>>
>$(a+b)/(a-c-d)_{a+b}$
>with -- and ++ defined as shortcuts fail (not on parenthesis, if I make those
>active too; depends on the fact that parenthesis are delimiters in math
mode?)

Hm, this works ok here, unless of course you redefine + a few times since
then the last meaning is used. 

\defineshortcut[++]  saves the old meaning which is + 
\defineshortcut[++]  saves th eole meaning which is shortcut 

and in math mode the second one is used which means that the first shortcut
is invokes.  

>(possibily this depends on shortcuts not being nestable); the latter is maybe
>more important.

not nestable indeed since they use delimited arguments. 

Beware: it's a dangerous mechanism anyway, esp when you load some module
that expects + to be +, so: use with care. 

Hans

PS. Actually i implemented shortcuts as a kind of joke. 
-------------------------------------------------------------------------
                                  Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                      Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: Comments on \defineshortcut

[Giuseppe Bilotta]

> At 01:16 PM 2/1/01 +0100, Giuseppe Bilotta wrote:
> >Hello, I'm playing with shortcuts now, and I found some limitations on the
> >current implementation.
> >
> >It's impossible to re-define shortcuts other than <>; the reason is that,
> once I
> >issue
> >
> >\defineshortcut [()][a][style=\overstrike]
> >
> >I cannot issue
> >
> >\defineshortcut [()][b][style=\underline]
> >
> >later because an "undefined control sequence" error is issued.
>
> \def\dodefineshortcut[#1][#2][#3]%
>   {\ifthirdargument
>      \ConvertConstantAfter\doifelse{#1}{}
>        {\dododefineshortcut[<>][#2][#3]}
>        {\dododefineshortcut[#1][#2][#3]}%
>    \else\ifsecondargument
>      \dododefineshortcut[<>][#1][#2]%
>    \else
>      \dododefineshortcut[<>][][#1]%
>    \fi\fi}
>

Will patch, recreate and test ASAP.

>
> >Second problem: ligs fail in some cases (if I \defineshortcut
> >[--][o][style\overstrike] then the following lines misses a few beats:
> >
> >it seems -o:to work- well--does it?---really?
>
> see it this way: in --- the first - picks up everything uuntil the next -
> so the third - triggers a new - which cannot find its matching -
>

even the -- lig is lost, anyway. But never mind:

> >Third problem: math fails too:
> >>
> >$(a+b)/(a-c-d)_{a+b}$
> >with -- and ++ defined as shortcuts fail (not on parenthesis, if I make those
> >active too; depends on the fact that parenthesis are delimiters in math
> mode?)
>
> Hm, this works ok here, unless of course you redefine + a few times since
> then the last meaning is used.
>
> \defineshortcut[++]  saves the old meaning which is +
> \defineshortcut[++]  saves th eole meaning which is shortcut
>
> and in math mode the second one is used which means that the first shortcut
> is invokes.
>

Maybe then saving should check if the old meaning was already a shortcut ... if
this is doable.

> PS. Actually i implemented shortcuts as a kind of joke.

Such a pity it's only a joke :-). They are very good for fast typing ...

Thanks very much

Giuseppe Bilotta

Using Microsoft products is like
having sex without condoms---but
much less pleasurable

Re: Comments on \defineshortcut

[Hans Hagen]

At 10:47 PM 2/2/01 +0100, Giuseppe Bilotta wrote:

>Maybe then saving should check if the old meaning was already a shortcut
... if
>this is doable.

sure, stacking is no problem, but then people would ask for non stacked
meanings -) 

btw, your end-of-mail sentence will let the mail archive end up in wrong
lookups in search engines, given the popularity of some search terms. 

Hans
-------------------------------------------------------------------------
                                  Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                      Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: Comments on \defineshortcut

[Hans Hagen]

At 10:47 PM 2/2/01 +0100, Giuseppe Bilotta wrote:

>even the -- lig is lost, anyway. But never mind:

ligs are strange animals, and implemented in ttp in such a way that they
may disappear or suddenly reappear; such is our tex life

Hans
-------------------------------------------------------------------------
                                  Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                      Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: Comments on \defineshortcut

[Giuseppe Bilotta]

[the patch works perfect; about the other question:]

>
> >Second problem: ligs fail in some cases (if I \defineshortcut
> >[--][o][style\overstrike] then the following lines misses a few beats:
> >
> >it seems -o:to work- well--does it?---really?
>
> see it this way: in --- the first - picks up everything uuntil the next -
> so the third - triggers a new - which cannot find its matching -
>
> >Third problem: math fails too:
> >>
> >$(a+b)/(a-c-d)_{a+b}$
> >with -- and ++ defined as shortcuts fail (not on parenthesis, if I make those
> >active too; depends on the fact that parenthesis are delimiters in math
> mode?)
>
> Hm, this works ok here, unless of course you redefine + a few times since
> then the last meaning is used.
>

I checked out--the problem was the "pending" - form the --- on the previous
line.

Anyway, note that -- should *not* just disappear, since -- is not a shorcut, but
"-o:<whatever text>-" is; so maybe in these circumstances (when "pure" shortcut
is note defined, but it is used) charactes should revert to their original
meaning:

In the previous example:

-o:overstriken text- should be overstriked, but -- and --- should work normally
(getting ligs and alike);

with \defineshortcut[**][b][style=bold]:

*b:bolded text* should be bold, but ** and *** should work normally (no ligs in
this case);

> PS. Actually i implemented shortcuts as a kind of joke.

Then maybe such fuss is not to be wasted time upon.

Giuseppe Bilotta

Using Microsoft products is like
having sex without condoms---but
much less pleasurable