Re: [dev] [surf][stylesheet][startpage] New ownership of Startpage not reflected in description
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
> 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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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?
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
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
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
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
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
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
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
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
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.
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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