Re: [dev] Seeking Recommendations for a UNIX-like Operating System

[Silvan Jegen]

Heyho!

EZS Ephir  wrote:
> Hello Marcel,
> 
> I consider to use OpenBSD. It is highly suckless and can be used as main
> operating system.
> 
> > - Safe connectivity to the web
> You can use surf for accessing the web here.
> 
> > - Ability to open a text editor (such as vim or vi)
> I'm pretty sure that nearly all UNIX systems have text editors in it :)
> It is available in OBSD.
> 
> > - (If possible) Support for Wayland (I am not a fan of X)
> Seemingly, Wayland is now Linux-only stuff, so it is not available in
> any other UNIX systems.

There seems to be ongoing work to make get a Wayland compositor to run
on OpenBSD:

https://www.xenocara.org/Wayland_on_OpenBSD.html

Looks like some more work is needed but it is feasible.


Cheers,
Silvan

Re: [dev] Seeking Recommendations for a UNIX-like Operating System

[Feodor]

marcel.wirk...@keemail.me писал(а) 2024.07.28 00:29:

Dear Members of the suckless.org Dev Mailing List,

My name is Marcel, and I am looking for a new operating system.

Since 2023, I have been using Gentoo Linux as my daily driver. However, 
after a thorough examination of the Linux kernel and recent decisions 
made by the Gentoo Linux council, I am contemplating switching to a 
different operating system. I am particularly interested in finding the 
most UNIX-like operating system available in 2024, which does not 
necessarily have to be Linux-based.


One option I have considered is plan9, but I am concerned about its 
safety for modern web use, as I frequently connect to the internet for 
research purposes. My primary requirements for an operating system are 
as follows:

- Safe connectivity to the web
- Ability to open a text editor (such as vim or vi)
- (If possible) Support for Wayland (I am not a fan of X)

Additionally, I am curious about the operating systems that you all use 
and the reasons behind your choices.


I appreciate your time and look forward to your recommendations.

-- Marcel


I can recomend you CRUX. It is a source-based GNU/Linux distro. It has 
BSD-style init scripts and ports system. There is a wayland port, but I 
didn't try it.
I used Gentoo for several years before, and now I switched to CRUX. I 
like it very much. It's KISS and very convenient. It is very comfortable 
to rule ports and make and edit own.


--
Feodor

Re: [dev] Seeking Recommendations for a UNIX-like Operating System

[lain.]

On 2024年07月27日 23:29, the silly marcel.wirk...@keemail.me claimed to have said:
> Dear Members of the suckless.org Dev Mailing List,
> 
> My name is Marcel, and I am looking for a new operating system.
> 
> Since 2023, I have been using Gentoo Linux as my daily driver. However, after 
> a thorough examination of the Linux kernel and recent decisions made by the 
> Gentoo Linux council, I am contemplating switching to a different operating 
> system. I am particularly interested in finding the most UNIX-like operating 
> system available in 2024, which does not necessarily have to be Linux-based.
> 
> One option I have considered is plan9, but I am concerned about its safety 
> for modern web use, as I frequently connect to the internet for research 
> purposes. My primary requirements for an operating system are as follows:
> - Safe connectivity to the web
> - Ability to open a text editor (such as vim or vi)
> - (If possible) Support for Wayland (I am not a fan of X)
> 
> Additionally, I am curious about the operating systems that you all use and 
> the reasons behind your choices.
> 
> I appreciate your time and look forward to your recommendations.
> 
> -- Marcel

I'd say either OpenBSD or NetBSD.
OpenBSD checks the safety and vim boxes, but not Wayland, and reserve
NetBSD if you're either running some obscure non-X86_64 hardware that
OpenBSD doesn't support (yet), or if OpenBSD runs too slow on your machine.

If you want something more desktop-oriented, hamonious, and you don't
mind it not being UNIX-like (but somewhat similar), there's Haiku.

As for Plan9, safety shouldn't be a problem, since there are 2 forks
that are still being maintained today, compatibility work poorly written
webpages, I mean, "modern web" is probably a bigger issue.

I don't use Wayland personally, and I daily drive OpenBSD, but I don't
mind that OpenBSD doesn't support Wayland, seeing it's a supposedly
"simple" protocol that has been in development for 16 years, and still
not production ready.
But honestly, if Wayland is important to you, then you might not have
other options than Linux to be honest.
Even though FreeBSD and NetBSD do have Wayland in their repositories,
it's a pain in the ass to get working on those.

-- 
lain.
PGP public key: https://fair.moe/lain.asc


signature.asc
Description: PGP signature

Re: [dev] Seeking Recommendations for a UNIX-like Operating System

[Страхиња Радић]

After years of using various versions of GNU/Linux (and creating my own 
pet distro based on musl+Linux), I finally settled on OpenBSD.

In a nutshell, BigTech working through RedHat destroyed GNU/Linux.

* * *

On Sat, Jul 27, 2024 at 11:29:49PM +0200, marcel.wirk...@keemail.me 
wrote:
> - (If possible) Support for Wayland (I am not a fan of X)

There was already a thread about Wayland back in 2021:

https://lists.suckless.org/dev/2108/34457.html

My opinion on X.Org vs Wayland from back then, which I still go by:

https://lists.suckless.org/dev/2109/34469.html
> Wayland sucks. X.Org sucks too, but it is still much better than 
> Wayland.


> - Ability to open a text editor (such as vim or vi)

I don't think there is a single OS which doesn't support this.


Дана 24/07/28 01:26AM, EZS Ephir написа:
> > - Safe connectivity to the web
> You can use surf for accessing the web here.

First it is necessary to define what does "safe" means.

My response to a similar topic from 2022:

https://lists.suckless.org/dev/2204/34785.html
> While Web itself sucks[1], and surf is a compromise between a 
> suckless shell and an engine that sucks (Webkit) for a medium that 
> sucks (HTML+CSS+JS), I find that it is unfortunately not satisfactory 
> yet from a privacy-respecting standpoint, at least until it supports 
> plugins such as uMatrix which block Ads and various other 
> privacy-intruding technologies. Simple filtering of URLs just isn't 
> enough.
>
> Until such a moment, I'm using ungoogled-chromium[2] for everyday 
> use.
>
> [1]: https://suckless.org/sucks/web/
> [2]: https://github.com/Eloston/ungoogled-chromium

OpenBSD is notable as one of the rare OSes having ungoogled-chromium as 
an official package, installable via pkg_add(1).

Re: [dev] Seeking Recommendations for a UNIX-like Operating System

[EZS Ephir]

Hello Marcel,

I consider to use OpenBSD. It is highly suckless and can be used as main
operating system.

> - Safe connectivity to the web
You can use surf for accessing the web here.

> - Ability to open a text editor (such as vim or vi)
I'm pretty sure that nearly all UNIX systems have text editors in it :)
It is available in OBSD.

> - (If possible) Support for Wayland (I am not a fan of X)
Seemingly, Wayland is now Linux-only stuff, so it is not available in any other
UNIX systems.

> Additionally, I am curious about the operating systems that you all use and 
> the reasons behind your choices.
Now I use Debian GNU/Linux because:

1. I need some WIFI drivers that *BSD systems don't support.
2. I am forced to use some systemd-related programs.

I would switch to OBSD if there were no such problems.

On Sat, Jul 27, 2024 at 11:29:49PM +0200, marcel.wirk...@keemail.me wrote:
> Dear Members of the suckless.org Dev Mailing List,
> 
> My name is Marcel, and I am looking for a new operating system.
> 
> Since 2023, I have been using Gentoo Linux as my daily driver. However, after 
> a thorough examination of the Linux kernel and recent decisions made by the 
> Gentoo Linux council, I am contemplating switching to a different operating 
> system. I am particularly interested in finding the most UNIX-like operating 
> system available in 2024, which does not necessarily have to be Linux-based.
> 
> One option I have considered is plan9, but I am concerned about its safety 
> for modern web use, as I frequently connect to the internet for research 
> purposes. My primary requirements for an operating system are as follows:
> - Safe connectivity to the web
> - Ability to open a text editor (such as vim or vi)
> - (If possible) Support for Wayland (I am not a fan of X)
> 
> Additionally, I am curious about the operating systems that you all use and 
> the reasons behind your choices.
> 
> I appreciate your time and look forward to your recommendations.
> 
> -- Marcel
> 

-- 
Gracefully, Ephir

Re: [dev] Seeking Recommendations for a UNIX-like Operating System

[NRK]

Hi Marcel,

> recent decisions made by the Gentoo Linux council

Out of curiosity, which ones in specific do you dislike?

- NRK

Re: [dev] Seeking Recommendations for a UNIX-like Operating System

[based department official]

https://openbsd.org

Ekkor: 2024. július 27. 23:29:49 CEST, marcel.wirk...@keemail.me írta:
>Dear Members of the suckless.org Dev Mailing List,
>
>My name is Marcel, and I am looking for a new operating system.
>
>Since 2023, I have been using Gentoo Linux as my daily driver. However, after 
>a thorough examination of the Linux kernel and recent decisions made by the 
>Gentoo Linux council, I am contemplating switching to a different operating 
>system. I am particularly interested in finding the most UNIX-like operating 
>system available in 2024, which does not necessarily have to be Linux-based.
>
>One option I have considered is plan9, but I am concerned about its safety for 
>modern web use, as I frequently connect to the internet for research purposes. 
>My primary requirements for an operating system are as follows:
>- Safe connectivity to the web
>- Ability to open a text editor (such as vim or vi)
>- (If possible) Support for Wayland (I am not a fan of X)
>
>Additionally, I am curious about the operating systems that you all use and 
>the reasons behind your choices.
>
>I appreciate your time and look forward to your recommendations.
>
>-- Marcel
>

[dev] Seeking Recommendations for a UNIX-like Operating System

[marcel . wirkore]

Dear Members of the suckless.org Dev Mailing List,

My name is Marcel, and I am looking for a new operating system.

Since 2023, I have been using Gentoo Linux as my daily driver. However, after a 
thorough examination of the Linux kernel and recent decisions made by the 
Gentoo Linux council, I am contemplating switching to a different operating 
system. I am particularly interested in finding the most UNIX-like operating 
system available in 2024, which does not necessarily have to be Linux-based.

One option I have considered is plan9, but I am concerned about its safety for 
modern web use, as I frequently connect to the internet for research purposes. 
My primary requirements for an operating system are as follows:
- Safe connectivity to the web
- Ability to open a text editor (such as vim or vi)
- (If possible) Support for Wayland (I am not a fan of X)

Additionally, I am curious about the operating systems that you all use and the 
reasons behind your choices.

I appreciate your time and look forward to your recommendations.

-- Marcel

Re: [dev] An update about my gtk2 fork

[Dave Blanchard]

On Tue, 23 Jul 2024 10:06:11 +0200
Hiltjo Posthuma  wrote:

> > forward). Software quality? What's that?
> 
> Maybe send a patch to them instead of whining on the internet.

Maybe shut the fuck up. The GNU project is widely known for its shit code 
quality and complete lack of craftsmanship. If you want to waste your time 
doing something useless like sending a patch to GNU, it'd be more entertaining 
to play the lottery, or vote.

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

[Κρακ Άουτ]

On 2024-07-25 15:44 Κρακ Άουτ  wrote:

> On 2024-06-18 14:10 Κρακ Άουτ  wrote:
>  
>> 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 raise. I searched
 but did not locate any such patch. Is there perhaps, or could you
 give me any advice on how to achieve this?
>>>  
>>> I'm not a regular user of DWM anymore, but I just rapidly tried
>>> with
>>> the last version and this feature seems to work. Maybe you have an
>>> outdated version (probably not, I think this has been there since
>>> 2009) or perhaps another patch is blocking this?
>>>  
>>> Regards.
>>  
>> In that case, a patch that I've added must have changed the
>> behaviour
>> (about ten added). I'll try a stock installation of dwm to see.
>>  
>> Thank you.
>  
> I tried the stock dwm, just downloaded from git.suckless.org/dwm. It
> does not autoraise floating windows when gaining focus.
>  
> So my initial question remains, any advice on how to achieve this?
>  

Let me clarify that autoraise does not happen when hovering mouse pointer over 
a floating window, when in floating mode or between windows that are set as 
floating.
It is autoraised if switching window using key shortcut.

I made this change in dwm.c and now it works to my preference:

In function `void focus(Client *c)` I added this `XRaiseWindow(dpy, c->win);` 
after `setfocus(c);`

Here is the altered function:

```
void
focus(Client *c)
{
if (!c || !ISVISIBLE(c))
for (c = selmon->stack; c && !ISVISIBLE(c); c = c->snext);
if (selmon->sel && selmon->sel != c)
unfocus(selmon->sel, 0);
if (c) {
if (c->mon != selmon)
selmon = c->mon;
if (c->isurgent)
seturgent(c, 0);
detachstack(c);
attachstack(c);
grabbuttons(c, 1);
XSetWindowBorder(dpy, c->win, 
scheme[SchemeSel][ColBorder].pixel);
setfocus(c);
XRaiseWindow(dpy, c->win);  // THIS is added to autoraise after 
focus with mouse pointer
} else {
XSetInputFocus(dpy, root, RevertToPointerRoot, CurrentTime);
XDeleteProperty(dpy, root, netatom[NetActiveWindow]);
}
selmon->sel = c;
drawbars();
}
```

If it's tested by others also, I'll consider making a patch.
I think it's a bit risky to publish it if tested by me only.

Regards.

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

[Κρακ Άουτ]

On 2024-06-18 14:10 Κρακ Άουτ  wrote:

> 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 raise. I searched
>>> but did not locate any such patch. Is there perhaps, or could you
>>> give me any advice on how to achieve this?
>>  
>> I'm not a regular user of DWM anymore, but I just rapidly tried
>> with
>> the last version and this feature seems to work. Maybe you have an
>> outdated version (probably not, I think this has been there since
>> 2009) or perhaps another patch is blocking this?
>>  
>> Regards.
>  
> In that case, a patch that I've added must have changed the
> behaviour
> (about ten added). I'll try a stock installation of dwm to see.
>  
> Thank you.

