Re: [dev] [surf][stylesheet][startpage] New ownership of Startpage not reflected in description

[NRK]

On Fri, Mar 29, 2024 at 05:00:29PM +, dev@1reverse.engineer wrote:
> The description under suckless/surf/stylesheets/startpage tells the
> user, that startpage is "hiding your identity [...]", yet after
> Startpage's change of ownership, users might receive a false sense of
> privacy as outlined in this article:
> https://restoreprivacy.com/startpage-system1-privacy-one-group/
> Therefore, a removal of such passage is recommended.

The git repo of the suckless website is publicly writeable. Feel free to
push your changes in there directly: https://suckless.org/wiki/

- NRK

Re: [dev] [sbase] Defining scope of sbase and ubase

[NRK]

> Everything in the quoted part seems personal preference.

I've been managing my vim plugins with git submodules via vim's builtin
"packadd" directory structure (~/.config/vim/pack/plugins/start/...).
And I can tell you that trying to do anything remotely non-trivial with
them is simply not a pleasant experience.

Recent example, there's no way to simply rename a submodule (the --name
argument to `submodule add`). You need to edit `.gitmodule` file,
edit `.git/config` file along with updating the .git symlinks inside the
module and `.git/module` and probably who knows what else. At the end, I
just `rm -rf` everything and re-cloned all the modules.

Maybe in the future git submodule's UI will be better but as of now it's
a PITA to use.

- NRK

Re: [dev] Announcing a couple small X11 utilities

[NRK]

Hi,

> I've addressed most of your concerns, please check the attached patch
> and let me know what else can be done.

I've added a commit to `selx` that allows you to pick a monitor [0]. You
can either use the cli flag:

$ sxot -g $(selx -m 0)

or select a monitor interactively via Ctrl+RightClick:

$ sxot -g $(selx)

The reason I haven't added it to `sxot` is because I'm assuming that
there are existing "standard" tools that can extract monitor information
already (xrandr maybe?). So it's better to reuse those existing tools.
But if that assumption turns out to be incorrect then I might
reconsider.

[0]: 
https://codeberg.org/NRK/selx/commit/cbf753b97fbefe31c2553fa629878d20df88e6e3

- NRK

Re: [dev] dev

[NRK]

Having trouble unsubscribing? Worry not, coach NRK is at your service!
For a fair pay of 1337 XMR, you'll receive:

★★★ A comprehensive guide on how to unsubscribe from the suckless dev mailing 
list ★★★

Offer available for a limited time only.

- NRK

Re: [dev] [dmenu][bug report] Second instance invisible

[NRK]

On Fri, Sep 22, 2023 at 12:22:25PM +0100, Christopher Lang wrote:
> I'm guessing that when the second dmenu opens, the first one is still
> fading out and this stops XCreateIC from working as intended?

Worth noting that according to the docs XCreateIC() may return NULL -
something that isn't checked for in dmenu. Perhaps you're getting a NULL
ic due to your config? Does the attached patch make any difference?

- NRK
>From defc910ce1fa51e3031af19abae8c70b3b8b8106 Mon Sep 17 00:00:00 2001
From: NRK 
Date: Fri, 22 Sep 2023 23:42:10 +0600
Subject: [PATCH] check for XCreateIC failure

---
 dmenu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/dmenu.c b/dmenu.c
index 40f93e0..a38e7b5 100644
--- a/dmenu.c
+++ b/dmenu.c
@@ -696,6 +696,8 @@ setup(void)
 
xic = XCreateIC(xim, XNInputStyle, XIMPreeditNothing | XIMStatusNothing,
XNClientWindow, win, XNFocusWindow, win, NULL);
+   if (xic == NULL)
+   die("XCreateIC failed");
 
XMapRaised(dpy, win);
if (embed) {
-- 
2.41.0

Re: [dev] getting rid of cmake builds

[NRK]

On Fri, Sep 22, 2023 at 04:07:15PM +0200, Roberto E. Vargas Caballero wrote:
> can you explain me how you solve the problem of duplicated static
> symbols?

It's not as big of a problem you're making it out to be. Neither dwm or
st for example has duplicated static symbols.

And it's easily solvable by having a slightly more descriptive name
(avoiding unnecessary global variables also reduces chances of
collision).

> Can you explain me where is the complexity?

I've already given a list of things on my initial post.

But if I need to repeat one of them: Dependency tracking is easily the
biggest problem that incremental builds introduce. Which is something that:

a) your tiny example makefile did not tackle
b) dwm makefile gets wrong as it does not track drw.h nor util.h
  (dmenu also fails to track util.h as well).

Aside from that, unity-build only requires a compiler. A Makefile
additionally requires (i) a Make implementation (ii) (usually) a posix
compliant shell.

Also this conversation feels like it's going in circles with me having
to constantly repeat things I've already said, so I'll say this:

If you're already convinced that a makefile is better than a unity
build, then that's fine. I'm not interested in forcing you to use
something else. Nor am I interested in fighting some
editor^W build-system war.

But I've tried out both makefiles (both simple and "complex" ones) and
unity-build and *my* conclusion is that the latter is significantly
simpler and superior for small projects - and I've given a list of
reason on my initial post.

If someone thinks those are valid reasons, then try it out. If not, then
don't.

- NRK

Re: [dev] getting rid of cmake builds

[NRK]

On Fri, Sep 22, 2023 at 12:33:15PM +0200, Roberto E. Vargas Caballero wrote:
> In a Makefile (in a good well written) you only have to pass a
> different CFLAGS value

Either I haven't communicated properly, or people are not reading
clearly. In either case, here's a practical example using a fresh ST
repo:

$ make
# ... builds st
$ make CFLAGS="-g3 -fsanitize=address,undefined"
# ... builds nothing because make doesn't take CFLAGS changes into 
account.

I've seen some (hacky) ways to dump the flags into a file to trigger
re-build more reliably. But as I've said, it's a solution to a self-made
problem.

> but in the shell script

There is no shell script involved. You invoke the compiler directly with
whatever flags you please. There's no need to track dependencies or
flags.

And this is no longer the 50s, we have enough memory to build a couple
thousand line of code without *requiring* splitting things into multiple
intermediate object files to avoid going OOM (even with bloated
compilers like gcc/clang with optimization enabled).

Incremental builds are not free. And for small projects, the complexities
they bring is (IMO) much higher compared to the benefits (which are
either non-existent or negligible for small projects).

> that is not about build systems, is about software design:

This is true. But it is also true that when people have a hammer in
hand, everything looks like a nail.

When someone start off with an over-complicated build system, they tend
to also end up over-engineering the software architecture as a result of
the build system making it easy to over-complicate things.

- NRK

Re: [dev] getting rid of cmake builds

[NRK]

On Fri, Sep 22, 2023 at 11:18:47AM +0200, Страхиња Радић wrote:
> ./build.sh

I did not advocate for `build.sh`.

And the wikipedia article I linked explains how unity-builds works
pretty well already: https://en.wikipedia.org/wiki/Unity_build

But in short: you simply include any `.c` file into one. There's zero
problem adapting to a different compiler or compiler flags. In fact,
it's *easier* to do than a makefile (which I also said on my previous
mail).

$ gcc -o exe src.c
$ clang -o exe src.c   # no need to "clean" anything

Doing cross-platform is also easy by just making your core application
"platform-agonistic" and having the "platform layer" provide platform
specific functionality. For example, here's a hypothetical
`app-windows.c` file:

#include "app.c" // platform-agonistic application
// ...
// now add windows specific functionalities and
// an entry point (i.e main function) below.

And the same for a "app-posix.c". And then you compile in a single
command, for example:

$ cc -o exe src-posix.c# on posix platforms
$ cl src-windows.c [...]   # on windows with msvc without requiring 
mingw or similar

- NRK

Re: [dev] getting rid of cmake builds

[NRK]

On Fri, Sep 22, 2023 at 10:00:56AM +0200, Страхиња Радић wrote:
> How does it decide when rebuilding is needed? Does it track dependencies and 
> how?

IMO in small projects, these are problems that should be *avoided entirely*
instead of creating them and then solving it. E.g you can have a simple
unity build [0] that builds everything in a single translation-unit via
a single compiler command:

$ cc -o exe src.c

This requires:

- No build system whatsoever.
- No dependency tracking.
- No need to run `make clean` or similar when changing compiler flags
  (e.g adding Sanitizers, testing with more aggressive warnings or
  optimization flags etc).
- Usually faster full builds (even compared to parallel make) due to not
  having to re-parse the same system headers again and again along with
  avoiding other fixed costs.
