[hackers] Re: [dev] [libsl] [PATCH 1/4] drw: fixup font_getexts
Any chance of this set of patches being reviewed by someone with commit privileges? Link to the thread for convenience since I'm cross-posting to a different list: http://lists.suckless.org/dev/1504/26513.html . Eric
Re: [hackers] [dwm] Patch to confirm Shift-Alt-Q
On Sat, Aug 08, 2015 at 05:39:55PM +0200, Quolick wrote: When I press Shift-Alt-Q, all windows killed without any confirmation. Is there any patch to add some king of dialog box? Maybe two menu items in the bar (like dmenu does) OK, Cancel? You could make Shift+Alt+Q launch a shell script instead. Maybe something like this: zenity --question --text 'Are you sure you want to exit?' pkill -x dwm Eric
[hackers] [dmenu] [PATCH] Typo Patch
This patch fixes a typo in dmenu.
Eric
From 98573e0f8c4dda3ebe2a3639f24046c7d80cc3d8 Mon Sep 17 00:00:00 2001
From: Eric Pruitt eric.pru...@gmail.com
Date: Wed, 5 Aug 2015 19:19:14 -0700
Subject: [PATCH] Fixed typo introduced by shared code
---
dmenu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dmenu.c b/dmenu.c
index 3b465cf..12cf6c7 100644
--- a/dmenu.c
+++ b/dmenu.c
@@ -128,7 +128,7 @@ main(int argc, char *argv[]) {
if(!setlocale(LC_CTYPE, ) || !XSupportsLocale())
fputs(warning: no locale support\n, stderr);
if(!(dpy = XOpenDisplay(NULL)))
- die(dwm: cannot open display\n);
+ die(dmenu: cannot open display\n);
screen = DefaultScreen(dpy);
root = RootWindow(dpy, screen);
sw = DisplayWidth(dpy, screen);
--
2.1.4
Re: [hackers] [scc][patch] fix build + some whitespace fixes
On Fri, Jul 17, 2015 at 08:33:12PM +0200, Hiltjo Posthuma wrote: patch 1: whitespace fixes patch 2: make fp of type FILE * and use needed includes patch 3: fix missing ; You forgot the attachments. Eric
Re: [hackers] [st][PATCH] Change mshortcuts to mkeys to make it clear
I don't understand this patch. Mice don't have keys, they have buttons (at least the dialects of English I'm familiar with). "Mouse keys" just sounds wrong and confusing to me. Eric signature.asc Description: Digital signature
Re: [hackers] [dmenu] Typofix, patches rebased
Hi Klemens, On Mon, Jan 11, 2016 at 05:29:47PM +, Klemens Nanni wrote: > cc596365a (unbolify dmenu) "breaks" some of the patches provided at > tools.suckless.org/dmenu/patches. Basically 's,bool,int' was all I had > to do besides some offset correction. Since this is the first time I'm > dealing with dmenu's source I do not guarantee anything, but it compiles > fine, though. Making them apply without errors ontop of latest git was > all I did, no changes in functionality or whatsoever. The entire website is a Git repository (http://suckless.org/wiki). You can clone it, update the patches then push the diffs which will eventually be reviewed by someone with commit privileges on the live repo. Eric
Re: [hackers] [dmenu] import new drw from libsl and minor fixes.
On Sun, Jun 26, 2016 at 02:53:03PM +0200, Hiltjo Posthuma wrote:
> I have pushed the drw changes to dmenu and dwm.
>
> Thanks for the contributions!
>
> It would be nice if people test it and report any regressions with their
> setups
> (font-fallback specificly).
I'm in the process of merging this with my personal changes, so I
haven't actually compiled dwm yet, but I did notice that the colors
array could be made self-documenting by using enum values instead of
comments; the code currently likes like this:
static const char *colors[][3] = {
/* fgbg border */
{ col_gray3, col_gray1, col_gray2}, /* normal */
{ col_gray4, col_cyan, col_cyan }, /* selected */
};
However, I personally think this is a little nicer:
static const char *colors[][3] = {
/* fgbg border */
[SchemeNorm] = { col_gray3, col_gray1, col_gray2},
[SchemeSel] = { col_gray4, col_cyan, col_cyan },
};
It also ensures that the order of the array doesn't matter, and it makes
it a little easier to add new color schemes.
Eric
Re: [hackers] [dmenu] import new drw from libsl and minor fixes.
On Sun, Jun 26, 2016 at 02:53:03PM +0200, Hiltjo Posthuma wrote: > It would be nice if people test it and report any regressions with their > setups > (font-fallback specificly). I finished merging my changes with the upstream tree, and I have not encountered any issues with fallback fonts while testing the changes. Eric
Re: [hackers] [sbase][PATCH] grep: remove = flag from readme
On Sun, Apr 03, 2016 at 11:50:08PM +0200, Mattias Andrée wrote: > That works with musl but not glibc. If you use 'setlocale(LC_ALL, "")' with GCC, grep behaves as expected: sbase$ echo äö | ./grep '[å]' (1) sbase$ echo å | ./grep '[å]' å Eric
Re: [hackers] [PATCH] [sites] dwm: patches: fix unclean cfacts patch
On Mon, Aug 01, 2016 at 12:44:04PM +0200, Patrick Steinhardt wrote: > --- > dwm.suckless.org/patches/cfacts.md | 2 +- > dwm.suckless.org/patches/dwm-6.1-cfacts.diff | 49 > ++-- > 2 files changed, 25 insertions(+), 26 deletions(-) You generally don't need to send update proposals to the mailing list for the "sites" repository even if you're not the original author so long as you don't fundamentally alter a patch's behavior. Eric
Re: [hackers] [dwm] [PATCH] support the NET_SUPPORTING_WM_CHECK EWMH property
On Sun, Nov 27, 2016 at 08:43:20PM +0100, Ivan Delalande wrote: > > Which GTK3 (sub)version and Firefox version do you use? Which other software > > did you notice issues with? > > I've seen this problem only with Firefox, version 50.0 and the HEAD on > mozilla-central.hg (52/53?) to debug the issue, and gtk3-3.22.4. But > I've had this for some times, so probably the previous versions as well, > Firefox 49.0.2 and gtk3-3.22.3, at least. I also have the same problem with Firefox 50 using GTK 3.14.5: ~$ firefox --version Mozilla Firefox 50.0 ~$ dpkg -l libgtk-3-0 [...] +++-===--= ii libgtk-3-0:amd643.14.5-1+deb8u1 amd64 [...] [...] This patch works for me, too. Firefox is the only GTK 3 application I use in full-screen mode, so I can't comment on any other programs. Eric
[hackers] [st] [PATCH] Make missing attribute fallback color optional
I wasted an hour trying to figure out why st on different hosts using
the exact same terminfo configuration and statically compiled tmux was
displaying some text in yellow. The hosts where this produced yellow
text were using an Ubuntu-based Linux distro while the hosts where st
continued to work as it always had were using Debian 8. I didn't dig
into the problem too much after I narrowed down the problem to a
specific commit, so I don't know which attributes st was unable to find.
However, the output rendered on the hosts that st's font selection
thought had incorrect attributes is almost a pixel perfect match for the
hosts where st was able to find a font that was an exact match which
makes this fallback color a false-positive for all practical intents. I
have modified st to make the fallback coloring optional because I'm sure
this is going to surprise someone else in the future, too.
---
config.def.h | 2 +-
st.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git config.def.h config.def.h
index 32d107d..2e29064 100644
--- config.def.h
+++ config.def.h
@@ -139,7 +139,7 @@ static unsigned int mousebg = 0;
/*
* Color used to display font attributes when fontconfig selected a font which
- * doesn't match the ones requested.
+ * doesn't match the ones requested. Set this to 0 to disable this feature.
*/
static unsigned int defaultattr = 11;
diff --git st.c st.c
index d6fe58a..2ee04fa 100644
--- st.c
+++ st.c
@@ -3824,10 +3824,10 @@ xdrawglyphfontspecs(const XftGlyphFontSpec *specs,
Glyph base, int len, int x, i
/* Fallback on color display for attributes not supported by the font */
if (base.mode & ATTR_ITALIC && base.mode & ATTR_BOLD) {
- if (dc.ibfont.badslant || dc.ibfont.badweight)
+ if (defaultattr && (dc.ibfont.badslant || dc.ibfont.badweight))
base.fg = defaultattr;
- } else if ((base.mode & ATTR_ITALIC && dc.ifont.badslant) ||
- (base.mode & ATTR_BOLD && dc.bfont.badweight)) {
+ } else if (defaultattr && ((base.mode & ATTR_ITALIC &&
dc.ifont.badslant) ||
+ (base.mode & ATTR_BOLD && dc.bfont.badweight))) {
base.fg = defaultattr;
}
--
2.1.4
Re: [hackers] [st] [PATCH] Make missing attribute fallback color optional
On Fri, Dec 16, 2016 at 12:10:10AM +0100, Martin Kühne wrote: > Wasn't there a patch about this at some point? > When you use $repos, you tend to get older stuff. I said nothing about using a precompiled st. If I did, I would submit this to my repository maintainers, not this list. Eric
Re: [hackers] [dwm] [PATCH] support the NET_SUPPORTING_WM_CHECK EWMH property
On Sat, Nov 26, 2016 at 08:00:01AM +0100, Ivan Delalande wrote:
> This is mostly arg's 762b66a resurrected ("hack that adds
> NET_SUPPORTING_WM_CHECK handling..."), but we have to create a dedicated
> window which remains unmapped as bar windows can now be destroyed at any
> time with their monitor.
Is this patch going to be merged?
Eric
Re: [hackers] [dwm] [PATCH] focusonclick
On Wed, Jan 04, 2017 at 08:33:12PM +0100, Markus Teich wrote: > 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, ReplayPointer, CurrentTime);` and > it > seems to work. I tried to understand why this call was needed in the first > place, but could not figure it out. It would be nice if anyone with more X > knowledge could approve that the removal of this call (as done in my attached > version) is actually the correct solution. 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 - https://github.com/ericpruitt/edge/blob/master/patches/dwm-00-click-to-focus.diff The second link is just my personal variant of the first patch. Neither of them have bugs that prevent mouse shortcuts from being used. Eric
[hackers] Re: [PATCH] dd: Use sigaction(2) to obviate select(2)
On Sun, Sep 10, 2017 at 04:31:24AM -0700, Eric Pruitt wrote: > By setting the SIGINT handler with sigaction(2), automatic retries of > the splice(2) syscall can be disabled by not setting SA_RESTART. This > makes it possible to use Ctrl+C even if the "if" operand refers to the > controlling terminal. The SIGINT message has also been moved outside the > signal handler since fprintf(3) is not an async-signal-safe function. I'm wondering if the ubase maintainer(s) have looked at this patch and whether or not they think there are some problems with it. Eric
Re: [hackers] Re: [PATCH] dd: Use sigaction(2) to obviate select(2)
On Sun, Oct 08, 2017 at 01:01:55PM -0700, Michael Forney wrote: > I am curious why ubase dd is using splice instead of just read/write > (as you noted most other implementations do). Unless there is a big > performance win, I would think that simplicity and portability would > be preferable. I did some digging through the commit history when I created this patch to find out why: the ubase dd(1) implementation is based on https://github.com/stealth/odd.git which implements the techniques described in http://stealth.openwall.net/papers/odd.pdf to improve the performance of dd(1). That is not to say I agree the added complexity is worth the performance improvement, but I at least understand the motivation and think it's a reasonable goal. Eric
[hackers] [ubase] dd doesn't handle reading from high latency files well
While testing a shell script with sbase and ubase, I ran into a problem where dd would chew up my CPU whenever it read from a slow file. I noticed this when running "dd" in a pipeline with "/dev/random" while my system was low on entropy. Here are the timing outputs from ubase's dd compared to GNU coreutils running on the same system: # Suckless Unportable Base: $ time (ubase-box dd if=/dev/random bs=1 count=16 &>/dev/null) real0m12.673s user0m2.992s sys 0m9.656s # GNU Core Utilities: $ time (coreutils --coreutils-prog=dd if=/dev/random bs=1 count=16 &>/dev/null) real0m16.987s user0m0.000s sys 0m0.004s The amount of sys time spent by ubase's dd is always a lot higher than coreutil's even when the wall-clock time of the runs is comparable. I haven't spent a lot of time looking into this yet, so I don't have a patch prepared, but glancing at strace showed rapid invocations of select(2) which often alternated between succeeding and ENOSYS: $ strace -o '!uniq -c >&2' ubase-box dd if=/dev/random bs=1 count=16 >/dev/null [...] 1 splice(4, NULL, 1, NULL, 1, SPLICE_F_MORE) = 1 1 select(4, [3], [1], NULL, NULL) = 2 (in [3], out [1]) 1 splice(3, NULL, 5, NULL, 1, SPLICE_F_MORE) = 1 1 splice(4, NULL, 1, NULL, 1, SPLICE_F_MORE) = 1 5074 select(4, [3], [1], NULL, NULL) = 1 (out [1]) 152992 select(4, [], [1], NULL, NULL) = -1 ENOSYS (Function not implemented) 1 select(4, [3], [1], NULL, NULL) = 1 (out [1]) 1 select(4, [3], [1], NULL, NULL) = -1 ENOSYS (Function not implemented) 34335 select(4, [], [1], NULL, NULL) = -1 ENOSYS (Function not implemented) 34778 select(4, [3], [1], NULL, NULL) = 1 (out [1]) 1 select(4, [3], [1], NULL, NULL) = 2 (in [3], out [1]) 1 splice(3, NULL, 5, NULL, 1, SPLICE_F_MORE) = 1 1 splice(4, NULL, 1, NULL, 1, SPLICE_F_MORE) = 1 1 select(4, [3], [1], NULL, NULL) = 2 (in [3], out [1]) [...] Eric
[hackers] [sbase] [PATCH] Add missing getconf.h dependency to sbase-box
--- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git Makefile Makefile index 1c39fef..0e421e7 100644 --- Makefile +++ Makefile @@ -233,7 +233,7 @@ dist: clean gzip sbase-$(VERSION).tar rm -rf sbase-$(VERSION) -sbase-box: $(LIB) $(SRC) +sbase-box: $(LIB) $(SRC) getconf.h mkdir -p build cp $(HDR) build cp getconf.h build -- 2.11.0
[hackers] Re: [ubase] dd doesn't handle reading from high latency files well
On Tue, Sep 05, 2017 at 09:31:04PM -0700, Eric Pruitt wrote: > The amount of sys time spent by ubase's dd is always a lot higher than > coreutil's even when the wall-clock time of the runs is comparable. I > haven't spent a lot of time looking into this yet, so I don't have a > patch prepared, but glancing at strace showed rapid invocations of > select(2) which often alternated between succeeding and ENOSYS: The GNU implementation just uses read(2) (https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/dd.c;h=ddeeb4f). I also looked at the dd implementations in: - OpenBSD: https://github.com/openbsd/src/blob/master/bin/dd/dd.c - FreeBSD: https://github.com/freebsd/freebsd/blob/master/bin/dd/dd.c - BusyBox: https://git.busybox.net/busybox/tree/coreutils/dd.c Assuming I didn't overlook something, they all use read(2) and write(2) without select(2). My inclination would be to revert ubase commit 0ca8e52 which introduced select(2) and avoid splice(2) since getting rid of the Linux-specific function might make it possible to move dd from ubase to sbase. Eric
[hackers] [PATCH] [ubase] dd: Use sigaction(2) to obviate select(2)
By setting the SIGINT handler using sigaction(2), automatic retries of
the splice(2) call can be disabled by not setting SA_RESTART. This makes
it possible to use Ctrl+C even if standard input is a terminal.
---
dd.c | 58 +-
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git dd.c dd.c
index cc05d40..4011045 100644
--- dd.c
+++ dd.c
@@ -8,7 +8,6 @@
*/
#include
#include
-#include
#include
#include
#include
@@ -38,6 +37,16 @@ struct dd_config {
static int sigint = 0;
+static void
+sig_int(int unused_1, siginfo_t *unused_2, void *unused_3)
+{
+ (void) unused_1;
+ (void) unused_2;
+ (void) unused_3;
+ fprintf(stderr, "SIGINT! Aborting ...\n");
+ sigint = 1;
+}
+
static int
prepare_copy(struct dd_config *ddc, int *ifd, int *ofd)
{
@@ -147,7 +156,6 @@ copy_splice(struct dd_config *ddc)
int ifd, ofd, p[2] = {-1, -1};
ssize_t r = 0;
size_t n = 0;
- fd_set rfd, wfd;
if (prepare_copy(ddc, , ) < 0)
return -1;
@@ -165,26 +173,19 @@ copy_splice(struct dd_config *ddc)
#endif
n = ddc->bs;
for (;ddc->b_out != ddc->count && !sigint;) {
- FD_ZERO();
- FD_ZERO();
- FD_SET(ifd, );
- FD_SET(ofd, );
- r = select(ifd > ofd ? ifd + 1 : ofd + 1, , , NULL,
NULL);
if (r < 0)
break;
- if (FD_ISSET(ifd, ) == 1 && FD_ISSET(ofd, ) == 1) {
- if (n > ddc->count - ddc->b_out)
- n = ddc->count - ddc->b_out;
- r = splice(ifd, NULL, p[1], NULL, n, SPLICE_F_MORE);
- if (r <= 0)
- break;
- ++ddc->rec_in;
- r = splice(p[0], NULL, ofd, NULL, r, SPLICE_F_MORE);
- if (r <= 0)
- break;
- ddc->b_out += r;
- ++ddc->rec_out;
- }
+ if (n > ddc->count - ddc->b_out)
+ n = ddc->count - ddc->b_out;
+ r = splice(ifd, NULL, p[1], NULL, n, SPLICE_F_MORE);
+ if (r <= 0)
+ break;
+ ++ddc->rec_in;
+ r = splice(p[0], NULL, ofd, NULL, r, SPLICE_F_MORE);
+ if (r <= 0)
+ break;
+ ddc->b_out += r;
+ ++ddc->rec_out;
}
close(ifd);
close(ofd);
@@ -227,14 +228,6 @@ print_stat(const struct dd_config *ddc)
}
static void
-sig_int(int unused)
-{
- (void) unused;
- fprintf(stderr, "SIGINT! Aborting ...\n");
- sigint = 1;
-}
-
-static void
usage(void)
{
eprintf("usage: %s [-h] [if=infile] [of=outfile] [bs[=N]] [seek=N] "
@@ -248,6 +241,7 @@ main(int argc, char *argv[])
int i = 0;
char buf[1024];
struct dd_config config;
+ struct sigaction sa;
argv0 = argv[0];
memset(, 0, sizeof(config));
@@ -286,7 +280,13 @@ main(int argc, char *argv[])
}
signal(SIGPIPE, SIG_IGN);
- signal(SIGINT, sig_int);
+
+ sa.sa_flags = SA_SIGINFO;
+ sigemptyset(_mask);
+ sa.sa_sigaction = sig_int;
+
+ if (sigaction(SIGINT, , NULL) == -1)
+ weprintf("sigaction");
if (copy() < 0)
weprintf("copy:");
--
2.11.0
[hackers] [PATCH] dd: Use sigaction(2) to obviate select(2)
By setting the SIGINT handler with sigaction(2), automatic retries of
the splice(2) syscall can be disabled by not setting SA_RESTART. This
makes it possible to use Ctrl+C even if the "if" operand refers to the
controlling terminal. The SIGINT message has also been moved outside the
signal handler since fprintf(3) is not an async-signal-safe function.
---
dd.c | 61 -
1 file changed, 32 insertions(+), 29 deletions(-)
diff --git dd.c dd.c
index cc05d40..2dce98e 100644
--- dd.c
+++ dd.c
@@ -8,7 +8,6 @@
*/
#include
#include
-#include
#include
#include
#include
@@ -38,6 +37,15 @@ struct dd_config {
static int sigint = 0;
+static void
+sig_int(int unused_1, siginfo_t *unused_2, void *unused_3)
+{
+ (void) unused_1;
+ (void) unused_2;
+ (void) unused_3;
+ sigint = 1;
+}
+
static int
prepare_copy(struct dd_config *ddc, int *ifd, int *ofd)
{
@@ -147,7 +155,6 @@ copy_splice(struct dd_config *ddc)
int ifd, ofd, p[2] = {-1, -1};
ssize_t r = 0;
size_t n = 0;
- fd_set rfd, wfd;
if (prepare_copy(ddc, , ) < 0)
return -1;
@@ -165,27 +172,24 @@ copy_splice(struct dd_config *ddc)
#endif
n = ddc->bs;
for (;ddc->b_out != ddc->count && !sigint;) {
- FD_ZERO();
- FD_ZERO();
- FD_SET(ifd, );
- FD_SET(ofd, );
- r = select(ifd > ofd ? ifd + 1 : ofd + 1, , , NULL,
NULL);
if (r < 0)
break;
- if (FD_ISSET(ifd, ) == 1 && FD_ISSET(ofd, ) == 1) {
- if (n > ddc->count - ddc->b_out)
- n = ddc->count - ddc->b_out;
- r = splice(ifd, NULL, p[1], NULL, n, SPLICE_F_MORE);
- if (r <= 0)
- break;
- ++ddc->rec_in;
- r = splice(p[0], NULL, ofd, NULL, r, SPLICE_F_MORE);
- if (r <= 0)
- break;
- ddc->b_out += r;
- ++ddc->rec_out;
- }
+ if (n > ddc->count - ddc->b_out)
+ n = ddc->count - ddc->b_out;
+ r = splice(ifd, NULL, p[1], NULL, n, SPLICE_F_MORE);
+ if (r <= 0)
+ break;
+ ++ddc->rec_in;
+ r = splice(p[0], NULL, ofd, NULL, r, SPLICE_F_MORE);
+ if (r <= 0)
+ break;
+ ddc->b_out += r;
+ ++ddc->rec_out;
}
+
+ if (sigint)
+ fprintf(stderr, "SIGINT! Aborting ...\n");
+
close(ifd);
close(ofd);
close(p[0]);
@@ -227,14 +231,6 @@ print_stat(const struct dd_config *ddc)
}
static void
-sig_int(int unused)
-{
- (void) unused;
- fprintf(stderr, "SIGINT! Aborting ...\n");
- sigint = 1;
-}
-
-static void
usage(void)
{
eprintf("usage: %s [-h] [if=infile] [of=outfile] [bs[=N]] [seek=N] "
@@ -248,6 +244,7 @@ main(int argc, char *argv[])
int i = 0;
char buf[1024];
struct dd_config config;
+ struct sigaction sa;
argv0 = argv[0];
memset(, 0, sizeof(config));
@@ -286,7 +283,13 @@ main(int argc, char *argv[])
}
signal(SIGPIPE, SIG_IGN);
- signal(SIGINT, sig_int);
+
+ sa.sa_flags = SA_SIGINFO;
+ sigemptyset(_mask);
+ sa.sa_sigaction = sig_int;
+
+ if (sigaction(SIGINT, , NULL) == -1)
+ weprintf("sigaction");
if (copy() < 0)
weprintf("copy:");
--
2.11.0
Re: [hackers] [PATCH] [ubase] dd: Use sigaction(2) to obviate select(2)
On Sun, Sep 10, 2017 at 11:55:53AM +0100, Richard Ipsum wrote: > This isn't a comment on this patch exactly, since this call exists in > the existing handler, but unless I'm missing something about the way > you're doing this it isn't safe to call fprintf in a signal handler > since your signal may be interrupting an fprintf call itself, and > since the data structures for stdio aren't reentrant, things will get > messy. I personally don't think there's any benefit in displaying the message at all. I'll post a revised patch since moving the warning is trivial, and it'll give me a chance to fix my botched commit message. Eric
Re: [hackers] [st][PATCH] in bracketed paste mode, filter escapes from pasted data
On Fri, Nov 03, 2017 at 12:14:46AM +0100, Laslo Hunhold wrote: > However, as it has already been laid out numerous times, we can not > accept companies to be in the list of contributors, only people. If > you are interested in the reasons, I can lay them out again, but > admittedly I think they are pretty obvious. I think most open source projects are happy to accept contributions from corporate entities, so I doubt this is obvious especially if you don't regularly read the suckless.org mailing lists. Rather than rehashing the issue "numerous times", you should update the website. The community page (https://suckless.org/community) is probably the right place. Eric
Re: [hackers] Re: [st][PATCH] Set minimum window size to avoid crash when resizing out of bounds
On Fri, May 18, 2018 at 12:12:32AM +0200, Michael Buch wrote: > Nvm, that's the correct patch. Got confused by it auto-replying to the > thread... It didn't at least as far as Mutt is concerned. Are you using the Gmail web UI? I think the Gmail web UI will treat emails with the same title as part of the same thread even if the In-Reply-To or References fields don't mention the Message-ID of an earlier email. Eric
Re: [hackers] [dwm][PATCH] ColBorder has been moved to the enum with ColFg and ColBg.
On Thu, Mar 15, 2018 at 05:11:10PM +0100, Silvan Jegen wrote: > The disadvantage of this is that you will have to save those > attachments somewhere and then apply them. When using "git send-email" > you can just feed the emails directly to "git am". That depends on what email client you use. Mutt makes piping both whole messages and individual attachments to arbitrary commands pretty painless IMO. Eric
Re: [hackers] [dwm][PATCH] ColBorder has been moved to the enum with ColFg and ColBg.
On Thu, Mar 15, 2018 at 08:28:26PM +0100, Silvan Jegen wrote:
> > That depends on what email client you use. Mutt makes piping both whole
> > messages and individual attachments to arbitrary commands pretty
> > painless IMO.
>
> I use mutt as well but I don't know how to deal with attachments efficiently.
>
> Mails I can just tag so to apply a series of patches sent with "git
> send-email" I tag them and pipe them to "git am". If several patches are
> attached to a mail, I haven't found a good way to download them all in
> one go and then apply them in batch to a repo.
>
> Would definitely like to learn about a more efficient way to deal with
> attached patches in mutt.
Move the cursor to the message in question then invoke view-attachments
("v" by default). From there you can use pipe-message ("|") with
git-apply, and you can tag multiple attachments using tag-message ("t")
just as you would with messages.
Eric
Re: [hackers] [dwm][PATCH] ColBorder has been moved to the enum with ColFg and ColBg.
On Thu, Mar 15, 2018 at 08:44:02PM +0100, Silvan Jegen wrote: > Ah, I wasn't aware that the tags also work on attachments, neat. Thanks > for the tip! > > That means both are equally convenient for me. However, if you send > patches inline (not as attachments) commenting on specific parts of > patches becomes as easy as clicking "reply" (or "r"...). If you add the appropriate MIME types to Mutt's auto_view list (http://www.mutt.org/doc/manual/#auto-view), the contents of the attached patches will be included in your reply, and it will show the patches without you having to switch to attachment mode first. Eric
Re: [hackers] [dwm][PATCH] ColBorder has been moved to the enum with ColFg and ColBg.
On Thu, Mar 15, 2018 at 10:17:25PM +0100, Silvan Jegen wrote: > Still sounds to me like having patches as attachments just causes me to > have to change my default configuration though. Change the world or change your configuration: the choice is yours! By adding a handful of bytes to your Mutt files, you can get the patches to effectively be inlined regardless of how the sender actually sent them. > What is the advantage of attaching the patches instead of just sending > them inline, I wonder. I think a large part of what people prefer will depend on how they access the mailing list. I imagine it's easier for most common mail clients to deal with inline patches when it comes to reviewing & commenting, but I prefer attachments because: - They're easier for me to send. The various mail functions that Git provides make some assumptions about one's MUA that, IMO, make it tedious (albeit scriptable) to use them with Mutt for **sending** patches. If the machine I'm using isn't configured to send emails, it's easier for me to move a patch / diff file between machines rather than a Git-generated email that I'll have to re-edit to fix things like the "From:" header. - I've seen inline patches get munged by MUAs. I have personally sent some broken patches because I forgot to disable automatic text wrapping of an email with an inline patch. - When people send batches of related patches, sending a single email means that all of the patches will be immediately accessible whereas separate emails might not arrive in close proximity to one another or even in order because of things like rate limit and spam countermeasures. Eric
[hackers] [PATCH] [dwm] Make unset property fallback strings configurable
Since the default rule matching does substring comparisons, using the
fixed string "broken" as a fallback value can complicate or make
unambiguous matching impossible, so this change makes various fallback
strings for unset properties configurable via config.h.
---
config.def.h | 5 +
dwm.c| 7 +++
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git config.def.h config.def.h
index a9ac303..8dfc8b1 100644
--- config.def.h
+++ config.def.h
@@ -43,6 +43,11 @@ static const Layout layouts[] = {
{ "[M]", monocle },
};
+/* Fallback strings for unset window properties. */
+static const char unset_instance_fallback[] = "broken";
+static const char unset_class_fallback[] = "broken";
+static const char unset_name_fallback[] = "broken";
+
/* key definitions */
#define MODKEY Mod1Mask
#define TAGKEYS(KEY,TAG) \
diff --git dwm.c dwm.c
index c98678d..9735e32 100644
--- dwm.c
+++ dwm.c
@@ -235,7 +235,6 @@ static int xerrorstart(Display *dpy, XErrorEvent *ee);
static void zoom(const Arg *arg);
/* variables */
-static const char broken[] = "broken";
static char stext[256];
static int screen;
static int sw, sh; /* X display screen geometry width, height */
@@ -288,8 +287,8 @@ applyrules(Client *c)
c->isfloating = 0;
c->tags = 0;
XGetClassHint(dpy, c->win, );
- class= ch.res_class ? ch.res_class : broken;
- instance = ch.res_name ? ch.res_name : broken;
+ class= ch.res_class ? ch.res_class : unset_class_fallback;
+ instance = ch.res_name ? ch.res_name : unset_instance_fallback;
for (i = 0; i < LENGTH(rules); i++) {
r = [i];
@@ -1998,7 +1997,7 @@ updatetitle(Client *c)
if (!gettextprop(c->win, netatom[NetWMName], c->name, sizeof c->name))
gettextprop(c->win, XA_WM_NAME, c->name, sizeof c->name);
if (c->name[0] == '\0') /* hack to mark broken clients */
- strcpy(c->name, broken);
+ strcpy(c->name, unset_name_fallback);
}
void
Re: [hackers] [PATCH] [dwm] Make unset property fallback strings configurable
On Tue, Apr 03, 2018 at 02:07:37PM -0700, Eric Pruitt wrote: > It seems odd to me that Git would create a broken (or perhaps > backward-incompatible) patch because of that option. What version of Git > are you using? I'm running 2.11.0. Actually, the patch fails to apply for me, too, so I've completely axed that option from my configuration. Eric
Re: [hackers] [st][patch] Increase the buffer size for escape sequences
On Mon, Sep 24, 2018 at 10:16:31PM +0200, Ingo Heimbach wrote: > I have recognized that a buffer size of 128*4 bytes is quite small to > store base64 encoded clipboard content (see OSC52), especially when > copying multiple code lines in a terminal editor like vim. I agree that the current buffer is too small. I'm pretty sure I've run into this problem myself with Vim and Bash, but I hadn't gotten around to digging into the problem. Eric
Re: [hackers] [dev][slstatus] FreeBSD port?
On Fri, Jan 25, 2019 at 11:44:43AM +0100, Hiltjo Posthuma wrote: > Please don't send HTML mail to the list. The message had text and HTML components. If you don't like HTML emails, why not configure your client to prefer text/plain portions of multipart/alternative emails? Eric
Re: [hackers] [st][PATCH] st-disable-bold-italic-fonts-0.8.2
On Sat, Mar 30, 2019 at 02:31:56PM +0100, Ryan Kes wrote: > +int disableroman = 0; > [...] > + if (!disableitalic) > + FcPatternAddInteger(pattern, FC_SLANT, FC_SLANT_ITALIC); > + if (!disableroman) > + FcPatternAddInteger(pattern, FC_SLANT, FC_SLANT_ROMAN); I don't think you need separate conditions/booleans for FC_SLANT_ROMAN because roman is the opposite of italic, so the code should read something like this: FcPatternAddInteger(pattern, FC_SLANT, disableitalic ? FC_SLANT_ROMAN : FC_SLANT_ITALIC); Or maybe I don't understand how Fontconfig works. Eric
Re: [hackers] [st][PATCH] st-disable-bold-italic-fonts-0.8.2
On Mon, Apr 01, 2019 at 10:19:30PM -0700, Eric Pruitt wrote: > On Sat, Mar 30, 2019 at 02:31:56PM +0100, Ryan Kes wrote: > > +int disableroman = 0; > > [...] > > + if (!disableitalic) > > + FcPatternAddInteger(pattern, FC_SLANT, FC_SLANT_ITALIC); > > + if (!disableroman) > > + FcPatternAddInteger(pattern, FC_SLANT, FC_SLANT_ROMAN); > > I don't think you need separate conditions/booleans for FC_SLANT_ROMAN > because roman is the opposite of italic, so the code should read > something like this: > > FcPatternAddInteger(pattern, FC_SLANT, disableitalic ? FC_SLANT_ROMAN : > FC_SLANT_ITALIC); > > Or maybe I don't understand how Fontconfig works. I realized that's also wrong as I sent the message. Just get rid of the "disableroman" variable and the associated "if" statement. Eric
Re: [hackers] [st][PATCH] st-disable-bold-italic-fonts-0.8.2
On Tue, Apr 02, 2019 at 08:15:21AM +0200, Ryan wrote: > Feel free to change it. All I did with the patch is change the previous > version so it works with 6.2. I have no interest in the patch itself, just pointing out a problem I saw. Eric
Re: [hackers] [st][PATCH] separate blinking timer from drawing in run()
On Wed, Jan 02, 2019 at 02:50:15AM +0100, kais euchi wrote: > This article [0] made me wonder how to improve latency in st, and i > thought i would share this small modification for a non-blinking setup. > When blinktimeout is set to 0, it reduces latency by ca. 5ms [1] by avoiding > useless delay calculation making it also independent from the xfps setting. I've been using this patch for several weeks, and it seems to resolve a problem I observed where sometimes, in the middle of a screen refresh, st would pause for a perceptible amount of time showing the screen in a half-updated state. Thanks for sharing, Eric
Re: [hackers] [st][PATCH] config: add Ctrl-Tab, Shift-Ctrl-Tab escapes
On Sat, Feb 16, 2019 at 01:05:41AM +0100, Igor Bukanov wrote:
> + { XK_Tab, ControlMask,"\033[1;5I", 0,0},
> + { XK_ISO_Left_Tab, ShiftMask|ControlMask,"\033[1;6I",0,0},
Are these escape sequences unique to Mintty? I wasn't able to find any
other emulators using them. I suspect Mintty is a lot less popular than
Xterm which uses "\033[27;5;9~" and "\033[27;6;9~", so I think it'd make
more sense to use Xterm's escape sequences in config.def.h.
Eric
[hackers] [st] [PATCH] Allow bounding boxes to be specified as absolutes
After upgrading my workstation to Debian 10, changes in Fontconfig and/or DejaVu Sans Mono have changed the values of dc.font.height in my st build. The characters themselves seem to be near pixel-perfect matches. I "fixed" the problem by adjusting the chscale configuration variable to shave a pixel off the bounding box, but since this depends on the character height, I would need to use a separate configuration for my laptop which still runs Debian 9. This patch allows the specification of bounding boxes using either absolute dimensions or the original scaling factors to mitigate that issue. --- config.def.h | 11 ++- x.c | 4 ++-- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/config.def.h b/config.def.h index 482901e..47c4004 100644 --- a/config.def.h +++ b/config.def.h @@ -23,10 +23,19 @@ char *stty_args = "stty raw pass8 nl -echo -iexten -cstopb 38400"; /* identification sequence returned in DA and DECID */ char *vtiden = "\033[?6c"; -/* Kerning / character bounding-box multipliers */ +/* Kerning / character bounding-box configuration. There are two ways to + * configure this: using scaling factors (cwscale and chscale) in which the + * bounding box is computed by multiplying the dimensions returned by + * Fontconfig by the scaling factors or absolute dimensions in pixels (cwidth + * and cheight). The cwscale factor is only used if cwidth is 0, and the + * chscale factor is only used if cheight is 0. + */ static float cwscale = 1.0; static float chscale = 1.0; +static unsigned int cwidth = 0; +static unsigned int cheight = 0; + /* * word delimiter string * diff --git a/x.c b/x.c index 5828a3b..b55b5ad 100644 --- a/x.c +++ b/x.c @@ -956,8 +956,8 @@ xloadfonts(char *fontstr, double fontsize) } /* Setting character width and height. */ - win.cw = ceilf(dc.font.width * cwscale); - win.ch = ceilf(dc.font.height * chscale); + win.cw = ceilf(cwidth ? cwidth : dc.font.width * cwscale); + win.ch = ceilf(cheight ? cheight : dc.font.height * chscale); FcPatternDel(pattern, FC_SLANT); FcPatternAddInteger(pattern, FC_SLANT, FC_SLANT_ITALIC); -- 2.20.1
Re: [hackers] [sbase][PATCH] Add implementation of tac(1)
On Sun, Mar 03, 2024 at 12:34:16AM +0100, Elie Le Vaillant wrote:
> +static void
> +tac(FILE *fp)
> +{
> + struct linebuf buf = EMPTY_LINEBUF;
> + struct line line;
> + getlines(fp, );
> +
> + if (buf.nolf) {
> + /* If the last line is not LF-terminated, the
> + * first output line should not be either */
> + buf.nolf--;
> + buf.lines[buf.nlines - 1].len--;
> + }
> +
> + while (buf.nlines--) {
> + line = buf.lines[buf.nlines];
> + fwrite(line.data, 1, line.len, stdout);
> + free(line.data);
> + }
> + free(buf.lines);
> +}
I'm not sure what level of optimization the maintainers expect, but
personally, I think there should be separate implementations for
seekable vs non-seekable files to avoid buffering the entire contents of
the file in memory unnecessarily.
Eric
