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

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

Format: 1.8
Date: Tue, 31 Mar 2009 23:52:18 +0200
Source: grml-etc-core
Binary: grml-etc-core
Architecture: source all
Version: 0.3.65
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.65) unstable; urgency=low
 .
   [ Frank Terbeck ]
   * zshrc: Add $NOTITLE to disable alteration of terminal titles.
     Based on an idea by Timo Boettcher.
   * zshrc: Cleaned up abbreviations by Alexander Steinböck.
     [Closes: issue642]
   * zshrc: source ~/.zshrc.local for root, too.
   * zshrc: Added a space to a grep related abbreviation for seamless
     typing; by Alexander Steinböck [Closes: issue616]
   * zshrc: Fix pattern to extract battery status from newer acpi
     versions. [Closes: issue657]
   * zshrc: Always read /etc/default/locale. Users are expected to
     adjust locale settings via '.zshrc.local'.
 .
   [ Michael Prokop ]
   * vimrc: add check for $NOPRECMD [Closes: issue447]
   * vimrc: enable features only if available [Closes: issue641]
   * zshrc: use 'setopt noglobdots' as [Open]SuSE uses in its
     /etc/zshrc 'setopt globdots' by default.
Checksums-Sha1: 
 62ef5f0963dbbc06fcce7734720ebd1d5f40a48b 873 grml-etc-core_0.3.65.dsc
 c131241e8dc510af121369aba69de1edd51beccf 108395 grml-etc-core_0.3.65.tar.gz
 8e6a8457af03923796f4139b08fd5aedb37b6246 110998 grml-etc-core_0.3.65_all.deb
Checksums-Sha256: 
 0df43059ce49c14ae32fb7094fc1dcd349e77268b70a020e969753756bfd29f2 873 grml-etc-core_0.3.65.dsc
 a712a6574c35e91cece4915141edfbc97fb1a9c83802ce3baa6db456dc0061b1 108395 grml-etc-core_0.3.65.tar.gz
 f0db9e49de5244a21d0a8667a160a17708367383d0b9c1d2a5a18ccb09c9441b 110998 grml-etc-core_0.3.65_all.deb
Files: 
 c8d22f616392fcd8d1654c84a55f98a1 873 grml optional grml-etc-core_0.3.65.dsc
 55c659366f4d2492e94a72891cde251a 108395 grml optional grml-etc-core_0.3.65.tar.gz
 17e5265a0096073b52ddb159ab149046 110998 grml optional grml-etc-core_0.3.65_all.deb

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

iD8DBQFJ0pDt2N9T+zficugRAqU7AJ93Xfy+J87cBzt2IY4k1dqXfgBk1QCfQQlF
s/ufAFaB4gpKUmMmoWFkgH8=
=erlD
-----END PGP SIGNATURE-----

Alexander Steinböck <bts@bts.grml.org>:
[...]
> [1] 0001-zshrc-Add-a-trailing-space-to-the-power-abbreviatio.patch
>     0002-zshrc-Text-formatting-in-section-power-abbreviation.patch
>     0003-zshrc-Use-single-quotes-througout-values-in-power-a.patch

[x] applied, thanks!

* Frank Terbeck <bts@bts.grml.org> [20090312 23:33]:

> > Frank, could you please check and apply? :)

> Well... I'm a  bit busy to take the proper amount of time for review
> right now... In a week, there is more time. It'll be luck if I get to
> it earlier. Sorry.

Definitely no need to hurry. Just take your time. :)
Thanks!

regards,
-mika-

Michael Prokop <bts@bts.grml.org>:
> * Alexander Steinböck <bts@bts.grml.org> [20090310 15:33]:
> > These patches[1] are successors of issue642 and totally replace the
> > former ones[2].
> 
> Frank, could you please check and apply? :)

Well... I'm a  bit busy to take the proper amount of time for review
right now... In a week, there is more time. It'll be luck if I get to
it earlier. Sorry.

Regards, Frank

* Alexander Steinböck <bts@bts.grml.org> [20090310 15:33]:

> These patches[1] are successors of issue642 and totally replace the
> former ones[2].

