We believe that your issue has been closed by the upload of
Version 0.3.51 of grml-etc-core from Michael Prokop <mika@grml.org>.
The explanation is attached below

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed, 06 Aug 2008 23:36:58 +0200
Source: grml-etc-core
Binary: grml-etc-core
Architecture: source all
Version: 0.3.51
Distribution: unstable
Urgency: low
Maintainer: Michael Prokop <mika@grml.org>
Changed-By: Michael Prokop <mika@grml.org>
Description: 
 grml-etc-core - core ecetera files for the grml system
Changes: 
 grml-etc-core (0.3.51) unstable; urgency=low
 .
   The "pfuh what nice zsh features" release. :)
 .
   [ Frank Terbeck ]
   * zshrc: Add persistent dirstack support for shells older than 4.2.0
   * zshrc: Make ',.' abbreviation optional [Closes: issue445]
   * zshrc: do not use xunfunction() anymore; it prevented things like
            'source ~/.zshrc' from working.
 .
   [ Michael Gebetsroither ]
   * zshrc: add runit sysv emulation support to Start/Stop/Restart/...
 .
   [ Michael Prokop ]
   * zshrc:
     - Add support for ${HOME}/.zshenv.
     - Add new function ansi-colors() [via harnir]
     - Support .deb in show-archive() [via harnir]
     - Fix wrong placed comments for debbug vs. debbugm.
       Thanks to Dennis Schreiber for pointing out.
     - Provide more processes in completion of programs like
       killall (thanks, ft).
     - New function uopen() to download a file and display it locally.
       Thanks for the idea, formorer; thanks for debugging help, ft. :)
     - New function linenr() to print a specific line of file, thanks
       to Wuehlmaus.
     - Update gizmo() function.
     - Add completion for aliases, deactivated by default because it
       might be confusing for several users for now. Idea by Julius,
       thanks for forwarding - wuehlmaus. :)
   * zshenv: set $PATH on Solaris/SunOS.
Files: 
 4719ee22f1e8ead12a3d32af1f757de4 596 grml optional grml-etc-core_0.3.51.dsc
 1acc07fe2643c83fb9fd903df52e5124 95898 grml optional grml-etc-core_0.3.51.tar.gz
 385a36a9894d444a9d9e32711e23ac47 98458 grml optional grml-etc-core_0.3.51_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFImh4F2N9T+zficugRAnNZAJ9LlLrlgBFN7LSR+BCI1/788U1jWACcC5UI
eRpIrMO92VRkC0IP/+y4nKs=
=EL2g
-----END PGP SIGNATURE-----

Michael Prokop <mika@grml.org>:
> * Frank Terbeck [20080407 14:42]:
> > Michael Prokop:
[...]
> > > Frank, any ideas how we could "work around" this issue?
[...]
> > We could create a binding, that would toggle these abbreviations on
> > and off. Or we could introduce a variable $DISABLE_ABBREV.
> 
> > Neither of these solutions is exceptionally nice.
> > I'll think about it...
> 
> ACK
> 
[...]
> [...] Maybe $NOPOWERCOMP or something like that (our "disable
> environment variables" usually start with $NO... :)) really might be
> the best option?

Hm, thinking about it:

To *really* make sure pasting stuff into the command line does not
trigger abbreviation, we won't get around disabling it, IMHO.

There would be, if we could tell the rate at which characters are
typed into the shell (much like irssi detects pasting). However, I
think it absolutely *not* justified to check timestamps for every
character ever entered (let alone the fact, that I don't know of a way
to get timestamps with higher resolution than whole seconds - which
would obviously be needed here).

Coming back to some seriousness about the subject:

    a) introduce $NOABBREVIATION (defaulting to 0).
    b) create a binding (e.g.: ^xA) that toggles the use of
       abbreviations on and off.

If $NOABBREVIATION it greater than 0, disable abbreviations by default
(while still being able to re-enable them with the binding).

If $NOABBREVIATION is at 0 (its default), everything should work as it
does now. If the user wants to paste something, and something goes
wrong because an abbreviation is triggered, he/she can disable
abbreviations temporarily by hitting the binding.


