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

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

[Hiltjo Posthuma]

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

Hi,

Maybe mupdf/mutools or the eGhostscript tools o qpdf?

-- 
Kind regards,
Hiltjo

Re: [dev] [st] XTSMGRAPHICS query

[Hiltjo Posthuma]

On Sat, Feb 17, 2024 at 09:45:44PM -0500, Tim Culverhouse wrote:
> Hello - I am the author of a TUI library and received a bug report regarding
> cursor placement on exiting an application.
> 
> I was able to narrow down a simple reproducer to how st a XTSMGRAPHICS query:
> 
>   echo -e "\x1b[?2;1;0S"
> 
> This can also be seen when using a notcurses application which *doesn't* enter
> the altscreen (ie `ncls`). notcurses does the XTSMGRAPHICS query in the alt
> screen (which is also the solution I will be using), but `ncls` uses notcurses
> direct mode, which never enters the alt screen thus this bug appears there as
> well.
> 
> I checked the source and it looks like the parser is not checking for a 
> private
> indicator when handling a CSI with final character S. In that case, this query
> gets parsed as a SU sequence. I think that ought be modified to ensure there
> isn't a '?' private indicator in the sequence before handling as SU.
> 
> Not much of a C programmer but I could take a shot at this if the solution
> sounds ok.
> 
> -- 
> Tim
> 

Hi Tim,

Thanks for the report.

Which TUI library did you write? Some real life programs to test it against
would be useful too.

I'll happily look at your patch when you send one,

-- 
Kind regards,
Hiltjo

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

[Hiltjo Posthuma]

On Sun, Feb 04, 2024 at 08:38:46AM +0300, Robin Haberkorn wrote:
> Hello!
> 
> I picked up the patch from Jochen Sprickerhof 
> that was posted on hack...@suckless.org a few years ago, allowing you to
> embed applications into st via Xembed. So this is the _host_ side of
> Xembed, very similar to what tabbed does. The thing is, you do not always
> want to open apps in new tabs - I personally do not use tabbed
> at all - but you just want it to cover your terminal window, so it behaves
> more like a fullscreen terminal application and does not spawn a new X11
> window that may ruin your tiling layout etc.
> 
> Check out to the last 3 patches on this branch:
> https://github.com/rhaberkorn/st/commits/patches/
> (The others are really just patches I personally use for customization.)
> 
> This has been tested with SciTECO (https://github.com/rhaberkorn/sciteco),
> nsxiv and mpv (--wid).
> Zathura unfortunately does not work flawlessly. It does not refresh its
> window once embedded. And neither does Zathura work with tabbed.
> 
> Also, st windows tend to freeze after resizing them a bit (but only while
> a client is embedded).
> 
> I am not very experienced in Xlib programming, so perhaps somebody else
> could have a look. Somebody who knows tabbed better than I do.
> 
> Another issue is that once an embedded app terminates, I try to remove
> the icon from the st window. xprop confirms that this works.
> But at least Awesome WM does not respect this change and continues
> to display the old icon.
> I suspect this is an Awesome WM bug.
> Perhaps somebody could test with another WM.
> 
> I like this feature so much, I also looked into whether it would be
> possible to somehow hack Gtk (e.g. using LD_PRELOAD) so you can
> embed most Gtk applications - after all they provide GtkPlug and it
> also derives from GtkWindow. Unfortunately, this would not be trivial.
> It might be easier to patch Gtk itself.
> 
> All of this should perhaps eventually be part of the Wiki once
> we fixed the remaining problems.
> 
> Best regards,
> Robin
> 

Hi,

If you want to contribute to upstream you need to rebase the patches on the
master version of st.

Then you send the patches (git-format-patch) to the mailinglist.

-- 
Kind regards,
Hiltjo

Re: [dev] Presenting some more software

[Hiltjo Posthuma]

On Mon, Jan 15, 2024 at 06:22:21AM +0100, Страхиња Радић wrote:
> On 24/01/13 09:19PM, stefan1 wrote:
> > https://github.com/stefan1/su
> > https://github.com/stefan1/rootdo
> > https://github.com/stefan1/rdoedit
> 
> I find sup[1] (~120-ish LoC) very useful, and in line with suckless 
> philosophy.
> 
> [1]: https://oldgit.suckless.org/sup/


I would recommend doas and for Linux the fork opendoas.

-- 
Kind regards,
Hiltjo

Re: [dev] [bug] sbase / expr: loss of leading zeros in string operations

[Hiltjo Posthuma]

On Sun, Jan 07, 2024 at 01:20:21PM +0100, fom...@0w.se wrote:
> Hello,
> 
> Thanks for the software.
> 
> For your information, with the latest and also with earlier sbase:
> 
> Expected:
> 
> $ expr 3 : '.*'
> 5
> $ expr 3 : '\(.*\)'
> 3
> 
> $ expr 3x : '\(.*\)'
> 3x
> 
> Observed:
> 
> $ ./expr 3 : '.*'
> 1
> $ ./expr 3 : '\(.*\)'
> 3
> 
> $ ./expr 3x : '\(.*\)'
> 3x
> 
> The leading zeros are lost if the argument looks like a number.
> 
> Regards, fomha4
> 

Thanks, the issue seems to be in lex() I think:
http://git.suckless.org/sbase/file/expr.c.html#l175

If anyone can write the patch it would be appreciated.

-- 
Kind regards,
Hiltjo

Re: [dev] surf: usage does not match supported flags

[Hiltjo Posthuma]

On Fri, Nov 10, 2023 at 10:37:31AM -0800, Eric Pruitt wrote:
> Since at least commit fce76429b8f8ed48116557df3a478bc435145d94, the
> flags in surf's usage don't match what's actually supported.
> 
> Eric
> 

This is the -p and -P option.
It should probably also be removed from the man page :)

-- 
Kind regards,
Hiltjo

Re: [dev] A secure wireless protocol

[Hiltjo Posthuma]

On Sat, Oct 14, 2023 at 01:17:04PM +0200, Sagar Acharya wrote:
> Dear devs,
> 
> Currently, all phones use WiFi, GSM, Bluetooth networks in practically all 
> applications. For WiFi and Bluetooth replacements, do you have any alternate 
> network in mind which caters to only local public and private keys.
> 
> So, a network which before transmitting a packet, encrypts it with the 
> recipients' public key and broadcasts it with recipients id as header, say 
> like,
> 
> 
> 
> A list of MAC addresses would be maintained on WiFi server end for each 
> device. Are there already such network softwares made out there?
> 
> The aim is no dhcp and not a single device outside list can communicate.
> Thanking you
> Sagar Acharya
> https://humaaraartha.in/selfdost/selfdost.html
> 

There are different levels of networking layers implementing secure tunnels in
different layers (IPSec, TLS, HTTPS, Wireguard, Encrypted XMLs over HTTPS). You
could even use public/private encrypted messages on sticky notes or by
carrier-pigeon.

Maybe I'm getting too old and conservative, but I'd use the standards (RFC)
that are there. Bluetooth kinda sucks though.

-- 
Kind regards,
Hiltjo

Re: [dev] C cgi based forum services

[Hiltjo Posthuma]

On Thu, Aug 10, 2023 at 09:21:15AM +0200, Sagar Acharya wrote:
> Are there any nice cgi based forums out there?
> 
> Which provide register, login and posting?
> 
> It would be best if they're coded in C or Lua.
> 
> 
> Thanking you
> Sagar Acharya
> https://humaaraartha.in
> 

Yes, but you could do some own research into it also.

-- 
Kind regards,
Hiltjo

Re: [dev] Suckless paint/graphic editor program [OS topic]

[Hiltjo Posthuma]

On Wed, Jul 12, 2023 at 02:59:04PM -0400, fo...@dnmx.org wrote:
> 1s of all I'd like to say I'm sorry because of the e-mail formatting that
> seems
> to happen.. someone did tell me clients don't like that, but I do not
> unfortunately have health to figure this out, I will remember this,
> though, for
> the future.
> (Talking about my last e-mail, I think)
> 
> 
> > On Tue, Jul 11, 2023 at 3:02
PM  wrote:
> > > Like I even started writing what I hate about systems, so-to make the
> perfect
> > > one for me and others, with cheap AF hardware that once can DIY, of
> course.
> > > Trust me when I say that roof over my head is blown-away from the
> amount of
> > > rich motivation, ideas and deducements I've had.
> > >
> > > I wish, I hope.. I research.. no one will help me but me, sadly.
> >
> > I'd be very interested to hear what you've come up with regarding a
> > perfect system.  I keep wanting to put together a custom distribution
> > spin-off and use only software that's easy to build from source.
> > Haven't had much luck with it.  I keep looking for programs and
> > libraries to use so I can at least build some of the programs I work
> > with from source.  I also keep looking at lightweight Linux
> > distributions to see if they have any similar goals and need
> > volunteers.  No luck so far.  I do find some interesting applications
> > looking at minimal Linux distributions though.  I also like checking
> > into the BSD alternatives to common GNU tools and libraries.
> 
> I'm not talking about a distribution, because in my opinion, even OpenBSD is
> foolish with some of it's approaches to security ;) or it's too much work now
> when the OS is complete-ish.. like more-less fundemental changes, not Unix
> compatible, better than Unix ever was or will be, but I'd of course have
> utilities like sed grep tail head etc.
> Basically every OS up until now would be a lesson.. big time from OpenBSD.
> Oh, and it'd be suckless, although not sure about the patching approach,
> because with that, on a bigger scale come security/reliability concerns,
> but I
> think I could get away with that by leaving the patchers aka hackers
> responsible, and perhaps there could be forks who's creators like just
> applied
> specific patches that work together with each other well and/or
> code/philosophy
> standard if you want security and/or reliability :)
> 
> Also would take some inspirations from TempleOS.
> And would not be licensed because fuck governments and their shit rules,
> in my
> world, intellectual fucking property are just 2 words without meaning,
> they do
> not exist.
> I predicted that licensing code could be automated with an algorith aka A.I.,
> and like less than 1 year later exactly that happened.
> All IP (patents,licensing,trademark) is utter and absolute impossibly mad
> dog-shit.. I am disappointed in humanity as a whole for allowing it and even
> conforming to it ("oh, you want a license? faaayn, here you go a CC0", NO
> MORE OF THAT BULLSHIT!!)
> 
> But 1st I have to optimize how my brain works in order to master memory
> management and efficiency.
> Also working on improving deduction skills, which can partially be
> achieved by
> eating certain foods that contain DHA/EPA omega3 acids found in for example
> wallnuts, your brain needs that.
> Yes, I'm that hardcore/extreme, in fact that's just the beginning.
> But we'll see, I might just be a fart in the wind.. I fucking hate my current
> state of pathetic nothingness.
> 
> 
> 

You are now banned from this list.

Please follow mail equitte and normal(tm) human behaviour.

-- 
Kind regards,
Hiltjo

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

[Hiltjo Posthuma]

On Tue, Jul 04, 2023 at 01:16:34PM -0500, Dave Blanchard wrote:
> I take a practical approach. I use simple programs when they do the job well, 
> and more complex programs when they get the job done better. Sometimes a 
> simple program can be useful for certain jobs, such as ones involving shell 
> scripting, whereas a complex program may be more useful for example in other 
> applications, such as using Solidworks for engineering work. LaTeX is 
> certainly a bloated monstrosity, but the damn thing is useful for a lot of 
> different tasks.
> 
> People on this email list tend to go to an extreme in favoring simplicity 
> above all else, which is why they release dumpster fires like the ST terminal 
> emulator for example which has absolutely no features at all, is riddled with 
> bugs and compatibility problems, and requires extensive patching to add in 
> any useful features. The developers are also basement-dwelling losers, total 
> raging assholes who take personal offense to the suggestion that their code 
> should be better commented or that someone might fork the code to make an 
> improved version. 
> 

true

> I tried ST for a time before realizing it was trash and just switched back to 
> Xterm, the gold standard of functional X11 terminal emulators, which the ST 
> developers talked shit about, calling "bloated" in their documentation, and 
> saying the code wasn't good. Actually it is not bloated, the code quality is 
> much higher than ST (and is actually commented!), It Just Works(TM), and it's 
> noticeably faster as well when ST is patched with the juvenile "scrollback 
> buffer support" implementation--which calls malloc() once for every line(!) 
> of the scrollback buffer. 
> 
> Take anything that a religious cult member says with a grain of salt.
> 
> Dave
> 

-- 
Kind regards,
Hiltjo

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

[Hiltjo Posthuma]

On Tue, Jul 04, 2023 at 07:06:12PM +0300, Nikita Krasnov wrote:
> Just bear with me on this one, this is not a bait or a troll, I promise. I
> genuinely fell very confused.
> 
> What would be the point of using minimalist software if bloated and
> excessively complex programs completely satisfy all my needs? I am not the
> kind of person that works directly with hardware, but it's not like I use my
> system only as a bootloader for a web browser either. It's just that my
> current workflow feels pretty complete to me.
> 
> Take LaTeX, for example. I do all of my LaTeX in TeXstudio and, frankly, I'm
> satisfied with it. Autocompletion is there by default and there are many
> shortcuts that I don't need to set up myself. I simply use the all of this.
> 
> You could say that TeXstudio is pretty bloated and isn't that flexible in
> terms of configuring and using it in conjunction with other applications.
> And you'd be right. But if I'll try to use more minimalist software like
> Neovim I would spend an endless amount of time configuring and patching all
> the features I now take for granted. And even if I succeed, there will
> certainly be a time when I would need some feature I haven't thought of in
> advance (a need to use a debugger inside Nvim, idk) and I would have to
> either avoid this feature for the time being or abandon anything I am
> currently doing and try to search information on how to integrate this thing
> into my system and into my workflow.
> 
> If I had used one of the bloated programs I probably could have found a
> solution in one of the menus after reading few Stack Overflow answers. But
> with Neovim I'd have to first find the program that would be suitable for
> what I try to achieve, then I'd have to read many lines or pages of
> documentation, after that I'd have to implement that thing and only then I'd
> be able to use the thing.
> 
> Such minimalism just seems unpractical to me. Maybe I have the wrong mindset
> when it comes to these things.
> 

> I do love using more niche and minimalist programs. I like when things are
> small, simple and understandable. I really like C over C++, Rust or anything

Why?

> else exactly for that reason. It's just makes computers fun, comfortable and
> cute (idk how else to describe it). But am not fond of endlessly configuring
> these things before they become even semi-practical. I really don't know
> what to think about all of this. What do you have to say about this?
> 
> --
> Nikita
> 

-- 
Kind regards,
Hiltjo

Re: [dev] Announcing a couple small X11 utilities

[Hiltjo Posthuma]

On Tue, Jul 04, 2023 at 07:51:59PM +0600, NRK wrote:
> Hi all,
> 
> I'd like to share some small X11 utilities that I've developed and have
> been using in my daily setup. The utilities are all fairly small in
> size and requires only typical X libraries.
> 
> sxcs
> 
> 
> This is a simple color picker and magnifier. My issue with all other
> existing minimal color pickers were that due to no magnification,
> picking out specific pixels was fairly difficult.
> 
> The usage is simple, you launch the program and pick a color. The result
> will be output to stdout in tab separated RGB, HSL and HEX format.
> 
> Repo: https://codeberg.org/NRK/sxcs
> SLoC: ~628
> Dependencies: Xlib, libXcursor
> 
> sxot
> 
> 
> This one is a *very minimal* screenshot tool. I wrote this when I
> realized that other cli screenshot tools (scrot, maim) do way too much.
> 
> sxot on the other hand is meant to follow the unix philosophy - it
> simply takes a screenshot and outputs a binary ppm image to stdout.
> Any other functionalities are supposed to be handled by more specialized
> tools. E.g sx4 (see below) for selection, optipng to convert to png,
> xclip for copying to clipboard etc.
> 
> Repo: https://codeberg.org/NRK/sxot
> SLoC: ~251
> Dependencies: Xlib, libXfixes
> 
> sx4
> ===
> 
> This one is a selection tool. It outputs the selection rectangle to
> stdout which can then be used for other purposes, such as screenshoting
> or screen-recording a specific area.
> 
> Repo: https://codeberg.org/NRK/sx4
> SLoC: ~500
> Dependencies: Xlib, libXext
> 
> ---
> 
> And that's all. Feel free to report any bugs, send bug-fixes, request
> additional features (within the project's scope) etc.
> 
> - NRK
> 

Nice, thanks for sharing :)

-- 
Kind regards,
Hiltjo

Re: [dev] Am I doing this right?

[Hiltjo Posthuma]

On Sat, Jul 01, 2023 at 06:15:17PM +0300, Nikita Krasnov wrote:
> Is this message – an equivalent of a new forum topic or thread? Does anyone
> even see this? Sorry, first time having conversations this way.  Also, is
> hard-wrapping lines at 80 characters a requirement? I see many people
> doing this here (I
> think I also saw Linus Torvalds doing the same in kernel emails).
> 
> I do see an appeal in this, but I don't necessarily see the purpose. You can
> configure any text editor to soft-wrap at the end of the screen
> without breaking lines.
> Is there something I can read about this?
> 

Congratulations, you have successfully sent an electronic mail!

-- 
Kind regards,
Hiltjo

Re: [dev] [slock] eye candy for slock

[Hiltjo Posthuma]

On Sun, Jun 25, 2023 at 11:32:56AM +0200, Ivan Morén wrote:
> I made this patch (see the attached animated gif) forever ago, and
> have been using it ever since. Does anyone have interest in this as a
> patch? I would be happy to share it, but would probably want to (maybe
> with help?) clean up the code to some suckless standard first.
> 
> Best regards!
> ivan
> 
> P.S. There is also another patch that enables escaping (like a screen
> saver) the locking until it is fully closed. In my version there are
> no colors, so a lot more minimalist, but I wanted to show you it as
> bare bones as possible, so I applied the patch without any other
> modifications.

Hi,

Community patches can be added to the wiki.

See the wiki contributions guidelines page.

-- 
Kind regards,
Hiltjo

Re: [dev] Suckless filesystems

[Hiltjo Posthuma]

On Thu, Jun 22, 2023 at 12:08:42PM +0200, Sagar Acharya wrote:
> Which are the filesystems which suckless recommends?
> 
> In my view, simple ones are FAT32, ext2.
> 
> I think journaling is required which I see as within disk backup. A robust 
> and easy fsck like program which corrects errors easily. And a program which 
> periodically checks memory and replaces all corrupted file data with 
> journaled data to be spick and span.
> 
> What are your views on these?
> Thanking you
> Sagar Acharya
> https://humaaraartha.in
> 
> Lately, I'm having some hard time with ufs2
> 

