On Mon, 1 Aug 2022 11:09:16 +0200
"Roberto E. Vargas Caballero" wrote:
Dear Roberto,
> Because then you will support only the last systems. If you keep
> the ranlib you will support systems that support all versions of
> the standard. Again, if you find a system without ranlib then
> we can
On Tue, 16 Aug 2022 11:19:55 -0400
fo...@dnmx.org wrote:
Dear fossy,
> Ah.. so very complicated, huh? Oh, well..
it's not a low-hanging-fruit by any means, yes.
> Hey, so.. I have a question.. how come that Suckless' web-site isn't
> hosted using Quark? If I remember correctly - it's Nginx?
>
On Mon, 8 Aug 2022 07:57:51 -0400
fo...@dnmx.org wrote:
Dear fossy,
> I'll try to do it by myself, but I don't promise anything.. It seems
> like the resp files were moved to esnprintf or something.
>
> Sorry for no original e-mail text, DNMX is broken :d
given quark's new structure
On Sun, 31 Jul 2022 12:18:22 +0200
Mattias Andrée wrote:
Dear Mattias,
> Why wouldn't SIZE_MAX be the maximum of size_t?
you're totally right and I changed it. Thanks!
With best regards
Laslo
On Mon, 1 Aug 2022 21:53:45 +0600
NRK wrote:
Dear NRK,
> Given that this no longer shadows a libc/conventional function, I'd go
> one step further and move the `fprintf + exit` check inside
> reallocate_array() so the calling code doesn't need to worry about
> null returns.
thanks for your
On Tue, Aug 16, 2022 at 12:00:52AM +0200, Hiltjo Posthuma wrote:
> I'd like to keep these functions. drw.{c,h} and some util functions are shared
> between some projects.
All the utf8 functions in drw.c are `static`. They can't be used from
another TU, by default at least.
If they *are* being
On Tue, Jul 19, 2022 at 04:38:34PM +0200, nenesses wrote:
> ---
> drw.c | 15 +++
> 1 file changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/drw.c b/drw.c
> index ced7d37..b6073a4 100644
> --- a/drw.c
> +++ b/drw.c
> @@ -25,16 +25,6 @@ utf8decodebyte(const char c, size_t *i)
On Tue, Jul 19, 2022 at 04:38:34PM +0200, nenesses wrote:
> -static size_t
> -utf8validate(long *u, size_t i)
> -{
> - if (!BETWEEN(*u, utfmin[i], utfmax[i]) || BETWEEN(*u, 0xD800, 0xDFFF))
> - *u = UTF_INVALID;
> - for (i = 1; *u > utfmax[i]; ++i)
> - ;
> -
On Sat, Aug 13, 2022 at 08:47:41AM +0200, Stein Gunnar Bakkeby wrote:
> Would it be easier to make the layout
> symbol size 15 (one less than the monitor symbol)?
Not really, since the src might still end up not containing the
nul-byte, the 16th byte will have to nul-terminated anyways. For
Yes it affects readability and I don't like the patch.
BTW please don't send HTML mail to this mailinglist.
Thanks,
On Sat, Aug 13, 2022 at 08:47:41AM +0200, Stein Gunnar Bakkeby wrote:
>Doesn't this affect readability? Would it be easier to make the layout
>symbol size 15 (one less
Doesn't this affect readability? Would it be easier to make the layout
symbol size 15 (one less than the monitor symbol)?
On Sat, 13 Aug 2022, 05:00 NRK, wrote:
> the dwm source code somewhat silently assumes that the symbol will fit
> into 16 bytes. but this may not be the case since users can
On Sat, Aug 13, 2022 at 09:55:00AM +0200, Hiltjo Posthuma wrote:
> I think its simpler to just add the comment if needed.
That's an option, yes. And I've considered it too. But it gets messy
with Unicode/UTF-8 where one visible character != one byte.
If you still think that's the way to go, then
On Sat, Aug 13, 2022 at 09:00:06AM +0600, NRK wrote:
> the dwm source code somewhat silently assumes that the symbol will fit
> into 16 bytes. but this may not be the case since users can define
> longer symbols in `config.h` (and there's no comment or note stating
> anything about the size
On Fri, Aug 12, 2022 at 7:35 AM Storkman wrote:
>
> On Wed, Aug 10, 2022 at 09:29:43PM +0200, Thomas Oltmann wrote:
> > Hi all!
> >
> > I think we can all agree that the current web archive over at
> > lists.suckless.org isn't all that great;
> > Author names get mangled, the navigation is
On Fri, Aug 12, 2022 at 05:56:48PM +0200, Thomas Oltmann wrote:
> Use gitea for what? To host my code instead of on GitHub?
> I agree GitHub is pretty janky, but at least it's readily available.
> I currently don't have a server + domain lying around.
>
> Personally, I think git.suckless.org
Use gitea for what? To host my code instead of on GitHub?
I agree GitHub is pretty janky, but at least it's readily available.
I currently don't have a server + domain lying around.
Personally, I think git.suckless.org would be the best place to host
this particular repo.
But that largely depends
Hi Storkman,
I've now looked through your patches. In order:
1: I agree that the current code is ugly, but I don't want to run the
preprocessing code
on all the fields that we don't even look at.
2: Applied!
3: Applied!
4: Both my original code and your patch were able to overrun the given
Just wondering, why not host a gitea instance? (wait until 1.8 when
Activitypub support is done.)
On Wed, Aug 10, 2022 at 09:29:43PM +0200, Thomas Oltmann wrote:
> Hi all!
>
> I think we can all agree that the current web archive over at
> lists.suckless.org isn't all that great;
> Author names get mangled, the navigation is terrible, some messages
> are duplicated, some missing.
>
> That's
Thanks for the tip,
it might serve as a reference point.
I doubt we would be able to reuse the code as-is,
in large part because it's awkwardly licensed (GPL w/ OpenSSL exception).
On Thu, Aug 11, 2022 at 2:09 AM Sebastian LaVine wrote:
>
> Have you guys heard of bubger?
>
>
On Thu, Aug 11, 2022 at 3:21 PM NRK wrote:
>
> On Thu, Aug 11, 2022 at 01:41:00PM +0200, Thomas Oltmann wrote:
> > This concern is probably completely esoteric, but I can see
> > how the pointer could theoretically overflow on some weird system
> > where the kernel doesn't sit in the higher half
On Thu, Aug 11, 2022 at 01:41:00PM +0200, Thomas Oltmann wrote:
> This concern is probably completely esoteric, but I can see
> how the pointer could theoretically overflow on some weird system
> where the kernel doesn't sit in the higher half of the address space ...
I'm personally not too
Hi NRK!
On Thu, Aug 11, 2022 at 11:10 AM NRK wrote:
>
> On Wed, Aug 10, 2022 at 09:29:43PM +0200, Thomas Oltmann wrote:
> > I think we can all agree that the current web archive over at
> > lists.suckless.org isn't all that great;
> > Author names get mangled, the navigation is terrible, some
On Wed, Aug 10, 2022 at 09:29:43PM +0200, Thomas Oltmann wrote:
> I think we can all agree that the current web archive over at
> lists.suckless.org isn't all that great;
> Author names get mangled, the navigation is terrible, some messages
> are duplicated, some missing.
I've noticed the missing
On Thu, Aug 11, 2022 at 02:02:50AM +0200, Thomas Oltmann wrote:
> Hi Hiltjo,
>
> thanks for the feedback.
>
> > In general the points look good to me. I haven't looked at the code.
> >
> > I think we can ignore some cruft. HTML mail should be avoided, atleast on
> > suckless.
> >
> > Supporting
On Wed, Aug 10, 2022 at 08:09:25PM -0400, Sebastian LaVine wrote:
> Have you guys heard of bubger?
>
> https://git.causal.agency/bubger/
>
> It might be useful for this purpose.
>
I'm not sure, it seems to require IMAP. The tool should work on
raw mails or maildir/mbox instead.
--
Kind
Hi Hiltjo,
thanks for the feedback.
> In general the points look good to me. I haven't looked at the code.
>
> I think we can ignore some cruft. HTML mail should be avoided, atleast on
> suckless.
>
> Supporting nested threads are a must though (imho).
Fair enough.
> Right now there are
On Wed, Aug 10, 2022 at 09:29:43PM +0200, Thomas Oltmann wrote:
> Hi all!
>
> I think we can all agree that the current web archive over at
> lists.suckless.org isn't all that great;
> Author names get mangled, the navigation is terrible, some messages
> are duplicated, some missing.
>
> That's
On Wed, Aug 10, 2022 at 11:02:45AM +0200, Stein Gunnar Bakkeby wrote:
>Hi Hijito,
>I wasn't sure how big of a wall of text to put in the commit comment.
>Let me clarify this first.
>We have a block of code adjusting the client's starting position for
>floating windows where:
>
Hi Hijito,
I wasn't sure how big of a wall of text to put in the commit comment. Let
me clarify this first.
We have a block of code adjusting the client's starting position for
floating windows where:
- if the window position and size exceeds the right hand side of the
monitor, then we move
On Tue, Aug 09, 2022 at 10:38:08AM +0200, Stein wrote:
> The reasoning behind the original line may be lost to time as
> it does not make much sense checking the position on the x-axis
> to determine how to position the client on the y-axis.
>
> In the context of multi-monitor setups the monitor
NRK writes:
ping!
In case this got lost in the noise :)
Thanks for the poke :-)
From my side, I've been running with this patch for a couple of weeks and
everything works fine, so I think it's good to go.
On Mon, Aug 08, 2022 at 07:53:40PM +0600, NRK wrote:
> On Mon, Aug 08, 2022 at 07:47:50PM +0600, NRK wrote:
> > > die should be before ecalloc
> >
> > Why should it be before `ecalloc` ? There's prototype in util.h already.
> > So the order of definition is irrelevant.
>
> Ah, I missed the
On Mon, Aug 08, 2022 at 07:47:50PM +0600, NRK wrote:
> > die should be before ecalloc
>
> Why should it be before `ecalloc` ? There's prototype in util.h already.
> So the order of definition is irrelevant.
Ah, I missed the commit `32fa3f5a code-style: sort function alphabetically`.
Sorting
> die should be before ecalloc
Why should it be before `ecalloc` ? There's prototype in util.h already.
So the order of definition is irrelevant.
- NRK
On Sat, Aug 06, 2022 at 04:27:13AM +0600, NRK wrote:
> main change here is making the `zoom()` logic saner. the rest of the
> changes are just small stuff which accumulated on my local branch.
>
> pop() must not be called with NULL. and `zoom()` achieves this, but in a
> very (unnecessarily)
Meh, it's just one line. usually `0` is reserved for 'success' and 1
or more designed to error codes and so on. If the system decides to
have such unusual way to handle return codes, then EXIT_* values would
be changed.
On Fri, Jul 29, 2022 at 3:19 AM Hiltjo Posthuma wrote:
>
> On Thu, Jul 28,
On Fri, Jul 29, 2022 at 06:26:04PM -0500, explosion0men...@gmail.com wrote:
> From: explosion-mental
>
> when calling die and the last character of the string corresponds to
> ':', die() will call perror(). See util.c
>
> Cuz muh lines of code!1
> ---
> dwm.c | 4 +---
> 1 file changed, 1
On Mon, Aug 01, 2022 at 11:42:44AM +0200, Stein wrote:
> This is in particular to avoid flickering in dwm (and high CPU usage)
> when hovering the mouse over a tabbed window that was previously
> managed by dwm.
>
> Consider the following two scenarios:
>
> 1)
>
> We start tabbed (window
On Sun, Jul 31, 2022 at 11:47:40AM +0200, g...@suckless.org wrote:
> static void *
> -reallocarray(void *p, size_t len, size_t size)
> +reallocate_array(void *p, size_t len, size_t size)
Given that this no longer shadows a libc/conventional function, I'd go
one step further and move the `fprintf
Hi,
On Sun, Jul 31, 2022 at 01:00:25AM +0200, Laslo Hunhold wrote:
> why would it reduce the portability of the Makefiles? It can be
> expected that all ar-implementations support the s-flag, and ranlib is
> simply legacy.
Because then you will support only the last systems. If you keep
the
Why wouldn't SIZE_MAX be the maximum of size_t?
On Sun, 31 Jul 2022 11:47:40 +0200
wrote:
> commit 25d89e6e460e68329e7a3f388fe3e150a8f5474a
> Author: Laslo Hunhold
> AuthorDate: Sun Jul 31 11:46:48 2022 +0200
> Commit: Laslo Hunhold
> CommitDate: Sun Jul 31 11:46:48 2022 +0200
>
>
On Sun, 31 Jul 2022 11:47:40 +0200
wrote:
> commit bdf42537c5792f6beb0360517ff378834cfd8a68
> Author: robert
> AuthorDate: Sat Jul 30 14:29:05 2022 -0700
> Commit: Laslo Hunhold
> CommitDate: Sun Jul 31 11:41:08 2022 +0200
>
> Add reallocarray implementation
>
>
On Sat, 30 Jul 2022 14:29:05 -0700
robert wrote:
Dear Robert,
> reallocarray is nonstandard and glibc declares it only when
> _GNU_SOURCE is defined. Without this patch or _GNU_SOURCE defined, I
> get a seg fault from reallocarray being implicitly declared with the
> wrong signature.
thanks
On Sun, Jul 31, 2022 at 01:00:27AM +0200, Laslo Hunhold wrote:
> as far as I can tell this is not correct, given the program exits with
> EXIT_SUCCESS, not EXIT_FAILURE.
Any specific reason why this matters? If exec(3) fails, I would assume a
non-zero exit status would be more appropriate.
On Fri, 22 Jul 2022 17:28:38 +0200
"Roberto E. Vargas Caballero" wrote:
Dear Roberto,
> I disagree with this change. I think it adds nothing and reduce
> portability of the Makefiles.
why would it reduce the portability of the Makefiles? It can be
expected that all ar-implementations support
On Fri, 29 Jul 2022 18:26:04 -0500
explosion0men...@gmail.com wrote:
Dear explosion0mental,
> when calling die and the last character of the string corresponds to
> ':', die() will call perror(). See util.c
>
> Cuz muh lines of code!1
> - fprintf(stderr, "dwm: execvp %s", ((char
>
On Fri, 22 Jul 2022 17:28:38 +0200
"Roberto E. Vargas Caballero" wrote:
Dear Roberto,
> I disagree with this change. I think it adds nothing and reduce
> portability of the Makefiles.
why would it reduce the portability of the Makefiles? It can be
expected that all ar-implementations support
On Tue, Jul 26, 2022 at 11:57:04PM +0600, NRK wrote:
> On Mon, Jul 04, 2022 at 03:01:35PM +0600, NRK wrote:
> > currently, doing something like the following would fail to build:
> >
> > $ make CFLAGS="-O3 -march=native"
> >
> > this is because CPPFLAGS get mangled with CFLAGS and so
> Hi,
Hi,
> I could not find this specification in the POSIX standard, but [2] > says:
>
> POSIX.1-2001 specifies that if the disposition of SIGCHLD
> is set to SIG_IGN or the SA_NOCLDWAIT flag is set for SIGCHLD
> (see sigaction(2)), then children that terminate do not
On Fri, Jul 29, 2022 at 06:26:04PM -0500, explosion0men...@gmail.com wrote:
> From: explosion-mental
>
> when calling die and the last character of the string corresponds to
> ':', die() will call perror(). See util.c
>
> Cuz muh lines of code!1
> ---
> dwm.c | 4 +---
> 1 file changed, 1
On Thu, Jul 28, 2022 at 07:32:54PM -0500, explosion0men...@gmail.com wrote:
> From: explosion-mental
>
> stdlib.h is included anyway.
> ---
> util.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/util.c b/util.c
> index fe044fc..e03ec21 100644
> --- a/util.c
> +++
Hi,
> > void
> > sigchld(int unused)
> > {
> > + if (signal(SIGCHLD, sigchld) == SIG_ERR)
> > + die("can't install SIGCHLD handler:");
> > while (0 < waitpid(-1, NULL, WNOHANG));
> > }
>
> Calling `die` inside a signhandler is still an issue and can produce
> bad behavior (I
On Mon, Jul 04, 2022 at 03:01:35PM +0600, NRK wrote:
> currently, doing something like the following would fail to build:
>
> $ make CFLAGS="-O3 -march=native"
>
> this is because CPPFLAGS get mangled with CFLAGS and so changing CFLAGS
> kills the build.
>
> similarly it's conventional to
> void
> sigchld(int unused)
> {
> + if (signal(SIGCHLD, sigchld) == SIG_ERR)
> + die("can't install SIGCHLD handler:");
> while (0 < waitpid(-1, NULL, WNOHANG));
> }
Calling `die` inside a signhandler is still an issue and can produce
bad behavior (I have seen a couple
Hi,
> > Do you have a reference of a description of this behaviour in an other
> > system,
> > specification or standard?
> >
>
> C89 (7.7.1.1), C99 (7.14.1.1), POSIX 2001 and 2008 all say that "the
> equivalent of signal(sig, SIG_DFL)" may be executed prior to executing
> the signal handler
I disagree with this change. I think it adds nothing and reduce
portability of the Makefiles.
Regards,
On Tue, Jul 19, 2022 at 09:27:35AM +0200, Hiltjo Posthuma wrote:
> On Tue, Jul 19, 2022 at 12:05:48AM +0200, François-Xavier Carton wrote:
> > Technically, no standard guarantees that the handler stays after being
> > called once. The implementation could reset it to the default action.
> > One
On Tue, Jul 19, 2022 at 12:05:48AM +0200, François-Xavier Carton wrote:
> On Thu, Jul 14, 2022 at 07:26:40AM +0600, NRK wrote:
> > die() calls vprintf, fputc and exit; none of these are
> > async-signal-safe, see `man 7 signal-safety`.
> > ---
> > dwm.c | 4 ++--
> > 1 file changed, 2
On Tue, Jul 19, 2022 at 12:05:48AM +0200, François-Xavier Carton wrote:
> Technically, no standard guarantees that the handler stays after being
> called once. The implementation could reset it to the default action.
Hmm, didn't know about that.
> One may want to re-add a call to signal here,
On Thu, Jul 14, 2022 at 07:26:40AM +0600, NRK wrote:
> die() calls vprintf, fputc and exit; none of these are
> async-signal-safe, see `man 7 signal-safety`.
> ---
> dwm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/dwm.c b/dwm.c
> index 5646a5c..8358fb0 100644
>
On Thu, Jul 14, 2022 at 07:26:40AM +0600, NRK wrote:
> die() calls vprintf, fputc and exit; none of these are
> async-signal-safe, see `man 7 signal-safety`.
> ---
> dwm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/dwm.c b/dwm.c
> index 5646a5c..8358fb0 100644
>
On Thu, Jul 14, 2022 at 07:29:01AM +0600, NRK wrote:
> On Mon, Jul 11, 2022 at 02:01:50PM +0700, Alif Radhitya wrote:
> > Assalamualaikum and good morning from Indonesia, Suckless Team.
> > I'm Alif Radhitya, another suckless user.
> >
> > I created a horizontal and vertical layout with one
On Mon, Jul 11, 2022 at 02:01:50PM +0700, Alif Radhitya wrote:
> Assalamualaikum and good morning from Indonesia, Suckless Team.
> I'm Alif Radhitya, another suckless user.
>
> I created a horizontal and vertical layout with one button like i3 for dwm.
Think this should probably go to the wiki.
On Fri, 8 Jul 2022 11:12:17 -0700
robert wrote:
Dear Robert,
> Unlike snprintf, strftime buffer contents are undefined when it fails,
> so make sure the buffer is null-terminated. To prevent garbage from
> being printed out, we simply set the timestamp to the empty string,
> but maybe setting
Hi,
On 04/07/2022 10:19, NRK wrote:
Hi Laslo,
On Sun, Jun 26, 2022 at 11:16:32PM +0200, Laslo Hunhold wrote:
come on, it is general knowledge that free() accepts NULL arguments.
I don't think that's a true. If it were general knowledge then we
wouldn't see the pattern of `if (ptr)
Hi Laslo,
On Sun, Jun 26, 2022 at 11:16:32PM +0200, Laslo Hunhold wrote:
> come on, it is general knowledge that free() accepts NULL arguments.
I don't think that's a true. If it were general knowledge then we
wouldn't see the pattern of `if (ptr) free(ptr)` in the code to begin
with.
And
Hi Tom,
> - if (!XGetTextProperty(dpy, win, , netwmname) || prop.nitems == 0)
> - if (!XGetWMName(dpy, win, ) || prop.nitems == 0)
> + if (!XGetTextProperty(dpy, win, , netwmname) || !prop.nitems) {
> + if (!XGetWMName(dpy, win, ) || !prop.nitems)
>
> Hi Tom o/
Hi Quentin \o/
> > > > # includes and libs
> > > > -INCS = -I. -I/usr/include -I/usr/include/freetype2 -I${X11INC}
> > > > -LIBS = -L/usr/lib -lc -lm -L${X11LIB} -lXft -lfontconfig -lX11
> > > > +INCS = -I/usr/include/freetype2 -I${X11INC}
> > > > +LIBS = -lm -L${X11LIB} -lXft
On Wed, 29 Jun 2022 09:07:49 +0600
NRK wrote:
Dear NRK,
> reported by clang-tidy.
thank you very much! I pushed it!
Also, even though I appreciate you checking the code, there are
admittedly multiple ugly spots that need refactoring and also known
bugs (especially for the _utf8-functions)
> Hi Quentin,
Hi Tom o/
> > > # includes and libs
> > > -INCS = -I. -I/usr/include -I/usr/include/freetype2 -I${X11INC}
> > > -LIBS = -L/usr/lib -lc -lm -L${X11LIB} -lXft -lfontconfig -lX11
> > > +INCS = -I/usr/include/freetype2 -I${X11INC}
> > > +LIBS = -lm -L${X11LIB} -lXft -lfontconfig -lX11
Hi Quentin,
> I think that you can also drop the || altogether,
> make will just tell you whatever problem it encountered
> while trying to invoque cscope.
>
> > - @mkdir -p ${DESTDIR}${MANPREFIX}/man1
> > - @cp sent.1 ${DESTDIR}${MANPREFIX}/man1/sent.1
> > - @chmod 644
Hi Hiltjo,
> I would remove the echo also for the verbose changes.
I get the point of consistency, but I think an output as the following is more
confusing than helpful.
echo sent build options:
sent build options:
This seems to just pollute stdout with unnecessary information.
Hi Tom,
> Let the Makefile be a bit more verbose and remove unnecessary extensions
> and flags in config.mk.
> ---
> cscope: ${SRC} config.h
> @echo cScope
> - @cscope -R -b || echo cScope not installed
> + cscope -R -b || echo cScope not installed
I think that you can also
On Sun, 26 Jun 2022 21:53:49 +0300
Greg Minshall wrote:
Dear Greg,
> for what it's worth, i'd probably code with the checks, so as to avoid
> future code editors (including myself) doing a double-take, thinking,
> "hmm, did the author consider that case?". (though, of course, you
> did that
Tom,
> Since no operation is performed when free(3) is used on NULL, remove
> the checks.
for what it's worth, i'd probably code with the checks, so as to avoid
future code editors (including myself) doing a double-take, thinking,
"hmm, did the author consider that case?". (though, of course,
On Sun, Jun 26, 2022 at 11:07:52AM +, Tom Schwindl wrote:
> Let the Makefile be a bit more verbose and remove unnecessary extensions
> and flags in config.mk.
> ---
> Makefile | 37 +++--
> config.mk | 18 --
> 2 files changed, 27
On Sat, Jun 25, 2022 at 11:38:20PM +0600, NRK wrote:
> On Sat, Jun 25, 2022 at 05:25:54PM +, Tom Schwindl wrote:
> > -static void run();
> > -static void usage();
> > -static void xdraw();
> > -static void xhints();
> > -static void xinit();
> > -static void xloadfonts();
> > +static void
On Sat, Jun 25, 2022 at 05:25:54PM +, Tom Schwindl wrote:
> -static void run();
> -static void usage();
> -static void xdraw();
> -static void xhints();
> -static void xinit();
> -static void xloadfonts();
> +static void run(void);
> +static void usage(void);
> +static void xdraw(void);
>
On Fri, 24 Jun 2022 11:51:51 +0200
Quentin Rameau wrote:
Dear Quentin,
> > libgrapheme.a: $(SRC:=.o)
> > - $(AR) rc $@ $?
> > + $(AR) rc $@ $(SRC:=.o)
> > $(RANLIB) $@
>
> This works as intended with $?, because then you only update objects
> that are out of date, not *all* objects
Hi,
> libgrapheme.a: $(SRC:=.o)
> - $(AR) rc $@ $?
> + $(AR) rc $@ $(SRC:=.o)
> $(RANLIB) $@
This works as intended with $?, because then you only update objects
that are out of date, not *all* objects inconditionally (just note that
you might want the -u flag too).
On Fri, 17 Jun 2022 13:47:32 -0400
fo...@dnmx.org wrote:
> Is there no better way of sending that long message?
> You ended up in my spam folder, and this is a rarety in-it-self.
> Just though I'd mention that.
> Have a nice day.
Such big commits are a rarity and I see no reason to adapt the
On Mon, 13 Jun 2022 06:11:00 +0600
NRK wrote:
Dear NRK,
> IMO they add unnecessary noise to the repo and commit diff. If this
> was the primary reason, then simply including them in the tarball
> would've sufficed.
>
> However since they already got committed, don't think it's worth
>
On Fri, Jun 10, 2022 at 09:16:03PM +0200, g...@suckless.org wrote:
> Even though the build works fine without them, the release tarball
> should not depend on an internet connection and be self-contained.
IMO they add unnecessary noise to the repo and commit diff. If this was
the primary reason,
On Wed, 8 Jun 2022 17:08:57 +0600
NRK wrote:
Dear NRK,
> On Mon, Jun 06, 2022 at 10:40:33PM +0200, g...@suckless.org wrote:
> > + /* with no breaks we break at the end */
> > + if (off == len) {
> > + return len;
> > + } else {
> > + return off;
> > + }
>
> This
On Mon, Jun 06, 2022 at 10:40:33PM +0200, g...@suckless.org wrote:
> + /* with no breaks we break at the end */
> + if (off == len) {
> + return len;
> + } else {
> + return off;
> + }
This is just the same as `return off;` , is it not?
- NRK
On Mon, May 23, 2022 at 06:39:22PM +0200, Mikau wrote:
> On May 23, 2022 10:21:39 AM GMT+02:00, Hiltjo Posthuma
> wrote:
> >On Sun, May 22, 2022 at 04:22:54PM +0300, Otto Modinos wrote:
> >> Several programs and terminal emulators (see links further down), are
> >> using this variable to
Hello,
`rxvt` seems[0] to be using this variable with a completely different
meaning, so I don't think `COLORTERM=st` is the correct value for us.
[0]:
http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.1.pod#ENVIRONMENT
On May 23, 2022 10:21:39 AM GMT+02:00, Hiltjo Posthuma
wrote:
>On Sun, May 22, 2022 at 04:22:54PM +0300, Otto Modinos wrote:
>> Several programs and terminal emulators (see links further down), are
>> using this variable to indicate truecolor support.
>>
>>
On Sun, May 22, 2022 at 04:22:54PM +0300, Otto Modinos wrote:
> Several programs and terminal emulators (see links further down), are
> using this variable to indicate truecolor support.
>
> https://github.com/termstandard/colors
> https://gitlab.com/gnachman/iterm2/-/issues/5294
>
Hey Arda,
> > I am really sorry, this is my first time posting a patch. I thought this
> > list was for patches and mainstream both. I wanted to send this as a patch,
> > where should I redirect this?
>
> I will redirect it to Wiki again, I have misread the website. Sorry for the
> inconvenience.
I will redirect it to Wiki again, I have misread the website. Sorry for the
inconvenience.
On Sun, May 22, 2022 at 12:11 AM Arda Atci wrote:
> Hi Quentin,
>
> I am really sorry, this is my first time posting a patch. I thought this
> list was for patches and mainstream both. I wanted to send
Hi Quentin,
I am really sorry, this is my first time posting a patch. I thought this
list was for patches and mainstream both. I wanted to send this as a patch,
where should I redirect this?
Sincerely,
Arda
On Sat, May 21, 2022 at 3:10 PM Quentin Rameau wrote:
> Hi Arda,
>
> I like the idea,
Hi Arda,
I like the idea, thanks for the work.
I'm not sure it really should be merged into the main repository though,
a Window Manager doesn't have the purpose of being restarted on the fly,
besides for debugging/testing purposes.
Maybe it would have a better place in the patches section?
On Thu, May 05, 2022 at 09:11:08AM +0200, Antonio Quartulli wrote:
> On 05/05/2022 05:38, Nick Hanley wrote:
> > On Wed, May 04, 2022 at 09:49:33AM +0200, Antonio Quartulli wrote:
> >> On 04/05/2022 00:18, Nick Hanley wrote:
> >>> On Tue, May 03, 2022 at 02:45:05PM -0400, fo...@dnmx.org wrote:
>
Thanks for the patches, they look good to me be I'll do a proper review
this weekend if nobody else did before.
Cheers!
It is worth nothing that I also talked to mcf off list and he said
getting a finished implementation of pax might be an even better option
as that is a posix standard
On 05/05/2022 05:38, Nick Hanley wrote:
On Wed, May 04, 2022 at 09:49:33AM +0200, Antonio Quartulli wrote:
On 04/05/2022 00:18, Nick Hanley wrote:
On Tue, May 03, 2022 at 02:45:05PM -0400, fo...@dnmx.org wrote:
Just wondering - why not just do
if (*getstyle(geturi(c)))
setstyle(c, file);
Hi Andrew,
> Posix tarballs use extended headers to represent paths and values that do
> not fit in the original ustar header format. This patch implements parsing
> and handling of a subset of these extended headers. The motivating
> tarball was the gcc source code, which exceeds the original
On Wed, May 04, 2022 at 09:49:33AM +0200, Antonio Quartulli wrote:
> On 04/05/2022 00:18, Nick Hanley wrote:
> > On Tue, May 03, 2022 at 02:45:05PM -0400, fo...@dnmx.org wrote:
> >> Just wondering - why not just do
> >> if (*getstyle(geturi(c)))
> >>setstyle(c, file);
> >
> > We need to pass
On 04/05/2022 00:18, Nick Hanley wrote:
On Tue, May 03, 2022 at 02:45:05PM -0400, fo...@dnmx.org wrote:
Just wondering - why not just do
if (*getstyle(geturi(c)))
setstyle(c, file);
We need to pass the file path returned by getstyle to setstyle.
An alternative would be to keep the
301 - 400 of 2783 matches
Mail list logo
