[9base] add read -c

          With the -c flag, read copies exactly nbytes of characters
          instead of lines. It is mutually exclusive with -n and -m
          flag.

-sl

diff -r c6943e63621b read/read.1
--- a/read/read.1	Thu Apr 19 18:17:26 2012 +0100
+++ b/read/read.1	Mon Jul 02 13:41:08 2012 -0500
 <at>  <at>  -9,6 +9,9  <at>  <at> 
 .br
 .B read
 [
+.B -c
+] [
+[
 .B -m
 ] [
 .B -n
 <at>  <at>  -62,6 +65,18  <at>  <at> 
 .I nline
 lines.
 .PP
+With the
+.B -c
+flag,
+.I read
+copies exactly
+.I nbytes
+of characters instead of lines. It is mutually exclusive with

[dmenu] multiple menu patch

Hello, guys!

I'd like to share my patch for dmenu which enables multiple menus
option.

WHAT IT DOES
Multiple menus allow you to see and choose many options
during one dmenu run. It looks like this:
http://s1.ipicture.ru/uploads/20120702/s6YyU3zR.png
After you press Enter all selected items will be printed to console.

MOTIVATION
I have a small wrapper for scrot on bash which asks some
questions before taking a screenshot. The questions such as: take a
screenshot of the region or the whole screen, which filename to use,
delay, save file after publishing or not and so on. Also, I cache
answers for these questions. However, sometimes I need to take a
screenshot with slightly different param and then I have to answer all
questions again even though I want to change only one. With this patch
I can 1) see all questions at once 2) quickly jump to questions I want
to change. I belive this patch is a generalisation and can be useful
in larget set of cases than original dmenu.

WHERE TO GET
You can get it from my repo:

hg clone https://bitbucket.org/balta2ar/dmenu-multiple-menu
cd dmenu-multiple-menu
hg checkout multiple-menu

Re: [dmenu] multiple menu patch

Have you considered multisel?

http://tools.suckless.org/dmenu/patches/multisel
http://tools.suckless.org/dmenu/patches/multiselect_and_newline

Re: [dmenu] multiple menu patch

Yes and it's only half of what I need.
It still presumes there is only one menu.
My patch shows many of them one after another on the screen.

On Tue, Jul 3, 2012 at 11:40 AM, Bjartur Thorlacius
<svartman95 <at> gmail.com> wrote:
> Have you considered multisel?
>
> http://tools.suckless.org/dmenu/patches/multisel
> http://tools.suckless.org/dmenu/patches/multiselect_and_newline
>

Re: github mirror

WDYT of https://github.com/scklss ?

Need to port across the descriptions.

Happy to add more members. Just need your gitub id suckless community member.

Greetings from Berlin,

Re: github mirror

On Tue, Jul 03, 2012 at 12:23:53PM +0200, Kai Hendry wrote:
> WDYT of https://github.com/scklss ?

Is there any point in this other than as a distributed backup?

I worry it may slightly fragment things, with people searching for
dwm and using the github copy, rather than our primary one. Or
sending us github pull requests rather than patches.

Re: github mirror

On 3 July 2012 12:47, Nick <suckless-dev <at> njw.me.uk> wrote:
> Is there any point in this other than as a distributed backup?
> I worry it may slightly fragment things, with people searching for
> dwm and using the github copy, rather than our primary one. Or
> sending us github pull requests rather than patches.

Well I'm hoping for more, since I quite like the github BTS and UI.

Depends on how many of suckless authors I can convince to take an
interest. ;) Don't think it would work if I'm some sort of proxy.

I think the github UI has some value at least.
https://github.com/scklss/dwm/graphs/

I'll work on a  <at> daily cronjob that will hopefully keep it synced.

Re: github mirror

I don't have a strong opinion on this either way.  The current setup works for me.  However bitbucket both
offers mercurial, and the suckless namespace is currently free.  Might be an easier, and more sensible fit
regarding a mirror.

On Jul 3, 2012, at 5:54 AM, Kai Hendry wrote:

> On 3 July 2012 12:47, Nick <suckless-dev <at> njw.me.uk> wrote:
>> Is there any point in this other than as a distributed backup?
>> I worry it may slightly fragment things, with people searching for
>> dwm and using the github copy, rather than our primary one. Or
>> sending us github pull requests rather than patches.
> 
> Well I'm hoping for more, since I quite like the github BTS and UI.
> 
> Depends on how many of suckless authors I can convince to take an
> interest. ;) Don't think it would work if I'm some sort of proxy.
> 
> 
> I think the github UI has some value at least.
> https://github.com/scklss/dwm/graphs/
> 
> 
> I'll work on a  <at> daily cronjob that will hopefully keep it synced.
> 

fceux in fullscreen

I'm sorry, I know similar questions have been posted before, but I
cannot seem to find my way around this issue: when I use fceux's
fullscreen option, a black square occupies part of the upper left corner
of the screen. While in fullscreen, dwm keybindings are unresponsive.

Also, this square is slightly bigger than the unmaximized fceux, so I
don't really know where is that coming from. How can I get it out of the
way?

Thanks,
Manolo

--

-- 

Re: github mirror

i have recently moved some of my repos to github, because some
people wanted to contribute via github with pull requests, so i used
hgpull to do it. here's the notes:

*) git repo was 8 times bigger than the hg one after export (git gc 
--aggressive fixes this)
*) every merge of a pull request results into a new branch and head 
which forces hggit to create another new branch+merge.
*) unrelated heads everywhere
*) i have finally moved to git. git is bloated, but at least it's not python
*) after aggressive gc, git repo is 6MB, while hg is 15MB

I tried once to make a smaller git by reusing the git's source code.. 
but this seems like an impossible task as long
as the source have big dependencies with itself, so you can't easily 
strip down the code. (git is almost 20MB installed).

I discussed in irc about rewriting hg in C, but they just lold and make 
fun on it saying i was trolling. those
kind of reactions doesn't happen in #git.

so.. what do you think about creating a suckless git client?

On 07/03/12 15:44, Micheal Smith wrote:
> I don't have a strong opinion on this either way.  The current setup works for me.  However bitbucket both
offers mercurial, and the suckless namespace is currently free.  Might be an easier, and more sensible fit
regarding a mirror.
>
> On Jul 3, 2012, at 5:54 AM, Kai Hendry wrote:
>