Re: [dev] Re: [libutf] Proposal for additional rune utility functions

From: FRIGN <>
Date: Wed, 11 Feb 2015 21:48:22 +0100

On Wed, 11 Feb 2015 20:29:49 +0000
Connor Lane Smith <> wrote:

Hey Connor,

> I've added these proposed functions, and done some other work too, on
> my GitHub repo [1], which is where I maintain libutf now that I no
> longer contribute particularly regularly. Please feel free to send me
> any other patch proposals, either directly or via this mailing list
> (preferably with a CC).

there's no need for a separate GitHub-repo. You are the maintainer and
have the right to push your stuff to suckless, and at least I personally
would really like to see the fresh changes here on rather
than some GitHub 0815 repository.

I don't know if you're subscribed to, but a lot of
things happened today in sbase's internal libutf.

runetype and case-conversion

I hacked on the mkrunetype.awk a lot and modified it so that it
generates is*rune.c's, lowerrune.c and upperrune.c.
The reasoning behind this is binary size, as discussed earlier. You can
see the result here[0].
Whereas the old implementation only supported the is*rune-checks, I
reworked the parser so that it now automatically generates the case-
conversion-functions "toupperrune()" and "tolowerrune()" from the
UnicodeData.txt as well.

proposed functions

I implemented your functions 1 to 1 as you wrote them, except fgetrune()
[1], which I saw could even be built in a simpler way. I hope you don't
take it personally. ;)
As soon as you mentioned, I've been very excited about the idea, that
libutf is self-sufficient without malloc. It also makes the code much
cleaner, when the malloc happens in the code itself rather than in some
magic function in the background.

As always, the efgetrune() and efputrune() functions are additions for
sbase and are not meant for merging into sbase.
Please let me know what you think.

I can't stress this enough: Please move your work back to the repository. It's only harder to work on three separate
repositories, as we would be much more efficient working on one
Our plan for sbase is to keep a slightly modified version of libutf
internally, but push all additions to the main repo on suckless,
after they have been discussed on the ml.




Received on Wed Feb 11 2015 - 21:48:22 CET

This archive was generated by hypermail 2.3.0 : Wed Feb 11 2015 - 22:00:11 CET