This is the best I can think of right now.
Implementation? Well, If at all, I can only do it this evening. And
only if I get my work done until then. Else, it will have to wait
another week or two - unless someone else does it (which in fact is
easily possible, because no black-zsh-magic would be needed at all;
I'm also willing to review code other produce on the subject).

Regards, Frank

PS: I am interested in an elegant way to detect pastes into the shell.
    So if someone has got an idea, I'm all ears. :-)

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

* Frank Terbeck [20080407 14:42]:
> Michael Prokop:
> > * Gus Tavares <bts@bts.grml.org> [20080407 11:42]:

> > I guess it's because of:

> > % bindkey ,.
> > ",." globalias

> That's right.

Ok. :)

> > Frank, any ideas how we could "work around" this issue?

> Off hand, I do not see an elegant way to deal with this.

> We could create a binding, that would toggle these abbreviations on
> and off. Or we could introduce a variable $DISABLE_ABBREV.

> Neither of these solutions is exceptionally nice.
> I'll think about it...

ACK

> How would you measure the "badness" of this? I have some difficulties
> in judging this, because I do not use things like the abbreviations
> stuff in my own configuration. Does stuff like this problem piss
> people more off than not having abbreviations at all?

Well, as least Gus is the first person I'm aware of who is stumbling
upon this issue. :) Maybe $NOPOWERCOMP or something like that (our
"disable environment variables" usually start with $NO... :)) really
might be the best option?

thx && regards,
-mika-

Michael Prokop <mika@grml.org>:
> * Gus Tavares <bts@bts.grml.org> [20080407 11:42]:
> 
> > Using your mouse, please copy and paste onto your zsh commandline the following
> > line:
> 
> > echo '#a,.b'
> 
> > The result is:
> 
> > #ab
> [...]
> 
> I guess it's because of:
> 
> % bindkey ,.
> ",." globalias

That's right.

> Frank, any ideas how we could "work around" this issue?

Off hand, I do not see an elegant way to deal with this.

We could create a binding, that would toggle these abbreviations on
and off. Or we could introduce a variable $DISABLE_ABBREV.

Neither of these solutions is exceptionally nice.
I'll think about it...

How would you measure the "badness" of this? I have some difficulties
in judging this, because I do not use things like the abbreviations
stuff in my own configuration. Does stuff like this problem piss
people more off than not having abbreviations at all?

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

* Gus Tavares <bts@bts.grml.org> [20080407 11:42]:

> Using your mouse, please copy and paste onto your zsh commandline the following
> line:

> echo '#a,.b'


> The result is:

> #ab
[...]

I guess it's because of:

% bindkey ,.
",." globalias

Frank, any ideas how we could "work around" this issue?

regards,
-mika-

Using your mouse, please copy and paste onto your zsh commandline the following
line:

echo '#a,.b'


The result is:

#ab


Yes, even before pressing Return, it won't even copy onto the command line properly.


In fact, type very quickly the character sequence (within the quotes) ",.".


Nothing, right?


Note that this also happens even in an ordinary terminal, not just in an xterm.
Also, this only happens in zsh, not in bash.


Now, please type (do not cut and paste with your mouse) the following line:

echo '#a,.b' | xclip


Then click your middle button or wheel on the commandline to paste what is in xclip.


The result is again:

#ab


Now please type:

cat > tmp.txt

and using your mouse copy and paste:

,.

[you will see that it pastes properly] and then type Return and ^D.


Then enter:

cat tmp.txt

and the result is OK.



It would seem that it is only when pasting directly onto the ( empty ? )
commandline of zsh that the character sequence ",." is eliminated. Even when
using xclip, any ",." is eliminated when pasting directly onto the zsh
commandline. Again, this doesn't occur within bash.



I checked the Web and the best I could come up with is from the site:

http://www.mkssoftware.com/docs/man1/xterm.1.asp

which states:

<quote>
sunKeyboard (class SunKeyboard)

 Specifies whether or not Sun/PC keyboard layout should be assumed rather than
DEC VT220. This causes the keypad + to be mapped to ,. and CTRL F1-F12 to
F11-F20, depending on the setting of the ctrlFKeys resource. so xterm emulates a
DEC VT220 more accurately. Otherwise (the default, with sunKeyboard set to
false), xterm uses PC-style bindings for the function keys and keypad.
</quote>


What does zsh have against the character sequence ",."?  I've noticed how when
typing the comma, zsh is slow to display it. But why does it only eliminate the
sequence ",." in particular?  For example, copy and paste:

echo '# a,,b a.,b a,:b a,;b a,a a,z a,0 a,9'

and it is OK. Are there other character sequences that get eliminated?

Thank you for your time.