Re: [dev] [st PATCH 1/3] xloadcols: remove cp variable

2015-04-23 Thread Martti Kühne
On Wed, Apr 22, 2015 at 4:14 PM, Garrick Peterson wrote: [...] >> for (cp = dc.col; cp < &dc.col[LEN(dc.col)]; ++cp) > > Forgive my ignorance of the LEN macro, but doesn’t this rely on accessing a > memory address outside of the allocated array? Wouldn’t that cause problems > if you’re up

Re: [dev] Updated history patch

2015-04-23 Thread koneu
On April 24, 2015 3:04:42 AM CEST, Mark Goldman wrote: >Hey everyone, the history patch didn't seem to apply cleanly so >manually updated the patch to apply cleanly as of commit 13a529c. How >can I get the new patch out to others who might want it? > >-mdg Push it to [0]. (0) git.suckless.org/s

[dev] Updated history patch

2015-04-23 Thread Mark Goldman
Hey everyone, the history patch didn't seem to apply cleanly so manually updated the patch to apply cleanly as of commit 13a529c. How can I get the new patch out to others who might want it? -mdg -- Our problems are mostly behind us, now all we have to do is fight the solutions.

Re: [dev] [surf] [PATCH] Simplify eval arg handling

2015-04-23 Thread koneu
Jochen Sprickerhof wrote: > * Jason Woofenden [2015-04-23 14:36]: > > Both implementations (before and after your patch) pass a char*. > > But (assuming I'm reading the code correctly) they don't pass the > > same address. > > True, the old one assumes a char** (an array of strings), whereas the

Re: [dev] [surf] [PATCH] Simplify eval arg handling

2015-04-23 Thread Jochen Sprickerhof
* Jason Woofenden [2015-04-23 14:36]: > Both implementations (before and after your patch) pass a char*. > But (assuming I'm reading the code correctly) they don't pass the > same address. True, the old one assumes a char** (an array of strings), whereas the new one assumes a char*, i.e., string.

Re: [dev] [surf] [PATCH] Simplify eval arg handling

2015-04-23 Thread Jason Woofenden
On 2015-04-23 08:06PM, Jochen Sprickerhof wrote: > Ok, it does make sense, I had overlooked it because eval() is usually > not called. The arg->v is passed to evalscript() which expects an char*. Both implementations (before and after your patch) pass a char*. But (assuming I'm reading the code co

Re: [dev] making releases

2015-04-23 Thread FRIGN
On Thu, 23 Apr 2015 18:28:45 +0100 Nick wrote: > I know several people here (who do more good work than me) think > that, but I disagree. I like not upgrading my software particularly > often if it doesn't have any bugs I care about in it, so I find it > easier to have some releases every so o

Re: [dev] [surf] [PATCH] Simplify eval arg handling

2015-04-23 Thread Jochen Sprickerhof
Ok, it does make sense, I had overlooked it because eval() is usually not called. The arg->v is passed to evalscript() which expects an char*. Cheers Jochen signature.asc Description: Digital signature

Re: [dev] making releases

2015-04-23 Thread Nick
Quoth Dimitris Papastamos: > Use upstream dmenu, port the patches if they do not already work and > submit them to the wiki. > > Packaging suckless software is useless. I know several people here (who do more good work than me) think that, but I disagree. I like not upgrading my software particu

Re: [dev] dmenu history

2015-04-23 Thread Dimitris Papastamos
On Thu, Apr 23, 2015 at 04:39:26PM +0100, maeve.ul...@openmailbox.org wrote: > http://tools.suckless.org/dmenu/patches/dmenu-tip-history.diff via > http://tools.suckless.org/dmenu/patches/history > > does not work with > > http://ftp.de.debian.org/debian/pool/main/s/suckless-tools/suckless-tools_

[dev] dmenu history

2015-04-23 Thread maeve . uladh
http://tools.suckless.org/dmenu/patches/dmenu-tip-history.diff via http://tools.suckless.org/dmenu/patches/history does not work with http://ftp.de.debian.org/debian/pool/main/s/suckless-tools/suckless-tools_40.orig-dmenu.tar.gz via https://packages.debian.org/jessie/suckless-tools Also, co

Re: [dev] [st] [PATCH] Optimize memory footprint of line buffers

2015-04-23 Thread suigin
On Wed, Apr 22, 2015 at 05:26:37AM -0700, suigin wrote: > > Another solution would be to allow people to typedef the color index > > type used by Glyph in config.h, and move the definitions for Glyph, > > TCursor and Term below where config.h is included in st.c? > > > > That way, it makes it easy