For me it depends. I tend to use the default and most-used filesystem. On Linux
this is ext[234].

On OpenBSD I use its default filesystem. It is good enough for most tasks for 
me.

For a filesystem reliability is the most important thing. Nothing else matters
if data is lost or access to it is unreliable.

-- 
Kind regards,
Hiltjo

Re: [dev] [sbase] segfault in cron

[Hiltjo Posthuma]

On Thu, Jun 22, 2023 at 05:46:09PM +0100, Frank Busse wrote:
> Hi,
> 
> 
> I ran KLEE on revision #530407 and it found a segfault in cron. It can
> be reproduced via:
> 
> $ printf '1*' > A
> $ sbase-530407/bin/cron "-nfA"
> 
> Seems free() points into rubbish:
> 
> AddressSanitizer:DEADLYSIGNAL
> =
> ==2103==ERROR: AddressSanitizer: SEGV on unknown address
> 
> #4 in __interceptor_free (ptr=0xbebebebebebebebe)
> #5 in parsefield (field=0x60c00040 "1*", low=0, high=59,
> f=0x60d00040) at cron.c:335
> #6 in loadentries () at cron.c:419
> #7 in main (argc=0, argv=0x7fffe3d8) at cron.c:528
> 
> 
> Best,
> 
> Frank
> 

Hi,

I can reproduce it also with clang and -fsanitize=address.

I think this is because it is one case where f->val is uninitialized.
The below patch initializes f->val and f->len before doing anything.

Lightly tested patch below:


diff --git a/cron.c b/cron.c
index 77304cc..c4d9af8 100644
--- a/cron.c
+++ b/cron.c
@@ -254,6 +254,8 @@ parsefield(const char *field, long low, long high, struct 
field *f)
while (isdigit(*p))
p++;
 
+   f->val = NULL;
+   f->len = 0;
f->type = ERROR;
 
switch (*p) {

-- 
Kind regards,
Hiltjo

Re: [dev] [license] gpl issues

[Hiltjo Posthuma]

On Sun, Jun 18, 2023 at 04:58:07PM +1200, Miles Rout wrote:
> 
> 
> On 6 May 2023 8:56:23 pm NZST, "Страхиња Радић"  wrote:
> > But that is pointless to 
> >bring up here, because the reality is that the programmers who made suckless 
> >software mostly picked Expat License (and are calling it "the MIT License"). 
> >It 
> >is irrelevant for non-GPL programs I fork or contribute to, because once the 
> >license is picked, software it applies to can't be relicensed.
> 
> As far as I understand, if you create a work (A) that is a fork of another 
> work (B), where B is MIT-licensed, nothing stops you from licensing A as GPL. 
> I wouldn't call it "relicensing": you're licensing your own work, A, which 
> happens to be derived from B. You aren't licensing B, which is someone else's 
> work. You do need to credit B's copyright holders of course.
> 
> Have I got something wrong here? I am no copyright lawyer, that is for sure, 
> so I cannot claim any expertise. Or did you mean something different?
> 
> >Here we come to my main point: that this is a troll topic, promoting 
> >division 
> >and pushing the main suckless principles to the background. Consequently, I 
> >already wrote too much here.
> 
>  I see no trolling in this thread. Suckless people generally seem to respect 
> others' opinions. Nice to see in this day and age!
> 
> Kind regards,
> Miles.
> 

Hi,

I think you can relicense only your own changes to GPL, so you'd have to keep
both the MIT and GPL license with the original copyright information.

And probably explain very clearly to which new parts the GPL license applies.

-- 
Kind regards,
Hiltjo

Re: [dev] organizing programs

[Hiltjo Posthuma]

On Sat, May 13, 2023 at 11:26:15PM +0200, Viktor Grigorov wrote:

> Pen and paper work best for me when it comes to tasks.

I like it, when you attach it to a balloon you can even sync it to the clouds!

> 
> May 13, 2023, 23:01 by s.je...@gmail.com:
> 
> > Heyhey!
> >
> > Страхиња Радић  wrote:
> >
> >> On 23/05/12 02:11PM, LM wrote:
> >> > I'd be curious to know what tools other people use on the list to
> >> > handle organizational jobs such as time and task scheduling, todo
> >> > lists, habit tracking, displaying/printing calendars, etc.  Any
> >> > recommendations?  If you use more than one application, which programs
> >> > work together or chain well?  Thanks.
> >>
> >> http://codemadness.org/todo-application.html
> >>
> >
> > Just chiming in with that years ago I was trying out taskwarrior as
> > well but after neglecting this system for years I have simply used a
> > ~/TODO.txt file at work.
> >
> > I always order the items in there according to priority and delete the
> > items I have finished using vim. This system has worked very well for
> > me and I haven't seen a need to change it yet. Your mileage may vary!
> >
> > Cheers,
> > Silvan
> >
> 
> 

-- 
Kind regards,
Hiltjo

Re: [dev] Simpler WiFi alternatives

[Hiltjo Posthuma]

On Sat, May 13, 2023 at 12:05:24AM -0700, Jeremy wrote:
> On 05/13/23 10:55AM, NRK wrote:
> > On Fri, May 12, 2023 at 10:10:31PM +0200, Yan Doroshenko wrote:
> > > Hello everyone,
> > > 
> > > I'd like to take a moment and thank everyone for an extremely polite,
> > > respectful and to the point discussion regarding the topic at hand. I was
> > > immensely pleased to have witnessed such a splendid display of a real
> > > community spirit as well as an immense level of professionalism. No doubt
> > > everyone involved is absolutely content with himself as well as his 
> > > actions
> > > and would have no doubt conducted the same way were it a face to face
> > > discussion.
> > 
> > It is true that this thread has been a massive cesspool. But
> > passive-aggressive replies like this does not help the situation - it
> > only contributes more to the cesspool.
> > 
> > - NRK
> > 
> 
> Have a look at the comment which Mr. Doroshenko was replying to. 
> 
> Personally, I couldn't agree more with Yan. It may seem passive-agressive
> but I believe English is not Mr. Doroshenko's first language, so I
> wouldn't be surprised by the "over-the-top" language.
> (your English is very good, by the way, Mr. Doroshenko)
> 
> Anselm & Hiltjo, suckless veterens(or at least the ones I see most often
> in the suckless threads), kept a cool head & have always refused to engage
> divisive rhetoric(name calling, all-caps, appeals to 1940s facism, etc).
> 

Speaking for myself.  I haven't always keep a cool head.  We're not robots and
only a human bean after all.

> The name-calling does make me a little sad("troll", "loser", "Nazi"),
> along with the characterizations of people's contributions to this
> thread("troll post", "garbage").
> 
> I'd like to think that there are feds(the "glow-in-the-dark" variety) or
> "competitors" sent to this mailing-list to try to trigger our insecurities
> & cause suckless to fragment, but that suckless is already inoculated &
> preoccupied with its own inner-self-criticism to be affected by outside
> forces.
> 
> Moderation in this mailing list is highly disciplined & I'm unironically
> impressed. Thank you.
> 

I don't remember the last time suckless ever banned someone on the mailinglist,
but it's not impossible.

> Jeremy
> 

-- 
Kind regards,
Hiltjo

Re: [dev] Simpler WiFi alternatives

[Hiltjo Posthuma]

On Fri, May 12, 2023 at 11:39:43AM -0700, Jeremy wrote:
> On 05/12/23 08:27AM, Lee Phillips wrote:
> > Since the administrators of this list are unable or unwilling to block 
> > access to this loser, I'm unsubscribing. I don't need this kind of garbage 
> > in my inbox. I have plenty of other kinds of garbage already.
> > 
> > 
> > Lee
> 
> [...]
> 
> Even if we agreed that Fossy has nothing to contribute here, I believe
> they are physically unable to block Mr. Fossy, simply because this kind
> of moderation is costly.
> 

Just for your info.  The message was only posted a few hours ago and I was
doing other things this day.

I think most people know whats an effective/good/"acceptable" way to
communicate.

Treat others how you want to be treated (very woke and uncool, I know).

-- 
Kind regards,
Hiltjo

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

[Hiltjo Posthuma]

On Sat, Apr 08, 2023 at 11:02:56PM +0200, Storkman wrote:
> On Sat, Apr 08, 2023 at 04:28:15PM +0200, p...@mailbox.org wrote:
> > Hello everyone,
> > 
> > I bind keyboard shortcut to launch dmenu_extended[1] in dwm, what works
> > flawlessly before the `Use sigaction(SA_NOCLDWAIT) for SIGCHLD
> > handling` [1] commit, since dmenu_extended does not change anything here,
> > is this a regression or bug introduced with this commit or
> > dmenu_extended need to adapt to conform the change? thanks.
> 
> From sigaction(2):
> > A child created via fork(2) inherits a copy of its parent's signal 
> > dispositions.
> > During an execve(2), the dispositions of handled signals are reset to the 
> > default;
> > the dispositions of ignored signals are left unchanged.
> 
> This would explain why running programs affected by this through st works,
> since it runs "signal(SIGCHLD, SIG_DFL)" before executing the shell 
> (st.c:715).
> 
> Adding "signal(SIGCHLD, SIG_DFL)" before execvp in spawn() at dwm.c:1657 fixes
> anki and mpv with youtube-dl for me.
> 
> > 
> > [1] https://github.com/MarkHedleyJones/dmenu-extended/
> > [2] 
> > https://git.suckless.org/dwm/commit/712d6639ff8e863560328131bbb92b248dc9cde7.html
> > 
> 

Thanks,

I've committed a fix based on your suggestion to dwm.
I also committed it for tabbed as it had a similar change.

If there are further iterations or patch suggestions feel free to reply,

-- 
Kind regards,
Hiltjo

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

[Hiltjo Posthuma]

On Sat, Apr 08, 2023 at 07:24:07PM +0200, p...@mailbox.org wrote:
> - patch is disabled
> - `dwm 2> ~/dwm.log` shows nothing
> 
> define command as
> 
> static const char *dmenu_extend[] = { "dmenu_extended_run", NULL };
> 
> bind the command to a keyboard shortcut
> 
> static Key keys[] = {
> MODKEY,   XK_o,  spawn,  {.v = 
> dmenu_extend } },
> ...
> };
> 
> same config, revert to 89f9905 dmenu_extend just works.
> 
> On 08.04.23 21:45, NRK wrote:
> > Hi,
> > 
> > On Sat, Apr 08, 2023 at 04:28:15PM +0200, p...@mailbox.org wrote:
> > > I bind keyboard shortcut to launch dmenu_extended[1] in dwm, what works
> > > flawlessly before the `Use sigaction(SA_NOCLDWAIT) for SIGCHLD
> > > handling` [1] commit, since dmenu_extended does not change anything here,
> > > is this a regression or bug introduced with this commit or
> > > dmenu_extended need to adapt to conform the change? thanks.
> > 
> > You'll need to provide more information. What does your config look
> > like? Does dwm print any error message to stderr? Did you try to
> > reproduce with a vanilla dwm? Etc.
> > 
> > Without providing more information it's not possible to say what's going
> > on here, especially because that commit doesn't really do anything to
> > process launching. Which takes me to the question, how did you verify
> > that it's this commit that's causing the problem?
> > 
> > Because the commit right before it (89f9905 grabkeys: Avoid missing
> > events when a keysym maps to multiple keycodes) seems like something
> > that might actually mess with keybinds. (Try changing your
> > dmenu_extended keybind to something else and see if that works or not).
> > 
> > - NRK
> > 
> 

Hi,

Please provide more information about your operating system etc.

This is with vanilla dwm and only the above change applied? (If not please do
so).

Thanks,

-- 
Kind regards,
Hiltjo

Re: [dev] [DEV][Quark] Big problem

[Hiltjo Posthuma]

On Sat, Feb 25, 2023 at 09:50:42AM -0500, fo...@dnmx.org wrote:
> Hello.
> Before I start, I want to clarify 2 things:
> 1. I'm not 100% sure if it's a Quark problem, but there are like 2/4th
> chance that it is.
> 2. I'm hosting my site over the Tor network
> 
> Problem I have: software runs, can access it from localhost via curl, but
> cannot access it from Tor
> 
> What happens when I try to access it from Tor? it seems to connect,
> but 0 bytes get transmited
> 
> wtf it suddendly started working
> 
> usually the fix is NOT restarting Tor, but restarting the jail and
> with it - Quark.. but it works via curl, which is confusing..
> 
> Not sure if Quark problem or Tor problem
> 
> In Quark log I get a message 'dropped'
> 
> I'd like to know if there's something I can do, like what key-words to
> look in Tor's logs
> 
> Also to mention: I am getting DDoS-ed for days now xD
> 
> I don't see any excessive CPU or memory usage, really - one of reasons
> I use Quark and a static web-site
> 
> 
> The main reason I think it's Quark's problem: restarting a FreeBSD jail
> with Quark running makes everything work again. This is also why I said
> 2/4 - 1/4 is Tor possible faulty, and the last 1/4 is perhaps something to
> do with FreeBSD jails.
> 
> The reason I thikn it's not Quark's problem: I can access it well with
> curl on localhost lol
> 
> I also wonder what "-   dropped   -" means.. and why is there no local
> interface IP address (the 1st '-')?
> 
> I helped with the logging to files with Quark bug, now I hope someone can
> help me with this.
> 
> 

Hi,

Have you tried watching the TOP 10 Quark Life Hacks video to solve the BIG
PROBLEM?

https://www.youtube.com/embed/SqaOZLuQfPg

Hope this helps and you'll get out of jail soon,

-- 
Kind regards,
Hiltjo

Re: [dev] dwm 6.4 compilation error on FreeBsd

[Hiltjo Posthuma]

On Thu, Feb 16, 2023 at 06:07:02PM +1300, beastie wrote:
> Hello I am experiencing an error when trying to compile the latest
> version of dwm from https://git.suckless.org/dwm,
> 
> Here is the commit that I think is causing the issue:
> https://git.suckless.org/dwm/commit/712d6639ff8e863560328131bbb92b248dc9cde7.html
> 
> here is the error output: https://pst.moe/paste/pdnucy
> 
> Thanks,
> Beastie
> 

Hello,

Just a reminder again to you (and others) to really send more information about
your system and how to reproduce the issue.  For example which version of
FreeBSD do you use?

I have some older FreeBSD 10 or 11 system somewhere I think, so will test it
with that, probably this weekend,

-- 
Kind regards,
Hiltjo

Re: [dev] bump copyright years?

[Hiltjo Posthuma]

On Wed, Feb 08, 2023 at 09:23:45PM +, Al wrote:
> This isn't in response to any single email in the thread, just putting my two 
> cents in :)
> 
> It isn't quite accurate to say that year of creation/publication is never 
> relevant. The year is relevant whenever copyright assignment is done. After, 
> all, if a corporation (or possibly a non-profit) owns a copyright, it is not 
> expected there will ever be a "death date" to add 75 years to.
> 
> Instead, afaik (for USA at least -- and I suppose many jurisdictions follow 
> suit), corporate copyright expires either 95 years after publication or 120 
> years after creation, whichever comes soonest.
> 
> In general, for individual contributions, I agree it is pointless to specify 
> a year. However, it's not always black-and-white.
> 
> Then again, I believe all suckless development is entirely done with Git 
> these days. So surely the datetime information recorded in each commit makes 
> the question moot?
> 
> If for no other reason, I would vote for dropping the year simply because 
> it's inelegant to manually track information that Git already records for us 
> automatically.

Theres no voting or democracy and it is not your decision to make.
> 
> .:AL:.
> 

-- 
Kind regards,
Hiltjo

Re: [dev] [st] terminfo entries won't get deleted

[Hiltjo Posthuma]

On Thu, Feb 02, 2023 at 10:33:55PM +, danin-sac wrote:
> Hi,
> after looking in the Makefile I saw that the terminfo entries wouldn't get 
> deleted if you uninstall the program. Is there a specific reason for that?
> 
> Best regards.
> 

maybe

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] Obtain focused monitor

[Hiltjo Posthuma]

On Sun, Jan 08, 2023 at 07:40:21PM +0900, A Farzat wrote:
> On 23/01/08 11:32am, Hiltjo Posthuma wrote:
> > On Sun, Jan 08, 2023 at 07:19:10PM +0900, A Farzat wrote:
> > > Is there a way to obtain the currently focused monitor in dwm? I want to
> > > use it in my script to control which monitor gets its brightness
> > > modified.
> > > 
> > > Regards,
> > > Farzat
> > 
> > selmon
> > 
> > -- 
> > Kind regards,
> > Hiltjo
> > 
> 
> And how do I access that command? If possible I want to access it from
> a shell script.
> 
> I am open to modifying the dwm source code if necessary.
> 
> Regards,
> Farzat

Hi,

For example using the dmenumon variable, it is set in spawn():
http://git.suckless.org/dwm/commit/ba56fe9fea0a28d8184a727a987836a0903e2682.html

Hope this helps,

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] Obtain focused monitor

[Hiltjo Posthuma]

On Sun, Jan 08, 2023 at 07:19:10PM +0900, A Farzat wrote:
> Is there a way to obtain the currently focused monitor in dwm? I want to
> use it in my script to control which monitor gets its brightness
> modified.
> 
> Regards,
> Farzat

selmon

-- 
Kind regards,
Hiltjo

Re: [dev] [ii] connect to servers with self signed tls certificates

[Hiltjo Posthuma]

On Sat, Oct 29, 2022 at 11:38:10AM -0500, fernandoreyesavila3 wrote:
> Hello all,
> 
> I am hosting an ergo irc server with self signed certificates.
> Connecting to any public irc server works as expected. ii prints the
> following when I try to connect to my server.
> 
> $ ii -s servername.com -p 6697
> NICK nando
> USER nando localhost servername.com :nando
> 
> ii: remote host closed connection: No such file or directory
> 
> I patched ii with tls encryption support and ran
> 
> $ ii -t -s servername.com -p 6697
> ii: tls_handshake: certificate verification failed: self signed certificate
> 
> I connected through hexchat by accepting invalid ssl certificates.
> Is there a similair option for ii? Any help would be appreciated.
> 
> Best,
> Fernando
> 

Hi,

With LibreSSL libtls: you could set a certificate file:

https://man.openbsd.org/tls_config_set_ca_file

Maybe you could add a command-line flag that allows to set this certificate so 
it
can be set per server.

