Re: ( Text in unknown character set UTF-8 not shown )

Re: ( Text in unknown character set UTF-8 not shown )

[ZyX]

[-- Attachment #1: Type: Text/Plain, Size: 1101 bytes --]

Reply to message «Re: ( Text in unknown character set UTF-8 not shown )», 
sent 10:17:21 23 December 2010, Thursday
by Bart Schaefer:

> I believe the reasoning is that double-quote is allowed to appear
> inside $'...' and to expand $'...' inside double-quotes creates a
> parsing conflict.  "How does this $'with " embeded' parse?"
"How does this $'with " embeded' parse?"
"Just like this `with " embedded` parse."
There are no parsing conflicts here, but
> Because it doesn't in any of the shells that introduced it before
> zsh had it.
is legitimate enough for me because it helps porting scripts from/to zsh.

> } It's not, as far as I can tell, mentioned in the documentation.
> 
> The documentation for zsh tends to omit things that are assumed
> knowledge, particularly when a concept or feature originates from
> another source -- because if you didn't already know about it from
> the original source, why did you even think to use it?
But when I worked in bash I knew nothing about $'...' (because I even did not 
know where to find documentation to tweak my inputrc).

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Why does $'' not expand inside ""?

[Bart Schaefer]

On Dec 23,  8:41pm, ZyX wrote:
} Subject: Re: ( Text in unknown character set UTF-8 not shown )

Sorry about that weird subject.

} > I believe the reasoning is that double-quote is allowed to appear
} > inside $'...' and to expand $'...' inside double-quotes creates a
} > parsing conflict.  "How does this $'with " embeded' parse?"
} "How does this $'with " embeded' parse?"
} "Just like this `with " embedded` parse."

Ah, but backticks were already present in the shell.  The conflict is
with "How did this $'with " embedded' parse before $'existed'?"

} > The documentation for zsh tends to omit things that are assumed
} > knowledge, particularly when a concept or feature originates from
} > another source -- because if you didn't already know about it from
} > the original source, why did you even think to use it?
} But when I worked in bash I knew nothing about $'...' (because I
} even did not know where to find documentation to tweak my inputrc).

Entirely understandable nowadays, but much of the zsh doc was written
when zsh was always the shell to which someone switched from another
shell with which they were already familiar.  That's not the case as
often any more now that zsh is packaged with several OS dists, and is
not the case for $'...', but the tendency to write that way remains.

_multi_parts -f doesn’t seem to have any effect

[Nikolai Weibull]

_multi_parts -f doesn’t seem to have any effect.  At least note the
one I care about, which is to apply colors to different file types.
Is this a known issue?

Re: ( Text in unknown character set UTF-8 not shown )

[Bart Schaefer]

On Nov 13,  4:07pm, Nikolai Weibull wrote:
}
} _multi_parts -f doesn't seem to have any effect.  At least note the
} one I care about, which is to apply colors to different file types.
} Is this a known issue?

It defintely passes -f through to compadd, so you're going to have to
be a bit more specific.  However, there are likely to be two combined
effects at work here.

(1) File type coloring is applied only to files that can be examined
with stat(2), unless you have some pattern-match colorings defined.

(2) _multi_parts treats each "component" of the string it breaks up as
an independent match, so it passes the prefix from the line to compadd
using -P rather than -W.

The result is that _multi_parts can only apply file coloring in cases
where there is no path prefix, i.e., files in the current directory.

Which, IIRC, is why _path_files exists in the first place.