Re: [dev][surf] searchengine patch against surf git tip

2013-01-05 Thread Hiltjo Posthuma
On Fri, Jan 4, 2013 at 10:44 PM, Carlos Torres wrote: > http://sprunge.us/QMMS > > someone requested that on IRC and i had it. > > Enjoy! > You can also use shellscripting and do something like this: #!/bin/sh read input token=$(printf "%s" "$input" | cut -b 1-2) stuff=$(printf "%s" "$input" |

[dev] [ii] 1.7 release

2013-01-05 Thread Nico Golde
Hey, way too late, but I just wrapped up the current git head of ii[0] to an 1.7 release. The archive is available at [1]. 1.7 (2013-01-05) - -k now specifies an environment variable that contains the server key. This behaviour has been changed in order to not expose the password

Re: [dev] [st] font fallback

2013-01-05 Thread Charlie Kester
On 12/29/2012 12:20 AM, Kai Hendry wrote: Initially I was worried that the newer version was somehow slower to the version I was running before. Not slower, but definitely bigger. The stripped executable is now 16x the size of that from the 0.3 release -- thanks, no doubt, to these font cach

Re: [dev] [st] font fallback

2013-01-05 Thread Christoph Lohmann
Greetings. On Sat, 05 Jan 2013 15:57:21 +0100 Charlie Kester wrote: > On 12/29/2012 12:20 AM, Kai Hendry wrote: > > Initially I was worried that the newer version was somehow slower to > > the version I was running before. > > Not slower, but definitely bigger. The stripped executable is now 16

Re: [dev] [st] font fallback

2013-01-05 Thread Charlie Kester
On 01/05/2013 06:57 AM, Christoph Lohmann wrote: Greetings. On Sat, 05 Jan 2013 15:57:21 +0100 Charlie Kester wrote: On 12/29/2012 12:20 AM, Kai Hendry wrote: Initially I was worried that the newer version was somehow slower to the version I was running before. Not slower, but definitely bi

Re: [dev][surf] searchengine patch against surf git tip

2013-01-05 Thread Carlos Torres
Thanks hiltjo! On Jan 5, 2013 7:29 AM, "Hiltjo Posthuma" wrote: > On Fri, Jan 4, 2013 at 10:44 PM, Carlos Torres > wrote: > > http://sprunge.us/QMMS > > > > someone requested that on IRC and i had it. > > > > Enjoy! > > > > You can also use shellscripting and do something like this: > > #!/bin/s

Re: [dev] [st] font fallback

2013-01-05 Thread Charlie Kester
On 01/05/2013 07:33 AM, Charlie Kester wrote: On 01/05/2013 06:57 AM, Christoph Lohmann wrote: Greetings. On Sat, 05 Jan 2013 15:57:21 +0100 Charlie Kester wrote: On 12/29/2012 12:20 AM, Kai Hendry wrote: Initially I was worried that the newer version was somehow slower to the version I was r

Re: [dev] [st] font fallback

2013-01-05 Thread Christoph Lohmann
Greetings. On Sat, 05 Jan 2013 18:55:12 +0100 Charlie Kester wrote: > Of course, some growth is expected as new features are added, but going > from 38k to 618k is hard to swallow. On my system: % ls -hs st-0.3/st 126K st % strip st-0.3/st && ls -hs st-0.3/st 48

Re: [dev] [st] font fallback

2013-01-05 Thread Carlos Torres
On Jan 5, 2013 1:21 PM, "Christoph Lohmann" <2...@r-36.net> wrote: > > What are the list's opinions? > Extract the keys to another header, categorize keys somehow, add defines in config.mk to include/exclude different category keys. Or document defines in readme. Possible categories: EXTENDED_FN,

Re: [dev] [st] README/Makefile cleanup

2013-01-05 Thread Christoph Lohmann
Greetings. On Sat, 05 Jan 2013 20:31:13 +0100 Peter Hartman wrote: > Attached. Thanks, the changes were applied. Sincerely, Christoph Lohmann

Re: [dev] [st] font fallback

2013-01-05 Thread Charlie Kester
On 01/05/2013 09:55 AM, Christoph Lohmann wrote: Greetings. On Sat, 05 Jan 2013 18:55:12 +0100 Charlie Kester wrote: Of course, some growth is expected as new features are added, but going from 38k to 618k is hard to swallow. On my system: % ls -hs st-0.3/st 126K st

Re: [dev] [st] font fallback

2013-01-05 Thread Roberto E. Vargas Caballero
> >That’s only partially true. The array is adding 48k, which another patch > >series will reduce. Most of the additional memory usage is due to the > >font handling. So the inability of font handling in X.org/Fontconfig is > >the reason why too much has to be done over and over again. Yet ano