Just an idea,

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] dmenu dwm wrong screen

[Hiltjo Posthuma]

On Fri, Oct 28, 2022 at 11:07:44AM +0200, Yan Doroshenko wrote:
> Helo,
> 
> 
> I have a strange behavior of dmenu inside dwm with two monitors. dmenu is
> displayed on the screen with the mouse cursor (instead of the active one) if
> there are no windows open on any screen. Otherwise it works fine.
> 
> 
> Is this expected behavior?
> 
> 
> Thanks,
> 
> Yan
> 
> 

Hi,

Thanks for reporting it. It was changed in dwm 6.4, but since multiple users
has asked (it doesn't seem to be some edge-case) I've reverted back the change
in the git version of dwm.

See also:
https://git.suckless.org/dwm/commit/ba56fe9fea0a28d8184a727a987836a0903e2682.html
https://git.suckless.org/dwm/commit/c2b748e7931e5f28984efc236f9b1a212dbc65e8.html

-- 
Kind regards,
Hiltjo

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

[Hiltjo Posthuma]

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

Wouldn't it just free the memory on program exit by the operating system?

In this case I don't see the issue becaus it doesn't memory leak over time.

Let me know if I missed something,

-- 
Kind regards,
Hiltjo

Re: [dev] Some questions on communication suckless style

[Hiltjo Posthuma]

On Wed, Oct 19, 2022 at 07:41:19AM +0200, Laslo Hunhold wrote:
> On Wed, 19 Oct 2022 00:49:57 +
> Rodrigo Martins  wrote:
> 
> Dear Rodrigo,
> 
> > toxic is a curses command line interface for the tox protocol. With
> > it you can do group audio calls and one on one video calls. toxic
> > doesn't (yet?) let you share your screen, but other tox clients, like
> > qtox, do.
> > 
> > I won't say it is suckless, but it is somewhat close. One could
> > easily use the tox library to implement a suckless tox client, take a
> > look at some echo bot code examples.
> 
> Dimitris Papastamos, z3bra and I had worked on ratox[0] (with useful
> scripts here[1]), a suckless Tox-client, back in 2014. After the second
> toxcore-API-iteration within a few months we were fed up with it,
> though, and the project was put on hold.
> 
> It was inspired by ii (FIFO-based-model), and we had some pretty cool
> state-machine-magic going on there. Ratox, among other things, even
> supported voice and video calls via FIFO, which was really cool!
> 

One of the nice features worth highlighting about it I think was you could also
use any binary stream (not just voice and audio) over it.

For example I briefly tested a VNC connection over the Tox protocol and it
worked quite well.

> If you're looking for a project, bringing this back up to speed with
> mainline-toxcore might be a nice thing. :)
> 
> With best regards
> 
> Laslo
> 
> [0]:http://git.2f30.org/ratox/log.html
> [1]:http://git.2f30.org/ratox-nuggets/log.html
> 

-- 
Kind regards,
Hiltjo

Re: [dev] Some questions on communication suckless style

[Hiltjo Posthuma]

On Fri, Oct 14, 2022 at 01:56:52PM -0500, fernandoreyesavila3 wrote:
> Hello,
> 
> I recently got my friends and I on irc through irssi. I am looking for a
> way to do screen sharing and voice chat. I looked at the suckless page
> and it doesn't include recomendations for voice chat besides xmpp which
> I could use jingle with, but the profanity nor mcabber support jingle. I
> also checked cat -v harmful and all I got was that xmpp is bad. I've
> looked at jitsi but it felt redundant to me to have irc if I was going
> call through xmpp. I'd also prefer to use a command line based interface.
> 
> Any recomendations on voice chat/screensharing true to the suckless
> philosophy would be appreciated.
> 
> Fernando
> 

Hi,

Probably not suckless-approved(tm), but my recommendation would be mumble for
voice-chat and VNC (over some SSH tunnel probably) for screen sharing.

Or maybe: https://en.wikipedia.org/wiki/Tin_can_telephone :)

-- 
Kind regards,
Hiltjo

[dev] json2tsv 1.0 release - a tool to convert JSON to TSV

[Hiltjo Posthuma]

Hi all,

I would like to share the 1.0 release of my project json2tsv.

json2tsv is a tool to convert JSON to TSV.

json2tsv reads JSON data from stdin. It outputs each JSON type to a TAB-
Separated Value format per line by default. A different field and record
separator can be set (than a TAB and newline).

The default output format is:
nodenametypevalue

The type field is a single byte and can be:

* a for array
* b for bool
* n for number
* o for object
* s for string
* ? for null

There is a shellscript wrapper included called "jaq" that uses awk as a sort of
"query language". This can be used in a similar way like jq(1), except you
don't have to learn some new jq-specific meta-language.

An example:

echo '{"url":"https://codemadness.org/"}' | \
jaq '$1 == ".url" { print $3 }'

A more detailed write-up is on my blog and phlog:
Blog: https://codemadness.org/json2tsv.html
Phlog: gopher://codemadness.org/1/phlog/json2tsv

It can be found at:
  * git://git.codemadness.org/json2tsv
  * gopher://codemadness.org/1/git/json2tsv
  * https://codemadness.org/releases/json2tsv/
  * gopher://codemadness.org/1/releases/json2tsv/

The tool has few dependencies and includes its own JSON parser in json.{c,h}.
Extensively tested and tested with a testsuite.

I would like to thank all people who gave feedback and have sent patches
and I hope this project is useful to others as well,

-- 
Kind regards,
Hiltjo

Re: [dev] Broken link in /faq/

[Hiltjo Posthuma]

On Wed, Aug 31, 2022 at 08:41:51PM +0200, Страхиња Радић wrote:
> The first link in
> 
> https://suckless.org/faq/
> 
> http://freecode.com/articles/stop-the-autoconf-insanity-why-we-need-a-new-build-system
> 
> seems to be broken. Just wanted to ask if it is ok for me to replace it with
> 
> https://web.archive.org/web/20181118080003/http://freshmeat.sourceforge.net/articles/stop-the-autoconf-insanity-why-we-need-a-new-build-system
> 
> Cheers,
> Strahinya

Hi,

Fine with me :)

Thanks,

-- 
Kind regards,
Hiltjo

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

[Hiltjo Posthuma]

On Tue, Aug 30, 2022 at 09:11:03PM +0600, NRK wrote:
> On Tue, Aug 30, 2022 at 04:50:14PM +0200, Hiltjo Posthuma wrote:
> > Then write a patch to improve it instead of whining about it.
> 
> The topic was font fallback; I adviced not to replicate drw, explained
> my reasoning why, and then adviced to look into ST instead.
> 
> I don't see any whining.
> 
> - NRK
> 

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

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

This part specificly. The tone if very whiny. It doesn't help complaining
the code is a mess or improper without proposing a patch.

-- 
Kind regards,
Hiltjo

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

[Hiltjo Posthuma]

On Tue, Aug 30, 2022 at 08:08:21PM +0600, NRK wrote:
> On Tue, Aug 30, 2022 at 11:42:33AM +0900, Pontus Stenetorp wrote:
> > My intuition is that it is related to font loading and fall backs, so
> > I am tempted to take a stab at it by comparing the font
> > loading/handling between tabbed, dwm, st, and sent to see if I can
> > spot any difference, as the latter three have no issues. If I am
> > correct, it should not be an awfully difficult patch.
> 
> The font fallback in dwm and dmenu is handled via libsl (i.e drw.c) and
> it's a huge mess [0].
> 
> The way it works is also very inefficient (it calls XftFontMatch() for
> every single "unknown" code-point). The `nomatches` cache is merely
> there to stop the bleeding and is not really a proper fix.
> 
> I wasn't very happy with the situation and had intended to rework the
> system to be something more simple, sensible and efficient. But I'm not
> sure if what I have planned is even possible with Xft/FontConfig or not.
> And quickly grepping through the function list wasn't that helpful. I'll
> probably have to allocate more time to read the docs properly.
> 
> But in any case I absolutely do NOT recommend trying to replicate drw's
> approach. Not sure what ST is doing, so that might be worth taking a
> look into instead.
> 
> [0]: https://git.suckless.org/libsl/file/drw.c.html#l251
> 
> - NRK
> 

Then write a patch to improve it instead of whining about it.

To be honest we all know the code is not perfect and never will be.

When rewriting it also be mindful of peoples preferences.

-- 
Kind regards,
Hiltjo

Re: [dev] Re: [sacc][PATCH] Infer the (n)curses(w) library to use and -l

[Hiltjo Posthuma]

On Wed, Aug 17, 2022 at 03:31:33PM -0300, Spenser Truex wrote:
> On 22/08/16 10:04AM, Quentin Rameau wrote:
> > Hi Spenser,
> >
> > > Useful since curses cocks up any portability here. We prioritise the
> > > user's entries in CURSESLIB where possible, and use LIBS when pkg-config
> > > cannot be used.
> >
> > Indeed, dealing with *ncurses* is a mess.
> > Ideally, we would only link against terminfo,
> > because that's what sacc needs, not curses,
> > but sadly this is implemented in most system
> > through ncurses.
> >
> > > An opinioned change (maybe the user should just figure this stuff out
> > > himself or curses should be fixed).
> >
> > As a result, there is no good simple way to deal with that,
> > and I prefer letting the user dealing with their system,
> > because they should know better
> > (with the potential help of documentation)
> > how it is setup.
> 
> The goal of this patch is to just "be helpful" rather than silently not
> building with some opaque messages about ld.
> 
> > Regarding the patch itself, besides the actual target idea,
> > I prefer to keep the Makefile POSIX-compatible
> > and you're introducing GNU make style operators.
> 
> POSIX make doesn't appear to have $(shell) which is the main thing used
> here. Instead the commands could be run inside a recipe somehow.
> 
> (posix make documentation): https://pubs.opengroup.org/onlinepubs/9699919799/
> 
> > I'm not motivated to change the way we link against terminfo,
> > at least not that way,
> > but maybe we could introduce a comment there
> > explaining that ncurses is a mess, but that already sounds like
> > something most people would already know???
> 
> For a comment, mentioning pkg-config --libs would be sufficient.
> 
> > In any case, thanks for your patch Spenser,
> > and I hope you'll still find sacc useful,
> >
> > cheers!
> >
> > P.S.: sacc isn't really a suckless.org project, although I suppose
> > people will not mind too much having it discussed there.
> 
> 
> I'm satisfied with adding a comment as a solution and will submit a
> patch. Then I will remember what to do the next time I compile sacc in
> a couple of years.
> 

100% customer satisfaction guaranteed

> --
> CAEE B377 FC82 BAF9 102C  D22F C5CE D003 1AA8 E281
> Spenser Truexhttps://equwal.com



-- 
Kind regards,
Hiltjo

Re: [dev] [lsw][bug] segfault after querying window with no children

[Hiltjo Posthuma]

On Sat, Jun 25, 2022 at 01:50:17AM +, Augusto Castelo wrote:
> Hi,
> 
> lsw crashes with a segfault when you pass a window id of a window with no 
> children.
> 
> I spotted the problem, at line 39 of lsw.c; XQueryTree isn't failing but is 
> setting `n` (children count (unsigned int)) to 0, later on `n` is used to 
> loop throgh the children, in the first iteration [n-1] >= [0] is 
> true when `n` is equal to 0 (because n-1 will evaluate to UINT_MAX) and then 
> calling XGetWindowAttributes on that address produces a segfault.
> 
> lsw-version: 0.3
> lsw-commit-hash: 4d6e1b3
> 
> Cheers!
> 

Hi Augusto,

Thanks reporting it. I pushed a fix to the repo. Let me know if it doesn't work
for you.

I also pushed a few code-style and cleanup improvements.

Thanks,

-- 
Kind regards,
Hiltjo

Re: [dev] redirecting standard error to another terminal

[Hiltjo Posthuma]

On Sat, Jun 18, 2022 at 09:03:27AM -0400, Greg Reagle wrote:
> OMG I wish I had known this YEARS ago.  I can redirect the standard error of 
> a program to a different terminal!  I am using X11 and dwm and st on Debian.  
> For example:
> 
> ls --foobar 2> /dev/pts/0
> 
> I am excited by the possibilities and mad at myself for not having thought of 
> doing this before.
> 
> When I am debugging a terminal program that use the whole screen (like a text 
> editor running ncurses) it doesn't really work to have stderr information 
> mixed in with the TUI.  Problem solved!  I can print debugging information to 
> stderr.  Or it would help with debugging something like dvtm.
> 
> Now that I think about it, redirecting stderr to a log file and looking at 
> the log file with tail -f in another terminal would also achieve similar 
> goal, I guess.
> 

You can also do:

dprintf(9, "something\n");

And do:

./program 9>topsecret_debug_log

#mindblown

-- 
Kind regards,
Hiltjo

Re: [dev] Suckless CMatrix clone

[Hiltjo Posthuma]

Hi Ryan,

On Sun, May 29, 2022 at 03:04:00AM -0400, Ryan Raymond wrote:
> Hello all. I'm working on a suckless cmatrix clone.
> It's not done yet, and it still suffers from constant memory leakage, but
> I'm having fun working on it.
> It already shows 50% reduced cpu/ram usage vs cmatrix, despite greatly
> improved fps.  Furthermore, because it doesn't rely on ncurses, it respects
> terminal transparency which is super cool. It works especially well with
> our own st/background-image patch.
> I just wanted to know if it would be possible to host this on suckless.org
> in the future, and what I would have to do to do that.

For reasons, like security I prefer to not host it.

You could host it on your website and link to it from the suckless wiki on the
related projects page.

> I still have so much work to do. but I'm having a blast. This is by far my
> largest original computer program, and my first attempt at an open-source
> project.
> Thanks.

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] Incorrect resolution when turning on dual monitors

[Hiltjo Posthuma]

On Tue, May 24, 2022 at 10:06:21PM -0400, Christopher Brown wrote:
> I am using the latest git version, so I reverted the commit. However,
> I am still experiencing the issue after doing that.
> 
> Christopher
> 
> On Sat, May 7, 2022 at 12:15 PM Hiltjo Posthuma  
> wrote:
> >
> > On Fri, May 06, 2022 at 10:27:32PM -0400, Christopher Brown wrote:
> > > Hello,
> > >
> > > I have been intermittently encountering an issue where dwm messes up
> > > my monitor resolutions when powering on my two monitors. Frequently,
> > > both screens will be combined on one monitor while the other monitor
> > > does not receive input. The "Two independent outputs" section of the
> > > multi monitor dwm documentation seems to describe what I am
> > > experiencing. I tried using the xrandr options it mentions, but I will
> > > still sometimes encounter the issue. Does anyone know how to prevent
> > > this from happening?
> > >
> > > Thank you,
> > > Christopher
> > >
> >
> > Hi Christopher,
> >
> > Do you run the latest git version?
> >
> > Can you try the commit
> > https://git.suckless.org/dwm/commit/d93ff48803f04f1363bf303af1d7e6ccc5cb8d3f.html
> > or if you run the git version revert the commit and see if it solves the 
> > issue?
> >
> > --
> > Kind regards,
> > Hiltjo
> >
> 

Hi Christopher,

OK thanks for testing and reporting back atleast,

I'm not sure what the issue is.

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] Incorrect resolution when turning on dual monitors

[Hiltjo Posthuma]

On Fri, May 06, 2022 at 10:27:32PM -0400, Christopher Brown wrote:
> Hello,
> 
> I have been intermittently encountering an issue where dwm messes up
> my monitor resolutions when powering on my two monitors. Frequently,
> both screens will be combined on one monitor while the other monitor
> does not receive input. The "Two independent outputs" section of the
> multi monitor dwm documentation seems to describe what I am
> experiencing. I tried using the xrandr options it mentions, but I will
> still sometimes encounter the issue. Does anyone know how to prevent
> this from happening?
> 
> Thank you,
> Christopher
> 

Hi Christopher,

Do you run the latest git version?

Can you try the commit
https://git.suckless.org/dwm/commit/d93ff48803f04f1363bf303af1d7e6ccc5cb8d3f.html
or if you run the git version revert the commit and see if it solves the issue?

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] Multihead Issues Autostart

[Hiltjo Posthuma]

On Sun, May 01, 2022 at 12:56:50PM +0200, Yan Doroshenko wrote:
> Hello,
> 
> 
> I'm using DWM on two monitors with cool_autostart patch and in the autostart
> array I'm running xrandr to set the monitor layout.
> 
> Quite often a situation happens when the second monitor is enabled (arandr
> displays it as active and in correct position, feh sets the background on
> it), but is unrecognized by DWM (there's no panel on it and windows can not
> be moved onto it). Any change in display layout fixes the issue and DWM
> recognizes the second screen.
> 
> 
> Do you have any ideas as to why it can be happening?
> 
> 
> Thanks,
> 
> Yan
> 

Can you try the latest git version (without patches)?

-- 
Kind regards,
Hiltjo


signature.asc
Description: PGP signature

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

[Hiltjo Posthuma]

On Thu, Apr 28, 2022 at 12:19:07PM +0200, Laslo Hunhold wrote:
> On Thu, 28 Apr 2022 08:34:36 +0600
> NRK  wrote:
> 
> Dear NRK,
> 
> > Recently noticed that the dwm and st logo was removed from their
> > homepages[0][1].
> > 
> > I was wondering if there's any specific reason for that, or if there's
> > plan for a new logo(s)?
> > 
> > I atleast really liked the current logos, as they reflect the
> > simiplicity of the software quite nicely :)
> > 
> > [0]: https://dwm.suckless.org
> > [1]: https://st.suckless.org
> 
> I made the logos a few years ago and Hiltjo removed them recently. I
> also liked them very much and would like to see them included again, but
> respect that it's his discretion to remove them as he is the maintainer.
> 
> What do the others think?
> 
> With best regards
> 
> Laslo
> 

Hi Laslo,

Sure I don't mind you added them back.
With the inverted colors they are visible here.

-- 
Kind regards,
Hiltjo

Re: [dev][st] Solution: UTF-8 needs IBus!

[Hiltjo Posthuma]