I tried the stock dwm, just downloaded from git.suckless.org/dwm. It does not 
autoraise floating windows when gaining focus.

So my initial question remains, any advice on how to achieve this?

Re: [dev] An update about my gtk2 fork

[Hiltjo Posthuma]

On Tue, Jul 23, 2024 at 07:57:06AM +0200, Markus Wichmann wrote:
> Am Mon, Jul 22, 2024 at 03:44:36PM + schrieb stefan1:
> > I mentioned -flto above, because without lto, gcc doesn't see that doing
> > init_func();
> > initializes the var variable in some cases.
> 
> That's a bug. Maybe report it. Although, when last I reported a bug to
> gcc, all that happened was that it got closed as duplicate, I got CCed
> on the original bug, and now I am getting a mail from the GCC bugtracker
> regularly, telling me that they bumped the versions (and pushed the bug

> forward). Software quality? What's that?

Maybe send a patch to them instead of whining on the internet.

> 
> Ciao,
> Markus
> 

-- 
Kind regards,
Hiltjo

Re: [dev] An update about my gtk2 fork

[Markus Wichmann]

Am Mon, Jul 22, 2024 at 03:44:36PM + schrieb stefan1:
> I mentioned -flto above, because without lto, gcc doesn't see that doing
> init_func();
> initializes the var variable in some cases.

That's a bug. Maybe report it. Although, when last I reported a bug to
gcc, all that happened was that it got closed as duplicate, I got CCed
on the original bug, and now I am getting a mail from the GCC bugtracker
regularly, telling me that they bumped the versions (and pushed the bug
forward). Software quality? What's that?

Ciao,
Markus

[dev] An update about my gtk2 fork

[stefan11111]

Hi suckless enjoyers. Beware, this is quite a long mail.
I have come with an update 6 months after this thread:
https://lists.suckless.org/dev/2401/35517.html

To those who can't open that link in their mailer, it's the thread where 
I

presented my fork of gtk2:
https://github.com/stefan1/gtk2

After 6 months, I made quite a bit of progress with it.
Since it's been quite some time, I might forget to mention everything 
important I
improved/fixed. If someone's interested, everything is in the git 
history.


Since I first wrote here about this, quite a few things have changed:
A few bugfixes.
Cleaning up the code with a linter.
Made compiling print backends optional.
Fixing all warnings when building with gcc14 with -flto and with cups 
support disabled.

Adding 64-bit time support(needs kernel 64-bit time_t).
Also removed all the code for Windows and apple since I can't test on 
those platforms
and I don't plan to support those. Doing this made the code considerably 
easier to maintain.


I mentioned -flto above, because without lto, gcc doesn't see that doing 
init_func();

initializes the var variable in some cases.
Also, I left 2 deprecation warnings in, because they aren't really 
warnings but bugs in glib.

they provide a file which contains something like this:
struct foo{
...
deprecated_pointer *bar; /* backwards compatibility */
...
}
And this isn't really me using deprecated functionality, but upstream's 
implementation being buggy.


I didn't fix the cups code because I don't have a way of testing it.

I'll emphasize a bit more the "no warnings" part.
There were literal hundreds of warnings I had to fix, and even void* 
arithmetic mixed in between.


Also, as an example of glib suck, glib makes heavy use of storing 
function pointers in void*'s,

making it unportable.

I also cleaned up and tested the DirectFB backend of gtk and I tried my 
best to preserve it.
I know someone was interested in this backed 6 months ago when I send 
the first mail about this.

However, gtk2 on directfb is very different from gtk2 on X.
A lot of functions aren't implemented for directfb, and some can't be 
implemented on directfb.

Notably, the gdkx.h header is missing entirely for obvious reasons.

I will try to keep supporting the directfb backend, especially given 
that directfb is actively developed:

https://github.com/directfb2/DirectFB2

I decided that all this warrants finally making a release:
https://github.com/stefan1/gtk2/releases/download/gtk%2B-2.24.34/gtk+-2.24.34.tar.gz

And for those of you running gentoo or another distro that uses portage 
as it's package manager,
I have a gentoo overlay with all these and plenty of other stuff I found 
interesting/useful:

https://github.com/stefan1/stefan_overlay

Also, I have tried to write a compatibility library to translate gtk3 
calls to gtk2 calls,

to give gtk3 apps the gtk2 look:
https://github.com/stefan1/gtk3-to-gtk2/

I've had limited success with this.
So far, I've managed to build and run 2 gtk3 apps with this, l3afpad and 
something else, I forgot what.
I have also tried to build the gtk3 version of codeblocks with this, 
which is a wxGTK app.

I could build it, but it segfaults before even spawning a window.
if know of other gtk3 apps I should test this with, let me know.

I also wrote this, but didn't invest much time in it:
https://github.com/stefan1/gtk2-makefile
It's not ready to be used, but it's meant to be a couple of Makefiles 
and a C configure parser to replace

the shell script generated by autoconf.
I abandoned the idea pretty quick since even if I succeeded in making it 
work, the end result would
likely be worse that what autotools already does, and I didn't want to 
make a worse end product just

because of my preference for simpler tools.
I linked to this mostly so it could serve as inspiration for someone 
else and see what other

people think of this.

And with this, the mail is finally over. Thanks for taking the time for 
reading it.

I would like to read your thoughts on this.
After these 6 months, I feel like I learned a bit more about C and glib, 
which is always a good thing.


Have a nice day and happy hacking and creating suckless software.
--
Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-7400_CPU_@_3.00GHz

COMMON_FLAGS="-O3 -pipe -march=native -fno-stack-protector 
-ftree-vectorize -ffast-math -funswitch-loops -fuse-linker-plugin -flto 
-fdevirtualize-at-ltrans -fno-plt -fno-semantic-interposition 
-falign-functions=64 -fgraphite-identity -floop-nest-optimize"


USE="-* git verify-sig rsync-verify man alsa X grub ssl ipv6 lto 
libressl olde-gentoo asm native-symlinks threads jit jumbo-build minimal 
strip system-man"


INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd 
/usr/lib/modules-load.d /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus 
/lib/udev /usr/share/icons /usr/share/applications 
/usr/share/gtk-3.0/emoji"

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

[Ethan Marshall]

On 12/06/24 07:03pm, Greg Reagle wrote:
> 
> And while I have your attention... What a great language Lua is!
Couldn't agree more. It has by far the best C interface I've ever used.
If you want a nice exploration into how a programming language works,
read the Lua source code - it is also wonderful.

Ethan

Re: [dev] [st] question about keyboard shortcuts

[Eric Pruitt]

On Tue, Jul 09, 2024 at 04:54:38PM +0300, Feodor wrote:
> > Tangentially, if you're asking for help configuring something, sharing
> > the configuration you have that doesn't work is the bare minimum you
> > should do. That information isn't something people trying to help you
> > should have to fish for.
>
> I use st and screen in my CRUX distro.

That's not what I meant. I was referring to the fact that you didn't
post your screen configuration file until I asked for it.

> What I didn't yet configured is "escape" keyboard combination in
> screen. I need to make CTRL+Tab to be escape combination in screen. So
> that should be escape ^something 'escape ^Bb' makes it to be CTRL+b as
> escape combination, and it works. But I need to make it CTRL+Tab.

Per the screen manual documenting "escape", that's not even possible:
"Each argument is either a single character, a two-character sequence
[...]." You would have to map Ctrl+Tab to a single, standard control
character instead of a multi-character sequence.

Eric

Re: [dev] [st] question about keyboard shortcuts

[Feodor]

2024.07.07 20:15 Eric Pruitt wrote:


This configuration snippet doesn't make sense to me. You don't need the
"escape" line and your bindkey configuration doesn't even use the right
sequences. All you should need are bindkey lines:

bindkey "^[[27;5;9~" next
bindkey "^[[27;6;9~" prev

I tested this on a new screen installation without issue.
I dont need 'bindkey "^[[27;5;9~" next' and 'bindkey "^[[27;6;9~" prev'. 
I need ALT+Left/Right to switch between tabs, which I've already 
configured with

