On Thu, 1 Oct 2020 09:04:32 +0100
Daniel Littlewood wrote:
Dear Daniel,
> My argument that the GPL is simpler here is that in the "default case"
> where changes are simply submitted without the contributor talking
> about licensing, the project as a whole is not covered by the given
> license
Dear Laslo,
> as far as I know, there's no need for a CLA. CLAs are just a
> simplification that contributors waive their rights to the code to the
> legal entity behind the project so the license file is not littered
> with 100s of people but only the legal entity. Which license you're
> using
On Wed, 30 Sep 2020 22:41:47 -0700
Michael Forney wrote:
Dear Michael,
> POSIX says we should be counting column positions rather than
> codepoints, but I think that might be rather difficult to get right
> and this is probably an improvement already.
>
> I know Laslo has studied this area for
On Wed, 30 Sep 2020 19:06:32 +0100
Daniel Littlewood wrote:
Dear Daniel,
> I am wary of going too far off topic, but I think a convincing
> argument against the use of "permissive" licenses like MIT is that if
> your project grows above a certain size, it necessitates CLAs in
> addition to a
On 2020-06-20, Richard Ipsum wrote:
> diff --git a/fold.c b/fold.c
> index 9c3c919..a54594b 100644
> --- a/fold.c
> +++ b/fold.c
> @@ -19,7 +19,7 @@ foldline(struct line *l) {
> for (i = 0, last = 0, col = 0, spacesect = 0; i < l->len; i++) {
> if (!UTF8_POINT(l->data[i]) &&
Hey Richard,
Thanks for the reminder about the patches.
On 2020-09-30, Richard Ipsum wrote:
> Hi, looks like these patches got lost/forgotten,
> is there any reason to not merge them?
Sorry about that. I hadn't forgotten about them, I had just been
putting off digging into the code to review
POSIX says we should be counting column positions rather than
codepoints, but I think that might be rather difficult to get right
and this is probably an improvement already.
I know Laslo has studied this area for libgrapheme, so maybe he has
suggestions.
On 2020-06-20, Richard Ipsum wrote:
>
Hi Pedro,
Thanks for those mentions, I love the qutebrowser project and am
warmed to see other examples of GPL projects finding ways to monetise
their work.
I am wary of going too far off topic, but I think a convincing
argument against the use of "permissive" licenses like MIT is that if
your
* Ingo Feinerer le [30-09-2020 15:11:29 +0200]:
> On Wed, Sep 30, 2020 at 02:42:07PM +0200, prx wrote:
> > Find attached a patch to support (not so new) sndiod OpenBSD.
>
> FYI: https://lists.suckless.org/hackers/2005/17308.html
Nice, thanks a lot !
I totally missed that, and still was using
Hi, Laslo and Hiltjo,
> You don't sell CDs with your software anymore (this
> worked maybe 20 years ago), but you can make good money with providing
> support, which is, I think, the most probable direction.
> > I think for businesses a development-model of selling and providing
> > the full
On Wed, Sep 30, 2020 at 02:42:07PM +0200, prx wrote:
> Find attached a patch to support (not so new) sndiod OpenBSD.
FYI: https://lists.suckless.org/hackers/2005/17308.html
Best regards,
Ingo
On Wed, 30 Sep 2020 14:06:39 +0200
Hiltjo Posthuma wrote:
Dear Hiltjo,
> The last sentence regarding non-financial political interests is not
> true/misleading. See also the page "Selling Free Software":
> https://www.gnu.org/philosophy/selling.en.html
interesting link, thanks for sharing.
On Wed, Sep 30, 2020 at 11:41:03AM +0200, Laslo Hunhold wrote:
> On Wed, 30 Sep 2020 11:19:43 +0200
> Hiltjo Posthuma wrote:
>
> Dear Hiltjo,
>
> > I actively search for FOSS in my life and think using software which
> > is GPL-licensed is fine.
>
> yeah, opinions differ here of course. I also
On Wed, 30 Sep 2020 11:19:43 +0200
Hiltjo Posthuma wrote:
Dear Hiltjo,
> I actively search for FOSS in my life and think using software which
> is GPL-licensed is fine.
yeah, opinions differ here of course. I also use a lot of GPL-licensed
software, but avoid it in terms of
On Wed, Sep 30, 2020 at 08:32:52AM +0200, Laslo Hunhold wrote:
> On Tue, 29 Sep 2020 20:01:41 +0100
> Daniel Littlewood wrote:
>
> Dear Daniel,
>
> > Thanks for your reply - I appreciate that this does not have much
> > practical importance. Unfortunately the simplest way for me to version
> >
On Tue, 29 Sep 2020 20:01:41 +0100
Daniel Littlewood wrote:
Dear Daniel,
> Thanks for your reply - I appreciate that this does not have much
> practical importance. Unfortunately the simplest way for me to version
> my dwm copy is by hosting it on Github, which is in some sense
> "publishing"
Thank you very much Chris for your reply.
I just tried again, from scratch, and failed again, with the same error.
Early on today I successfully installed other suckless patches, this time
for st, following the same procedure and everything worked flawlessly. In
fact since I have two other
Hi Vinícius,
The error message from patch is quite clear that it failed to apply, so
compilation is premature. You need to either massage it in, or find a patch
which roughly matches your version.
Dear Laslo,
Thanks for your reply - I appreciate that this does not have much
practical importance. Unfortunately the simplest way for me to version
my dwm copy is by hosting it on Github, which is in some sense
"publishing" it. I was hoping to be able to do this without worrying,
but it seems
On Tue, 29 Sep 2020 09:54:43 +0100
Daniel Littlewood wrote:
Dear Daniel,
> Hi all, apologies if this is the wrong mailing list (I couldn't tell
> exactly where to send it).
>
> Could someone please confirm for me what the licensing status of
> patches hosted on the suckless domain is? I assume
Quoth Hiltjo Posthuma:
> On Thu, Sep 24, 2020 at 02:00:47PM +0530, Sarthak Shah wrote:
> > This patch adds a tatami arrangement to dwm, accessible through modkey+y
>
> Please submit this to the wiki as it's not an upstream patch and do not submit
> non-upstream patches to hackers@.
>
>
On Thu, Sep 24, 2020 at 02:00:47PM +0530, Sarthak Shah wrote:
> This patch adds a tatami arrangement to dwm, accessible through modkey+y
Hi,
Please submit this to the wiki as it's not an upstream patch and do not submit
non-upstream patches to hackers@.
https://suckless.org/community/
The
On 2020-09-14, Tait Hoyem wrote:
> Here is the new patch:
Thanks, applied.
> + printf("%zd\n", bytecount);
This should be %zu (size_t is an unsigned type), but I fixed this up
when applying.
> From: Spenser Truex
Hello Spenser,
Thanks for the patch, a few comments :
Throughout the patch, there are indentation issues.
> Ensure that the keybindings are like vim, and not just made up.
This should be rephrased, precising that it's about vertical
mode, and nothing is made up.
> Old
On 20/09/15 12:16PM, Pedro Lucas Porcellis wrote:
> > I find the original blue border difficult to see
>
> I do as well! I really think your patch should be merged upstream, as
> it's a better color overall.
Thank you!
It took me awhile to realise that what I needed wasn't some patch like
"gaps"
> I find the original blue border difficult to see
I do as well! I really think your patch should be merged upstream, as
it's a better color overall.
Changes to the default config are what personal forks are for IMO.
Sent from ProtonMail mobile
Original Message
On Sep. 15, 2020, 14:22, wrote:
> From: Spenser Truex
>
> I find the original blue border difficult to see, and it is especially
> hard to notice against the same
Thanks, Laslo, and Micheal!
I decided to keep the fputs() for consistency's sake.
Here is the new patch:
>From a41d12fb9ef3fc36db34e7368b27d54413532165 Mon Sep 17 00:00:00 2001
From: Tait Hoyem
Date: Mon, 14 Sep 2020 22:18:57 +
Subject: [PATCH] Add bytecount print to 'w' command
---
ed.c
On Sun, 13 Sep 2020 15:14:53 -0700
Michael Forney wrote:
Dear Michael,
> I think we should use a different type than int here. I'm not sure if
> size_t or off_t is more appropriate, but size_t is probably
> reasonable.
I think size_t is more reasonable here, because it's easier to work
with
Thanks for the patch.
On 2020-09-07, Tait Hoyem wrote:
> diff --git a/ed.c b/ed.c
> index cee9687..82b9c2c 100644
> --- a/ed.c
> +++ b/ed.c
> @@ -623,14 +623,16 @@ static void
> dowrite(const char *fname, int trunc)
> {
> FILE *fp;
> - int i, line;
> + int i, line, bytecount;
I
Hi,
The WM_ICON_NAME is often used in X programs as a shorter Title name.
Originally some window managers would use this as the text for an Icon to
represent the running program, these days it's more likely to be used in a
taskbar. Some shells will have a different configuration to set the
On Sun, Sep 06, 2020 at 05:53:41PM +1200, John Collis wrote:
> Also added _NET_WM_ICON_NAME.
> ---
> st.c | 9 +
> win.h | 1 +
> x.c | 16 +++-
> 3 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/st.c b/st.c
> index 8cf7245..ccef9c4 100644
> --- a/st.c
>
On Wed, 2 Sep 2020 19:01:10 +0200
Hiltjo Posthuma wrote:
Dear Hiltjo,
congrats on the newly released version! :)
> I'd also like to say there is now a separate Atom feed added per
> repository to stagit and to git.suckless.org to make tracking only
> releases easier for maintainers which
> bump version to 5.0
\o/
Hiltjo Posthuma writes:
Hiltjo, any objections?
I have no objections (your Honour) and released dmenu 5.0.
Wonderful, thank you! Have a great rest of your week. :-)
Chris
On Tue, Sep 01, 2020 at 04:49:49PM +0100, Chris Down wrote:
> Hey folks,
>
Hi,
> Unlike a lot of the rest of our software, generally dmenu works pretty well
> even as a distribution-provided binary package, since usually users only
> want to change colours, fonts, and other stuff that can be
On Wed, Aug 26, 2020 at 08:27:18PM +, tdu wrote:
> From dfd158c8dea87a0a4dbc5b2eda7c096069d1484a Mon Sep 17 00:00:00 2001
> From: tdu
> Date: Wed, 26 Aug 2020 18:50:09 +0300
> Subject: [PATCH] Add the following tags for the status2d patch: ^w^ -
> Swaps bg/fg color. ^v^ - Saves the
Hi Leonardo,
* Leonardo Taccari [2020-08-23 09:59]:
The attached patch in this email fix this issue.
Thanks! +1 for including in master.
Cheers Jochen
signature.asc
Description: PGP signature
On Mon, 17 Aug 2020 22:58:06 +0200
Armin Friedl wrote:
Dear Armin,
thanks for your patch! One thing in advance: The indentation is a bit
messed up (spaces instead of tabs), but let's first discuss the
contents.
> Currently, maxnprocs may actually lower the limit. Especially when
> using the
On Mon, Aug 17, 2020 at 03:47:27AM -0700, Jeremy wrote:
> Then should the functions which use the global variable, "term", in st.c
> accept a Term pointer instead?
>
> In the case of st, I believe this may affect readability slightly,
> however, it would allow for some extensibility(if dvtm, for
On Mon, 17 Aug 2020 03:47:27 -0700
Jeremy wrote:
Dear Jeremy,
thanks for your feedback. In any case, before diving into this topic,
st's maintainer (Hiltjo) has the final say on these things. It's not a
clear-cut debate and depends largely on personal taste and practicality.
> Then should the
Then should the functions which use the global variable, "term", in st.c
accept a Term pointer instead?
In the case of st, I believe this may affect readability slightly,
however, it would allow for some extensibility(if dvtm, for example,
wanted to rewrite its terminal implementation).
I'm not
On Sat, 15 Aug 2020 15:32:11 -0700
robert wrote:
Dear Robert,
thanks for your patch!
> Previously, all hidden targets were rejected with 403, but
> /.well-known/ and its contents should be an exception.
>
> - /* reject hidden target */
> - if (realtarget[0] == '.' || strstr(realtarget,
Hello Job,
> 'make clean' now removes config.h
Wrong
> 'make dist' should no longer exit with error code 1
Good
On Wed, 5 Aug 2020 19:54:10 +0200
Hiltjo Posthuma wrote:
Dear Hiltjo,
> > - /* Open a new process group */
> > + /* open a new process group */
> > setpgid(0,0);
> ^
> Theres no space there. It's an injustice :P
thanks for pointing that out! I fixed it. :)
With
On Wed, Aug 05, 2020 at 07:14:08PM +0200, g...@suckless.org wrote:
> commit 2318a89ecd7aad5a296b657caec22beff92a4284
> Author: Laslo Hunhold
> AuthorDate: Wed Aug 5 19:14:10 2020 +0200
> Commit: Laslo Hunhold
> CommitDate: Wed Aug 5 19:14:10 2020 +0200
>
> Begin comment in lowercase
On Sun, Aug 02, 2020 at 08:57:06PM +0200, Maarten van Gompel wrote:
> ---
> svkbd.c | 102 ++--
> 1 file changed, 55 insertions(+), 47 deletions(-)
>
> diff --git a/svkbd.c b/svkbd.c
> index 1ff77f9..132a52d 100644
> --- a/svkbd.c
> +++
On 20-08-02 06:42, Hiltjo Posthuma wrote:
> Thanks for improving the patches. There are many changes so bear with me to
> review them. It may take some time.
No problem, thanks for looking at it.
> Some notes:
> - The man page should list and document all the (new) options:
>-D, -O,
On Sun, Aug 02, 2020 at 03:46:05PM +0200, Maarten van Gompel wrote:
> This is v2 of a big patch for svkbd. The overall intention is to make
> svkbd viable keyboard on a smartphone (the pinephone in particular).
> Svkbd is the keyboard of choice in the SXMO project
> (https://sr.ht/~mil/Sxmo/) by
On Sun, Aug 02, 2020 at 03:46:05PM +0200, Maarten van Gompel wrote:
> This is v2 of a big patch for svkbd. The overall intention is to make
> svkbd viable keyboard on a smartphone (the pinephone in particular).
> Svkbd is the keyboard of choice in the SXMO project
> (https://sr.ht/~mil/Sxmo/) by
Hi Hiltjo et al,
Thanks for your feedback. It took a bit before I could dive back into it.
Comments inline:
On 20-07-25 01:26, Hiltjo Posthuma wrote:
> On Fri, Jul 24, 2020 at 09:49:55PM +0200, Maarten van Gompel wrote:
> > From: Miles Alan
> >
> > Fix SIGTERM handler - flip terminate flag in
On 2020-07-14, Hiltjo Posthuma wrote:
> The below patch adds an -f flag to force fork(2)ing and creating a new
> process.
Thanks, I applied the patch.
Though I wonder, is Linux the only operating system that typically has
setsid(1)? It doesn't look like it is available on BSDs. It's such a
On Tue, Jul 14, 2020 at 10:15:43AM +0200, Hiltjo Posthuma wrote:
> Hi,
>
> The below patch adds an -f flag to force fork(2)ing and creating a new
> process.
>
>
> From a75ef384c11b64732dd6a3adc9249ba6beb8a67e Mon Sep 17 00:00:00 2001
> From: Hiltjo Posthuma
> Date: Tue, 14 Jul 2020 10:11:43
On Fri, Jul 24, 2020 at 09:49:59PM +0200, Maarten van Gompel wrote:
> ---
> README.md | 87
> config.def.h | 1 +
> layout.sxmo.h | 39 +-
> svkbd.c | 107 +-
> 4 files changed,
On Fri, Jul 24, 2020 at 09:49:58PM +0200, Maarten van Gompel wrote:
> ---
> README| 63 ---
> layout.sxmo.h | 168 --
> svkbd.c | 165 -
> 3 files changed, 297
On Fri, Jul 24, 2020 at 09:49:55PM +0200, Maarten van Gompel wrote:
> From: Miles Alan
>
> Fix SIGTERM handler - flip terminate flag in sigterm handler & cleanup
> properly
>
> Modify run function to use select() with a timeout since X events will be
> blocked otherwise and terminate wouldn't
On Tue, 21 Jul 2020 10:41:53 -0700
Jeremy wrote:
Dear Jeremy,
> From: Jeremy Bobbin
thanks for your patch! I've applied it.
With best regards
Laslo
On Tue, 21 Jul 2020 20:38:41 +0200
Hiltjo Posthuma wrote:
Dear Hiltjo,
> I would use timegm(). It is not in POSIX, but it does exactly the
> right thing. It should be available in glibc, musl and on all BSDs.
>
> Hacking around mktime to get the correct result has some gotcha's. I
> would not
On Tue, Jul 21, 2020 at 07:51:56PM +0200, Laslo Hunhold wrote:
> On Sun, 19 Jul 2020 09:37:31 -0700
> Jeremy wrote:
>
> Dear Jeremy,
>
> I wrote this this mail yesterday, but the mailing list had some
> technical problems, so I'm resending it.
>
> > stat(3)'s mtime is in local time while
On Sun, 19 Jul 2020 09:37:31 -0700
Jeremy wrote:
Dear Jeremy,
I wrote this this mail yesterday, but the mailing list had some
technical problems, so I'm resending it.
> stat(3)'s mtime is in local time while REQ_MOD is in GMT.
> This patch translates mtime to GMT before comparing to REQ_MOD.
Hey Hiltjo,
I appreciate your feedback. That suggestion works well and is nicer.
I've submitted the modified patch.
Thanks!
Jeremy
On 07/19/20 10:33PM, Hiltjo Posthuma wrote:
> On Sun, Jul 19, 2020 at 09:37:31AM -0700, Jeremy wrote:
> > From: Jeremy Bobbin
> >
> > stat(3)'s mtime is in local
On Sun, Jul 19, 2020 at 09:37:31AM -0700, Jeremy wrote:
> From: Jeremy Bobbin
>
> stat(3)'s mtime is in local time while REQ_MOD is in GMT.
> This patch translates mtime to GMT before comparing to REQ_MOD.
> ---
> http.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git
At some point one might want to force a refresh for example after
checking email or changing the volume. Sending a SIGUSR1 achieves this
now.
---
slstatus.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/slstatus.c b/slstatus.c
index 96fa5b6..ee42786 100644
---
On Tue, Jul 14, 2020 at 02:45:14PM +0200, Mart Lubbers wrote:
> Dear all,
> I've submitted this patch before but maybe I did something wrong (it was
> before
> the confirmation mail of the subscription). If there is anything else off with
> this email/patch, please let me know.
> Best,
>
>
On Tue, Jul 14, 2020 at 12:15:20PM +0200, Mattias Andrée wrote:
> Hi,
>
> Is there any reason you would want to force it?
>
>
Yes, when getpgrp() != getpid().
I use this in my plumb script for my news program to setsid -f and open a link
my browser. Using the setsid -f option the browser is
Hi,
Is there any reason you would want to force it?
Regards,
Mattias Andrée
On Tue, 14 Jul 2020 10:15:43 +0200
Hiltjo Posthuma wrote:
> Hi,
>
> The below patch adds an -f flag to force fork(2)ing and creating a new
> process.
>
>
> From a75ef384c11b64732dd6a3adc9249ba6beb8a67e Mon Sep
On Sun, Jul 05, 2020 at 07:39:19PM +, miz...@protonmail.com wrote:
> ---
> ii.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/ii.c b/ii.c
> index 7ca3ee8..426fcff 100644
> --- a/ii.c
> +++ b/ii.c
> @@ -102,7 +102,6 @@ ewritestr(int fd, const char *s)
> for (off = 0; off <
On 2020-07-03 18:40:09+0200, Hiltjo Posthuma wrote:
> On Wed, Jul 01, 2020 at 09:29:25PM +0200, joris.k...@gmail.com wrote:
> > From: Joris Klaasse Bos
> >
> > Before this commit, running st on a system with musl libc would
> > result in a segmentation fault. This is because musl implements
> >
Thanks, applied.
This hasn't been included in the mainline yet, but I have been trying it
out for the past couple of weeks.
One implication of these changes that I have found is that dialog boxes may
be marked with the WM_TRANSIENT_FOR hint, indicating to the window manager
that it is a transient top-level
On Wed, Jul 01, 2020 at 09:29:25PM +0200, joris.k...@gmail.com wrote:
> From: Joris Klaasse Bos
>
> Before this commit, running st on a system with musl libc would
> result in a segmentation fault. This is because musl implements
> locales differently, which means the function
>
On 01/07/20, Daniel Moch wrote:
> On Wed, Jul 01, 2020 at 08:53:57PM +0200, albanb wrote:
> > From: Alban Brillat
> >
> > Statuscolor patch fix for 6.2 release (quite late...). The current patch is
> > really slow,
> > because of the time spent by the macro TEXTW for the raw characters used
>
On Wed, Jul 01, 2020 at 08:53:57PM +0200, albanb wrote:
> From: Alban Brillat
>
> Statuscolor patch fix for 6.2 release (quite late...). The current patch is
> really slow,
> because of the time spent by the macro TEXTW for the raw characters used
> to define color.
> Never tried to submit a
On Tue, Jun 23, 2020 at 11:26:27AM -0700, Michael Forney wrote:
> Thanks for testing this out, Richard.
>
> On 2020-06-23, Richard Ipsum wrote:
> > I don't feel qualified to criticise the overall design, but do we not still
> > need a way to specify whether traversal should be pre-order or
On Tue, 23 Jun 2020 11:43:41 -0700
Michael Forney wrote:
Dear Michael,
> I don't think it will be a problem. We are not interested in the path
> with an appended trailing slash, it is just an intermediate step in
> constructing the path to the child. When we add the final path
> component, we
On 2020-06-23, Laslo Hunhold wrote:
> isn't that a bug waiting to happen when anything about the semantics of
> the function later changes?
I don't think it will be a problem. We are not interested in the path
with an appended trailing slash, it is just an intermediate step in
constructing the
Thanks for testing this out, Richard.
On 2020-06-23, Richard Ipsum wrote:
> I don't feel qualified to criticise the overall design, but do we not still
> need a way to specify whether traversal should be pre-order or post-order?
> I figure this is what DIRFIRST was for right?
The effective
On Tue, Jun 23, 2020 at 02:30:51AM -0700, Michael Forney wrote:
> recurse() is peculiar function since it is used for two purposes:
>
> 1. To bootstrap the recursion process.
> 2. To perform recursion when a directory is encountered.
>
> In the first case, we stat() the directory, record it in
On Sun, 21 Jun 2020 07:20:29 +0200 (CEST)
g...@suckless.org wrote:
Dear Michael,
> We know that r->pathlen < sizeof(r->path) since r->path is
> nul-terminated, so we can safely add a '/' here. If there is no
> space left over for the rest of the path and nul-terminator, this
>
On 2020-06-03, Richard Ipsum wrote:
> path is not fixed up on exit from recursive step, this leads to
> incorrect paths in du's output.
Thanks, applied with a small tweak to keep the invariant that
r->pathlen == strlen(r->path).
Hi,
Attached patch with commit message.
Br,
Jakub Leszczak
On Thu, Jun 11, 2020 at 6:32 PM Hiltjo Posthuma wrote:
>
> On Sun, Jun 07, 2020 at 08:36:57PM +0200, Jakub Leszczak wrote:
> > Hi,
> >
> > What is the status of this patch? I do not see it being added to the
> > mainline, nor any new
In Thu, 11 Jun 2020 22:14:31 +0200
Hiltjo Posthuma wrote:
> On Thu, Jun 11, 2020 at 01:56:21PM +0500, Nikita Zlobin wrote:
> > workdir could be got from active client via xprop, then set for
> > spawned client. Terminals can pass it with xprop -id ${WINDOWID}
> > command from hook, created for
On Thu, Jun 11, 2020 at 03:28:32PM +0200, Alex Flierl wrote:
> The function drw_fontset_free in drw.c was never called.
> ---
> drw.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drw.c b/drw.c
> index 8fd1ca4..4cdbcbe 100644
> --- a/drw.c
> +++ b/drw.c
> @@ -95,6 +95,7 @@
On Sun, Jun 07, 2020 at 08:36:57PM +0200, Jakub Leszczak wrote:
> Hi,
>
> What is the status of this patch? I do not see it being added to the
> mainline, nor any new messages for some time.
>
> Br,
> Jakub Leszczak
>
Hi Jakub,
Can you send the last version one more time? The last sent
In Thu, 11 Jun 2020 08:47:09 +0200
Laslo Hunhold wrote:
> On Thu, 11 Jun 2020 11:42:40 +0500
> Nikita Zlobin wrote:
>
> Dear Nikita,
>
> > One more reason to propose utf. I have read this to better
> > understand Xft: https://keithp.com/~keithp/talks/xtc2001/paper
> >
> > It mentions, that
On Thu, 11 Jun 2020 11:42:40 +0500
Nikita Zlobin wrote:
Dear Nikita,
> One more reason to propose utf. I have read this to better understand
> Xft: https://keithp.com/~keithp/talks/xtc2001/paper
>
> It mentions, that Xft requires unicode. Not sure, what unicode type is
> meant, but at least
In Wed, 10 Jun 2020 22:09:01 +0200
Hiltjo Posthuma wrote:
> On Thu, Jun 04, 2020 at 02:13:49PM +0500, Nikita Zlobin wrote:
> > At least some desktop tools (non-mainstream) are in trouble with
> > tabbed window name. At the moment of try I have only tint2 and
> > rofi. First just showes intitled,
In Wed, 10 Jun 2020 22:09:01 +0200
Hiltjo Posthuma wrote:
> On Thu, Jun 04, 2020 at 02:13:49PM +0500, Nikita Zlobin wrote:
> > At least some desktop tools (non-mainstream) are in trouble with
> > tabbed window name. At the moment of try I have only tint2 and
> > rofi. First just showes intitled,
In Wed, 10 Jun 2020 22:10:02 +0200
Hiltjo Posthuma wrote:
> On Thu, Jun 04, 2020 at 04:01:17PM +0500, Nikita Zlobin wrote:
> > unmanage() after killclient() causes at least one BadDrawable from
> > client. For urxvtd it can crash entire daemon.
> > ---
> > tabbed.c | 2 +-
> > 1 file changed, 1
On Thu, Jun 04, 2020 at 04:01:17PM +0500, Nikita Zlobin wrote:
> unmanage() after killclient() causes at least one BadDrawable from client.
> For urxvtd it can crash entire daemon.
> ---
> tabbed.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tabbed.c b/tabbed.c
>
On Thu, Jun 04, 2020 at 02:13:49PM +0500, Nikita Zlobin wrote:
> At least some desktop tools (non-mainstream) are in trouble with tabbed
> window name.
> At the moment of try I have only tint2 and rofi. First just showes intitled,
> but
> second - "Invalid encoding". Though xfwm4 has no problem
In Thu, 4 Jun 2020 16:21:40 -0400
Daniel Moch wrote:
> On Thu, Jun 04, 2020 at 11:26:15AM +0500, Nikita Zlobin wrote:
> > Somewhat disconvenient after true multitab terminals, that new term
> > tabs don't inherit workdir from previous active. Here is some
> > attempt to make such a bond.
>
> My
‐‐‐ Original Message ‐‐‐
On Wednesday, June 10, 2020 12:11 PM, Hiltjo Posthuma
wrote:
> On Wed, Jun 10, 2020 at 02:03:48PM +, Michel Boaventura wrote:
>
> > Hi,
> > This patch brings Vanity Gaps to master, because the current patch on the
> > site does not apply after f09418b.
> >
On Wed, Jun 10, 2020 at 03:20:35PM +, Michel Boaventura wrote:
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, June 10, 2020 12:11 PM, Hiltjo Posthuma
> wrote:
>
> > On Wed, Jun 10, 2020 at 02:03:48PM +, Michel Boaventura wrote:
> >
> > > Hi,
> > > This patch brings Vanity Gaps to
Hi,
What is the status of this patch? I do not see it being added to the
mainline, nor any new messages for some time.
Br,
Jakub Leszczak
In Thu, 4 Jun 2020 16:21:40 -0400
Daniel Moch wrote:
> On Thu, Jun 04, 2020 at 11:26:15AM +0500, Nikita Zlobin wrote:
> > Somewhat disconvenient after true multitab terminals, that new term
> > tabs don't inherit workdir from previous active. Here is some
> > attempt to make such a bond.
>
> My
In Thu, 4 Jun 2020 16:21:40 -0400
Daniel Moch wrote:
> On Thu, Jun 04, 2020 at 11:26:15AM +0500, Nikita Zlobin wrote:
> > Somewhat disconvenient after true multitab terminals, that new term
> > tabs don't inherit workdir from previous active. Here is some
> > attempt to make such a bond.
>
> My
On Thu, Jun 04, 2020 at 11:26:15AM +0500, Nikita Zlobin wrote:
> Somewhat disconvenient after true multitab terminals, that new term
> tabs don't inherit workdir from previous active. Here is some attempt
> to make such a bond.
My memory is that terminals in this case inherit their working
Hi!
On Wed, Jun 03, 2020 at 02:11:37PM +0200, Rhylx wrote:
> https://raw.githubusercontent.com/Rhylx/surf/master/chromebar.diff
Can you resend this email embedding the diff on it?
You can find more info on the hacking [1] page and on git-send-mail [2]
as well.
---
[1]:
On Sat, 9 May 2020 10:10:39 +0200
Mattias Andrée wrote:
Dear Mattias,
> > I don't like this change, because it destroys reentrancy, which is
> > very importent for multithreaded applications, and complicates
> > things unnecessarily.
>
> malloc(3) and free(3) are thread-safe, so there
801 - 900 of 2784 matches
Mail list logo