On Tue, Apr 26, 2022 at 05:38:51PM -0500, Robert Winkler wrote:
> On Tue Apr 26, 2022 at 4:21 PM CDT, Κράκ Άουτ wrote:
> > Στις 26 Απρ 2022 23:59, ο/η Robert Winkler έγραψε:
> > > To make a long story short: The input of UTF-8 characters with st needs
> > > an IBus daemon (standard on Gnome, but not on other window managers such
> > > as Plasma, dwm, ..).
> > >
> > > I added to ~/.config/autostart:
> > >
> > > `Ibus-Daemon.desktop`
> > >
> > > ~~~
> > > [Desktop Entry]
> > > Name=IBus Daemon
> > > Type=Application
> > > Exec=ibus-daemon -drx
> > > Terminal=false
> > > ~~~
> > >
> > > Thanks for all your ideas!
> > >
> >
> > Well, UTF-8 or st definitely do not need IBus, I haven't it installed on
> > my system and everything works fine. Yet if it provides a solution, go
> > for it.
> >
> > Just in case they may help you avoid IBus, my Debian system (systemd
> > multi-user.targer, no Display Manager, X started by startx) related etc
> > files:
> >
> > cat /etc/default/locale
> > LANG="el_GR.UTF-8"
> >
> > cat /etc/default/keyboard
> > XKBMODEL="pc105"
> > XKBLAYOUT="us,gr"
> > XKBVARIANT=","
> > XKBOPTIONS="grp:caps_toggle,numpad:mac,grp_led:caps"
> 
> Well, I don't understand the details; I found this solution by testing
> all possibilities mentioned on the mailing list or found in duckduckgo
> searches. The key for me was the different behavior in Gnome.
> 
> I verified the IBus solution on an armbian64 SBC (who really benefits
> from suckless programs):
> 
> 1) Installation and configuration of ibus.
> 2) Autostart of ibus-daemon.
> 3) Installation of im-config and defining ibus as default.
> 
> Maybe it is useful for someone.
> 
> Best regards,
> Robert 
> 

Hi Robert,

I think you meant to say your specific Input Method Editor (IME) requires ibus.

Good to know your configuration problem is fixed now,

-- 
Kind regards,
Hiltjo

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

[Hiltjo Posthuma]

On Thu, Apr 28, 2022 at 08:34:36AM +0600, NRK wrote:
> Hi,
> 
> Recently noticed that the dwm and st logo was removed from their
> homepages[0][1].
> 
> I was wondering if there's any specific reason for that, or if there's
> plan for a new logo(s)?
> 
> I atleast really liked the current logos, as they reflect the
> simiplicity of the software quite nicely :)
> 
> [0]: https://dwm.suckless.org
> [1]: https://st.suckless.org
> 
> - NRK
> 

Hi NRK,

Recently dark mode CSS support was added to the site.

It was reported on IRC the logo's were not visible with them.

I think these logos are a bit pointless, they just look like text, but less
clear.

-- 
Kind regards,
Hiltjo

Re: [dev][st][dwm] st UTF-8 works on Gnome, but not on DWM

[Hiltjo Posthuma]

On Tue, Apr 26, 2022 at 08:20:34AM -0500, Robert Winkler wrote:
> Getting closer: I tried the compiled st in different window managers
> (thanks for the hint to test the binary in different environments!).
> 
> In Plasma, spectrwm, and dwm, UTF-8 of st does not work.  
> 
> But SURPRISE: in Gnome (Wayland, PoP OS! 22.04 LTS), it does!
> 
> This means that the compiled st is working fine, but something strange
> is happening related to the environment. But what?
> 
> Anyone has an idea, what could be the difference between Gnome and DWM
> with respect to the font encoding?
> 
> 

My guess it's still the locale environment somehow (despite the previous posted
locale environment values looking good).

Maybe the Gnome session thingy sets the proper values, but your script or
session file which launches dwm (which spawns st) doesn't have it set?

Just a random guess,

Good luck,

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] possible regression in 8806b6e

[Hiltjo Posthuma]

On Mon, Apr 25, 2022 at 05:38:35PM +0100, Chris Down wrote:
> Hiltjo Posthuma writes:
> > Whats the similar issue exactly? Does this issue also happen when bisecting 
> > the
> > same commit (so its a also regression)?
> 
> For 8806b6e23793 ("manage: propertynotify: Reduce cost of unused size
> hints"), the issue is that c->isfixed may not be set early, which might
> affect whether we intend to make the window floating or not.
> 
> For bece862a0fc4 ("manage: For isfloating/oldstate check/set, ensure trans
> client actually exists"), the issue is that some non-SDL client which
> actually _should_ float have WM_TRANSIENT_FOR set to the root window. I
> posted about this on hackers@ a few weeks ago.[0]
> 
> For 8806b6e23793, I think the change I suggested should be sufficient, but
> would like to get confirmation from Ethan first and then will submit it as a
> proper patch.
> 

Yes please

> For bece862a0fc4, I think it might just need to be reverted unless more
> specific logic can be applied, since it seems over the top to add more logic
> just to reliably distinguish SDL clients from other affected clients.
> 

I've reverted the patch. It can be reworked to fix both issues (the regression 
and the initial
reason it was posted) maybe.

> In both cases the symptoms are that some subset of clients may not float
> when they should, but in the case of 8806b6e23793 it's "fixed" windows where
> the dimensions are fixed in size hints, and in the case of bece862a0fc4 it's
> windows with WM_TRANSIENT_FOR set to the root window (like the gpg2
> pinentry).
> 
> 0: https://lists.suckless.org/hackers/2203/18220.html

-- 
Kind regards,
Hiltjo


signature.asc
Description: PGP signature

Re: [dev] [dwm] possible regression in 8806b6e

[Hiltjo Posthuma]

On Mon, Apr 25, 2022 at 04:00:21PM +0200, Jochen Sprickerhof wrote:
> Hi Chris,
> 
> * Chris Down  [2022-04-25 14:47]:
> > I'm still unable to reproduce the issue, but I am curious, does this fix
> > things? :-)
> > 
> > diff --git a/dwm.c b/dwm.c
> > index 0fc328a..f2a10c0 100644
> > --- a/dwm.c
> > +++ b/dwm.c
> > @@ -1061,6 +1061,7 @@ manage(Window w, XWindowAttributes *wa)
> > XSetWindowBorder(dpy, w, scheme[SchemeNorm][ColBorder].pixel);
> > configure(c); /* propagates border_width, if size doesn't change */
> > updatewindowtype(c);
> > +   updatesizehints(c);
> > updatewmhints(c);
> > XSelectInput(dpy, w, 
> > EnterWindowMask|FocusChangeMask|PropertyChangeMask|StructureNotifyMask);
> > grabbuttons(c, 0);
> > 
> > My guess is that the pinentry that you're using relies on early
> > c->isfixed logic, whereas the one Sebastian and I are using relies on
> > WM_TRANSIENT_FOR, so the issue I reported and the one you reported have
> > different causes, despite having different symptoms.
> > 
> > If this fixes it, please let me know and I'll send it as a proper patch.
> 
> This fixes a similar issue for me.
> 
> Thanks!
> 
> Jochen

Whats the similar issue exactly? Does this issue also happen when bisecting the
same commit (so its a also regression)?

-- 
Kind regards,
Hiltjo


signature.asc
Description: PGP signature

Re: [dev] Bye

[Hiltjo Posthuma]

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

This page describes how to unsubscribe:

https://suckless.org/community/

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] possible regression in 8806b6e

[Hiltjo Posthuma]

On Sat, Apr 23, 2022 at 12:39:28AM +0100, Ethan Marshall wrote:
> Hi all,
> 
> I recently noticed that certain dialog windows (such as the Chromium
> system printing dialog and gpg-askpass popups) were being managed as
> tiled windows, rather than floating. This changed recently, so I
> bisected down to this commit:
> 
> 8806b6e2379372900e3d9e0bf6604bc7f727350b is the first bad commit
> commit 8806b6e2379372900e3d9e0bf6604bc7f727350b
> Author: Chris Down 
> Date:   Thu Mar 17 15:56:13 2022 +
> 
> manage: propertynotify: Reduce cost of unused size hints
> ...
> 
> dwm/dwm.c | 8 +---
> 
> Is this intended behavior? Or is this a bug introduced by this patch?
> 
> Thanks
>   Ethan
> 

Hi,

Thanks for the report. It is not known and intended behavior. The patch
shouldn't cause a regression.

@Chris: can you look at it and see if this is an actual regression and send an
updated patch if it is?

Thanks,

-- 
Kind regards,
Hiltjo

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

[Hiltjo Posthuma]

On Tue, Apr 19, 2022 at 07:09:57PM -0500, Robert Winkler wrote:
> 
> 
> On April 15, 2022 2:23:36 PM CDT, Quentin Rameau  wrote:
> >Hi Robert,
> >
> >> Hi, according to the st Status, UTF-8 should be working. Much needed for
> >> multilingual typing with ú, ü, ß, µ, ¿ etc.
> >> However, I only get 00e9 if I type é; anything, I need to specify in
> >> config.h?
> >
> >No, you just should only need to declare correctly your LC_CTYPE
> >
> 
> Sorry, but I don't get it fixed. I rebuilt the locals with dpkg-reconfigure 
> locales, with the US UTF-8 as default.
> 
> On lxterminal, the characters é, ö etc. work. In st they don't.
> 
> 
> 

It works in st. It's a misconfiguration on your system.

If you provide more information, not the bare minimum, maybe some people are
kind enough to help you.

-- 
Kind regards,
Hiltjo

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

[Hiltjo Posthuma]

