[9fans] NFD and p9p acme on OSX

[9fans] NFD and p9p acme on OSX

[Mark van Atten]

Running p9p on OSX, I find it useful to put this in my rc profile:

fn ls {
builtin ls $* | iconv -f UTF8-MAC -t UTF-8
}

fn lc {
builtin lc $* | iconv -f UTF8-MAC -t UTF-8
}

so as to deal with the NFD used by the OSX file system and list
names containing non-ascii characters correctly.

But this doesn't solve the corresponding problem when clicking B3 to
open a directory in acme.

Am I overlooking something? If not, what do people use to deal with
this---perhaps a patch to lib9?

Mark.

Re: [9fans] NFD and p9p acme on OSX

[erik quanstrom]

On Thu Sep 12 05:41:19 EDT 2013, vanattenmark@gmail.com wrote:
> Running p9p on OSX, I find it useful to put this in my rc profile:
>
> fn ls {
> builtin ls $* | iconv -f UTF8-MAC -t UTF-8
> }
>
> fn lc {
> builtin lc $* | iconv -f UTF8-MAC -t UTF-8
> }
>
> so as to deal with the NFD used by the OSX file system and list
> names containing non-ascii characters correctly.
>
> But this doesn't solve the corresponding problem when clicking B3 to
> open a directory in acme.
>
> Am I overlooking something? If not, what do people use to deal with
> this---perhaps a patch to lib9?

i created something similar for plan 9.  it uses runecompose
(see runeclass(2), http://9atom.org/magic/man2html/2/runeclass)
this uses tables built by awk scripts directly from unicodedata.txt.
there is a rune/compose (see rune(1), http://9atom.org/magic/man2html/1/rune)
that makes it possible to write
	fn lc {builtin lc $* | rune/compose}

but i agree, one would like a more systemic solution.  cooking this
into stat/wstat wouldn't work, because the file name text might escape
p9p and cause the rest of the system to be confused.

perhaps runecompose and runedecompose (or equivalent) could be
cooked into fullrune, chartorune, runetochar, etc.  (for apple oses only?)
the big pain point would be dealing with the fact that chartorune
could create up to maxcombiners*4 bytes of utf-8, and fullrune might
need that size buffer to convert one rune.  it's easy to grep for these
use cases.

- erik

Re: [9fans] NFD and p9p acme on OSX

[Mark van Atten]

Thank you, Erik, for your comments!

I just realized that in

fn ls {
builtin ls $* | iconv -f UTF8-MAC -t UTF-8
}

one needs

u iconv

because otherwise it picks the wrong iconv when executing this
redefined ls in contexts where $PLAN9/bin occurs in the path first;
for example, try

9 man cat

with the uncorrected redefinition of ls.

As ever,
Mark.



On Thu, Sep 12, 2013 at 4:17 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Thu Sep 12 05:41:19 EDT 2013, vanattenmark@gmail.com wrote:
>> Running p9p on OSX, I find it useful to put this in my rc profile:
>>
>> fn ls {
>> builtin ls $* | iconv -f UTF8-MAC -t UTF-8
>> }
>>
>> fn lc {
>> builtin lc $* | iconv -f UTF8-MAC -t UTF-8
>> }
>>
>> so as to deal with the NFD used by the OSX file system and list
>> names containing non-ascii characters correctly.
>>
>> But this doesn't solve the corresponding problem when clicking B3 to
>> open a directory in acme.
>>
>> Am I overlooking something? If not, what do people use to deal with
>> this---perhaps a patch to lib9?
>
> i created something similar for plan 9.  it uses runecompose
> (see runeclass(2), http://9atom.org/magic/man2html/2/runeclass)
> this uses tables built by awk scripts directly from unicodedata.txt.
> there is a rune/compose (see rune(1), http://9atom.org/magic/man2html/1/rune)
> that makes it possible to write
>         fn lc {builtin lc $* | rune/compose}
>
> but i agree, one would like a more systemic solution.  cooking this
> into stat/wstat wouldn't work, because the file name text might escape
> p9p and cause the rest of the system to be confused.
>
> perhaps runecompose and runedecompose (or equivalent) could be
> cooked into fullrune, chartorune, runetochar, etc.  (for apple oses only?)
> the big pain point would be dealing with the fact that chartorune
> could create up to maxcombiners*4 bytes of utf-8, and fullrune might
> need that size buffer to convert one rune.  it's easy to grep for these
> use cases.
>
> - erik
>