Frank, could you please check and apply? :)

> P.S.: Do we care to delete outdates patches in the BTS? Or should they
> stay for reference?

Please delete outdated patches if they are deprecated. :)

regards,
-mika-

These patches[1] are successors of issue642 and totally replace the
former ones[2].

---------------
P.S.: Do we care to delete outdates patches in the BTS? Or should they
stay for reference?

                   ---------- Footnotes ----------

[1] 0001-zshrc-Add-a-trailing-space-to-the-power-abbreviatio.patch
    0002-zshrc-Text-formatting-in-section-power-abbreviation.patch
    0003-zshrc-Use-single-quotes-througout-values-in-power-a.patch

[2] 0001-zshrc-Add-a-trailing-space-for-several-power-comple.patch
    0002-zshrc-Disordered-argument-list-in-MPlayer-s-power-c.patch

Alexander Steinböck <bts@bts.grml.org>:
> > But I don't see why you can't base your work on top of that last patch
> > in your git branch...
>
> I thought it would be easier to follow the history later when
> providing a simpler patch based on an updated master branch. (s.
> issue642) Less modifications overall.

Well, ideally these two issues that came up in this report should have
remain in this report in two patches of one patchset.

That why we could discuss *both* patches touching the same code area
at the same time. Therefore removing the need of artificial
synchronisation.

Regards, Frank

> But I don't see why you can't base your work on top of that last patch
> in your git branch...
I thought it would be easier to follow the history later when
providing a simpler patch based on an updated master branch. (s.
issue642) Less modifications overall.

Alexander Steinböck <bts@bts.grml.org>:
> > > After issue616 has been improved and pulled, I'll provide an
> > > updated patch for this issue.
> > Um, this *is* issue616...
> > So, I really don't understand what you're talking about.
> *argh* I meant issue642 of course. My bad. I'm sorry.

That's what I suspected.
But I don't see why you can't base your work on top of that last patch
in your git branch...

Regards, Frank

> > After issue616 has been improved and pulled, I'll provide an
> > updated patch for this issue.
> Um, this *is* issue616...
> So, I really don't understand what you're talking about.
*argh* I meant issue642 of course. My bad. I'm sorry.

Alexander Steinböck <bts@bts.grml.org>:
> After issue616 has been improved and pulled, I'll provide an updated
> patch for this issue.

Um, this *is* issue616...
So, I really don't understand what you're talking about.

Regards, Frank

fter issue616 has been approved and pulled respectively, I'll provide
an updated patch for this issue.

> > Actually, I think Alexander meant if my earlier remark still
> > applies. IIRC, I made a review with comments that are still
> > standing out to be corrected.
ACK.

> > So, unless you're in a hurry, I'd say we give Alexander the time
> > he needs to come up with a cleaned up patch.
> No need to hurry, Alexander - just take your time. :)
OK. But I'm hoping to be able to squeeze in some time for it today.

* Frank Terbeck <bts@bts.grml.org> [20090214 22:05]:

> > Alright, then I'll apply and push
> > http://bts.grml.org/grml/file195/0001-zshrc-Add-a-trailing-space-for-several-power-comple.patch

> Actually, I think Alexander meant if my earlier remark still applies.
> IIRC, I made a review with comments that are still standing out to be
> corrected.

Ah thanks for pointing out - I wasn't sure what I'm expected to do.
;)

> So, unless you're in a hurry, I'd say we give Alexander the time he
> needs to come up with a cleaned up patch.

No need to hurry, Alexander - just take your time. :)

regards,
-mika-

Michael Prokop <bts@bts.grml.org>:
> Frank Terbeck <ft@bewatermyfriend.org> [20090214 20:54]:
> > Alexander Steinböck <bts@bts.grml.org>:
> > > > And what I said about "take the unneeded expansions out": scratch
> > > > that. It's cleaner if that's done in a separate patch. Either
> > > > *before* (which is probably preferable) or *after* the patch
> > > > discussed in this bug. I'm fine either way, just don't squash it
> > > > into one patch.
> > > That does still apply, I guess.
> 
> > Yes.
> 
> Alright, then I'll apply and push
> http://bts.grml.org/grml/file195/0001-zshrc-Add-a-trailing-space-for-several-power-comple.patch