On Thu, Feb 17, 2022 at 11:12:23AM +0100, Страхиња Радић wrote:
> On 22/02/17 01:08, NRK wrote:
> > Assuming there isn't, one alternative could be just using env vars.
> 
> Why would an environment variable be preferable here to a command line
> parameter?
> 
> Environment variables are clunky, messy, insecure, prone to errors, race
> conditions and the whims of a particular setup. They should be avoided 
> whenever
> possible. The suckless way is to have configuration done in config.h instead.
> 
> In this specific example, having a separate dmenumon, which would have to be
> updated, is needed because of C.  It is needed to pass ASCII character for the
> monitor number, which thus has to be constructed by using the expression:
> 
>   '0' + selmon->num
> 
> but we can't use this expression directly in place of dmenumon to initialize
> dmenucmd, because it is not allowed to have non-constant initializer elements 
> in
> C. (Try it as an exercize - you'll get a compilation error.)
> 
> I guess the room for improvement would be to move the code to reassign 
> dmenumon
> to some other (more "optimal") place than spawn function, but I don't see the
> realistic gain from doing that, or need, outside of some abstract purism.

I agree, some advantage I can think of is it would support on a multi-monitor
support with 10 or more monitors. Otherwise I prefer the current code.

-- 
Kind regards,
Hiltjo


signature.asc
Description: PGP signature

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

[Hiltjo Posthuma]

On Wed, Feb 16, 2022 at 05:52:48PM +0600, NRK wrote:
> Hi,
> 
> Currently dmenumon and dmenucmd are hardcoded into spawn(), I noticed
> this after I removed `dmenumon` (as I don't use multimonitor) from
> config.h and saw that the compilation failed.
> 
>   if (arg->v == dmenucmd)
>   dmenumon[0] = '0' + selmon->num;
> 
> While this way of doing things "works", I do wonder if hardcoding things
> like this is the best way to go about solving the issue.
> 
> - NRK
> 

Hi,

Whats the issue and whats the solution/patch?

-- 
Kind regards,
Hiltjo

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

[Hiltjo Posthuma]

On Fri, Feb 11, 2022 at 03:26:12PM +0100, Sebastiano Tronto wrote:
> Hello,
> 
> > I would like to share my project I've been using and tweaking over the 
> > years:
> > 
> > sfeed is a RSS and Atom parser (and it has some format programs).
> > [...]
> 
> Thank you Hiltjo for this nice piece of software. I have been using it
> for a while now and I really enjoy its flexibility. As a testament to
> how versatile sfeed is, let me share the little script that I use to
> browse my feeds [1]. It essentially just builds up on your example
> 
> > #!/bin/sh
> > url=$(curl -s gopher://codemadness.org/0/atom.xml | \
> > sfeed | sfeed_plain | \
> > dmenu -l 35 -i | \
> > sed -n 's@^.* \([a-zA-Z]*://\)\(.*\)$@\1\2@p')
> > test -n "${url}" && $BROWSER "${url}"
> 
> but it allows you to organize your feeds in folders and select the ones
> you want to see with dmenu (to be precise with a dmenu-based filepicker
> [2]). It then dynamically generates a sfeedrc file to show you only
> those feeds.
> 
> [1] https://sebastiano.tronto.net/git/scripts/file/sfeed-browser.html
> [2] https://sebastiano.tronto.net/git/scripts/file/dmenu-filepicker.html
> 
> Best,
> Sebastiano
> 

Hi Sebastiano,

Thanks for sharing the example, I'm glad its useful to others and its flexible
to change to your liking :)

-- 
Kind regards,
Hiltjo

[dev] sfeed: RSS/Atom parser and reader

[Hiltjo Posthuma]

Hi,

I would like to share my project I've been using and tweaking over the years:

sfeed is a RSS and Atom parser (and it has some format programs).

It converts RSS or Atom feeds from XML to a TAB-separated file. There are
formatting programs included to convert this TAB-separated format to various
other formats. There are also some programs and scripts included to import and
export OPML and to fetch, filter, merge and order feed items.

The README file has some examples of some of the functionality which other
programs offer like newsboat/snownews, rss2email, rsstail.  Instructions on how
to use it are also described in the README or the sfeed man pages, like:

man sfeed

One brief example, to stream a single feed into a curses UI:

curl https://codemadness.org/atom_content.xml | sfeed | sfeed_curses

Another example uses the formatting tool sfeed_plain to convert to a plain-text
listing and uses the dmenu vertical menu to open a link in a browser:

#!/bin/sh
url=$(curl -s gopher://codemadness.org/0/atom.xml | \
sfeed | sfeed_plain | \
dmenu -l 35 -i | \
sed -n 's@^.* \([a-zA-Z]*://\)\(.*\)$@\1\2@p')
test -n "${url}" && $BROWSER "${url}"

Screenshot: https://codemadness.org/downloads/screenshots/sfeed-screenshot.png

Multiple feeds can be synced with the included shellscript sfeed_update and the
multiple TAB-separated feed files can then be opened as file arguments with the
format programs. Some formatting programs will then show a sidebar or an index
of the feeds.

For example:

sfeed_curses ~/.sfeed/feeds/*

Screenshot: 
https://codemadness.org/downloads/screenshots/sfeed_curses_screenshot.png

By default sfeed_curses uses xdg-open to open links and the lynx browser to
convert HTML content to plain-text and pipe it to the pager.

sfeed is written in C (and some shellscripts and awk code) and has few
dependencies.

The program can be found at:

  * Git: git://git.codemadness.org/sfeed

  * Git browsing:
* https://git.codemadness.org/sfeed/file/README.html
* gopher://codemadness.org/1/git/sfeed/file/README.gph

  * Release tarballs, currently the latest version is 1.2:
* https://codemadness.org/releases/sfeed/
* gopher://codemadness.org/1/releases/sfeed/

  * Atom feed for releases: https://git.codemadness.org/sfeed/tags.xml

  * Writings:
* https://codemadness.org/sfeed.html
* gopher://codemadness.org/1/phlog/sfeed
* Curses UI with some screenshots.
  * https://codemadness.org/sfeed_curses.html
  * gopher://codemadness.org/1/phlog/sfeed_curses

I hope it is useful to others as it is useful to me and would like to thank all
the people that have given helpful feedback and patches already.

-- 
Kind regards,
Hiltjo

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

[Hiltjo Posthuma]

On Fri, Dec 31, 2021 at 11:33:21AM +0100, Laslo Hunhold wrote:
> On Fri, 31 Dec 2021 11:16:18 +0100
> Hiltjo Posthuma  wrote:
> 
> Dear Hiltjo,
> 
> > In my opinion a practical way is to really test it on different
> > systems (bleeding edge Linux, older Debian stable, NetBSD, OpenBSD)
> > and GNU/Make, different BSD make programs.
> > 
> > This doesn't cover the POSIX compatibility, but some make
> > implementations are not fully POSIX either and this also finds other
> > issues.
> 

To clarify, I did not mean to say this makes a POSIX make lint tool useless.

> yes, this also helped me identify some issues, but as far as I know all
> of them implement e.g. ":=" and "?=" and macros in target rules. Of
> course one might say that it's enough to cover multiple
> implementations, but given there's often no reason to use extensions,
> something like Mattias proposed would really come in handy.
> 
> With best regards
> 
> Laslo
> 

-- 
Kind regards,
Hiltjo

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

[Hiltjo Posthuma]

On Fri, Dec 31, 2021 at 01:52:42AM -0800, Arthur Williams wrote:
> I too fell victim to the GNU trap and thought "?=" was standard and
> actually useful.
> 
> > and want to "dynamically" override it (e.g. in a build system context)
> > when the environment already specifies PREFIX, you either do
> >
> >make -e
> 
> Completely forgot about the -e flag. Now I need to go update all my
> projects and who knows what other GNU-isms I'm unknowingly using.
> 

Hi,

In my opinion a practical way is to really test it on different systems
(bleeding edge Linux, older Debian stable, NetBSD, OpenBSD) and GNU/Make,
different BSD make programs.

This doesn't cover the POSIX compatibility, but some make implementations are
not fully POSIX either and this also finds other issues.

> > that is exactly what I meant earlier on that the POSIX-intended good
> > practices get destroyed by the retarded GNU extensions.
> 
> Yeah you make a strong argument. I too think a linting tool would be
> useful. I imagine it would function like shellcheck does for shells. If
> nothing else it would really help people identify GNU extensions vs
> portable behavior.
> 

-- 
Kind regards / Happy new year,
Hiltjo

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

[Hiltjo Posthuma]

On Wed, Oct 27, 2021 at 03:52:09AM +0600, NRK wrote:
> On Tue, Oct 26, 2021 at 07:51:52PM +, Ian Liu Rodrigues wrote:
> > I've noticed that in some situations wide characters are being cropped
> > on my terminal. The following script, which uses a wide character from
> > the "Nerd Font Symbol"[1], shows a test case:
> > 
> > 
> > echo -e '\e[31m \e[0m c'
> > echo -e '\e[31m  \e[0mc'
> > 
> 
> Hi Liu,
> 
> I remember having the same problem in ST, however it works fine now.
> Looking at my git log I haven't applied any patches for it and even the
> upstream branch works fine for me.
> 
> This might be related to terminfo (5). I won't be delving any deeper
> into this as I've moved over to XTerm long ago due to input latency
> reasons. You might want to check FAQ provided in the ST repo.
> 
> P.S echo is non-portable. Use printf.
> https://wiki.bash-hackers.org/commands/builtin/echo#portability_considerations
> 
> - NRK
> 

Its a longstanding myth st has input latency issues.
The common quoted benchmark is wrong.

-- 
Kind regards,
Hiltjo

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

[Hiltjo Posthuma]

On Tue, Oct 26, 2021 at 07:35:01AM +0200, Sagar Acharya wrote:
> I assume you mean writing css straight into html file itself. Kamitkami is 
> not meant for css that we write. One can use if one uses 1 single style file 
> which turns gigantic when used across many html files.
> It's meant for using css frameworks like cirrus. I use cirrus by stanley lim 
> and it's gigantic. I don't want most elements in the css which I include.
> Thanking you
> Sagar Acharya
> https://designman.org
> 
> Oct 26, 2021, 04:56 by n...@disroot.org:
> 
> > On Mon, Oct 25, 2021 at 08:36:31PM +0200, Sagar Acharya wrote:
> >
> >> I'm making this software called kamitkami. It's a python script which 
> >> takes 2 inputs foo.html and bar.css and outputs a css file named 
> >> bar_foo.css which contains only the css which applies to the particular 
> >> html page . This will make css extremely minimal and page loading faster.
> >>
> >
> > Wouldn't it make more sense to just inline the css into the html
> > instead? I think Dylan was doing that for K1SS.
> > https://archive.md/dFqxv
> >
> > - NRK
> >
> 
> 

Hi,

One solution can be not using CSS frameworks and just write it by hand. It is
not hard to do, creates cleaner files and improves understanding of CSS.

Many years ago I wrote a small snippet:
https://www.codemadness.org/query-unused-css-rules-on-current-document-state.html

There are also options for it in the inspectors in the browsers now.

Note that in the ugly web world for example it could need some ugly event and
execute Javascript and insert some ugly DOM element which is used in the CSS
(so you need to manually test for that). Otherwise it would be marked as not
used.

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] Possible bug in resizemouse function

[Hiltjo Posthuma]

On Sat, Oct 16, 2021 at 10:18:18PM +0800, Xu Lu wrote:
> The related code is in line 1326-1332 in dwm.c (current git HEAD):
> 
>   if (c->mon->wx + nw >= selmon->wx && c->mon->wx + nw <= selmon->wx + 
> selmon->ww
>   && c->mon->wy + nh >= selmon->wy && c->mon->wy + nh <= selmon->wy + 
> selmon->wh)
>   {
>   if (!c->isfloating && selmon->lt[selmon->sellt]->arrange
>   && (abs(nw - c->w) > snap || abs(nh - c->h) > snap))
>   togglefloating(NULL);
>   }
> 
> This outer if statement dates back to 13 years ago in [1]. The changes
> in movemouse in [1] got removed in [2]. The changes in resizemouse is
> neither perfect. Width and height are compared with coordinates, which
> is not a proper way. As a result, it does not work well, e.g., for
> multi-monitor setup.
> 
> 
> The expected behavior should be to constraint the resizing within the
> window area of the current monitor.
> 
> Now, in a multi-monitor set-up, start two windows in one monitor. Try
> resize the window in the stack. During resize, move the cursor directly
> into the other monitor to the right(suppose it is set up that way).
> This way, the window will be resized. But, if there was one window,
> the same action won't resize it.
> 
> 
> Possible solutions:
> 
> I am not a C developer, but I tried some changes and works for me (even
> works with patches like resizecorners):
> 
>   if (ev.xmotion.x >= selmon->wx && ev.xmotion.x <= selmon->wx + 
> selmon->ww
>   && ev.xmotion.y >= selmon->wy && ev.xmotion.y <= selmon->wy + 
> selmon->wh)
> 
> Or, with the help of 'INTERSECT' macro:
> 
>   if (INTERSECT(ev.xmotion.x, ev.xmotion.y, 1, 1, selmon) == 1)
> 
> The two are basically equivalent to each other. This tests whether the
> cursor is inside the monitor's window area, not sure if that's still
> the same intention as before.
> 
> Or, remove the outer if like in [2]. So the resizing is not constrained
> by the window area.
> 
> [1]: 
> https://git.suckless.org/dwm/commit/71365a524f67235024de7db277c63f8ac4f46569.html
> [2]: 
> https://git.suckless.org/dwm/commit/5b238c8dab945023b6a16a6c9f642b11137f2204.html
> 

Hi,

Thank you for the feedback. I've looked at it on a multi-monitor setup and also
discussed it on IRC with other people and the current behaviour seems expected.

Unless I misunderstand the issue I think it is not a bug.

-- 
Kind regards,
Hiltjo

Re: [dev] Join Please

[Hiltjo Posthuma]

On Sat, Sep 18, 2021 at 09:00:09AM -0400, Carl wrote:
> Hello,
> 
> May I please join?
> 
> Thanks!
> --
> 

https://www.youtube.com/embed/twyWHrHWq9E

-- 
Kind regards,
Hiltjo

Re: [dev] [website] broken links to plan9.bell-labs.com

[Hiltjo Posthuma]

On Fri, Aug 27, 2021 at 02:13:02PM +0800, roy...@gmail.com wrote:
> Hello,
> 
> I noticed that there are broken links in
> https://suckless.org/community/ that is linking to
> plan9.bell-labs.com, which should be replaced with 9p.io/plan9/.
> 
> Regards,
> Roy
> 

OK... so do it.

-- 
Kind regards,
Hiltjo

Re: [dev] [st] Crash when displaying these characters

[Hiltjo Posthuma]

On Mon, Aug 16, 2021 at 03:34:51PM -0700, Menche wrote:
> On Mon, 16 Aug 2021 21:56:57 +0200
> Robert Alm Nilsson  wrote:
> 
> > Hi, when I run this command:
> > 
> >  printf '\xf0\x9f\x8d\x95'
> > 
> > st crashes with this output:
> > 
> >  X Error of failed request:  BadLength (poly request too large or 
> > internal Xlib length error)
> >Major opcode of failed request:  139 (RENDER)
> >Minor opcode of failed request:  20 (RenderAddGlyphs)
> >Serial number of failed request:  818
> >Current serial number in output stream:  845
> > 
> > It doesn't generate any core dump; it just exits with status 1.
> > 
> > Operating system: Debian unstable.
> > 
> > Using latest commit on master, which is currently:
> > 2ec571a Add 14th bit to XK_SWITCH_MOD bitmask
> > 
> 
> That pizza character renders fine on my setup (git master st on
> openbsd). What font are you using? I suspect the other replies are
> referring to st's deliberate lack of support for colored glyphs.
> 

st doesn't disable colored glyphs, but dmenu and dwm do apply this ugly
workaround.

It is a bug in Xft as the FAQ mentions.
There are patched Xft library versions that fix the bug also in the meantime.
Some distros are also not affected due to their (proper) font configuration.

> -- 
> Menche 
> 

-- 
Kind regards,
Hiltjo

Re: [dev][dmenu] Setting FC_SCALABLE causes slowdowns

[Hiltjo Posthuma]

On Sun, Aug 08, 2021 at 10:33:07AM -0400, Miles Alan wrote:
> I'm working on trying to speed up dmenu rendering in some edgecases. I've
> sent a patch to the hackers ML about line-length effecting performance.
> 
> A second issue I'm noticing is that the line within drw.c:
> FcPatternAddBool(fcpattern, FC_SCALABLE, FcTrue);
> 
> will cause vast rendering slowdowns based on the input charset. A good
> example to try is the text in this chinese ebook:
> 
> curl 'https://www.gutenberg.org/files/24264/24264-0.txt' |
>   dmenu -l 30 -fn Terminus-10
> 
> If you set FC_SCALABLE to FcFalse, it seems then the characters are
> rendered and things are instant (as they should be). So should FC_SCALABLE
> being FcFalse / unset be the default? Is there another way to speed up
> rendering outside of dmenu's scope if not?
> 
> Miles
> 

Hi Miles,

I will review your other patch, thanks for looking into performance.

In the case of FC_SCALABLE it changes the way fonts are displayed and actually
seems to make it slower here.

Note that you can also override some of the attributes in the XML fontconfig
configuration, so maybe that's a better way to workaround not scaling fonts.

-- 
Kind regards,
Hiltjo

Re: [dev] Article in line with suckless.org

[Hiltjo Posthuma]

On Sat, Aug 07, 2021 at 08:02:31AM +0200, Sagar Acharya wrote:
> I have written this article at the link below.
> 
> https://designman.org/sagaracharya/blog/pretend_computer_security
> 
> It enhances the value of suckless by pointing the problems in gigantic 
> softwares. Let me know what you think.
> 
> Thanking you
> Sagar Acharya
> https://designman.org
> 

Hi,

I see the following text:

"
How to pretend that one provides great computer security?

1. Create a community.
2. Always keep adding code. Never remove and take your code to a million 
lines.
3. Pretend to the world that you are experts because your software has a 
million lines.
4. Keep solving a handful of bugs and release updates. So, people will 
think they just got more secure when there are now  bugs instead of 1 
in your software.
5. Add more bugs, I mean more code forever. 

Sagar Acharya [6th August 2021] 
"

I don't get it.

-- 
Kind regards,
Hiltjo

Re: [dev] [svkbd] layout.sr.h

[Hiltjo Posthuma]

On Mon, Aug 02, 2021 at 04:13:12PM +0200, Страхиња Радић wrote:
> On 21/08/02 02:31, Petr Vaněk wrote:
> > probably no Serbian reviewers here if no one wrote in 4 months :)
> 
> I suspected that is the case, but still the question remains who then reviewed
> layout.sh.h?
> 
> > Anyway, I looked to the patch and compared the layout with online
> > available images of Serbian keyboards [1] and it looks similar except of
> > left down 'Ж'.
> > 
> > [1] 
> > https://upload.wikimedia.org/wikipedia/commons/6/60/QWERTZ_Srpska_tastatura.jpg
> [...]
> > I see a letter similar to 'S' here instead of 'Ж'. But I don't know
> > nothing about this alphabet, maybe it is correct to have 'Ж' here.
> 
> The letter that looks like the latin "S" is pronounced as "dz", but in
> Macedonian[1]. Serbian cyrillic alphabet[2] doesn't include the letter as we
> don't have words which make use of the "dz" sound. Frankly, I have no idea 
> what
> was the original rationale behind including "S" in Serbian cyrillic keyboard
> layout, while leaving out other Macedonian letters like "Ѓ" or "Ќ", except 
> maybe
> as a possible leftover from adjusting some other (ISO 8859-5?) keyboard layout
> to create a layout for Serbian cyrillic. Regardless, I will send a different
> patch which includes the "S" with this message.
> 
> Do note that X11/keysymdef.h states:
> 
>   #define XK_Serbian_dze   0x06af  /* deprecated */
> 
> so probably someone already noticed the error. As a native Serbian speaker, I
> can testify that we don't use the "S" letter when writing in cyrillic (unless 
> as
> a latin "S" in foreign words like "POSIX"), nor we use the "dz" sound in
> Serbian.
> 
> > 
> > This should be { 0, 0, XK_Cancel },
> > 
> 
> Noted, I am sending the patch which includes this correction with this 
> message.
> 
> [1]: https://en.wikipedia.org/wiki/Macedonian_alphabet
> [2]: https://en.wikipedia.org/wiki/Serbian_Cyrillic_alphabet
> 

> diff --git a/layout.sr.h b/layout.sr.h
> new file mode 100644
> index 000..e68cf99
> --- /dev/null
> +++ b/layout.sr.h
> @@ -0,0 +1,88 @@
> +#define KEYS 66
> +static Key keys_sr[] = {
> + { "`","~", XK_quoteleft, 1},
> + { "1","!", XK_1, 1 },
> + { "2","\"", XK_2, 1 },
> + { "3","#", XK_3, 1 },
> + { "4","$", XK_4, 1 },
> + { "5","%", XK_5, 1 },
> + { "6","&", XK_6, 1 },
> + { "7","/", XK_7, 1 },
> + { "8","(", XK_8, 1 },
> + { "9",")", XK_9, 1 },
> + { "0","=", XK_0, 1 },
> + { "'","?", XK_apostrophe, 1 },
> + { "+","*", XK_plus, 1 },
> + { "<-",0, XK_BackSpace, 2 },
> + { "Del",0, XK_Delete, 1},
> + { 0 }, /* New row */
> + { "->|", 0, XK_Tab, 1 },
> + { "љ","Љ", XK_Cyrillic_lje, 1 },
> + { "њ","Њ", XK_Cyrillic_nje, 1 },
> + { "е","Е", XK_Cyrillic_ie, 1 },
> + { "р","Р", XK_Cyrillic_er, 1 },
> + { "т","Т", XK_Cyrillic_te, 1 },
> + { "з","З", XK_Cyrillic_ze, 1 },
> + { "у","У", XK_Cyrillic_u, 1 },
> + { "и","И", XK_Cyrillic_i, 1 },
> + { "о","О", XK_Cyrillic_o, 1 },
> + { "п","П", XK_Cyrillic_pe, 1 },
> + { "ш","Ш", XK_Cyrillic_sha, 1 },
> + { "ђ","Ђ", XK_Serbian_dje, 1 },
> + { "Enter",0, XK_Return, 3 },
> + { 0 }, /* New row */
> + { 0, 0, XK_Caps_Lock, 2 },
> + { "а","А", XK_Cyrillic_a, 1 },
> + { "с","С", XK_Cyrillic_es, 1 },
> + { "д","Д", XK_Cyrillic_de, 1 },
> + { "ф","Ф", XK_Cyrillic_ef, 1 },
> + { "г","Г", XK_Cyrillic_ghe, 1 },
> + { "х","Х", XK_Cyrillic_ha, 1 },
> + { "j","J̣̣", XK_Cyrillic_je, 1 },
> + { "к","К", XK_Cyrillic_ka, 1 },
> + { "л","Л", XK_Cyrillic_el, 1 },
> + { "ч","Ч", XK_Cyrillic_che, 1 },
> + { "ћ","Ћ", XK_Serbian_tshe, 1 },
> + { "ж","Ж", XK_Cyrillic_zhe, 1 },
> + { 0 }, /* New row */
> + { 0, 0, XK_Shift_L, 2 },
> + { "<",">", XK_less, 1 },
> + { "ж","Ж", XK_Cyrillic_zhe, 1 },
> + { "џ","Џ", XK_Cyrillic_dzhe, 1 },
> + { "ц","Ц", XK_Cyrillic_tse, 1 },
> + { "в","В", XK_Cyrillic_ve, 1 },
> + { "б","Б", XK_Cyrillic_be, 1 },
> + { "н","Н", XK_Cyrillic_en, 1 },
> + { "м","М", XK_Cyrillic_em, 1 },
> + { ",",";", XK_comma, 1 },
> + { ".",":", XK_period, 1 },
> + { "-","_", XK_minus, 1 },
> + { 0, 0, XK_Shift_R, 2 },
> + { 0 }, /* New row */
> + { "Ctrl", 0, XK_Control_L, 2 },
> + { "Win", 0, XK_Super_L, 2 },
> + { "Alt", 0, XK_Alt_L, 2 },
> + { "", 0, XK_space, 5 },
> + { "Alt Gr", 0, XK_ISO_Level3_Shift, 2 },
> + { "Menu", 0, XK_Menu, 2 },
> + { "Ctrl", 0, XK_Control_R, 2 },
> +};
> +
> +Buttonmod buttonmods[] = {
> + { XK_Shift_L, Button2 },
> + { XK_Alt_L, Button3 },
> +};
> +
> +#define OVERLAYS 1
> +static Key overlay[OVERLAYS] = {
> + { 0, 0, XK_Cancel },
> +};
> +
> +#define LAYERS 1
> +static char* layer_names[LAYERS] = {
> + "sr",
> +};
> +
> +static Key* available_layers[LAYERS] = {
> + keys_sr,
> +};

> diff --git a/layout.sr.h b/layout.sr.h
> new file mode 100644
> index 

Re: [dev] [svkbd] layout.sr.h

[Hiltjo Posthuma]

On Fri, Jul 30, 2021 at 08:53:33PM +0200, Страхиња Радић wrote:
> On 21/03/29 11:39, Страхиња Радић wrote:
> > On 21/03/29 11:25, Hiltjo Posthuma wrote:
> > > 
> > > Hi,
> > > 
> > > You can add the patch as an attachment or inline and send it for review 
> > > (any Serbian
> > > users care to review it?).
> > 
> > I have attached the patch to this email. I essentially modified the
> > existing layout.sh.h to match the XKB "sr" layout, producing layout.sr.h.
> 
> Hey, I just saw that svkbd was recently updated, but it seems it still doesn't
> have my layout.sr.h. If there is anything that needs to be changed or updated 
> in
> that file in order for it to be added to svkbd, I'd like to know.
> 

Hi,

I'm not sure, but in the original e-mail I asked if there are other Serbian
users to review it. That would be nice, because I can't really properly review
the patch.

-- 
Kind regards,
Hiltjo


signature.asc
Description: PGP signature

Re: [dev] Better naming for arg.h API

[Hiltjo Posthuma]

On Thu, Jul 08, 2021 at 05:32:38PM +0500, Nikita Zlobin wrote:
> In Mon, 5 Jul 2021 13:36:50 +0200
> Hiltjo Posthuma  wrote:
> 
> > It is based on:
> > https://9fans.github.io/plan9port/man/man3/arg.html
> > 
> > argc (count) and argv (array of strings) are the program argument
> > names.
> > 
> 
> Hmmm, now I'm confused about possible meaning for __fixargv0().
> Its definition is not here, what means that it can't see argv0, defined
> just above. Must be rather that it works with argv[0], in this case I'm
> rather wrong about "fix", haha.
> 

Can you please stop spamming the mailinglist? I already explained the reasons
why arg.h won't be changed.

Feel free to blame me for being rude or whatever.

-- 
Kind regards,
Hiltjo

Re: [dev] Better naming for arg.h API

[Hiltjo Posthuma]

On Mon, Jul 05, 2021 at 02:48:10PM +0500, Nikita Zlobin wrote:
> For now all names in arg.h use ARG for prefix.
> However, considering existing argv parsing helpers like getopt, there
> could be two prefixes:
> OPT - for option key or name (for long opts)
> ARG - optional option value if any, argument.
> 
> This way I could propose alternated naming, which would be more clear
> just by reading names in this header file:
> 
> # Is 'C' in the end of ARGC to specify it's short opt?
> # If so, this means possible OPTS implementation
> # (single argv field, representing opts sequence,
> # would be OPTV in this case)
> 
> - ARGBEGIN ARGEND ARGC
> + OPTBEGIN OPTEND OPTC
> 
> # Same, why 'F' in the end?
> - EARGF ARGF ARGF_
> + EARG  ARG  ARG_
> 

