Re: [hackers] [sent] [PATCH] Add toggle fullscreen shortcut: f

Am 2018-03-20 23:13, schrieb Héctor Monacci: 2018-03-20 6:56 GMT-03:00 Markus Teich <markus.te...@stusta.mhn.de>: The patch is borderline feature-creep, but still fine. As mentioned earlier I currently don't have access to my key, so if no one else want's to do the honor (fee

Re: [hackers] [sent] [PATCH] Add toggle fullscreen shortcut: f

Am 2018-03-20 04:20, schrieb Quentin Rameau: > Don't you think it's worth it? I don't think so, but at the end of the day, Markus will make the decision and that's what matters. The maintainer decides what to merge and what not. Same as Laslo on this. The patch is borderline feature-creep,

Re: [hackers] [PATCH 1/2] Embed dmenu in tabbed own window

My laptop broke recently and I'm currently travelling and unable to restore my keys. Can someone else take care of these 2 patches? Thanks! --Markus Am 2018-03-10 16:44, schrieb Lucas Gabriel Vuotto: Signed-off-by: Lucas Gabriel Vuotto --- config.def.h | 2 +- 1 file

Re: [hackers] [surf][PATCH] Document SIGHUP in manpage

Quentin Rameau wrote: > I'm not sure the example is necessary, and I'd prefer to rephrase it > simply to “Surf will reload the current page on SIGHUP”, what do you > think? I agree that the example should be removed.

Re: [hackers] [sent] [PATCH] Draw a progress bar on non-image slides

David Phillips wrote: > Thought I would try floating it for mainline anyway. To avoid feature creep I like to "test out" most new feature patches through the wiki first. If enough users voice their opinion to include a patch it will most likely be merged to mainline eventually. My personal

Re: [hackers] [sent] add slide numbers with configurable appearance and size

ssd wrote: > Here is an updated version of the slide numbers patch Heyho, Sorry, I forgot about this one and just remembered as your patch was mentioned in the progress bar patch mail. Please also add yours to the wiki. Thanks! --Markus

Re: [hackers] [sent] [PATCH] Draw a progress bar on non-image slides

David Phillips wrote: > Similar to the slide numbers patch, it may be useful for an audience to know > how much more of a presentation they have to endure. A naïve approach to this > is to introduce a progress bar to the bottom of the slides which indicate the > presenter's progress based on slide

Re: [hackers] Re: [dmenu][PATCH] make prompt padding symmetric

Alessandro Caputo wrote: > At least on my two computers and with the fonts I tested, there's a problem > with the padding of dmenu's prompt. > I have attached two screenshots with simply an 'O' as prompt, and these are > the pixel counts on each side of the 'O': > - original: 18 left, 11 right > -

Re: [hackers] [slock][patch] configure bell amplitude

Heyho M, Please rebase your patch to apply on master: $ git am patches.mbox/ Applying: configure bell amplitude error: patch failed: config.def.h:10 error: config.def.h: patch does not apply error: patch failed: slock.c:165 error: slock.c: patch

Re: [hackers] [swerc] use png logo again || Hiltjo Posthuma

Laslo Hunhold wrote: > I understand the reasons for the switch, most prominently the security > implications for people visiting suckless.org with the Tor-browser > (because SVGs can contain embedded javascript). > Quality-wise though, it sadly is a step down and we should definitely > look for a

Re: [hackers] [tabbed][PATCH] Fix minor inconsistency in man page

Good catch, thanks! I've applied your patch. --Markus

Re: [hackers] [dwm] yet another cleanup || Anselm R Garbe

robin wrote: > On Mon, May 08, 2017 at 09:09:05PM +0200, g...@suckless.org wrote: > > The previous patches introduced some unclean space-based indentation > > patterns. This patch fixes them. > > The "unclean space-based" indentation is in accordance with >

Re: [hackers] [dwm] cleanup and bugfixes

s make the previous ones obsolete. So you only have to look at these latest three patches, ignore the earlier ones. :) Markus Teich wrote (Message-Id: <20170107162130.25354-1-markus.te...@stusta.mhn.de>): > this thread makes all my other recently published dwm patches obsolete as they > are uni

