Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Qmail-Scanner-Diagnostics: from mail-pf0-f172.google.com by f.primenet.com.au (envelope-from <schaefer@brasslantern.com>, uid 7791) with qmail-scanner-2.11 
 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1.  
 Clear:RC:0(209.85.192.172):SA:0(0.0/5.0):. 
 Processed in 0.135105 secs); 22 Jul 2016 15:51:47 -0000
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=T_DKIM_INVALID
	autolearn=unavailable autolearn_force=no version=3.4.1
X-Envelope-From: schaefer@brasslantern.com
X-Qmail-Scanner-Mime-Attachments: |
X-Qmail-Scanner-Zip-Files: |
Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=brasslantern-com.20150623.gappssmtp.com; s=20150623;
        h=from:message-id:date:in-reply-to:comments:references:to:subject
         :mime-version;
        bh=YQlB8orOGpcz62D9b/OmB+knPAnqaLJMdFaCB8SdCEY=;
        b=uEeXPQsk/ZU1+aOTDiKN5VSWPDFbMbK2LZZzgbf5HeNXmRBLMZ/hLBEiM0mHSBDP0k
         fLzPIr01KjpIrt7k8anap+5MVvF1ORUnOUkzBZP19Mm82/IVYKmxK2Sa2kZBCOrEVQ5C
         X/Wbndc7C0CEIOLlj+I7Q3qDIhkL3borfmzeWQUmlkmZrQZjFmDbZehRk09VEDKOz6P5
         4b1/t/R6oZBcCWiPIAMWGouca1mtfOZDE9tYQ7MjCAGw5G34IGLjDmlg/zfcE+jCIvc3
         RwfWTqaf7J5n00BJPjdBdVoVaUxoD0Iz1Pm1JPcDSWXnmvcZ8mpWYbwP/uhbmAAUBzDx
         6vVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:from:message-id:date:in-reply-to:comments
         :references:to:subject:mime-version;
        bh=YQlB8orOGpcz62D9b/OmB+knPAnqaLJMdFaCB8SdCEY=;
        b=AXc22qIltS1sfm2t4bUclvNN/TijtPd1xEGMGUS5jdDHi9e/ojduwC+xMrmPI7eeAY
         xET75lnTh7TwS/QyAi9LzYbRZmUSesC5BhCOs0I4dtrRBkLD3U2JhEZpQBRkDczsT1i6
         Za+PyxiOPH3rx+G69rK8qj/5khOjJuhn7TCs+QZi5WuePLcQIjfGG3SDQrCVMDG5IZSQ
         QSA36g0DMtmnUe22AD68xvrWfgC46inYJLJvrzZafCG3CQU7SBaHHsoBqMlaKVE8Xlrq
         hFy4eAYrAG4JFMKUJWXeZmJLtUjNiCXD5xT3PDi2cvVxvGpeIhevXolK/4i/7GqP5nyQ
         nI5Q==
X-Gm-Message-State: AEkooutgdpvydHb41rdFrMzWGi1rsfb6GX/Eeix8YPPcK7jpNYzTW7tUIQggQ33SMurYbg==
X-Received: by 10.98.14.208 with SMTP id 77mr7581333pfo.23.1469202701141;
        Fri, 22 Jul 2016 08:51:41 -0700 (PDT)
From: Bart Schaefer <schaefer@brasslantern.com>
Message-Id: <160721173805.ZM31148@torch.brasslantern.com>
Date: Thu, 21 Jul 2016 17:38:05 -0700
In-Reply-To: <20160720093515.07cedcdc@pwslap01u.europe.root.pri>
Comments: In reply to Peter Stephenson <p.stephenson@samsung.com>
        "Re: Incorrect sorting of Polish characters" (Jul 20,  9:35am)
References: <CAJzQX7rXddxjFA2reSiGYHpU9Razo2vwO5F5g-4Ddz-ZjXZsUQ@mail.gmail.com> 
	<160716130718.ZM4513@torch.brasslantern.com> 
	<20160718103329.7acbb1b1@pwslap01u.europe.root.pri> 
	<20160718111735.6adea125@pwslap01u.europe.root.pri> 
	<160719220508.ZM10438@torch.brasslantern.com> 
	<20160720093515.07cedcdc@pwslap01u.europe.root.pri>
X-Mailer: OpenZMail Classic (0.9.2 24April2005)
To: zsh-workers@zsh.org
Subject: Re: Incorrect sorting of Polish characters
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Seq: zsh-workers 38917

On Jul 20,  9:35am, Peter Stephenson wrote:
} Subject: Re: Incorrect sorting of Polish characters
}
} On Tue, 19 Jul 2016 22:05:08 -0700
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > Hm.  On a glob of 16794 files it's about 4% slower over 10 trials with
} > the extra pass over the array of matches.  I don't suppose there's some
} > way to store the original file name at the time metafication is applied
} > rather than metafying and then unmetafying again?
} 
} It already works like that, and it only copies and unmetafies if there's
} a Meta character.

What I meant was (now that I have poked around a bit further), maybe
zreaddir() should be able to return unmetatfied strings on request,
which scanner() could then metafy before calling pattry() and when a
match is found, pass both to insert() ?

Seems wasteful for zreaddir() to unconditionally metafy when the
caller may need the name unmetafied.  However, this does mean passing
both strings through a lot of layers, so maybe not worth it for 4%.

The strchr() does shave it down a fraction.