- Nearly as fast as incremental builds or at least not noticeably slower
  that would hamper developer productivity (reminder: for small projects).
- Better warnings due to compiler (and static analyzers) being able to
  look across TU boundaries. [1]
- Simple build makes it easier to use other tools on the project such as
  static analyzers or fuzzers.

Some tend to argue that this "doesn't scale", but as I said, this is for
small projects. And the chances of your small project turning into the
next linux kernel [2] with 30M LoC is probably not high. So don't create
new *actual problems* by trying to solve an imaginary one.

[0]: https://en.wikipedia.org/wiki/Unity_build
[1]: you can add LTO to overcome this. But then your incremental builds
will usually become _significantly slower_ because LTO (as of now at
least) makes the linking process extremely slow.
[2]: *even in* large projects, unity builds are still useful to speed up
compilation. For example the infamous linux kernel "fast header" patches
included reducing TUs by, "consolidating .c files":
https://lore.kernel.org/lkml/ydifz+lmewets...@gmail.com/T/#u

- NRK

Re: [dev] [dmenu][bug report] Second instance invisible

[NRK]

On Thu, Sep 21, 2023 at 02:02:12PM +0100, Christopher Lang wrote:
> I run the following shell command:
>   seq 2 | dmenu && seq 3 | dmenu
> The first dmenu instance opens as expected. I hit the enter key and a 1
> is printed. However, the second dmenu instance does not appear.

Cannot reproduce on my system, tried on unpatched master branch and v5.2.
The 2nd dmenu instance appears just fine after the first one closes.

If you can consistently reproduce, then attach gdb to the 2nd instance
(via `gdb --pid`) and try to inspect what might be going wrong compared
to a non-buggy case.

- NRK

Re: [dev] sbm dmenu bookmarker

[NRK]

On Sun, Jul 30, 2023 at 05:18:35PM -0300, Spenser Truex wrote:
> A friend of mine was impressed with how quickly I was spamming the most
> based and redpilled links from this script and wanted me to publish it.

Best marketing for a bookmark program ever.

> the "code"
> https://github.com/equwal/sbm

You should really get rid of the useless use of cats (it's common enough
mistake that it even has an abbreviation - UUOC [0]).