Actually, I think Alexander meant if my earlier remark still applies.
IIRC, I made a review with comments that are still standing out to be
corrected.

So, unless you're in a hurry, I'd say we give Alexander the time he
needs to come up with a cleaned up patch.

Regards, Frank

* Frank Terbeck <ft@bewatermyfriend.org> [20090214 20:54]:
> Alexander Steinböck <bts@bts.grml.org>:
> > > And what I said about "take the unneeded expansions out": scratch
> > > that. It's cleaner if that's done in a separate patch. Either
> > > *before* (which is probably preferable) or *after* the patch
> > > discussed in this bug. I'm fine either way, just don't squash it
> > > into one patch.
> > That does still apply, I guess.

> Yes.

Alright, then I'll apply and push
http://bts.grml.org/grml/file195/0001-zshrc-Add-a-trailing-space-for-several-power-comple.patch
- ok?

regards,
-mika-

Alexander Steinböck <bts@bts.grml.org>:
> > And what I said about "take the unneeded expansions out": scratch
> > that. It's cleaner if that's done in a separate patch. Either
> > *before* (which is probably preferable) or *after* the patch
> > discussed in this bug. I'm fine either way, just don't squash it
> > into one patch.
> That does still apply, I guess.

Yes.

Regards, Frank

> Alexander: Mika just merged ft-rebased into master. All work can be
> based on master again.
OK

> And what I said about "take the unneeded expansions out": scratch
> that. It's cleaner if that's done in a separate patch. Either
> *before* (which is probably preferable) or *after* the patch
> discussed in this bug. I'm fine either way, just don't squash it
> into one patch.
That does still apply, I guess.

Michael Prokop <bts@bts.grml.org>:
> * Frank Terbeck <bts@bts.grml.org> [20090213 12:19]:
[...]
> > Oh, and AFAICS I won't make any changes to 'ft' or 'ft-rebased'
> > anymore, unless people come up with bugs in the current state.
> 
> Ok cool, I'll test the upgrade path and will merge ft-rebased then.

Alexander: Mika just merged ft-rebased into master. All work can be
based on master again.

Regards, Frank

* Frank Terbeck <bts@bts.grml.org> [20090213 12:19]:

> > I won't make any changes in grml-etc-core from now on. Feel free to
> > do whatever needs to be done, I won't push anything on grml-etc-core
> > until you tell me that I can merge ft-rebased into master.

> Well, if you just change things that don't touch the zsh setup, a
> rebase will not have any conflicts and therefore is trivial. :-)
> So, if you need to make emergency fixes somewhere that's not a
> problem, if you give me a ping that a rebase is needed.

Right, fine. :)

> Oh, and AFAICS I won't make any changes to 'ft' or 'ft-rebased'
> anymore, unless people come up with bugs in the current state.

Ok cool, I'll test the upgrade path and will merge ft-rebased then.

regards,
-mika-

Michael Prokop <bts@bts.grml.org>:
> * Frank Terbeck <bts@bts.grml.org> [20090213 11:56]:
[...]
> > Mika: If you make changes to 'master' before the merge, ping me and
> > I'll update the rebased branch. Other then that, we're good to go.
> 
> I won't make any changes in grml-etc-core from now on. Feel free to
> do whatever needs to be done, I won't push anything on grml-etc-core
> until you tell me that I can merge ft-rebased into master.

Well, if you just change things that don't touch the zsh setup, a
rebase will not have any conflicts and therefore is trivial. :-)
So, if you need to make emergency fixes somewhere that's not a
problem, if you give me a ping that a rebase is needed.

Oh, and AFAICS I won't make any changes to 'ft' or 'ft-rebased'
anymore, unless people come up with bugs in the current state.

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

* Frank Terbeck <bts@bts.grml.org> [20090213 11:56]:

> > Do I have to take any action or do you plan to apply the patches on
> > your own?

