[dev] [st][bug] Font fallback fails on some systems

I've recently upgraded my system and noticed that many Unicode characters are no longer displayed in st, although other applications were unaffected. After some investigation, I found that it's a font fallback failure: the font returned by FcFontSetMatch lacked the character requested via the

Re: [dev] alternatives to C: Ada, Rust, Pascal

On 2024-06-22 03:58:46 +, NRK wrote: > Sized strings > - > > typedef struct { > uint8_t *s; // or you can use `(unsigned) char *` > ptrdiff_t len; // or you can use `size_t`, see explanation > below > } Str; > > * Cheap access to the

Re: [dev] alternatives to C: Ada, Rust, Pascal

Hello Friend, On 06/21/24 10:45AM, Greg Reagle wrote: > I am not a fan of C because of problems like buffer overflows; weakly typed > arrays; lack of (built-in) range checking for enumerations, numeric types, > arrays; lack of overflow checking; string handling being too complex. > Basically

Re: [dev] [dwm][st] why use ints over bools?

On Fri, 21 Jun 2024 23:29:29 +0200 Storkman wrote: > On Fri, Jun 21, 2024 at 10:12:15PM +0200, Mattias Andrée wrote: > > On Fri, 21 Jun 2024 21:14:19 +0200 > > Markus Wichmann wrote: > > > > > Am Thu, Jun 20, 2024 at 11:53:45PM +0200 schrieb Страхиња Радић: > > > > Given that, why

Re: [dev] alternatives to C: Ada, Rust, Pascal

NRK wrote: > Below are two of the most impactful changes. I was going to elaborate on > these but it was getting *really* long very quickly so I've kept it to a > brief overview followed by a real-world project that demonstrates these > techniques. I completely agree. Since trying sized

Re: [dev] alternatives to C: Ada, Rust, Pascal

On Fri, Jun 21, 2024 at 10:45:01AM -0400, Greg Reagle wrote: > Basically what you might call "safety and ease issues." I won't comment on the other languages mentioned because my view on nearly all of them is negative. But most of my "safety and ease of use" with C I've been able to solve by just

Re: [dev] [dwm][st] why use ints over bools?

În 22 iunie 2024 00:10:52 EEST, "Страхиња Радић" a scris: >Дана 24/06/21 09:14PM, Markus Wichmann написа: >> Isn't it all about familiarity in the end? Or can you articulate what >> parts of C11 and C23 you find objectionable? > >Just a few examples: > >- C11: bounds checking interfaces (now

Re: [dev] alternatives to C: Ada, Rust, Pascal

On Fri, Jun 21, 2024 at 06:48:53PM +0200, Страхиња Радић wrote: > Дана 24/06/21 10:45AM, Greg Reagle написа: > > Rust also has some good safety and ease-of-use features. It is very > > big and complex with a lot of features (compared to C). > > Previous thread, now necroed: > >

Re: [dev] [dwm][st] why use ints over bools?

On Fri, Jun 21, 2024 at 10:12:15PM +0200, Mattias Andrée wrote: > On Fri, 21 Jun 2024 21:14:19 +0200 > Markus Wichmann wrote: > > > Am Thu, Jun 20, 2024 at 11:53:45PM +0200 schrieb Страхиња Радић: > > > Given that, why complicate code by introducing a separate, superfluous, > > > type? > > >

Re: [dev] [dwm][st] why use ints over bools?

Дана 24/06/21 09:14PM, Markus Wichmann написа: > Let me offer a counterpoint: Expressiveness. If I make a function return > a bool, then everyone from the world's worst junior dev to Ken Thompson > himself will be able to see at the very first glance that the function > is returning a boolean

Re: [dev] [dwm][st] why use ints over bools?

On Fri, 21 Jun 2024 21:14:19 +0200 Markus Wichmann wrote: > Am Thu, Jun 20, 2024 at 11:53:45PM +0200 schrieb Страхиња Радић: > > Given that, why complicate code by introducing a separate, superfluous, > > type? > > Let me offer a counterpoint: Expressiveness. If I make a function return > a

Re: [dev] [dwm][st] why use ints over bools?

Am Thu, Jun 20, 2024 at 11:53:45PM +0200 schrieb Страхиња Радић: > Given that, why complicate code by introducing a separate, superfluous, > type? Let me offer a counterpoint: Expressiveness. If I make a function return a bool, then everyone from the world's worst junior dev to Ken Thompson

Re: [dev] alternatives to C: Ada, Rust, Pascal

Дана 24/06/21 10:45AM, Greg Reagle написа: > Rust also has some good safety and ease-of-use features. It is very > big and complex with a lot of features (compared to C). Previous thread, now necroed: https://lists.suckless.org/dev/2104/34265.html * * * Rust sucks. It was made by Big Tech

[dev] alternatives to C: Ada, Rust, Pascal

Warm greetings to my fellow programmers and lovers of elegant simplicity. I wrote the sbase cal program in Pascal for fun, learning, experimentation. I have also written it in Rust and Ada, for the same reasons. I recently started re-learning Pascal (which I learned in high school) using

Re: [dev] [dwm][st] why use ints over bools?

Дана 24/06/20 10:24PM, sewn написа: > Sure, but why? It is part of the suckless coding style. Since st is a suckless project, it follows the suckless coding style. * * * I can't speak for those who wrote the suckless coding standard, but as a bystander, I can give this observation. If the

Re: [dev] [dwm][st] why use ints over bools?

On 2024-06-15 22:06, Страхиња Радић wrote: Дана 24/06/15 11:54AM, Zac написа: I'm curious why you use ints though. Because bools are 31 bits smaller than ints, which is 31 bits of memory saved. Not that 31 bits is very much, but still... https://suckless.org/coding_style/ Tests and

Re: [dev] [dwm] autoraise floating windows when gaining focus

On 2024-06-18 13:52 Anthony wrote: > On 6/18/24 8:25 AM, Κρακ Άουτ wrote: >> Hello to all, > > Hi. > >> I'd like to autoraise floating windows when gaining focus. The >> current behaviour is, windows gets focus on mouse pointer hover, but >> needs modkey press + left button mouse click to

[dev] [dwm] autoraise floating windows when gaining focus

Hello to all, I'd like to autoraise floating windows when gaining focus. The current behaviour is, windows gets focus on mouse pointer hover, but needs modkey press + left button mouse click to raise. I searched but did not locate any such patch. Is there perhaps, or could you give me any

Re: [dev] [dwm][st] why use ints over bools?

Am Sat, Jun 15, 2024 at 06:10:50PM +0200 schrieb Vincent Lefevre: > IMHO, this has been poorly designed. There should have been a macro > taking a parameter N (an integer constant expression), where the > type would have been valid for any N up to the maximum width (thus > at least 64). For

Re: [dev] [dwm][st] why use ints over bools?

> There should have been a macro taking a parameter N (an integer > constant expression), where the type would have been valid for any N > up to the maximum width (thus at least 64). For portability, the > existence of the macro could have also been tested with #ifdef, > allowing a fallback. I

Re: [dev] [dwm][st] why use ints over bools?

On Sat, 15 Jun 2024 16:16:14 +0200 Mattias Andrée wrote: > You will save between 0 and 3 bytes on common platforms, > and those 3− bytes will probably be allocated and wasted anyway. > Is it worth it? > > It's absolutely better than _Bool, but I don't think there > is any point in using char

Re: [dev] [dwm][st] why use ints over bools?

Дана 24/06/15 11:54AM, Zac написа: > I'm curious why you use ints though. Because bools are 31 bits smaller than > ints, which is 31 bits of memory saved. Not that 31 bits is very much, but >still... https://suckless.org/coding_style/ > Tests and Boolean Values > > * Do not use C99 bool types

Re: [dev] [dwm][st] why use ints over bools?

On 2024-06-15 16:24:38 +0200, Mattias Andrée wrote: > No, you should use [u]int_least1_t, except that probably doesn't > exist, So, you must not use it. :) On the opposite, int_least8_t is a *required* type in ISO C99+. That's why I've proposed it. > I think C actually should add some what to

Re: [dev] [dwm][st] why use ints over bools?

No, you should use [u]int_least1_t, except that probably doesn't exist, so char is best as it is per definition the most narrow type, and if the signness is important you can specify it. I think C actually should add some what to specify [u]int_{least,fast}N_t for arbitrary N. It could be simple

Re: [dev] [dwm][st] why use ints over bools?

You will save between 0 and 3 bytes on common platforms, and those 3− bytes will probably be allocated and wasted anyway. Is it worth it? It's absolutely better than _Bool, but I don't think there is any point in using char over int. All common operations (this may exclude division and modulo)

Re: [dev] [dwm][st] why use ints over bools?

On 2024-06-15 17:05:27 +0300, stefan1 wrote: > What about using char's then? char may be signed or unsigned. I would suggest unsigned char or signed char, or better, (u)int_least8_t. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

Re: [dev] [dwm][st] why use ints over bools?

What about using char's then? În 15 iunie 2024 15:36:16 EEST, "Mattias Andrée" a scris: >I have some general issues with _Bool: > >Arithmetic or bitwise operations on _Bool is subject to type promotion >making them rather pointless. > >With also be a problem if they were not, as you than

Re: [dev] [dwm][st] why use ints over bools?

I have some general issues with _Bool: Arithmetic or bitwise operations on _Bool is subject to type promotion making them rather pointless. With also be a problem if they were not, as you than couldn't sum of _Bool's to find how many were set (commonly this we be to detect if more than 1 was

Re: [dev] [dwm][st] why use ints over bools?

On Sat 15 Jun 2024, Zac wrote: > > In a number of spots in dwm and st I've seen the use of integers as booleans. > e.g. > - dwm.c line 95, 140, 1870 > - drw.c line 252 > - st.c line 44, 48 > > That's not an extensive list; just some examples. > > I'm curious why you use ints though. Because

[dev] [dwm][st] why use ints over bools?

In a number of spots in dwm and st I've seen the use of integers as booleans. e.g. - dwm.c line 95, 140, 1870 - drw.c line 252 - st.c line 44, 48 That's not an extensive list; just some examples. I'm curious why you use ints though. Because bools are 31 bits smaller than ints, which is 31 bits

Re: [dev] promoting suckless code on RosettaCode.org, tips for Lua

Greg, thanks. i've looked at Lua, but not much. but, i do very much like Javascript (in spite of the name) + typescript (in spite of the lineage). if you know those two, i'd find a two cents/sentence thumbs up/down interesting. cheers, Greg

[dev] promoting suckless code on RosettaCode.org, tips for Lua

I like to demonstrate suckless-style code (by which I mean simpler, fewer lines, more elegant) on RosettaCode.org. I have found overly elaborate and complex code that I have either replaced or supplemented with a simpler implementation. I encourage the rest of you to take a look and see what

Re: [dev][Quark] Big problem

Hi Fossy Dnmx, I'm re-opening this thread & I'm Hoping your health has returned. I want to say "cd ~; httpd" & then see everything in ~ from my Web Browser on port 8080. This is hard & I can't figure out all of these http servers recommended from suckless.org. "permission denied becuase of

[dev] slock: running svkbd at same time

Hi suckless community, I was hoping for pointers on how to get svkbd to overlay on top of slock so you can type a password in without a physical keyboard present. This is to make slock work with a phone running sxmo.

Re: [dev] piscou?

Дана 24/05/04 12:48PM, Hiltjo Posthuma написа: > Have you reported this issue to the author of piscou? No. There is actually a number of issues with the program itself (for example: under the #ifdef DEBUG it calls both dunstify and notify-send - it loops over the list). This is more about its

Re: [dev] piscou?

On Sat, May 04, 2024 at 12:40:21PM +0200, Страхиња Радић wrote: > While browsing through the commits to /sites, I noticed a program > piscou[1]. Just looking at its Makefile, it seems to include dubious > code such as: > > clang: CC=clang > clang: CFLAGS += -Weverything

[dev] piscou?

While browsing through the commits to /sites, I noticed a program piscou[1]. Just looking at its Makefile, it seems to include dubious code such as: clang: CC=clang clang: CFLAGS += -Weverything -Wno-unsafe-buffer-usage clang: clean release and piscou: $(src) $(headers) Makefile

Re: [dev] less keys for w3m

Greg Reagle wrote: > This took me a long time to do. I made any key that has a function in > less that is also available in w3m have the same key in w3m (2nd > paragraph), with a few exceptions, that are in my 1st paragraph. I am > posting this here for feedback, suggestions, improvements,

[dev] less keys for w3m

This took me a long time to do. I made any key that has a function in less that is also available in w3m have the same key in w3m (2nd paragraph), with a few exceptions, that are in my 1st paragraph. I am posting this here for feedback, suggestions, improvements, etc. And in case anyone

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

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

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:

Re: [dev][ubase] passwd runtime error on musl

Am Thu, Mar 21, 2024 at 06:01:25PM -0300 schrieb Brian Mayer: > Hello. > > I compiled ubase using GCC and musl, but using passwd gives me an error > message: > > $ passwd root > passwd: getpass: No such device or address > > Any ideas? > > Thanks > Looking at the getpass() source, it looks like

[dev][ubase] passwd runtime error on musl

Hello. I compiled ubase using GCC and musl, but using passwd gives me an error message: $ passwd root passwd: getpass: No such device or address Any ideas? Thanks

Re: [dev] [ubase] compile using musl

> What version of musl are you using? Hi Eric, I'm using version 1.2.5 of musl. My issue was not using -D_GNU_SOURCE in the CFLAGS, as Mattias suggested. Thanks

Re: [dev] [ubase] compile using musl

On Sat, Mar 16, 2024, at 4:52 AM, Eric Pruitt wrote: > On Fri, Mar 15, 2024 at 04:22:19PM -0300, Brian Mayer wrote: >> My guess is that glibc provides that function by musl doesn't. So as >> my system is using musl that function is not found. Can I get some >> help? > > The splice(2) call is

Re: [dev] [ubase] compile using musl

On Fri, Mar 15, 2024 at 04:22:19PM -0300, Brian Mayer wrote: > My guess is that glibc provides that function by musl doesn't. So as > my system is using musl that function is not found. Can I get some > help? The splice(2) call is provided by musl: src/linux/splice.c:ssize_t splice(int

Re: [dev] [ubase] compile using musl

Hello. > Add -D_GNU_SOURCE Thanks! It worked beautifully, the hard part was how to properly add this option to buildroot.

[dev] [svkbd] stuck spacebar bug

i think i found a bug in svkbd. When you hold the space button until it repeatedly puts out spaces and then move the pointer to the shift key (still pressing left mouse button) it puts out spaces forever. This bug occurs on every layout with modifier key and space next to each other. The

Re: [dev] [ubase] compile using musl

On Fri, 15 Mar 2024 16:22:19 -0300 Brian Mayer wrote: > Hi, I'm Brian, I'm trying to compile ubase using musl as libc on > buildroot. I use a Pinebook Pro, so aarch64 is my arch. > > By just running make I get this error: > >

[dev] [ubase] compile using musl

Hi, I'm Brian, I'm trying to compile ubase using musl as libc on buildroot. I use a Pinebook Pro, so aarch64 is my arch. By just running make I get this error: /home/blmayer/git/distro/buildroot/output/host/bin/aarch64-buildroot-linux-musl-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE

Re: [dev] [sbase] New branch for sbase+ubase

On 2024-03-14 11:49, Roberto E. Vargas Caballero wrote: The idea is that everything is portable. Let's take the example of ps. We can extract the non portable bits of ps into the libsys library (or whatever name we like), so the code in posix/ is portable. Ok, that is evidently better. Having

Re: [dev] [sbase] New branch for sbase+ubase

Hi, On Wed, Mar 13, 2024 at 11:51:46PM +0100, Elie Le Vaillant wrote: > I think this layout has a few problems: > > - we lose the meaningful separation that the sbase/ubase layout allowed, > i.e the distinction > between what is portable and what isn't. This _could_ be included as > part

Re: [dev] [sbase] New branch for sbase+ubase

On 2024-03-13 11:27, Roberto E. Vargas Caballero wrote: I am thinking about the new layout, and for now I was considering something like: - posix (tools defined by POSIX) - misc (helpful tools not defined by POSIX). - linux (tools that only make sense in linux) -

[dev] [sbase] New branch for sbase+ubase

Hi, I have pushed a new branch called ubase-merge that has all the files from ubase in the directory ubase of the root directory in the repository. You can still see the full history of a file in that directory using something like git log --follow. I am thinking about the new layout, and for

Re: [dev] reading an epub book with less: adventures in text processing

Rather late to the party and I've already forgotten the initial email. Nevertheless, I'll give the program I most use: epub2txt.[0] It's not perfect, but compared to calibre's ebook-convert, and everything else I found in C in github or codeberg or gitlab, it's the best. A once-over with an

Re: [dev] reading an epub book with less: adventures in text processing

On 2024-03-11 17:44 Greg Reagle wrote: > Now my next question is, what is the tool that does the *best* job of > turning a PDF book into a readable text document? Via html or > docbook or markdown or whatever--doesn't matter. My previous > experience trying things out to achieve this goal is

Re: [dev] reading an epub book with less: adventures in text processing

On Sat, Mar 9, 2024, at 1:15 PM, Greg Minshall wrote: > for some personal tastes/usage cases, this, using pandoc's `-t` > option, might be minor-ly simpler: > > man --local-file --pager 'less -ir' \ > <(pandoc --standalone -t man \ >

[dev] Re: reading an epub book with less: adventures in text processing

I think I finally figured it out! With help, of course, from my wise and helpful community. Thanks! And reading the man page for elinks. :> for direct viewing in less: pandoc -s -t html City_of_Truth-Morrow.epub | elinks -dump-color-mode 2 -force-html | less -ir to make a file to keep,

Re: [dev] Re: reading an epub book with less: adventures in text processing

On Sat, Mar 9, 2024, at 12:53 PM, LM wrote: > You could try modifying sdlbook or bard. It would be nice if either of these > offered keymapping functionality like some programming editors do. Thank you for telling me about these two programs. I had not heard of them.

Re: [dev] reading an epub book with less: adventures in text processing

On Sat, Mar 9, 2024, at 4:06 PM, Georg Lehner wrote: > Option 1: use w3m [snip] All great commands. Thank you. > The reason you loose formatting when saving from less(1) or w3m is, that > these programs on purpose do not save the terminal control characters > which are doing the markup. Line

Re: [dev] reading an epub book with less: adventures in text processing

On Sat, Mar 9, 2024, at 11:33 AM, Hiltjo Posthuma wrote: > Maybe mupdf/mutools or the eGhostscript tools o qpdf? Yes, thank you for this excellent advice. I tried "mutool convert", but I am more satisfied with pandoc's output, for both text and html output (from epub).

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

Hi, After reading the opinion of the people in this thread, I think the best option is to merge the sbase and ubase repositories and having a mechanism in the build system to select the set of tools to be included in the build. The main drawback of this is that the build system will be more

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

Re: [dev] reading an epub book with less: adventures in text processing

Hi Greg, On 2024-03-09 15:34, Greg Reagle wrote: I have an epub ebook. It is a novel, but when I get this process working, I want to repeat it for any epub ebook. I want to read it, with formatting (such as underline or italics), with less. I am happy to use any software that exists in the

Re: [dev] reading an epub book with less: adventures in text processing

Greg, thanks for this! for some personal tastes/usage cases, this, using pandoc's `-t` option, might be minor-ly simpler: man --local-file --pager 'less -ir' \ <(pandoc --standalone -t man \ 2015.31233.Arab-Geographers-Knowledge-Of-Southern-India.epub) | less and,

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

On Sat, 09 Mar 2024 17:28:49 +0100 Elie Le Vaillant wrote: > Страхиња Радић wrote: > > Compiling all programs into one binary is currently an option, and IMHO it > > should remain an option. > > I fully agree. However, the single binary situation should be improved. > > > Great, combine

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

On 24/03/09 05:28PM, Elie Le Vaillant wrote: > Or is it out-of-scope for us to implement a full-blown shell? I really am > not sure. I think it would be interesting to have "official" suckless versions of all of the mentioned programs, which would at minimum implement their descriptions from

Re: [dev] reading an epub book with less: adventures in text processing

On Sat, Mar 09, 2024 at 09:34:12AM -0500, Greg Reagle wrote: > I have an epub ebook. It is a novel, but when I get this process working, I > want to repeat it for any epub ebook. > > I want to read it, with formatting (such as underline or italics), with less. > I am happy to use any software

[dev] Re: reading an epub book with less: adventures in text processing

On Sat, Mar 9, 2024, at 9:34 AM, Greg Reagle wrote: > I want to read it, with formatting (such as underline or italics), with > less. Or, I would be satisfied with an ebook reader program (either TUI or GUI is fine) that has the same functionality and keys as less. Of course it can have some

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

Страхиња Радић wrote: > Compiling all programs into one binary is currently an option, and IMHO it > should remain an option. I fully agree. However, the single binary situation should be improved. > Great, combine the two versions of libutil into a single, separate > libutil repository I'm

[dev] reading an epub book with less: adventures in text processing

I have an epub ebook. It is a novel, but when I get this process working, I want to repeat it for any epub ebook. I want to read it, with formatting (such as underline or italics), with less. I am happy to use any software that exists in the process, but I MUST use less in the end to read

[dev] Re: dwm: Maybe a combination of columns and grids?

On Thu, Jan 25, 2024, at 2:48 PM, Greg Reagle wrote: > I love the way that the columns patch handles the master area, i.e. the > ability to control its width and number of windows, and that the > windows in the master area take up the full height of the display. In > the stacking area, though,

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

On Sat, 9 Mar 2024 14:53:07 +0100 Страхиња Радић wrote: > On 24/03/09 12:59AM, Mattias Andrée wrote: > > I agree, a single repo (or alternatively making libutil it's own repo) is > > necessary if we want one binary, and I think we do. > > Compiling all programs into one binary is currently an

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

On 24/03/09 12:59AM, Mattias Andrée wrote: > I agree, a single repo (or alternatively making libutil it's own repo) is > necessary if we want one binary, and I think we do. Compiling all programs into one binary is currently an option, and IMHO it should remain an option. In my own toy distro[1]

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

On Sat, 09 Mar 2024 12:10:28 +0100 Eolien55 wrote: > Mattias Andrée wrote: > > I think there should be one directory called "portable" containing only > > tools > > from sbase, and one directory called "linux" containing the tools from ubase > > and maybe even symlinks to the tools in

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

Mattias Andrée wrote: > I think there should be one directory called "portable" containing only tools > from sbase, and one directory called "linux" containing the tools from ubase > and maybe even symlinks to the tools in "portable". This structure would allow > us to add implementations for

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

On Fri, 08 Mar 2024 23:33:12 +0100 Eolien55 wrote: > Страхиња Радић wrote: > > The problem of having separate *box executables could be solved by creating > > an > > "umbrella" *box project, perhaps having sbase, ubase and > > [insert_letter]base as > > git submodules, and deciding what to

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

Страхиња Радић wrote: > The problem of having separate *box executables could be solved by creating > an > "umbrella" *box project, perhaps having sbase, ubase and [insert_letter]base > as > git submodules, and deciding what to build based on the contents of config.mk. The problem is that

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

On 24/03/08 06:40AM, Roberto E. Vargas Caballero wrote: > I would like to move the discussion here and see what alternatives > we have and how to proceed in this case. IMHO, if the intention behind sbase was to provide a minimal portable POSIX utilities implementation, anything not fitting that

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

I think we should keep the implementation of each tool as minimal as possible, but POSIX-complete, and of course common tools such as install(1) and tar(1). However, actually using a system that is nothing more than POSIX is very cumbersome. And I think it is a better solution to implement

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

Elie Le Vaillant wrote: > Another idea could be to have both in the same git repository, > [...] This would be my idea as well. It also wouldn't be that difficult to let people pick and choose which sets of tools to include in the final -box via config.mk or similar. I would stick with only the

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

Hi, I think one of the main current issues with the current organization of sbase's and ubase's code, is that while they share parts of code (some parts of libutil are shared), they do not actually have it in common. As a result, changes to shared parts of libutil in sbase are not reflected in

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

Hi, While reviewing several patches for sbase adding new tools some discussion happened and I thought it was better to move the discussion here. The patches raised a concern about what should be the scope of sbase. The idea of sbase was to provide a minimal portable POSIX base, while having

Re: [dev] [st] externalpipe on OpenBSD

Hi, can anyone take a look at this and approve or comment if there is anything to add to or change about the patch? https://lists.suckless.org/wiki/2402/4748.html

[dev] [sbase] tar compresses slowly

I noticed that 'tar' is very slow to compress if compared to 'GNU tar', especially when there are multiple small files. 26 GB of OS's ISO images: GNU tar: 195s sbase tar: 250s (128% more) 3.6 GB of images: GNU tar: 3s sbase tar: 27s (900% more) (!)

Re: [dev] [st] externalpipe on OpenBSD

On 24/02/21 10:12AM, Страхиња Радић wrote: > [...] (the program specified in openurlcmd doesn't get > executed). I narrowed this down to adding "exec" to the second pledge: +@@ -803,7 +809,7 @@ ttynew(const char *line, char *cmd, const char *out, char **args) + break; +

[dev] [st] externalpipe on OpenBSD

Hello, I recently installed OpenBSD for the first time and I noticed a few issues with externalpipe[1]. It seems this patch clashes with the parameters passed to pledge(2) in ttynew[2] (the program specified in openurlcmd doesn't get executed). I also noticed that when I simply comment out

Re: [dev] [st] XTSMGRAPHICS query

On Sun, 18 Feb 2024 02:54:19 CST, Hiltjo Posthuma wrote: > Hi Tim, > > Thanks for the report. > > Which TUI library did you write? Some real life programs to test it against > would be useful too. The library is https://sr.ht/~rockorager/vaxis. I have already moved all queries in it to the alt

Re: [dev] [st] XTSMGRAPHICS query

On Sun, 18 Feb 2024 00:29:00 CST, Markus Wichmann wrote: > Had to research what this is supposed to do: XTerm replies to it with > the screen size. Except the docs explicitly warn you that it is not > necessarily the screen size. More accurately, it responds with the screen geometry available for

Re: [dev] [st] XTSMGRAPHICS query

On Sat, Feb 17, 2024 at 09:45:44PM -0500, Tim Culverhouse wrote: > Hello - I am the author of a TUI library and received a bug report regarding > cursor placement on exiting an application. > > I was able to narrow down a simple reproducer to how st a XTSMGRAPHICS query: > > echo -e

Re: [dev] [st] XTSMGRAPHICS query

Am Sat, Feb 17, 2024 at 09:45:44PM -0500 schrieb Tim Culverhouse: > Hello - I am the author of a TUI library and received a bug report regarding > cursor placement on exiting an application. > > I was able to narrow down a simple reproducer to how st a XTSMGRAPHICS query: > > echo -e

[dev] [st] XTSMGRAPHICS query

Hello - I am the author of a TUI library and received a bug report regarding cursor placement on exiting an application. I was able to narrow down a simple reproducer to how st a XTSMGRAPHICS query: echo -e "\x1b[?2;1;0S" This can also be seen when using a notcurses application which

Re: [dev] Announcing a couple small X11 utilities

On 15.02.24 03:47, NRK wrote: maybe also announce it on xorg-announce ? IMHO it's good to get some more publically visible traffic on X tools, showing that X isn't dead at all. by the way: I'd recommend using spdx-license-identifer tag instead of redundant license texts in individual

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

Re: Re: [dev] [st][patch] more work on the XEmbed embedder

On Sun, Feb 04, 2024 at 06:29:40PM +0100, Страхиња Радић wrote: > > That is how it usually works. Users submit patches, which are provided on > > https://st.suckless.org/patches/ > > and (depending on context) might get merged into the upstream. This > particular > patch doesn't look

Re: [dev] [st][patch] more work on the XEmbed embedder

On 24/02/04 03:22PM, Robin Haberkorn wrote: > Thirdly, I doubt that the maintainers would want to merge this into mainline. The essence of the suckless philosophy goes hand in hand with the Unix philosophy - programs that do one thing well and cooperate with other programs. st is and should

Re: [dev] [st][patch] more work on the XEmbed embedder

04.02.24 12:52, Hiltjo Posthuma пишет: > Hi, > > If you want to contribute to upstream you need to rebase the patches on the > master version of st. > > Then you send the patches (git-format-patch) to the mailinglist. > Okay. But first of all, there are remaining problems. I would like to

Re: [dev] [st][patch] more work on the XEmbed embedder

On Sun, Feb 04, 2024 at 08:38:46AM +0300, Robin Haberkorn wrote: > Hello! > > I picked up the patch from Jochen Sprickerhof > that was posted on hack...@suckless.org a few years ago, allowing you to > embed applications into st via Xembed. So this is the _host_ side of > Xembed, very similar to

Re: [dev] dev

On Sat, Feb 03, 2024 at 09:04:04PM +, NRK wrote: > 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

[dev] [st][patch] more work on the XEmbed embedder

Hello! I picked up the patch from Jochen Sprickerhof that was posted on hack...@suckless.org a few years ago, allowing you to embed applications into st via Xembed. So this is the _host_ side of Xembed, very similar to what tabbed does. The thing is, you do not always want to open apps in new

  1   2   3   4   5   6   7   8   9   10   >