Most unix commands accept a file, so instead of `cat file | sort` you
can just do `sort file`. And in cases where the command doesn't accept a
file, you can use shell redirection, e.g `https://en.wikipedia.org/wiki/Cat_(Unix)#Useless_use_of_cat

- NRK

Re: [dev] Announcing a couple small X11 utilities

[NRK]

Hi Yan,

On Sat, Jul 29, 2023 at 02:46:29PM +0200, Yan Doroshenko wrote:
> I've created a patch for sxot that adds a -m (--monitor) param that allows
> to select which monitor to capture in a multihead setup. Let me know what
> you think.

Thanks for the patch, I don't use a multimonitor setup to test it out
properly, but there are already a couple things which aren't too good.

+   int m[1];
+   str_to_int(str_from_cstr(argv[++i]), m);

str_to_int() does certain error checking (such as overflow) and returns
false in case of failure. That return value should not be ignored. It
should fatally error out if str_to_int() returns false.

It's also weird to use `int m[1]` instead of using `int m` and then
taking a pointer.

+   XRRScreenResources *screen;
+   screen = XRRGetScreenResources (x11.dpy, 
DefaultRootWindow(x11.dpy));

I'm not familiar with Xrander (and my local manpage is lacking
documentation for this function) but given that it returns a pointer, it
most likely needs to be error checked.

+   XRRCrtcInfo *crtc_info;
+   crtc_info = XRRGetCrtcInfo (x11.dpy, screen, 
screen->crtcs[m[0]]);

Same here, most likely needs error checking. But even more importantly:

screen->crtcs[m[0]]

one can never assume anything about data that came from outside. There's
no guarantee that m[0] won't be bigger than the len of `screen->crtcs`.

I see that there's a `ncrtc` member, which likely contains the len of
`crtcs`. You should check to make sure that it doesn't exceed that.

If you compile with AddressSanitizer (see the "recommended debug build"
on the README) and input some absurdly high value, you'll notice the
buffer overflow:

$ ./sxot -m 1024 >/dev/null
=
==11432==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x61a02600 at pc 0x00404271 bp 0x7ffe95aa74a0 sp 0x7ffe95aa7498

And even if you enter a valid value, ASan reports 2 leaks (output
cleaned up):

$ ./sxot -m 0 >/dev/null
SUMMARY: AddressSanitizer: 1296 byte(s) leaked in 2 allocation(s).

So something probably needs to be freed above.

- NRK

Re: [dev] Suckless DNS server

[NRK]

On Wed, Jul 19, 2023 at 03:20:21PM -0700, Jeremy wrote:
> crypto_uint16 uint16_unpack_big(const unsigned char *x) 
> crypto_uint16 y;
> 
> y  = x[0]; y <<= 8;
> y |= x[1];
> 
> return y;
> }
> 
> As you're probably already aware, if there were 3 answers, and you
> were running this on a Big Endian machine, the program would attempt to
> iterate over 768 answers.

I fail to see how that'd happen. The above routine takes a 16bit big
endian encoded byte stream and places the bytes into the right place
*regardless* of what the host system's byte order is.

C standard defines shift operator as multiplication and division by
powers of 2. And the result of `x * 256` never depend on the system's
byte order and so neither does `x << 8`.

Rob Pike already has an excellent article on this, so I'll just refer to
that: https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html

(Though keep in mind that the shift of 24 needs to be casted to
unsigned - i.e `(unsigned)data[3]<<24` - to avoid UB due to the result being
bigger than `INT_MAX`).

> Instead, one can use htons(byteorder.3).

If anything, those functions are precisely the source of confusion like
these and should be avoided for this reason.

As already explained in Rob's article above, the host system's byte
order is almost never relevant, what matters is what byte order is the
data stream encoded in. As long as you know that, you can simply shift
the bytes into proper place *never* needing to ask or know about the
host system's byte order.

- NRK

Re: [dev] Suckless DNS server

[NRK]

> const char *e_str(int i)
> {
>   X(0,"no error");
>   X(EINTR,"interrupted system call")
>   X(ENOMEM,"out of memory")
>   X(ENOENT,"file does not exist")
>   X(ETXTBSY,"text busy")
>   X(EIO,"input/output error")
>   ...
>   return "unknown error";
> }
> 
> Maybe this is just comedy?

The real comedy is strerror() not being thread-safe because on certain
implementation it returns a static buffer:
https://man.freebsd.org/cgi/man.cgi?query=strerror=0#end

> void byte_copy(void *yv, long long ylen, const void *xv) {
> 
> long long i;
> const char *x = xv;
> char *y = yv;
> 
> for (i = 0; i < ylen; ++i) y[i] = x[i];
> }
> 
> Of course, byte_copy is superior to memcpy & strncpy here because he's
> copying some pretty long(!) strings.

I do no know what the purpose of this was, but interface wise, it is
indeed superior to memcpy because it can deal with
`n == 0 && (src == NULL || dst == NULL)` case without invoking UB:
https://port70.net/~nsz/c/c99/n1256.html#7.21.1p2

| n can have the value zero [but] pointer arguments on such a call shall
| still have valid values

And in practice, compilers like to mark any arguments to string.h
functions as non-null unconditionally due to the above reason.
https://godbolt.org/z/brz7jhchr

---

FYI I'm not exactly interested in defending dq because I know nothing
about it, but the above criticism at least seems more like knee jerk
reaction due to something being different rather than actual/technical
criticism.

- NRK

Re: [dev] [dwm][PATCH] Add function to exec into another executable

[NRK]

Hi Dmitry,

>  but I don't need to restart X, which is much more annoying.

There's no need to patch anything to achieve this. You can do something
like this in your xinitrc:

while :; do dwm; done

This will re-run dwm after it quits. And if you want to quit for real,
then you can just invoke `shutdown`.

- NRK

Re: [dev] Help to debug window name with special characters

[NRK]

On Thu, Jul 06, 2023 at 10:23:45AM -0300, Dr. André Desgualdo Pereira wrote:
> Second, xprop change from
> WM_NAME(STRING) = "André Desgualdo Pereira.odt - OpenOffice Writer"
> to 
> WM_NAME(STRING) = "André Desgualdo Pereira.odt - OpenOffice Writer"
> and also a new attibute seems to be added:
> _NET_WM_NAME(STRING) = "Andr\303\251 Desgualdo Pereira.odt - OpenOffice 
> Writer"

"\303\251" is a utf8 sequence (in octal) which maps to U+00E9 (é):
https://www.compart.com/en/unicode/U+00E9

DWM (and dmenu) deals specifically with utf8 IIRC. I'm not sure what
encoding those other two are using, but it's probably not using utf8
which is why it's not working.

Try to see if there's some settings in those application (or their
gui libraries) to make them use utf8.

- NRK

Re: [dev] Announcing a couple small X11 utilities

[NRK]

On Thu, Jul 06, 2023 at 03:43:31PM -0400, fo...@dnmx.org wrote:
> I love such tools.. Is it possible to make something console-based?

Most terminal emulators (I think?) already have some option to
dump the screen content into some image format. If not, I don't
think it'd be difficult feature to add to the terminal -
especially for simple image formats like ppm or farbfeld.

And it makes more sense for it to be done by the terminal
emulator, since it /already/ has parsed all the escape codes and
rendered a pixmap - instead of doing it via an external tool
which would need to duplicate all that work.

- NRK

Re: [dev] Help to debug window name with special characters

[NRK]

On Wed, Jul 05, 2023 at 08:11:39AM -0300, Dr. André Desgualdo Pereira wrote:
> Also xprop show the window name correctly, but wmctrl shows "N/A".

You might want to share the full output of xprop. Otherwise just sharing
the `*_NAME` properties is fine too: `xprop | grep _NAME`

Since you said it works on debian 11, it might also be useful to share
the output of them from debian 11 and compare with 12 to see if anything
changed.

(Specifically, I'm interested in the "type" of the property. If it's
anything other than STRING or UTF8_STRING then that might be a hint.)

- NRK

Re: [dev] Minimalist software. Should I care?

[NRK]

On Tue, Jul 04, 2023 at 07:06:12PM +0300, Nikita Krasnov wrote:
> What would be the point of using minimalist software if bloated and
> excessively complex programs completely satisfy all my needs?

I ask this question the other way around, "Why would I use a bloated
complex program when a simple one fills my needs?"

https://youtube.com/watch?v=k0qmkQGqpM8

> Such minimalism just seems unpractical to me.

My experience has been the opposite, it's the bloated programs that are
hard to customize whenever I want to do something even *slightly*
outside the box.

But at the end of the day, I'm not really interested in trying to
forcefully "convert" you (or anyone else) since I believe that people
should be able to do what they want with their computers.

- NRK

Re: [dev] Announcing a couple small X11 utilities

[NRK]

On Tue, Jul 04, 2023 at 04:37:23PM -0400, Sebastian LaVine wrote:
> I'm curious, what inspired you to write this instead of using xwd?

Never really knew that it existed :) Going by the manpage, it seems to
do a bit more than I'd like, but overall it doesn't seem too bad.

- NRK

[dev] Announcing a couple small X11 utilities

[NRK]

Hi all,

I'd like to share some small X11 utilities that I've developed and have
been using in my daily setup. The utilities are all fairly small in
size and requires only typical X libraries.

sxcs


This is a simple color picker and magnifier. My issue with all other
existing minimal color pickers were that due to no magnification,
picking out specific pixels was fairly difficult.

The usage is simple, you launch the program and pick a color. The result
will be output to stdout in tab separated RGB, HSL and HEX format.

Repo: https://codeberg.org/NRK/sxcs
SLoC: ~628
Dependencies: Xlib, libXcursor

sxot


This one is a *very minimal* screenshot tool. I wrote this when I
realized that other cli screenshot tools (scrot, maim) do way too much.

sxot on the other hand is meant to follow the unix philosophy - it
simply takes a screenshot and outputs a binary ppm image to stdout.
Any other functionalities are supposed to be handled by more specialized
tools. E.g sx4 (see below) for selection, optipng to convert to png,
xclip for copying to clipboard etc.

Repo: https://codeberg.org/NRK/sxot
SLoC: ~251
Dependencies: Xlib, libXfixes

sx4
===

This one is a selection tool. It outputs the selection rectangle to
stdout which can then be used for other purposes, such as screenshoting
or screen-recording a specific area.

Repo: https://codeberg.org/NRK/sx4
SLoC: ~500
Dependencies: Xlib, libXext

---

And that's all. Feel free to report any bugs, send bug-fixes, request
additional features (within the project's scope) etc.

- NRK

Re: [dev] [license] gpl issues

[NRK]

Hi Hiltjo,

> you'd have to keep both the MIT license with the original copyright
> information.

I believe this part is true because almost all MIT style licenses (with
some exception such as `MIT-0`) have the following restriction:

The above copyright notice and this permission notice shall be included 
in
all copies or substantial portions of the Software.

> I think you can relicense only your own changes to GPL [...]
>
> And probably explain very clearly to which new parts the GPL license applies.

However, I don't believe these are true. Because there's nothing in the
MIT license that requires tracking which part is new nor is there
anything preventing derivative work under a different license.

So my understanding is more or less the same as what Markus Wichmann
said on the other reply.

- NRK

Re: [dev] [dwm] swallow without patching dwm -- or losing focus

[NRK]

On Thu, May 25, 2023 at 07:42:04PM -0300, Spenser Truex wrote:
> I converted this swallow program to C, not that it makes any difference
> at this code size. It's just a couple of malloc'd strings.
> 
> https://github.com/equwal/swallow-c--

$ ./swallow '$(rm -fr $HOME)'

`system` is a function that should never be used unless the person is
aware of all the shell shenanigans that can bite back. The above is an
extreme example, but *any* character that has special meaning to shell
can cause problems.

You should instead look into exec and/or posix_spawn functions before
going any further.

- NRK

Re: [dev] organizing programs

[NRK]

On Sun, May 14, 2023 at 09:55:16PM +0200, Sebastiano Tronto wrote:
> I could not find any tool that was simple enough for my taste, so I
> rolled my own[0].
>
> [0] https://git.tronto.net/sdep

Not too bad, and since the source was pretty small, I decided to take a
glance. Here's some unsolicited review:


9 #define min(X,Y) (Xhttps://c-faq.com/cpp/safemacros.html


11 /*
12  * Maximum number of characters in a line. The rest will be 
truncated.
13  * Change this if you need very long lines.
14  */
15 static const int MAXLEN = 1;

`const` in C doesn't mean "constant expression", and so if you use
`buf[MAXLEN]` you'll get a VLA (compile with -Wvla and you should see warning
about it). Either use a #define or an enum.

https://c-faq.com/ansi/constasconst.html


55 static Options default_op();

`f()` does not do what you might think. A function without an argument list
takes *unspeficied* amount of arguments, not zero arguments (a historical
baggage). These have been obsolete since C99 and newer clang version defaults
to erroring out on it, see: https://wiki.gentoo.org/wiki/Modern_C_porting

Explicitly use `f(void)` instead.


71  next->ev.text = malloc(sizeof(char) * l);

sizeof(char) is *defined* to be always 1. So it's not really doing anything:
https://c-faq.com/malloc/sizeofchar.html


72  strncpy(next->ev.text, text, l);

`strncpy` doesn't nul-terminate in case the soruce is bigger than the dest.
Additionally strncpy will *always* write `n` bytes even if the soruce fits into
the dest. This is rarely the semantic people want and 99% of the time I see
strncpy used it's typically either bugger, misused, or enefficient.

There is no standard "copy and truncate if needed" function. Closest you can
find would be memccpy:

if (memccpy(dest, src, '\0', n) == NULL)
dest[n - 1] = '\0';

You can wrap this in function or roll your own (TIP: if you have your string 
copy
function return a pointer to the nul-byte in dest, then you can use it for
efficient concat: https://www.symas.com/post/the-sad-state-of-c-strings).


216 static char *
217 strtrim(char *t)
218 {
219 char *s;
220 
221 for (s = [strlen(t)-1]; s != t && isspace(*s); *s = '\0', 
s--);
222 for (; *t != '\0' && isspace(*t); t++);

The entire ctype library is badly designed because it only accepts input that's
either EOF or [0, UCHAR_MAX]. From the manpage:

| These functions check whether c, which must have the value of an unsigned char
| or EOF (otherwise the behavior is undefined)

Either cast the argument to `unsigned char` or just roll your own. (Also
keep in mind that `plain char` can be either signed or unsigned
depending on the implementation).

Also the name `strtrim` steps into the namespace reserved by .
You can rename it to `str_trim` to avoid it.


And that's mostly it from a quick glance. Slightly relevant:
http://www.catb.org/~esr/writings/unix-koans/ten-thousand.html

- NRK

Re: [dev] organizing programs

[NRK]

On Fri, May 12, 2023 at 02:11:33PM -0400, LM wrote:
> I'd be curious to know what tools other people use on the list to
> handle organizational jobs such as time and task scheduling, todo
> lists, habit tracking, displaying/printing calendars, etc.  Any
> recommendations?  If you use more than one application, which programs
> work together or chain well?  Thanks.

In the past I've used taskwarrior [0] for managing todos. It's a cli
application with pretty much most features you might expect out of a
todo app (and as a result of it, the source isn't as small/lean as
typical suckless style software). Not sure if this is the type of thing
you're after or not, but I figured I'd mention it.

However, I no longer use it (or any other todo application) because I
realized these "organizational" application cause more distraction than
productivity (for me at least).

[0]: https://taskwarrior.org/

- NRK

Re: [dev] Simpler WiFi alternatives

[NRK]

On Fri, May 12, 2023 at 10:10:31PM +0200, Yan Doroshenko wrote:
> Hello everyone,
> 
> I'd like to take a moment and thank everyone for an extremely polite,
> respectful and to the point discussion regarding the topic at hand. I was
> immensely pleased to have witnessed such a splendid display of a real
> community spirit as well as an immense level of professionalism. No doubt
> everyone involved is absolutely content with himself as well as his actions
> and would have no doubt conducted the same way were it a face to face
> discussion.

It is true that this thread has been a massive cesspool. But
passive-aggressive replies like this does not help the situation - it
only contributes more to the cesspool.

- NRK

Re: [dev] [license] gpl issues

[NRK]

On Sun, May 07, 2023 at 11:31:04AM +0200, Страхиња Радић wrote:
> but the arguments presented in it leave me unconvinced.

The "maneuverings" argument in specific was entirely misdiagnosed. Even
in his own example (redhat trying to remove /etc) you can clearly see it
has nothing to do with GPL and everything to do with _adoption_.

Let's imagine a world where the linux ecosystem (including the GNU
tools) were permissively licensed. And now redhat wants to remove
`/etc`. Of course, if redhat was the only distro that did this, most
applications wouldn't adopt their policy - leaving them with an insane
amount of packages which will be broken on their distro - making this
plan infeasible.

According to that article's logic:

This kind of "hijacking" and political maneuverings never happen
with a permissive license like the BSD or MIT licenses.

in this imaginary universe, redhat would just go, "Hmm, we didn't get
what we wanted, but since linux is BSD licensed, we'll just give up."
Does that sound realistic? Of course not. They would've done exactly
what they're doing right now - trying to push their policies unto every
(or at least most) distros via the virus that is systemd so that their
policies gain _adoption_ among applications/libraries. Linux being
GPL/BSD makes zero difference when you need adoption from a massive
amount of third party applications.

If you want a real world example, just look at wayland-protocol, which
is MIT licensed. According to that articles logic, Valve can just fork
it and add their custom-protocol and implement it in their compositor.

But if Valve's compositor is the only compositor that implement's a
protocol, then most applications won't follow/adopt it and thus the
protocol will be useless.

So the reality of the situation is that Valve is still "maneuvering" and
trying to get what they want into the upstream wayland-protocol so that
it gains adoption. The MIT license made zero difference.

- NRK

Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.

[NRK]

Hi,

On Sat, Apr 08, 2023 at 04:28:15PM +0200, p...@mailbox.org wrote:
> I bind keyboard shortcut to launch dmenu_extended[1] in dwm, what works
> flawlessly before the `Use sigaction(SA_NOCLDWAIT) for SIGCHLD
> handling` [1] commit, since dmenu_extended does not change anything here,
> is this a regression or bug introduced with this commit or
> dmenu_extended need to adapt to conform the change? thanks.

You'll need to provide more information. What does your config look
like? Does dwm print any error message to stderr? Did you try to
reproduce with a vanilla dwm? Etc.

Without providing more information it's not possible to say what's going
on here, especially because that commit doesn't really do anything to
process launching. Which takes me to the question, how did you verify
that it's this commit that's causing the problem?

Because the commit right before it (89f9905 grabkeys: Avoid missing
events when a keysym maps to multiple keycodes) seems like something
that might actually mess with keybinds. (Try changing your
dmenu_extended keybind to something else and see if that works or not).

- NRK

Re: [dev] dwm 6.4 compilation error on FreeBsd

[NRK]

> dwm.c:1549:31: error: use of undeclared identifier 'SA_NOCLDWAIT'
> sa.sa_flags = SA_NOCLDSTOP | SA_NOCLDWAIT | SA_RESTART;
>  ^
> dwm.c:1549:46: error: use of undeclared identifier 'SA_RESTART'
> sa.sa_flags = SA_NOCLDSTOP | SA_NOCLDWAIT | SA_RESTART;

Both of those are specified by POSIX and the FreeBSD manpage has it as well:
https://man.freebsd.org/cgi/man.cgi?query=sigaction=0=0=FreeBSD+13.1-RELEASE+and+Ports=default=html

I think we might need to define `_XOPEN_SOURCE=700L`. Does this fix the
issue:

diff --git a/config.mk b/config.mk
 # flags
-CPPFLAGS = -D_DEFAULT_SOURCE -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809L 
-DVERSION=\"${VERSION}\" ${XINERAMAFLAGS}
+CPPFLAGS = -D_DEFAULT_SOURCE -D_BSD_SOURCE -D_XOPEN_SOURCE=700L 
-DVERSION=\"${VERSION}\" ${XINERAMAFLAGS}

- NRK

Re: [dev] [st] Font problem

[NRK]

On Thu, Feb 09, 2023 at 07:46:09PM +0200, Juozas Auryla wrote:
> Is it a bug or i did something wrong?

How do you expect people to be able to answer that when you haven't
provided any steps to reproduce the problem. What exact font
configuration is xfce-terminal using? What exact font configuration is
st using? What's your system font-config setting? Etc.

- NRK

Re: [dev] [dwm] view() and toggleview() functions

[NRK]

On Mon, Jan 16, 2023 at 08:21:57PM +0900, A Farzat wrote:
> Btw, on the email subject it says [SPAM Warning!]. Is it anything I need
> to be concerned with?

No, you're good. It was just a false positive on my end and I forgot to
remove that before replying.

- NRK

Re: [SPAM Warning!][dev] [dwm] view() and toggleview() functions

[NRK]

On Sun, Jan 15, 2023 at 06:28:55PM +0900, A Farzat wrote:
> 2- In the view() function, there is this line:
> ```c
> selmon->seltags ^= 1; /* toggle sel tagset */
> ```
> What is the purpose of this line? In fact, what is the purpose of having
> two tagsets in the first place? From what I see, all the tag
> functionality can be achieved using only one tagset.

It's for going back to the previous layout via `MODKEY+TAB`.

- NRK

Re: [dev] [st] compilation warnings/errors

[NRK]

On Sun, Nov 13, 2022 at 09:46:00AM +0600, Enan Ajmain wrote:
> But if you're asking why the Makefile of st doesn't use these flags by
> default then I think the makefile is supposed to be used by the end user
> and the user should not be required to deal with warnings. Unless they
> want to, in which case they can include the flags themselves.

Adding to this, warning can change from compiler to compiler, from
version to version and even the same compiler and same version can emit
different warnings depening on other flags (e.g a lot of warnings in gcc
aren't active unless certain optimization flags are active as well).

This makes `-Werror` not a good idea for build process that's supposed
to be run by the users; packagers often have to patch flags like this
out for example [0].

Also, wiki patches are community maintained. If you find a problem with
a specific patch, then just push the fix directly:
https://suckless.org/wiki/

[0]: https://flameeyes.blog/2009/02/25/future-proof-your-code-dont-use-werror/

- NRK

Re: [dev] [libsl][bug] Call FcFini on cleanup for projects calling FcIni

[NRK]

On Sun, Oct 30, 2022 at 12:50:54PM -0700, Anskrevy wrote:
> And here is my valgrind output
> https://gist.github.com/Anskrevy/b981453fb7fbe3fb410ac1dd883d23ad

Looking at the backtrace it doesn't seem like it generated anywhere from
libsl (or your program)

==2726510== 288 (256 direct, 32 indirect) bytes in 1 blocks are 
definitely lost in loss record 192 of 320
==2726510==at 0x4841888: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2726510==by 0x49E9F25: FcPatternObjectInsertElt (fcpat.c:525)
==2726510==by 0x49EE180: FcPatternObjectAddWithBinding (fcpat.c:711)
==2726510==by 0x49FC079: UnknownInlinedFun (fcpat.c:1258)
==2726510==by 0x49FC079: UnknownInlinedFun (fcxml.c:3109)
==2726510==by 0x49FC079: FcEndElement (fcxml.c:3234)
==2726510==by 0x4D2E61E: doContent (xmlparse.c:3047)
==2726510==by 0x4D2BCB3: UnknownInlinedFun (xmlparse.c:2612)
==2726510==by 0x4D2BCB3: doProlog (xmlparse.c:4893)
==2726510==by 0x4D2D7CC: prologProcessor (xmlparse.c:4598)
==2726510==by 0x4D31879: XML_ParseBuffer (xmlparse.c:2009)
==2726510==by 0x49F67E4: 
FcConfigParseAndLoadFromMemoryInternal.lto_priv.0 (fcxml.c:3544)
==2726510==by 0x49F7136: _FcConfigParse.lto_priv.0 (fcxml.c:3679)
==2726510==by 0x49F7319: UnknownInlinedFun (fcxml.c:3447)
==2726510==by 0x49F7319: _FcConfigParse.lto_priv.0 (fcxml.c:3638)
==2726510==by 0x49FA2F5: UnknownInlinedFun (fcxml.c:2606)
==2726510==by 0x49FA2F5: FcEndElement (fcxml.c:3156)

In any case, I don't think libsl should call FcFini because we don't
know if the user is done with fontconfig or not and the FcFini
documentation states [0]:

| Frees all data structures allocated by previous calls to fontconfig
| functions. Fontconfig returns to an uninitialized state, requiring a new
| call to one of the FcInit functions before any other fontconfig function
| may be called.

The last line (requiring a new...before any other functions may be called)
makes me question if it's even okay that fontconfig functions are being
called without initializing the library.

ST calls FcInit during setup [1], dmenu/dwm doesn't. Maybe they should ?

I'm not really sure, the fontconfig documentation doesn't seem to say
anywhere (aside from that line in FcFini docs) weather initialization is
required or not.

[0]: 
https://www.freedesktop.org/software/fontconfig/fontconfig-devel/fcfini.html
[1]: https://git.suckless.org/st/file/x.c.html#l1144

- NRK

Re: [dev] [libsl][bug] Call FcFini on cleanup for projects calling FcIni

[NRK]

On Thu, Oct 27, 2022 at 01:19:28PM -0700, Anskrevy wrote:
> Any program using libsl, or calling FcIni (directly or indirectly), that
> does not call FcFini results in a small memory leak. dwm and dmenu are
> effected by this.

I do not see any call to FcInit in libsl, nor do I see any such call in
dmenu/dwm. Running dmenu master branch under leak-sanitizer doesn't show
any leaks related to fontconfig (v2.13.1) either.

How exactly did you detect this leak? And are you sure this is a problem
on libsl/dmenu/dwm side and not the library itself leaking things?

- NRK

Re: [dev] dwm 6.4 bug

[NRK]

On Wed, Oct 26, 2022 at 02:10:19PM +, Tom Schwindl wrote:
> However, a length check & truncation
> of the last char doesn't seem harmful at all. Thoughts?

I had bought up this issue in the past and the conclusion was that there
should just be a comment added [0] as users are treated as programmers.

[0]: https://lists.suckless.org/hackers/2208/18484.html

- NRK

Re: [dev] Some misc tools that could help others

[NRK]

On Wed, Sep 21, 2022 at 04:24:28PM +, Hadrien Lacour wrote:
> The other "interesting" one is genhtab, an alternative to gperf that is much
> simpler to use and produces smaller binaries for big tables (but slower, cf
> genhtab_bench) using a simple chained hashing table (with some tricks due to
> being built AOT) using fnv1a; I'll probably try with XXH3 soon, to see if the
> speed issue can be mitigated without too much binary bloating.

const uint32_t bkt =  hash & (ht.len - 1);

Due to mul being the last step in fnv1a, the entropy is stored in the
high bits, so you want to be masking the high bits and not the low ones.

Alternatively you can change the hash function to mix the high bits with
the low ones just before returning:

hash ^= hash >> 33; /* for the 64bit version. */

But I'd much rather just mask the high bits instead.

And for statically generated hash-tables (as well as in general) I tend
to prefer open-addressing rather than chaining. For probing I prefer
linear probe with robin-hood insertion[0] for statically generated
tables.

As for why: linear probing nicely exploits spatial locality[1] and
robin-hood can reduce the max probe size by alleviating clustering[2].
This leads to both faster worst-case lookups as well as less memory
usage.

For run-time tables where you don't know the inputs, double-hashing
might be a better approach[3]. But for statically generated one, I
wouldn't use double-hashing since you can easily change the hash
function until it's producing good results (e.g for fnv1a changing the
starting state or the multiplier, or both[4]).

Also one more trick that can reduce memory usage is to eliminate pointer
overhead and use an array of arrays, i.e using `char [][n]` instead of
`char *[]`. This isn't _guaranteed_ to reduce mem usage though, so
you'll have to do some calculation to figure it out, i.e:

/* approximate mem usage for `char *[]` */
for (sum = 0, i = 0; i < LEN(input); ++i)
sum += (strlen(input[i]) + 1) + sizeof (char *);
/* vs char[][max_input_strlen + 1] */
sum = LEN(input) * (max_input_strlen + 1);

Off the top of my head, these would be some of the major tricks I use
when building a statically generated hash-tables. And yeah, I prefer
building it on a case by case basis instead of using some pre-made
generator :)

[0]: https://programming.guide/robin-hood-hashing.html
[1]: https://en.wikipedia.org/wiki/Locality_of_reference
[2]: https://en.wikipedia.org/wiki/Primary_clustering
[3]: https://nullprogram.com/blog/2022/08/08/
[4]: 
https://github.com/jarun/nnn/blob/de3ad1b14618392753051959b2e7ac52f70252a1/src/icons-hash.c#L124-L125

- NRK

Re: [dev] [st] libXft-2.3.5 fixed the color emoji crash

[NRK]

On Mon, Sep 12, 2022 at 06:52:52PM -0400, Steve Ward wrote:
> https://gitlab.freedesktop.org/xorg/lib/libxft/-/blob/libXft-2.3.5/NEWS
> > Version 2.3.5
> > Add support for BGRA glyphs display and scaling

Seems to be working indeed. How does this impact existing suckless
tools?

ST never had any workarounds regarding this iirc (though the FAQ should
probably be updated). As for DWM/Dmenu - does it make sense to guard the
workaround with an preprocessor version check?

#if XFT_MAJOR < 2 || XFT_MINOR < 3 || XFT_REVISION < 5
/* workaround */
#endif

Just removing the workaround entirely might be an option as well with
the assumption that if someone is running updated dwm/dmenu they should
have an updated libXft as well.

But I suppose there are plently of people that build suckless software
from source but install libraries from distro package manager (which may
be outdated depending on the distro policy).

- NRK

Re: [dev] [libgrapheme] Some questions about libgrapheme

[NRK]

On Fri, Sep 02, 2022 at 02:08:03PM -0300, atrtar...@cock.li wrote:
> Quite inefficient really, but I guess it's fine since my usage would be
> only user input (left arrow)

If efficiency is not a concern, then you can easily use something like
this (just a quick prototype, didn't verify if it's correct or not):

/* returns an offset into `s` */
static size_t
prev_char_offset(const char *s, size_t slen, size_t off)
{
assert(s != NULL);
assert(slen > 0);
assert(off <= slen);

size_t ret = 0;
const char *const end = s + slen;
while (s < end) {
size_t n = grapheme_next_character_break_utf8(s, end - 
s);
if (ret + n >= off)
return ret;
ret += n;
s += n;
}
return 0; /* unreachable (?) */
}

If I was expecting a decent amount of non-ascii input, I would use the
bitvector approach described by Thomas Oltmann. 1bit per byte overhead
should be fine for most use-cases.

- NRK

Re: [dev] [tabbed] utf8 characters not displayed in tabs

[NRK]

On Tue, Aug 30, 2022 at 10:47:46PM +0200, Storkman wrote:
> but more generally,
> the "set of fonts covering as wide variety of code-points as possible"
> ...is just the set of all installed fonts, isn't it?

Not entirely. Let's say a system has 3 fonts installed: A, B and C. A
and B both *only* cover English characters and C covers Chinese ones.

In that case, our list would be [A, C]. B can be eliminated from the
fallback-list since it doesn't add anything new. (Or it could be [B, C]
with A eliminated).

We could of course add a reasonable upper-limit to this list, say
128/196 or something along those lines.

And just so everyone is on the same page: drw ALREADY maintains such a
list. I'm only proposing we change *how* we construct the list (assuming
it's possible).

This is roughly how things currently work:

0. at startup push the user specified fonts (in config.h) to the list
// list = [ userfont0, userfont1 ]
foreach code-point:
1. walk the list to find a font that can render the code-point.
   if any of the fonts in the list can render it, just use that.
2. if not, then run XftFontMatch() to see if we can find
   a match.
3. If XftFontMatch() finds a match then append the
   matched font to the list (so that step 1 can find it
   next time around).
   // list = [ userfont0, userfont1, matchedfont0, matchedfont1 
... ]

My idea is to simply remove step 2 and 3 from the loop and construct the
list at startup so we don't have to constantly keep calling
XftFontMatch() inside the loop for each unknown code-point.

> I'm a big fan of pre-calculating this list before compiling the program.

I was talking about doing it on program startup since I don't think you
should have to recompile the program every time you install a new font
for font fallback to work.

> If your question is simply "which code-points ARE NOT supported by ANY font",

Wasn't exactly what I was looking for but even this *could be* an
improvement over the current system if it can be done in reasonable
space, speed and code-size.

- NRK

Re: [dev] [tabbed] utf8 characters not displayed in tabs

[NRK]

On Tue, Aug 30, 2022 at 05:36:31PM +0200, Hiltjo Posthuma wrote:
> "
> The font fallback in dwm and dmenu is handled via libsl (i.e drw.c) and
> it's a huge mess [0].
> 
> The way it works is also very inefficient (it calls XftFontMatch() for
> every single "unknown" code-point). The `nomatches` cache is merely
> there to stop the bleeding and is not really a proper fix.
> "
> 
> This part specificly. The tone if very whiny.

I see; the intention there was to just describe/explain why I think
replicating drw is not a good idea. It wasn't meant to be whiny.

> It doesn't help complaining the code is a mess or improper without
> proposing a patch.

The "proper" way (IMO) would be to build up a list of fonts which would
be capable of representing as many code-points available in the system
*right at startup* - instead of checking each unknown code-point as we
go.

This way if the code-point cannot be found within the list; we'll know
right away that it's a missing glyph and there won't be any need to call
XftFontMatch for each "unknown" code-point.

The problem is, as I said, I'm not sure if it's even possible/feasible
with Xft/FontConfig as I'm not very familiar with those libraries. If
someone knows the answer, then feel free to speak up.

If it is possible and someone can point out which routines I should be
looking at then I can try to take a crack at it. In case that's not
possible, then there's probably not a whole lot that can be done about
the situation.

- NRK

Re: [dev] [tabbed] utf8 characters not displayed in tabs

[NRK]

On Tue, Aug 30, 2022 at 04:50:14PM +0200, Hiltjo Posthuma wrote:
> Then write a patch to improve it instead of whining about it.

The topic was font fallback; I adviced not to replicate drw, explained
my reasoning why, and then adviced to look into ST instead.

I don't see any whining.

- NRK

Re: [dev] [tabbed] utf8 characters not displayed in tabs

[NRK]

On Tue, Aug 30, 2022 at 11:42:33AM +0900, Pontus Stenetorp wrote:
> My intuition is that it is related to font loading and fall backs, so
> I am tempted to take a stab at it by comparing the font
> loading/handling between tabbed, dwm, st, and sent to see if I can
> spot any difference, as the latter three have no issues. If I am
> correct, it should not be an awfully difficult patch.

The font fallback in dwm and dmenu is handled via libsl (i.e drw.c) and
it's a huge mess [0].

The way it works is also very inefficient (it calls XftFontMatch() for
every single "unknown" code-point). The `nomatches` cache is merely
there to stop the bleeding and is not really a proper fix.

I wasn't very happy with the situation and had intended to rework the
system to be something more simple, sensible and efficient. But I'm not
sure if what I have planned is even possible with Xft/FontConfig or not.
And quickly grepping through the function list wasn't that helpful. I'll
probably have to allocate more time to read the docs properly.

But in any case I absolutely do NOT recommend trying to replicate drw's
approach. Not sure what ST is doing, so that might be worth taking a
look into instead.

[0]: https://git.suckless.org/libsl/file/drw.c.html#l251

- NRK

Re: [dev] [st] incorrect italic, bold, bold italic versions

[NRK]

On Fri, Aug 05, 2022 at 11:55:39PM +0300, Plato Kiorpelidis wrote:
> Sometimes FcFontMatch in xloadfont does not match the font the user expects.
> This happens because fontconfig attempts to find a matching font using
> heuristics. To deal with this I wrote a patch[1] that allows the user to
> explicitly state the prefered italic, bold and bold italic fonts.

I think the bigger issue here is the fact that ST doesn't allow user to
specify the fallback fonts in config.h. DWM and Dmenu on the other hand
do.

The font2 patch[0] on the wiki kinda enables fallback fonts. But I
didn't like the fact that it adds a separate array `font2`. IMO you
should be able to do this, similar to dmenu/dwm:

static const char *fonts[] = {
"font0",
"font1",
"font2",
};

And ST would/should prioritize `font0` and then fallback to
`font1 -> font2 -> ..` etc before attempting it's own heuristics.

[0]: https://st.suckless.org/patches/font2/

- NRK

Re: [dev] suckless indentation with vim

[NRK]

On Tue, Jul 05, 2022 at 06:43:53PM -0500, Robert Winkler wrote:
> Probably a newly written 'vimish' editor is needed.

I see that "vis" has already been mentioned. There's also neatvi, and
kakoune.

But if your problem with neovim is that it isn't compatible with the vim
ecosystem, then neatvi and kakoune; or any other "newly written" vi
clone will suffer from the same problem.

neatvi: https://github.com/aligrudi/neatvi
kakoune: https://github.com/mawww/kakoune

- NRK

Re: [dev] suckless indentation with vim

[NRK]

On Tue, Jul 05, 2022 at 08:54:20AM +0200, David Demelier wrote:
> I'm not sure if it's really easy to implement a smart alignment.

Do you mean implementing it in vimscript/externally or internally?

Because I don't think implementing it internally should be difficult,
given that it already can do alignment, it just continues to use tabs as
long as possible rather than using it as much as the previous line.

Though I could be wrong, as I've never taken a look at the vim codebase.

> Of course, always better to view whitespaces when dealing with that
> mix.

Even suckless indentation aside, it's useful when you deal with multiple
codebases which use different styles.

- NRK

Re: [dev] suckless indentation with vim

[NRK]

On Sat, Jul 02, 2022 at 07:29:03PM +0200, Rene Kita wrote:
> It does. Just press Tab to indent and press Space to align. You don't
> need a plugin. ;)

One of the main reason I use vim is because it makes it VERY easy to
edit/refactor code. A lot of things which are very cumbersome on other
point-and-click style editors can be done in 1~3 just keystrokes.

It can do auto-indentation with `=`, which makes moving a block of code
from one place to another very easy. But in cases where spaces need to
used for alignment, it can mess it up and end up using tabs instead.

The following (indentation related) settings is what I've got on my
vimrc:

set cinoptions+=t0 " Don't outdent function return types
set cinoptions+=:0 " No extra indentation for case labels
set cinoptions+=(0 " Lineup function args

which pretty much does everything I need, except using spaces for
alignment. I see no reason why that needs to be manual when everything
else vim can do automatially.

- NRK

Re: [dev] [dwm] Multihead Issues Autostart

[NRK]

On Sun, May 01, 2022 at 06:57:33PM +0200, Yan Doroshenko wrote:
> (stupid qustion alert)
> 
> But how can I try, whether my xrandr in autostart works, if I run version
> with no autostart patch?
> 

Hi Yan,

You don't need a patch to execute something at startup. If you're using
startx directly, then look into `xinitrc` (man 1 xinit has some
examples). And if you're using some login/display manager then look into
it's documentation instead.

- NRK

Re: [dev] Regarding dwm and st logo being removed

[NRK]

On Thu, Apr 28, 2022 at 01:06:05PM +0200, Laslo Hunhold wrote:
>   #main img[src$=svg] {
>   filter: invert(1);
>   }
> 
> All  within #main that are svg's are inverted in dark mode.
> Granted it makes use of a filter, which is not supported everywhere,
> but given prefers-color-scheme is also only supported by modern
> browsers, this should not be an issue.
> 
> I hope everyone's okay with this.

The change (visually) looks fine to me and I'm happy to see the logos
back again =)

And while we're on the topic of dark mode; the current theme uses a #000
black for it's background. Which looks great my phone with AMOLED
display, but not so great on my desktop with an LCD panel where
something like #171717 looks much better.

I'm not asking to change it though, since that'll just swap the problem.
Just putting the info out there as feedback.

- NRK

Re: [dev] Regarding dwm and st logo being removed

[NRK]

On Thu, Apr 28, 2022 at 09:29:43AM +0200, Hiltjo Posthuma wrote:
> Recently dark mode CSS support was added to the site.
> 
> It was reported on IRC the logo's were not visible with them.

Ah, that makes sense. But wouldn't it make sense to remove the logos
from *all* are projects then?

Also since the logos are just svgs, I *think* it should be possible to
override the color of the "fill" dynmaically via css (?) If so, then I
think that's probably a better course of action :)

- NRK

Re: [dev] Bye

[NRK]

On Sat, Apr 23, 2022 at 12:06:16PM +0200, Olivier Regnier wrote:
> 
> 

NOOOoo, don't leave! :(

- NRK

Re: [dev] [st] UTF-8 not working

[NRK]

On Wed, Apr 20, 2022 at 08:46:46AM -0500, Robert Winkler wrote:
> I had to remove color emojis due to crashes of my email client aerc in
> st, as advised in this mailing list.

I think it's better to reject color emojies in ST rather than removing
them system-wide. The FAQ already mentions how to do it.

diff --git a/x.c b/x.c
index f70e3fb..6e94f76 100644
--- a/x.c
+++ b/x.c
@@ -1015,6 +1015,7 @@ xloadfonts(const char *fontstr, double fontsize)
}
defaultfontsize = usedfontsize;
}
+   FcPatternAddBool(pattern, FC_COLOR, FcFalse);

if (xloadfont(, pattern))
die("can't open font %s\n", fontstr);

And on a sidenote, I support not adding such workaround in mainline ST.
It's an XFT issue which should've been fixed long ago. A merge request
fixing this exists for 2 years now [0].

The thread suggests that the patch isn't perfect, but it's certainly
better than crashing the application as it does right now.

[0]: https://gitlab.freedesktop.org/xorg/lib/libxft/-/merge_requests/1

- NRK

Re: [dev] Some direction with my project

[NRK]

Hi Dorian,

Took a quick glance into the source and a couple things which stood out,
that haven't been pointed out already:

#define BUFFER_SIZE MAX_TAGS * MAX_TAG_SIZE

Macros like this pretty much always should be parenthesized. It costs
nothing and can save you from getting into potential bugs. See
http://c-faq.com/cpp/safemacros.html for a more detailed explanation.

else if (strlen(temp) > 0) {
  strcat(tempForWrite, temp);

I see lots of `strcat` calls going on, and maybe you *are* checking for
overflow somewhere out there, but it's not immediately obvious where.

I would suggest using `strlcat` instead. I would also suggest being very
careful with the str* family of functions, they often contain various
bear traps.

  if (errno == ENOTSUP) {
  fprintf(stderr, "Extended attributes are not available on your 
filesystem.\n");
  return -1;
} else if (errno == ENOENT) {
  fprintf(stderr, "File does not exist.\n");
  return -1;
}

Use strerror().
Also a lot of these messages are being used in multiple location. I'd
just use a macro for them.

#define ERRMSG_X "error x"
...
fprintf(stderr, "%s\n", ERRMSG_X);

...Or an array of them and index into it using enum.

Lastly, it's already been pointed out, but it's very cringe having to go
into a `src` dir just to find a single source file in there.

And related to that, given it's a single source file and none of the
functions are being called externally, you should declare (as well as
define) all the functions as `static`.

- NRK

Re: [dev] dwm oddity

[NRK]

On Sun, Apr 03, 2022 at 03:10:48PM -0700, Greg Minshall wrote:
> likely, the heel of my palm is making some (light?) contact with the
> touch pad.

Hi Greg,

You could probably try the "focusonclick" patch[0] to confirm your
suspicion. I personally use it because I find that feature annoying.

But on monocle layout, I don't think it should be possible for the mouse
cursor to change focus. So your problem is probably related to some
patch you're using. Try using vanilla dwm without any patches and see if
you still run into the issue.

[0]: https://dwm.suckless.org/patches/focusonclick/

- NRK

Re: [dev] [dwm] hardcoded dmenucmd && dmenumon

[NRK]

On Wed, Feb 16, 2022 at 05:39:14PM +0100, Hiltjo Posthuma wrote:
> whats the solution/patch?

If there is a "standard" (or at least conventional) way of communicating
the active monitor between wm and other X clients then it's probably
best to follow that.

Assuming there isn't, one alternative could be just using env vars. dwm
would set an env var, say $DWM_CURRENT_MONITOR inside spawn() and
`dmenu_run` can be adjusted to utilize that `-m "$DWM_CURRENT_MONITOR"`
or fallback to some default if the env var doesn't exist.

This would remove the need to special case dmenucmd and would allow
other scripts/programs spawned via dwm to utilize this env var as well.

On Wed, Feb 16, 2022 at 05:39:14PM +0100, Hiltjo Posthuma wrote:
> Whats the issue

Wouldn't consider it an "issue", but rather a place for potential
improvement.

- NRK

Re: [dev] sfeed: RSS/Atom parser and reader

[NRK]

Hi,

I've been using sfeed with the sfeed_curses frontend for a while now and
am generally pretty happy with it.

On Mon, Feb 14, 2022 at 03:15:40PM +1100, syg wrote:
> I made a tiny script on top of a terminal-based menu selector a friend
> and I have been developing for the last few years[1] and it works
> great.

> [1]: https://pedantic.software/projects/choice.html

I tried out `choice` several months ago. Really liked it's key-value
feature and patched my demnu to do something similar[0]. However not
having a case insensitive search killed it for me.

[0]: https://tools.suckless.org/dmenu/patches/separator

- NRK

Re: [dev] Is there a text editor following the UNIX philosophy?

[NRK]

Hi,

AFAIK, neovim is trying to offload some of it's stuff
(autocomplete/linting) to a language server via LSP. They're also
offloading syntax highlighting to tree-sitter.

But I highly doubt that this is what you're looking for when you're
talking about a "unix-like" editor. The dependancy on tree-sitter is
specficially what made me uninstall neovim and switch over to vanilla
vim.

- NRK

Re: [dev] requirements of build systems

[NRK]

On Tue, Feb 01, 2022 at 09:29:55PM +0900, Pontus Stenetorp wrote:
> Speaking for myself, I certainly have experienced issues with
> inaccurate timestamps on NFS for compute clusters where its use is
> very common. Not saying this as a supporter of NFS and the likes, just
> as evidence that it does occur in practice.

That's good to know, I wasn't thinking about NFS at all.

Also just to be clear, my question wasn't rhetorical. Since I've never
experienced issue with make, I was genuinely curious if this issue
occurs in practice or not.

- NRK

Re: [dev] requirements of build systems

[NRK]

On Mon, Jan 31, 2022 at 12:10:27AM +0200, Petros Pateros wrote:
> However, it was pointed out to me that relying on mtime can give wrong 
> results,
> for example:
> (a) if the clock is set backwards or in case of insufficient granularity in 
> mtime
> then a file that gets modified might have the same mtime
> (b) an mmap(2)-ed file can get modified but its mtime might not get updated
> soon enough

How likely is it for these situations to occur in practice? If these are
practical problems, then it makes sense to solve them. Otherwise I think
it's best not to waste resource solving theoretical problems.

- NRK

Re: [dev] conference video mirror

[NRK]

On Sun, Jan 16, 2022 at 08:57:58AM -0500, Greg Reagle wrote:
> If it's slow, download then watch.

Downloading was slow as well, wget estimates 30hours to download.

> Also, I just tried 
> https://dl.suckless.org/slcon/2019/slcon-2019-00-laslo_hunhold-openbsd_supremacy.webm
>  and it was fine.  It buffered much quicker than I watched it.

I *did* try out a VPN before sending the mail, assuming it could've been
related to my ISP routing or something of that sort but I didn't see any
improvement.

Anyhow, just tried it out again today and it seems to be working fine
now (without needing to use any VPN or anything).

On Sun, Jan 16, 2022 at 10:05:55AM -0500, Jeffrey Picard wrote:
> I’d love to help get all of these videos migrated if you’re interested in 
> that.

That'd be nice, extra mirrors can't hurt. Feel free to email me the
links if/when you get around doing so.

- NRK

Re: [dev] Special target ".POSIX" in Makefiles

[NRK]

On Fri, Dec 31, 2021 at 11:29:11PM +0100, Mattias Andrée wrote:
> I just started implementing a linter[0]. Even though I just
> started it today, I think that's enough for this year.
> 
> Happy New Year!
> Mattias Andrée
> 
> [0] https://github.com/maandree/makelint/

Thank you very much, I'll keep an eye on this.

Also as for the name, while looking it up I noticed that there's another
project by the exact same name [0]. Funny enough, this project's goal
seems to be complete opposite of ours, it advices usage of non-posix
implicit variables like $(RM) in it's README.

Might be a good idea to use a different name to avoid potential
confusion. Something like `makecheck` should be fine, I cannot find any
other project with that name.

[0]: https://github.com/christianhujer/makelint

- NRK

Re: [dev] Special target ".POSIX" in Makefiles

[NRK]

On Fri, Dec 31, 2021 at 12:49:46PM +0600, NRK wrote:
> What would be a posix replacement for `?=` ? I assume something like:
> 
>   VAR = $$(if test -n "$$VAR"; then printf "%s" "$$VAR"; else printf 
> "fallback"; fi)
> 

Now that I think about it, posix shell has parameter expansion that
could be used here for a more compact assignment:

VAR = $${VAR:-fallback}

should also do the trick. I guess it could also be double quoted to
protect against word splitting as well. But I don't think that'd be a
good idea for things like CFLAGS where word splitting is desired.

- NRK

Re: [dev] Special target ".POSIX" in Makefiles

[NRK]

On Thu, Dec 30, 2021 at 09:17:32PM +0100, Mattias Andrée wrote:
> I've actually being thinking of writing a makefile linter.
> How interested would people be in such a tool?
> 
> The reason to have a linter separate from a make utility itself
> is that it would not have to reject non-standard features that
> you don't want to implement in make. And I also think it would for
> cleaner implementation of both projects. Additionally, I would
> suspect that a lot of people would just stay with GNU make because
> it's in every distro, so having it as a separate project would
> probably give it wider adoption.

I'd definitely be interested in such a tool. Weather it be in form of a
make implementation or linter doesn't matter a whole lot to me as long
as the end goal of having a tool to help write portable makefile is
achieved.

On Thu, Dec 30, 2021 at 11:07:35PM +0100, Laslo Hunhold wrote:
>$ snake -l
>Makefile:1:1: warning: Missing ".POSIX" target.
>config.mk:2:4: warning: "?=" is a GNU-extension. 
>Makefile:20:34: warning: A prerequisite must not contain a macro.
>$

Hmm, I was under the impression that `?=` was accepted into POSIX. But I
cannot find any mention of it in the posix manpage (man 1p make) so I
guess I was wrong.

What would be a posix replacement for `?=` ? I assume something like:

VAR = $$(if test -n "$$VAR"; then printf "%s" "$$VAR"; else printf 
"fallback"; fi)

- NRK

Re: [dev] [dwm] default window attaching behaviour

[NRK]

On Wed, Dec 01, 2021 at 12:26:22AM +1000, dther wrote:
> and only launch new "temporary" terminals when I need to run and see
> the output of a command. If I need an TUI volume mixer or something,
> I'd launch it as a tmux window or in floating mode to avoid disturbing
> my layout.

Hi,

You should consider using a "scratchpad" for this purpose. There's a
couple scratchpad patches it in the wiki.

I personally didn't like them though, I don't remember why exactly but
it had something to do with messing up my tag-based workflow.

- NRK

Re: [dev] [st] wide characters getting cropped

[NRK]

On Thu, Nov 11, 2021 at 05:31:15PM +0100, Страхиња Радић wrote:
> (for example, if a simple "cat /some/file" for a multi-line text file
> has a delay anywhere from 500 ms to a second or two between the output
> of individual lines, when not dependant on factors such as reading
> from a network of a faulty hard disk; that would just be annoying, but
> still usable).

You're correct, cating some file is not something that needs critical
speed. But that's not what I'm talking about when I say "latency".

I'm reffering specifically to "input latency" or "end-to-end latency",
which is the delay between a physical input (in this case key-press on
the keyboard) and it's output (in this case the key-press being
rendered).

- NRK

Re: [dev] [st] wide characters getting cropped

[NRK]

On Tue, Nov 09, 2021 at 02:00:57PM +0100, Laslo Hunhold wrote:
> I'm always wondering: What do you suggest to improve the
> latency-situation?

If I knew the answer to that, then I would've ditched XTerm and patched
ST already. Unfortunately I know next to nothing when it comes to the
inner workings of a terminal.


On Tue, Nov 09, 2021 at 10:09:48PM +0100, Страхиња Радић wrote:
> I'm wondering what's the use case for such critical need for low latency?

I wouldn't say it's "critical need". And if we judge from that pov then
one could ask, "What's the critical need for a dynamic window manger or
minimal softwares in general?".

XTerm has many (visible) problems. Maybe I've misconfiuged it, but I
cannot get it to fallback to other fonts reliably, and thus some glyphs
don't render. It also chokes badly when it tries to render some unicode
glyphs for the first time.

I have neither of those problems on ST. But those situations are far
less common for me compared to situation where I'm typing into the
terminal (which is always). So if I can get a better experience out of
the most common workflow out of a certain software, then it's going be
the one I will end up using.

Also just to clarify, I wouldn't say ST has "latency issues", that
implies the situation is _bad_. As I've said, it's the 2nd most
responsive terminal I've tried and _MILES_ better than these "gpu
accelerated" terminals. It's also the only other terminal that I still
have installed in my system.

- NRK

Re: [dev] [st] wide characters getting cropped

[NRK]

On Wed, Oct 27, 2021 at 09:38:41AM +0200, Hiltjo Posthuma wrote:
> Its a longstanding myth st has input latency issues.
> The common quoted benchmark is wrong.

If we're thinking about the same benchmark then it's also outdated.
But regardless I didn't base my decision on that. Sometimes ago (9-10
months) I was testing out a whole bunch of different terminals, some of
the worst offenders when it comes to latency was Alacritty and Termite
IIRC.

ST, in my expereince, has been the 2nd most responsive terminal and
quite close to XTerm. But still not as responsive and thus overtime I
have switched over to it.

It would be interesting to see someone doing a proper benchmark with all
latest terminal versions, since I don't have any data to back up what I
am saying :) So take it as you may.

- NRK

Re: [dev] [st] wide characters getting cropped

[NRK]

On Tue, Oct 26, 2021 at 07:51:52PM +, Ian Liu Rodrigues wrote:
> I've noticed that in some situations wide characters are being cropped
> on my terminal. The following script, which uses a wide character from
> the "Nerd Font Symbol"[1], shows a test case:
> 
> 
> echo -e '\e[31m \e[0m c'
> echo -e '\e[31m  \e[0mc'
> 

Hi Liu,

I remember having the same problem in ST, however it works fine now.
Looking at my git log I haven't applied any patches for it and even the
upstream branch works fine for me.

This might be related to terminfo (5). I won't be delving any deeper
into this as I've moved over to XTerm long ago due to input latency
reasons. You might want to check FAQ provided in the ST repo.

P.S echo is non-portable. Use printf.
https://wiki.bash-hackers.org/commands/builtin/echo#portability_considerations

- NRK

Re: [dev] Whether a css selector applies to given html surf code

[NRK]

On Mon, Oct 25, 2021 at 08:36:31PM +0200, Sagar Acharya wrote:
> I'm making this software called kamitkami. It's a python script which takes 2 
> inputs foo.html and bar.css and outputs a css file named bar_foo.css which 
> contains only the css which applies to the particular html page . This will 
> make css extremely minimal and page loading faster.

Wouldn't it make more sense to just inline the css into the html
instead? I think Dylan was doing that for K1SS.
https://archive.md/dFqxv

- NRK

Re: [dev] Wayland compositors

[NRK]

Hi,

Adding to what Laslo has already said:

I think it's laughable that that wayland devolopers claim wayland to be
a replacement for X while actively ignoring many use-case and forcing
their "perfect frame" philosophy onto the users.

It is _OK_ if the devs prioritize having perfect frame and want to work
on it more, I think we all want to work on features that are more
valueable to us. But to actively discard other use-cases is _NOT_ ok.

I for one have no regards to "perfect frame" and value a crisp low
latency desktop without running any compositor. This is not possible in
wayland but perfectly viable in X. Why should I have wayland dev's
use-cases shoved down my throat? If I wanted to be pushed around by devs
I'd use proprietary software instead.

And it's also very funny that the devs (one of them atleast) think that
instead of making wayland work for these users calling them
"anti-vaxxers and flat-earters" is the way to go :)

https://drewdevault.com/2021/02/02/Anti-Wayland-horseshit.html

- NRK