Re: [dev] Build system: redo

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

On 21/01/03 02:38, Greg Reagle wrote:
> I am in the habit of using printf rather than echo because of the drawbacks 
> of echo as explained in 
> https://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo.
>   For
>   echo relinking
> specifically, it doesn't matter.  For 
>   echo recompiling $2.c
> specifically, if $2 contains any characters that echo might interpret, it 
> might come out wrong.

echo is generally used much more often than printf in shell scripts, if not
for anything else then for historic reasons. Any problems with characters which
could be interpreted by echo can be avoided by simply not using such characters
or strings in filenames, but limiting oneself to, for example, [A-Za-z0-9._-]+..

> They are educational messages for me because I am learning.

This is not only a convention of Go, but also a much older convention of
UNIX programs, to avoid output unless there is an error, in which case the
output is made to stderr. This is not without reason. In UNIX, programs should
ideally work with each other through piping, and their output can also be
redirected to a file. I think Sergey's example is very good, as cc does not
output anything, unless it has a warning or an error, in which case it also uses
stderr. redo uses a similar philosophy, in contrast to GNU Make, which outputs
whenever it enters a directory (for example).

Best regards,
Strahinya Radich

Re: [dev] [dwm][bug] Programs teleport tag on startup

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

On 21/01/16 10:13, Spenser Truex wrote:
> I can't imagine any way that this is desirable. I will try to patch a
> fix later, seems like low hanging fruit.

I think this should be a patch for dwm, in order to not increase the
complexity of the code. The idea of dwm and suckless programs is simplicity of
the code, additional functionality comes in the form of patches and is optional.



signature.asc
Description: PGP signature

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

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

On 21/02/10 01:10, Κράκ Άουτ wrote:
> 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?
> 
> Can I also achieve 0/sec somehow? I suggested 1/sec because division by
> zero is not possible.

I'm not familiar with the context of the quoted code, but it looks like
if checks for the time difference between the current time and last recorded
time. The check succeeds if the difference is 1000/60 ~ 17 in the first case and
1000 in the second case. As the divisor gets closer to zero, the threshold
against which the difference is tested becomes greater. As you said, division by
zero is not possible. The division is there in the first place purely for the
sake of code clarity, the difference is an integer constant and can be specified
as just a single number, without the division. 

From the purely logical standpoint, "achieving 0/sec" would be
equivalent to not executing the code in the if-block at all, and would be best
accomplished by commenting the block out.


signature.asc
Description: PGP signature

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

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

On 21/02/10 03:46, Страхиња Радић wrote:
> time. The check succeeds if the difference is 1000/60 ~ 17 in the first case 
> and
> 1000 in the second case. As the divisor gets closer to zero, the threshold

*is lesser than or equal to



signature.asc
Description: PGP signature

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

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

On 21/02/10 08:09, Κράκ Άουτ wrote:
> resources. So if the if-block is removed you get the opposite of 0/sec.
> 
The if block includes not only the condition "if (/*...*/)", but also
the line or a block of code following it, whose execution is controlled by the
condition.



signature.asc
Description: PGP signature

Re: [dev] st: enlarge font

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

On 21/03/20 12:01, Nuno Teixeira wrote:
> st -f "Liberation Mono":pixelsize=16 is my desired size.
> 
> I will create a config.h with:
> static char *font = "Liberation 
> Mono:pixelsize=16:antialias=true:autohint=true";
> 
> And compile with it, is that the correct way to do it?

It will work, but more correct would be to change config.def.h, per
Makefile:

config.h: config.def.h
cp config.def.h config.h

Also, in the future you can also try setting different values for
"size=" instead of "pixelsize=", as it works better for some fonts.


signature.asc
Description: PGP signature

Re: [dev] st: enlarge font

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

On 21/03/24 04:13, Cág wrote:
> Actually config.def.h is a template, the default configuration, and
> probably should be left unmodified.  The rule you mentioned (run by `make
> config.h` copies config.def.h into config.h, obviously, and then config.h
> is supposed to be edited.

Didn't know that, thanks. What is the reasoning behind having a separate
.def.h in the first place then? Wouldn't editing a local copy of config.h from
the cloned repository suffice?


signature.asc
Description: PGP signature

[dev] [svkbd] layout.sr.h

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

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



signature.asc
Description: PGP signature

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

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

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.

diff --git a/layout.sr.h b/layout.sr.h
new file mode 100644
index 000..4925b53
--- /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, XK_Cancel },
+};
+
+#define LAYERS 1
+static char* layer_names[LAYERS] = {
+	"sr",
+};
+
+static Key* available_layers[LAYERS] = {
+	keys_sr,
+};


signature.asc
Description: PGP signature

Re: [dev] Completeness suckless

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

On 21/04/09 03:18, Laslo Hunhold wrote:
> You can build software with the goal of user-friendliness in mind, but
> this always comes with concessions. As long as you provide consistent
> and easy to understand user-interfaces (APIs, Synopses, etc.), it is, I
> think, the user's turn to try to understand them to the fullest, even
> if it means learning a bit of a programming language.
> 
> How do the others see it?

I think that "user friendliness" carries complexity with it that is just being
concealed from the user. There are prejudices about what is "friendlier": having
a complex program that does a lot of things with little to no input, which also
means less control, or having a simple program that does one thing well, is
simple enough to understand and works well with other such simple programs. It
becomes apparent when there is some error or something unpredicted happens: it
is often difficult to diagnose the error and equally difficult, if not
impossible, to present a working solution for a "user friendly" (=complex)
program compared to a simple program. The solution in the case of a simple
program is exact and textual, easily transmitted in digital form or pronounced,
compared to the difficulty of having to describe where exactly, and how to click
in a GUI.



signature.asc
Description: PGP signature

Re: [dev] [st] libxft-bgra X Error

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