Re: [hackers] [dwm] cleanup and bugfixes

Markus Teich wrote: > Markus Teich wrote: > > this thread makes all my other recently published dwm patches obsolete as > > they are unified in this patch series. Please use `git am` on the separate > > patch mails when merging them upstream to ensure the commit messa

Re: [hackers] [dwm] cleanup and bugfixes

Markus Teich wrote: > this thread makes all my other recently published dwm patches obsolete as they > are unified in this patch series. Please use `git am` on the separate patch > mails when merging them upstream to ensure the commit message is kept intact. Heyho, are those patches st

[hackers] [dwm] [PATCH 3/3] Don't restrict snap in mousemove

This also fixes a bug where client windows only switch to floating mode when the mouse is dragged in one specific direction. --- Heyho, this patch is also the same as submitted previously. I also just added it to this patch series for a better overview of the pending patches. --Markus dwm.c

[hackers] [dwm] [PATCH 2/3] Button passthrough when client is not focused

Before this change it is not possible to press a button in a client on the first click if the client is not yet focused. The first click on the button would only focus the client and a second click on the button is needed to activate it. This situation can occur when moving the mouse over a client

[hackers] [dwm] cleanup and bugfixes

Heyho, this thread makes all my other recently published dwm patches obsolete as they are unified in this patch series. Please use `git am` on the separate patch mails when merging them upstream to ensure the commit message is kept intact. --Markus

[hackers] [dwm] [PATCH 1/3] cleanup

b/LICENSE index 90121f5..fc41d77 100644 --- a/LICENSE +++ b/LICENSE @@ -16,7 +16,7 @@ MIT/X Consortium License © 2011 Christoph Lohmann <2...@r-36.net> © 2015-2016 Quentin Rameau <quinq@fifth.space> © 2015-2016 Eric Pruitt <eric.pru...@gmail.com> -© 2016 Markus Teich <marku

[hackers] [dwm] [PATCH] Don't restrict snap in mousemove

This also fixes a bug where client windows only switch to floating mode when the mouse is dragged in one specific direction. --- Heyho, this patch basically reverts 71365a[0] from 2008. I could not find a reasonable explanation in the git log why this old patch was introduced and in the current

Re: [hackers] [dwm] [PATCH] focusonclick

Eric Pruitt wrote: > I do not know much about X11 either, but try looking at the source of one of > these patches which keeps / includes an XAllowEvents call: > > - http://lists.suckless.org/dev/1212/13833.html > - >

[hackers] [dwm] [PATCH] focusonclick

--- Heyho, while fixing the focusonclick patch I noticed that the latest version on the wiki[0] breaks some mouse-bindings. After applying the patch to the current git master, I could not move or resize floating windows with the mouse anymore. I tried removing the line `XAllowEvents(dpy,

[hackers] [PATCH] whitespace alignment

--- config.def.h | 2 +- dwm.c| 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/config.def.h b/config.def.h index ba9a240..a9ac303 100644 --- a/config.def.h +++ b/config.def.h @@ -15,7 +15,7 @@ static const char col_cyan[]= "#005577"; static const char

[hackers] [PATCH] simplify client moving on monitor count decrease

--- dwm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/dwm.c b/dwm.c index 4eba952..88d49d7 100644 --- a/dwm.c +++ b/dwm.c @@ -1896,9 +1896,8 @@ updategeom(void) /* less monitors available nn < n */ for (i = nn; i < n; i++)

[hackers] [dwm] [PATCH] whitespace alignment

--- Heyho, I overlooked that when making the decoupling patch. Sorry for the noise. --Markus config.def.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config.def.h b/config.def.h index ba9a240..a9ac303 100644 --- a/config.def.h +++ b/config.def.h @@ -15,7 +15,7 @@

Re: [hackers] [dwm] [PATCH] break up long config line

Markus Teich wrote: > Anselm R Garbe wrote: > > Why, are you entering command line options also on separate lines? > > Nope, but my command line input mostly is way shorter, because I don't have to > enter a declaration in front of it and if I have such a special case like >

Re: [hackers] [dwm] applied Ivan Delalande's NET_SUPPORTING_WM_CHECK patch for gtk3 compatibility || Anselm R Garbe

Anselm R Garbe wrote: > I agree, but my MUA couldn't detect a proper attachment. Heyho Anselm, `git am` also works with the whole source-text of a mail. For example with mutt you can create a local patches.mbox maildir on your filesystem and then copy the mail source there with `C`. Then `git am

