Re: [dev] which versions are dwm patches intended to apply to cleanly?

[Britton Kerin]

Here's a fixed version of dwmfifo using the naming conventions that
seem current give
practice in st and discussion here: since it's against a release
version nothing but that
in the tag.

I like the st format for names of patches against non-release ok,
though I can see the
case for git commit as well.  It seems odd to have patches for dates
for which there is
no commit.  I guess the devs are just pasting the current date in,
which of course could
cause confusion for those trying to apply the patch if the devs repo
wasn't up-to-date
when they made the patch...

Britton
From 5fcae4cc3cc895f641f94bd09e426237aa86aab2 Mon Sep 17 00:00:00 2001
From: Britton Leo Kerin 
Date: Thu, 16 Jun 2016 14:27:23 -0800
Subject: [PATCH] Squashed commit of the following:

commit e8daba47f246dcd2ae5a5452221a993a6e489892
Author: Britton Leo Kerin 
Date:   Sat Jun 11 16:04:38 2016 -0800

Better messages on failure

commit f57b4d2aef1f9e796f828220e55c885c919b2a9c
Author: Britton Leo Kerin 
Date:   Sat Jun 11 15:58:22 2016 -0800

Fixed patch failure resolution mistake

commit 25c36a5536ec95faad3317cdfa8483af26c25b44
Author: Britton Leo Kerin 
Date:   Sat Jun 11 14:46:01 2016 -0800

Suckless dwmfifo, with fixes
---
 config.def.h | 62 +
 dwm.c| 70 +++-
 2 files changed, 127 insertions(+), 5 deletions(-)

diff --git a/config.def.h b/config.def.h
index 7054c06..9f4ef79 100644
--- a/config.def.h
+++ b/config.def.h
@@ -111,3 +111,65 @@ static Button buttons[] = {
{ ClkTagBar,MODKEY, Button3,toggletag,  
{0} },
 };
 