It is based on:
https://9fans.github.io/plan9port/man/man3/arg.html

argc (count) and argv (array of strings) are the program argument names.

-- 
Kind regards,
Hiltjo

Re: [dev] tabbed: Use PWD xprop to set workdir for spawned clients. Any clear cons?

[Hiltjo Posthuma]

On Fri, Jul 02, 2021 at 01:16:41AM +0500, Nikita Zlobin wrote:
> I use tabbed for multitab terminal emulator. But I lacked one feature,
> presenting in at least some vte-based terminals: when new tab is
> opened, it inherits workdir from previous active tab.
> 
> I tried to find, it same could be implemented with tabbed. I found
> following solution, which would work independently of what exact
> underlying terminal is used to be spawned. When spawning new tab, tabbed
> checks for certain X property, where workdir is written (obviously, by
> client itself). If found, then it uses this path as workdir for new
> client. This seems simplest possible way for me. Since shells
> (including dash, let alone bash) set PWD env var, containing current
> workdir, I decided to use this name for new X prop too.
> 
> And to adapt unprepared terminals - appended snippet to ~/.bashrc:
> 
> workdir_to_xprop() {
>   [ -v WINDOWID ] && \
>   xprop -id "${WINDOWID}" -f PWD 8s -set "PWD" "${PWD}"
> }
> 
> cd() {
>   builtin cd "$@" || return
>   [ "$OLDPWD" = "$PWD" ] || {
>   workdir_to_xprop
>   }
> }
> 
> workdir_to_xprop
> 
> (can't be sure, how correct it is, but usually it works, as even path
> change from midnight commander is counted in this way too).
> 
> I tried to submit it to hackers ML for simple reason: this list is
> described to be for patches, directed to upstream. As for my patches
> (there were more patches, mostly with fixes) - I targeted them for
> upstream, so sending them there was logical. Too bad - sending patches
> in the way it's required was first ever time, so I wasted couple of
> attempts, while finally sent them in most correct way (not sure if I
> can do it again). Looks like, whoever checks this got tired from all of
> this.
> 
> I hoped, in case if any deficiencies, get resonable arguments why. But
> I got no replies besides two:
> - one is argumentless -1 against this very feature: some claimed they
>   don't use it, despite I have at least 1 example where it presents;
> - second is simply that if has to go to dev
>   (well, finally I got reason to subscribe here, but not for this yet).
> 
> https://lists.suckless.org/hackers/2006/17451.html
> 
> Main question is in topic.
> I don't ask about pros, which are just obvious for me :)
> There could be more of them, but for now I'm too lost to even
> formulate something more specific. Did not expect such attitude, looks
> like as if you have to deserve to even be replied. Or could be that
> hackers only react if you proposal affects what's in their current
> coding focus (yet another wild guess).
> 

Hi,

What "attitude"?  Theres no need to be negative in the assumptions or be
passive-aggressive. In any case it won't help.

As one of the few suckless devs that is still active I still do this as a
hobby. Interacting with such negative people is low on my priority todo list
and makes it less fun.

Reading back the thread I see no issue. I even reviewed the patch and gave
feedback.

In the meantime a new (partial, "temporary") maintainer has been assigned to
tabbed (me), because the old maintainer did not have time anymore.

Like the other thread you posted, if you have ideas: implement them and feel
free to share them if you want do, but don't demand.

-- 
Kind regards,
Hiltjo

Re: [dev] Possible ideas for suckless project

[Hiltjo Posthuma]

On Thu, Jul 01, 2021 at 11:54:27PM +0500, Nikita Zlobin wrote:
> Hello.
> I had some ideas for several years, but never tried to discuss them due
> to nothing similar was ever in use. I like suckless direction, though I
> would also seek to use same concepts (those I already know) to boost
> effectives and usefulness for regular-user-oriented configs as well
> 
> As for 'config' word meaning - I leave maximum range if possible
> meanings, with at least these:
> 1 - desktop configuration,
> 2 - any utilities combination (most likely organized to pipeline) for
> case-specific solution, probably onetime.
> 
> === Ideas ===
> 
> 1. Versatile communication interface
> 
> Applications, requiring IPC or other under-hood communication kind,
> could just get channel and use it. Burden channel maintainance should
> be done by separate system or lib. Variants:
> - shared memory (via API only)
> - fifo, socket, etc (via everything, including scripts)
> 

Theres imsg (see OpenBSD source-tree or tmux), POSIX message queue, 9p.

> 2. Gfxterm (graphics output server).
> 
> What's great in TUI apps - probably, that they don't do graphical
> drawing in their own. They just send & receive text. Same convept could
> be used for gui. Perhaps, even redraws could be scheduled at this level
> too - gfx term would redraw only changed regions, taking this burden
> from gui.
> 
> Well, I know that X11 has own X drawing utilities. But it's just too
> outdated. For example - X bitmap creation, X draw API vs cairo. Cairo
> wins by accuracy, result from X api looks too coarse comparing to that.
> I discovered this while contributing to dunst notification daemon.
> Originally it used Xshape'd opaque RGB format. Now it involves Xshape
> when no compositor available (though I would prefer both, because when
> picom blur is used, it blurs even fully transparent areas if not shaped
> out). Dunst commit: 0e35c6acb0c110a4ab00a560ff15f3e2c85c5f4c.
> 
> Btw, what about wayland? Can it have place in suckless paradigm or it's
> rather rockless? In my vision, serving a compositing manager is rather
> essential for window system, which does the final output.
> 
> After all, compositing could have different modes - it could be full
> (as in compton, compiz), pseudo-like (can't find better name, when only
> wallpaper image is used for background, ignoring underlying windows) or
> off.
> 
> Also would like to note one problem, affecting most of graphics drawing
> systems. I noticed, that for correct result - shaping alpha blending
> must be done separately from transparency alpha. Applying both before
> compositing with rest - primary (probably only one) reason for various
> artifacts. Ideally - each pixels must first undergo color mixing (for
> transparent layers). Also in dunst: commit
> 9833fbba1f6259de40828b213090eb9908861047.
> 
> 3. GUI server.
> 
> GUI display also could be done in unified way. Applications would just
> pass structure - of course, not in xml, but in more optimal way (this
> leads to another idea - unified language/protocol system).
> Theoretically it would allow (if someone has time and motivation) to
> write scripts, directly printing data to necessary channel (well, for
> shell script it would be at least fifo) and read back.
> 

ltk: git://lumidify.org/ltk.git
swk (unmaintained): https://oldgit.suckless.org/swk/log.html
dialog: https://invisible-island.net/dialog/
zenity: https://help.gnome.org/users/zenity/

> 4. Unified (minimal) system to easy language & protocol support.
> 
> - each language should have user-readable and compiled representation
> - unified interface to (de)compile data, be it in API or cmd utilities
> - accept both files and streams for processing (auto stream mode if
>   file is fifo).
> 

Maybe qbe compiler backend: https://c9x.me/compile/

-- 
Kind regards,
Hiltjo

Re: [dev] [st] Thoughts on kitty keyboard protocol

[Hiltjo Posthuma]

On Sun, Jun 20, 2021 at 08:25:23PM +, opal hart wrote:
> On Sat, 22 May 2021 15:10:02 +0200
> Страхиња Радић  wrote:
> 
> > Speaking as (thus far) just a user of suckless programs and someone who 
> > supports
> > suckless philosophy, it comes down to: why should this protocol be 
> > supported?
> > There isn't a significant number of existing suckless programs that need
> > supporting this protocol
> 
> Suckless software isn't a void separate from the rest of the world, and
> the "suckless philosophy" is constantly inconsistent with its own
> beliefs. Your underlying point that little (if any) software supports
> this protocol may be correct though.
> 

Constantly inconsistent in what way?

> > As for the terminal emulator kitty which is using it, it does include a 
> > number
> > of unnecessary features. Why would a terminal emulator need OpenGL?
> 
> Of all the issues I have with kitty, GPU acceleration is not one of
> them.
> 
> > Its job is to just allow terminal I/O.
> 
> And display it.
> 
> > It should work on older hardware, and on systems where OpenGL isn't
> > or cannot be installed.
> 
> There are plenty of other terminal emulators for systems where it would
> be impractical to install kitty.
> 
> > As far as the attitude of the developer behind it, I have seen examples of 
> > him
> > locking proposals or bug reports on kitty's Github page when they don't 
> > match
> > his vision, disregarding arguments. It might be irrelevant, but in the
> > hypothetical case of presenting that protocol to a standards body, maybe 
> > not.
> 
> You're on a mailing list for opinionated software to ... complain about
> other opinionated software?
> 
> I really hope you understand how poorly you have been arguing. While I
> believe it is pointless to support "yet another" set of terminal
> control sequences, it's barely for the reasons you gave. And if anyone
> does want to support this protocol, it would be better done in an
> optional feature patch or a fork.
> 
> -- 
> wowaname 



-- 
Kind regards,
Hiltjo


signature.asc
Description: PGP signature

Re: [dev] Update outdated suckless website

[Hiltjo Posthuma]

Hi Martin,

Thank you for the valuable feedback.

On Fri, Jun 11, 2021 at 02:15:47PM +0800, Martin Tournoij wrote:
> Hello,
> 
> I think the suckless website could do with some updating. I think suckless
> has potential, but people are turned off by the old website. Using a more
> modern website built with a modern framework like React or VueJS could
> probably solve a lot of its problems.
> 
> Some of the problems:
> 
> 1. I am able to find most information by using the clearly labelled menu
>items. This is very boring! A good website makes users search for the
>content they want, this is more fun and drives engagement.
> 
> 2. I am unable to find a mobile app for either iOS or Android? Is there a
>suckless mobile app? You really can't afford to NOT have a mobile app
>these days.
> 
> 3. Because the website is written in plain language with relevant and
>useful content the SEO score is very low. You can add some more
>critical keywords as a quick fix, but personally I would recommend some
>larger changes, such as renaming "software that sucks less" to "Is it
>true that software can suck less? We compiled 7 reasons why it could!"
> 
>Other content that could be added are blog posts, for example "How
>suckless' minimalism can help your relationship with your dog", or "Six
>different ways suckless can get you laid", "Why Linus Torvalds says he
>HATES suckless", "Does using suckless mean you're a beta cuck?", etc.
>The most important part is a title that will either 1) confirm people's
>preconceived notions, or 2) outrage people. Most people don't read the
>article so that's not very important, as long as it uses many keywords.
>It's also important to post this on at least 46 subreddits, Hacker
>News, Lobste.rs, etc. Don't worry if it may be on-topic or not, with
>some luck it will slip past the moderation because your incendiary
>title will drive engagement. You can always create a new account if you
>get banned.
> 
> 4. Suckless.org currently has a score of 100 on Google PageSpeed. This is
>far too high. The homepage loads in about 200ms for me, far too fast
>too. Slower load times increases frustration of users, and more
>emotional users drive greater engagement.
> 

200ms seems still a bit high, maybe we could use geolocated CDNs of the
reliable Fastly CDN for negative latency.

> 5. It doesn't ask to send me notifications at all. As a user, I feel
>undervalued and ignored. Please, ask for notifications and send me a
>notification every time something important happens, such as mailing
>list posts, or other important events such as a suckless developer
>breaking wind. I absolutely need to know about this without any delay.
> 
> 6. The page is not standards-compliant: it only uses about 9% of my CPU
>during the initial load and 0% after this. This is not in accordance
>with modern web standards. It's important to be standards-compliant.
>It's really stuck in the IE6 days in this regard!
> 

The 0% CPU issue is a known bug which is caused by a lazy CPU, you should buy a
new one.

> 7. It's not made with . This breaks my 變. Do you not love me? I think
>this is very rude.
>

While it is true not loving someone is very rude, this is not the case. We at
suckless(tm) love all our consumers. I will forward this complaint to our
Senior Love Manager.
 
> 8. I am not distracted by fun and interesting advertisements. If I do not
>see an advertisement about Coca Cola, Swatch, Wix, etc. every 5 to 10
>minutes then I might forget about them, and that would be terrible!!
> 
> 9. There are no social media features, and I can't  or  anything. I
>also can't post it to my Facebook. I would really like to share it with
>my anti-vaccination group on Facebook but now it's very hard :-(
> 
> 10. The website is only in English; I expected the page to be
> automatically translated to Indonesian as I'm accessing it from
> Indonesia. Respecting the user's preferences from the Accept-Language
> header is also not in accordance with modern web standards.
> 

Some of the content is in German, which was too controversial.  There is still
some on the following page however:
https://ev.suckless.org/satzung/

> 11. The suckless website is open source and I cloned the git repo, but I
> couldn't find any way to run it with systemd. Is this possible? I
> wanted to try and make it better, but it's very hard for new
> contributors if your website doesn't run on systemd. I also tried
> adding it to my k8s cluster, but that didn't work either :-/
> 
> As you can see, these are all very real problems. I think suckless will
> never be popular without a good modern website. I could add some more, but
> I think we can start by working on these problems.
> 
> There are many modern frameworks but you should really use React in my
> opinion. It is amazing. I do everything with React; 

Re: [dev] adding mtm to the suckless website

[Hiltjo Posthuma]

On Fri, May 21, 2021 at 06:11:49PM -0400, Greg Reagle wrote:
> I would like to add mtm (https://github.com/deadpixi/mtm), but I don't know 
> whether to add it to "rocks" or "other_projects".  What is the difference?
> 

The rocks part

-- 
Kind regards,
Hiltjo

Re: [dev] [dmenu] XLFD fonts are not supported

[Hiltjo Posthuma]

On Sun, May 16, 2021 at 10:39:27PM +0200, qsm...@tutanota.com wrote:
> If I try 
> 
>     printf 'X\n' | dmenu -fn '-misc-fixed-*-*-*-*-*-*-*-*-*-*-*-*'
> 
> with Dmenu 5.0, it runs with a fallback font that is clearly not the XLFD 
> Fixed font. No warning, nothing at all on standard error to hint at the fact 
> that it is not using it.
> 
> I believe that either the manual page should document that XLFD is not 
> supported anymore or that the stderr should be used to warn users that the 
> font was not recognized and a fallback was used instead.
> 

dmenu uses Xft fonts since atleast dmenu 4.5, which was released in 2015.

Maybe it is a good idea to document in the man page though (Xft / freetype /
fontconfig), not sure.

-- 
Kind regards,
Hiltjo

Re: [dev] Sxmo presentation at AlpineConf (Sat May 15, 14:30 UTC)

[Hiltjo Posthuma]

On Fri, May 14, 2021 at 03:59:47PM +0200, Maarten van Gompel wrote:
> Hi all,
> 
> I just wanted to drop a little announcement that this weekend on
> AlpineConf 2021, we will present Sxmo, the simple X mobile environment.
> As it is largely based on the suckless stack of tools (dwm, dmenu,
> svkbd, st), it may be interesting for some of you.
> 
> Here's the invitation from Alpine Linux:
> https://lists.alpinelinux.org/~alpine/devel/%3C9637f9fa-7efc-6fed-6635-a66c1cefca8%40dereferenced.org%3E
> 
> The Sxmo presentation is scheduled at 14:30 UTC / 16:30 CEST, tomorrow
> Saturday the 15th of May. It'll all be online so it can also be watched
> at a later time of course.
> 
> Kind regards,
> 
> --
> 
> Maarten van Gompel
> 
> proy...@anaproy.nl
> https://proycon.anaproy.nl
> https://github.com/proycon
> 
> GnuPG key:  0x39FE11201A31555C
> XMPP:   proy...@anaproy.nl   Matrix: @proycon:matrix.anaproy.nl
> Telegram:   proycon  IRC: proycon (freenode)
> Mastodon:   https://social.anaproy.nl/@proycon   (@proy...@social.anaproy.nl)
> Twitter:https://twitter.com/proycon
> 

Hi Maarten,

Thanks, I will have a look. sxmo looks interesting and made nice progress.

-- 
Kind regards,
Hiltjo

Re: [dev] less lines of code suck less

[Hiltjo Posthuma]

On Mon, May 03, 2021 at 04:28:47PM -0400, Greg Reagle wrote:
> Would sbase suck less if the program head, which is currently a C program of 
> 77 lines, were replaced with something like 
>   #!/bin/sh
>   sed "$1"q
> 

No

> I know that it would need to be a bit more elaborate than that to handle the 
> -n flag, but still.  Is there any advantage to having a separate C program?
> 

Yes

-- 
Kind regards,
Hiltjo

Re: [dev] Checksums and Sig files for release gzip

[Hiltjo Posthuma]

On Wed, Apr 14, 2021 at 09:05:01AM +0300, Sergey Matveev wrote:
> *** Markus Wichmann [2021-04-14 06:03]:
> >I don't care about the speed of a hash function.
> 
> If we a talking here about checking software integrity, then speed is
> important. Millions of people check the hash of downloaded files -- if
> it is slow, then huge quantity of time/energy is wasted. Less time you
> spent on hashing, less energy is wasted. SHA2 (and SHA3 too, if we are
> not talking about KangarooTwelve modifications) is the worst choice from
> ecology point of view.
> 

Generating hashes for all dl.suckless tarball files (287 files) takes 0.75
seconds in total, it is not an issue.

What is the preferred hash by Greta?

> >I think bitcoin mining is pollution
> 
> I agreed. But I see nothing in common between proof-of-works and hash
> functions. PoWs ("good one", like Argon2 that can be used for that task)
> uses special construction -- it does not matter if underlying hash is
> fast or slow, because we can simply make more iterations with it.
> 
> >and in case of password cracking, having a slower hash
> >function is an advantage for me
> 
> That can only mean that you still use an ancient PBKDF2-like schemes of
> password strengthening. A long time ago a Password Hashing Competition
> brought us memory-hardened hashing functions like Argon2 (winner), and
> Balloon (appeared after PHC, but my favourite). Hash function speed do
> not play any considerable role there, because memory is actively used
> and *is* the bottleneck for brute forcing operation. Anyway, slower hash
> for PBKDF2 means that number of iterations will be smaller -- faster
> hash means more number of iterations. So only the dead simple password
> hashing constructions like hash(password) will benefit from slower hash,
> that is just silly and unacceptable to use at all, if you worry about
> brute-force cracking.
> 
> >I am not a cryptographer. From what I understand about SHA-3, it offers
> >a better HMAC function
> 
> 1) Do not confuse "MAC" and "HMAC". HMAC is a special construction
> (H(K XOR opad) || H((K XOR ipad) || m)) that can make a MAC with hash
> functions. It is required at least because many hash functions are
> constructed as Merkle–Damgård, that has some properties preventing
> simple H(K || m) usage.
> 
> 2) SHA3 is not Merkle–Damgård and can be safely used as a MAC with just
> H(K || m) calculation. HMAC can be used with SHA3 without any problems,
> but it just calls hash function one more time. For big messages that
> does not play any noticeable role at all (hashing of terabyte and one
> more hash of dozens of bytes), but for small one "native" SHA3-MAC just
> will be faster.
> 
> 3) "Native" SHA3-MAC is not better. It is just the same, from security
> point of view. Nothing wrong with HMAC, nothing wrong with SHA3-MAC.
> Latter will be just faster especially for small messages.
> 
> >(the whole padding thing is not needed anymore,
> >since hash extension attacks are not possible).
> 
> Yes, HMAC prevents them. SHA3 is simply immune for them out of box,
> because of its sponge construction. Nothing is wrong with both of them,
> noone is better.
> 
> >Cryptographers had a big old competition over the
> >"best" hashing algorithm and in 2012, Keccak won.
> 
> There are too many questions what is "best". Keccak won mainly because
> it is not Merkle-Damgård construction that probably someday can
> be found to be problematic with more issues. Possibly that
> construction itself was a mistake. SHA3 is a ready replacement **if**
> something is wrong with SHA2. Official statements require to replace MD5
> and SHA1 with SHA2+. But there are no statements and recommendation to
> replace SHA2 with SHA3, because nothing is wrong with SHA2.
> 
> >And I will continue to advocate for its use exclusively over SHA-2 to
> >keep the zoo of hash functions small. SHA-3 should be used for its HMAC
> >property alone, and it is adequate for all other tasks, so there is also
> >no reason to keep SHA-2 around.
> 
> Nothing wrong to use SHA3. But it is wrong to say that SHA2 is somehow
> bad and must be replaced. That is why even newer creations, knowing that
> SHA3 is already here for a long time, still choosing SHA2 exactly for
> keeping the zoo of hash functions small, because noone is going to
> replace already existing SHA2-driven software with SHA3. Why Git is not
> moving to SHA3 from SHA1? Because there is no point in that, nothing is
> wrong with SHA2 existing in every piece of libraries.
> 
> But anyway there is no possibility just to stay with only SHA2 or only
> SHA3. Because all of them are slow. I use hash alone for verifying data
> integrity and I need for speed. That is why BLAKE2/Skein are so
> popular and BLAKE3 is gaining popularity too. And as I remember, Skein
> even has security marging higher than Keccak. BLAKE2 has completely
> acceptable margin for all cryptographic tasks too. Possibly KangarooTwelve
> will gain popularity too. 