Re: [hackers] [slock][PATCH] Fix resize with multiple monitors and portrait mode

Bob Uhl wrote: > Cool! Is there a suggested Emacs config to support the suckless code > conventions? Heyho Bob, I don't think so, just write your own. We have a styleguide[0], but it is only recommended, not mandatory. If in doubt, the existing projects style is the one to use. --Markus 0:

Re: [hackers] [slock][PATCH] Fix resize with multiple monitors and portrait mode

Bob Uhl wrote: > A similar patch for a different project is found at: > > https://bugs.freedesktop.org/attachment.cgi?id=2994=edit Heyho Bob, which version of slock are you using? Please try the latest one. slock-1.4 was just released a few days ago. Build it from source if your distribution

[hackers] [dwm] [PATCH] make OOM on new client non-fatal

--- > >>> I can at least imagine cases where quitting on allocation failure is not > >>> good. For example dwm is running, a new client starting up, but there is > >>> no memory left for the client struct. In this case dwm should just print > >>> an error, but not quit to give the user the

Re: [hackers] [dwm] [PATCH] decouple color-scheme count from dwm.c

Heyho Anselm, Markus Teich wrote: > this patch allows for a flexible amount of different colorschemes in config.h > without having to edit dwm.c as well. > This patch simplifies the status bar text padding and fixes the comment with a > wrong description. I think enough tim

[hackers] [libsl] die() on failure in ecalloc?

