For example: % print -r -- ${(q+):-{$'\C-['..$'\C-]'}} '^[' '^\' '^]' % print -r -- ${(q+):-{$'\C-[',$'\C-]'}} $'\C-[' $'\C-]' % setopt braceccl % print -r -- ${(q+):-{$'\C-['-$'\C-]'}} $'\C-[' $'\C-\' $'\C-]' % Is there a reason for this inconsistency? Why not always produce quoted or unquoted output? Also, why bindkey-style quoting? Wouldn't ${(q+)}-style quoting be more convenient, since it's more straightforward to "unquote"?
On Wed, Aug 4, 2021 at 12:05 AM Marlon Richert <marlon.richert@gmail.com> wrote:
>
> Is there a reason for this inconsistency? Why not always produce
> quoted or unquoted output?
>
> Also, why bindkey-style quoting? Wouldn't ${(q+)}-style quoting be
> more convenient, since it's more straightforward to "unquote"?
The answer to "why doesn't feature A take advantage of feature B" is
often "because A was developed long before B".
I believe that's the case in both instances here. BRACE_CCL and {x,y}
existed before {a..z}, and {a..z} existed before $'..'. Old code was
never updated to be consistent with newer code, either from simply
being overlooked, or for backwards compatibility.
On Wed, Aug 4, 2021 at 6:52 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Wed, Aug 4, 2021 at 12:05 AM Marlon Richert <marlon.richert@gmail.com> wrote:
> >
> > Is there a reason for this inconsistency? Why not always produce
> > quoted or unquoted output?
> >
> > Also, why bindkey-style quoting? Wouldn't ${(q+)}-style quoting be
> > more convenient, since it's more straightforward to "unquote"?
>
> The answer to "why doesn't feature A take advantage of feature B" is
> often "because A was developed long before B".
>
> I believe that's the case in both instances here. BRACE_CCL and {x,y}
> existed before {a..z}, and {a..z} existed before $'..'. Old code was
> never updated to be consistent with newer code, either from simply
> being overlooked, or for backwards compatibility.
I just wish {a..z} didn't use quoting at all. :)
I understand, though, that it's hard to change at this point, because
of backwards compatibility.
How would you feel about adding a shell option to make {a..z}
unquoted? (Or failing that, an option to make all of them
$'..'-quoted.)
On Wed, Aug 4, 2021 at 11:18 PM Marlon Richert <marlon.richert@gmail.com> wrote: > > I just wish {a..z} didn't use quoting at all. :) Re-reading the doc for this, {a..z} is guaranteed to produce PRINTABLE output, which is not true of the other variations of brace expansion. > How would you feel about adding a shell option to make {a..z} > unquoted? Ambivalent. If you're going to set an option anyway, why can't you use BRACE_CCL and {a-z} ? > (Or failing that, an option to make all of them > $'..'-quoted.) That, I think not. You've already demonstrated that it's simple to add the quoting ... and in what circumstance would you want the brace expansion quoted, but the word in which it's embedded, unquoted?
On 8/6/21, Bart Schaefer <schaefer@brasslantern.com> wrote: > On Wed, Aug 4, 2021 at 11:18 PM Marlon Richert <marlon.richert@gmail.com> > wrote: >> >> I just wish {a..z} didn't use quoting at all. :) > > Re-reading the doc for this, {a..z} is guaranteed to produce PRINTABLE > output, which is not true of the other variations of brace expansion. If you want to expand these printable representations to the actual codepoints, you can use (g:ce:) . >> How would you feel about adding a shell option to make {a..z} >> unquoted? > > Ambivalent. If you're going to set an option anyway, why can't you > use BRACE_CCL and {a-z} ? braceccl works on the byte level only so it's not usable for multibyte codepoints etc. >> (Or failing that, an option to make all of them >> $'..'-quoted.) > > That, I think not. You've already demonstrated that it's simple to > add the quoting ... and in what circumstance would you want the brace > expansion quoted, but the word in which it's embedded, unquoted? -- Mikael Magnusson
On Thu, Aug 5, 2021 at 5:55 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> On 8/6/21, Bart Schaefer <schaefer@brasslantern.com> wrote:
> > On Wed, Aug 4, 2021 at 11:18 PM Marlon Richert <marlon.richert@gmail.com>
> >> How would you feel about adding a shell option to make {a..z}
> >> unquoted?
> >
> > Ambivalent. If you're going to set an option anyway, why can't you
> > use BRACE_CCL and {a-z} ?
>
> braceccl works on the byte level only so it's not usable for multibyte
> codepoints etc.
Hm, it might make more sense to enable multibyte in braceccl than to
disable quoting in {a..z}. (Admittedly, it also might be more
difficult.)
On Fri, Aug 6, 2021 at 3:55 AM Mikael Magnusson <mikachu@gmail.com> wrote: > > On 8/6/21, Bart Schaefer <schaefer@brasslantern.com> wrote: > > On Wed, Aug 4, 2021 at 11:18 PM Marlon Richert <marlon.richert@gmail.com> > > wrote: > >> > >> I just wish {a..z} didn't use quoting at all. :) > > > > Re-reading the doc for this, {a..z} is guaranteed to produce PRINTABLE > > output, which is not true of the other variations of brace expansion. > > If you want to expand these printable representations to the actual > codepoints, you can use (g:ce:) . Thanks! I had been looking through https://zsh.sourceforge.io/Doc/Release/Expansion.html for anything mentioning `bindkey`, but couldn't find any. :) > With the c option, sequences like ‘^X’ are also processed. That could be made more "grep-able". In general, I think that page could really use a "reverse" index. Listing parameter flags by letter only doesn't really help in finding anything. Believe me, I've tried.
On 8/7/21, Marlon Richert <marlon.richert@gmail.com> wrote:
> On Fri, Aug 6, 2021 at 3:55 AM Mikael Magnusson <mikachu@gmail.com> wrote:
>>
>> On 8/6/21, Bart Schaefer <schaefer@brasslantern.com> wrote:
>> > On Wed, Aug 4, 2021 at 11:18 PM Marlon Richert
>> > <marlon.richert@gmail.com>
>> > wrote:
>> >>
>> >> I just wish {a..z} didn't use quoting at all. :)
>> >
>> > Re-reading the doc for this, {a..z} is guaranteed to produce PRINTABLE
>> > output, which is not true of the other variations of brace expansion.
>>
>> If you want to expand these printable representations to the actual
>> codepoints, you can use (g:ce:) .
>
> Thanks! I had been looking through
> https://zsh.sourceforge.io/Doc/Release/Expansion.html for anything
> mentioning `bindkey`, but couldn't find any. :)
>
>> With the c option, sequences like ‘^X’ are also processed.
>
> That could be made more "grep-able".
>
> In general, I think that page could really use a "reverse" index.
> Listing parameter flags by letter only doesn't really help in finding
> anything. Believe me, I've tried.
It is indeed always useful when the manpage happens to mention the
exact thing you're looking for, but if it did this in all places and
for everything everyone was looking for, it would be quite a bit
longer :). The documentation for the print builtin also doesn't
mention bindkey, which is why I didn't mention it in the documentation
for g::. The code also doesn't reference bindkey here, fwiw:
case 'e':
getkeys |= GETKEY_EMACS;
break;
case 'o':
getkeys |= GETKEY_OCTAL_ESC;
break;
case 'c':
getkeys |= GETKEY_CTRL;
break;
(although GETKEYS_BINDKEY used presumably for bindkey, is defined as
the combination of exactly those three flags).
--
Mikael Magnusson
On Sun, Aug 8, 2021 at 3:09 AM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> The documentation for the print builtin also doesn't
> mention bindkey
The documentation for print does, in fact, mention bindkey:
-b Recognize all the escape sequences defined for
the bindkey command, see the section `Zle Builtins' in zshzle(1).
Can we give canonical names to these different styles of escape
sequences? That would make it easier to grep for them in the docs.