On 21/04/19 11:59, Luuk van Baal wrote:
> I was looking for pointers in regards to this error I'm receiving when
> using 
> libxft-bgra(https://gitlab.freedesktop.org/xorg/lib/libxft/-/merge_requests/1).
>  I explained the issue in 
> (https://gitlab.freedesktop.org/xorg/lib/libxft/-/merge_requests/1#note_884325):
> 
> "This patch (installed through this AUR package) leads to
> 
> X Error of failed request:  RenderBadPicture (invalid Picture parameter)
>   Major opcode of failed request:  139 (RENDER)
>   Minor opcode of failed request:  8 (RenderComposite)
>   Picture id in failed request: 0x3b84
>   Serial number of failed request:  15315
>   Current serial number in output stream:  15327
> 
> when scrolling through this 
> file(https://raw.githubusercontent.com/luukvbaal/iconlookup/master/iconlookup)
>  in suckless' simple terminal using a patched nerd font. Very peculiar I know 
> but this is the only way I've been able to reproduce this error.
> This sequence crashes the terminal every time:
> open st -> open iconlookup in vim -> press 160gg to go to line 160(full size 
> terminal showing 47 lines centered around line 160).
> The same error does not happen when using different terminals but also does 
> not happen in st when using the standard libxft from the arch repositories.
> I'm interested in figuring this out but I'm not sure how to debug the
> error. Would appreciate any pointers or thoughts regarding this."
> 
> I'm curious to know your thoughts on this as like I said the problem
> does not occur with mainline libxft and st, does occur with libxft-bgra
> and st, but does not occur with libxft-bgra and other terminals(tried
> xterm/kitty/alacritty). Might this issue be fixed on st's side?

Interesting, I'm not getting this error. I use Artix Linux, libxft-bgra
2.3.3.r7.7808631e-1 from AUR, vim 8.2.2653-1 and my modified st which I
regularly update from suckless repo[1].  Also ttf-nerd-fonts-symbols, *not*
ttf-nerd-fonts-symbols-mono, as the latter package has a bug with the uppercase
"E".[2] (Maybe related?)

Side note: I prefer :160 in vim to go to a particular line.

[1]: https://git.sr.ht/~strahinja/st
[2]: https://github.com/ryanoasis/nerd-fonts/issues/581



signature.asc
Description: PGP signature

Re: [dev] [st] libxft-bgra X Error

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

On 21/04/19 07:06, Страхиња Радић wrote:
> Interesting, I'm not getting this error. I use Artix Linux, libxft-bgra
> 2.3.3.r7.7808631e-1 from AUR, vim 8.2.2653-1 and my modified st which I
> regularly update from suckless repo[1].  Also ttf-nerd-fonts-symbols, *not*
> ttf-nerd-fonts-symbols-mono, as the latter package has a bug with the 
> uppercase
> "E".[2] (Maybe related?)

After further testing, I can say that this bug does happen, but inconsistently,
and with no obvious way to reproduce. When it does happen, I get the following
output:

X Error of failed request:  RenderBadPicture (invalid Picture parameter)
  Major opcode of failed request:  139 (RENDER)
  Minor opcode of failed request:  8 (RenderComposite)
  Picture id in failed request: 0x1
  Serial number of failed request:  4871
  Current serial number in output stream:  5009

It also isn't tied to vim. I tried using joe -asis and less, with the same
result. Interestingly enough, cat iconlookup doesn't crash st, even when
scrolling back with tmux to the offending lines.



signature.asc
Description: PGP signature

Re: [dev] less lines of code suck less

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

On 21/05/03 05:27, Greg Reagle wrote:
> And if it has less lines, in a higher level language, sounds like a win.

Higher level languages usually mean more complexity and less control. Having
less lines in a higher level language doesn't mean much if the language adds
unnecessary overhead "behind the scenes". Ideally, the least bloat and the most
control is achieved by directly programming machine code. That's what
performance-critical code is written in. It isn't considered as "practical" for
most things, though.



signature.asc
Description: PGP signature

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

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

On 21/05/22 06:50, Tobias Bengfort wrote:
> https://sw.kovidgoyal.net/kitty/keyboard-protocol.html
> 
> Basically it provides a way to send unambigous esc and other keys as well as
> key release events to terminal programs while being mostly backwards
> compatible.
> 
> It sounds like a reasonable proposal to me. What do you make of it? Should
> this be implemented in st?

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, in fact I think that there are none. It is just a
proposal used by one terminal emulator and not regulated by any of the existing
standards bodies.

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? Its job is
to just allow terminal I/O. It should work on older hardware, and on systems
where OpenGL isn't or cannot be installed. But it seems to have grown a
following among people who generally like to use complicated software.

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.



signature.asc
Description: PGP signature

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

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

On 21/06/20 08:25, opal hart wrote:
> Suckless software isn't a void separate from the rest of the world,

Suckless software is following a specific set of principles, and the software
that sucks is not following those principles. The two are separate.

> and
> the "suckless philosophy" is constantly inconsistent with its own
> beliefs. 

I will join Hiltjo in asking for examples.

> Of all the issues I have with kitty, GPU acceleration is not one of
> them.

It doesn't matter what issues you might have. It is an unnecessary feature. A
terminal emulator is not a graphically intensive program like a game. It is
meant to enable terminal I/O.

> And display it.

"O" in "I/O" stands for "output".

> There are plenty of other terminal emulators for systems where it would
> be impractical to install kitty.

Why would they need to support kitty's protocol? If we are speaking about st, it
is a finished program, fulfilling its purpose while not adding unnecessary 
bloat.

> You're on a mailing list for opinionated software to ... complain about
> other opinionated software?

Not complain, just stating that while most suckless programs tend to respect
standards like POSIX, introducing a protocol which is nonstandard to a standards
body, for example ISO, by someone unwilling to potentially modify that protocol
due to the discussion in the said body would be pointless.

> And if anyone
> does want to support this protocol, it would be better done in an
> optional feature patch or a fork.

I agree. However, that was not what Tobias (the OP) called for. It was rather
the inclusion of the support for kitty protocol in base st.



signature.asc
Description: PGP signature

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

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

On 21/06/21 07:00, Tobias Bengfort wrote:
> To me it is also obvious that this protocol sucks less than the old one.

If we go only by the added code, it is quite the contrary. Less is more.

> Currently you need to write a GUI if you need to get reliable keyboard
> events. This proposal would allow you to do the same in a TUI. TUIs require
> much less code compared to GUIs.

TUIs are still not ideal. What is closer to ideal is CLI. Nonetheless, there are
many core suckless programs which are X programs, and none that I know of which
are TUI (be it using bloated libraries like ncurses, or using simpler solutions
like termbox). Even the IRC client ii is not TUI but CLI.

This protocol seems to cater to TUIs, adding functionality which is as of now
not widely accepted nor widely implemented.



signature.asc
Description: PGP signature

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

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

On 21/06/29 10:03, Martin Tournoij wrote:
> > It is true that some people could be driven away after being greeted 
> > with a black screen without any preconfigured keybinding to open a 
> > terminal or dmenu, but dwm takes pride in "keeping its userbase small 
> > and elitist, withoutnovices asking stupid questions".
> 
> That has never been part of the appeal for me. Suckless are tools for
> *advanced* users, yes, and elides most "hand-holding" which makes it
> better for folks like us. By extension this means it's somewhat
> "elitist", but I've never considered that a a goal in and of itself.

I'd just add that (true, intrinsic) elitism, in relation to autonomy in learning
and exploring software, or even coming up with solutions to problems on one's
own, is not a bad thing. Not everything needs to cater to the ignorant masses.
No corporate edge needs to be gained by having a larger userbase.  By catering
to the masses, software inevitably goes against the suckless principles, adding
unnecessary features and dependencies.



signature.asc
Description: PGP signature

Re: [dev] [dwm] Why should (or shouldn't) dwm have a spawn function?

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

On 21/06/29 02:04, qsm...@tutanota.com wrote:
> However, worded at it is now, I think we will agree that for someone on the
> outside it will come out as proud or warding off, whereas something like "we
> have no interest in being very popular or trendy; our software will not be
> expanded to adapt to every user's possible particular taste" might be more to
> the point here raised and does look quite healthy.

The sentence is precise and to the point. There's no need to change it to
cater to those who are *intrinsically* disinterested in:

- configuring programs by changing the source code 

- using command line programs, often several at a time, working together through
  pipes

- foregoing flashy UI libraries which just add eye candy and megabytes of
  pointless code

and by extension, those disinterested in using suckless programs. It is their
preference that sets them apart, and there's nothing wrong in that. Why force
them to use suckless software when they don't want to? Those who do want to use
it, understand and respect its philosophy will not be turned off.



signature.asc
Description: PGP signature

Re: [dev] suckless indicators?

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

On 21/07/08 12:49, Nikita Zlobin wrote:
> I tried to make mere windows more useful by making them to output more
> useful content in place of window name. One existing example is gentoo
> emerge, which prints status in number of emerged packages with system
> load.

But... why? There is already slstatus, which does an excellent job. One can make
a shell script which fetches information from wttr.in (for example), add the
call to that script to crontab, and have slstatus pick up that information. Even
dwmblocks adds unnecessary functionality - why would a status indicator need to
support mouse clicks at all? Its job is to display a minimum of information, not
lead to windows with more information.

You have to understand that for a program to be considered suckless, it needs to
be straight to the point and minimal. Extra functionality is added through
patches.


signature.asc
Description: PGP signature

Re: [dev] suckless indicators?

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

On 21/07/08 12:30, Nikita Zlobin wrote:
> Perhaps because user wants :P
[...]
> Writing to window title is primary function of my approach. It could be
> done by main app (best), but this time it's dedicated script, designed
> to run parallel and write to window title, while main app displays it
> content. How can it be more minimal?
[...]
> - Main app, doing it themselves? Better of has. Or find better point to
>   add this feature for app, that doesn't support that.

Catering to user desires is a pitfall which leads to bloated software. It is
easy for the users of suckless software to customize it, so there's no need to
include those customizations in the main repositories, except maybe as patches.
The drawbacks of doing the opposite outweigh the benefits.

> What's better way to open app, logically related to some applet: click
> applet, which is here and now, or again open dialog/menu/term,
> select/type command...

The best way to start a program (I avoid the term "app"/"applet" to refer to
programs and scripts) is to type its name. In dwm, that's what dmenu_run is for,
by default invoked by Mod+p.  For more advanced use of programs there's st.

> (ah, forgot another example - mc and even shell, printing cwd to
> statusline)

While generally better than GUI file managers in terms of dependencies, Midnight
Commander (and in fact, any file manager) is not suckless software. TUI in
general is not suckless. I believe there was a discussion recently about this.

If you are referring to 

https://suckless.org/rocks/

it states at the top:

> Software on this page should have ideas similar to the suckless philosophy.

Note the wording: "similar".

> Each has own understanding of suckless.

That's fine, but everyone's understanding of suckless is not necessarily the
mainline understanding.

> About patches: I'm not sure, what it's about.
> - If about my specific implementations, using scripts, then there's
> nothing to be simplified.

The functionality itself, the "problem" those scripts are trying to solve, is
not fundamental and would best constitute a patch instead of being included in
the baseline repository of a package like st.

As a standalone project, I again don't see the need to include this in the
suckless repositories. 



signature.asc
Description: PGP signature

Re: [dev] suckless indicators?

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

On 21/07/08 02:47, Nikita Zlobin wrote:
> People don't serve machines - machines serve people.

To turn this around, machines serve people who know how to control them. People
who don't should not dictate features to be included in software.

I think the results of doing the opposite are obvious and commonplace. Suckless
movement is different, and that's part of its appeal.



signature.asc
Description: PGP signature

Re: [dev] Auditing requiirement for sbase

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

On 21/07/30 10:42, EuAndreh wrote:
> > but POSIX already sells such a set of unit tests.
> 
> A curiosity of mine: was such test suite ran against sbase?

If you have found a bug in sbase, do report it.

Otherwise, the idea of suckless software is for software to have simple and easy
to understand source code, which by extension automatically means less errors
and less need for "unit tests". See:

https://suckless.org/philosophy/



signature.asc
Description: PGP signature

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

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

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.



signature.asc
Description: PGP signature

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

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

On 21/07/30 09:24, Hiltjo Posthuma wrote:
> 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.

Who reviewed the layout.sh.h? Can't the same person review layout.sr.h?



signature.asc
Description: PGP signature

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

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

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 000..35ffcc2
--- /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_

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

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

On 21/08/07 08:02, Sagar Acharya wrote:
> It enhances the value of suckless by pointing the problems in gigantic
> softwares. Let me know what you think.

The plural form of "software" is "software". "Softwares" is not a real word in
English.

> Thanking you

*Thank you


> It enhances the value of suckless by pointing the problems in gigantic
> softwares.

What is said on https://suckless.org/philosophy should already be more than
enough to grasp the concept.


On 21/08/07 08:59, Hadrien Lacour wrote:
> To illustrate this with programming, the majority of "programmers" aren't
> hackers, they're barely programmers. They want a language with an ecosystem
> that gives them packages to do something as simple as padding a string, or a
> builtin HTTP server in the standard library

So much this. I'd even go to change "barely programmers" into "barely coders".

This is why I cannot seriously consider languages like Rust.


On 21/08/07 02:54, Sagar Acharya wrote:
> This is where I diverge from suckless, suckless goes for hardcore minimalistic
> software at cost of user experience. 

Wrong. I'd argue that the "user experience" in most programs that suck is worse
than the "user experience" using suckless programs. That's one of the reasons we
call them like that - "programs that suck" and "suckless programs".

I believe we already discussed this about four months back.


>Addicted to almost all software out
> there like WhatsApp, Facebook, and many more things, most are never gonna use
> stuff like dwm. And things like Windows would keep them there. I myself
> use dwm, hyperbola OS, but suggesting it to common people wouldn't be
> wise. They'll switch back to Windows, and this time maybe forever.

And?

This sense of urgency and worry about the size of the userbase seems to be tied
to "software development" inside (big tech) corporations. They add (or remove)
features to software guided by statistical analysis of the target audience with
the aim of supporting what is perceived to generate the most profit, not by the
program's purpose or any other reason. Suckless movement is not a corporation.
It is a gathering of programmers writing software for themselves and others who
value the principles of simplicity and quality in software.

If anyone wants to use other software, by all means they should. There's nothing
wrong with that, but on the other side, that shouldn't influence suckless
programs.



signature.asc
Description: PGP signature

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

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

On 21/08/16 09:56, Robert Alm Nilsson wrote:
> 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

Read the FAQ.



signature.asc
Description: PGP signature

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

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

On 21/08/18 08:06, Mateusz Okulus wrote:
> You need libxft-bgra. It's a bug in xft.
> 
> Read https://git.suckless.org/st/file/FAQ.html for explanation.
> 
> Notice that instead of disabling as in FAQ you can install this fork of
> xft which is what I recommend, because it'll also work on dwm, dmenu
> etc.

libXft can still crash, even with libxft-bgra applied:

https://gitlab.freedesktop.org/xorg/lib/libxft/-/merge_requests/1#note_899767

Note, libXft developers seem inactive and don't respond to messages, even to the
author of the libxft-bgra patch.



signature.asc
Description: PGP signature

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

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

On 21/08/20 07:27, Mateusz Okulus wrote:
> I haven't experienced any crashes after installing xft-bgra. For regular
> use this seems to be enough. Even then both dwm and st use libxft, and
> I'm fairly certain that there are no patches to replace it. There isn't
> a better alternative afaik.

I was too under the impression that libXft works all the time, but then had an
unpleasant surprise when it did crash.

I have debugged the issue for a while, and my conclusion is that it is
inconsistent. This means that while the emoji can work in libXft without
crashing for some time (with the libxft-bgra patch applied), occasionally there
will be a crash. I haven't been able to create a reliable reproducible
environment for this crash. 

This inconsistent behavior has led me to believe that maybe some piece of code
within the library relies on reading values outside of the allocated memory
space.



signature.asc
Description: PGP signature

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

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

To add to my previous message, this occasional crashing could be the reason
behind the recommended approach by suckless - disabling the color emoji support
altogether, instead of having programs run unreliably.

And finally, when I recommended reading the FAQ, it was precisely because this
issue was described near the end of it (not the inconsistent behavior, but there
are links to three separate issue threads, one of them having a link to the
thread that I linked. Most importantly, it states that this:

 *
 *** is not an st issue, but libXft issue! ***
 *

and that

 **
 *** libXft developers should be bugged about it, and not suckless! ***
 **

Again, libXft developers seem inactive (probably focusing on Wayland instead of
X.Org/Xft).



signature.asc
Description: PGP signature

Re: [dev] Wayland compositors

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

On 21/08/31 02:28, Nick wrote:
> Hi all,
> 
> I'm thinking it would be fun to play around with Wayland, so was 
> looking at different compositors (which do window management plus 
> other stuff). Has anyone else on the list taken Wayland for a spin 
> and had any experience with them?
> 
> From a search around the 3 that look interesting to me, a dwm user 
> for many years, are:
> - velox - written by Michael Forney, described as "inspired by dwm 
>   and xmonad"
> - sway - i3 for Wayland, undoubtedly mature, undoubtedly more 
>   features than I'd prefer
> - dwl - "dwm for Wayland", looks nicely dwm-ish, though no built-in 
>   status bar so I guess I'd have to find some external software to 
>   provide that.
> 
> Any thoughts, experiences, recommendations?
> 
> Nick
> 

https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277



signature.asc
Description: PGP signature

Re: [dev] Wayland compositors

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

On 21/09/08 12:28, Nick wrote:
> honest I found the arguments made there to be largely unconvincing, 

Any argument in particular and why?

> * I'm thinking in particular of the repeated "emojis broke my st" 
>   mails, caused by a bug in Xft that noone upstream seems to care much
>   about fixing, and the fact that surf is a really just a nice
>   interface atop the hulking edifice of webkit2/gtk+

This is the fault of X developers, who decided to dedicate their time entirely
to Wayland. In their eyes, Wayland is the continuation of X.Org.

It is clear by now that Wayland is influenced by big corporations, RedHat in
particular, which is also forcing things like GNOME, systemd and Rust in the
Linux kernel upon the users.

Wayland sucks. X.Org sucks too, but it is still much better than Wayland.



signature.asc
Description: PGP signature

Re: [dev] Wayland compositors

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

By the way, here's another article not on Github (but linked from that page):

https://tildearrow.org/?p=post&month=2&year=2021&item=antihs



signature.asc
Description: PGP signature

Re: [dev] Wayland compositors

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

On 21/09/08 01:36, Nick wrote:
> The fact that the Jitsi devs closed 
> the bug as "not much we can do on our side" doesn't mean "wayland 
> broke it and we can't fix it".

It's exactly the same thing.

> the screen recording / sharing stuff - it works differently on 
> Wayland (for not-bad reasons),
[...]
> good reasons (thinking of the "prevents GUI applications from 
> running as root" and "breaks windows rasing/activating themselves").

The issues listed show a pattern and the impact of breaking with a
long-standing, time-tested tradition just for the sake of doing something "new"
and "different". "New" doesn't automatically mean "good".

They also show the attitude of the developers responsible for Wayland. I don't
like it when the "developers" tell the users what is good for them, especially
when they are being opinionated and stubborn for no reason at all.  Let the
users decide how they are using the software. Let us be able to make mistakes! 

It is the same line of thought as when we compare C to a language like Rust. One
of the key reasons why C is better than Rust and similar overprotecting
opinionated languages, is because it gives user the freedom to do whatever he
wants, mistakes included. In this, C is closer to machine language, and thus
more powerful, more expressive, allowing finer control.

Similar thing to Wayland happened with systemd, the developers responsible for
it were acting unreasonably and immaturely when confronted with different
opinions. Whenever one lacks civility in communication and resorts to
swearwords, that shows faulty of his cause and a weakness of his conviction.

You haven't mentioned the other points, just some of the major ones being the
issue of non-GNOME desktop environments, for example KDE. I'm not using KDE, but
why just erase it in favor of GNOME monopoly? I'm using no desktop environment,
I'm using dwm, but many of its key features are not supported by Wayland. 

Again and finally, I don't want to have to change my software-using habits just
because some "developer's" decision. I want to choose what software I use and
how. Thankfully, there are free licenses, and no free software is ever truly
"dead". If Wayland becomes enforced like systemd, in time there will be a
solution comparable to runit/OpenRC/s6.



signature.asc
Description: PGP signature

Re: [dev] Wayland compositors

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

On 21/09/16, 20:36, Kyryl Melekhin wrote:
>And remember, always follow unix philosophy - go for what works first, optimize
>it later.

This should read "programs should do one thing and do it well" (DOTADIW)[1],
with the added "and work together".  Exactly what Wayland's monolithic,
opinionated concept doesn't. If a compositor crashes, the whole session goes
down. Comparatively in X.Org, you lose window transparency, shadows and
animations and can continue your work as normal. Wayland is in many ways
reminiscent of systemd.

[1]: https://en.wikipedia.org/wiki/Unix_philosophy


On 21/09/17 06:33, Tobias Bengfort wrote:
>I think much of the hate for wayland is misdirected. 

Although I cannot speak for everyone, criticism of Wayland is driven by facts,
not emotions. "Hate" or "love" don't have anything to do with it.

> Don't get me wrong, the state of wayland is bad. But IMHO that is not entirely
> the wayland people's fault.

It doesn't matter who is responsible. If Wayland is not finished, its developers
shouldn't act like it is and force it on users and programmers. Ideally, common
courtesy would be to dedicate part of their efforts towards the "long term
support" (fixing bugs, actual "finishing") of X.Org without introducing new
features. For example, they could address the well-known Xft color emoji crash,
a real example affecting suckless software. Instead, they deliberately choose
otherwise, while presenting Wayland as the new standard, using strong language
to tell off and even openly insult, resorting to petty name-calling, people who
suggest this or who present evidence on why their decisions are wrong. They
didn't even merge independently developed libxft-bgra patch so far! (Yes, it
doesn't solve the entire problem yet, but that's what git is for.)

>it's open source and I cannot force anyone do work on X if they don't want to.

Neither should Wayland be presented as the "be all, end all" of GUI under
GNU/Linux, even moreso since it "isn't in a good state" (fully agree).  After
all those years, someone should begin to wonder if it's worth it at all. Maybe
the general direction should be reevaluated?

>We could absolutely have a full replacement for the X server based on wayland.
>The wayland people won't build it for us though. Neither will the gnome 
>people. 

To use an allegory: it is perfectly fine that they don't want to build our
bridges. But they shouldn't tear down the ones we have, no matter how worn out
or in need of repair they might be. The new ones have design flaws and aren't
even complete.

> You can decide for yourself whether you want to keep whining

Typical use of a strong language as a substitute for having real arguments.

Re: [dev] st crash(child exited with status 1)

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

On 21/09/28 01:24, Sergei wrote:
> 1. screen -dmS rtorrent_daemon rtorrent -n -o import=~/.rtorrent/rtorrent.rc
[...]
> 2. sudo -u user bash -c "st  -e screen -r rtorrent_daemon" or "st -e screen
> -r rtorrent_daemon

st -e screen -r rtorrent_daemon

Running this command, there are no issues here. Ensure that screen is
active in the background first by

ps aux | grep -i screen

before executing the second command.

P.S: Bloat - sudo, GNU Screen, Bash, Debian (a distribution of Systemd/Snap).


signature.asc
Description: PGP signature

Re: [dev] tcvt: very useful for seeing more at once

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

On 21/10/14 12:28, Greg Reagle wrote:
> Useful, but a lot of wasted screen space on my monitor:
> man dwm

If MANWIDTH is unset (default), man page will take all of the available width of
the terminal, unless:

- COLUMNS is also somehow unset (it is set by most sane shells by default), or
- ioctl(2) is somehow nonfunctional, or
- you are not using a tilling wm, or
- you are using a floating terminal, in which case switching it back to full
  screen should use up more of the screen space.

I have no idea what tcvt is or does. Since you haven't provided any details on
that program(?)/script(?), I can only guess.


signature.asc
Description: PGP signature

Re: [dev] tcvt: very useful for seeing more at once

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

On 21/10/15 07:03, Martin Tournoij wrote:
> Note that mandoc has a default of 78 if not set; GNU man (and maybe some
> others?) do indeed take up the full width by default, but mandoc won't take up
> more than 78.

I've mostly used GNU man, and from my briefly trying other versions of man I
didn't go into that much detail regarding whether they set MANWIDTH or not, so I
don't know.

In any case, navigating man pages using the default pager is easy enough.


signature.asc
Description: PGP signature

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

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

This is what a web page should be:

http://motherfuckingwebsite.com/

This is less minimal, more readable, but still not plagued by "frameworks" and
"web coding" (uggh!). This is as far as web should go, ideally:

http://bettermotherfuckingwebsite.com/

There is nothing to gain from "minifying" CSS, just lose on readability by a
human.


signature.asc
Description: PGP signature

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

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

On 21/10/26 04:48, Sagar Acharya wrote:
> That's a bit more primitive. It can go a bit more vibrant wrt fonts, colors,
> break points for mobile, tablet which would still be minimal in my view. I'm
> approaching such simplicity from the other complex end which most people
> prefer, unfortunately.

These are the web pages of some of the giants of computing:

https://www-cs-faculty.stanford.edu/~knuth/
https://www.w3.org/People/Berners-Lee/
https://www.bell-labs.com/usr/dmr/www/
http://www.wall.org/~larry/
https://www.cs.helsinki.fi/u/torvalds/
https://stallman.org/

Notice anything they have in common?

Modern web is a perversion of what it once was - a simple environment to
represent hypertext. Years of cruft and overengineering have lead to a bloated
mess we have today. Things like Gemini

https://gemini.circumlunar.space/

have risen recently precisely to address this problem.

Suckless movement is not about conformism, about "going with the flow" of what
"most people prefer". On the contrary, it is about shaking up the core values of
mainstream computing.

Take dmenu as an example. Its most well known use is to launch programs from the
script dmenu_run. Its counterpart in the traditional GUI would be eye candy
icons or shortcut buttons on some panel. When first confronted with such
concept, "most people" will find it "primitive" and even outlandish. However, if
some thought is given to understanding why it is made that way, one inevitably
starts to see the genius of the concept and why it is much better than clicking
an icon or a button with a mouse.

Surf is a necessary evil to be able to access the modern web. For new websites
however, anyone who finds value in the suckless principles should actively work
on reverting the web to a sane state it was in some 20+ years ago.

I suggest starting by making websites one creates viewable and readable in:

- NetSurf
- links


signature.asc
Description: PGP signature

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

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

On 21/10/26 05:22, Nick wrote:
> Quoth Страхиња Радић:
> > This is what a web page should be:
> > 
> > http://motherfuckingwebsite.com/
> 
> When I load that in tor browser with js disabled (my default setup 
> these days), I get a 20741 byte page with the title "Captcha" and no 
> content except an eternally rotating image.
> 
> The web is beyond saving.

Yeah, it seems it sadly includes Gogole Analytics JS at the end after all:

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

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

On 21/10/26 08:32, Sagar Acharya wrote:
> People like what they feel. Majority of people out there aren't coders.
> Majority of coders just code to earn and would gladly just accept what their
> company pushes to them. These people just like convenience. As much as we'd
> like them to accept a bit of pain for minimalist and simple code, I don't
> think they'd go beyond a certain point.
[...]
> Somethings work different to the way we want them to work. And the sad reality
> is, majority people are never gonna accept simplicity as a trade off for
> convenience. I think keeping convenience the same while making things simple
> is the way forward. I love suckless but this is where I differ a bit.

I believe we already had a similar conversation back in August and April. Here's
my reply from August:

==

On 21/08/07 02:54, Sagar Acharya wrote:
> This is where I diverge from suckless, suckless goes for hardcore minimalistic
> software at cost of user experience. 

Wrong. I'd argue that the "user experience" in most programs that suck is worse
than the "user experience" using suckless programs. That's one of the reasons we
call them like that - "programs that suck" and "suckless programs".

I believe we already discussed this about four months back.


>Addicted to almost all software out
> there like WhatsApp, Facebook, and many more things, most are never gonna use
> stuff like dwm. And things like Windows would keep them there. I myself
> use dwm, hyperbola OS, but suggesting it to common people wouldn't be
> wise. They'll switch back to Windows, and this time maybe forever.

And?

This sense of urgency and worry about the size of the userbase seems to be tied
to "software development" inside (big tech) corporations. They add (or remove)
features to software guided by statistical analysis of the target audience with
the aim of supporting what is perceived to generate the most profit, not by the
program's purpose or any other reason. Suckless movement is not a corporation.
It is a gathering of programmers writing software for themselves and others who
value the principles of simplicity and quality in software.

If anyone wants to use other software, by all means they should. There's nothing
wrong with that, but on the other side, that shouldn't influence suckless
programs.


signature.asc
Description: PGP signature

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

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

n 21/10/26 07:51, Ian Liu Rodrigues wrote:
> echo -e '\e[31m \e[0m c'
> echo -e '\e[31m  \e[0mc'
>
>
> Here is a screenshot of the script's output: https://qu.ax/3SBs.png

For me, this patch fixed the glyph truncation:

https://github.com/LukeSmithxyz/st/pull/224

Perhaps someone could add this to the official patches?


signature.asc
Description: PGP signature

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

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

On 21/10/29 12:18, Dmytro Kolomoiets wrote:
> Страхиња Радић, do you have a cleaned up version of the patch
> which applies to latest st tree without rejecting hunks?

No, but it shouldn't be too hard to make given the PR. I have applied it to my
fork of st (https://git.sr.ht/~strahinja/st).


signature.asc
Description: PGP signature

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

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

On 21/11/09 02:00, Laslo Hunhold wrote:
> I'm always wondering: What do you suggest to improve the
> latency-situation? Can we even be "better" than the screen's framerate?

I'm wondering what's the use case for such critical need for low latency?
Playing DOOM (2016) in a terminal with aalib? That's not what terminal emulators
were meant for.


signature.asc
Description: PGP signature

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

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

On 21/11/10 08:55, NRK wrote:
> I wouldn't say it's "critical need". And if we judge from that pov then
> one could ask, "What's the critical need for a dynamic window manger or
> minimal softwares in general?".

Terminal emulator's job is to allow terminal input/output. Latency is simply not
relevant, unless it is noticeable by a human (for example, if a simple "cat
/some/file" for a multi-line text file has a delay anywhere from 500 ms to a
second or two between the output of individual lines, when not dependant on
factors such as reading from a network of a faulty hard disk; that would just be
annoying, but still usable). st doesn't have such issues, so anyone experiencing
them should look for the cause elsewhere (Xft/fontconfig?).

Also, the need for "minimal software" is not comparable to the "need" for "low
latency" in a terminal emulator. The former is a fundamental concept, while the
latter is superficial.

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

If you refer to color emoji or Nerd Font symbols, they are poorly supported in
X, and I'd even say they are bloat by themselves. But it is to be expected of
XTerm to have problems. To quote https://st.suckless.org,
> xterm is bloated and unmaintainable. Here's an excerpt from the README:
> 
> Abandon All Hope, Ye Who Enter Here
> 
> This is undoubtedly the most ugly program in the distribution. It was one
> of the first "serious" programs ported, and still has a lot of historical
> baggage.  Ideally, there would be a general tty widget and then vt102 and
> tek4014 subwidgets so that they could be used in other programs. We are
> trying to clean things up as we go, but there is still a lot of work to
> do.
> 
> Needless to say things have not changed, it's still ugly. It has over 65K
> lines of code and emulates obscure and obsolete terminals you will never need.
> 
> The popular alternative, rxvt has only 32K lines of code. This is just too
> much for something as simple as a terminal emulator; it's yet another example
> of code complexity.
> 
> Terminal emulation doesn't need to be so complex.


signature.asc
Description: PGP signature

Re: [dev] [surf] XDG conformity

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

On 21/12/16 09:39, Janek F wrote:
> After trying surf recently, I was appalled to see a ".surf" directory in my 
> home.
> Is XDG basedir compliance not natural in suckless software?

Suckless software follows the principles that predate X Desktop Group and its
specifications, as well as its own principles.

Before 2000, it was customary in GNU/Linux to have user-specific configuration
files in the user's home directory, starting with a dot. For example, vim's
configuration file is ~/.vimrc, joe's configuration file is ~/.joerc and so on.
Those files are commonly called "dotfiles", because they literally start with a
dot, and programs like ls omit listing them by default (they are "hidden").

In addition, suckless software has its own convention, which is to configure
software by changing a header file in its source code, usually located in the
file config.h in the source directory of a particular program.


signature.asc
Description: PGP signature

Re: [dev] [surf] segmentation fault

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

On 22/01/12 04:02, m...@datameer.com wrote:
> Does that mean I have to compile surf incl all dependencies with
> https://github.com/void-linux/void-packages?

Compiling from source is the intended way to use suckless software.

Suckless software is configured by editing config.h, rather than by using
configuration files.


signature.asc
Description: PGP signature

Re: [dev] [surf] segmentation fault

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

On 22/01/13 11:52, m...@datameer.com wrote:
> Regarding the note on the website `Compile your own webkit or expect
> hell`...
> Is it better or more stable to compile webkit as well?

Why don't you just try it and find out?

If you are asking me about my personal experience, I always compile surf from
source. I maintain my own personal fork with my choice of patches and
customizations at [1]. I never had any problems yet on Artix with compiling and
using surf with Artix's precompiled webkit.

When using binary packages, you are at the mercy of however the maintainers of
your distro decided to compile it. When you compile software from source, you
have (more) control over how the software is compiled. If the binary version of
wekbit doesn't work, the only other thing you can try is compile it from source.
If that fails too, raise the issue with the maintainers of your distro.

[1]: https://git.sr.ht/~strahinja/surf


signature.asc
Description: PGP signature

Re: [dev] requirements of build systems

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

On 22/01/31 12:10, Petros Pateros wrote:
> What would you expect from a build system? Should it trust mtime?
> Is it responsible for verifing the file's contents for actual changes?
> More generally, what are the key features that make a build system useful?

apenwarr/redo is the implementation of djb redo I settled on for my programs. It
has the most features among the current implementations. For redistribution, it
has a shell script named "do", so even if users don't have full apenwarr/redo
installed on their system, they can execute

$ ./do -c

to build my programs, or

# ./do -c install

to install them.


signature.asc
Description: PGP signature

Re: [dev] requirements of build systems

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

On 22/02/05 03:23, Petros Pateros wrote:
> On Mon, Jan 31, 2022 at 06:38:01PM +0100, Страхиња Радић wrote:
> > apenwarr/redo is the implementation of djb redo I settled on for my 
> > programs. It
> > has the most features among the current implementations.
> 
> I'm glad to hear that. But it doesn't implement the less-features feature 
> (that comes
> along with the only-the-features-necessary-for-the-do-one-job-well-plan) that 
> I
> was looking for ;-).

I'm not talking about the unnecessary cruft here, just the most features within
the djb's redo specification.


signature.asc
Description: PGP signature

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

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

On 22/02/11 11:47, Daniel Littlewood wrote:
> It seems to me like the obvious alternative workflow would be, rather
> than to have a single monolithic program for the general job of
> "editing text" (which is really lots of jobs pretending to be one),
> one might have a program for syntax highlighting, a program for
> completion, a facility for dispatching text to shell commands, and so
> on. On the more extreme end one could even imagine separating the jobs
> of navigating through a buffer (i.e. a pager) from the editing of
> text. Obviously that's not a complete idea by itself, or I wouldn't be
> asking for suggestions.

The question of "Unix philosophy" is more nuanced than that, it should be
applied in an sensible manner. It just isn't practical to bring the scope which
the "thing" that "programs do well" belongs to, down to such a fundamental level
as navigating through a buffer. Those buffers are better manipulated as internal
structures inside a single program, rather than some (textual) representation in
an input/output stream.

What should and can be avoided though, are for example plugins. A text editor
doesn't need plugins, it should be sufficient for its purpose. Customization
could be instead implemented through patches, as in other suckless programs.

A text editor should do "its thing" well, nothing more, nothing less. "Its
thing" should be editing of text files.


signature.asc
Description: PGP signature

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

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

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.


signature.asc
Description: PGP signature

Re: [dev] Some direction with my project

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

On 22/04/15 02:20, Wolf wrote:> 
> Configure script provides lot more then detection though. I have yet to
> see a hand written make providing support for --program-prefix or
> --program-transform-name for example. For packaging software, these
> additional features are useful from time to time.

They are trivial to program in a handwritten makefile.

On topic, suckless programs usually make use of makefiles which are 
hand-customized, just like the program settings (config.h). For bonus points, 
use Plan9 mk.

For my own programs, I prefer djb redo[2], which uses simple shell scripts and 
is better than GNU make[3].

About the Changelog/NEWS, they originate before the time of git and are 
superseded by git log/git shortlog.


1: https://9p.io/sys/doc/mk.html
2: https://github.com/apenwarr/redo
3: https://redo.readthedocs.io/en/latest/#whats-so-special-about-redo


signature.asc
Description: PGP signature

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

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

On 22/04/19 07:09, Robert Winkler wrote:
> 
> 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.

With

export LC_ALL=en_US.UTF-8

properly configured fonts in fontconfig[1][2][3] and properly configured 
config.h, Unicode characters, and even emoji, work in st. See the documentation 
for fontconfig for information on how to properly configure fonts in X.Org.

st works here perfectly with Unicode characters and color emoji.


[1]: https://www.freedesktop.org/wiki/Software/fontconfig/
[2]: https://freedesktop.org/software/fontconfig/fontconfig-user.html
[3]: https://wiki.archlinux.org/title/Font_configuration


signature.asc
Description: PGP signature

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

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

On 22/04/24 02:53, Robert Winkler wrote:
> Hi, thanks for all the hints I got from the [st] [dev]!
> Anyway, I still cannot sort it out; hopefully the following information
> helps that someone can spot the problem:
> As I mentioned, the UTF-8 symbols work in other terminals such as
> lxterminal.

How have you set up your input method? Try using setxkbmap(1) to set X input 
method. Also make sure that st's terminfo entries are installed
(make && sudo make install from st repository) and you have

export TERM=st-256color


signature.asc
Description: PGP signature

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

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

On 22/04/26 08:20, Robert Winkler wrote:
> Anyone has an idea, what could be the difference between Gnome and DWM
> with respect to the font encoding?

I'm using dwm in X.Org using no display manager (autostart X at login [1]) in 
Artix Linux and everything works correctly. Setting environment variables 
correctly greatly depends on your startup "stack", ie. if you are using display 
manager such as lightdm, sddm... or just logging in through getty (like myself) 
and autostarting X at login, and also on your login shell. You should study the 
documentation of every piece of that "stack" thoroughly to determine how 
exactly to set up your system.

Like I mentioned in my previous message, input also depends on how you set it 
up in X. I'm configuring XKB[2] through the use of setxkbmap(1) by dwm on 
startup (I use "cool autostart"[3] patch for dwm to do that, though I could 
have also chosen to do it in $HOME/.xinitrc - again, I don't use a DM).


[1]: https://wiki.archlinux.org/title/Xinit#Autostart_X_at_login
[2]: https://wiki.archlinux.org/title/X_keyboard_extension
[3]: https://dwm.suckless.org/patches/cool_autostart/


signature.asc
Description: PGP signature

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

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

On 22/04/26 05:39, Hadrien Lacour wrote:
> 
> Compare the output of env in the two situations. Something I noticed in one of
> your mails: you have en_US.UTF-8 in your locale output while here, on Gentoo, 
> I
> have en_US.utf8.

https://wiki.gentoo.org/wiki/Localization/Guide
> The command above lists the suffix in lower case without any hyphens, 
> glibc understands both forms of the suffix, many other programs don't. The
> most common example of which is X. So it is best to always use UTF-8 in
> preference to utf8.


signature.asc
Description: PGP signature

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

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

On 22/04/26 03:59, Robert Winkler wrote:
> To make a long story short: The input of UTF-8 characters with st needs
> an IBus daemon 

No, it doesn't.


signature.asc
Description: PGP signature

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

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

On 22/04/28 09:29, Hiltjo Posthuma wrote:
> Recently dark mode CSS support was added to the site.
> 
> It was reported on IRC the logo's were not visible with them.

This can be remedied with CSS which applies white background to logos (perhaps 
with some padding:  to also give a bit of a border).

In my opinion, dark mode is unnecessary and favored by mainstream "webdevs".


signature.asc
Description: PGP signature

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

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

On 22/04/28 12:19, Laslo Hunhold wrote:
> What do the others think?

I also like them, I think they contribute to overall visual identity of 
suckless programs and suckless.org and should be reincorporated into the 
website.


signature.asc
Description: PGP signature

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

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

On 22/04/15 07:08, Robert Winkler wrote:
> 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?
> Best, Robert

Liks I said, I only use:

- login through getty (no display manager like lightdm, sddm, gdm...)
- no desktop environment, pure X.Org
- dwm as a window manager
- X.Org's native XKB configured with:
setxkbmap -layout us,rs -option grp:alt_shift_toggle
  which is executed by dwm on startup

and I can input various characters in Cyrillic, as well as color emoji and
other symbols using my own script[1].

May I ask what shell are you using inside st? The only problem I noticed so far 
with my script, which uses xdotool(1) to type characters, is when I am using it 
while st is specifically executing mksh as a shell. With bash, dash and zsh 
emoji are inserted correctly. This is undoubtedly some misconfiguration of mksh 
on my part, which I have yet to figure out in detail.

However, when I type ordinary text, regardless if it is using Cyrillic 
characters, using Serbian keyboard, or those characters you listed in your 
original message, using Spanish keyboard, they are entered and displayed 
correctly, even in mksh. I have captured a screenshot[2] as a proof of concept. 

In the first line in the screenshot, I have typed a command to configure XKB:

setxkbmap -layout us,es -option grp:alt_shift_toggle

In the second line, I have typed characters after switching to Spanish layout 
by pressing left Alt+Shift.

In the third line, I have typed the characters I used to get characters in the 
previous line, after switching back to US layout.

The other screenshot[3] demonstrates pasting a text containing color emoji from 
a web page into Bash running under st. I do have libxft-bgra patch for Xft 
installed through an AUR package to show color emoji.


[1]: https://git.sr.ht/~strahinja/dwm/tree/master/item/pickchar
[2]: https://i.imgur.com/yWd2nPd.png
[3]: https://i.imgur.com/7yTYHUY.png
[4]: https://aur.archlinux.org/libxft-bgra.git


signature.asc
Description: PGP signature

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

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

On 22/04/28 06:48, Страхиња Радић wrote:
> May I ask what shell are you using inside st? The only problem I noticed so 
> far 
> with my script, which uses xdotool(1) to type characters, is when I am using 
> it 
> while st is specifically executing mksh as a shell. With bash, dash and zsh 
> emoji are inserted correctly. This is undoubtedly some misconfiguration of 
> mksh 
> on my part, which I have yet to figure out in detail.

After some investigation, I discovered the following paragraph in mksh FAQ[1]:

> The shell’s utf8-mode before mksh R60 supported only the BMP (Basic 
> Multilingual Plane) of UCS and mapped raw (extended ASCII) octets, i.e. these 
> which are not valid UTF-8 BMP codepoints) into the U+EF80‥U+EFFF range, which 
> is allocated at the CSUR for this purpose. (It otherwise lies in the PUA; 
> however, there is ambiguity if encountering those UTF-8-encoded, so it 
> changed 
> for R60.) The Arithmetic expressions and CAVEATS sections in mksh(1) contain 
> more details about encoding and mapping.
>
> As of R60, utf8-mode maps “raw octets” to U-1080‥U-10FF, which is 
> outside the UCS and therefore collision-free. There’s work underway to make 
> the 
> shell support the full 21-bit UCS range for R60.

Since I'm currently using mksh R59, that part of the mystery is solved as well.

**Definitive conclusion: st does not need GNOME, ibus or other bloat (aside 
from 
good old native X.Org bloat itself) to support UTF-8 input/output.**


[1]: http://www.mirbsd.org/mksh-faq.htm#posix-mode


signature.asc
Description: PGP signature

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

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

On 22/04/28 01:44, Robert Winkler wrote:
> 
> usually, I am using the fish 

https://www.youtube.com/watch?v=8AQobpqySAU


signature.asc
Description: PGP signature

Re: [dev][surf] Compatibility: "empty" wep pages

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

On 22/04/29 09:48, Robert Winkler wrote:
> Hi, surf is up to now the best browser I found for weak machines such as the 
> Raspberry Pi 0W, with respect to compatibility and customisability (link
> hints, full keyboard control).
> 
> The support of Javascript pages is fair.
> 
> However, some Web Pages do not work at all.
> 
> Example: 
> just produces a white page.

This is how that page (containing Google Analytics and Google Tag Manager) 
looks in surf here:

https://i.imgur.com/lgKot4U.png

While Web itself sucks[1], and surf is a compromise between a suckless shell 
and an engine that sucks (Webkit) for a medium that sucks (HTML+CSS+JS), I find 
that it is unfortunately not satisfactory yet from a privacy-respecting 
standpoint, at least until it supports plugins such as uMatrix which block Ads 
and various other privacy-intruding technologies. Simple filtering of URLs 
just isn't enough.

Until such a moment, I'm using ungoogled-chromium[2] for everyday use.

[1]: https://suckless.org/sucks/web/
[2]: https://github.com/Eloston/ungoogled-chromium


signature.asc
Description: PGP signature

Re: [dev] [dwm] Xorg crashed if I ran Pale Moon in dwm

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

On 22/06/22 01:04, p...@mailbox.org wrote:
> > the discussion https://forum.palemoon.org/viewtopic.php?f=3&t=28505

[   140.237] Failed to compile FS: 0:1(10): error: GLSL 1.30 is not supported. 
Supported versions are: 1.10, 1.20, and 1.00 ES

^ This is most probably caused by mismatched/misconfigured video drivers and/or
misconfigured X.Org (try asking on the forums of your distro instead).

dwm is very simple and doesn't use fancy GL APIs, unlike bloated web browsers
like Palemoon, so this has nothing to do with it.


signature.asc
Description: PGP signature

Re: [dev] suckless indentation with vim

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

On 22/07/02 11:07, NRK wrote:
> If someone's using vim and follows this style, what plugin and/or
> setting do you use?

set tabstop=8
set softtabstop=0
set shiftwidth=0
set noexpandtab

Not being lazy to type text, and indenting each line manually.

Side note: vim is bloated compared to vi and vis.


signature.asc
Description: PGP signature

Re: [dev] Replace ranlib(1) calls?

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

On 22/07/23 11:06, Tom Schwindl wrote:
> Again, you'd have to rely on a tool which isn't defined.
> If a system says it's POSIX compliant, we can assume that the `-s' option
> exists, but there is no standard which tells us whether ranlib(1) is available
> or not.

Standards are not the Holy Grail.

https://harmful.cat-v.org/standards/ 


signature.asc
Description: PGP signature

[dev] tar filename handling

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

I was using suckless tar to create an archive of a Python package, and hit a 
limit. When checking out the code, I noticed that the name of the file is 100 
characters long, however there is also the prefix field which is 155 characters 
long, and the actual path should be combined from prefix (if present) + name.

https://git.suckless.org/sbase/file/tar.c.html#l36

The path that failed was

./sucks/lib/python3.9/site-packages/docutils/parsers/__pycache__/commonmark_wrapper.cpython-39.opt-1.pyc

which is 104 characters long. On further inspection, it seems that the prefix 
field is taken into account with -x and -t ("small dance..."):

https://git.suckless.org/sbase/file/tar.c.html#l460

but not with -c:

https://git.suckless.org/sbase/file/tar.c.html#l204

I just wanted to know if this is planned for a future update. If not, I'd like 
to try to implement long (>100) path splitting for -c.


signature.asc
Description: PGP signature

Re: [dev] tar filename handling

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

I have made the necessary change, you can review my patch here:

https://git.sr.ht/~strahinja/sbase/tree/master/item/patches/0001-Split-path-into-prefix-name-on-c.patch

I also attached it to this message.
From d91f1b0315ca3a0d584f8ac7c2e8ef16cc7493c4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A1=D1=82=D1=80=D0=B0=D1=85=D0=B8=D1=9A=D0=B0=20=D0=A0?=
 =?UTF-8?q?=D0=B0=D0=B4=D0=B8=D1=9B?= 
Date: Mon, 1 Aug 2022 09:12:03 +0200
Subject: [PATCH] Split path into prefix + name on -c
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Страхиња Радић 
---
 tar.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/tar.c b/tar.c
index d3a9f3b..4c35102 100644
--- a/tar.c
+++ b/tar.c
@@ -180,6 +180,7 @@ static int
 archive(const char *path)
 {
 	char b[BLKSIZ];
+	char *split;
 	struct group *gr;
 	struct header *h;
 	struct passwd *pw;
@@ -187,6 +188,7 @@ archive(const char *path)
 	size_t chksum, i;
 	ssize_t l, r;
 	int fd = -1;
+	int slen, plen;
 
 	if (lstat(path, &st) < 0) {
 		weprintf("lstat %s:", path);
@@ -201,7 +203,19 @@ archive(const char *path)
 
 	h = (struct header *)b;
 	memset(b, 0, sizeof(b));
-	estrlcpy(h->name,path,sizeof(h->name));
+	if ((split = strrchr(path, '/')) > path)
+	{
+		plen = strlen(path);
+		slen = (int)(split - path);
+		if (snprintf(h->prefix, sizeof(h->prefix), "%.*s",
+			slen, path) >= sizeof(h->prefix))
+			eprintf("snprintf: input string too long\n");
+		if (snprintf(h->name, sizeof(h->name), "%.*s",
+			(int)(plen-slen-1), path+slen+1) >= sizeof(h->name))
+			eprintf("snprintf: input string too long\n");
+	}
+	else
+		estrlcpy(h->name, path,   sizeof(h->name));
 	putoctal(h->mode,(unsigned)st.st_mode & 0777, sizeof(h->mode));
 	putoctal(h->uid, (unsigned)st.st_uid, sizeof(h->uid));
 	putoctal(h->gid, (unsigned)st.st_gid, sizeof(h->gid));
-- 
2.37.1



signature.asc
Description: PGP signature

[dev] tar -n (equivalent of --no-recursion)

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

I have made another patch for tar, this is more "quality of life" oriented. It 
adds the option -n to tar, which is equivalent to GNU tar's --no-recursion. 
This comes in handy when tar is used together with find(1) to filter and 
hand-pick the list of files to be archived.

The patch is here:

https://git.sr.ht/~strahinja/sbase/tree/master/item/patches/0001-Add-n-equivalent-of-no-recursion.patch

and I have also attached it to this message for review.
From 3c58d0ce54200f001309da369a54cb58a4e7ddf7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A1=D1=82=D1=80=D0=B0=D1=85=D0=B8=D1=9A=D0=B0=20=D0=A0?=
 =?UTF-8?q?=D0=B0=D0=B4=D0=B8=D1=9B?= 
Date: Mon, 1 Aug 2022 09:21:08 +0200
Subject: [PATCH] Add -n (equivalent of --no-recursion)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Страхиња Радић 
---
 tar.1 |  5 +
 tar.c | 16 
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/tar.1 b/tar.1
index be2ebea..f7d27a0 100644
--- a/tar.1
+++ b/tar.1
@@ -15,6 +15,7 @@
 .Op Fl C Ar dir
 .Op Fl J | Fl Z | Fl a | Fl j | Fl z
 .Op Fl h
+.Op Fl n
 .Fl c Ar path ...
 .Op Fl f Ar file
 .Sh DESCRIPTION
@@ -36,6 +37,10 @@ as input | output archive instead of stdin | stdout.
 If '-', stdin | stdout is used.
 .It Fl m
 Do not preserve modification time.
+.It Fl n
+Do not recurse into directories. This flag is an extension to standard,
+equivalent to GNU tar's
+.Fl -no-recursion .
 .It Fl t
 List all files in the archive.
 .It Fl x
diff --git a/tar.c b/tar.c
index d3a9f3b..3f8daf9 100644
--- a/tar.c
+++ b/tar.c
@@ -63,7 +63,7 @@ static int tarfd;
 static ino_t tarinode;
 static dev_t tardev;
 
-static int mflag, vflag;
+static int mflag, nflag, vflag;
 static int filtermode;
 static const char *filtertool;
 
@@ -374,7 +374,7 @@ c(int dirfd, const char *name, struct stat *st, void *data, struct recursor *r)
 	if (vflag)
 		puts(r->path);
 
-	if (S_ISDIR(st->st_mode))
+	if (S_ISDIR(st->st_mode) && !nflag)
 		recurse(dirfd, name, NULL, r);
 }
 
@@ -507,7 +507,7 @@ usage(void)
 {
 	eprintf("usage: %s [-C dir] [-J | -Z | -a | -j | -z] -x [-m | -t] "
 	"[-f file] [file ...]\n"
-	"   %s [-C dir] [-J | -Z | -a | -j | -z] [-h] -c path ... "
+	"   %s [-C dir] [-J | -Z | -a | -j | -z] [-h] [-n] -c path ... "
 	"[-f file]\n", argv0, argv0);
 }
 
@@ -534,6 +534,9 @@ main(int argc, char *argv[])
 	case 'm':
 		mflag = 1;
 		break;
+	case 'n':
+		nflag = 1;
+		break;
 	case 'J':
 	case 'Z':
 	case 'a':
@@ -577,7 +580,12 @@ main(int argc, char *argv[])
 		if (chdir(dir) < 0)
 			eprintf("chdir %s:", dir);
 		for (; *argv; argc--, argv++)
-			recurse(AT_FDCWD, *argv, NULL, &r);
+		{
+			if (!nflag)
+recurse(AT_FDCWD, *argv, NULL, &r);
+			else
+archive(*argv);
+		}
 		break;
 	case 't':
 	case 'x':
-- 
2.37.1



signature.asc
Description: PGP signature

Re: [dev] tar filename handling

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

On 22/08/01 09:30, Quentin Rameau wrote:
> Andrew has posted a patch (on hackers@ on may first) for this
> that nobody had time to review yet. :/
> I suggest you try it, that should fix your issue.

Ah, I'm not subscribed on that list (yet?). Anyway, I tested my patch on my use 
case and it behaves correctly so far, so I leave you guys to decide whether to 
review/include it or not.

In the meantime, I have posted another patch, which adds a -n option 
(equivalent of --no-recursion) for your consideration.


signature.asc
Description: PGP signature

[dev] Broken link in /faq/

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

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


signature.asc
Description: PGP signature

Re: [dev] Commandline Email Advice Request

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

On 22/11/25 09:43, Teodoro Santoni wrote:
> Gmail doesn't allow to use SMTP in a classic way (normal auth
> with/without encryption). You may need to ask your sysadmins for
> XOAUTH2 keys and try to pass that git send-email through an SMTP thing
> like msmtp.
> A faster solution would be to make the patches with git format-patch
> and then send a manually created email with the patches attached.

I use Google's "App password" to authenticate, with "Allow insecure login" 
setting in Gmail to use msmtp with it.


signature.asc
Description: PGP signature

Re: [dev] st: no need for scrollback patch or program by using -o option

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

On 23/01/14 09:25, Markus Wichmann wrote:
> On Fri, Jan 13, 2023 at 07:53:41PM -0600, Dave Blanchard wrote:
> > I experimented with st for a week or so, before finally realizing that
> > it's poorly-written trash. It has no advantages over XTerm at all.
> >
> 
> So where's the patch?
> 
> Given that a terminal emulator is a necessary part of the Trusted
> Computing Base if the system has X11, I'd prefer it to be as simple as
> possible, so that it is not exploitable. st is simple enough to be able
> to roughly gauge whether it has memory bugs or not. XTerm is such
> overwritten tripe I cannot gauge that at all.
> 
> Ciao,
> Markus

Obvious trolling should receive no response. This kind of noise belongs to 
Reddit and similar communities, where it is commonplace.

Most of what's to be said in "defense" of st and other suckless software is 
already out there on suckless.org, including the sorry state of XTerm being the 
driving idea behind writing st, which the OP turned upside-down, so that's one 
more reason against responding, and enough to see it's trolling.


signature.asc
Description: PGP signature

Re: [dev] st: no need for scrollback patch or program by using -o option

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

On 23/01/16 12:33, Страхиња Радић wrote:
> Most of what's to be said in "defense" of st and other suckless software is 
> already out there on suckless.org, including the sorry state of XTerm being 
> the 
> driving idea behind writing st, which the OP turned upside-down, so that's 
> one 
> more reason against responding, and enough to see it's trolling.

s/OP/person Markus responded to/


signature.asc
Description: PGP signature

Re: [dev] [st] Font problem

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

On 23/02/10 03:19PM, Vincent Lefevre wrote:
> Actually that's more Cairo vs Xft. Pango may use either:

Right. In any case, the most likely place the OP should check is fontconfig 
configuration and fc-* programs for debugging (fc-match, fc-list and so on).


signature.asc
Description: PGP signature

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

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

On 23/02/25 12:59PM, fo...@dnmx.org wrote:
> Tried -s 128 -t 8, doesn't seem to do jack shit..
> Got less than 10 connection logs from Quark and then another dropped one..
> Is there any other reason Quark would print-out 'dropped', other than
> connection pool at max?
> 
> I restarted the jail, so Quark's memory and stuff should have been reset.

Reread Laslo's message and look at the source code as he suggested in the 
mentioned message.


signature.asc
Description: PGP signature

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

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

On 23/04/08 07:24PM, p...@mailbox.org wrote:
> static const char *dmenu_extend[] = { "dmenu_extended_run", NULL };

How about:

> > (Try changing your
> > dmenu_extended keybind to something else and see if that works or not).

1. What happens if you use:

static const char *dmenu_extend[] = { "dmenu_run", NULL };

2. What happens when you run from the terminal emulator:

2.a:
$ dmenu_extended_run

2.b:
$ which dmenu_extended_run

3. What happens if you add the path obtained from 2.b to the command

> static const char *dmenu_extend[] = { "dmenu_extended_run", NULL };
 ^-- here, before 'd'?



signature.asc
Description: PGP signature

Re: [dev] Using ii to connect to libera

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

On 23/04/20 06:00, Sagar Acharya wrote:
> I expected it to be interactive out of the box. A chat client, I cannot 
> imagine anything except interactive abilities.

Consider this a learning opportunity then: it is better to read documentation 
and/or a website[1] of some program, than create assumptions which might not be 
based in reality.

From the website[1]:

> ii is a minimalist FIFO and filesystem-based IRC client.
[...]
> Join a channel as follows: $ echo "/j #wmii" > in and ii creates a new #wmii  
> (channel) directory with in and out files.

And so on...

[1]: https://tools.suckless.org/ii/


signature.asc
Description: PGP signature

Re: [dev] [license] gpl issues

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

On 23/05/05 08:07AM, Laslo Hunhold wrote:
> I try to take a balanced stance in the GPL vs. MIT discussion, given it
> usually derails into tribalist diatribes on both sides.

Essays have been written and are available online explaining everything about 
GPL and related licenses, so there's no need for anyone to reiterate what is 
already there (examples: [1], [2], [3], [4] and so on). Anyone interested can 
read them and form their own opinion. Personally, I believe that GNU GPLv3+ is 
superior and use it for programs I write from scratch. 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.

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.


[1]: https://www.gnu.org/licenses/license-list.html
[2]: https://www.gnu.org/philosophy/philosophy.html
[3]: https://www.gnu.org/licenses/why-not-lgpl.html
[4]: https://www.gnu.org/licenses/rms-why-gplv3.html


signature.asc
Description: PGP signature

Re: [dev] [license] gpl issues

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

On 23/05/06 09:55PM, Laslo Hunhold wrote:
> [0]:https://unixsheikh.com/articles/the-problems-with-the-gpl.html

Dear Laslo,

Thank you for reminding me of Unixsheikh's article on his view of GPL and other 
licenses. I read it a while ago, but the arguments presented in it leave me 
unconvinced. I don't think the two matters, of picking a license and ensuring 
that programs remain simple and to the point in the technical sense, are or 
have to be connected. I simply linked some of the articles on gnu.org which I 
think are relevant and complement the articles linked before my reply by 
presenting the views of the "other side", which are behind GPL-related 
licenses.

As I stated before, I don't see the practical point of this "debate" with 
regards to (most of) existing suckless software - the Expat ("MIT") license 
can't (_legally_; of course _realistically_ anything goes, even "software 
'piracy'" is a reality but illegal) be changed, even if it is "permissive". It 
is GPL-compatible, Expat-licensed works can be combined with GPL-licensed 
works. So what's the point in that case?

The only viable "debate" could be about what license to pick for future 
programs written from scratch, but that wasn't what OP asked.

Sincerely,
Strahinya


signature.asc
Description: PGP signature

Re: [dev] Simpler WiFi alternatives

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

On 23/05/11 04:03PM, fo...@dnmx.org wrote:


This list needs moderation ASAP, otherwise it risks turning into another 
Reddit (which, for those who might not know, is a veritable cesspool).


signature.asc
Description: PGP signature

Re: [dev] organizing programs

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

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


signature.asc
Description: PGP signature

Re: [dev] running a shortlink provider

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

On 23/05/25 07:02AM, Marcel Plch wrote:
> 2) Pick favorite Web stack
[...]
> I personally would go for Python/Django, I'm not sure how suckless that's
> considered (probably not at all)
[...]
> Web is in a sad state so

You answered your own question. Web is bloat, in particular HTML itself as 
something derived from SGML.

Suckless way to have a URL shortener public service would probably be to create 
a CGI script in rc/shell or a program in C.

Perhaps the most minimal solution for keeping data would be TSV files, but they 
are not suitable for storing data entered from the web because of concurrency, 
so a "real" database would be needed.



signature.asc
Description: PGP signature

Re: [dev] running a shortlink provider

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

On 23/05/25 10:29AM, Anthony wrote:
> What do you mean by, "because of concurrency"?

At any given moment, several HTTP clients can request posting data at the same 
time. They can hang indefinitely in the middle of sending data. If the process 
involves writing to a file, this can lead to data corruption or data loss. Even 
with a file lock, other such requests can be delayed or even denied. That's why 
a more sophisticated approach, possibly with caching, transactions and other 
methods which are present in database systems, is needed.


signature.asc
Description: PGP signature

Re: [dev] running a shortlink provider

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

On 23/05/25 07:19PM, Spenser Truex wrote:
> I don't support this database heavy database stuff. A key-value pair
> dataset would be enough. It's basically a perl one-liner. 

See (just a quick example): https://stackoverflow.com/a/43050919/184064

This is still not an ideal solution, but it illustrates some of issues which 
can arise. Having a website in PHP around 2001 has taught me that writing to a 
file in a HTTP environment filled with crawlers, bots, people holding F5 and 
slow clients, is vastly different than writing to a file on a single-user 
system.


> If you have a markup language for your database it's bloat.

I mentioned a database system, not a markup language.


> Why use a hammer when you can beat the nail with your hand?

Indeed, one just doesn't do the latter.



signature.asc
Description: PGP signature

Re: [dev] [quark] a monty-pythonesque journey with SYSTEMd

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

On 23/05/29 11:37PM, Spenser Truex wrote:
> systemd

Just don't use it, it sucks. Use anything else for PID 1 and process 
supervision.

https://suckless.org/sucks/systemd/


signature.asc
Description: PGP signature

Re: [dev] [license] gpl issues

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

On 23/06/18 04:58PM, Miles Rout wrote:
> 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?

You can't license the whole of A as GPL, only your modifications. Expat license 
requires that:

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

which explicitely forbids removing the copyright and permission notices on 
Expat-licensed code, or replacing them with, say, GPL notices.

Like I said, Expat license is GPL-compatible[1]. That means[2]:
> It means that the other license and the GNU GPL are compatible; you can 
> combine 
> code released under the other license with code released under the GNU GPL in 
> one larger program.
>
> All GNU GPL versions permit such combinations privately; they also permit 
> distribution of such combinations provided the combination is released under 
> the same GNU GPL version. The other license is compatible with the GPL if it 
> permits this too.
>
> GPLv3 is compatible with more licenses than GPLv2: it allows you to make 
> combinations with code that has specific kinds of additional requirements 
> that 
> are not in GPLv3 itself. Section 7 has more information about this, including 
> the list of additional requirements that are permitted.

However, it *doesn't* mean that I can just take someone's program A licensed 
under Expat and relicense the parts of my fork B (realistically, perhaps 95% of 
program A) under GPL. More precisely, that is not legally possible, as I stated 
before.


[1]: https://www.gnu.org/licenses/license-list.html#Expat
[2]: https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean


signature.asc
Description: PGP signature

Re: [dev] [license] gpl issues

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

On 23/06/20 08:41, Miles Rout wrote:
> It requires the notice is included (so people know that that code is 
> available elsewhere under that licence), not that the notice is included _as 
> your licence for the overall work_.

As someone else said, "words do matter". Copyright notice is not "just words", 
it is important and carries legal weight. Expat license requires that the 
copyright and permission notices are left intact in (and thus apply to) "all 
copies" or "substantial portions" of the software. In this, it is not entirely
"permissive".

It is implied that the software which is mentioned here is the original code as 
published by the original author. If someone makes additional code which 
complements that program but is otherwise newly introduced to the program, he 
can (sub)license (according to terms of Expat license) the additional code 
under a different license, provided it is compatible with Expat. GNU GPL is 
such a compatible license.[1]


> Works as wholes are licensed under 
> copyright licences, not parts of works.

False. Parts of works can be licensed under different licenses and combined 
into a single unit, provided the two licenses are compatible. See [1].

The same program can even be multi-licensed by the copyright holder (original 
author).[2]


> I don't think relicensing is particularly relevant: the question is whether 
> your work, i.e. the whole program you have published, which includes both 
> code you wrote and you did not write, is able to be licensed under the GPL. 
> That is about licence compatibility.

Let us recall the original message:

> I'm curious about licensing and was wondering why suckless tools are released 
> under MIT rather than an alternative like GPL. Is it just to make it 
> compatible 
> with more other software?

So yeah, the topic is about potential relicensing of suckless software under 
GNU GPL.

Still, as far as compatibility goes, the question is already answered multiple 
times here: Expat license is compatible with the GNU GPL.[3]


[1]: https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean
[2]: https://www.gnu.org/licenses/gpl-faq.html#HeardOtherLicense
[3]: https://www.gnu.org/licenses/license-list.html#Expat


signature.asc
Description: PGP signature

Re: [dev] [license] gpl issues

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

On 23/06/18 09:01, Страхиња Радић wrote:
> You can't license the whole of A as GPL, only your modifications.
[...]
> which explicitely forbids removing the copyright and permission notices on
> Expat-licensed code, or replacing them with, say, GPL notices.

On second thought, I think Markus may be right. It is GPL which would forbid 
non-compatible sublicensing (which is changing the license of derived works 
*completely*), not Expat. Under Expat, you can sublicense *your copy/fork* to 
any license, including the proprietary licenses. (This is one of the reasons 
why I think that GNU GPL is superior--it stays true to the original intent.)

Of course, the copyright holder(s), or original authors, can always choose to 
retain the original license on their software, or relicense their work in any 
way they choose (IMHO this wouldn't retroactively impact the forks made when 
the program's license allowed free-software-licensed forks).



signature.asc
Description: PGP signature

Re: [dev] Am I doing this right?

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

On 23/07/02 06:39PM, Sebastian LaVine wrote:
> On Sun Jul 2, 2023 at 6:28 PM EDT, Nikita Krasnov wrote:
> > While we're on it. Are there any good Android email clients 
> > that you can recommend? I've yet to find an app that allows 
> > you to send emails in plain text, let alone with line 
> > hard-wrapping :(
> 
> I use and can recommend .

Since K9-Mail announced[1] that it will be "integrated" into Mozilla 
Thunderbird on Android, I use FairEmail[2] instead. Both "apps" are a bloated 
mess, but at least FairEmail doesn't depend on privacy-intruding Mozilla[3].

BTW, I suggest avoiding Android in the first place, for multiple reasons.

I have compiled a list of programs I use and recommend on my website[4] (page 
is in Serbian, but you can Google translate it to somewhat acceptable level).


[1]: https://k9mail.app/2022/06/13/K-9-Mail-and-Thunderbird
[2]: https://email.faircode.eu/
[3]: https://digdeeper.club/articles/mozilla.xhtml
[4]: https://strahinja.org/tekstovi/softver/preporuke


signature.asc
Description: PGP signature

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

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

On 23/07/04 07:06PM, Nikita Krasnov wrote:
> What would be the point of using minimalist software if bloated and
> excessively complex programs completely satisfy all my needs?

Doing all that but with much less resources (in the broadest sense) wasted.


On 23/07/04 01:16PM, Dave Blanchard wrote:
> 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,

Troll.


> noticeably faster as well when ST is patched with the juvenile "scrollback 
> buffer support" implementation

I use tmux.

Scrollback patch is literally the last recommended solution to scrollback in st 
FAQ:

> ## How do I scroll back up?
>
> * Using a terminal multiplexer.
>* `st -e tmux` using C-b [
>* `st -e screen` using C-a ESC
> * Using the excellent tool of [scroll](https://git.suckless.org/scroll/).
> * Using the scrollback [patch](https://st.suckless.org/patches/scrollback/).



signature.asc
Description: PGP signature

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

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

On 23/07/04 07:06PM, Nikita Krasnov wrote:
> 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.

Neovim is bloat. But for both Neovim and vi/Vi IMproved, just go through the 
tutorial and learn basic keys and ideas behind using it. (BTW, addons are 
unnecessary, Vim is a fully functional text editor, and then some.) If that's 
too hard for you, then that's your reason, the "why (not)?". Just carry on 
using whatever else without regrets. But if you want to be a "cool kid", you 
should know that that's bought with self-determination and a strength of will 
to read, tinker and explore.

BTW, the rationale and core ideas behind the suckless movement are explained on
the website, go read it:

https://suckless.org/philosophy/



signature.asc
Description: PGP signature

Re: [dev] Problem with windows name

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

On 23/07/09 08:43AM, Dr. André Desgualdo Pereira wrote:
> # xprop
> xprop shows the correct name, but it doesn't has the _NET_WM_NAME defined as 
> it used to have on Debian 11 and before (I guess it is because missing 
> library 
> tkinter for python2.7).
> Example: WM_NAME(STRING) = "André Desgualdo.odt - OpenOffice Writer"

I have made two files, one with á and ASCII characters and another with added 
њ. The results from xprop are:

WM_NAME(STRING) = "thisátest.odt - LibreOffice Writer"
^^
WM_NAME(COMPOUND_TEXT) = "thisátestњ.odt - LibreOffice Writer"
^

This implies that this is a X.Org issue. Strings having only ISO 8859-1 
characters are silently degraded to STRINGs when they should really be 
COMPOUND_TEXT.


signature.asc
Description: PGP signature

Re: [dev] Problem with windows name

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

I debugged dwm, adding to drw.c:

static void
log_msg(const char* fmt, ...)
{
char buf[4096];
va_list args;
va_start(args, fmt);
vsnprintf(buf, sizeof(buf), fmt, args);
va_end(args);
fprintf(logfile, "%s\n", buf);
}

and calls to utf8decodebyte:

static long
utf8decodebyte(const char c, size_t *i)
{
   for (*i = 0; *i < (UTF_SIZ + 1); ++(*i))
   if (((unsigned char)c & utfmask[*i]) == utfbyte[*i])
   {
   log_msg("*i = %lu, for '%c' returning '%c'",
   *i, c, (unsigned char)c & ~utfmask[*i]);
   return (unsigned char)c & ~utfmask[*i];
   }
   return 0;
}

and drw_text:
utf8str = text;
nextfont = NULL;
while (*text) {
   log_msg("*text == '0x%X' == '%c'",
   *text, *text);
   utf8charlen = utf8decode(text, &utf8codepoint, 
UTF_SIZ);
   for (curfont = drw->fonts; curfont; curfont = 
curfont->next) {
   charexists = charexists || 
XftCharExists(drw->dpy, curfont->xfont, utf8codepoint);

I got the following output from "thisátest.odt"

// á
*text == '0xFFE1' == ''
*i = 3, for '' returning '^A'
*i = 1, for 't' returning 't'
*text == '0x74' == 't'
*i = 1, for 't' returning 't'

and the following from "thisátestњ.odt":

// á
*text == '0xFFC3' == ''
*i = 2, for '' returning '^C'
*i = 0, for '' returning '!'
[...]
// њ
*text == '0xFFD1' == ''
*i = 2, for '' returning '^Q'
*i = 0, for '<9A>' returning '^Z'

From here, it seems that dwm is receiving correct UTF-8 representations of "á"
(0xC3 0xA1) and "њ" (0xD1 0x9A) for "thisátestњ.odt", but it receives
ISO 8859-1 representation of "á" (no wonder, given it is passed a STRING 
instead 
of UTF8_STRING or COMPOUND_TEXT), 0xE1, followed by the next ASCII character, 
0x74 ("t"), still interpreting the two as UTF-8 sequence, when those two bytes 
form an invalid UTF-8. That invalid UTF-8 is further passed to libfreetype or 
whatever, which just interrupts output at that point.


signature.asc
Description: PGP signature

Re: [dev] Problem with windows name

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

Adding to gettextprop in dwm.c:

// ...
if (!XGetTextProperty(dpy, w, &name, atom) || !name.nitems)
return 0;
FILE* log = fopen("/home/user/dwm.log", "at");
fprintf(log, "---\n");
fprintf(log, "atom = {%lu}\n", atom);
fprintf(log, "text = {%s}\n", text);
fprintf(log, "value= {%s}\n", name.value);
fprintf(log, "encoding = {%lu}\n", name.encoding);
fprintf(log, "format   = {%d}\n", name.format);
fprintf(log, "nitems   = {%lu}\n", name.nitems);
fclose(log);
if (name.encoding == XA_STRING) {
// ...

I got: 

---
atom = {39}
text = {}
value= {thistest.odt - LibreOffice Writer}
encoding = {31}
format   = {8}
nitems   = {34}
---
atom = {39}
text = {}
value= {thistestL.odt - LibreOffice Writer}
encoding = {385}
format   = {8}
nitems   = {38}

So COMPOUND_TEXT sets the encoding field of XTextProperty to 385, a value not 
listed in Xatom.h, while STRING sets it to 31 (XA_STRING). The code:

if (name.encoding == XA_STRING) {
strncpy(text, (char *)name.value, size - 1);
} else if (XmbTextPropertyToTextList(dpy, &name, &list, &n) >= Success 
&& n > 0 && *list) {
strncpy(text, *list, size - 1);
XFreeStringList(list);
}

converts any string not having XA_STRING as encoding with 
XmbTextPropertyToTextList[1].

The issue is that ISO 8859-1-encoded text, marked as XA_STRING, is copied with 
strncpy, and treated as UTF-8 later on in drw_text in drw.c. It probably should 
be converted to UTF-8 from the current locale, even when encoding field is set 
to XA_STRING. However, when I commented out the first branch like this:

/*if (name.encoding == XA_STRING) {
strncpy(text, (char *)name.value, size - 1);
} else*/ if (XmbTextPropertyToTextList(dpy, &name, &list, &n) >= Success
&& n > 0 && *list) {
strncpy(text, *list, size - 1);
XFreeStringList(list);
}

The document title in LibreOffice was shown correctly. *However*, the output 
from slstatus, containing UTF-8 while having the encoding field also set to 
XA_STRING, was *not* shown correctly, even though the description of 
XmbTextPropertyToTextList states that

> The input text strings must be given in the current locale encoding (for 
> XmbTextListToTextProperty and XwcTextListToTextProperty), or in UTF-8 
> encoding 
> (for Xutf8TextListToTextProperty).

and my LANG is set to sr_RS.UTF-8 (so my "current locale encoding" should be 
UTF-8).

So, this would be a workaround, but one with further potential issues.


[1]: https://linux.die.net/man/3/xmbtextpropertytotextlist

Re: [dev] Problem with windows name

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

I managed to fix root window title being shown incorrectly by skipping 
conversion only for root window. I attached a patch with this message. Feel 
free to review it, I will make any necessary corrections.
From c5b399e138f6873e2eb9a292d55c5382e654f074 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A1=D1=82=D1=80=D0=B0=D1=85=D0=B8=D1=9A=D0=B0=20=D0=A0?=
 =?UTF-8?q?=D0=B0=D0=B4=D0=B8=D1=9B?= 
Date: Mon, 10 Jul 2023 09:25:30 +0200
Subject: [PATCH] dwm.c: Always convert title to UTF-8, except for root window
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Window names containing only ISO 8859-1 were broken on the location of
non-ASCII ISO 8859-1 character, for example áâãéíóôúç, because they were
treated as UTF-8. When commenting out the if-branch testing for XA_STRING, root
window title, usually set by status programs such as slstatus to UTF-8 text,
was not shown correctly, so this patch adds an exception for root window
instead, skipping conversion in that case.

Reported by Dr. André Desgualdo Pereira.

Signed-off-by: Страхиња Радић 
---
 dwm.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/dwm.c b/dwm.c
index f1d86b2..c896325 100644
--- a/dwm.c
+++ b/dwm.c
@@ -917,7 +917,10 @@ gettextprop(Window w, Atom atom, char *text, unsigned int size)
 	text[0] = '\0';
 	if (!XGetTextProperty(dpy, w, &name, atom) || !name.nitems)
 		return 0;
-	if (name.encoding == XA_STRING) {
+	/*if (name.encoding == XA_STRING) {
+		strncpy(text, (char *)name.value, size - 1);
+	} else */
+	if (w == DefaultRootWindow(dpy)) {
 		strncpy(text, (char *)name.value, size - 1);
 	} else if (XmbTextPropertyToTextList(dpy, &name, &list, &n) >= Success && n > 0 && *list) {
 		strncpy(text, *list, size - 1);
-- 
2.38.5



signature.asc
Description: PGP signature

Re: [dev] sbm dmenu bookmarker

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

On 23/07/31 08:15AM, Randy Palamar wrote:
> `grep -v -e '#' -e '^$' $BOOKMARKS | dmenu -i -l 20 | cut -f 1 -d ' '`
> 
> Then I pipe it to the clipboard or a plumber script depending
> on what I want to do with it (bound to a keybind in dwm).
> 
> To add bookmarks I either use a text editor or just echo:
> 
> `echo "https://nsa.gov file sharing, hosting provider" >> $BOOKMARKS`

Since bookmarks are related to the Web, I usually keep them inside of my 
bloated web browser for the bloated Web (the very term [in the digital 
sense] originates from Netscape IIRC). They can be copied to the clipboard from 
there and pasted into st. Anything else I just type out. ¯\_(ツ)_/¯


signature.asc
Description: PGP signature

Re: [dev] C variants, compilers and completeness

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

On 23/08/18 02:18, David Demelier wrote:
> On Mon, 2023-07-24 at 17:38 +0200, Sagar Acharya wrote:
> > I see C compilers recommended by suckless are:
> > 
> > tinycc
> > simplecc
> > cproc
> > qbe
> > lacc
> 
> qbe isn't a compiler. however cproc is promising but I had various
> issues compiling some apps, can't use it as my daily for now.

I haven't checked recently, but the most noticeable missing feature of cproc, 
as well as some other compilers, were VLAs. When someone writes the support for 
VLAs, cproc & co. will become much more usable.

The simpler compilers generally work for smaller projects, but for many 
existing packages, for now there is no real alternative to GCC and Clang/LLVM.


signature.asc
Description: PGP signature