Heyho, Davids patch for sent reminded me of an open issue. I proposed the following change to libsls ecalloc() a few months ago, but did not get feedback. void * ecalloc(size_t nmemb, size_t size) { void *p; if (!(p =

Re: [hackers] [slock][PATCH] Remove arg.h, simplify option parsing

Heyho, Klemens Nanni wrote: > >>> arg.h is really ugly code and way to complex for tools like slock that > >>> have such minimal synopsis. > >> > >> it's a bit of "macro magic", but not really that complex if you think about > >> it. Also, the usage within the code is dead simple and

[hackers] [dwm] [PATCH] don't purge tagset of alternative view on _NET_ACTIVE_WINDOW event

Before this patch when receiving a _NET_ACTIVE_WINDOW event from a window which is out of view one of the two altenative views/tagsets gets purged and replaced with just the tags where the respective window is visible. For example if you have tags [1,2,3] selected in the first view and tags

[hackers] [dwm] [PATCH] per client resizehints

--- Heyho Anselm, here you go. Per client resize hints. Since the client struct is always initialized with zeroes to preserve behaviour either the meaning has to be reversed ("ignorehints"?) or a default rule with class, instance and title set to NULL has to be added. --Markus config.def.h

[hackers] More dwm patches

Heyho, I am currently updating my patch queue and I have some more patches in there which might be considered for mainline dwm. If they are not accepted, I'll just push them to the wiki when done. - resizehints per client (+1 SLoC): Some old version of mplayer "forced" me to write this. I

[hackers] [dwm] [PATCH] don't purge tagset of alternative view on _NET_ACTIVE_WINDOW event

Before this patch when receiving a _NET_ACTIVE_WINDOW event from a window which is out of view one of the two altenative views/tagsets gets purged and replaced with just the tags where the respective window is visible. For example if you have tags [1,2,3] selected in the first view and tags

Re: [hackers] [dwm] [PATCH] break up long config line

Anselm R Garbe wrote: > Why, are you entering command line options also on separate lines? Heyho Anselm, Nope, but my command line input mostly is way shorter, because I don't have to enter a declaration in front of it and if I have such a special case like color schemes, I tend to put them away

Re: [hackers] [dwm] [PATCH] get rid of unnecessary ternary operator

Anselm R Garbe wrote: > To me ! is logical NOT and your suggestion relies on the fact that > XUrgencyHint is a single bit flag? no? > > I prefer the original code, as it doesn't use side effects of logical NOTs. Heyho Anselm, The `(wmh->flags & XUrgencyHint)` is used as a bool value regardless.

Re: [hackers] [dwm] [PATCH] decouple color-scheme count from dwm.c

Anselm R Garbe wrote: > On 26 October 2016 at 20:30, Markus Teich <markus.te...@stusta.mhn.de> wrote: > > this patch allows for a flexible amount of different colorschemes in > > config.h without having to edit dwm.c as well. Applying this upstream would > > hel

Re: [hackers] [dwm] [PATCH] clarify status text padding

Anselm R Garbe wrote: > On 26 October 2016 at 22:42, Markus Teich <markus.te...@stusta.mhn.de> wrote: > > This patch simplifies the status bar text padding and fixes the comment with > > a wrong description. > > Have you tested this with long tag names? Heyho Ansel

[hackers] [dwm] [PATCH] break up long config line

--- config.def.h | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/config.def.h b/config.def.h index ba9a240..deb1584 100644 --- a/config.def.h +++ b/config.def.h @@ -56,7 +56,13 @@ static const Layout layouts[] = { /* commands */ static char dmenumon[2] = "0"; /*

[hackers] [dwm] [PATCH] get rid of unnecessary ternary operator

--- dwm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dwm.c b/dwm.c index 3d6cc28..85ec75e 100644 --- a/dwm.c +++ b/dwm.c @@ -2020,7 +2020,7 @@ updatewmhints(Client *c) wmh->flags &= ~XUrgencyHint; XSetWMHints(dpy, c->win,

[hackers] [dwm] [PATCH] clarify status text padding

--- Heyho, This patch simplifies the status bar text padding and fixes the comment with a wrong description. --Markus dwm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/dwm.c b/dwm.c index 25ef526..3d6cc28 100644 --- a/dwm.c +++ b/dwm.c @@ -717,8 +717,8 @@

[hackers] [dwm] [PATCH] decouple color-scheme count from dwm.c

--- Heyho, this patch allows for a flexible amount of different colorschemes in config.h without having to edit dwm.c as well. Applying this upstream would help patches like urgentborder and statuscolors with the new drw mechanics. This patch has no benefit to core dwm at all, but since it's an

Re: [hackers] [PATCH] [ii] get rid of EXIT_bla crap

Laslo Hunhold wrote: > Oh, and before you inform me. I know that OpenVMS has the roles > inverted (exit(1) means success). However, there are two aspects we > should keep in mind: > > 1) OpenVMS is not the most popular OS any more. > 2) Using EXIT_* we cannot write reliable manuals,

[hackers] [PATCH] [ii] get rid of EXIT_bla crap

--- Heyho, this was done to most other suckless projects as well and I just noticed it when reading the EXIT_TIMEOUT patch, so here you go. --Markus ii.c | 30 ++ 1 file changed, 14 insertions(+), 16 deletions(-) diff --git a/ii.c b/ii.c index 5d57458..857388e

Re: [hackers] [sent][PATCH] README: add Xft to dependencies

Heyho, Thanks. I applied your patch. --Markus

Re: [hackers] [PATCH] [slock] Remove faulty example and add a section on security considerations

FRIGN wrote: > What you do is call > system("doas setxkbmap -option &"); > which disables Ctrl+Alt+Backspace for the entire session. So you can > only kill your X server until you have locked your screen once. It > won't work afterwards, which sucks and is unpredictable. Heyho, as an

Re: [hackers] [PATCH] [slock] Remove faulty example and add a section on security considerations

Klemens Nanni wrote: > Setting `DontVTSwitch' in xorg.conf(5) disables this feature completely > whereas chjj's fork (which mine is based on) blocks it in slock only, which is > imho a much saner approach since there are many legitimate reasons to use > multiple virtual terminals. > > Same story

Re: [hackers] [PATCH] [slock] Remove faulty example and add a section on security considerations

FRIGN wrote: > > I don't think it is that obvious. Have a look at the discussion starting > > from the slock-1.3 announcement on February 12th this year again. Since the > > example does not work any more, changing it to `slock sudo s2ram` and adding > > a note about the needed line in the sudo

Re: [hackers] [PATCH] [slock] Remove faulty example and add a section on security considerations

FRIGN wrote: > The given example does not work and the usage is so obvious that an example > probably is not necessary here anyway. Heyho, I don't think it is that obvious. Have a look at the discussion starting from the slock-1.3 announcement on February 12th this year again. Since the example

Re: [hackers] [slock] [PATCHSET] Some improvements and more security

FRIGN wrote: > I sat down this evening to write down some patches that have been floating > around in my head for a while. Heyho, thanks for the patches. > Subject: [PATCH 1/3] Localize and rework data structures > … > -typedef struct { > +struct lock { > int screen; > Window root,

Re: [hackers] [slock] config.mk: be more explicative about FLAGS

Quentin Rameau wrote: > Group each *FLAG with its description and add a NetBSD specific. Heyho Quentin, I merged the patch. Thanks for the clarification. --Markus

Re: [hackers] [slock] [PATCH] Properly drop privileges

Heyho, Quentin Rameau wrote: > > > Just a question though, do we need to set a group to drop privileges > > > to? Wouldn't getting the gid out of the user name sufficient? > > > > why cut the flexibility there? > It looks more simple to me to just give a user to drop privileges to. > A user

Re: [hackers] [slock] Unify how we check passwords between different OSes

Quentin Rameau wrote: > But I understand what you mean, so what do you think about prefixing > them with the actual function name (and prepending the tool name too of > course): > die("slock: getspnam: cannot retrieve shadow entry[…]"); > die("slock: getpwnam_shadow: cannot retrieve shadow

Re: [hackers] [slock] Unify how we check passwords between different OSes

Heyho Quentin, Quentin Rameau wrote: > These variables seems to be about the auth_userokay() So the removal is fine. Thanks for the clarification. > > > diff --git a/slock.c b/slock.c > > > … > > > +#else > > > + if (rval[0] == '*' && rval[1] == '\0') { > > > +#ifdef __OpenBSD__ > > > +

Re: [hackers] [slock] Unify how we check passwords between different OSes

Heyho Quentin, thanks for the update. Quentin Rameau wrote: > diff --git a/config.mk b/config.mk > … > -# Install mode. On BSD systems MODE=2755 and GROUP=auth > -# On others MODE=4755 and GROUP=root > -#MODE=2755 > -#GROUP=auth There was a patch some time ago making use of those variables. If

Re: [hackers] [slock] Unify how we check passwords between different OSes

Heyho Quentin, I think it's a good simplification, but does it still work on the other BSDs as well, not just OpenBSD? The commented block about BSD in config.mk should be updated as well with the patch. --Markus

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

Anselm R Garbe wrote: > Use 'sizeof(type)' with brackets but 'sizeof var' without. Heyho Anselm, can you elaborate on the reasoning behind this? The styleguide says "Always use () with sizeof". --Markus

Re: [hackers] [slock] Fix my previous commit and some light refactoring

Heyho Quentin, Quentin Rameau wrote: > What I mean is if it makes sense to have a timeout in one case, it's > valable for all other cases too. > Also that's a (maximum) timeout, not a strict delay. So when nothing > gets in the way of grabbing input, slock is automatically started > anyway

Re: [hackers] [slock] [PATCH] simplify fix for CVE-2016-6866

Heyho, Can someone with such a weird network authentication setup check if my updated version fixes the bug as well befor I apply it? Eric, hiro, you both seem to have access to such systems. --Markus

Re: [hackers] [slock] Fix my previous commit and some light refactoring

Quentin Rameau wrote: > My preference would have been to completely remove the waiting behaviour > outside of slock and maybe provide a simple shell script wrapper like sleep 1; > slock. Another solution (as discussed with FRIGN) would have been to force > other applications to ungrab input

Re: [hackers] [slock] Fix my previous commit and some light refactoring

Quentin Rameau wrote: > My last commit removing the input grabbing waiting loop was a mistake, I > tested it on a specific setup which didn't raise any error while regular > setups should do. So the second of the four next commits fixes that. Heyho Quentin, in the commit message you mentioned

Re: [hackers] [slock] [PATCH] simplify fix for CVE-2016-6866

FRIGN wrote: > are you sure we are not hitting any TOCTTOU problems here? Heyho, I'm pretty sure this won't be a regression. According to the crypt(3) manpage there are just three possible errors: EINVAL salt has the wrong format. This is the important one. We want to check if the pws

Re: [hackers] [slock] [PATCHES] Refactor dontkillme() and mandoc manual

Markus Teich wrote: > This one looks good. I will apply it tomorrow if there are no complaints. Heyho, Applied. Thanks for the audit and update, FRIGN. --Markus

[hackers] [slock] [PATCH] simplify fix for CVE-2016-6866

--- Heyho, after reading Erics original CVE report and proposed fix again and thinking about it, I came to the conclusion that this is a cleaner fix. It calls crypt() pre-locking with a bogus "x" as password just to see if the pws value is correct and other system requirements are met to call

Re: [hackers] [slock] CVE-2016-6866 NULL Pointer Dereference Denial of Service Vulnerability(2016-08-19)

Hiltjo Posthuma wrote: > Any more input on this from the community? (you, yes you behind the keyboard) Heyho, I applied fixes as I think they make the most sense. If you (yes you behind the keyboard) have a weird network authentication setup where slock used to crash, please test if it works now

Re: [hackers] [slock] Exit as soon as possible on input grabbing error

FRIGN wrote: > Quentin Rameau wrote: > > + fprintf(stderr, > > + "slock: unable to grab mouse pointer for screen %s\n", > > + screen); > > this looks like a good compromise. :) Heyho, since there are multiple other lines even

Re: [hackers] [slock] Exit as soon as possible on input grabbing error

Heyho, Quentin Rameau wrote: > We want to know at once if slock failed or not to lock the screen, not seing a > black screen for a whole second (or two) and then die. Thanks to ^7heo for > reporting this. Thanks for the patch. I'd like to apply it with one change: > +

Re: [hackers] [slock] CVE-2016-6866 NULL Pointer Dereference Denial of Service Vulnerability(2016-08-19)

Hiltjo Posthuma wrote: > I agree, it's better to check if crypt() returns NULL. > > Maybe something like this (untested): > > … Heyho, looks good to me. Do we also want to check the format of pws pre-locking? This would give the benefit of being able to error out early if the network auth

Re: [hackers] [slock] [PATCH] Refactor main()

FRIGN wrote: > attached you find the patch updated according to your annotations. > Is it good to merge? Heyho, Merged. Thanks again for the patch. --Markus

Re: [hackers] [slock] [PATCH] Refactor main()

Heyho, FRIGN wrote: > ah, that might have slipped past. I generally code according to the > suckless.org coding styles[0], and given there was no reference on how > the project specific block looks like, I did it that way. > For one-line if-statements it makes sense to keep the braces away, but >

Re: [hackers] [sent] Fix error-messages || FRIGN

Hiltjo Posthuma wrote: > I (and some others) think we should apply the behaviour change in die() to all > other suckless projects that use it for consistency. Heyho, yes, I proposed it to FRIGN yesterday as well. The consistency benefit is obvious, but there might be another point left to

Re: [hackers] Re: [slock][patch] clear passwords with explicit_bzero

Hiltjo Posthuma wrote: > Can someone apply this patch or give a reason why it sucks? :) Heyho, I'm too busy to test it currently. Could one of the other slock maintainers proceed? --Markus

Re: [hackers] [sent] add ff and ff.bz2 support in config.def.h

FRIGN wrote: > I wrote a patch as an addition to config.def.h to support ff and ff.bz2 > images. Let me know what you think. Heyho FRIGN, thanks. I've pushed it together with an update to the example presentation and a new ".ff" image to test it. --Markus

Re: [hackers] [PATCH 4/8] drw: simplify color schemes

Markus Teich wrote: > this is a patch series which unifies the drw part of libsl accross the > following three projects: > > * dwm > * dmenu > * sent Heyho, after the updates have been pushed to those three repositories, just the libsl repo is remaining. @Anselm, could you pus

Re: [hackers] [dmenu][PATCH] fix: Do not crash on e.g. dmenu < /dev/null

S. Gilles wrote: > @@ -480,7 +480,7 @@ readstdin(void) > } > if (items) > items[i].text = NULL; > - inputw = TEXTW(items[imax].text); > + inputw = items ? TEXTW(items[imax].text) : 0; > lines = MIN(lines, i); > } Heyho, Nice catch! I didn't notice that

Re: [hackers] [dmenu] import new drw from libsl and minor fixes.

Hiltjo Posthuma wrote: > Fair enough, I think I'll apply it with the (temporary fix), since the current > width is also less accurate and the speed trade-off is not worth it. > > Again: thanks for the patches! I'll also review the patch for dwm soon(tm). Heyho, Thanks, I'll push the sent patch

Re: [hackers] [dmenu] import new drw from libsl and minor fixes.

Hiltjo Posthuma wrote: > Your patch fixes the slowness for me, but we need to think of a more accurate > but faster way indeed. Heyho, I plan to clean up the drw_text function some time in the future. I think it is possible to split the string into chunks which are drawn by the same font

Re: [hackers] [dmenu] import new drw from libsl and minor fixes.

faster, but is not as accurate, since it doesn't account for fallback fonts if they are needed in the string. Please try the attached dmenu patch and let me know if the slowness problem is fixed. --Markus >From 99ca606fc347df279f9313a5df1a991bfb590937 Mon Sep 17 00:00:00 2001 From: Markus Teich <markus.te..

Re: [hackers] [dwm] [PATCH] Replace str[n]cpy with strlcpy

FRIGN wrote: > I'll drop this little patch here so we finally make the switch to the safe > OpenBSD-functions for string copying. Heyho, please don't forget the drw unification patches from two weeks ago, when merging this. Hiltjo seems to be busy right now and I don't know if anyone else but

Re: [hackers] [PATCH 4/8] drw: simplify color schemes

Markus Teich wrote: > If there are no objections, I'd update the patches to use `typedef XftColor > Scm`. Heyho, Attached are the updated patches for libsl, dmenu, dwm and sent. I'll update the sent repo myself once the changes are merged in libsl, dmenu and dwm. --Markus

Re: [hackers] [PATCH 4/8] drw: simplify color schemes

Hiltjo Posthuma wrote: > I'm willing to apply your unification patches to dmenu and dwm, but can you > make a patch for dwm/dmenu if it breaks it? Heyho Hiltjo, sorry, I don't quite get what you are referring to. If a regression with my patch series turns up, of course I will fix it assuming

[hackers] [sent] import new drw and util from libsl.

--- config.def.h | 6 +- drw.c| 326 ++- drw.h| 28 ++--- sent.c | 85 ++-- util.c | 24 - util.h | 3 +- 6 files changed, 235 insertions(+), 237 deletions(-) diff --git

[hackers] [dmenu] import new drw from libsl and minor fixes.

- extract drawitem function (code deduplication) - fix bug where inputw was not correctly calculated from the widest item, but just from the one with the longest strlen() which is not the same. - minor code style fixes (indentation, useless line breaks) --- config.def.h | 12 +-- dmenu.c

[hackers] [dwm] import new drw from libsl and minor fixes.

- better scaling for occupied tag squares. - draw statusline first to omitt some complicated calculations. --- config.def.h | 24 +++--- drw.c| 253 --- drw.h| 63 ++- dwm.c| 85 +---

[hackers] [PATCH 8/8] drw: fixup drw_text

- add optional left padding parameter which is ignored on non-render calls where just the width of the text is calculated. - add /* NOP */ comments to empty loop bodies. --- drw.c | 30 +++--- drw.h | 2 +- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git

[hackers] [PATCH 7/8] drw: misc fixes

--- drw.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drw.c b/drw.c index 0adf33e..80383c9 100644 --- a/drw.c +++ b/drw.c @@ -63,9 +63,8 @@ utf8decode(const char *c, long *u, size_t clen) Drw * drw_create(Display *dpy, int screen, Window root, unsigned

[hackers] [PATCH 6/8] drw: fixup font handling

- replace static sized fontcache array with dynamic linked list (sent needs that). - remove `drw_` prefix from static helper functions. - distinguish different error cases in internal xfont_create. - remove ascent and descent members from struct Fnt since they are seldomly used and can still

[hackers] [PATCH 5/8] drw: fixup drw_rect function

- drw_rect was just setting the color when filled == empty == 0. If you don't want to draw a rectangle, you should not call drw_rect. - parameters w and h now also specify the result exactly. --- drw.c | 10 +- drw.h | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git

[hackers] [PATCH 4/8] drw: simplify color schemes

- Use simple XftColor type instead of Clr struct => No need for drw_clr_free function. - Replace ClrScheme struct with simple array of XftColor items `Scm`. - Add Enum with ColFg and ColBg for indexing Scm type variables. - Remove border color, since drw.c does never use it. dwm can still use it

[hackers] [PATCH 3/8] drw: simplify font_getexts

The struct Extnts was pointless. With the new interface there is also no need to have an extra function which just extracts the width. --- drw.c | 33 ++--- drw.h | 8 +--- 2 files changed, 15 insertions(+), 26 deletions(-) diff --git a/drw.c b/drw.c index

Re: [hackers] [farbfeld] Remove dimension checks || FRIGN

k...@shike2.com wrote: > > One problem I see with this approach is that an error will potentially go > > unnoticed and require more time to diagnose than necessary. > > Indeed. Heyho, what about still checking dimensions, but removing the `return 1`, so you get garbage with an error message?

Re: [hackers] [libzahl] gitignore: blacklist _/, for private files || Mattias Andrée

g...@suckless.org wrote: > gitignore: blacklist _/, for private files Heyho, you should not push such ignores for private files to the repositories. Just use the .git/info/exclude file which works the same as a .gitignore file, but lives only in the context of your copy of the repository.

Re: [hackers] [slock][PATCH] Reset color to INIT on Escape key press

Thomas wrote: > Wouldn't it be more consistent if setting failonclear to false also caused > slock not to fail on "escape"? After all, if you don't press "return", there's > been no guess. Heyho Thomas, that is exactly the behaviour on "failonclear == false". It will only set the screen to the

Re: [hackers] [sent] support FreeBSD || Markus Teich

Brad Barden wrote: > Heads up, unless I'm missing something the {foo,bar} alternation here is a > bash-ism. You may want to spell them both out instead. Heyho Brad, Thanks, should be fixed now. Can a FreeBSD and an OpenBSD user confirm, the new settings work after uncommenting? --Markus

Re: [hackers] [sent] Fix cmdline argument check

Quentin Rameau wrote: > + if (argv[0] && strcmp(argv[0], "-")) { > + if (!(fp = fopen(argv[0], "r"))) > + die("Unable to open '%s' for reading:", argv[0]); Heyho, I decided to fix it a little differently, since I did not like this nested if. --Markus

[hackers] [PATCH] [slock] Revert "No need for usage()"

This reverts most of commit a6dc051e3744ce5b14c54d2d246d3e8258207e76 and fixes some related stuff: - keep spelling fixes from original commit - make -h and -v also work when followed by more arguments - any unknown flag prints usage - fix output of -v to display "slock: version 1.3" instead of

[hackers] [PATCH] [slock] revert using argv0 and minor fixup

- use hardcoded "slock" instead of argv[0] - add "slock: " to fprintf calls, where it was missing - revert `argc--, argv++` shifting --- slock.c | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/slock.c b/slock.c index a0ffed0..2aa395e 100644 --- a/slock.c +++

  1   2   >