Re: [dev] [PATCH] Disable buffering of stdin in sic

2014-12-22 Thread Anselm R Garbe
Hi Troels, On 3 December 2014 at 15:13, Troels Henriksen wrote: > If several lines are given to the stdin of sic in a single write() call > (by whatever is controlling sic), only the first line will be seen by > sic until the stdin file descriptor is triggered the next time. This is > due to int

Re: [dev] [PATCH] [lsw] Ensure buf[] is always null-terminated after strncpy()

2014-12-22 Thread Anselm R Garbe
On 1 December 2014 at 21:19, Dimitris Papastamos wrote: > On Mon, Dec 01, 2014 at 08:09:40PM +, Dimitris Papastamos wrote: >> if(!XmbTextPropertyToTextList(dpy, &prop, &list, &n) && n > 0) { >> strncpy(buf, list[0], sizeof buf); >> XFreeStringList(list); >> -

[dev] hackers@ update for suckless maintainers

2014-12-22 Thread Dimitris Papastamos
Hi everyone, I have now updated the git hook that emails out the pushed patches to hack...@suckless.org and it can now handle multiple patches with a single push. The order of delivery is not guaranteed but it tries its best to send them in the proper order. We could perhaps add a small delay be

[dev] [dmenu] [PATCHES 1-5] Changes and cleanup

2014-12-22 Thread FRIGN
Good evening, I sat down this afternoon to read through the dmenu-code and noticed some things that I fixed with attached patches. PATCH 1: Use estrtol instead of atoi to make input-checks more thorough PATCH 2: Un-boolify according to what I already did in some other repos PATCH 3: config.def.h

[dev] proposal to use mdoc(7)

2014-12-22 Thread Dimitris Papastamos
Hi everyone, I'd like to hear your opinion on mdoc(7). I've already started converting the sbase manpages to the mdoc language. As an example compare the converted grep[0] to the older grep[1]. The mandoc(1) tool also has the ability to convert from mdoc(7) to man(7) by doing mandoc -Tman grep.

Re: [dev] [dmenu] [PATCHES 1-5] Changes and cleanup

2014-12-22 Thread Eric Pruitt
On Mon, Dec 22, 2014 at 06:40:59PM +0100, FRIGN wrote: > PATCH 4: As already discussed style(9) is the reference for future code > changes. Given the codebase hasn't already been transformed, I > did it. Although I think sticking to a specific style going forward is reasonable (e