+static const char *dwmfifo = "/tmp/dwm.fifo";
+static Command commands[] = {
+   { "dmenu",   spawn,  {.v = dmenucmd} },
+   { "term",spawn,  {.v = termcmd} },
+   { "togglebar",   togglebar,  {0} },
+   { "focusstack+", focusstack, {.i = +1} },
+   { "focusstack-", focusstack, {.i = -1} },
+   { "incnmaster+", incnmaster, {.i = +1} },
+   { "incnmaster-", incnmaster, {.i = -1} },
+   { "setmfact+",   setmfact,   {.f = +0.05} },
+   { "setmfact-",   setmfact,   {.f = -0.05} },
+   { "zoom",zoom,   {0} },
+   { "view",view,   {0} },
+   { "killclient",  killclient, {0} },
+   { "setlayout-tiled", setlayout,  {.v = [0]} },
+   { "setlayout-float", setlayout,  {.v = [1]} },
+   { "setlayout-mono",  setlayout,  {.v = [2]} },
+   { "togglelayout",setlayout,  {0} },
+   { "togglefloating",  togglefloating, {0} },
+   { "viewall", view,   {.ui = ~0} },
+   { "tag", tag,{.ui = ~0} },
+   { "focusmon+",   focusmon,   {.i = +1} },
+   { "focusmon-",   focusmon,   {.i = -1} },
+   { "tagmon+", tagmon, {.i = +1} },
+   { "tagmon-", tagmon, {.i = -1} },
+   { "view1",   view,   {.ui = 1 << 0} },
+   { "view2",   view,   {.ui = 1 << 1} },
+   { "view3",   view,   {.ui = 1 << 2} },
+   { "view4",   view,   {.ui = 1 << 3} },
+   { "view5",   view,   {.ui = 1 << 4} },
+   { "view6",   view,   {.ui = 1 << 5} },
+   { "view7",   view,   {.ui = 1 << 6} },
+   { "view8",   view,   {.ui = 1 << 7} },
+   { "view9",   view,   {.ui = 1 << 8} },
+   { "toggleview1", toggleview, {.ui = 1 << 0} },
+   { "toggleview2", toggleview, {.ui = 1 << 1} },
+   { "toggleview3", toggleview, {.ui = 1 << 2} },
+   { "toggleview4", toggleview, {.ui = 1 << 3} },
+   { "toggleview5", toggleview, {.ui = 1 << 4} },
+   { "toggleview6", toggleview, {.ui = 1 << 5} },
+   { "toggleview7", toggleview, {.ui = 1 << 6} },
+   { "toggleview8", toggleview, {.ui = 1 << 7} },
+   { "toggleview9", toggleview, {.ui = 1 << 8} },
+   { "tag1",tag,{.ui = 1 << 0} },
+   { "tag2",tag,{.ui = 1 << 1} },
+   { "tag3",tag,{.ui = 1 << 2} },
+   { "tag4",tag,{.ui = 1 << 3} },
+   { "tag5",tag,{.ui = 1 << 4} },
+   { "tag6",tag,{.ui = 1 << 5} },
+   { "tag7",tag,{.ui = 1 << 6} },
+   { "tag8",tag,{.ui = 1 << 7} },
+   { "tag9",tag,{.ui = 1 << 8} },
+   { "toggletag1",  toggletag,  {.ui = 1 << 0} },
+   { "toggletag2",  toggletag,  {.ui = 1 << 

Re: [dev] which versions are dwm patches intended to apply to cleanly?

[Quentin Rameau]

Hi,
> Admittedly, I don't immediately see the date in there.
You will as soon as you have seen another one.

> Also, always
> think about how you can enforce this properly. Most people don't even
> know how to get a short hash.
Too bad for “most people”, they'll have to learn (that “getting” a
short hash is just getting the first chars of it).
We could have an explanation page for that too.

> > Also condensing the date to skip the century is a good idea in the
> > year 2016. Still 84 years to come without a century problem of patch
> > file names.  
> 
> This makes it harder to spot as a date.
I agree, I'd be for keeping the whole year, unless we really need to
cut down two characters.

> > I would even go that far to skip the date completely. It doesn't
> > really tell you much. If someone bothers of the age of a patch, then
> > you can always check git with the hash.  
> 
> We already had this discussion, Anselm, and we concluded back then
> that the date is a great heuristic. The git hash first forces you to
> have the repo at hand. When you go check the patches, the first thing
> you have to think about is: Is this patch still quite recent?
> The recency is always with respect to the project at hand, however,
> this decision can only be made by the user and depends on the nature
> of the commits.
> Additionally, if you have a list of patches
>   st-externalpipe-ea87104.patch
>   st-externalpipe-fbd023a.patch
>   st-externalpipe-fe0239e.patch
> you don't see which one is the newest one.
But there shouldn't be that many in the first place.
The correct way would be to have a patch for release versions, and one
for last git version, the rest is maintenance.
Though having the date in the filename wouldn't hurt and indeed is
handy to quickly see a patch age.

> As a last point of thought: The shorthash gives no info at all. It
> could either be a broken patch against HEAD or not, however, pasting
> the hash in the name somehow claims more than it does, and gives less 
> information to 99% of people.
The shorthash gives the information on which commit it was made against.
It could be broken against HEAD or not, but you wouldn't have a patch
named st-externalpipe-BROKEN.patch anyway.
Also it helps to lookup which changes (commits) have been made since
the patch has been produced for maintenance.

Re: [dev] which versions are dwm patches intended to apply to cleanly?

[Martin Kühne]

On Thu, Jun 16, 2016 at 4:15 PM, FRIGN  wrote:
>> I would suggest to use: --> hash>-.patch
>
> st-externalpipe-ea87104-160423.patch
>
> Admittedly, I don't immediately see the date in there.


Use 4 digit years. Also, there's ISO-8601 [0].

cheers!
mar77i

[0] https://imgs.xkcd.com/comics/iso_8601.png

Re: [dev] which versions are dwm patches intended to apply to cleanly?

[FRIGN]

On Thu, 16 Jun 2016 10:23:15 +0200
v4hn  wrote:

Hey v4hn,

> No. It indicates that individuals make use of some patches and contribute
> their changes to make a patch work with whatever git checkout they use.
> 
> Threads such as this one only appear because people who are too lazy to
> update patch files they find flying around somewhere on their own and
> instead decide to waste everyones time by sending user-request-mails.
> This is not launchpad.

yeah, you nailed it. I spent considerable time updating the st-patches
over the last couple of months, and only few joined me in the "fight",
like Joshua Haase, David Phillips, Ivan Tham and Anders Larsson.

In certain respects, the st patches could use another update. Even
hunk-differences can break someday after more commits. Maybe I'll
work on a way to automate the process somewhat. :)

To everybody else: Stop painting pictures here on the ml and actually
help improve the patches. In the end, only the one who does something
gets to decide how it's done.

Cheers

FRIGN

-- 
FRIGN 

Re: [dev] which versions are dwm patches intended to apply to cleanly?

[FRIGN]

On Thu, 16 Jun 2016 07:27:58 +0200
Anselm R Garbe  wrote:

Hey Anselm,

> I would suggest to use: -- hash>-.patch

st-externalpipe-ea87104-160423.patch

Admittedly, I don't immediately see the date in there. Also, always
think about how you can enforce this properly. Most people don't even
know how to get a short hash.

> Replacing the "git" portion with the short hash makes it much more
> accurate to what git version the patch applies to.

but it breaks sorting.

> Also condensing the date to skip the century is a good idea in the
> year 2016. Still 84 years to come without a century problem of patch
> file names.

This makes it harder to spot as a date.

> I would even go that far to skip the date completely. It doesn't
> really tell you much. If someone bothers of the age of a patch, then
> you can always check git with the hash.

We already had this discussion, Anselm, and we concluded back then that
the date is a great heuristic. The git hash first forces you to have
the repo at hand. When you go check the patches, the first thing you
have to think about is: Is this patch still quite recent?
The recency is always with respect to the project at hand, however,
this decision can only be made by the user and depends on the nature of
the commits.
Additionally, if you have a list of patches
st-externalpipe-ea87104.patch
st-externalpipe-fbd023a.patch
st-externalpipe-fe0239e.patch
you don't see which one is the newest one.

As a last point of thought: The shorthash gives no info at all. It could
either be a broken patch against HEAD or not, however, pasting the
hash in the name somehow claims more than it does, and gives less 
information to 99% of people.

Cheers

FRIGN

-- 
FRIGN 

Re: [dev] which versions are dwm patches intended to apply to cleanly?

[v4hn]

On Thu, Jun 16, 2016 at 09:58:34AM +0200, Kamil Cholewiński wrote:
> On Thu, 16 Jun 2016, David Phillips  wrote:
> > What? Since when were any patches "supported"?
> 
> The amount of effort that goes into organising them (as evidenced by the
> thread) indicates that, in fact, there is some "support".

No. It indicates that individuals make use of some patches and contribute
their changes to make a patch work with whatever git checkout they use.

Threads such as this one only appear because people who are too lazy to
update patch files they find flying around somewhere on their own and
instead decide to waste everyones time by sending user-request-mails.
This is not launchpad.


v4hn


signature.asc
Description: PGP signature

Re: [dev] which versions are dwm patches intended to apply to cleanly?

[Kamil Cholewiński]

On Thu, 16 Jun 2016, David Phillips  wrote:
> What? Since when were any patches "supported"?

The amount of effort that goes into organising them (as evidenced by the
thread) indicates that, in fact, there is some "support".