From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, NICE_REPLY_A autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 17213 invoked from network); 26 Mar 2023 03:31:34 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 26 Mar 2023 03:31:34 -0000 Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Sat Mar 25 23:26:12 -0400 2023 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1679801507; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=40a+RPs9quGfgdoHIFKfGe16OFyup6l/zu0kYNm6lMo=; b=Kou1z1ZNHaET6qAJvTe+3aQMQqeOVAjjZJK37t7WJk1YTPYlGj1nyBQsVj4ENYPmvPae5E hUWhXHXmo2TudgcNE4FVhy1tgD7M7XHFvGkspML7YdhjIyPpy/nvPdmn8y2aCMZEYS/lql 1WCgEbn7rUCTKbjpSyELcTOK5dkYHuI= Received: from [192.168.168.200] (161-097-205-025.v4.mynextlight.net [161.97.205.25]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id 958d4200 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Sat, 25 Mar 2023 22:31:47 -0500 (CDT) Message-ID: Date: Sat, 25 Mar 2023 21:25:31 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Content-Language: en-US To: 9front@9front.org References: <1AB7C1C576671B627BD6B552AA0E826C@gaff.inri.net> From: Jacob Moody In-Reply-To: <1AB7C1C576671B627BD6B552AA0E826C@gaff.inri.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: interface method scripting controller Subject: Re: [9front] Re: removal of /lib/unicode Reply-To: 9front@9front.org Precedence: bulk On 3/25/23 21:05, sl@stanleylieber.com wrote: >> /lib/unicode was removed in favor of just using the upstream data file >> it was ripped from. I have updated the references in the man pages >> to reflect this. I apologize for that mistake. > > ah. no problem, i was just curious what was going on. i'll never > remember the new file path off the top of my head, but on the other > hand i guess i'm not manually checking /lib/unicode all that often > anyway. > > why didn't we just have the mkfile put the information in the original > place? Yes a couple reasons. /lib/unicode only included those in the 16bit BMP domain. When extending this to include all the modern code points you need more hex digits. Unless you went with using two different zero padded first columns. I could not find a good way of updating these for things past the BMP and not breaking someone's script. Likewise /lib/unicode while derived from UnicodeData.txt does not include the data fields that are needed to do the generation. So either way I was going to need to update each line of the file anyway. I figured to instead just say 'we use the official txt file' is bit nicer in my opinion. Likewise other files were desired for the generation, so moving things to a directory seemed to make more sense.