Re: [dev] new pre-patched version of dwm available

2016-07-31 Thread Eric Pruitt
On Sun, Jul 31, 2016 at 08:26:36AM +0200, Jan Christoph Ebersbach wrote:
> Have you tried to increase patch's fuzz factor with the --fuzz option in
> order to achieve the same result?

I messed tried messing with the fuzzing factor, but I had some patches
apply in wrong place. I am not certain because it's been a while since I
tried this, but I want to say the problem was generally caused by code
that's often repeated e.g. for loops for counting windows or iterating
over monitors. I just ran dwm.c through "sort | uniq -c | sort -n," and
"for (m = mons; m; m = m->next)" appears at least 6 times.

> I never used the rebase model described in the customization section.
> Since you know both ways, why did you switch to patch files?

I've actually tried three approaches: (1) the rebase my own tree onto
the suckless one, (2) patches alongside the dwm source code and my
current approach which is (3) patches completely divorced from the dwm
repository. With the first two approaches, I found dealing with
patch-breaking updates far too tedious especially when patches were
dependent on one another. My config.mk also differed from the suckless
one, so I generally had to review it and manually adjust the
corresponding flags in my file. There are several things I like about
using patches and an external dwm repository, but some this also applies
to (2):

- When dwm gets updated, I can work on one patch at a time in almost any
  order (of my 16 dwm patches, only 2 have dependencies while the
  remaining 14 can be applied with or without the other).