> We'll handle it, unless you want something specific.

Thanks. Just go for it. :)

> > BTW: I plan to merge the ft-rebased branch in those days, so feel
> > free to adjust whatever is necessary. ;)

> Well then:
> Let's put grml-etc-core (at least the zsh part) into "deep freeze".

ACK

> 'ft-rebased' is currently a fast-forward to the 'master' branch on
> git.grml.org, which is good - that's what I was aiming for.

Fine

> Mika: If you make changes to 'master' before the merge, ping me and
> I'll update the rebased branch. Other then that, we're good to go.

I won't make any changes in grml-etc-core from now on. Feel free to
do whatever needs to be done, I won't push anything on grml-etc-core
until you tell me that I can merge ft-rebased into master.

thx && regards,
-mika-

Michael Prokop <bts@bts.grml.org>:
> As discussed at the BSP on IRC: ACK from my side.

Good.

> Do I have to take any action or do you plan to apply the patches on
> your own?

We'll handle it, unless you want something specific.

> BTW: I plan to merge the ft-rebased branch in those days, so feel
> free to adjust whatever is necessary. ;)

Well then:
Let's put grml-etc-core (at least the zsh part) into "deep freeze".

'ft-rebased' is currently a fast-forward to the 'master' branch on
git.grml.org, which is good - that's what I was aiming for.

Mika: If you make changes to 'master' before the merge, ping me and
I'll update the rebased branch. Other then that, we're good to go.

Alexander: When you clean up the patch, base it on ft-rebased, that
way it'll just apply later. And what I said about "take the unneeded
expansions out": scratch that. It's cleaner if that's done in a
seperate patch. Either *before* (which is probably preferable) or
*after* the patch discussed in this bug. I'm fine either way, just
don't squash it into one patch. We'll apply those patches *after* we
merged 'ft-rebased' into 'master'.

Regards, Frank

As discussed at the BSP on IRC: ACK from my side. Do I have to take any action 
or do you plan to apply the patches on your own? BTW: I plan to merge the ft-
rebased branch in those days, so feel free to adjust whatever is necessary. ;)

thx!

regards,
-mika-

* Frank Terbeck <bts@bts.grml.org>
> Well, I hope I'm not starting to nitpick too heavily.
You're a hard man to please. (o; But it's absolutely fine with me. In
fact, I appreciate your constructive criticism and all the effort
you're going through with your responses.
> But since I do like the way you're writing nice and lengthy commit
> messages, I think it's okay to see whether we can can them just
> right[tm]. :-)
Doing my best. But I'm aware of the fact that I can get rather complex
when writing in english. Therefore I'm really glad there's someone
reviewing the yackety-yak I produce.

> I don't like the wording. I know we're using 'power completion'
> elsewhere, too. But it's really just an expansion. There is *nothing*
> that's completed at all.
ACK.
> > Take '|& grep --color=auto ' for instance. Mind the trailing space.
> I guess I'd just drop this line altogether. It doesn't add much of
> value.
ACK.

> The patch itself looks fine. An updated patch with a cleaned up commit
> msg would be terrific, though. :)
Will do. But, before any further investigation, let's wait for mika's
point of view regarding the various expansions you've mentioned.

> However, I *seriously* don't know why the following are in the
> $abk[] hash at al. Where's the point in having those in addition to
> simple aliases?
> [...]
> The only reason I see would be to be able to expand aliases at will.
> Then again: are we adding new aliases to this list? Did we do it in
> the past, after we got this expansion? Can't compsys's _expand do
> something like that for us?
That's an interesting idea.

I'm not really using these expanѕion either -- exepct `e,.' for `print
-l' or a modified `mp' for `mplayer -vo xv -xy ' to specify width and
height -- and therefore I agree that several of these expansions are
rather questionable.
And a line such as
> >      'fori' 'for i ({..}) { }'
would IMHO be more useful when implemented as a widget.

But as I mentioned above, let's hear mika's point of view.