Re: [dev] Checksums and Sig files for release gzip

[Hiltjo Posthuma]

On Fri, Apr 16, 2021 at 09:16:30PM +0200, Anders Damsgaard wrote:
> * Sagar Acharya  [2021-04-16 20:01:56 +0200]:
> 
> > Was any decision taken with regards to this? Would we have certain 
> > checksums and sigs for releases in future?
> > 
> > Thanking you
> > Sagar Acharya
> > https://designman.org
> 
> Sagar, please realize that people are volunteering their time, and I think
> most are doing it for fun.  As far as I can tell, you are not entitled to
> demand any action.  If you want something done, send a patch and expect
> it to be carefully scrutinized.
> 

I agree with this and for now it won't be changed.

The admins team will make a decision about this if needed.

-- 
Kind regards,
Hiltjo

Re: [dev] Checksums and Sig files for release gzip

[Hiltjo Posthuma]

On Tue, Apr 13, 2021 at 04:45:07PM +0200, Daniel Cegiełka wrote:
> How/where SHA512 is better than SHA256 or SHA1? I don't see any added
> value in this. If someone breaks into your server and replace files,
> may also regenerate check sums (SHA256/512 or SHA3, scrypt etc.). The
> use of MD5 will be equally (un)safe as SHA512 :)
> 

One example where it would not be equally unsafe is if someone or some distro
mirrors the source-code.

> A better solution is e.g. signify from OpenBSD or GnuPG.
> 
> https://man.openbsd.org/signify
> 
> Daniel
> 
> wt., 13 kwi 2021 o 13:36 Sagar Acharya  napisał(a):
> >
> > Can we have SHA512 checksums and sig files for the release gzips of 
> > suckless software?
> >
> > Thanking you
> > Sagar Acharya
> > https://designman.org
> >
> 

-- 
Kind regards,
Hiltjo

Re: [dev] Completeness suckless

[Hiltjo Posthuma]

On Mon, Apr 12, 2021 at 08:22:18AM +0200, Daniel Cegiełka wrote:
> > Choose an OS which has a small kernel and other minimal software
> > that you need. (OpenBSD is the only one I can see here today)
> 
> suckless is strongly Linux-oriented - musl, ubase, smdev, nldev, nlmon
> 

No, there are also many other tools (dwm, dmenu, st) etc which are not
Linux-oriented.  The userbase is probably mostly Linux-oriented, but that's
something different.

musl is a nice project (imho) but not part of suckless.org itself.

> I wonder if it would make sense to make a little Linux kernel.
> Everything that is unnecessary could be deleted. And yes, this
> sounds controversial, but for example:
> 
> https://github.com/michaelforney/linux-headers/tree/master/scripts
> 
> Daniel
> 
> 
> 
> > On 9 Apr 2021, at 14:54, Sagar Acharya  wrote:
> >
> > I recently wrote this article
> >
> > https://designman.org/sagaracharya/blog/trusting_no_one
> >
> > being absolutely unaware about suckless and this was brought to my 
> > attention.
> >
> > Suckless's philosophy is hands down amazing and crucial wrt computer 
> > security. Although I'd like to point out 1 aspect. Why does suckless target 
> > very sophisticated users? If it shuns trying to go after elitist users, it 
> > can improve computer security of people all around the world and also 
> > themselves, since if others are secure, you yourself will become even more 
> > secure!
> >
> > For it, there would be few requirements. Free software, minimal, easy to 
> > use, beautiful to look at (by default). I guess the latter 2 are lagging a 
> > bit.
> >
> > Thanking you
> > --
> > Sagar Acharya
> > https://designman.org
> >
> > P.S. Shifted completely to dwm this week. Can't even think of anything 
> > theoretically better than this!
> >
> 

-- 
Kind regards,
Hiltjo

Re: [dev] Completeness suckless

[Hiltjo Posthuma]

On Sat, Apr 10, 2021 at 08:14:08AM +0200, Sagar Acharya wrote:
> >I say that coming from one of the best universities in France; I didn't have 
> >very much respect left for the word "scientist" when I left
> Same here. Exactly same! But they for sure are intelligent. One of the key 
> things in capitalism is getting tamed by the powerful. Majority of these 
> geniuses don't know how their work impacts the world! They get tamed by 
> people who work against their own principles just because knowing their 
> tamer's principles is difficult!
> 
> >Now try bspwm
> Damn that's good! Very simple logic. But I'll stick to dwm for now. Check it 
> after a while.
> 
> >Where would you say their capacities are lacking?
> Most don't have the logical abilities. Amongst ones who do, many don't want 
> to read in times of videos. They want instant gratification. For few it is 
> also about power. You suggest them to use dwm. They'll think they're above 
> you socially and won't use it. This maybe a bit biased but 1 thing I know for 
> sure, that people are far, very far away from using minimal systems.
> 
> >The practical knowledge of computer science comes from experience in a 
> >consumer-driven, market environment. Academia is not that environment.
> +1.
> 
> >A lot of people had a take for a user-friendlier dwm, you should try those, 
> >or similar wms with "battery pack included" like i3 or awesome.
> Again, I'm not talking about dwm specifically. i3wm is a single wm and while 
> it's good, I think suckless can target COMPLETE systems. It's philosophy is 
> great.
> 
> >We believe this should become the mainstream philosophy in the IT sector. - 
> >On suckless site.
> This IT sector is constantly making things easier for people or atleast 
> making people believe it is. If suckless wants this to become mainstream 
> philosophy, it has to do itself. People don't wanna change especially when 
> computers are just the tools to achieve some end.
> 
> If suckless makes it easy for people to use minimalistic systems, they will. 
> I shifted from complete windows to dual boot to complete GNU/Linux (Parrot 
> Linux) to Parabola (Plasma) to Parabola (dwm) in about 3 years. I can't 
> imagine shifting directly to current state. I would get frustrated and go 
> back to Windows if someone would ask me to get to this point from complete 
> Windows. But if there were tutorials explaning why would you use wm instead 
> of de, wm were a bit more beautiful, things would be much simpler. Plasma is 
> hands down beautiful! But it's very complex!
> 
> Thanking you
> Sagar Acharya
> https://designman.org
> 

> P.S. I'd love to contribute.
> 

Whats stopping you from doing it?

-- 
Kind regards,
Hiltjo

Re: [dev] [svkbd] layout.sr.h

[Hiltjo Posthuma]

On Mon, Mar 29, 2021 at 10:38:49AM +0200, Страхиња Радић wrote:
>   Hi,
> 
>   I created a Serbian keyboard layout for svkbd, how can I upload it so it
> can be included in svkbd?
> 
>   Thanks in advance,
>   Strahinya Radich
> 

Hi,

You can add the patch as an attachment or inline and send it for review (any 
Serbian
users care to review it?).


Helpful guides:
https://suckless.org/community/
https://suckless.org/hacking/
https://suckless.org/coding_style/

-- 
Kind regards,
Hiltjo


signature.asc
Description: PGP signature

Re: [dev] [dwm] Hide window content when moving/resizing windows

[Hiltjo Posthuma]

On Wed, Feb 10, 2021 at 01:10:40PM +0200, Κράκ Άουτ wrote:
> Στις 10/2/21 12:34 μ.μ., ο/η Hiltjo Posthuma έγραψε:
> > On Wed, Feb 10, 2021 at 10:40:39AM +0200, Κράκ Άουτ wrote:
> > > I started using dwm a couple of months ago, switching from xfce4. Since
> > > my pc is a bit constrained on resources I really appreciate the low
> > > memory footprint of dwm. But I've noticed that it's slower than
> > > xfce/xfwm when resizing/moving floating windows. Also on converting
> > > tiled to floating and vice-versa (equivalent to unmaximize/maximize on
> > > xfwm).
> > > 
> > > Regarding driver and general X setup everything is fine, 3D graphics, hw
> > > assisted video playback work ok. I've pinned down the speed difference
> > > to xfwm's option to hide contents of windows when moving and resizing,
> > > which I've enabled on xfwm. Only the frame of the window is drawn, until
> > > the final position when the hole window draws back again.
> > > 
> > > I've searched for dwm patches with equivalent functionality, haven't
> > > found anything. Do you have any idea how to achieve hiding content of
> > > windows when moving and resizing on dwm?
> > > 
> > > I've also met this,
> > > https://lists.suckless.org/dwm/0809/6775.html
> > > I quote, "Some people mentioned that mouseresize is really slow in dwm".
> > > Apparently others have noticed this lag also. In this mail there is a
> > > patch/hack, but it's some years old, I tried to patch my dwm setup with
> > > it, didn't make it.
> > > 
> > > I suppose for a light, hackable wm like dwm, it would be nice to have an
> > > option or a patch to hide window content when moving/resizing windows.
> > > It makes a difference on older hardware.
> > > 
> > 
> > Hi,
> > 
> > Can you describe more precisely what is felt as "slow" to you? Some numbers
> > would be nice.
> > What are the exact specifications of your machine, related to video drivers,
> > memory etc?
> > 
> > This commit was added after 2008 as a fix/workaround. It limits updates to
> > ~60fps:
> > 
> > https://git.suckless.org/dwm/commit/3d1090ba896319368c4771b88d325fcee368a608.html
> > 
> > At the time I think the lag was introduced after a X11 change related to the
> > graphics stack on my machine, but I'm not entirely sure.
> > 
> > I think it would be nice to have this patch anyway, either as a wiki-patch 
> > or
> > maybe even upstreamed if it is simple enough.
> > 
> 
> Hi Hiltjo,
> 
> It's not slow in the sense that it's not usable, but obviously not as
> fast as not drawing contents at all. Unfortunately I have no way to
> benchmark and provide numbers; it doesn't take a sec or more to move a
> floating window, it's just a bit sluggish.
> 
> To clarify, the same sluggishness applies for xfwm, if I enable it to
> show the contents of windows while moving/resizing. I do not consider
> dwm to fall short or have a bug, it's just that I cannot disable showing
> windows contents on move/resize, as in other window managers.
> 
> My pc is an 11 year old Intel i3 cpu, Ati Radeon HD 2000.
> 

The general specs should be fine.

> So, looking at your code, can I limit updates to 1/sec instead of
> 60/sec? Changing this line,
> `if ((ev.xmotion.time - lasttime) <= (1000 / 60))`
> to
> `if ((ev.xmotion.time - lasttime) <= (1000 / 1))`
> would be enough?
> 

You could try it and see if it's an OK workaround for your use-case.  It would
of course have a trade-off of not updating as frequently showing the new
geometry.

> Can I also achieve 0/sec somehow? I suggested 1/sec because division by
> zero is not possible.
> 
> Forgive me if the proposal it totally wrong, I'm not into C at all.
> 

You could change the event loop and set some flag, then update the geometry
after processing the events. It would not give any visual feedback then however
(with the current logic).

In resizemouse() around here:
https://git.suckless.org/dwm/file/dwm.c.html#l1334

-- 
Kind regards,
Hiltjo

Re: [dev] Hide window content when moving/resizing windows

[Hiltjo Posthuma]

On Wed, Feb 10, 2021 at 10:40:39AM +0200, Κράκ Άουτ wrote:
> I started using dwm a couple of months ago, switching from xfce4. Since
> my pc is a bit constrained on resources I really appreciate the low
> memory footprint of dwm. But I've noticed that it's slower than
> xfce/xfwm when resizing/moving floating windows. Also on converting
> tiled to floating and vice-versa (equivalent to unmaximize/maximize on
> xfwm).
> 
> Regarding driver and general X setup everything is fine, 3D graphics, hw
> assisted video playback work ok. I've pinned down the speed difference
> to xfwm's option to hide contents of windows when moving and resizing,
> which I've enabled on xfwm. Only the frame of the window is drawn, until
> the final position when the hole window draws back again.
> 
> I've searched for dwm patches with equivalent functionality, haven't
> found anything. Do you have any idea how to achieve hiding content of
> windows when moving and resizing on dwm?
> 
> I've also met this,
> https://lists.suckless.org/dwm/0809/6775.html
> I quote, "Some people mentioned that mouseresize is really slow in dwm".
> Apparently others have noticed this lag also. In this mail there is a
> patch/hack, but it's some years old, I tried to patch my dwm setup with
> it, didn't make it.
> 
> I suppose for a light, hackable wm like dwm, it would be nice to have an
> option or a patch to hide window content when moving/resizing windows.
> It makes a difference on older hardware.
> 

Hi,

Can you describe more precisely what is felt as "slow" to you? Some numbers
would be nice.
What are the exact specifications of your machine, related to video drivers,
memory etc?

This commit was added after 2008 as a fix/workaround. It limits updates to
~60fps:

https://git.suckless.org/dwm/commit/3d1090ba896319368c4771b88d325fcee368a608.html

At the time I think the lag was introduced after a X11 change related to the
graphics stack on my machine, but I'm not entirely sure.

I think it would be nice to have this patch anyway, either as a wiki-patch or
maybe even upstreamed if it is simple enough.

-- 
Kind regards,
Hiltjo

Re: [dev] newbie question

[Hiltjo Posthuma]

On Wed, Oct 28, 2020 at 11:44:35AM +0100, Adam Kandur wrote:
> 
> hi everyone, i'm new in c programming. i tried to read sources but stuck with 
> enum.
> as i know, enum is mainly used to assign names to integral constants. but i 
> don't understand, for example, this code
> --
> enum term_mode {
>     MODE_WRAP    = 1 << 0,
>     MODE_INSERT  = 1 << 1,
>     MODE_ALTSCREEN   = 1 << 2,
>     MODE_CRLF    = 1 << 3,
>     MODE_ECHO    = 1 << 4,
>     MODE_PRINT   = 1 << 5,
>     MODE_UTF8    = 1 << 6,
> };
> --why not simply write ?
> --
> enum term_mode {
>     MODE_WRAP    = 1,
>     MODE_INSERT  = 2,
>     MODE_ALTSCREEN   = 4,
>     MODE_CRLF    = 8,
>     MODE_ECHO    = 16,
>     MODE_PRINT   = 32,
>     MODE_UTF8    = 64,
> };
> --
> 

Hi,

They are the same and are coding-style.

The bitshift typically hints that the value is used as a bitmask somewhere.

-- 
Kind regards,
Hiltjo

Re: [dev] [surf][bug] bug in pipe communication to extension

[Hiltjo Posthuma]

On Sat, Oct 17, 2020 at 09:53:47AM +0200, Jona Ackerschott wrote:
> Dear suckless community,
> 

Hi Jona,

> There seems to be a bug in surf, in the 'readpipe' function in surf.c.
> The pipes for communication with the web extension are being closed
> there in the switch statement, which is problematic, because this function is 
> called every time
> the web extension is initialized.
> This desing seems to be chosen on the assumption that the surf web extension
> will only be initialized once.
> However, this is not the case and as soon as the web extension gets
> initialized a second time the current page may be loading forever.
> 
> To reproduce this bug, execute mainline surf without patches, go to 
> 'google.com'
> (Exactly this, combinations of 'http(s)' or 'www' added to this
> can change the behaviour) and then to 'twitter.com' (Again extactly this).
> These sites are just one example, this also happens with other sites,
> mostly pretty bloated ones.
> You should see that 'twitter.com' is not loading and the error messages
> 'webext: error sending: i', 'webext: message too short: %i' (where %i is
> some negative integer).
> There is also a variation of this bug, where you find only the first
> error message and the page is loading in a finite amount of time.
> 
> I think all this behaviour can be traced back to the fact, that the
> pipes are being closed to early in readpipe, because they could be
> needed again.
> A fix could be to let those pipes open during runtime and only close
> them in the 'cleanup' function.
> At least this fixes all the problems i have talked about.
> 

Where is the patch?