- Because of how my build system works, I can temporarily disable a
  patch by simply renaming it from *.diff to something like *.diff.x
  because the Makfile target only globs for *.diff. I often use vidir
  (https://joeyh.name/code/moreutils/) to do this with multiple patches.

- Similarly, if I want to discard a patch because I don't use it or the
  functionality has been accepted upstream, I don't have to use "git
  revert" and hunt for all changes related to a specific feature and
  hope there are no dependency issues. Instead, I just "git rm" the diff
  file and call it a day.

Eric


signature.asc
Description: Digital signature


Re: [dev] new pre-patched version of dwm available

2016-07-30 Thread Jan Christoph Ebersbach
On Sun 24-07-2016 20:42 -0700, Eric Pruitt wrote:

> On Sat, Jul 23, 2016 at 05:21:42PM +0200, FRIGN wrote:
> > It's a difficult matter because patches interfere. I know of no way
> > to make multiple patches inclusive to each other, in many cases it
> > is not possible.
>
> Something I do with my patches to make them easier manually edit the
> resulting diffs to reduce lines of context for certain chunks. As a
> result, rebasing some of changes on newer versions of dwm becomes a
> little less painful. I will also sometimes write code in a less
> efficient manner if it means I can produce a patch that won't conflict
> with any of my other patches while still applying cleanly to dwm.

Have you tried to increase patch's fuzz factor with the --fuzz option in
order to achieve the same result?

> Up until about a month ago, I kept a copy of the dwm repo that I
> periodically merged with the suckless master tree, but I now keep a
> repository of patches alone that get applied to dwm using a Makefile
> (https://github.com/ericpruitt/mydwm).

I never used the rebase model described in the customization section.
Since you know both ways, why did you switch to patch files?

> More recently, I decided to combine all of my suckless configurations
> and GUI-related programs into a single repo that is yet unpublished
> but works similarly to the aforementioned link. Here's what the
> Makefile for that currently looks like:
> https://gist.github.com/ericpruitt/32f3f8b6c3df903d03f5e95ed8ba3428
> I'm using GNU make and taking advantage of the numerous features it
> provides. I know that monstrosity is far from suckless, but it works
> well, and I've learned a lot about GNU make.

Nice work.  I keep dwm and other suckless tools as submodules in my
personal configuration repositories with simple build and install
scripts.  A central location to update all tools is something I'm
missing in my setup.

Jan Christoph
--
Jan Christoph Ebersbach
I didn’t want some petty, inferior brand of righteousness that comes
from keeping a list of rules when I could get the robust kind that comes
from trusting Christ - God’s righteousness.  Phil 3:9


signature.asc
Description: PGP signature


Re: [dev] new pre-patched version of dwm available

2016-07-26 Thread Britton Kerin
On Sun, Jul 24, 2016 at 7:26 PM, Ben Woolley  wrote:
> I think it is natural for related changes to be consolidated over time. Think 
> of punctuated equilibrium.
>
> Maybe after it is clear that some patches just go well together, fitting a 
> related niche, they could be consolidated to make maintenance easier.

In some cases this might be good.  In others the larger consolidated
patch will be more likely to conflict with others, making it harder for
users to pick and choose their favorite features.

> On Jul 24, 2016, at 12:51 PM, Jan Christoph Ebersbach  wrote:
>> Personally, I'd recommend newbies that want to use a patched version to
>> find someone who's maintaining a "fork".  Maybe these "forks" could be
>> listed in the patches section of the wiki.  What do you think?

I think yes.  I'd call them 'flavors' or "pre-rolled" rather than "forks" since
they would be friendly and aiming for maximum compatibility with other
patches.

It doesn't matter what I think though, and so far no buy-in from the
suckless admins...

Britton



Re: [dev] new pre-patched version of dwm available

2016-07-24 Thread Eric Pruitt
On Sat, Jul 23, 2016 at 05:21:42PM +0200, FRIGN wrote:
> It's a difficult matter because patches interfere. I know of no way to
> make multiple patches inclusive to each other, in many cases it is not
> possible.

Something I do with my patches to make them easier manually edit the
resulting diffs to reduce lines of context for certain chunks. As a
result, rebasing some of changes on newer versions of dwm becomes a
little less painful. I will also sometimes write code in a less
efficient manner if it means I can produce a patch that won't conflict
with any of my other patches while still applying cleanly to dwm.

Up until about a month ago, I kept a copy of the dwm repo that I
periodically merged with the suckless master tree, but I now keep a
repository of patches alone that get applied to dwm using a Makefile
(https://github.com/ericpruitt/mydwm). More recently, I decided to
combine all of my suckless configurations and GUI-related programs into
a single repo that is yet unpublished but works similarly to the
aforementioned link. Here's what the Makefile for that currently looks
like: https://gist.github.com/ericpruitt/32f3f8b6c3df903d03f5e95ed8ba3428
I'm using GNU make and taking advantage of the numerous features it
provides. I know that monstrosity is far from suckless, but it works
well, and I've learned a lot about GNU make.

Eric



Re: [dev] new pre-patched version of dwm available

2016-07-24 Thread Ben Woolley
I think Jan provided insight through experience. That is basically the opposite 
of stupid. 

> On Jul 24, 2016, at 2:09 PM, hiro <23h...@gmail.com> wrote:
> 
> perhaps you want too many stupid things.
> 



Re: [dev] new pre-patched version of dwm available

2016-07-24 Thread Ben Woolley
I think it is natural for related changes to be consolidated over time. Think 
of punctuated equilibrium. 

Maybe after it is clear that some patches just go well together, fitting a 
related niche, they could be consolidated to make maintenance easier. 

> On Jul 24, 2016, at 12:51 PM, Jan Christoph Ebersbach  wrote:
> 
> Hi,
> 
> I also keep a patched version of dwm at github.com/jceb/dwm-patches that
> stacks all the patches in order to smoothly apply them.  This is also
> how I develop my patch using quilt.
> 
> Unfortunately, it's extremely hard to port interwoven patches back to
> mainline.  I have some tooling at github.com/jceb/dwm-clean-patches that
> reduces the pain to the bare minimum but even this is a lot of pain and
> time.
> 
> Personally, I'd recommend newbies that want to use a patched version to
> find someone who's maintaining a "fork".  Maybe these "forks" could be
> listed in the patches section of the wiki.  What do you think?
> 
> Jan Christoph
> 
> PS: I'll update my share of patches in the next 1-2 weeks to the current
> HEAD.
> 
>> On Sat 23-07-2016 17:21 +0200, FRIGN wrote:
>> 
>> On Fri, 22 Jul 2016 13:54:36 -0800 Britton Kerin
>>  wrote:
>> 
>> Hey Britton,
>> 
>>> dwm needs patches to be good but the patches area is a mess and I
>>> couln't get along with devs about fixing it, so I thought a
>>> pre-rolled version of dwm might be useful instead:
>> 
>> you really raise a valid point, fortunately, as you may know, there
>> are proceedings to clean up the wiki and the progress is already
>> pretty good.  It's a difficult matter because patches interfere. I
>> know of no way to make multiple patches inclusive to each other, in
>> many cases it is not possible.  There are some things thought that I'd
>> like to see in mainline, e.g.  removing borders of the window when
>> there's only one window in the current tag.
>> 
>> Cheers
>> 
>> FRIGN
> 
> --
> Jan Christoph Ebersbach
> I didn’t want some petty, inferior brand of righteousness that comes
> from keeping a list of rules when I could get the robust kind that comes
> from trusting Christ - God’s righteousness.  Phil 3:9



Re: [dev] new pre-patched version of dwm available

2016-07-24 Thread hiro
perhaps you want too many stupid things.



Re: [dev] new pre-patched version of dwm available

2016-07-24 Thread Jan Christoph Ebersbach
Hi,

I also keep a patched version of dwm at github.com/jceb/dwm-patches that
stacks all the patches in order to smoothly apply them.  This is also
how I develop my patch using quilt.

Unfortunately, it's extremely hard to port interwoven patches back to
mainline.  I have some tooling at github.com/jceb/dwm-clean-patches that
reduces the pain to the bare minimum but even this is a lot of pain and
time.

Personally, I'd recommend newbies that want to use a patched version to
find someone who's maintaining a "fork".  Maybe these "forks" could be
listed in the patches section of the wiki.  What do you think?

Jan Christoph

PS: I'll update my share of patches in the next 1-2 weeks to the current
HEAD.

On Sat 23-07-2016 17:21 +0200, FRIGN wrote:

> On Fri, 22 Jul 2016 13:54:36 -0800 Britton Kerin
>  wrote:
>
> Hey Britton,
>
> > dwm needs patches to be good but the patches area is a mess and I
> > couln't get along with devs about fixing it, so I thought a
> > pre-rolled version of dwm might be useful instead:
>
> you really raise a valid point, fortunately, as you may know, there
> are proceedings to clean up the wiki and the progress is already
> pretty good.  It's a difficult matter because patches interfere. I
> know of no way to make multiple patches inclusive to each other, in
> many cases it is not possible.  There are some things thought that I'd
> like to see in mainline, e.g.  removing borders of the window when
> there's only one window in the current tag.
>
> Cheers
>
> FRIGN
>

--
Jan Christoph Ebersbach
I didn’t want some petty, inferior brand of righteousness that comes
from keeping a list of rules when I could get the robust kind that comes
from trusting Christ - God’s righteousness.  Phil 3:9


signature.asc
Description: PGP signature


Re: [dev] new pre-patched version of dwm available

2016-07-23 Thread Hannes Blut

On 23.07.16 at 11:51am, Hiltjo Posthuma wrote:

On Fri, Jul 22, 2016 at 11:54 PM, Britton Kerin  wrote:

dwm needs patches to be good but the patches area is a mess and I
couln't get along with devs about fixing it, so I thought a pre-rolled
version of dwm might be useful instead:


You raise a good point in my opinion: when someone uploads a patch to
the wiki it should be maintained, atleast on the current stable
version of a tool, dwm in this case.

There are alot of patches that are messy, but at the same time with
some programming knowledge (expected from suckless "users") the
patches are easy to adapt.


I disagree. When I write a patch to introduce an additional feature, I 
don't have to publish it. The only reason to upload it to the wiki is to 
help other people to have an easier time, if they want the same feature.  
Let the next person fix broken patch versions, in stead of punishing 
people who provide patches with additional workload.


--
CXblut
cxb...@gmail.com



Re: [dev] new pre-patched version of dwm available

2016-07-23 Thread FRIGN
On Fri, 22 Jul 2016 13:54:36 -0800
Britton Kerin  wrote:

Hey Britton,

> dwm needs patches to be good but the patches area is a mess and I
> couln't get along with devs about fixing it, so I thought a pre-rolled
> version of dwm might be useful instead:

you really raise a valid point, fortunately, as you may know, there are
proceedings to clean up the wiki and the progress is already pretty
good.
It's a difficult matter because patches interfere. I know of no way to
make multiple patches inclusive to each other, in many cases it is not
possible.
There are some things thought that I'd like to see in mainline, e.g.
removing borders of the window when there's only one window in the
current tag.

Cheers

FRIGN

-- 
FRIGN 



Re: [dev] new pre-patched version of dwm available

2016-07-23 Thread Hiltjo Posthuma
On Fri, Jul 22, 2016 at 11:54 PM, Britton Kerin  wrote:
> dwm needs patches to be good but the patches area is a mess and I
> couln't get along with devs about fixing it, so I thought a pre-rolled
> version of dwm might be useful instead:
>

You raise a good point in my opinion: when someone uploads a patch to
the wiki it should be maintained, atleast on the current stable
version of a tool, dwm in this case.

There are alot of patches that are messy, but at the same time with
some programming knowledge (expected from suckless "users") the
patches are easy to adapt.

> brittonkerin.com/sdwm
>
> ...snip snip...
>
> This isn't meant as a hostile fork.  It could in theory usefully live
> on suckless.org under flavors/ or something where others might want to
> put similar stuff.

This is why there is a wiki section for the patches with optional
features. We don't want to merge every feature in dwm. Some people
like it, others don't. At this time I expect most people to have their
own "dwm fork", it is nothing special.

Kind regards,
Hiltjo



Re: [dev] new pre-patched version of dwm available

2016-07-23 Thread lukáš Hozda
>Do *you* also need patches to be good?
Damn you suckless guys always know how to crack me up

2016-07-23 1:16 GMT+02:00 Quentin Carbonneaux :
> On Fri, Jul 22, 2016 at 01:54:36PM -0800, Britton Kerin wrote:
>> dwm needs patches to be good [...]
>
> Do *you* also need patches to be good?
>



Re: [dev] new pre-patched version of dwm available

2016-07-22 Thread Quentin Carbonneaux
On Fri, Jul 22, 2016 at 01:54:36PM -0800, Britton Kerin wrote:
> dwm needs patches to be good [...]

Do *you* also need patches to be good?



Re: [dev] new pre-patched version of dwm available

2016-07-22 Thread lukáš Hozda
Very nice! Keep up the good work,

regards,
Lukáš

2016-07-22 23:54 GMT+02:00 Britton Kerin :
> dwm needs patches to be good but the patches area is a mess and I
> couln't get along with devs about fixing it, so I thought a pre-rolled
> version of dwm might be useful instead:
>
> brittonkerin.com/sdwm
>
> It consists of the dwm head + the following fixed and merged patches:
>
> =pertag=
> because having to reset layout on tag switch sucks
>
> =selfrestart=
> because tweaking sdwm without this sucks
>
> =resizecorners=
> because not allowing resize from any corner sucks
>
> =savefloats=
> because dwm not remembering floating sizes sucks
>
> =warp=
> because keyboard focus + sloppy focus + mouse focus needs it
>
> =dwmfifo=
> because not being able to automate wm sucks
>
> =wminfo=
> dump wm data structs, to provide context to dwmfifo
>
> This isn't meant as a hostile fork.  It could in theory usefully live
> on suckless.org under flavors/ or something where others might want to
> put similar stuff.
>
> Britton
>