bindkey ^[[1;3D prev
bindkey ^[[1;3C next
and it works as I need.
What I didn't yet configured is "escape" keyboard combination in screen. 
I need to make CTRL+Tab to be escape combination in screen. So that 
should be

escape ^something
'escape ^Bb' makes it to be CTRL+b as escape combination, and it works. 
But I need to make it CTRL+Tab.



Tangentially, if you're asking for help configuring something, sharing
the configuration you have that doesn't work is the bare minimum you
should do. That information isn't something people trying to help you
should have to fish for.

I use st and screen in my CRUX distro.

Re: [dev] [st] question about keyboard shortcuts

[Eric Pruitt]

On Sun, Jul 07, 2024 at 11:20:52AM +0300, Feodor wrote:
> As you said, I tried to edit ~/.Xresources:

I never said anything about Xresources. Those are for XTerm, not st. The
important part from Stack Exchange link are the screenrc files.
Furthermore:

> escape ^[[27;5;9~
> bindkey ^[[1;3D prev
> bindkey ^[[1;3C next

This configuration snippet doesn't make sense to me. You don't need the
"escape" line and your bindkey configuration doesn't even use the right
sequences. All you should need are bindkey lines:

bindkey "^[[27;5;9~" next
bindkey "^[[27;6;9~" prev

I tested this on a new screen installation without issue.

Tangentially, if you're asking for help configuring something, sharing
the configuration you have that doesn't work is the bare minimum you
should do. That information isn't something people trying to help you
should have to fish for.

Eric

Re: [dev] [st] question about keyboard shortcuts

[Feodor]

2024.07.06 19:51 Eric Pruitt wrote:

> I've used xcape and sxhkd with some success in mapping modifier keys,
> however in a different situation from yours.
>
> https://github.com/alols/xcape
> https://github.com/baskerville/sxhkd

Eric, do you confirm that I have to use sxhkd and xcape?


I don't use either of those. The only other accompanying configuration
snippets are in tmux which natively supports those escape sequences for
Ctrl+(Shift)+Tab:
.

On Fri, Jun 28, 2024 at 11:03:45AM +0300, Feodor wrote:

but the combination CTRL+Tab doesn't work for "escape" command for
screen. Instead I get ";5;9~" printed after the prompt when I press
CTRL+Tab.


Can you post the actual configuration you're using? I haven't used GNU
Screen as my daily-driver in some time and no longer have to my 
original

configuration files, but when I had Ctrl+(Shift)+Tab setup in Screen, I
think I used "bind" and/or "bindkey" i.e. 
.


Eric


The only other accompanying configuration snippets are in tmux which 
natively supports those escape sequences for Ctrl+(Shift)+Tab

I think, screen does not support those sequences by default.
I wrote to screen's mailing lists:

I need to set "escape" combination to CTRL+TAB.
You can't. TAB is CTRL-I in VT100 mode which most terminals use, so 
there is no way to modify that further with CTRL.

As you said, I tried to edit ~/.Xresources:
*vt100.translations: #override \n\
Ctrl ~Shift Tab: string(0x1b) string("[27;5;9~")

also tried:
*vt100.translations: #override \n\
Ctrl Tab: string(0x1b) string("[27;5;9~")

but still I get ";5;9~" printed after the prompt when I press CTRL+Tab.

My ~/.screenrc is:
startup_message off
term 'screen-256color'
encoding UTF-8
termcapinfo st* ti@:te@
shell -/bin/bash
msgminwait 0
msgwait 0
caption always '%{= kW}%-w%{= Ck}%50>%n %t%{-}%+w%<%{d} %=%{B}%0c%{d}'
escape ^[[27;5;9~
bindkey ^[[1;3D prev
bindkey ^[[1;3C next


think I used "bind" and/or "bindkey"

for "escape" line:
escape 
is needed.
escape ^Bb -- works for CTRL+b.

Re: [dev] [st] question about keyboard shortcuts

[Eric Pruitt]

> > I've used xcape and sxhkd with some success in mapping modifier keys,
> > however in a different situation from yours.
> > 
> > https://github.com/alols/xcape
> > https://github.com/baskerville/sxhkd
> 
> Eric, do you confirm that I have to use sxhkd and xcape?

I don't use either of those. The only other accompanying configuration
snippets are in tmux which natively supports those escape sequences for
Ctrl+(Shift)+Tab:
.

On Fri, Jun 28, 2024 at 11:03:45AM +0300, Feodor wrote:
> but the combination CTRL+Tab doesn't work for "escape" command for
> screen. Instead I get ";5;9~" printed after the prompt when I press
> CTRL+Tab.

Can you post the actual configuration you're using? I haven't used GNU
Screen as my daily-driver in some time and no longer have to my original
configuration files, but when I had Ctrl+(Shift)+Tab setup in Screen, I
think I used "bind" and/or "bindkey" i.e. 
.

Eric

Re: [dev] [st] question about keyboard shortcuts

[Feodor]

2024.06.27 14:51 Steve Ward wrote:
On Thu, Jun 27, 2024 at 6:47 AM Feodor  
wrote:


Is it possible to intercept CTRL+TAB and send another character?

I need to make CTRL+TAB keyboard combination for GNU screen "escape"
command, but TAB is CTRL-I in VT100 mode which most terminals use, so
there is no
way to modify that further with CTRL. So I need to make st intercept
CTRL+TAB as another character.
Is this possible? Maybe with some patch?



I've used xcape and sxhkd with some success in mapping modifier keys,
however in a different situation from yours.

https://github.com/alols/xcape
https://github.com/baskerville/sxhkd


Eric, do you confirm that I have to use sxhkd and xcape?

Re: [dev] [dmenu] What's the expected behavior on invalid utf8?

[Hiltjo Posthuma]

Hi NRK,

On Thu, Jul 04, 2024 at 03:04:42AM +, NRK wrote:
> Hello all,
> 
> A couple days ago I was looking into how dmenu deals with invalid utf8
> sequences and noticed a couple odd things. Here's the testcase for those
> who want to follow along:
> 
>   $ printf "0\xef1234567\ntest" | dmenu
> 
> In drw.c::utf8decode(), invalid utf8 sequence is set to U+FFFD (�) and
> drw_text continues on doing it's width calculation as if there was a
> U+FFFD codepoint in the text.
> 
> However when it comes to actually rendering the text via
> XftDrawStringUtf8(), we simply pass it `utf8str`; which obviously
> doesn't have any U+FFFD but instead has invalid utf8 sequences.
> 
> I'm not sure if this is documented or not, but on my system xft
> basically just cuts the text off at the error. In other words, only 0 is
> rendered, followed by a large blank area (see pic0.png).
> 
> Is this actually the expected behavior? If yes, then why not break out
> early on error instead of calculating width with a made up U+FFFD which
> will never be rendered?
> 
> I have a rough patch which actually renders invalid utf8 as � instead of
> cutting it off (see pic1.png). IMO it's a nicer behavior. But I wanted
> to ask what everyone else expects before polishing the patch and sending
> it over.
> 
> I also noticed that in utf8decode() there's this line:
> 
>   if (j < len)
>   return 0;
> 
> Is this ever reachable? If yes, wouldn't it be a infinite loop since
> `text` would never advance inside drw_text()?
> 
> - NRK

It should indeed be the replacement character. I'd be interested to review the
patch.

Thank you,

-- 
Kind regards,
Hiltjo

Re: [dev] [dmenu] What's the expected behavior on invalid utf8?

[Страхиња Радић]

Дана 24/07/04 11:32AM, GMD Ephir написа:
> I'm pretty sure that this is how it should be done, so I recommend
> you to send this patch to "hackers" mailing list.

I second this, there certainly is no harm in sending the patch to 
hackers@.

Re: [dev] [dmenu] What's the expected behavior on invalid utf8?

[GMD Ephir]

On Thu, Jul 04, 2024 at 03:04:42AM +, NRK wrote:
> Hello all,
> 
> A couple days ago I was looking into how dmenu deals with invalid utf8
> sequences and noticed a couple odd things. Here's the testcase for those
> who want to follow along:
> 
>   $ printf "0\xef1234567\ntest" | dmenu
> 
> In drw.c::utf8decode(), invalid utf8 sequence is set to U+FFFD (�) and
> drw_text continues on doing it's width calculation as if there was a
> U+FFFD codepoint in the text.
> 
> However when it comes to actually rendering the text via
> XftDrawStringUtf8(), we simply pass it `utf8str`; which obviously
> doesn't have any U+FFFD but instead has invalid utf8 sequences.
> 
> I'm not sure if this is documented or not, but on my system xft
> basically just cuts the text off at the error. In other words, only 0 is
> rendered, followed by a large blank area (see pic0.png).
> 
> Is this actually the expected behavior? If yes, then why not break out
> early on error instead of calculating width with a made up U+FFFD which
> will never be rendered?
> 
> I have a rough patch which actually renders invalid utf8 as � instead of
> cutting it off (see pic1.png). IMO it's a nicer behavior. But I wanted
> to ask what everyone else expects before polishing the patch and sending
> it over.
> 
> I also noticed that in utf8decode() there's this line:
> 
>   if (j < len)
>   return 0;
> 
> Is this ever reachable? If yes, wouldn't it be a infinite loop since
> `text` would never advance inside drw_text()?
> 
> - NRK

I'm pretty sure that this is how it should be done, so I recommend you to send 
this
patch to "hackers" mailing list.

If you are still in doubt whether you need to send this patch, please,
send it to this discussion. Personally, I would use this.

-- 
Gracefully, Ephir

[dev] [dmenu] What's the expected behavior on invalid utf8?

[NRK]

Hello all,

A couple days ago I was looking into how dmenu deals with invalid utf8
sequences and noticed a couple odd things. Here's the testcase for those
who want to follow along:

$ printf "0\xef1234567\ntest" | dmenu

In drw.c::utf8decode(), invalid utf8 sequence is set to U+FFFD (�) and
drw_text continues on doing it's width calculation as if there was a
U+FFFD codepoint in the text.

However when it comes to actually rendering the text via
XftDrawStringUtf8(), we simply pass it `utf8str`; which obviously
doesn't have any U+FFFD but instead has invalid utf8 sequences.

I'm not sure if this is documented or not, but on my system xft
basically just cuts the text off at the error. In other words, only 0 is
rendered, followed by a large blank area (see pic0.png).

Is this actually the expected behavior? If yes, then why not break out
early on error instead of calculating width with a made up U+FFFD which
will never be rendered?

I have a rough patch which actually renders invalid utf8 as � instead of
cutting it off (see pic1.png). IMO it's a nicer behavior. But I wanted
to ask what everyone else expects before polishing the patch and sending
it over.

I also noticed that in utf8decode() there's this line:

if (j < len)
return 0;

Is this ever reachable? If yes, wouldn't it be a infinite loop since
`text` would never advance inside drw_text()?

- NRK

Re: [dev] [st] question about keyboard shortcuts

[Steve Ward]

On Thu, Jun 27, 2024 at 6:47 AM Feodor  wrote:
>
> Is it possible to intercept CTRL+TAB and send another character?
>
> I need to make CTRL+TAB keyboard combination for GNU screen "escape"
> command, but TAB is CTRL-I in VT100 mode which most terminals use, so
> there is no
> way to modify that further with CTRL. So I need to make st intercept
> CTRL+TAB as another character.
> Is this possible? Maybe with some patch?
>

I've used xcape and sxhkd with some success in mapping modifier keys,
however in a different situation from yours.

https://github.com/alols/xcape
https://github.com/baskerville/sxhkd

Re: [dev] [st] question about keyboard shortcuts

[Feodor]

Eric Pruitt писал(а) 2024.06.28 00:12:

On Thu, Jun 27, 2024 at 12:39:07PM -0400, Greg Reagle wrote:

Note that I have not actually tried this and I am no expert on the
topic.  You might want to update the terminfo database too?


I can confirm that will work. It's what I use in my st configuration:
https://github.com/ericpruitt/emus/blob/3a5b62e2f1674f2ee1e5c39b758fe23f6e529301/desktop-environment/st-config.h#L247

Eric


Thanks for your reply, Eric.
I added
{ XK_Tab,   ControlMask,"\033[27;5;9~",  0,0},
to "static Key key[] = {" section, and prescribed
escape ^[[27;5;9~
in my ~/.screenrc, but the combination CTRL+Tab doesn't work for 
"escape" command for screen. Instead I get ";5;9~" printed after the 
prompt when I press CTRL+Tab.

Re: [dev] [st] question about keyboard shortcuts

[Eric Pruitt]

On Thu, Jun 27, 2024 at 12:39:07PM -0400, Greg Reagle wrote:
> Note that I have not actually tried this and I am no expert on the
> topic.  You might want to update the terminfo database too?

I can confirm that will work. It's what I use in my st configuration:
https://github.com/ericpruitt/emus/blob/3a5b62e2f1674f2ee1e5c39b758fe23f6e529301/desktop-environment/st-config.h#L247

Eric

Re: [dev] [st] question about keyboard shortcuts

[Greg Reagle]

On Thu, Jun 27, 2024, at 6:46 AM, Feodor wrote:
> Is it possible to intercept CTRL+TAB and send another character?
>
> I need to make CTRL+TAB keyboard combination for GNU screen "escape" 
> command, but TAB is CTRL-I in VT100 mode which most terminals use, so 
> there is no
> way to modify that further with CTRL. So I need to make st intercept 
> CTRL+TAB as another character.
> Is this possible? Maybe with some patch?

Ctrl+Tab can be represented by:
^[[27;5;9~
Look at this line is st's config.def.h as a template:
{ XK_ISO_Left_Tab,  ShiftMask,  "\033[Z",0,0},
Therefore add something like:
{ XK_ISO_Left_Tab,  ControlMask,  "\033[27;5;9~,0,0},
AND/OR
{ XK_Tab,  ControlMask,  "\033[27;5;9~,0,0},
I do not know the difference between XK_ISO_Left_Tab and XK_Tab.

Note that I have not actually tried this and I am no expert on the topic.  You 
might want to update the terminfo database too?

I found the information at 
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Alt-and-Meta-Keys.

[dev] [st] question about keyboard shortcuts

[Feodor]

Is it possible to intercept CTRL+TAB and send another character?

I need to make CTRL+TAB keyboard combination for GNU screen "escape" 
command, but TAB is CTRL-I in VT100 mode which most terminals use, so 
there is no
way to modify that further with CTRL. So I need to make st intercept 
CTRL+TAB as another character.

Is this possible? Maybe with some patch?

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

[Greg Reagle]

On Tue, Jun 25, 2024, at 5:00 PM, Anselm Garbe wrote:
> I wonder why you didn't look into golang.

Garbage collection.  For a "better C" I don't want garbage collection.  And if 
I am going to use a higher level language that *does* have garbage collection, 
Go has not impressed me so far.  I'd rather use a higher level language.  
Admittedly, I don't know a lot about Go and haven't tried to program in it.

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

[Pedro Lucas Porcellis]

On Fri Jun 21, 2024 at 11:45 AM -03, Greg Reagle wrote:
> I have looked into numerous language:  Rust, Pascal, Ada, V, Hare,
> Zig, D, and others I am probably forgetting.  I have not become an
> expert in these languages but read tutorials.  And I have written
> small programs (like cal) in a few.

Of all languages presented here, Hare standout as one of the most close
linked to C. It is a language that is designed to be a better C, with
some of the features of C++ and Rust. While keeping the simplicity of C
and (intended) to have a very small and simple footprint/design too.
Golang is another language that is designed to be a better C, but it is
a bit bigger and more complex than Hare and has a wider ecosystem.

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

[Anselm Garbe]

Hi there,

On Fri, Jun 21, 2024 at 8:21 AM Greg Reagle  wrote:
> I have looked into numerous language:  Rust, Pascal, Ada, V, Hare, Zig, D, 
> and others I am probably forgetting.  I have not become an expert in these 
> languages but read tutorials.  And I have written small programs (like cal) 
> in a few.

I wonder why you didn't look into golang.

Best regards,
Anselm

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

[Greg Minshall]

NRK  wrote:

> 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 building better "primitives"
> instead of changing language - which comes with significant cost such as
> having to adapt to new tooling, new ecosystem (which are almost always
> significantly less mature than C) and so on.

i guess my native language would be C.

for some recent project i ran into:

https://github.com/glouw/ctl

"C template library".  (i don't really know C++'s 'stl', so i can't
compare).  but, i found this (mostly moribund) project, once i sort of
figured out how to use of it, a fairly pleasant straight-jacket into
which to fit while coding in C.

cheers, Greg

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

[Sergei Grechanik]

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 charset. Apparently, this is possible if
the pattern is nonsensical, in my case, the pattern was something like
this (simplified):

JetBrainsMonoNerdFontMono:charset=2807:lang=und-zsye,en

U2807 is a Braille character, for which st needed a fallback. The
lang=und-zsye is for emojis. This combination confused fontconfig and
it returned 'Noto Color Emoji', which doesn't contain Braille
characters (although I still find it strange that fontconfig doesn't
prioritize the charset).
I propose two possible solutions for this:

1) Fix the pattern. "lang=und-zsye" was added to the pattern by a call
to FcConfigSubstitute. On my system there are some fontconfig rules
that eventually add emoji fonts to every pattern. Although these rules
may be buggy, other applications were not affected, indicating that st
does something differently. I think the difference is that it calls
FcConfigSubstitute twice: the first time when it searches for the main
font and the second time when it searches for the fallback font. It's
the second call that makes the pattern nonsensical. My guess is that
calling it twice is not correct. This patch removes the second call
and fixes the issue:

diff --git a/x.c b/x.c
index bd23686..639b06b 100644
--- a/x.c
+++ b/x.c
@@ -1330,8 +1330,6 @@ xmakeglyphfontspecs(XftGlyphFontSpec *specs,
const Glyph *glyphs, int len, int x
fccharset);
FcPatternAddBool(fcpattern, FC_SCALABLE, 1);

-   FcConfigSubstitute(0, fcpattern,
-   FcMatchPattern);
FcDefaultSubstitute(fcpattern);

fontpattern = FcFontSetMatch(0, fcsets, 1,


2) Explicitly verify whether the fallback font contains the character
(I think, xterm does something like this). Please find the patch in
the attachment.

Please consider applying one or both of these patches to the mainline
(or addressing the issue in some other way). Note that I have no prior
experience with fontconfig, so I don't really know what I'm doing, and
the patches may require some modifications.
From 1420a2218d5f65c4bf76a0390be58fe9ec89a6aa Mon Sep 17 00:00:00 2001
From: Sergei Grechanik 
Date: Mon, 10 Jun 2024 20:16:58 -0700
Subject: [PATCH] Check if the fallback font actually contains the char

For some reason FcFontSetMatch may return a font that doesn't contain
the character specified via the charset. This commit works around this
by calling FcFontSort instead and then trying the fonts one by one until
we find a font that actually contains the character.
---
 x.c | 41 -
 1 file changed, 28 insertions(+), 13 deletions(-)

diff --git a/x.c b/x.c
index bd23686..84cc0ae 100644
--- a/x.c
+++ b/x.c
@@ -128,7 +128,6 @@ typedef struct {
 	short lbearing;
 	short rbearing;
 	XftFont *match;
-	FcFontSet *set;
 	FcPattern *pattern;
 } Font;
 
@@ -966,7 +965,6 @@ xloadfont(Font *f, FcPattern *pattern)
 		(const FcChar8 *) ascii_printable,
 		strlen(ascii_printable), );
 
-	f->set = NULL;
 	f->pattern = configured;
 
 	f->ascent = f->match->ascent;
@@ -1055,8 +1053,6 @@ xunloadfont(Font *f)
 {
 	XftFontClose(xw.dpy, f->match);
 	FcPatternDestroy(f->pattern);
-	if (f->set)
-		FcFontSetDestroy(f->set);
 }
 
 void
@@ -1251,9 +1247,9 @@ xmakeglyphfontspecs(XftGlyphFontSpec *specs, const Glyph *glyphs, int len, int x
 	FT_UInt glyphidx;
 	FcResult fcres;
 	FcPattern *fcpattern, *fontpattern;
-	FcFontSet *fcsets[] = { NULL };
 	FcCharSet *fccharset;
-	int i, f, numspecs = 0;
+	FcFontSet *candidatefonts;
+	int i, j, f, numspecs = 0;
 
 	for (i = 0, xp = winx, yp = winy + font->ascent; i < len; ++i) {
 		/* Fetch rune and mode for current glyph. */
@@ -1310,11 +1306,6 @@ xmakeglyphfontspecs(XftGlyphFontSpec *specs, const Glyph *glyphs, int len, int x
 
 		/* Nothing was found. Use fontconfig to find matching font. */
 		if (f >= frclen) {
-			if (!font->set)
-font->set = FcFontSort(0, font->pattern,
-   1, 0, );
-			fcsets[0] = font->set;
-
 			/*
 			 * Nothing was found in the cache. Now use
 			 * some dozen of Fontconfig calls to get the
@@ -1334,8 +1325,32 @@ xmakeglyphfontspecs(XftGlyphFontSpec *specs, const Glyph *glyphs, int len, int x
 	FcMatchPattern);
 			FcDefaultSubstitute(fcpattern);
 
-			fontpattern = FcFontSetMatch(0, fcsets, 1,
-	fcpattern, );
+			/* FcFontSetMatch may return a font that doesn't contain
+			 * the character we are looking for. Sort the font set
+			 * instead and use the first one that contains the
+			 * character or the first font if none contains it.
+			 */
+			candidatefonts =
+FcFontSort(0, fcpattern, 1, 0, );
+			

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

[Vincent Lefevre]

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 string length which allows expressing string
>   operations much more naturally (read: less error prone).
> * Zero copy sub-string. This is a huge one, because it avoids many
>   spurious copies and/or allocations.

This is OK if your string is constant. Otherwise, this may be
dangerous, e.g. in case the full string is changed in place.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Jeremy]

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 what you might call "safety and ease issues."  I am not comparing C 
> to garbage-collected languages because they are different domains.  I am 
> comparing to other compiled and high-performance languages that lack garbage 
> collection.

What if C & Rust were in different domains? For example
- C is a language designed to describe how to operate on a fixed
address space
- Rust is a macro preprocessor & type system that allows you
to generate code by providing a minimal set of trait & lifetime
constraints

In this case, saying "C lets you overflow a buffer" is like saying "Rust lets
you write types that do way too much behind the scenes".

Given that the implementing the right data structures are a significant
part of what makes an application performant, I don't think there's a
replacement for C.

You might say "alternatives to grep: awk, ripgrep... ripgrep can browse
the whole filesystem using multiple threads. awk can add" but wants to
write '/' everytime they write a regex? sometimes I just want to run a
single regex over a stream of input.

I wish Rust would have stuck with persuing being a safe language. 
You can still overflow the stack. You can still go OOM.
There's nothing novel.

Lifetimes in rust was a cool idea to see implemented, but I really
wish they'd gotten weird with it. Imagine Lifetimes for stuff on
the stack. Then "yeild" is no-cost. Modern-day Coroutines(rhymes with
Goroutines, which upsets some people). Everything's recursive now because
who gives a shit - you don't have a stack to blow out because you've got
"stack-safety" too. Oops, forgot something: files have a lifetime beyond
the scope of main. Program doesn't compile if the file doesn't exist on
the FS. We only support NixOS now. DNS resolution is now free since it
happens at compile time. don't run the program after DNS expiration. it's
undefined behavior.

Jeremy

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

[Mattias Andrée]

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 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
> > > himself will be able to see at the very first glance that the function
> > > is returning a boolean value. If I make a function return an int, that
> > > is not so clear.  
> > 
> > Expressiveness is great, but _Bool is more than just an expression of
> > intent. If _Bool was nothing more than a typedef of int, it would be great.
> > 
> > However, in the real world, I also find that boolean isn't expressive enough
> > and enum is needed. This is because people do silly things like returning
> > true or false, without it being obvious that the function should even return
> > anything at all,  
> 
> Doesn't the function having a return type make it obvious that it returns 
> something?

Yes, but apart from that. If you just look at the name, 

> 
> > do indicate for example if the function was successful,
> > or the action was completed or need to be made again, or if the action
> > modified the stated (could be true if the state was not modified or true
> > if the state was not modified).  
> 
> If I have a function like "bool is_cromulent(foo)", I'd expect it to return
> true when foo IS cromulent (or 1 if the return type is int).
> Are you saying it should return cromulence_t with values either
> IS_CROMULENT or IS_NOT_CROMULENT?

No, I'm talking about bad code.

What would you expect "bool applyConfiguration(conf)" to return?

Maybe it returns true on success and false on failure.
Maybe it returns true the state was modified and false otherwise.

> 
> > > [...] Not so long ago, this very list opined that C89 is the only true
> > > C standard [...]  
> 
> If there was a new poll, I demand a recount!
> 

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

[Randy Palamar]

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 strings/fat pointers and
learning about Arenas I have used them in every project I have
written. Both of these techniques lead to faster code with fewer
bugs and usually in less total lines.

> (Do note that this "style" of C programming quite different to the
> suckless one, so I wouldn't be surprised if it generates some
> "backlash".)

In my view the suckless "style" on the aforementioned page is
entirely dogma and should be ignored. To me the only thing that
matters is writing code which minimizes the amount of end user
time waste (both in terms of runtime and lost time to bugs/poor
usability). As far as I can tell not a single item in the suckless
"style" serves towards meeting this goal.

> Region based memory management
> --
> [...]
> You can make many of them and then discard them all in one call.
> 

Why even bother with making a call? Usually I partition my Arenas
at startup into permanent and temporary parts. The temporary part
gets passed around on the stack and is thus reset when the scope
exits. For example a "frame allocator":

Arena frame_storage = new_arena(size); /* or from the bulk arena at startup */
while (!ctx->window_should_close) {
do_work(ctx, frame_storage);
/* any allocations made in frame_storage are discarded
 * when the loop restarts */
}

In this way it is completely free* (I'm sure you know this NRK).
Of course this involves passing structs around by value which I'm
sure is not suckless approved but it makes literally no difference
to the CPU unless the struct's size is very big (Arenas can be
done in 16 bytes which is small compared to the 64 byte vector
registers on newish CPUs).

* May involve a stack pointer move if for whatever reason
  frame_storage was not passed in through a register.

- Randy

-- 
https://rnpnr.xyz/
GPG Fingerprint: B8F0 CF4C B6E9 415C 1B27 A8C4 C8D2 F782 86DF 2DC5


signature.asc
Description: PGP signature

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

[NRK]

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 building better "primitives"
instead of changing language - which comes with significant cost such as
having to adapt to new tooling, new ecosystem (which are almost always
significantly less mature than C) and so on.

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.

(Do note that this "style" of C programming quite different to the
suckless one, so I wouldn't be surprised if it generates some
"backlash".)

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 string length which allows expressing string
  operations much more naturally (read: less error prone).
* Zero copy sub-string. This is a huge one, because it avoids many
  spurious copies and/or allocations.
* Unifies "strings" and "memory blobs", and so the various string
  functions you will build can be reused on memory blobs with embedded
  nul bytes.

The most important thing to note here is that there is no "capacity"
member. The string does not - and should not - be tangled with
allocation details as that will be handled below.

(I've also mostly been using signed sizes as they get rid of many
unnecessary signed vs unsigned mixing altogether and have more intuitive
behavior around 0. The same reason why Go uses signed sizes:
https://github.com/golang/go/issues/27460#issuecomment-418203686)


Region based memory management
--

The idea is very simple: instead of managing each allocation
individually, you group allocation by their lifetime instead.
https://en.wikipedia.org/wiki/Region-based_memory_management

E.g: if you build a tree where each node is `malloc`-ed then to free the
tree, you'd need to traverse it and free everything individually. With
region based scheme, you'd simply free the entire region. No traversal
needed.

// allocating node on a region
for (...) {
Node *np = alloc_node(_arena);
// ...
}
// free-ing the entire tree
free_arena(_arena);

The tree example is a bit niche but the this scheme is much more
impactful for temporary allocations. You can make many of them and then
discard them all in one call.

checkpoint = arena_snapshot();
int *p = alloc(, int, 32);
int *q = alloc(, int, 64);
if (rand() & 0x1) float *v = alloc(, float, 128); // silly demo
// do "work"
// ...
arena_reset(, checkpoint); // frees all allocation made inside 
of `scratch` since `checkpoint` was captured


Example and resources
-

For a real world example of these techniques, I recommend looking at
u-config:

https://github.com/skeeto/u-config
https://nullprogram.com/blog/2023/01/18/#u-config-implementation 
(implementation notes)

It's a `pkg-config` replacement which requires a quite a heavy bit of
string manipulation. If you were to implement this using nul-strings
you'd be in a lot of pain. But using sized strings and an arena
allocator u-config code is fairly easy to hack on and also very robust
(it withstands hours of fuzz-testing without any buffer overflows).

This this has gotten pretty big already, I'll drop a couple resources
for those who are interested:

On arena allocators:
* https://nullprogram.com/blog/2023/09/27/  (practical tips and tricks)
* https://www.rfleury.com/p/untangling-lifetimes-the-arena-allocator  (a bit 
more theoretical)
Other allocator schemes (niche, but can be useful depending on the situation)
* https://floooh.github.io/2018/06/17/handles-vs-pointers.html
  (generational handles when you have truly dynamic lifetimes that cannot
  be expressed using an arena)
* https://www.gingerbill.org/series/memory-allocation-strategies/
  (pool & buddy allocator. pretty niche, but good to be aware of in case
  they happen to be a good fit for your problem.)
Rants:
* https://www.youtube.com/watch?v=f4ioc8-lDc0=4482s (against
  overcomplicated memory management solutions that stems of "single
  element thinking").
* https://www.symas.com/post/the-sad-state-of-c-strings
* https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/

- NRK

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

[stefan11111]

Î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 even suggested for removal)
>   https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm
>- C23: nullptr{_t,}, true/false, _BigInt, "C++ compatibility" - just no.
>   https://harmful.cat-v.org/software/c++/
>
>The overarching trend seems to be that C is gradually turning into C++ 
>lite with all the keywords, attributes, etc. There's no need for any of 
>that.
>

Imo, the "new" C standard smells c++.
At this rate, we might even see class
become a keyword in C.

I see no reason to add even more keywords and
types that nobody asked for(nullptr/nullptr_t).
Some, like true and false can break existing
code which already uses those as
variables/functions.

As someone else said in this thread, maybe the
worst addition is the fact that void foo() is now
the same as void foo(void), which was a very
useful feature.

However, even worse IMO is the fact that gcc
devs have started breaking perfectly good code
since gcc14.
-- 
Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-7400_CPU_@_3.00GHz

COMMON_FLAGS="-O3 -pipe -march=native -ftree-vectorize -ffast-math 
-funswitch-loops -fuse-linker-plugin -flto -fdevirtualize-at-ltrans -fno-plt 
-fno-semantic-interposition -falign-functions=64 -fgraphite-identity 
-floop-nest-optimize"

USE="-* git verify-sig rsync-verify man alsa X grub ssl ipv6 lto libressl 
olde-gentoo asm native-symlinks threads jit jumbo-build minimal strip 
system-man"

INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd 
/usr/lib/modules-load.d /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /lib/udev 
/usr/share/icons /usr/share/applications /usr/share/gtk-3.0/emoji 
/usr/lib64/palemoon/gtk2"

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

[Storkman]

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:
> 
> https://lists.suckless.org/dev/2104/34265.html
> 
> 
> * * *
> 
> Rust sucks. It was made by Big Tech (Mozilla) and aggressively 
> advertised as a replacement for C. There are numerous "replacements" 
> for Unix tools rewritten in Rust, all following the same "mainstream 
> dev" pattern.

Rust appears to be the number one largest programming language package
in Gentoo, with a 314MB download (155MB for the binary version).
GHC is probably second place, at 147MB, unless you count LLVM and Clang
together, which would be 250MB.
I'm sure it's this big for a very good reason, but when compiling a compiler
takes all day, and then it crashes because it ran out of RAM or hard disk
space or whatever, it just makes me a bit sad.

> C needs no replacement. C is a mature, standardized language (unlike 
> Rust), tightly intertwined with Unix and Unix-like systems as described 
> by POSIX.

It would be nice, though. I'm generally in favor of having more good things.

> Pascal is a language tailored for introductory level programming. It 
> was used in high school and freshman university courses here in the 
> late 90s and early 2000s. I don't know of any examples of serious 
> software written in Pascal.

The original Pascal as conceived by Niklaus Wirth in 1970 is worth
checking out, if you're interested in computing history. Maybe.
Most "serious" Pascal software is probably actually written in Delphi,
an object-oriented GUI-equipped dialect created by Borland.
Check out FreePascal if the idea of writing C++ with one hand tied behind
your back sounds appealing to you.

> Ada was already mentioned in your previous thread that I linked above, 
> as an alternative to Rust if one cares about "safe" languages. It was a 
> heavily extended version of Pascal made for the use of USAF.

Ada is theoretically interesting, but I think enjoying using it requires
a very specific type of personality. Check it out if you get a thrill from
filing out tax forms.

> * * *
> 
> Safety is overrated. The more "safe" a language is, the less it can do. 
> The more the programmer is "protected" from "shooting himself in the 
> foot", the less control he has over the program. The most powerful 
> language is assembler/machine code, and C is very close.
> 

-- 
Storkman

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

[Storkman]

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?  
> > 
> > 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 value. If I make a function return an int, that
> > is not so clear.
> 
> Expressiveness is great, but _Bool is more than just an expression of
> intent. If _Bool was nothing more than a typedef of int, it would be great.
> 
> However, in the real world, I also find that boolean isn't expressive enough
> and enum is needed. This is because people do silly things like returning
> true or false, without it being obvious that the function should even return
> anything at all,

Doesn't the function having a return type make it obvious that it returns 
something?

> do indicate for example if the function was successful,
> or the action was completed or need to be made again, or if the action
> modified the stated (could be true if the state was not modified or true
> if the state was not modified).

If I have a function like "bool is_cromulent(foo)", I'd expect it to return
true when foo IS cromulent (or 1 if the return type is int).
Are you saying it should return cromulence_t with values either
IS_CROMULENT or IS_NOT_CROMULENT?

> > [...] Not so long ago, this very list opined that C89 is the only true
> > C standard [...]

If there was a new poll, I demand a recount!

-- 
Storkman

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 value. If I make a function return an int, that
> is not so clear.

Maybe a "junior dev" who learned to program in Java or C# would only be 
able to see it if _Bool was used instead of int, but the rest of the 
world is (idiomatically and intuitively - knowing that logical type in 
C is int and how it is usually used, aside from deducing from the name 
of the function itself) going to have no problem understanding that

int isalpha(int c);

returns 0 if the parameter c is not a letter, and !=0 otherwise, and 
that it perfectly plugs into if-constructs:

if (!isalpha(s[i]))
// ...

This is one of those places where C is closer to machine code/assembler 
than, say, level of abstraction (obscurity) of Pascal or Java.


> 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 even suggested for removal)
   https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm
- C23: nullptr{_t,}, true/false, _BigInt, "C++ compatibility" - just no.
   https://harmful.cat-v.org/software/c++/

The overarching trend seems to be that C is gradually turning into C++ 
lite with all the keywords, attributes, etc. There's no need for any of 
that.

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

[Mattias Andrée]

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 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 value. If I make a function return an int, that
> is not so clear.

Expressiveness is great, but _Bool is more than just an expression of
intent. If _Bool was nothing more than a typedef of int, it would be great.

However, in the real world, I also find that boolean isn't expressive enough
and enum is needed. This is because people do silly things like returning
true or false, without it being obvious that the function should even return
anything at all, do indicate for example if the function was successful,
or the action was completed or need to be made again, or if the action
modified the stated (could be true if the state was not modified or true
if the state was not modified).

> 
> That said, if a function returns bool and is longer than one or two
> statements, it is probably already doing something wrong. I have seen
> bool used as error code, and it is such a missed opportunity to return
> an enum of error codes to say what actually went wrong.
> 
> > Every new iteration of C after C99 introduced more unnecessary cruft.
> > C99 is the best version, although it has its rough edges, one of which
> > is the _Bool type.
> >  
> 
> All versions of C after C89 added more stuff that wasn't there before.
> That is mostly the point. You cannot remove things without introducing
> an incompatibility. So the only thing I can remember that was ever
> removed was gets(), which was a bad idea from the start, and finally
> removed in C11.
> 
> I don't know, to me statements like "C99 is the best version" are always
> funny. Not so long ago, this very list opined that C89 is the only true
> C standard and everything that came after is "not C", as I recall. Which
> is literally wrong, of course (C is whatever WG14 says it is, whether
> you like it or not).
> 
> Isn't it all about familiarity in the end? Or can you articulate what
> parts of C11 and C23 you find objectionable?

C99 added a lot of good features. And just a couple of questionable features:
//, , and intermingled declarations and code. So this was a very good
improvement

C95 added digraphs, , and the not-too-well-designed  and
, which aren't that commonly used; so while making some
improvements, this wasn't the best of improvements.

I think C11 really brought some nice improvements, but you don't need them too
often, so C99 is often enough: _Aliasas, _Alignof, aligned_alloc, _Thread_local,
_Atomic, anonymous nested structs and unions, _Generic. It also adds a lot of
things that I could take or leave. There's nothing to objectionable in C11, even
if things code be better designed.

C17 only addressed defects in C11, so this version is completely 
non-objectionable.

C23 really does add some nice things that have been missing, but most often them
don't actually have to be a part of C. One thing I really do like about C23 is
__VA_OPT__. I don't see with we need nullptr, nullptr_t and _BigInt looks like a
big design blunder. I find changing the meaning of the auto keyword, and to a
lesser extent making true, false, alignas, alignof, bool, static_assert, and
thread_local keywords, objectionable. While not technically objectionable, I
personally find the [[ ]]-syntax for attributes unstylish. But worst of all 
might
be making `int foo()` equivalent to `int foo(void)`.

> 
> Ciao,
> Markus
> 

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

[Markus Wichmann]

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
himself will be able to see at the very first glance that the function
is returning a boolean value. If I make a function return an int, that
is not so clear.

That said, if a function returns bool and is longer than one or two
statements, it is probably already doing something wrong. I have seen
bool used as error code, and it is such a missed opportunity to return
an enum of error codes to say what actually went wrong.

> Every new iteration of C after C99 introduced more unnecessary cruft.
> C99 is the best version, although it has its rough edges, one of which
> is the _Bool type.
>

All versions of C after C89 added more stuff that wasn't there before.
That is mostly the point. You cannot remove things without introducing
an incompatibility. So the only thing I can remember that was ever
removed was gets(), which was a bad idea from the start, and finally
removed in C11.

I don't know, to me statements like "C99 is the best version" are always
funny. Not so long ago, this very list opined that C89 is the only true
C standard and everything that came after is "not C", as I recall. Which
is literally wrong, of course (C is whatever WG14 says it is, whether
you like it or not).

Isn't it all about familiarity in the end? Or can you articulate what
parts of C11 and C23 you find objectionable?

Ciao,
Markus

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 (Mozilla) and aggressively 
advertised as a replacement for C. There are numerous "replacements" 
for Unix tools rewritten in Rust, all following the same "mainstream 
dev" pattern.

C needs no replacement. C is a mature, standardized language (unlike 
Rust), tightly intertwined with Unix and Unix-like systems as described 
by POSIX.

Pascal is a language tailored for introductory level programming. It 
was used in high school and freshman university courses here in the 
late 90s and early 2000s. I don't know of any examples of serious 
software written in Pascal.

Ada was already mentioned in your previous thread that I linked above, 
as an alternative to Rust if one cares about "safe" languages. It was a 
heavily extended version of Pascal made for the use of USAF.

* * *

Safety is overrated. The more "safe" a language is, the less it can do. 
The more the programmer is "protected" from "shooting himself in the 
foot", the less control he has over the program. The most powerful 
language is assembler/machine code, and C is very close.

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

[Greg Reagle]

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 
Free Pascal Compiler (fpc).  By the way, I haven't tried the IDE or Lazarus, 
but I might later--right now I am just using vi editor and fpc command.  I 
really really like it.  It is not nearly as complicated as Rust or Ada.  The 
source code is very easy to read and understand if you know C or Ada or similar 
language.  It has quite a few safety and ease-of-use features that are very 
easy to use.  I especially like the compiler switches Co, CO, Cr, Ct, and gh.  
During development I use
fpc -Cort -gchlw -vewniq
Pascal has the great advantage of being very mature.  FPC supports several 
different dialects, some much simpler than others.

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 what you might call "safety and ease issues."  I am not comparing C 
to garbage-collected languages because they are different domains.  I am 
comparing to other compiled and high-performance languages that lack garbage 
collection.

I have looked into numerous language:  Rust, Pascal, Ada, V, Hare, Zig, D, and 
others I am probably forgetting.  I have not become an expert in these 
languages but read tutorials.  And I have written small programs (like cal) in 
a few.

Ada has a lot of nice safety features and it can also be fairly low level 
(specifying bits and bytes for storage).  However, it is very big (especially 
the later versions) and comprehensive and has a great deal of features.  It 
lacks simplicity (compared to C).

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).

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 question is what is the reasoning behind not using `bool` (or, 
more accurately, `_Bool`, since `bool` is a macro defined in stdbool.h) 
type in suckless coding style:

- The result of logical operators, such as !, &&, || and relational 
  operators, such as <, <=, >, >= is explicitly int in C99 anyway 
  (check the actual text of the standard if you don't believe me), with 
  possible values 0 and 1

- The type of `expression` in:

if (expression) statement
if (expression) statement else statement

  in C99 is "scalar" with value tested for 0 - if unequal, `statement`
  following `if` is executed, if equal, statement following `else` is
  executed.

Given that, why complicate code by introducing a separate, superfluous, 
type? Major compilers, such as GCC and Clang/LLVM, are competent enough 
to optimize for speed or size as needed anyway.

Every new iteration of C after C99 introduced more unnecessary cruft. 
C99 is the best version, although it has its rough edges, one of which 
is the _Bool type.

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

[sewn]

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 Boolean Values

* Do not use C99 bool types (stick to integer types).

* Otherwise use compound assignment and tests unless the line grows 
too long:


if (!(p = malloc(sizeof(*p
hcf();


Sure, but why?

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 raise. I searched
>> but did not locate any such patch. Is there perhaps, or could you
>> give me any advice on how to achieve this?
>  
> I'm not a regular user of DWM anymore, but I just rapidly tried with
> the last version and this feature seems to work. Maybe you have an
> outdated version (probably not, I think this has been there since
> 2009) or perhaps another patch is blocking this?
>  
> Regards.

In that case, a patch that I've added must have changed the behaviour
(about ten added). I'll try a stock installation of dwm to see.

Thank you.

[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 advice on how to achieve this?

Thank you

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

[Markus Wichmann]

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 portability, the existence of the macro could have
> also been tested with #ifdef, allowing a fallback.

Well, there is INT_LEAST${N}_MAX from stdint.h, telling you that type
int_least${n}_t exists. And C23 has the new _BitInt(N) types, if that
helps any.

Of course, you can also just face up to reality and notice that you will
likely never work on a machine with CHAR_BIT != 8, and even if you do,
it will be unlikely to have CHAR_BIT % 8 != 0. Therefore, any
int_least${n}_t with $n % 8 != 0 is unlikely to exist.

Ciao,
Markus

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

[NRK]

> 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 don't think this is a good idea at all. A huge majority of "fallback"
code I see in realworld are riddled with bugs - because no one tests
those path - and the more ifdefs you have the faster your software
becomes untestable because each ifdef increases the build combination by
an exponetial factor.

"But how can specifying minimum width lead to bugs"? Integer promotion
rules.

uint16_t a = UINT16_MAX;
uint16_t b = 1;
int c = a + b;   // what is the value of c ??

Is the value of `c` 0 due to unsigned wraparound? Or is it 2^16 because
of integer promotion? You don't know unless you know the rank and width
of `int` for that platform.

Any nontrivial software will contain thousands if not millions of
arithmetic operations. Trying to babysit each arithmetic operations for
"theoretical portability" is not only a massive waste of time, it's very
likely buggy as well unless you can actually test it.

So unless you know for certain that you will be targetting weird
machines and have the means to test on it: keep it simple and make
things *obviously correct* instead of overcomplicating things for
"theoretical portability".

- NRK

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

[Mattias Andrée]

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 over int. All common operations
> (this may exclude division and modulo) supported on int,
> by definition, that same is not true for char. Say for example
> that, want to check if the value is non-zero. Using it, this
> will probably entail performing some operation on the value
> and than duing a jump conditioned on a flag register. With
> more narrow types, this may (not the case on x86-64) require

The x86-64 instruction set doesn't require type promotion,
but the CPU may still require it, and although I'm not certain,
I think x86-64 CPU does perform type promotion in these
cases. It should at least be fair to say that less complex
CPU will do this to avoid implementing all different operations
for all the different type, and CPU's may also avoid it and instead
favour type promotion in order to improve parallellism.

> that value to first be promoted to int.
> 
> 
> On Sat, 15 Jun 2024 17:05:27 +0300
> stefan1  wrote:
> 
> > 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 couldn't sum of 
> > >_Bool's
> > >to find how many were set (commonly this we be to detect if more than 1 was
> > >set).
> > >
> > >It is implementation-define which signness _Bool has, meaning, I don't know
> > >if it will be promoted to a signed or an unsigned int.
> > >
> > >_Bool is only useful to make sure that a non-zero value is converted to the
> > >value 1. And if this is absolutely necessarily, you should make this 
> > >explicit,
> > >e.g. with `!!x` or `x?1:0`. _Bool can introduce implicit and unnecessary
> > >overhead to ensure that the value is always 1 or 0. And despite all this,
> > >you can mess up and get _Bool's with a non-boolean value.
> > >
> > >It is implementation-defined how wide a _Bool is.
> > >
> > >_Bool will be at least the size of a byte, if you really want it to be a 
> > >bit
> > >if you have many of them, you can use bit fields or good old names values 
> > >to
> > >store multiple boolean values in one int. Generally you don't gain any real
> > >savings by using a single byte type instead of an int if you only one or 
> > >two
> > >booleans.
> > >
> > >Basically, I like things to be explicit and well-defined.
> > >
> > >
> > >
> > >On Sat, 15 Jun 2024 11:54:02 +
> > >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 bools are 31 bits smaller 
> > >> than ints, which is 31 bits of memory saved. Not that 31 bits is very 
> > >> much, but still...
> > >> 
> > >
> > >
> >   
> 
> 

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 (stick to integer types).
>
> * Otherwise use compound assignment and tests unless the line grows too long:
>
> if (!(p = malloc(sizeof(*p
>   hcf();

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

[Vincent Lefevre]

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 specify
> [u]int_{least,fast}N_t for arbitrary N. It could be simple as
> libc having to enumerate all up to some N. But it's a bit silly
> that [u]int_{least,fast}N_t (expecially [u]int_leastN_t) exists
> only for 8, 16, 32, and 64, when the machine probably has integers
> with those exact widths anyways.

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 portability, the existence of the macro could have
also been tested with #ifdef, allowing a fallback.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Mattias Andrée]

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 as
libc having to enumerate all up to some N. But it's a bit silly
that [u]int_{least,fast}N_t (expecially [u]int_leastN_t) exists
only for 8, 16, 32, and 64, when the machine probably has integers
with those exact widths anyways.


On Sat, 15 Jun 2024 16:14:58 +0200
Vincent Lefevre  wrote:

> 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.
> 

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

[Mattias Andrée]

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) supported on int,
by definition, that same is not true for char. Say for example
that, want to check if the value is non-zero. Using it, this
will probably entail performing some operation on the value
and than duing a jump conditioned on a flag register. With
more narrow types, this may (not the case on x86-64) require
that value to first be promoted to int.


On Sat, 15 Jun 2024 17:05:27 +0300
stefan1  wrote:

> 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 couldn't sum of _Bool's
> >to find how many were set (commonly this we be to detect if more than 1 was
> >set).
> >
> >It is implementation-define which signness _Bool has, meaning, I don't know
> >if it will be promoted to a signed or an unsigned int.
> >
> >_Bool is only useful to make sure that a non-zero value is converted to the
> >value 1. And if this is absolutely necessarily, you should make this 
> >explicit,
> >e.g. with `!!x` or `x?1:0`. _Bool can introduce implicit and unnecessary
> >overhead to ensure that the value is always 1 or 0. And despite all this,
> >you can mess up and get _Bool's with a non-boolean value.
> >
> >It is implementation-defined how wide a _Bool is.
> >
> >_Bool will be at least the size of a byte, if you really want it to be a bit
> >if you have many of them, you can use bit fields or good old names values to
> >store multiple boolean values in one int. Generally you don't gain any real
> >savings by using a single byte type instead of an int if you only one or two
> >booleans.
> >
> >Basically, I like things to be explicit and well-defined.
> >
> >
> >
> >On Sat, 15 Jun 2024 11:54:02 +
> >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 bools are 31 bits smaller 
> >> than ints, which is 31 bits of memory saved. Not that 31 bits is very 
> >> much, but still...
> >>   
> >
> >  
> 

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

[Vincent Lefevre]

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: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[stefan11111]

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 couldn't sum of _Bool's
>to find how many were set (commonly this we be to detect if more than 1 was
>set).
>
>It is implementation-define which signness _Bool has, meaning, I don't know
>if it will be promoted to a signed or an unsigned int.
>
>_Bool is only useful to make sure that a non-zero value is converted to the
>value 1. And if this is absolutely necessarily, you should make this explicit,
>e.g. with `!!x` or `x?1:0`. _Bool can introduce implicit and unnecessary
>overhead to ensure that the value is always 1 or 0. And despite all this,
>you can mess up and get _Bool's with a non-boolean value.
>
>It is implementation-defined how wide a _Bool is.
>
>_Bool will be at least the size of a byte, if you really want it to be a bit
>if you have many of them, you can use bit fields or good old names values to
>store multiple boolean values in one int. Generally you don't gain any real
>savings by using a single byte type instead of an int if you only one or two
>booleans.
>
>Basically, I like things to be explicit and well-defined.
>
>
>
>On Sat, 15 Jun 2024 11:54:02 +
>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 bools are 31 bits smaller than 
>> ints, which is 31 bits of memory saved. Not that 31 bits is very much, but 
>> still...
>> 
>
>

-- 
Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-7400_CPU_@_3.00GHz

COMMON_FLAGS="-O3 -pipe -march=native -ftree-vectorize -ffast-math 
-funswitch-loops -fuse-linker-plugin -flto -fdevirtualize-at-ltrans -fno-plt 
-fno-semantic-interposition -falign-functions=64 -fgraphite-identity 
-floop-nest-optimize"

USE="-* git verify-sig rsync-verify man alsa X grub ssl ipv6 lto libressl 
olde-gentoo asm native-symlinks threads jit jumbo-build minimal strip 
system-man"

INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd 
/usr/lib/modules-load.d /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /lib/udev 
/usr/share/icons /usr/share/applications /usr/share/gtk-3.0/emoji 
/usr/lib64/palemoon/gtk2"

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

[Mattias Andrée]

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
set).

It is implementation-define which signness _Bool has, meaning, I don't know
if it will be promoted to a signed or an unsigned int.

_Bool is only useful to make sure that a non-zero value is converted to the
value 1. And if this is absolutely necessarily, you should make this explicit,
e.g. with `!!x` or `x?1:0`. _Bool can introduce implicit and unnecessary
overhead to ensure that the value is always 1 or 0. And despite all this,
you can mess up and get _Bool's with a non-boolean value.

It is implementation-defined how wide a _Bool is.

_Bool will be at least the size of a byte, if you really want it to be a bit
if you have many of them, you can use bit fields or good old names values to
store multiple boolean values in one int. Generally you don't gain any real
savings by using a single byte type instead of an int if you only one or two
booleans.

Basically, I like things to be explicit and well-defined.



On Sat, 15 Jun 2024 11:54:02 +
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 bools are 31 bits smaller than 
> ints, which is 31 bits of memory saved. Not that 31 bits is very much, but 
> still...
> 

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

[Pontus Stenetorp]

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 bools are 31 bits smaller than 
> ints, which is 31 bits of memory saved. Not that 31 bits is very much, but 
> still...

You may want to refer to a textbook or make an online search about that 
assumption. On every architecture I have worked with, it would be *at least* a 
byte.

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

[Zac]

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 of memory saved. Not that 31 bits is very much, but 
still...

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

[Greg Minshall]

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

[Greg Reagle]

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 you 
can do.  I am very pleased that I can choose whatever language I want.  If any 
of you want to collaborate or inquire I welcome your emails.

Here is a case in point:  
https://rosettacode.org/wiki/Word_wheel#No_metatables,_simple

And while I have your attention... What a great language Lua is!  Of course it 
is not for every purpose, but for a high-level interpreted language, it is the 
bee's knees.  Lua is a very loosey-goosey language, which has some 
disadvantages.  To make it a bit more "strict" and careful, I recommend 2 
tools: luacheck and penlight strict.  Luacheck is a command (available from 
LuaRocks) that checks the code like lint.  And when you have Penlight library 
installed (also from LuaRocks) you can add "-l pl.strict" to your lua command 
line.  Neither command requires any change at all to the Lua (source) file 
meaning they both work on standard plain Lua.

And as a bonus, I also recommend argcheck by geoffleyland (see LuaRocks) which 
enables type-checking of function parameters via comments, so that the Lua code 
works just fine with a standard Lua interpreter.

Re: [dev][Quark] Big problem

[Jeremy]

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 chroot" and then say when run as
root, "refusing to run as root". which makes me start to question things.

I did this instead:
curl https://raw.githubusercontent.com/emikulic/darkhttpd/master/darkhttpd.c |
cc -x c -o ./darkhttpd

And it works flawlessly and intinuitively. it does what I want to do
(`./darkhttpd ~/.local/bin`).

I sympathize with your socket connections closing unexpectedly.

Darkhttpd should work for your usecase on the Darkweb, without
the scheduler mangling all your socket connections. darkhttpd uses select
which I personally.  am against bc I struggle to ever remember which
arguments goes where, so actually I don't recommend  darkhttpd anymore.

So In closing, i prefer fork/dup for a lot of things, and the
Processses are just goroutines under the hood anyway & so Fork/dup
is light-weight.

Jeremy

On 02/26/23 03:36PM, fo...@dnmx.org wrote:
> By the way, are there connections being made to Quark that aren't logged,
> like some sort of silent handling?
> I am trying to come up with possible answer without reading code lol is fun.
> 
> Like how does it drop connection after only 3 connections? I restarted the
> jail, which is like a computer restart, memory should be reset..
> 
> 

[dev] slock: running svkbd at same time

[hazardchem]

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 presence on /rocks.

Re: [dev] piscou?

[Hiltjo Posthuma]

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 -Wno-unsafe-buffer-usage
>   clang: clean release
> 
> and
> 
>   piscou: $(src) $(headers) Makefile
>   -ctags --kinds-C=+l *.h *.c
>   -vtags.sed tags > .tags.vim
>   $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(src) $(ldlibs)
> 
> and doesn't even compile (tested on Artix Linux and OpenBSD). On 
> OpenBSD, I get:
> 
>   $ make
>   make: don't know how to make CFLAGS (prerequisite of: release)
>   Stop in /home/strajder/src/piscou
> 
> About the program itself, I think that something like nopen[2] from the 
> file manager noice[3] with its 103 LoC better represents the suckless 
> principles than piscou.
> 
> About the license, piscou uses the GNU Affero license, whose purpose 
> is[4]:
> 
> > The purpose of the GNU Affero GPL is to prevent a problem that 
> > affects developers of free programs that are often used on servers.
> [...]
> > But suppose the program is mainly useful on servers. When D modifies 
> > the program, he might very likely run it on his own server and never 
> > release copies. Then you would never get a copy of the source code of 
> > his version, so you would never have the chance to include his changes 
> > in your version. You may not like that outcome.
> >
> > Using the GNU Affero GPL avoids that outcome. If D runs his version on 
> > a server that everyone can use, you too can use it. 
> 
> in other words, it is intended for server software. piscou is supposed 
> to be an interactive program, possibly running a GUI previewer?
> 
> P.S: From the synopsis, the percent-signs
> 
>   piscou %piscou-filename% [%piscou-extra0% %piscou-extra1% ...]
> 
> don't seem to be literal, so the syntax is confusing. Looks like it is 
> taken from Microsoft's COMMAND.COM variable substitution?
> 
> I suggest removal.
> 
> [1]: 
> https://git.suckless.org/sites/commit/a540477f182ef370a7e2aa6ef850889b6b92bbfa.html
> [2]: https://git.codemadness.org/noice/file/nopen.c.html
> [3]: https://git.codemadness.org/noice/log.html
> [4]: https://www.gnu.org/licenses/why-affero-gpl.html
> 

Hi,

Have you reported this issue to the author of piscou?

-- 
Kind regards,
Hiltjo

[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
-ctags --kinds-C=+l *.h *.c
-vtags.sed tags > .tags.vim
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(src) $(ldlibs)

and doesn't even compile (tested on Artix Linux and OpenBSD). On 
OpenBSD, I get:

  $ make
  make: don't know how to make CFLAGS (prerequisite of: release)
  Stop in /home/strajder/src/piscou

About the program itself, I think that something like nopen[2] from the 
file manager noice[3] with its 103 LoC better represents the suckless 
principles than piscou.

About the license, piscou uses the GNU Affero license, whose purpose 
is[4]:

> The purpose of the GNU Affero GPL is to prevent a problem that 
> affects developers of free programs that are often used on servers.
[...]
> But suppose the program is mainly useful on servers. When D modifies 
> the program, he might very likely run it on his own server and never 
> release copies. Then you would never get a copy of the source code of 
> his version, so you would never have the chance to include his changes 
> in your version. You may not like that outcome.
>
> Using the GNU Affero GPL avoids that outcome. If D runs his version on 
> a server that everyone can use, you too can use it. 

in other words, it is intended for server software. piscou is supposed 
to be an interactive program, possibly running a GUI previewer?

P.S: From the synopsis, the percent-signs

  piscou %piscou-filename% [%piscou-extra0% %piscou-extra1% ...]

don't seem to be literal, so the syntax is confusing. Looks like it is 
taken from Microsoft's COMMAND.COM variable substitution?

I suggest removal.

[1]: 
https://git.suckless.org/sites/commit/a540477f182ef370a7e2aa6ef850889b6b92bbfa.html
[2]: https://git.codemadness.org/noice/file/nopen.c.html
[3]: https://git.codemadness.org/noice/log.html
[4]: https://www.gnu.org/licenses/why-affero-gpl.html

Re: [dev] less keys for w3m

[Greg Minshall]

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, etc.  And
> in case anyone wants to try it.

awesome -- thanks!

[dev] less keys for w3m

[Greg Reagle]

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 wants to try it.  
I did not do anything with Meta/Alt keys because some of them clash with my dwm 
keys.

I am fairly confident in my 1st through 3rd and 5th paragraphs.  I am not so 
confident in my 4th paragraph (w3m features not in less).  I tried to make it 
somewhat mnemonic and to keep similar functions on similar keys.  For example:
  x and X are NEXT and PREV
  t and T and C-t all deal with tabs
  p & P and o & O have similar functionality

Here it is following:

# w3m defaults incompatible with less, but fundamental to w3m and very 
convenient
keymap  C-j GOTO_LINK
keymap  h   MOVE_LEFT
keymap  j   MOVE_DOWN
keymap  k   MOVE_UP
keymap  l   MOVE_RIGHT

# w3m defaults not compatible with less
# ASCII hyphen-dash
keymap  -   SET_OPTION
keymap  <   BEGIN
keymap  >   END
keymap  C-b PREV_PAGE
keymap  C-e UP
keymap  C-f NEXT_PAGE
keymap  C-k DOWN
keymap  C-m UP
keymap  C-n UP
keymap  C-p DOWN
keymap  C-r REDRAW
keymap  C-y DOWN
keymap  DOWNUP
keymap  e   UP
keymap  E   LOAD
keymap  f   NEXT_PAGE
keymap  LEFTSHIFT_LEFT
keymap  m   MARK
keymap  r   REDRAW
keymap  RIGHT   SHIFT_RIGHT
keymap  s   SAVE_SCREEN
keymap  UP  DOWN
keymap  v   EDIT
keymap  V   VERSION
keymap  w   PREV_PAGE
keymap  y   DOWN
keymap  Y   DOWN
keymap  z   NEXT_PAGE
keymap  \'  NEXT_MARK
# underscore
keymap  _   OPTIONS

# w3m defaults already compatible with less
keymap  !   SHELL
keymap  /   SEARCH
keymap  =   INFO
keymap  ?   SEARCH_BACK
keymap  b   PREV_PAGE
keymap  C-g LINE_INFO
keymap  C-l REDRAW
keymap  C-s ISEARCH
keymap  C-t TAB_LINK
keymap  C-v NEXT_PAGE
keymap  C-z SUSPEND
keymap  g   BEGIN
keymap  G   END
keymap  H   HELP
keymap  J   UP
keymap  K   DOWN
keymap  n   SEARCH_NEXT
keymap  N   SEARCH_PREV
keymap  Q   EXIT
keymap  q   QUIT
keymap  R   RELOAD
keymap  SPC NEXT_PAGE
keymap  |   PIPE_BUF
#   Home key
keymap  M-[1~   BEGIN
#   Insert key
keymap  M-[2~   MENU
#   End key
keymap  M-[4~   END
#   Page Up key
keymap  M-[5~   PREV_PAGE
#   Page Down key
keymap  M-[6~   NEXT_PAGE
#   F10 function key
keymap  M-[21~  MENU

# w3m features not in less
keymap  ,   TAB_LEFT
keymap  .   TAB_RIGHT
keymap  a   SAVE_LINK
keymap  A   ADD_BOOKMARK
keymap  B   BACK
keymap  C   COMMAND
keymap  C-d BOOKMARK
keymap  C-o COOKIE
keymap  C-t TAB_LINK
keymap  C-u GOTO_RELATIVE
keymap  C-x ISEARCH_BACK
keymap  C-] TAB_MENU
keymap  d   NEXT_WORD
keymap  o   LIST_MENU
keymap  O   MOVE_LIST_MENU
keymap  p   SELECT
keymap  P   SELECT_MENU 
keymap  t   TAB_GOTO
keymap  T   NEW_TAB
keymap  U   GOTO
keymap  x   NEXT
keymap  X   PREV
keymap  \"  MOUSE_TOGGLE
keymap  \\  VIEW
keymap  {   PREV_TAB
keymap  }   NEXT_TAB
keymap  ~   LINK_MENU
#   F10 function key
keymap  M-[21~  MENU

# extra keys
keymap  ^?  PREV_PAGE

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

[NRK]

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

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

- NRK

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

[dev]

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.

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

[Markus Wichmann]

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 open("/dev/tty") fails.
You can verify this by running passwd in strace (although you may have
to run both inside sudo, since debuggers disable setuid).

Ciao,
Markus

[dev][ubase] passwd runtime error on musl

[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

Re: [dev] [ubase] compile using musl

[Brian Mayer]

> 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

[pessoa]

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 provided by musl:
>
> src/linux/splice.c:ssize_t splice(int fd_in, off_t *off_in, int 
> fd_out, off_t *off_out, size_t len, unsigned flags)
> include/fcntl.h:ssize_t splice(int, off_t *, int, off_t *, size_t, 
> unsigned);
>
> What version of musl are you using? I don't get that compilation error
> on my x86_64 desktop, but the build does fail to find makedev which
> seems to be due to an issue with the header includes:
>
> ubase$ make -j1 CC=/home/ericpruitt/emus/core/musl-1.2.4/bin/musl-cc
> /home/ericpruitt/emus/core/musl-1.2.4/bin/musl-cc -s -o mknod 
> mknod.o libutil.a -lcrypt
> /usr/bin/ld: mknod.o: in function `main':
> mknod.c:(.text+0x27d): undefined reference to `makedev'
> collect2: error: ld returned 1 exit status
> gmake: *** [Makefile:161: mknod] Error 1
>
> The glibc documentation says makedev and related macros should be
> included via  which mknod.c does not use. I assume it
> works on glibc because one of the explicitly mentioned headers itself
> pulls in sysmacros.h. I would guess you're running into a similar issue.
>
> Eric

Re: [dev] [ubase] compile using musl

[Eric Pruitt]

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 fd_in, off_t *off_in, int fd_out, 
off_t *off_out, size_t len, unsigned flags)
include/fcntl.h:ssize_t splice(int, off_t *, int, off_t *, size_t, 
unsigned);

What version of musl are you using? I don't get that compilation error
on my x86_64 desktop, but the build does fail to find makedev which
seems to be due to an issue with the header includes:

ubase$ make -j1 CC=/home/ericpruitt/emus/core/musl-1.2.4/bin/musl-cc
/home/ericpruitt/emus/core/musl-1.2.4/bin/musl-cc -s -o mknod mknod.o 
libutil.a -lcrypt
/usr/bin/ld: mknod.o: in function `main':
mknod.c:(.text+0x27d): undefined reference to `makedev'
collect2: error: ld returned 1 exit status
gmake: *** [Makefile:161: mknod] Error 1

The glibc documentation says makedev and related macros should be
included via  which mknod.c does not use. I assume it
works on glibc because one of the explicitly mentioned headers itself
pulls in sysmacros.h. I would guess you're running into a similar issue.

Eric

Re: [dev] [ubase] compile using musl

[Brian Mayer]

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

[ziegler]

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 issue was reproducible on 
multiple fairly different machines.

Re: [dev] [ubase] compile using musl

[Mattias Andrée]

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:
> 
> /home/blmayer/git/distro/buildroot/output/host/bin/aarch64-buildroot-linux-musl-gcc
> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -O2
> -g0  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> -o df.o -c df.c
> dd.c: In function 'copy_splice':
> dd.c:179:21: warning: implicit declaration of function 'splice'
> [-Wimplicit-function-declaration]
>  179 | r = splice(ifd, NULL, p[1], NULL, n, SPLICE_F_MORE);
>  | ^~
> /home/blmayer/git/distro/buildroot/output/host/bin/aarch64-buildroot-linux-musl-gcc
> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -O2
> -g0  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> -o dmesg.o -c dmesg.c
> dd.c:179:54: error: 'SPLICE_F_MORE' undeclared (first use in this function)
>  179 | r = splice(ifd, NULL, p[1], NULL, n, SPLICE_F_MORE);
>  |  ^
> dd.c:179:54: note: each undeclared identifier is reported only once
> for each function it appears in
> /home/blmayer/git/distro/buildroot/output/host/bin/aarch64-buildroot-linux-musl-gcc
> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -O2
> -g0  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> -o eject.o -c eject.c
> make[1]: *** [Makefile:164: dd.o] Error 1
> 
> 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?
> 
> Thanks,
> Brian
> 

Add -D_GNU_SOURCE

[dev] [ubase] compile using musl

[Brian Mayer]

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 -D_FILE_OFFSET_BITS=64  -O2
-g0  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-o df.o -c df.c
dd.c: In function 'copy_splice':
dd.c:179:21: warning: implicit declaration of function 'splice'
[-Wimplicit-function-declaration]
 179 | r = splice(ifd, NULL, p[1], NULL, n, SPLICE_F_MORE);
 | ^~
/home/blmayer/git/distro/buildroot/output/host/bin/aarch64-buildroot-linux-musl-gcc
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -O2
-g0  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-o dmesg.o -c dmesg.c
dd.c:179:54: error: 'SPLICE_F_MORE' undeclared (first use in this function)
 179 | r = splice(ifd, NULL, p[1], NULL, n, SPLICE_F_MORE);
 |  ^
dd.c:179:54: note: each undeclared identifier is reported only once
for each function it appears in
/home/blmayer/git/distro/buildroot/output/host/bin/aarch64-buildroot-linux-musl-gcc
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -O2
-g0  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-o eject.o -c eject.c
make[1]: *** [Makefile:164: dd.o] Error 1

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?

Thanks,
Brian

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

[Elie Le Vaillant]

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 in libsys/ all the nonportable bits
is feasible and better than re-implementing each tool for each new 
platform.


I think some tools such as sysctl are going to be way more complex than 
that

though. Linux kindly provides /proc/sys, and the current sysctl merely
replaces '.' by '/' and writes to the corresponding file. Such an
implementation is impossible on OpenBSD. It does not provide any 
systematic

way of mapping a "key" (such as "vm.drop_caches", or "vm.loadavg")
to the underlying bit-array that uniquely identifies it for sysctl(2).
We would need to write thousands of lines of OS-dependant code just to
_parse_ the command-line.

But sysctl _is_ fundamental for a working userland. Should we thus put
it in linux/, or find a way to make it portable nonetheless?


I don't get why we should have categories like "shell-only", or why
we should have so high level of customization.


Well, this is just a suggestion. I can see why it would be a bad idea
to have such high level of customization.

But I sill believe that those categories should be defined in the 
Makefile

rather than in directories. It is _very_ easy to pick-and-choose which
utilities to build with the master branch. It just requires to modify 
the
BIN list, ie. remove tools that don't fit. With a directory-based 
separation,

such a process would be more complex, and would require to modify each
Makefile individually; which, arguably, is cumbersome.

This is basically just overlapping lists of utilities, defined by 
standards,

type of utility, etc.


What is the reasoning for categories like "shell-only"?


The categories you've outlined are very clear and make sense; but they
aren't the only way of grouping tools. "shell-only" was just an example,
but some tools only make sense when used in a terminal, for displaying
data to the user. Sometimes, this is not needed (such as routers for 
example,
where there is very little need for tools like cal, cols or clear). 
Maybe this

it way too specific (and way too arbitrary), but it was just an example.
But if we ever implement tools such as gzip or xz, ping or nc, etc.
it _could_ be useful to have sets such as "compression", "net", that
may overlap with other categories.

This proposed scheme is quite inspired by the way busybox separates
its utilities, but maybe it is wrong for this precise reason. I find
the directory separation both in toybox and busybox quite useful
and elegant, so that's why I'm suggesting a system that would allow
for such separation in a simple way (Makefile lists).

I put only linux because at this moment we only have linux specific 
tools,
if we add OpenBSD tools then we can have the openbsd directory. Of 
course

that it would mean that if you add linux and openbsd at the same time
your build will fail, just don't do stupid things.

  - Allow for categories _inside the Makefile_. We could have 
something

like:
   POSIXTOOLS = portable/ls unportable/$(OS)/ps.c ...
   MISCTOOLS = portable/sponge.c portable/cols.c portable/rev.c 
...

   INTERACTIVETOOLS = portable/cols.c portable/clear.c ...
   ...
   BIN = $(POSIXTOOLS) $(MISCTOOLS) $(LINUXTOOLS)



At this stage and with the configuration that we want to have I
think we have to get rid of the monolithic approach and just define
the directories that we want to include in our build:

all: posix misc curses

and every directory with simple Makefiles.


As commented before, I think this is problematic for users who want
more control on which tools they want to build. Also, I'm really not
sure how you could get rid of the monolithic approach while still
being able to build sbase-box.

The current script-based method is quite good I think, except that it
builds all the C files in the current directory. The Makefile recipe
would need to provide the script with which files to build, ie. with
lists of C files. The root Makefile has to have knowledge of the
C files in each subdirectory, and pass it to mkbox (along with which
libsys version to use). We would have a non-monolithic build for
individual tools, but a monolithic one for sbase-box, which means
duplicating lists of utilities.

If we get rid of the monolithic approach, then what I propose
(overlapping categories as lists of utilities in a Makefile)
would be inapplicable.



As commented, the idea is to have all the tools written with portable
code. Tools in POSIX are implemented in all the systems, so they
have a way to be implemented.  At this moment I just began to
classify the tools, that is not easy, and I didn't care about fixing
the portability problems, but after deciding the categories then it
should be the next step.


Of course! I think some 

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

[Roberto E. Vargas Caballero]

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 of the Makefile
> (PORTABLE set vs NONPORTABLE), but I think it is better to explicitly
> separate in different
> directories portable from non-portable tools. If we don't, we are making
> sbase a Linux-only
> project (the only implementation for ps becomes a Linux-only one, and we
> would need to fork
> sbase to make it available to other platforms; same for all the other
> tools from ubase), which
> I find a bit sad considering the goals of portability of sbase

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.
In some cases it would mean to remove some functionalities or worst
performance, but it is not a problem because we can keep in ubase
the optimized versions.  For example, sbase has a portable dd and
ubase has a customized linux dd version.

>   - I think Mattias Andrée scheme is better than this one. With a
> directory-base separation
> (between categories of utilities, based on somewhat arbitrary factors
> (standards, rather than
> say, minimalness, or use-case, or platform or implementation, etc.)), we
> cannot have overlapping
> categories, which is quite problematic. For example, if we wished to
> have a category for
> "shell-only usage" (such as clear, or cols), we couldn't implement it in
> an easy way, because
> this category overlaps with misc/, curses-dummy/, and maybe others too.

I don't get why we should have categories like "shell-only", or why
we should have so high level of customization. Having some categories
makes sense, but going to the level of user custom lists is too
much in my opinion. The separation between posix/ and misc/ is there
because may people raised the concern that they didn't use tools
like sponge, tac or shuf ever, so it is questionable to include
them, but as there are other people that use them we add the option
to include them.  The curses tools have the problem that include a
strong dependency with a complex library, and it is desirable to
skip them, because it can be very problematic to build them in some
cases. Having the unix/ category is there for all the tools that
were part of POSIX previously and/or were part of UNIX historically
but for different reasons are not part of POSIX today.  Having a
POSIX only set of tools has the advantage of being a tool to check
if your shell script is portable or not.

What is the reasoning for categories like "shell-only"?

> What I suggest to fix both problems:
>   - separate on the grounds of portability/nonportability. In other words,
> something along the lines
> of:
>libutil/
>portable/
>  ls.c
>  cols.c

As commented before, all the tools must be portable, except of
course linux specific tools. After talking with quinq he liked the
idea because then tools for Openbsd can be easily added just adding
a new openbsd directory.

> This more or less reproduces the sbase/ubase separation, but allowing
> future OSes to come in
> the future rather than just Linux (so, for example, *maybe* OpenBSD

I put only linux because at this moment we only have linux specific tools,
if we add OpenBSD tools then we can have the openbsd directory. Of course
that it would mean that if you add linux and openbsd at the same time
your build will fail, just don't do stupid things.

>   - Allow for categories _inside the Makefile_. We could have something
> like:
>POSIXTOOLS = portable/ls unportable/$(OS)/ps.c ...
>MISCTOOLS = portable/sponge.c portable/cols.c portable/rev.c ...
>INTERACTIVETOOLS = portable/cols.c portable/clear.c ...
>...
>BIN = $(POSIXTOOLS) $(MISCTOOLS) $(LINUXTOOLS)

At this stage and with the configuration that we want to have I
think we have to get rid of the monolithic approach and just define
the directories that we want to include in our build:

all: posix misc curses

and every directory with simple Makefiles.

> This allows for such grouping, while also allowing overlapping
> categories. This also doesn't
> hinder the useful semantic sbase/ubase separation (which is especially
> handy when working on
> non-Linux OSes). I think overall that sbase/ubase is the most useful
> distinction, so it should
> be treated specially, and not as part of the build-system (but more as
> part of the directory
> organization).

As commented, the idea is to have all the tools written with portable
code. Tools in POSIX are implemented in all the systems, so they
have a way to be implemented.  At this moment I just began to
classify the tools, that is 

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

[Elie Le Vaillant]

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)
	- curses-terminfo (tools with dependency of terminfo, like clean and 
reset).

- curses-dummy (curses tools implementation without using terminfo).
- libutil (library with utility functions)
- libsys (library with system dependant functions).



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 of the Makefile
(PORTABLE set vs NONPORTABLE), but I think it is better to 
explicitly separate in different
directories portable from non-portable tools. If we don't, we are 
making sbase a Linux-only
project (the only implementation for ps becomes a Linux-only one, 
and we would need to fork
sbase to make it available to other platforms; same for all the 
other tools from ubase), which

I find a bit sad considering the goals of portability of sbase

  - I think Mattias Andrée scheme is better than this one. With a 
directory-base separation
(between categories of utilities, based on somewhat arbitrary 
factors (standards, rather than
say, minimalness, or use-case, or platform or implementation, 
etc.)), we cannot have overlapping
categories, which is quite problematic. For example, if we wished to 
have a category for
"shell-only usage" (such as clear, or cols), we couldn't implement 
it in an easy way, because
this category overlaps with misc/, curses-dummy/, and maybe others 
too.


What I suggest to fix both problems:
  - separate on the grounds of portability/nonportability. In other 
words, something along the lines

of:
   libutil/
   portable/
 ls.c
 cols.c
   unportable/
 linux/
   lsmod.c
   ps.c
   libsys/
 maybe-other-os-in-the-future/
This more or less reproduces the sbase/ubase separation, but 
allowing future OSes to come in
the future rather than just Linux (so, for example, *maybe* OpenBSD 
could have some tools in

the future. This is a suggestion).

  - Allow for categories _inside the Makefile_. We could have something 
like:

   POSIXTOOLS = portable/ls unportable/$(OS)/ps.c ...
   MISCTOOLS = portable/sponge.c portable/cols.c portable/rev.c ...
   INTERACTIVETOOLS = portable/cols.c portable/clear.c ...
   ...
   BIN = $(POSIXTOOLS) $(MISCTOOLS) $(LINUXTOOLS)
This allows for such grouping, while also allowing overlapping 
categories. This also doesn't
hinder the useful semantic sbase/ubase separation (which is 
especially handy when working on
non-Linux OSes). I think overall that sbase/ubase is the most useful 
distinction, so it should
be treated specially, and not as part of the build-system (but more 
as part of the directory

organization).

Possible drawbacks which I've thought about could be:
  - This requires to occasionally write and update different, 
overlapping lists of tools. I believe
this is not too much of an issue. Adding new items should be quite 
easy, and you've already done
a form a grouping which we could use for this proposed alternative 
layout. This task could also
be aided by the way busybox groups its different utilities, and the 
different standards and

packages listed on the toybox website.

  - The Makefile would be a bit more complex. If we truly add support 
for multiple platforms (which
is a mere suggestion), it could become a bit complex (as in: 
platform-specific bits of Makefile
to properly compile libsys, or platform-specific utilities (lsmod, 
sysctl...)). If we don't,
and just keep a portable/linux separation at the directory-level, we 
still need a bit more
complexity (defining tool categories, properly distinguishing 
between libutil and libsys at
compile-time, and only for platform-specific tools, etc.) than what 
we currently have, but this
complexity would be very similar to the one we would have with your 
proposed layout.


Overall, I think that the benefits of the proposed alternative layout 
(sbase/ubase primary distinction,
reflected at the directory level; and Makefile-specific lists as 
secondary distinction, only reflected
at the build-system level, which allows very great flexibility) outweigh 
the inconveniences. Moreover,
I think that your layout has issues, such as the fact that sbase becomes 
a de-facto Linux-only project,
considering that tools whose implementation are Linux-specific (ps, 
mknod, etc.) are not treated
differently from tools which are inherently portable (sponge, sed...), 
or the fact that the categories
you've made so far forbid any kind of 

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

[Roberto E. Vargas Caballero]

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 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)
- curses-terminfo (tools with dependency of terminfo, like clean and 
reset).
- curses-dummy (curses tools implementation without using terminfo).
- libutil (library with utility functions)
- libsys (library with system dependant functions).


The separation between curses and curses-dummy is because we have
currently some curses tools implemented using hardcoded sequences
instead of using terminfo to locate the correct sequences for the
terminal used. While this would work in the majority of terminal
emulators (because almost all of them emulate vt100 compatible
emulatros) it would not work in many cases. It is a good idea
to keep them because it reduces the dependencies of the project,
and it makes easier to bootstrap systems. But I think we can also
implement the correct solutions and select what is the option
at build time.

it was commented to have functions that isolated the system dependencies
between different systems, and I thought that instead of adding them
to libutil it was better to define a new library only for that
purpose.

Please, give your opinion.

Regards,

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

[Viktor Grigorov]

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 editor capable 
of multiple selection and edition is the most I've had to do. Faulty output 
includes, say, only a single letter rather than a whole word capitalised or 
within '\e[...m' and '\e[0m'.

Protip; Run it with -w 0 to get 'natural' paragraphs.


[0] https://github.com/kevinboone/epub2txt2

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 that it's just
> not worth it.  The output always winds up un-readable.

I use pdftotext from poppler-utils. It does quite good job.

This is my main pdf reader command:
```
pdftotext -layout -nopgbrk ${1@Q} - | less -MS --use-color
```

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

[Greg Reagle]

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 \
> 2015.31233.Arab-Geographers-Knowledge-Of-Southern-India.epub) | less
> 

Very cool command.  Good idea to use process substitution.  Here is another way 
of doing it:
pandoc --standalone -t man City_of_Truth-Morrow.epub | man /dev/stdin
but I don't know how portable /dev/stdin is.

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

[Greg Reagle]

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, for repeated viewing in less:
pandoc -s -t html City_of_Truth-Morrow.epub | elinks -dump-color-mode 2 
-force-html > City_of_Truth-Morrow-formatted.txt

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 that it's just not worth it.  The output always winds up 
un-readable.

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

[Greg Reagle]

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.

https://github.com/rofl0r/SDLBook
https://github.com/festvox/bard

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

[Greg Reagle]

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 breaks and terminal control are created 
> on demand, depending on the type and size of the terminal (window) and 
> will display different (weird) when any of this is different from the 
> terminal you (would have) saved them to a file.

Yes I have noticed this.  I would like to be able to tell programs to keep the 
formatting, but they decide automatically on their own to remove it.  The 
automatic decision to keep or remove formatting based on terminal type is fine, 
but I find it very annoying that I cannot override this decision with many 
programs.  GNU's ls is an exception (with the --color option).  I would like to 
tell w3m or elinks to dump html and keep the formatting, which they cannot do 
(directly).  There are ways around that cause extra steps.

> The -s option (--standalone) option for Pandoc is not required for man 
> page output.

Well it definitely is for me, meaning the version of Pandoc that I use: 
2.17.1.1-2~deb12u1 amd64

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

[Greg Reagle]

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

[Roberto E. Vargas Caballero]

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 complex than the one that we have now.

I am going to import the history of ubase into sbase and
I will push to a new branch. Meanwhile, I am going to
keep frozen the pending patches that we have in the hackers
mailing list until the migration is done. I would ask
later to the authors to resend them adjusted to the structure
of the project. Please, raise your concerns if you consider
that something else should be done.

More mails are expected in specific threads while we
progress with the migration.

Regards,

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

[NRK]

> Everything in the quoted part seems personal preference.

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

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

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

- NRK

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

[Georg Lehner]

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 process, but I MUST use less 
in the end to read it.  The terminal emulators that I use are usually st, 
xterm, and termux.  All of them are capable of colored text and underlining and 
so forth, and I want to take advantage of this.

Pandoc does a very good job converting epub to html, and it looks good with 
w3m, however when I use w3m in a pipe, the output is truly *plain* text, 
meaning there are no escape codes for formatting.  Same story with elinks.  Is 
it possible to get either of these programs, or some other program, to dump 
html to text *with* escape codes?

Since I could not get HTML to work, I went with man format.  Amazing.  Pandoc 
automatically chooses man format for output based on the '.1' extension in the 
followingv
 pandoc --standalone -o City_of_Truth-Morrow.1 City_of_Truth-Morrow.epub
Remember to use standalone option or it won't work.  Then
 man --local-file --pager 'less -ir' City_of_Truth-Morrow.1
It looks great!  (for text only on a terminal)  It has bold and underlined 
text.  From there I can use less 's' command to save the formatted text to a 
file.

There might be a better or more direct way of achieving this goal, but this I 
what I figured out for now.  And the rationale is this:  I already know and 
love less.  There is no good reason for me to learn the user interface of a 
different program like an epub reader or an html reader to read a book that 
does not have graphics, diagrams, pictures, and/or custom formatting.


Just modify your workflow slightly and you are good:

Option 1: use w3m

pandoc -s -t html City_of_Truth-Morrow.epub | w3m -T text/html

Option 2: use man/less

pandoc -t man City_of_Truth-Morrow.epub | man -l -

Option 3, save as html for future use:

pandoc -s  -o City_of_Truth-Morrow.html City_of_Truth-Morrow.epub

Saves your epub to html. Whenever you want to view it, use your favorite 
browser, i.e. w3m, with all its features.


Option 4: save as man:

pandoc -s -t man -o City_of_Truth-Morrow.man City_of_Truth-Morrow.epub

Whenever you view it, use: man -l City_of_Truth-Morrow.man

- - -

Some notes:

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 breaks and terminal control are created 
on demand, depending on the type and size of the terminal (window) and 
will display different (weird) when any of this is different from the 
terminal you (would have) saved them to a file.


The -s option (--standalone) option for Pandoc is not required for man 
page output. For html (and other formats) pandoc outputs only the  
content, the -s options wraps this into a complete  document.


Best Regards,


  Georg

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

[Greg Minshall]

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, this deserves to be somewhere like fortune: "I already know and
love less.".  :)  maybe "fortune-mod-fles-pleh"?  :)

cheers, Greg

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

[Mattias Andrée]

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 the two versions of libutil into a single, separate
> > libutil repository  
> 
> I'm not sure whether or not this is a good idea, because it makes
> sbase and ubase dependant upon a separate repository, which needs to
> be present in the parent directory for it to build. It'd also make
> sbase development cumbersome, because we very frequently change
> libutil when we change sbase. Both are developed as one single
> project, and patches reflect this. libutil should not be isolated I
> think.
> 
> > then have a directory hierarchy like this:
> > 
> > corebox
> > ├──sbase (portable only)  \
> > ├──ubase (nonportable) depend on libutil.so and/or libutil.a
> > ├──xbase (non-POSIX)  /
> > └──libutil (option to produce .so and/or .a)  
> 
> ubase is not only nonportable, it is _linux-specific_. It is also
> non-POSIX. I think ubase should be renamed to reflect this. The
> distinction between POSIX/non-POSIX is, I think, not very useful. As

There are also multiple standards, not just POSIX. For example
tar, true, false are not POSIX (tar was removed from POSIX, and
true and false are defined only as shell built-in in POSIX), but they
are defined in LSB which a propular, but it's a Linux specific standard.
Most of POSIX but not all of POSIX is also defined by LSB.

> Mattias said, pure POSIX is quite cumbersome, and not very descriptive
> as of what you can expect from it. sh and vi are POSIX, but out-of-scope
> for sbase (from the TODO), whereas sponge is crucial for sbase (it
> allows simpler implementation of -i for sed, which _is_ POSIX, or the
> -o flag for sort (POSIX too)) and would thus be excluded from sbase
> and put into xbase.

sed -i is not POSIX.

> 
> The solution Mattias proposed (having one big repository, a portable
> subdir, a linux (and maybe others in the future, like openbsd) subdir
> and a Makefile which includes more descriptive sets than POSIX/non-POSIX
> (well, it _can_ be used, but it is not enough)) is I think the best to
> fix the problem of libutil duplication/drifting away of versions. It
> also allows a broader scope without impeding on the goals of sucklessness.
> 
> One supplementary question, more in line with the original question asked
> by Roberto E. Vargas Caballero, is: would awk and sh be out-of-scope?
> Should we rather try to implement extensions to awk, or follow the 
> specification
> as strictly possible? Should we implement POSIX sh, or some other shell, such 
> as rc?
> Or is it out-of-scope for us to implement a full-blown shell? I really am
> not sure.

I don't think there is any reason that sbase should implement
all of the standard utilities you need, I think it should only
be the small tools that you can reasonably write in one file.
Large and complicated programs like sh should be it's own project.

> 
> Regards,
> Elie Le Vaillant
>