> Regards,
> Jona
> 

-- 
Kind regards,
Hiltjo

Re: [dev] GNU Guix

[Hiltjo Posthuma]

On Tue, Sep 29, 2020 at 12:21:57PM +, Cuckoo's Calling wrote:
> Hello All,
> 
> I came across an amazing project called GNU Guix.
> 
> So, I made an animation to introduce the novel concepts of this project.
> 
> Here is the link for the video,
> https://gnuguix-drive.mycozy.cloud/public?sharecode=YvERPGX14g5S
> 
> Please leave me a feedback on your experience.
> 
> Cheers,
> Cuckoo's Calling.
> 

I get "Your Cozy has been blocked".

Is it Cuckockblocked?

-- 
Kind regards,
Hiltjo

Re: [dev] [LibrePlanet]: New Presentation

[Hiltjo Posthuma]

On Mon, Sep 28, 2020 at 05:21:06AM +, Goo Goo Knox wrote:
> Hi All,
> 
> I am planning to apply for a session in upcoming LibrePlanet conference, to 
> present a topic on this project.
> 
> Here is the self-shot version of the presentation, 
> https://fs333.gounlimited.to/tea5ur5c2h2qzxfffn4yv5jg53piwzbdni5tp7o7twot3lgjhc2w5gxv2g5a/v.mp4
> 
> Please leave me a feedback. :-)
> 
> Cheers,
> Goo-Goo-Knox.
> 

Hi,

The link doesn't seem to work for me (HTTP 404).

What is the topic about specificly?

Are there slides?

-- 
Kind regards,
Hiltjo

Re: [dev] [svkbd] request release tag

[Hiltjo Posthuma]

On Wed, Sep 16, 2020 at 11:36:45PM +0200, Hiltjo Posthuma wrote:
> On Wed, Sep 16, 2020 at 04:11:15PM +0200, Maarten van Gompel wrote:
> > On 20-09-13 10:44, Hiltjo Posthuma wrote:
> > > Sure that's possible. I have released 0.2 now.
> > >
> > > If you have additional fixes/changes which are generic enough to be 
> > > upstreamed
> > > they are of course welcome.
> > 
> > Hi Hiltjo,
> > 
> > Thanks for the release! When packaging for Alpine Linux I found an
> > issue with the make install script through (I just submitted a patch to
> > fix it and bumped the version to 0.2.1). Could I request another
> > tag & release? Sorry for the inconvenience!
> > 
> > Regards,
> > 
> > --
> > 
> > Maarten van Gompel
> > 
> > proy...@anaproy.nl
> > https://proycon.anaproy.nl
> > https://github.com/proycon
> > 
> > GnuPG key:  0x39FE11201A31555C
> > XMPP:   proy...@anaproy.nl   Matrix: @proycon:matrix.anaproy.nl
> > Telegram:   proycon  IRC: proycon (freenode)
> > Discord:proycon#8272
> > Mastodon:   https://social.anaproy.nl/@proycon   
> > (@proy...@social.anaproy.nl)
> > Twitter:https://twitter.com/proycon
> > Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
> > 
> 
> Hi Maarten,
> 
> I pushed the patch. I'll try to do a release tomorrow when I can.
> 
> No worries at all about any inconvenience, thanks for the feedback.
> 
> -- 
> Kind regards,
> Hiltjo
> 

Hi,

svkbd 0.2.1 is now released. It also contains a fix defining the DEFAULT_SOURCE
feature macro as pointed out by quinq (thanks!).

-- 
Kind regards,
Hiltjo

Re: [dev] [svkbd] request release tag

[Hiltjo Posthuma]

On Wed, Sep 16, 2020 at 04:11:15PM +0200, Maarten van Gompel wrote:
> On 20-09-13 10:44, Hiltjo Posthuma wrote:
> > Sure that's possible. I have released 0.2 now.
> >
> > If you have additional fixes/changes which are generic enough to be 
> > upstreamed
> > they are of course welcome.
> 
> Hi Hiltjo,
> 
> Thanks for the release! When packaging for Alpine Linux I found an
> issue with the make install script through (I just submitted a patch to
> fix it and bumped the version to 0.2.1). Could I request another
> tag & release? Sorry for the inconvenience!
> 
> Regards,
> 
> --
> 
> Maarten van Gompel
> 
> proy...@anaproy.nl
> https://proycon.anaproy.nl
> https://github.com/proycon
> 
> GnuPG key:  0x39FE11201A31555C
> XMPP:   proy...@anaproy.nl   Matrix: @proycon:matrix.anaproy.nl
> Telegram:   proycon  IRC: proycon (freenode)
> Discord:proycon#8272
> Mastodon:   https://social.anaproy.nl/@proycon   (@proy...@social.anaproy.nl)
> Twitter:https://twitter.com/proycon
> Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
> 

Hi Maarten,

I pushed the patch. I'll try to do a release tomorrow when I can.

No worries at all about any inconvenience, thanks for the feedback.

-- 
Kind regards,
Hiltjo

Re: [dev] [svkbd] request release tag

[Hiltjo Posthuma]

On Sun, Sep 13, 2020 at 08:17:22PM +0200, Maarten van Gompel wrote:
> Hey Hiltjo et al.,
> 
> Can we do a release tag for svkbd (0.2)? I'd like to package it for at
> least Alpine Linux / postmarketOS so it'd be best if we have a proper tag
> then.
> 
> Regards,
> 
> --
> 
> Maarten van Gompel
> 
> proy...@anaproy.nl
> https://proycon.anaproy.nl
> https://github.com/proycon
> 
> GnuPG key:  0x39FE11201A31555C
> XMPP:   proy...@anaproy.nl   Matrix: @proycon:matrix.anaproy.nl
> Telegram:   proycon  IRC: proycon (freenode)
> Discord:proycon#8272
> Mastodon:   https://social.anaproy.nl/@proycon   (@proy...@social.anaproy.nl)
> Twitter:https://twitter.com/proycon
> Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
> 

Hi Maarten,

Sure that's possible. I have released 0.2 now.

If you have additional fixes/changes which are generic enough to be upstreamed
they are of course welcome.

Thanks for the work so far,

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] Unexpected session close by clicking a link

[Hiltjo Posthuma]

On Fri, Sep 11, 2020 at 01:55:12PM -0300, Sure Thing wrote:
> On Thu, Sep 10, 2020 at 7:31 PM Hiltjo Posthuma  
> wrote:
> >
> > On Thu, Sep 10, 2020 at 04:24:20PM -0300, Sure Thing wrote:
> > > Hi, I've been using dwm for a few months, excellent wm. Recently I
> > > clicked a link (retro console review on youtube) and the session
> > > closed (as if Meta-Shift-Q was pressed).
> > > I compiled a version with symbols, attached gdb to the process, and
> > > the last instruction from dwm is:
> > >
> > > 286 memcpy(buf, utf8str, len);
> > > [...]
> > >
> > > the last jump is at:
> > > 1888 in ../sysdeps/x86_64/multiarch/memcpy-ssse3.S
> > > (gdb) s
> > > 0x7f30606195b3 in inflate () from /lib/x86_64-linux-gnu/libz.so.1
> > >
> > > and the last output is:
> > > __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:1888
> > > 1888 in ../sysdeps/x86_64/multiarch/memcpy-ssse3.S
> > > (gdb) s
> > > 0x7f30606195b3 in inflate () from /lib/x86_64-linux-gnu/libz.so.1
> > > (gdb) s
> > > Single stepping until exit from function inflate,
> > > which has no line number information.
> > > 0x7f306063b737 in png_read_row () from 
> > > /lib/x86_64-linux-gnu/libpng16.so.16
> > > (gdb) s
> > > Single stepping until exit from function png_read_row,
> > > which has no line number information.
> > > [Inferior 1 (process 53650) exited with code 01
> > >
> > > Has this happened to someone else? Greets from south america!
> > >
> > > --
> > > Eronte.
> > > ĄFatwolf!
> > >
> >
> > Hi Eronte,
> >
> > Do you use the latest dwm version (without patches to reproduce the issue of
> > course)?
> >
> 
> Good day Hiltjo, I'm using vanilla dwm from the ubuntu repos:
> 
> dwm |  6.1-5 | http://ubuntu.dcc.uchile.cl/ubuntu focal/universe
> amd64 Packages
> 
> > The last line seems to correspond to this:
> > https://git.suckless.org/dwm/memfile/drw.c.html#l136
> 
> Error 404.
> 
> > But I assume the trace is incorrect and it's the common Xft bug, but the 
> > latest
> > git and release version has a workaround for this.
> >
> > The st FAQ has some information (maybe you see a similar error in the Xorg 
> > log)?
> > https://git.suckless.org/st/file/FAQ.html#l238
> 
> Checking the xorg log. Hmmm, no errors, and shows a normal exit:
> 
> [ 48733.193] (II) Server terminated successfully (0). Closing log file.
> 
> > in drw.c there are comments about this workaround also, like:
> > https://git.suckless.org/dwm/file/drw.c.html#l136
> 
> Ooh, this may be it. A colored font in the page.
> 
> > Please let me know with more detailed information if it's not the Xft bug 
> > but
> > some issue in drw_text() or so.
> 
> Trying dwm git version. Success! Problem has left the building.
> I'll read the source file and see what I can learn from this.
> I really appreciate your help, thank you!
> 
> -- 
> Eronte.
> ¡Fatwolf!
> 

Hi,

Thanks for the reply and confirming it is not an other issue.

I made a typo after pasting the url, it should be:
https://git.suckless.org/dwm/file/drw.c.html#l136

You're welcome,

-- 
Kind regards,
Hiltjo

Re: [dev] [dwm] Unexpected session close by clicking a link

[Hiltjo Posthuma]

On Thu, Sep 10, 2020 at 04:24:20PM -0300, Sure Thing wrote:
> Hi, I've been using dwm for a few months, excellent wm. Recently I
> clicked a link (retro console review on youtube) and the session
> closed (as if Meta-Shift-Q was pressed).
> I compiled a version with symbols, attached gdb to the process, and
> the last instruction from dwm is:
> 
> 286 memcpy(buf, utf8str, len);
> [...]
> 
> the last jump is at:
> 1888 in ../sysdeps/x86_64/multiarch/memcpy-ssse3.S
> (gdb) s
> 0x7f30606195b3 in inflate () from /lib/x86_64-linux-gnu/libz.so.1
> 
> and the last output is:
> __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:1888
> 1888 in ../sysdeps/x86_64/multiarch/memcpy-ssse3.S
> (gdb) s
> 0x7f30606195b3 in inflate () from /lib/x86_64-linux-gnu/libz.so.1
> (gdb) s
> Single stepping until exit from function inflate,
> which has no line number information.
> 0x7f306063b737 in png_read_row () from 
> /lib/x86_64-linux-gnu/libpng16.so.16
> (gdb) s
> Single stepping until exit from function png_read_row,
> which has no line number information.
> [Inferior 1 (process 53650) exited with code 01
> 
> Has this happened to someone else? Greets from south america!
> 
> -- 
> Eronte.
> ¡Fatwolf!
> 

Hi Eronte,

Do you use the latest dwm version (without patches to reproduce the issue of
course)?

The last line seems to correspond to this:
https://git.suckless.org/dwm/memfile/drw.c.html#l136

But I assume the trace is incorrect and it's the common Xft bug, but the latest
git and release version has a workaround for this.

The st FAQ has some information (maybe you see a similar error in the Xorg log)?
https://git.suckless.org/st/file/FAQ.html#l238

in drw.c there are comments about this workaround also, like:
https://git.suckless.org/dwm/file/drw.c.html#l136

Please let me know with more detailed information if it's not the Xft bug but
some issue in drw_text() or so.

Thanks,

-- 
Kind regards,
Hiltjo

Re: [dev] [dmenu] ASCII tab and unit separator cause startup lag

[Hiltjo Posthuma]

On Thu, Aug 06, 2020 at 10:06:35AM -0400, Greg B wrote:
> Hello,
> 
> I've been using dmenu for a window switcher with wmctrl. I noticed after
> a recent refactor to my window-listing function that I was seeing
> significant lag in the dmenu window popping up after my hotkey. I've
> done some digging and determined that including tabs and \037 (ASCII
> unit separator) cause noticeable startup delays in dmenu. It appears
> that no keys are lost - anything I type after invoking my hotkey for
> this script gets captured after dmenu finally renders. Nevertheless this
> is an annoyance.
> 
> I am using the packaged dmenu in Ubuntu 20.04. A sample of the output of
> my window listing script is below, along with two simpler samples
> exhibiting slow startup behavior.
> 
> I'm happy to do further testing or troubleshooting if anyone can point
> me in the right direction.
> 
> -gb
> 
> $ dmenu -v
> dmenu-4.8
> 
> # simple repro with tabs - startup render seems to scale linearly with
> # number of tabs
> $ for i in {1..10}; do echo $'\t'; done | dmenu
> 
> # simple repro with \037
> $ for i in {1..10}; do echo $'\037'; done | dmenu
> 
> # sample output of window-listing script. tab-separated fields, and
> #
> \037 precedes the window ID (last column, 0x...)
> xfce4-panel.Xfce4-panel   
> xfce4-panel   0x0123
> xfdesktop.Xfdesktop   Desktop 0x02400013
> Navig
> ator.Firefox  software0x0419
> Alacritty.Alacritty   alacritt
> y-terminal0x0522
> signal.Signal Signal  0x0641
> spoti
> fy.SpotifyWithin  0x06c1
> evolution.Evolution   Inbox   0x08c00
> 020
> emacs.Emacs   emacs   0x074000cb
> rambox.Rambox Rambox  0x04800
> 001
> evolution.Evolution   [dmenu] 0x08ca4ad4
> 
> 

Hi,

Probably some complicated font setup. No issues here.

-- 
Kind regards,
Hiltjo

Re: [dev] [st] XIM switching problems in combination with XKB dead keys

[Hiltjo Posthuma]

On Fri, Jul 17, 2020 at 07:01:59PM +0200, Maarten van Gompel wrote:
> Hi,
> 
> I identified a problem when switching input methods: XIM and XKB keymaps
> with dead keys can not be used properly in the same session as that
> breaks the dead keys (= composition keys for diacritics).
> 
> My situation: I use regular XKB to type in languages using a latin or
> cyrillic script, but for Chinese I need of course need a proper input
> method (e.g. fcitx or ibus-libpinyin). I want to change between input
> methods on the fly, this currently does not work, if st is started with
> a XMODIFIERS="@im=whatever" then normal dead keys don't work, regardless
> whether the underlying XIM server is running or not, if it is started
> with an empty XMODIFIERS="", then they do work. It means I need to
> restart the terminal if I want to properly switch between chinese and my
> usual dead keys. Switching in my case entails killing the XIM server if
> it's running and running setxkbmap to set the desired keymap.
> 
> To reproduce:
> 
> Case 1)
>  $ export XMODIFIERS=""
>  $ setxbkmap es
>  $ st
> Type apostrophe a and output is á  , as expected, but of course no XIM now
> 
> Case 2)
>  $ export XMODIFIERS="@im=fcitx"
>  $ setxbkmap es  #spanish XKB keymap to illustrate the issue
>  $ st
> Type apostrophe a and output is 'a instead of á
> 
> 
> I think st should behave the same way most applications do; if the xim
> server is not running, it should exhibit the same behaviour as if no XIM
> was configured at all. (for comparison; terminals like urxvt and
> alacritty behave in this way, GTK and QT apps too)
> 
> The problem was introduced in the following commit:
> 
> 787c9a55fea7131b4f1e5c7699b68b3517db8e49 Quentin Rameau 
> x: fix XIM handling
> 
> Prior to this commit though, the situation was much worse as st would
> simply crash if the XIM server stopped, so there's good progress but we
> aren't entirely there yet :)
> 
> Regards,
> 
> --
> 
> Maarten van Gompel
> 
> proy...@anaproy.nl
> https://proycon.anaproy.nl
> https://github.com/proycon
> 
> GnuPG key:  0x39FE11201A31555C
> XMPP:   proy...@anaproy.nl   Matrix: @proycon:matrix.anaproy.nl
> Telegram:   proycon  IRC: proycon (freenode)
> Mastodon:   https://social.anaproy.nl/@proycon   (@proy...@social.anaproy.nl)
> Twitter:https://twitter.com/proycon
> 

Hi,

Thanks for the feedback. Is anyone willing to work on this and improve general
XIM support?

Alternatively maybe the current code should be removed and completely reworked?

-- 
Kind regards,
Hiltjo

[dev] [st] release 0.8.4

[Hiltjo Posthuma]

Hi all,

st is now tagged 0.8.4 as release and available as a tarball.

I want to thank all people who made patch contributions to make st better.

Below most of the changes are listed.


Security


* config.def.h: add an option allowwindowops, by default off (secure).

  Similar to the xterm AllowWindowOps option.
  The sequence for base64-encoded clipboard copy is now guarded and off by
  default because it allows a sequence written to the terminal to manipulate the
  clipboard of the (other) running user non-interactively.


Features


* Integrate auto-sync: draw on idle to avoid flicker/tearing by avih.
  st could easily tear/flicker with animation or other unattended
  output. This commit eliminates most of the tear/flicker.

* Optimize column width calculation and UTF-8 encode for the common-case ASCII.
  In particular on glibc and OpenBSD the wcwidth() call is more expensive.
  On musl there is no/little difference.

* Add support for REP (repeat) escape sequence and xterm compatibility, by
  avih.  The capability is not exposed yet due to some issues with
  applications.

* Call xsetcursor to set win.cursor in main, by Steve Ward.
  Allowing to set the st snowman cursor extension dynamically.


Fixes and other changes
---

* Fix unicode glitch in DCS strings, by Tim Allen.
  The related sixel stub code is now removed also.

* Fix for incorrect (partial) written sequences when libc wcwidth() == -1
  and using st -o.

* Mouse selection fixes, by Jakub

* Make shift+wheel behaves as shift+Prev/Next, patch by k0ga
  This patch adds a new hack, making shift+wheel returning the
  same sequences than shift+Prev/Next, meaning that scroll or
  any other similar program will not be able to differentiate
  between them.

* Expose rin terminfo capability.
  Tianlin Qu discovered that st is missing rin (scroll back #1 lines).

* Replace exit(3) by _exit(2) in signal handler sigchld(), by Jan.
  This change prevents st to crash and dump core in some situations.

* FAQ: add details and a patch example for single-buffering (for the w3mimg
  hack).

-- 
Kind regards,
Hiltjo