Alexander Steinböck <bts@bts.grml.org>:
> 
> Alexander Steinböck <z3ttacht@grml.org> added the comment:
> 
> Option listing of some MPlayer power completions are disordered. I.e.
> 'fbmplayer' 'mplayer -vo -fs -zoom fbdev ' Therefore MPlayer is
> searching for a file called 'fbdev'.

Yes. Good catch.
And this supports my theory, that *noone* actually uses this expansion
for such aliases (see my previous mail).

[...]
> The output video driver must be specified after `-vo'.
> 
> Merging of all completions regarding MPlayer into one section as well.

This message, I like.

[...]

Personally, I'd have prefered to have the moving around of 'cx' to be
in its own commit, but hey, I'm probably taking things too far right
now. :-)

> +    'cx' 'chmod +x '
> @@ -829,21 +830,20 @@ abk=(
> -    'cmplayer' 'mplayer -vo -fs -zoom fbdev '
> -    'fbmplayer' 'mplayer -vo -fs -zoom fbdev '
> +    'cmplayer'  'mplayer -vo fbdev -fs -zoom '
> +    'fbmplayer' 'mplayer -vo fbdev -fs -zoom '
> +    'fb2' 'mplayer -vo fbdev -fs -zoom -xy 2 1>/dev/null '
> +    'fb3' 'mplayer -vo fbdev -fs -zoom -xy 3 1>/dev/null '
> +    'mp'  'mplayer -vo xv -fs -zoom '
> -    'cx' 'chmod +x '
> -    'fb2' '=mplayer -vo fbdev -fs -zoom 1>/dev/null -xy 2 '
> -    'fb3' '=mplayer -vo fbdev -fs  -zoom 1>/dev/null -xy 3 '
> -    'mp' 'mplayer -vo xv -fs -zoom '

Otherwise, the patch looks fine, and should be in after the other one
get its update.

Regards, Frank

Well, I hope I'm not starting to nitpick too heavily.
But since I do like the way you're writing nice and lengthy commit
messages, I think it's okay to see whether we can can them just
right[tm]. :-)

Alexander Steinböck <bts@bts.grml.org>:
> From f8b4c2f57de0c6c5cffa5493f9d778972f857af9 Mon Sep 17 00:00:00 2001
> From: =?utf-8?q?Alexander=20Steinb=C3=B6ck?= <z3ttacht@grml.org>
> Date: Thu, 5 Feb 2009 16:55:42 +0100
> Subject: [PATCH 1/2] zshrc: Add a trailing space for several power completions.
> 
> Hence $USER doesn't need to hit the space bar when some arguments are
> supposed to follow after the expansion of a power completion.

I don't like the wording. I know we're using 'power completion'
elsewhere, too. But it's really just an expansion. There is *nothing*
that's completed at all.

Therefore:
Hence the user doesn't need to hit the space bar when some arguments
are supposed to follow after an expansion.

> Take '|& grep --color=auto ' for instance. Mind the trailing space.

I guess I'd just drop this line altogether. It doesn't add much of
value.

> Therefore one can just keep typing conveniently.
[...]

The patch itself looks fine. An updated patch with a cleaned up commit
msg would be terrific, though. :)

> --- a/etc/zsh/zshrc
> +++ b/etc/zsh/zshrc

However, I *seriously* don't know why the following are in the $abk[]
hash at all... It has nothing to do with your patch, I'm just
wondering. Mika? Where's the point in having those in addition to
simple aliases?

[...]
> -    'da' 'du -sch'
> +    'da' 'du -sch '
>      'j' 'jobs -l'
> -    'u' 'translate -i'
> +    'u' 'translate -i '
>      'co' "./configure && make && sudo make install"
        ^- That one I actually get. Maybe you'd want to add options to
           configure...

>      'CH' "./configure --help"
>      'conkeror' 'firefox -chrome chrome://conkeror/content'
        ^- that one should be out. That extension is a standalone
           program these days, AFAIK.

> @@ -821,29 +821,29 @@ abk=(
>      'lsnew' $'ls -rl *(D.om[1,10])\n# display the newest files'
>      'lsold' $'ls -rtlh *(D.om[-11,-1])\n # display the oldest files'
>      'lssmall' $'ls -Srl *(.oL[1,10])\n# display the smallest files'

These 3 I don't get either. Their names tell the story as to what they
do...

> -    'rw-' 'chmod 600'
> -    '600' 'chmod u+rw-x,g-rwx,o-rwx'
> -    'rwx' 'chmod u+rwx'
> -    '700' 'chmod u+rwx,g-rwx,o-rwx'
> -    'r--' 'chmod u+r-wx,g-rwx,o-rwx'
> -    '644' $'chmod u+rw-x,g+r-wx,o+r-wx\n # 4=r,2=w,1=x'
> -    '755' 'chmod u+rwx,g+r-w+x,o+r-w+x'
> +    'rw-' 'chmod 600 '
> +    '600' 'chmod u+rw-x,g-rwx,o-rwx '
> +    'rwx' 'chmod u+rwx '
> +    '700' 'chmod u+rwx,g-rwx,o-rwx '
> +    'r--' 'chmod u+r-wx,g-rwx,o-rwx '
> +    '644' $'chmod u+rw-x,g+r-wx,o+r-wx \n # 4=r,2=w,1=x'
> +    '755' 'chmod u+rwx,g+r-w+x,o+r-w+x '

These might serve the purpose of learning the octal values. Then
again.. I don't know. To me they feel totally redundant.

>      'md' 'mkdir -p '
> -    'cmplayer' 'mplayer -vo -fs -zoom fbdev'
> -    'fbmplayer' 'mplayer -vo -fs -zoom fbdev'
> +    'cmplayer' 'mplayer -vo -fs -zoom fbdev '
> +    'fbmplayer' 'mplayer -vo -fs -zoom fbdev '
>      'fblinks' 'links2 -driver fb'

These I don't get at all.
The names tell the story again. And IMHO the point of an alias is to
not bother about complex repetitive options and arguments.

>      'insecssh' 'ssh -o "StrictHostKeyChecking=no" -o "UserKnownHostsFile=/dev/null"'
>      'insecscp' 'scp -o "StrictHostKeyChecking=no" -o "UserKnownHostsFile=/dev/null"'
>      'fori' 'for i ({..}) { }'
> -    'cx' 'chmod +x'
> -    'e'  'print -l'
> +    'cx' 'chmod +x '
> +    'e'  'print -l '
>      'se' 'setopt interactivecomments'
>      'va' 'valac --vapidir=../vapi/ --pkg=gtk+-2.0 gtktest.vala'
> -    'fb2' '=mplayer -vo fbdev -fs -zoom 1>/dev/null -xy 2'
> -    'fb3' '=mplayer -vo fbdev -fs  -zoom 1>/dev/null -xy 3'
> +    'fb2' '=mplayer -vo fbdev -fs -zoom 1>/dev/null -xy 2 '
> +    'fb3' '=mplayer -vo fbdev -fs  -zoom 1>/dev/null -xy 3 '
>      'ci' 'centericq'
>      'D'  'export DISPLAY=:0.0'
> -    'mp' 'mplayer -vo xv -fs -zoom'
> +    'mp' 'mplayer -vo xv -fs -zoom '

A variation of my previous arguments apply to these, too.

Why did we do that again?
The only reason I see would be to be able to expand aliases at will.
Then again: are we adding new aliases to this list? Did we do it in
the past, after we got this expansion? Can't compsys's _expand do
something like that for us?

Maybe I'm missing something. I don't use that feature at all. So
correct me if I'm wrong.

Regards, Frank

Option listing of some MPlayer power completions are disordered. I.e.
'fbmplayer' 'mplayer -vo -fs -zoom fbdev ' Therefore MPlayer is
searching for a file called 'fbdev'.

I've put all power completions regarding MPlayer after another as
well.

---
Note: I didn't open another issue because this patch is a successor of
the one with the trailing spaces.

Hence $USER doesn't need to hit the space bar when some arguments are
supposed to follow after the expansion of a power completion.
Take '|& grep --color=auto ' for instance. Mind the trailing space.
Therefore one can just keep typing conveniently.