Re: [dev] [st] fixed font doesn't work

[Hadrien Lacour]

On Sun Jan 29, 2023 at 5:35 PM CET, Mikhail wrote:
> Hi, I'd like to switch from xterm to st, but i want to keep xterm's
> default font, if I do
>
> xterm -fn '-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1'
>
> everything is ok - it's the font I want to use, but if i do
>
> st -f '-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1'
>
> i see different font, much larger and much uglier.
>
> Some fc-* commands (font 6x13 also the font I'd like to use):
>
> $ fc-match -- -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
> DejaVuSans.ttf: "DejaVu Sans" "Book"
>
> $ fc-match 6x13
> DejaVuSans.ttf: "DejaVu Sans" "Book"
>
> $ fc-list | grep 6x13
> /usr/X11R6/lib/X11/fonts/misc/6x13O.pcf.gz: Fixed:style=Oblique SemiCondensed
> /usr/X11R6/lib/X11/fonts/misc/6x13B-ISO8859-1.pcf.gz: Fixed:style=Bold 
> SemiCondensed
> /usr/X11R6/lib/X11/fonts/misc/6x13B.pcf.gz: Fixed:style=Bold SemiCondensed
> /usr/X11R6/lib/X11/fonts/misc/6x13O-ISO8859-1.pcf.gz: Fixed:style=Oblique 
> SemiCondensed
> /usr/X11R6/lib/X11/fonts/misc/6x13.pcf.gz: Fixed:style=SemiCondensed
> /usr/X11R6/lib/X11/fonts/misc/6x13-ISO8859-1.pcf.gz: Fixed:style=SemiCondensed
> /usr/X11R6/lib/X11/fonts/misc/clR6x13.pcf.gz: Clean:style=Regular
>
>
> How to make st use default xterm's font? It's OpenBSD current.

st uses xft, try `st -f 'Misc Fixed:style=SemiCondensed:pixelsize=13'`.

Re: [dev] [libgrapheme] version 2.0.0 release

[Hadrien Lacour]

On Thu Oct 6, 2022 at 11:23 PM CEST, Laslo Hunhold wrote:
> Dear fellow hackers,
>
> I'm pleased to announce version 2.0.0 of libgrapheme[0][1], a library
> for Unicode string handling.
>
> This version adds
>
>   - word segmentation
>   - sentence segmentation
>   - detection of permissible line break opportunities
>   - case detection
>   - case conversion
>
> and has been heavily refactored for correctness and conformance. The
> library now is freestanding (i.e. not dependant on a standard
> library), which allows you to link it into pretty much anything.
>
> There has been a small API-change: grapheme_next_character_break() has
> been renamed to grapheme_next_character_break_utf8() and GRAPHEME_STATE
> has been dropped in favor of an explicit uint_least16_t-state-variable
> for the single function it's being used with. Changing code should be
> quick and simple.
>
> I have made the decision to adopt the semantic versioning scheme[2].
> While it is not perfect, it gives the version number more semantic
> meaning, and in its spirit, I bumped the major version given there's
> been a breaking API change, but I don't expect many major version bumps
> in the future, if at all.
>
> Take a look at the README and libgrapheme(7) for an overview. Every
> function-manual comes with an example and the usage should be more or
> less obvious.
>
> With best regards
>
> Laslo Hunhold
>
> [0]: https://libs.suckless.org/libgrapheme
> [1]: https://dl.suckless.org/libgrapheme/libgrapheme-2.0.0.tar.gz
> [2]: https://semver.org/

Hurray, I'll probably try it soon, as I was waiting for case conversion to
happen.
Too bad I still need to roll my theoretically incorrect but de facto usable
wcwidth analog, but I understand the reasoning behind this choice.

Re: [dev] Some misc tools that could help others

[Hadrien Lacour]

On Wed Sep 21, 2022 at 8:21 PM CEST, NRK wrote:
> On Wed, Sep 21, 2022 at 04:24:28PM +0000, Hadrien Lacour wrote:
> > The other "interesting" one is genhtab, an alternative to gperf that is much
> > simpler to use and produces smaller binaries for big tables (but slower, cf
> > genhtab_bench) using a simple chained hashing table (with some tricks due to
> > being built AOT) using fnv1a; I'll probably try with XXH3 soon, to see if 
> > the
> > speed issue can be mitigated without too much binary bloating.
>
>   const uint32_t bkt =  hash & (ht.len - 1);
>
> Due to mul being the last step in fnv1a, the entropy is stored in the
> high bits, so you want to be masking the high bits and not the low ones.
Huh, makes sense, I was somehow counting on it having a good distribution.

> And for statically generated hash-tables (as well as in general) I tend
> to prefer open-addressing rather than chaining. For probing I prefer
> linear probe with robin-hood insertion[0] for statically generated
> tables.
>
Never liked the conceptual complexity of open addressing (and how you can lock
on a single bucket, in read-write MT scenarios), but it could be better, indeed.
Another thing I like about chained hashing, is how you can just change the
bucket type according to your read/write performance needs (vector, skiplist,
avl tree, etc...).

> As for why: linear probing nicely exploits spatial locality[1] and
> robin-hood can reduce the max probe size by alleviating clustering[2].
> This leads to both faster worst-case lookups as well as less memory
> usage.
In this specific case, there's not much cache improvement since the bucket
contents are stored sequentially, without pointers except for the keys.

> For run-time tables where you don't know the inputs, double-hashing
> might be a better approach[3]. But for statically generated one, I
> wouldn't use double-hashing since you can easily change the hash
> function until it's producing good results (e.g for fnv1a changing the
> starting state or the multiplier, or both[4]).
>
> Also one more trick that can reduce memory usage is to eliminate pointer
> overhead and use an array of arrays, i.e using `char [][n]` instead of
> `char *[]`. This isn't _guaranteed_ to reduce mem usage though, so
> you'll have to do some calculation to figure it out, i.e:
>
>   /* approximate mem usage for `char *[]` */
>   for (sum = 0, i = 0; i < LEN(input); ++i)
>   sum += (strlen(input[i]) + 1) + sizeof (char *);
>   /* vs char[][max_input_strlen + 1] */
>   sum = LEN(input) * (max_input_strlen + 1);
>
That's a very special case, but worth thinking about, indeed.

To be honest, performance wasn't the focus, since I can't imagine beating
gperf -lC.

[dev] Some misc tools that could help others

[Hadrien Lacour]

y ASCII, it is then considered UTF-8 encoded and
embedded via a C11 u8"..." string literal (TODO: automatic conversion if
uchardet/iconv are available, C23/C++20 char8_t handling)


And that's all. Hope it wasn't spam to you. If you too have some small potatoes
stuff that doesn't warrant a project announcement but certainly make your life
easier, don't hesitate to follow.

Regards,
Hadrien Lacour

Re: [dev] ii: how to process out in a pipeline and still page with less

[Hadrien Lacour]

On Sat, May 28, 2022 at 08:32:57PM +0200, Markus Wichmann wrote:
> ultimately terminates on the terminal. But who knows if that is the
> case? Pipelines ending in a call to "less" will terminate on the
> terminal, pipelines ending in a call to "nc" will not. So the shell
> can't know, only the last command can know.

The only solution would be to allow buffering to be passed through
exec/posix_spawn, with a way to signal tools to not go through their heuristic
logic. Then the shell could have a syntax to signal the pipeline buffering mode.

Basically, another POSIX problem that can't be fixed =).


[BLOG POST WARNING]

A better solution would require departing from UNIX/POSIX and its minimalist API
of "input: stdin/argv/signals in, output: stdout/stderr/return code out and FS
for both".

You know, years ago I found myself laughing at stuff like Lisp OSs or Spring as
overly complex academic drivel, but the more I "progress" in computing, the
more I learn of my error and understand UNIX as reactionary: rightly so,
considering Multics and PL/I and the hardware of the time; but the reasons that
made sense then don't now.
Now that I'm infatuated with Common Lisp, functions instead of executables make
perfect sense to me. In that case there would be no pipe and no buffering
problem at all, since memory is shared and you're passing objects/pointers
around instead of copying massive amounts of it via kernel.

Re: [dev] ii: how to process out in a pipeline and still page with less

[Hadrien Lacour]

On Sat, May 28, 2022 at 07:58:40PM +0200, Markus Wichmann wrote:
> > You can use stdbuf(1) to modify that aspect without touching the
> > program source itself.
> >
>
> Had to look up the source for that. I had heard of stdbuf, but I always
> thought that that was impossible. How can one process change a
> process-internal detail of another program? One that is not inherited
> through fork() or exec(), I mean. Well, turns out it is impossible.
> stdbuf sets LD_PRELOAD and execs the command line, and the changing of
> the buffer modes happens in the library.
>
> That means that whole thing only works if:
> - you have the target program linked dynamically
> - you have stdbuf and the target program linked against the same libc
> - the target program doesn't change buffering modes later, anyway
> - the target program does not have elevated privilege.
>

You know what, thanks for looking it up, I also thought it was using some kind
of fork or ptrace hack. The man page doesn't even mention this =(

Now, I wonder how it'd be fixed ("it" being how does the read end of the pipe
signal to the write one the kind of buffering it wants) in a perfect world.
An environment variable read by the libc would work but is kind of ugly. A pipe
flag together with a special sh syntax would be even uglier. H.

Re: [dev] ii: how to process out in a pipeline and still page with less

[Hadrien Lacour]

On Sat, May 28, 2022 at 03:33:16AM +, Rodrigo Martins wrote:
> Hello,
>
> The problem here is I/O buffering. I suspect it to happen in the C standard 
> library, specifically on the printf function family. If I recall, the C 
> standard says stdio is line-buffered when the file is an interactive device 
> and let's it be fully buffered otherwise. This is likely why you see 
> different behavior with and without less on the pipeline.
> I don't yet have a clear solution to this problem that doesn't involve 
> modifying each program in the pipeline, but I've annexed a C source as an 
> example that may be used in place of tr to replace single chars. This program 
> is not supposed to buffer any I/O.
> I see tee "shall not buffer output". Another possibility is the setbuf 
> function, but I'm not sure it can be used without editing each program. More 
> investigation is needed.
>
> Rodrigo.

You can use stdbuf(1) to modify that aspect without touching the program source
itself.

Re: [dev] ii: how to process out in a pipeline and still page with less

[Hadrien Lacour]

On Fri, May 27, 2022 at 02:43:03PM -0400, Greg Reagle wrote:
> I have a file named "out" (from ii) that I want to view.  Of course, it can 
> grow while I am viewing it.  I can view it with "tail -f out" or "less +F 
> out", both of which work.  I also want to apply some processing in a 
> pipeline, something like "tail -f out | tr a A | less" but that does not 
> work.  The less command ignores my keystrokes (unless I hit Ctrl-C, but that 
> kills tail and tr).  The "tr a A" command is arbitrary; you can substitute 
> whatever processing you want, even just cat.
>
> This command "tail -f out | tr a A" is functional and has no bugs, but it 
> doesn't let me use the power of less, which I crave.
>
> This command "tail out | tr a A | less" is functional and has no bugs, but it 
> doesn't let me see newly appended lines.
>
> Can I use the power of the Unix pipeline to do text processing and the power 
> of less for excellent paging and still be able to see new lines as they are 
> appended?  Why doesn't or can't less continue to monitor stdin from the 
> pipeline and respond to my keystrokes from the tty?
>
> I am using Debian 11 in case it matters, with fish.  But I am happy to try 
> other shells.  In fact I already have and that doesn't seem to help.  I have 
> also tried more, most, nano -, and vi -, instead of less, to no avail.
>

I don't know ii at all, but it seems like you're searching for "less +F", to me.

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

[Hadrien Lacour]

On Tue, Apr 26, 2022 at 07:48:35PM +0200, Страхиња Радић wrote:
> 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.

I see, well, no cigar.

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

[Hadrien Lacour]

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

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.

Re: [dev] Some direction with my project

[Hadrien Lacour]

On Fri, Apr 15, 2022 at 09:37:07AM -0500, Chibby Bromanson wrote:
> On Fri, Apr 15, 2022 at 08:34:51AM +0000, Hadrien Lacour wrote:
> > On Thu, Apr 14, 2022 at 09:42:51PM -0500, Chibby Bromanson wrote:
> > > Greetings,
> > >
> > > I am very impressed with the suckless software movement and I am doing
> > > my best to try to create my own tool that follows the philosophy.  I
> > > still have a lot to learn with the C language but so far I am proud of
> > > the results.  I would be greatful if someone would review my tool and
> > > consider it for inclusion in the list of tools that ROCK! :D
> > >
> > > The tool is for maintaining a list of descriptive tags on an extended
> > > file attribute.  It plugs in nicely with fzf and other command line
> > > tools.
> > >
> > > http://github.com/bromanbro/taggins
> > >
> > > Thank you for your consideration.
> > >
> > > Dorian
> > >
> >
> > Any reason for using space as internal delimitor when it could be anything
> > that's unlikely to be used in a tag (e.g. ASCII US)?
> >
> > Although I had the same idea a long time ago, I decided that using some
> > kind of database [1] solves both the problem of xattr portability and
> > performance (no need to crawl the filesystem to get your tags).
> >
> >
> > [1] Would have to be anything with a daemon to avoid reading/writing the
> > db constantly and using a tree structure for performance reasons.
> > Said daemon could also do stuff like Windows -> POSIX and/or character 
> > encoding
> > path translation if more portability is wanted.
> >
> >
> > Regards,
> > Hadrien Lacour
> >
>
> Greetings,
>
> A space is used as a delimeter primarily because tags are by nature a
> single word.  And this tagging system, unlike many others, is made
> specifically to feed other command line tools while maintaining
> transparency and legibility.
>
Then I'd suggest \n: you get the same ease of use in sh, but you can have
your space.

> There are different ways to solve the problem of tagging.  All the
> technologies listed above; the need for a database, a daemon to monitor
> files etc.  That is why Xattribute is used.  So that you do not need
> those things.  Maintaining files and file information is the
> responsibility of the filesystem.
>
I understand the choice, believe me, but performance was high in my concerns
and my usecase is acting on a great number of files ("list all files with this
tag combination" or "sort this file list by tag(s)") on HDDs.

> After 12 years of Xattributes most tools and filesystems now respect
> them.  Your grandfathers zip program may not but tar will.
>
For example, NFS on Linux only got support for them with 5.9. And I don't think
NetBSD/OpenBSD support it (ZFS on NetBSD might, though).

Re: [dev] Some direction with my project

[Hadrien Lacour]

On Thu, Apr 14, 2022 at 09:42:51PM -0500, Chibby Bromanson wrote:
> Greetings,
>
> I am very impressed with the suckless software movement and I am doing
> my best to try to create my own tool that follows the philosophy.  I
> still have a lot to learn with the C language but so far I am proud of
> the results.  I would be greatful if someone would review my tool and
> consider it for inclusion in the list of tools that ROCK! :D
>
> The tool is for maintaining a list of descriptive tags on an extended
> file attribute.  It plugs in nicely with fzf and other command line
> tools.
>
> http://github.com/bromanbro/taggins
>
> Thank you for your consideration.
>
> Dorian
>

Any reason for using space as internal delimitor when it could be anything
that's unlikely to be used in a tag (e.g. ASCII US)?

Although I had the same idea a long time ago, I decided that using some
kind of database [1] solves both the problem of xattr portability and
performance (no need to crawl the filesystem to get your tags).


[1] Would have to be anything with a daemon to avoid reading/writing the
db constantly and using a tree structure for performance reasons.
Said daemon could also do stuff like Windows -> POSIX and/or character encoding
path translation if more portability is wanted.


Regards,
Hadrien Lacour

Re: [dev] Some direction with my project

[Hadrien Lacour]

On Thu, Apr 14, 2022 at 09:42:51PM -0500, Chibby Bromanson wrote:
> Greetings,
>
> I am very impressed with the suckless software movement and I am doing
> my best to try to create my own tool that follows the philosophy.  I
> still have a lot to learn with the C language but so far I am proud of
> the results.  I would be greatful if someone would review my tool and
> consider it for inclusion in the list of tools that ROCK! :D
>
> The tool is for maintaining a list of descriptive tags on an extended
> file attribute.  It plugs in nicely with fzf and other command line
> tools.
>
> http://github.com/bromanbro/taggins
>
> Thank you for your consideration.
>
> Dorian
>

Some implementation details: do you really need autohell when the only thing
you use it for is to detect the presence of sys/xattr.h? That's only a few lines
of sh calling cc to do the same.
Personally, I use POSIX sh to "augment" make with the usual stuff like
[un]install or what GNU make provides.


About my previous message, SQlite may work, I don't really know anything
about the support of tree structures in it. It is rarely wise to write
your own database, after all.

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

[Hadrien Lacour]

On Fri, Feb 11, 2022 at 02:54:24PM +0100, Hiltjo Posthuma wrote:
> Hi,
>
> I would like to share my project I've been using and tweaking over the years:
>
> sfeed is a RSS and Atom parser (and it has some format programs).
>

Another thank for your project, which completely replaced newboat (and its
ridiculous asciidoctor and thus Ruby build time dependency) for me.

Some tricks that may be useful:
* Use `no_proxy=* feed ...` to disable curl proxying, useful for those
  Cloudflare websites blocking Tor.
* Here's a wrapper around sfeed_curses to conserve the feed order from your
  sfeedrc: https://git.sr.ht/~q3cpma/scripts/tree/master/item/sfeed_view.sh
  (only the logic of overriding the feed function together with eval should be
  "extracted" from this).

Re: [dev] Wayland compositors

[Hadrien Lacour]

On Wed, Sep 08, 2021 at 08:35:33PM +0200, Laslo Hunhold wrote:
> On Tue, 31 Aug 2021 14:28:29 +0100
> Nick  wrote:
>
> Dear Nick,
>
> > Any thoughts, experiences, recommendations?
>
> the discussion has been very fruitful. Let me share my thoughts.
>
> Wayland the protocol is actually rather simple. It's a very thin
> messaging layer between a compositor and clients, nothing more.
> But this is exactly the problem: It's too thin and the
> Wayland-developers didn't dare to go beyond a minimal set of things.
>
This, it would have been a great goal to modularize X11 and keep the worthy
parts, not just reduce it to an exercise in "minimalism" (and complete lack of
portability) and expect the free FOSS market to magically solve the remainder.

> All of the things that are breaking are those based on
> (compositor-specific) Wayland-extensions which add functionality you'd
> expect (gamma control, screen sharing, etc. etc.). I will never forgive
> the Wayland-developers for their lack of courage.
>
> We're talking about the next generation of display/window managers, and
> they messed it up so badly! Just a few things that come to mind:
>
>- network transparency is a _good_ thing and was thrown away way too
>  easily. I like being able to run GUI-applications from time to
>  time via ssh. Most of the time they are just basic
>  GUI-framework-programs you could "stream" very efficiently, but if
>  you're talking about composited surfaces, I would expect Wayland
>  to do that for me too, via a compressed stream or something.
>  It's trivial to stream Ful-HD-Video P2P using modern compression
>  algorithms, why wasn't this taken into consideration?
>  People are always talking about moving away from the single
>  computer and into the "orbit" (see Urbit, etc.). Today's
>  technology makes it possible to be much more flexible in this
>  regard.
>- color management was totally ignored. This could've been a strong
>  point for Wayland, but instead they made it even worse than in X,
>  which is actually a difficult feat. We need to move away from the
>  sRGB-monoculture, especially because it's not bloaty to actually
>  support proper colour management and it has tangible benefits.
>- everything about Wayland is hacky and deeply integrated into
>  Linux, but what for? To get "perfect frames", as it is often said?
>  This could've been done so much better, for example by going
>  vector-first. Most stuff in a GUI can easily be represented by
>  vector-data, which is very sparse. You do have bitmap-surfaces
>  from time to time (video player, browser, games, etc.), but it
>  would've been a very interesting and radical approach. The
>  advantage of this is that you don't need to think about dpi and
>  other shit except in those bitmap surfaces. All the rasterization
>  would be the last step and not intrinsic to the protocol itself,
>  but just the compositor.
>
> Anyway, to sum it up: Probably nobody here is really a fan of X, but
> it's what we have. Wayland is an underwhelming mess and they really
> dropped the ball here. The mix of (often incompatible and competing)
> extensions that are made up and forced upon us (while leading to more
> and more userspace-applications relying on them and unexpectedly
> breaking in vanilla Wayland-compositors that don't want to be tainted
> with the garden-variety of extensions) is just horrible.
>
> I used to have enthusiasm about Wayland, but now this feeling has
> completely been replaced with pity. They really dropped the ball on
> this one and I will not waste any more time with it.
>
> With best regards
>
> Laslo
>
A good rant. Let me add my biggest problem: global keyboard grabbing isn't
possible unless done by the compositor, so something like bspwm+sxhkd doesn't
look possible right now.

Re: [dev] Wayland compositors

[Hadrien Lacour]

On Tue, Aug 31, 2021 at 03:49:43PM +0200, Maarten van Gompel wrote:
> Hi Nick et al,
>
> With Sxmo we're currently also moving towards wayland (we'll have to
> reinvent what the X in our name means then).  We found that, especially
> on the Pinephone, the performance under Wayland is simply superior to
> that on X11. We settled on sway to replace dwm, as dwl still lacks the
> maturity we need and sway has that going for it. I agree it comes with
> maybe a few too many bells & whistles as we'd like. Though of course, by
> definition a wayland compositor has a considerably higher complexity
> than an X11 window manager anyway.
>
> We will also keep supporting X and the suckless stack, but
> Wayland will become the default in the very near future for us.
> Unfortunately this means we had to look for comparable alternatives for
> the suckless software stack we've grown attached to. But fortunately
> there are people taking up wayland-focused initiatives with a similar
> philosophy. Thus far we have:
>
> dwm -> sway (granted, not the same thing)
> svkbd -> wvkbd  (see https://github.com/jjsullivan5196/wvkbd/pull/2)
> st -> foot
> dmenu -> bemenu
>

If only there was an equivalent to lemonbar and bspwm+sxhkd (not possible from
what I understand; unless the compositor launches the binary, maybe?).

https://github.com/majestrate/wterm looks like a better concept but foot is
maintained and doesn't bundle wld, at least.

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

[Hadrien Lacour]

On Sat, Aug 07, 2021 at 02:54:18PM +0200, Sagar Acharya wrote:
>
>
> > On Sat, Aug 07, 2021 at 10:34:00AM +0200, Sagar Acharya wrote:
> >
> >> Just 1 thing needs to be done, make easier for a majority to use minimal, 
> >> secure software and make it harder for majority to use gigantic, malware 
> >> injected software. And things would become better.
> >>
> > Sadly not possible, as the whole concept of orthogonality (a requirement for
> > simplicity) goes against the fact that the majority of people don't want to
> > tailor the computer to their needs, they want it to "just werk".
> >
> This is where I diverge from suckless, suckless goes for hardcore 
> minimalistic software at cost of user experience. 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.
>
> If I want to serve good software to people who want their systems to "just 
> werk" (most out there), today, I'll go for trisquel KDE edition. It's not 
> minimalistic but much better than Windows.
>

So you're trying to solve a societal problem with technology. Good luck.

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

[Hadrien Lacour]

On Sat, Aug 07, 2021 at 06:59:08AM -0600, Lincoln Auster wrote:
> Hi,
>
> > Anyway, you're correct, and that's why modularity (which needs a
> > better interchange format than UNIX's stream of bytes, to be honest)
>
> This is pretty irrelevant to the original email, but in terms of IPC
> protocols, what would you suggest instead?
>
My problem is that a lot of tools output and/or take tabular data (lists being
a special case with 1 column); with newlines being a massive pain in file lists
or ls/df/free/etc... output being a pain to parse _properly_.
What I would propose:
* Environment variables FS and RS can be used to define the field and record
  separators; these would default to ASCII US and RS (which is, after all, the
  reason these control chars exist).
* All tools should have options to override them (even if you can already
  override the env by invocation).
* Either make control characters forbidden in filenames - POSIX will never do
  that, as the austin group bug tracker shows - or use US and \0 as default
  values for FS and RS.

> I've been writing a small application with dbus recently, and I've been
> pretty happy with dbus as a protocol. It looks to be very good at
> solving some of the problems that plain text can't, and its interfaces
> seem like not at all a bad a choice for complex (that is, non purely
> textual) interaction. I imagine, however, that its OO-ness and relative
> size make it somewhat unpopular among the 'minimal-at-any-cost' subset
> of the suckless community. Does anyone have any specific protocol
> recommendations, and thoughts on dbus (or RPC in general) as a method
> for complex IPC? thanks!
>
Personally, I think the concept is nice, even though 
https://9fans.github.io/plan9port/man/man4/plumber.html
was a better solution. I'm quite partial to UNIX domain sockets and IPC FIFOs
(with a dummy writer fd opened by the receiver), but it's obviously less
"streamlined" than system buses.

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

[Hadrien Lacour]

On Sat, Aug 07, 2021 at 10:34:00AM +0200, Sagar Acharya wrote:
> Just 1 thing needs to be done, make easier for a majority to use minimal, 
> secure software and make it harder for majority to use gigantic, malware 
> injected software. And things would become better.
Sadly not possible, as the whole concept of orthogonality (a requirement for
simplicity) goes against the fact that the majority of people don't want to
tailor the computer to their needs, they want it to "just werk".

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

What they don't want is languages like C that tries to give the bare minimum
(although lacking real genericity, which _Generic isn't) while being easy to
compile or like Forth/Lisp/Tcl that gives them IMMEDIATE/defmacro/uplevel and
tell that this is what real power looks like and to get to work if they want to
wield it.


By the way, this sidenote by Paul Graham (to be honest, the whole article:
http://paulgraham.com/avg.html) should be given to read to CS students:
> [3] All languages are equally powerful in the sense of being Turing
> equivalent, but that's not the sense of the word programmers care about. (No
> one wants to program a Turing machine.) The kind of power programmers care
> about may not be formally definable, but one way to explain it would be to
> say that it refers to features you could only get in the less powerful
> language by writing an interpreter for the more powerful language in it. If
> language A has an operator for removing spaces from strings and language B
> doesn't, that probably doesn't make A more powerful, because you can probably
> write a subroutine to do it in B. But if A supports, say, recursion, and B
> doesn't, that's not likely to be something you can fix by writing library
> functions

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

[Hadrien Lacour]

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

I don't want to rain hard on your parade, but your website pages load 72 kB of 
minified JS/CSS.

Anyway, you're correct, and that's why modularity (which needs a better 
interchange format than
UNIX's stream of bytes, to be honest) is important to scale better without the 
amount of bug
and difficulty of testing scaling similarly.

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

[Hadrien Lacour]

On Tue, Jun 29, 2021 at 01:48:51PM +0200, Mateusz Okulus wrote:
> sxhkd complicates the setup with little additional benefit.

The point of sxhkd isn't really itself, but having your daemon I/O completely
available through IPC. This is a big advantage, as it allows the most
power/freedom when interacting with it; especially through scripting.

And of course, it's very easy to replace something like sxhkd.

Re: [dev] Why not use the -exec feature of find?

[Hadrien Lacour]

On Tue, Jun 22, 2021 at 08:26:40AM -0400, Greg Reagle wrote:
> All over the place (tutorials, manuals, articles, questions and answers) I 
> see the advice to use the null feature of find (-print0) and xargs (-0) to be 
> able to handle any kind of wacky file name (e.g. filenames with newlines).  
> Granted, *if* you are going to pipe find into xargs, the advice makes sense.  
> But wouldn't it be better in every way to use the -exec (or -execdir) feature 
> of find instead of piping into xargs?  Why isn't that the common advice?  Is 
> the -exec feature of find fairly new, or fairly new to Posix?
>

More specifically,
everything can be done with:

find ... -exec sh -c '
# My code using $@
' argv0 {} + | ...

Re: [dev] I just "discovered" programming language Nim

[Hadrien Lacour]

On Sun, May 02, 2021 at 08:37:54AM -0400, Greg Reagle wrote:
> I just "discovered" programming language Nim.  Has anyone tried it?  Any 
> reviews?  Looks very interesting.
>
> https://nim-lang.org/
>

Seeing some examples on RosettaCode, it certainly doesn't look bad, but isn't
radical/high level enough to replace Lisp/Scheme/Tcl/FORTH/etc..., nor is it
simple enough (syntax, concept numbers, GC) to replace C. Looks like another
"jack of all trades, master of none" Python-like lang, to me.

Re: [dev] Completeness suckless

[Hadrien Lacour]

On Sat, Apr 10, 2021 at 08:14:08AM +0200, Sagar Acharya wrote:
> If suckless wants this to become mainstream philosophy
That's where the fallacy is. I suppose suckless devs aren't naive and simply
know that people aren't the same (dare I say "not equal"), so they simply make
software for themselves and people like themselves.

Re: [dev] Completeness suckless

[Hadrien Lacour]

On Fri, Apr 09, 2021 at 01:07:01PM -0700, Jeremy wrote:
> On 04/09/21 09:07PM, Hadrien Lacour wrote:
> > On Fri, Apr 09, 2021 at 08:24:35PM +0200, Sagar Acharya wrote:
> > > I have studied Engineering Physics at IIT Delhi. There, Computer Science 
> > > guys are insane geniuses. They don't bother to set their system up. Very 
> > > few do. Most use dual boot Ubuntu and Windows. Now that I have completed 
> > > my Bachelor degree, I do not know a single person in my surroundings who 
> > > uses GNU/Linux or BSD OSes.
> > Which goes on to show that Computer Science has nothing to do with 
> > computers and
> > that scientists aren't necessarily the same as engineers/programmers,
> > nor are they wiser than average.
> > (I say that coming from one of the best universities in France; I didn't 
> > have
> > very much respect left for the word "scientist" when I left).
> >
>
> Do architects lay brick?
>

No, but they better understand how bricks work. Unless "architect" just means
"designer", nowadays, and I'm just being out of touch with the times.

Re: [dev] Completeness suckless

[Hadrien Lacour]

On Fri, Apr 09, 2021 at 02:54:31PM +0200, Sagar Acharya wrote:
> P.S. Shifted completely to dwm this week. Can't even think of anything 
> theoretically better than this!

Now, try bspwm :)

Re: [dev] Completeness suckless

[Hadrien Lacour]

On Fri, Apr 09, 2021 at 08:24:35PM +0200, Sagar Acharya wrote:
> I guess this is where I diverge, user centric things always work better and 
> have more power.
More features != More power.
> One can always add a few more simple things, keeping minimalism of suckless 
> intact. One can create dwmd (dwm for dumb) with few more features.
Minimalism/power and catering to the lowest common denominator are simply and
completely incompatible. You've got to understand that interfaces for grandma
or Joe down the street and the ones for those who use dwm/bspwm can't be made
one. You have to be best at what you do, not a ridiculous jack-of-all-trades.

> Majority of the people in this world are never going to bother with creating 
> their own code.
Then they'll never be "free" while using something they will never bother
understanding.

> I have studied Engineering Physics at IIT Delhi. There, Computer Science guys 
> are insane geniuses. They don't bother to set their system up. Very few do. 
> Most use dual boot Ubuntu and Windows. Now that I have completed my Bachelor 
> degree, I do not know a single person in my surroundings who uses GNU/Linux 
> or BSD OSes.
Which goes on to show that Computer Science has nothing to do with computers and
that scientists aren't necessarily the same as engineers/programmers,
nor are they wiser than average.
(I say that coming from one of the best universities in France; I didn't have
very much respect left for the word "scientist" when I left).

Re: [dev] Completeness suckless

[Hadrien Lacour]

On Fri, Apr 09, 2021 at 12:10:54PM -0400, Greg Reagle wrote:
> On Fri, Apr 9, 2021, at 11:42, Hadrien Lacour wrote:
> > Where do we stop, though? For me, sh (even with all its braindamage)
>
> Speaking of the brain damage of sh, I highly recommend rc [1] which is 
> available
> in 9base [2] and other sources like Plan 9 Port.

I've found my calling with Tcl, personally. It's really what the shell should
have been, in my opinion, though it lacks the easy '|', which does live as
pipethread if it's really wanted.

Re: [dev] Completeness suckless

[Hadrien Lacour]

On Fri, Apr 09, 2021 at 02:54:31PM +0200, Sagar Acharya wrote:
> I recently wrote this article
>
> https://designman.org/sagaracharya/blog/trusting_no_one
>
> being absolutely unaware about suckless and this was brought to my attention.
>
> Suckless's philosophy is hands down amazing and crucial wrt computer 
> security. Although I'd like to point out 1 aspect. Why does suckless target 
> very sophisticated users? If it shuns trying to go after elitist users, it 
> can improve computer security of people all around the world and also 
> themselves, since if others are secure, you yourself will become even more 
> secure!
>
> For it, there would be few requirements. Free software, minimal, easy to use, 
> beautiful to look at (by default). I guess the latter 2 are lagging a bit.
>
> Thanking you
> --
> Sagar Acharya
> https://designman.org
>
> P.S. Shifted completely to dwm this week. Can't even think of anything 
> theoretically better than this!
>

Where do we stop, though? For me, sh (even with all its braindamage) is exactly
what suckless for the masses is, allowing for almost Lego-like ease of building
software as you want it. Actually, it is only the concept of pipes and line
oriented programs that provide that.

Security isn't the main point of suckless, it's only a consequence of clean and
simple code.
The main point is to empower people, but not through the spoon-feeding and
shoestring-tying the FSF likes so much, but by helping those who help
themselves.
That's how you get actual "computer freedom", by being able to program and
fullfill more and more of your needs/wants. suckless programs are made to
fit this mindset: simple enough to be modified and built around the UNIX
philosophy of use with other simple programs.

The people who want that simplicity but with more power (very hard thing to
create, actually), turn to Scheme or Tcl.

Re: [dev] st: enlarge font

[Hadrien Lacour]

On Mon, Mar 22, 2021 at 03:15:35PM -0400, Sebastian LaVine wrote:
> On 3/22/21 12:20 PM, Nuno Teixeira wrote:
> > please don't! I use i3+st for about 10 years!
> > Why?
> I don't think it is you that Wesley was referring to, Nuno, but rather this
> one:
>
> > > On Monday, March 22nd, 2021 at 12:59 AM, 
> > >  wrote:
>
> The Suckless community is international, and many of course do not speak
> English -- in particular American English -- as a primary language. But as
> an American, the word used in that email address is beyond vulgar, and
> extremely -- uniquely -- offensive. I agree with Wesley that that email
> address should be removed from the list.
>
> --
> Sebastian LaVine | https://smlavine.com
>

You'll have better luck with the Debian mailing lists.

Re: [dev] Build system: redo

[Hadrien Lacour]

On Sun, Jan 03, 2021 at 02:38:30PM -0500, 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.
>
> > In my opinion the later is easier to read and understand.
>
> Yes I agree that the echo is a bit simpler and easier than the printf, but it
> has disadvantages.
>

Pretty easy to replace echo in your and any scripts, as long as it doesn't use
-n or -e.

echo()
{
printf '%s\n' "$*"
}

Re: [dev] [sbase][tar] GNU tar support

[Hadrien Lacour]

On Wed, Nov 25, 2020 at 05:49:56PM +0100, Laslo Hunhold wrote:
> On Wed, 25 Nov 2020 07:51:22 -0500
> Cág  wrote:
>
> Dear Cág,
>
> > A quick question: for "POSIX tar archive (GNU)" files tar prints
> > tar: unsupported tar-filetype L
> >
> > Is GNU tar support out of scope?
>
> there's probably no way to implement those GNU-extensions in a good and
> suckless way. The FSF has the bad habit for their
> standard-implementations that they tend to add everything including the
> kitchen sink which might as well be easily handled by other standard
> tools (think of "cat -v" for example).
>
> Even if a suckless implementation of GNU tar was possible, would you
> really want it to be included? I'd rather like to encourage people to
> use standard non-proprietary file formats.
>
> With best regards
>
> Laslo
>

This portability report 
https://mgorny.pl/articles/portability-of-tar-features.html
might help a bit.

The tl;dr is that you either use POSIX ustar with its path length and file size
limits, or use GNU tar when your input doesn't fit; pax was supposed to be the
replacement, but is more or less unused/ignored.

Regards

Re: [dev] Scrollback utility for use with st

[Hadrien Lacour]

On Mon, Apr 06, 2020 at 01:38:09PM +0200, Laslo Hunhold wrote:
> On Mon, 6 Apr 2020 13:27:21 +0200
> Laslo Hunhold  wrote:
>
> > I'm definitely not an expert in terminal emulators (Roberto, Hiltjo
> > and Christoph are), but the case is pretty clear to me when I look at
> > scroll[0], which Jan and Jochen are working on right now.
> > If you look at scroll.c, you can see that the tool deals pretty
> > intensely with escape codes.
>
> And just to add to this thought: Sure, scroll does not reimplement an
> entire terminal emulator, but still, what I meant is that they have to
> substantially reimplement many of the functions a terminal emulator
> has. Added to this, scroll does not yet solve the cutting off of lines
> on resize. For this, it needs to detect a terminal-resize and redraw
> the screen, adding more to complexity.
>
> We are already at 300+ LOC with scroll, and even if the changes in st
> are not merely 50-80 LOC to address the two problems I mentioned
> earlier, they sure will be below 300 LOC.
>
> With best regards
>
> Laslo
>

As you said, the coupling may be too tight to benefit from a separate
application.
Personally, I already use the scrollback patch, because some possibly
interactive applications like emerge don't like it when stdout isn't a tty.

Re: [dev] Scrollback utility for use with st

[Hadrien Lacour]

On Mon, Apr 06, 2020 at 10:40:32AM +0200, Laslo Hunhold wrote:
> On Mon, 06 Apr 2020 08:48:38 +0200
> "Silvan Jegen"  wrote:
>
> Dear Silvan,
>
> > I honestly never use tmux either. If I think I may need the output of
> > a program, I just redirect it to a file/editor/pager.
>
> yeah, same here. But how often do you get some output and think "oh, I
> actually needed that" and just re-run it? It works for 99% of the
> cases, but in this 1% it takes a bit of work to "reset" an environment
> for a second run. In both cases, you needlessly lose time.
>
> > I have been using st all this time even with those issues that I also
> > think are annoying. The workaround for the first one is to just
> > redirect output but I never found a workaround for the second issue.
> > I always have to remember to not resize the st window (or rather,
> > rearrange it in dwm) when I may still need the output.
>
> This is exactly the anti-pattern I pointed out. Given windows are not
> kept at fixed sizes in a tiling wm, st _especially_ needs to satisfy
> that it is not "affected" by resizes.
>
> > Issue 2) I would be glad to have fixed. If a patch to fix both issues
> > would only cost us 50-80 LOC, I feel it may be worth it. I am quite
> > sure there will be differing opinions on this...
>
> Yes, I would love to hear from you all what your opinion on this matter
> is.
>
> With best regards
>
> Laslo
>

If what you said is true about having to reimplement a terminal emulator
in the scrollback utility, it completely makes sense to integrate it.

Re: [dev] A simple POSIX build system

[Hadrien Lacour]

Fool that I am, I forgot to link it. Here it is:
https://git.sr.ht/~q3cpma/posix-build

[dev] A simple POSIX build system

[Hadrien Lacour]

Hello, I've made a POSIX sh/make build system in order to ditch GNU make. Its
only dependency is mktemp(1), which is available almost everywhere and can be
written in few lines of C with mkstemp(3) if not.
Here's an excerpt from the README:


For some time, I've been using GNU make with all its features to allow for some
complex operations. But after a while I noticed that GNU make was just (poorly)
trying to fuse POSIX make with sh, while not being as good as both.

So here's an almost (see Dependencies) POSIX compliant build system built on
POSIX sh and POSIX make. Here are some features it has:
* Proper install/uninstall without needing install(1) nor readlink(1) -f to
  normalize PREFIX.
* Simple runtime path rewriting for sh(1) scripts, allowing for inplace and
  installed use alike.
* A compiler flag detector.
* With the aforementioned detector, easy handling of LTO and PGO for both
  gcc and clang.
* Some more compilation variables like NATIVE and STATIC or flag presets in
  the form of CONFIG.
* Gperf and lex files handling (note: a `file.lex` or `file.gperf` is
  expected to produce a `file.c`, because SUFFIX rules don't allow for
  `file.lex.c`).
* No macro/environment mess like make, we only use the environment since
  it's a nice builtin associative array and one that is automatically
  passed to subprocesses.
* Since it's sh, it's as extensive as it should be, no need to bolt so much
  on make, and with a different syntax to boot.


If this can help other people rolling complicated makefiles, I guess it could
be nice. Criticism is welcome.


Regards,
Hadrien Lacour

Re: [dev] startup time of some interpreters

[Hadrien Lacour]

On Thu, Feb 20, 2020 at 02:24:22PM -0500, Greg Reagle wrote:
> On Thu, Feb 20, 2020, at 13:07, Hadrien Lacour wrote:
> > A much more accurate mesure of disgust is the number of syscall made for 
> > such a
> > simple task:
>
> That's very interesting, thank you.  Do you know how to write a similar test 
> for memory usage?
>
Your GNU time usage already include this, no? busybox time -v is also quite 
good.

Re: [dev] startup time of some interpreters

[Hadrien Lacour]

On Thu, Feb 20, 2020 at 12:22:53PM -0500, Greg Reagle wrote:
> Hello. I am amazed at how fast Lua is to start up and shut down. Is my 
> benchmark defective in any way? Lua seems to start up and exit faster than 
> bash, python, rc, and ksh. Dash and mksh are faster. These interpreters are 
> all packages from Debian Stable 10 "Buster".
>
> /usr/bin/time sh -c 'for i in $(seq 1 200); do dash -c "echo \"hello\""; 
> done' > /dev/null
> 0.12user 0.04system 0:00.17elapsed 97%CPU (0avgtext+0avgdata 1728maxresident)k
> 0inputs+0outputs (0major+16728minor)pagefaults 0swaps
>
> /usr/bin/time sh -c 'for i in $(seq 1 200); do mksh -c "echo \"hello\""; 
> done' >
> /dev/null
> 0.16user 0.05system 0:00.23elapsed 96%CPU (0avgtext+0avgdata 1904maxresident)k
> 0inputs+0outputs (0major+18472minor)pagefaults 0swaps
>
> /usr/bin/time sh -c 'for i in $(seq 1 200); do lua -e "print \"hello\""; 
> done' >
> /dev/null
> 0.22user 0.07system 0:00.31elapsed 97%CPU (0avgtext+0avgdata 2496maxresident)k
> 0inputs+0outputs (0major+25334minor)pagefaults 0swaps
>
> /usr/bin/time sh -c 'for i in $(seq 1 200); do bash -c "echo \"hello\""; 
> done' > /dev/null
> 0.26user 0.09system 0:00.36elapsed 96%CPU (0avgtext+0avgdata 3240maxresident)k
> 0inputs+0outputs (0major+30253minor)pagefaults 0swaps
>
> /usr/bin/time sh -c 'for i in $(seq 1 200); do ksh -c "echo \"hello\""; done' 
> > /dev/null
> 0.28user 0.14system 0:00.44elapsed 95%CPU (0avgtext+0avgdata 3888maxresident)k
> 0inputs+0outputs (0major+37146minor)pagefaults 0swaps
>
> /usr/bin/time sh -c 'for i in $(seq 1 200); do /usr/lib/plan9/bin/rc -c "echo 
> \"hello\""; done' > /dev/null
> 0.43user 0.14system 0:00.60elapsed 96%CPU (0avgtext+0avgdata 2008maxresident)k
> 0inputs+0outputs (0major+43700minor)pagefaults 0swaps
>
> /usr/bin/time sh -c 'for i in $(seq 1 200); do python -c "print \"hello\""; 
> done' > /dev/null
> 2.32user 0.88system 0:03.32elapsed 96%CPU (0avgtext+0avgdata 7220maxresident)k
> 0inputs+0outputs (0major+174760minor)pagefaults 0swaps
>

Why would it be "defective" other than sh or I/O adding time noise? lua is a
very simple language with a light reference interpreter. You should consider
tcl (through jimsh) too, I find this language way more elegant than these.

hadrien@gentoo-zen2700x> time sh -c 'for i in $(seq 1 200); do busybox ash -c 
"echo \"hello\""; done' > /dev/null
0.05s
hadrien@gentoo-zen2700x> time sh -c 'for i in $(seq 1 200); do bash -c "echo 
\"hello\""; done' > /dev/null
0.13s
hadrien@gentoo-zen2700x> time sh -c 'for i in $(seq 1 200); do python2 -c 
"print \"hello\""; done' > /dev/null
1.55s
hadrien@gentoo-zen2700x> time sh -c 'for i in $(seq 1 200); do python3 -c 
"print(\"hello\")"; done' > /dev/null
2.72s
hadrien@gentoo-zen2700x> time sh -c 'for i in $(seq 1 200); do perl -e "print 
\"hello\n\""; done' > /dev/null
0.17s
hadrien@gentoo-zen2700x> printf '%s\n' '#!/usr/bin/tclsh' 'puts hello' 
>hello.tcl
hadrien@gentoo-zen2700x> time sh -c 'for i in $(seq 1 200); do ./hello.tcl; 
done' > /dev/null
0.39s
hadrien@gentoo-zen2700x> time sh -c 'for i in $(seq 1 200); do jimsh -e "puts 
hello"; done' > /dev/null
0.18s
hadrien@gentoo-zen2700x> time sh -c 'for i in $(seq 1 200); do lua -e "print 
\"hello\""; done' > /dev/null
0.11s

What it shows is that python is slower than a dead rat and the reference tcl
could be better. Apart from that, they're all quite fast.
A much more accurate mesure of disgust is the number of syscall made for such a
simple task:

hadrien@gentoo-zen2700x> strace -fc busybox ash -c 'echo hello' 2>&1 >/dev/null 
| tail -n1 | awk '{print $3}'
26
hadrien@gentoo-zen2700x> strace -fc bash -c 'echo hello' 2>&1 >/dev/null | tail 
-n1 | awk '{print $3}'
132
hadrien@gentoo-zen2700x> strace -fc python2 -c 'print "hello"' 2>&1 >/dev/null 
| tail -n1 | awk '{print $3}'
683
hadrien@gentoo-zen2700x> strace -fc python3 -c 'print("hello")' 2>&1 >/dev/null 
| tail -n1 | awk '{print $3}'
517
hadrien@gentoo-zen2700x> strace -fc perl -e 'print("hello\n");' 2>&1 >/dev/null 
| tail -n1 | awk '{print $3}'
173
hadrien@gentoo-zen2700x> strace -fc ./hello.tcl 2>&1 >/dev/null | tail -n1 | 
awk '{print $3}'
190
hadrien@gentoo-zen2700x> strace -fc jimsh -e 'puts hello' 2>&1 >/dev/null | 
tail -n1 | awk '{print $3}'
78
hadrien@gentoo-zen2700x> strace -fc lua -e 'print "hello"' 2>&1 >/dev/null | 
tail -n1 | awk '{print $3}'
90

Speaks for itself.

Re: [dev] [no js web]

[Hadrien Lacour]

On Wed, Feb 19, 2020 at 09:56:50PM +, sylvain.bertr...@gmail.com wrote:
> Hi,
>
> As some may already know I am sueing the french administration which recently
> (a couple of years) broke the support of no js web browsers.
>
> The follow up would be to deal with this issue at the EU administration level
> and the local W3C representatives.
>
> I am currently trying to get a lawyer allocated for this, and if there are any
> french citizens among suckless aware people who would like to join the party,
> do not hesitate to get in touch with me.
>
> regards,
>
> --
> Sylvain
>

Well, good luck with it, even if you're right on the issue. Pretty sure that
Microsoft usage in schools is the same problem: mandatory proprietary shitware
paid by the taxpayers.

Personally, I was much more scared of the DSP2 directive that basically made
Google/Apple powered smartphones mandatory for online banking/shopping. Some
banks made some completely offline OTP+QRcode devices available (for a price,
"of course"), fortunately.

Re: [dev] Surf backend

[Hadrien Lacour]

On Sat, Jan 25, 2020 at 06:22:18PM +0100, Quentin Rameau wrote:
> Hi Jesse, Hadrien,
>
> > >   In regard to "replace webkit with something sane" from the TODO.md
> > > fileincluded within surf.  I'm not sure if you all are aware of this:
> > > https://github.com/SteveDeFacto/zsurf
> > > Little abandoned project in the vein of surf, but using webengine
> > > backend.
> > >
> > >   I'm a huge fan of Suckless.  Use dwm, dmenu, and st daily.  Webkit is
> > > all that stops me from using surf.  I work in web development and sadly
> > > most websites are optimised for use with webengine/blink.  I know
> > > virtually nothing about C and such.  Yet I am easily able to configure
> > > every suckless tool/utility. This is no doubt due to extensive
> > > documentation and logical configuration.  It's also nice having
> > > my config baked into the source code, as a fork. Versus having to
> > > keep track of config files.  Nor do I have to worry about pacman
> > > updating the software to be incompatible with my configurations.
> > >
> > >   Anyway, thought I'd float this out to you guys.  Might be a good
> > > starting point for surf with a webengine backend.
> > >
> > > -Jesse Limerick
> > >
> > >
> >
> > I think you're lost, mate. If you want some hints about why: webkit's
> > tar.xz is 20M while qtwebengine is 244M, one is made in C and useable in
> > C while the other is a C++ only abomination requiring Qt.
> > Don't misunderstand, though, Webkit is also horrible.
>
> While webkit is C++ too, don't be naive about that, this is true that
> the GTK port wrapper is C and this is nicer to interface with it.
>
> I don't think that even if we wanted to interface with QtWebengine,
> it's possible to build it outside the whole Qt framework.
>
> There is little to no incentive from Google to make a good C API for
> interfacing with CEF/blink/whatever and even less for having a humanly
> bearable way to build it so not much in that way either.
>
> WebkitGTK is still the less sucky backend available, but it remains an
> ugly monster.
>

Sorry, I don't know why I thought even for a moment that Webkit was C.

Re: [dev] Surf backend

[Hadrien Lacour]

On Sat, Jan 25, 2020 at 05:20:19AM -0500, Jesse Limerick wrote:
>   In regard to "replace webkit with something sane" from the TODO.md
> fileincluded within surf.  I'm not sure if you all are aware of this:
> https://github.com/SteveDeFacto/zsurf
> Little abandoned project in the vein of surf, but using webengine
> backend.
>
>   I'm a huge fan of Suckless.  Use dwm, dmenu, and st daily.  Webkit is
> all that stops me from using surf.  I work in web development and sadly
> most websites are optimised for use with webengine/blink.  I know
> virtually nothing about C and such.  Yet I am easily able to configure
> every suckless tool/utility. This is no doubt due to extensive
> documentation and logical configuration.  It's also nice having
> my config baked into the source code, as a fork. Versus having to
> keep track of config files.  Nor do I have to worry about pacman
> updating the software to be incompatible with my configurations.
>
>   Anyway, thought I'd float this out to you guys.  Might be a good
> starting point for surf with a webengine backend.
>
> -Jesse Limerick
>
>

I think you're lost, mate. If you want some hints about why: webkit's
tar.xz is 20M while qtwebengine is 244M, one is made in C and useable in
C while the other is a C++ only abomination requiring Qt.
Don't misunderstand, though, Webkit is also horrible.

The only suckless browser I can imagine is Netsurf, basically.

[dev] mus: simple album playlist music player

[Hadrien Lacour]

Hello,

some time ago, I posted about a project of mine supposed to replace mpd and its
complexity. The effort was here, but the implementation really lacked polish.
Now, though, I'm confident enough to post again since it's in a state that
could be useful to others.

The concept is simple, you have newline delimited playlist of directories
(albums), a daemon that consumes it via a simple and modular C player made with
libao and libflac/libvorbis/libopus (each one being optional at build time) and
a client to control the daemon (play, pause, next album, etc...).

There's also an optional bunch of tools to handle an album database whose
principal goal is to keep a playcount for each entry and thus provide random
picking that's still fair (i.e. random but with a forced dispersion).
This functionality is what finally decided me to abandon cmus; that and the
fact that I didn't really need the curses interface.

I tried to keep it portable, but I ended having to depend on flock(1) and chose
to use C11, GNU make and gperf for comfort; which limits the use to GNU/Linux
and the various modern BSDs.

Here's the link for those of you that are interested: 
https://git.sr.ht/~q3cpma/mus


Regards,
Hadrien Lacour

Re: [dev] [st] How do I add a keybinding to open a new ST window in the current working directory?

[Hadrien Lacour]

On Tue, Apr 23, 2019 at 04:54:17PM +0600, Enan Ajmain wrote:
> Hi,
>
> I want to add a keybinding to ST to spawn a new ST window in the
> current working directory. How do I do that?
>
> Thanks,
> Enan
>

Hello,

personally, I put
bindkey -e -s '^[t' 'st >/dev/null 2>&1 &!\n'

in my .zshrc so alt+t does exactly what you want.

Re: [dev] Preprocessor

[Hadrien Lacour]

On Tue, Apr 23, 2019 at 12:44:57PM -0700, Evan Gates wrote:
> On Tue, Apr 23, 2019 at 12:42 PM Hadrien Lacour
>  wrote:
> > That was just shitposting. I use `find` to avoid most of the UNIX 
> > braindamage
> > in this case.
>
> Which is good as long as you use -exec correctly. Or if you're going
> to use xargs make sure to use nul separated lists. Xargs without the
> nul option is broken by design.
>
Yeah, I know. Always baffled me that POSIX allows '\n' in filenames without
standardizing the various '\0' options (read -0, find -print0, xargs -0,
sed -Z, etc...).
If only ASCII FS-US had been used as intended.

Re: [dev] Preprocessor

[Hadrien Lacour]

On Tue, Apr 23, 2019 at 09:30:14AM -0700, Evan Gates wrote:
> On Tue, Apr 23, 2019 at 9:24 AM Hadrien Lacour
>  wrote:
> > What if "$1" is empty? POSIX sh doesn't have the nullglob shop, you know.
>
> [ "$1" ] || exit # add a message if you want
> [ -d "$1" ] || exit # if you want to check that the directory exists
> for p in "$1"/*; do [ -e "$p" ] || continue; ... # if you want to make
> sure the glob expanded and files exist
>
> Another option is:
>
> [ "$1" ] || exit
> set -- "$1"/*
> [ -e "$1" ] || exit
> for p do ...; done
>
> And in reality use something to print an error message, not just exit. E.g.:
>
> die() { printf %s\\n "$*" >&2; exit 1; }
> [ "$1" ] || die Argument is empty
> [ -d "$1" ] || die "Directory does not exist: $1"
>
> etc.
>

That was just shitposting. I use `find` to avoid most of the UNIX braindamage
in this case.

Re: [dev] Preprocessor

[Hadrien Lacour]

On Mon, Apr 22, 2019 at 01:35:02PM -0700, Evan Gates wrote:
> On Mon, Apr 22, 2019 at 1:25 PM Adrian Grigore
>  wrote:
> >
> > ls -1 "$1" | while IFS= read -r p
> > do
>
> Not sure about the preprocessor stuff, but this right here is terrible
> practice. Use a for loop and glob. Assuming that "$1" is a directory:
>
> for p in "$1"/*; do ...
>
> http://mywiki.wooledge.org/ParsingLs
>

What if "$1" is empty? POSIX sh doesn't have the nullglob shop, you know.

Re: [dev] Holding st after a command has completed

[Hadrien Lacour]

On Sun, Apr 14, 2019 at 03:24:34AM +0300, Ivan "Rambius" Ivanov wrote:
> Hello,
>
> The st terminal has -e option that executes a specific command instead
> of the shell. However, st closes immediately after the command has
> completed. Is it possible to hold the st's window after the command
> has finished? That is similar to xterm's -hold command.
>
> Thank you for your responses in advance.
>
> Regards
> rambius
>
> --
> Tangra Mega Rock: http://www.radiotangra.com
>

The usual way of doing this is
$ st -e sh -c 'ls; exec sh'

Re: [dev] [dmenu] 4.9 release messes with input focus

[Hadrien Lacour]

Same on bspwm, here.

Re: [dev] [Announce] [dwm-6.2] [dmenu-4.9] new release

[Hadrien Lacour]

Does that mean that some kind of simple fallback mechanism will be implemented?
A bit like Lemonbar allowing to specify multiple X fonts.

Re: [dev] Web development in C (or, C'ing clearly through the webs of bias)

[Hadrien Lacour]

Your very mail is bloated, mate. Did you really need all of this to tell "back
up your claims"?

Re: [dev] Let's talk about Go, baby

[Hadrien Lacour]

How do you reconcile love of minimalism with the big added runtime complexity
of a garbage collector (when you need to support multithreading and balance
latency, throughput and memory usage)?

Personally, I think that a high level language that can easily interact with a
low level one is a good solution; that's why I'm currently leaning toward C +
sh and/or TCL.

Re: [dev] [dmenu] running shell scripts in dmenu

[Hadrien Lacour]

I had similar problems before (I use startx to start X). They vanished when I
put `export PATH=$HOME/bin:$PATH` in my .xinitrc in addition to my .zshenv.

[dev] [slock] not multibyte aware, right?

[Hadrien Lacour]

Hello,

I'm trying to make slock work with a french keyboard and the character £, but
after reading the source, am I correct in saying that it doesn't support
multibyte encodings? l179-180 of slock.c makes me think so.

Mentioning it in the README would be quite useful.

Regards,
Hadrien Lacour

Re: [dev] Re: mus - A simple album playlist based music player

[Hadrien Lacour]

On Thu, Nov 15, 2018 at 03:29:14PM -0800, Andy Valencia wrote:
> > I've just finished a simple project of mine to replace cmus with something a
> > bit more UNIXy and I think it could interest some people.
> I wrestled with various ways of conveniently playing my music,
> and eventually came up with:
>
> http://sources.vsta.org:7100/wplayer
>
> You run it on the server with all your tracks (my own collection runs
> around 200k files, flac/mp3/ogg), and then you just point your web
> browser at wplayer running on your server.  Both Firefox and Chrome
> support flac/mp3/ogg, but if you're tight on bandwidth you can add
> "?noflac" to the URL and it'll transcode flac to ogg as you play
> files.
>
> Andy
>

It is a more complete and flexible solution than mine, but certainly more
complex and demanding as far as dependencies goes (python, HTTP server). It
also is more conventional in its approach, with a tag db created at startup.

This is something I wanted to avoid, because cmus scanning my collection during
my machine startup made my HGST HDD produce death throes like noises.

[dev] mus - A simple album playlist based music player

[Hadrien Lacour]

Hello,

I've just finished a simple project of mine to replace cmus with something a
bit more UNIXy and I think it could interest some people.

Here's the link: https://repo.or.cz/mus.git with an excerpt from the README:

+--+
| Overview  
   |
|   
   |
|   
   |
| A well designed and easy to modify music player I made for myself. It only
   |
| supports FLAC and GNU/Linux, out of the box.  
   |
|   
   |
| Formed of three independant parts:
   |
| * mus_server.sh:  play albums from a playlist and answer commands from 
the   |
|   client  
   |
| * mus_client.sh:  send commands to the server and receive its answers 
   |
|   read or modify the playlist based on stdin  
   |
| * mus_album-*:fairly pick random albums (see fair_shuf/README)
   |
|   
   |
| A lemonbar status script can be found at 
https://repo.or.cz/q3cpma-lemonbar.git. |
+--+

The main drawbacks for now are that it's Linux only because it depends on flock
(there's a more portable version at [1]) and inotify (could be replaced either
by [2] or a simple polling loop).


[1] https://github.com/discoteq/flock
[2] https://github.com/emcrisostomo/fswatch

Re: [dev] GPL free Linux

[Hadrien Lacour]

> > On 12 Nov 2018, at 05:28, Markus Wichmann  wrote:
> Please, do tell if you find such a library. The ones I found were either
> the wrong language (Tk, Qt, FLTK), or hopelessly obtuse (gtk). Or pretty
> much no assistance at all (xaw, motif).

I never used it, but someone showed xforms (http://xforms-toolkit.org/) to me
and it looks nice.

Re: [dev] GPL free Linux

[Hadrien Lacour]

On Mon, Nov 12, 2018 at 11:25:44AM +, Alessandro Pistocchi wrote:
>
>
> > On 12 Nov 2018, at 10:05, Hadrien Lacour  wrote:
> >
> > On Sun, Nov 11, 2018 at 09:43:12PM -0700, Anthony J. Bentley wrote:
> >> Markus Wichmann writes:
> >>> Why would you do something so pointless? First of all, licences only
> >>> matter if you plan on redistribution, so most here won't care. Second,
> >>> all the GPL demands is that you distribute the source, which any good
> >>> distribution should do, anyway, right?
> >>
> >> GPL also demands that you not combine the code with GPL-incompatible
> >> terms, even if those terms are free themselves. A ridiculous requirement
> >> that violates the spirit and practice of free software.
> >>
> >
> > Even if this discussion is pointless, I'll humour the list; attacking the
> > methods and not the goal (which is to eradicate proprietary software) 
> > without
> > proposing an alternative methode is at best fallacious.
> >
> > On the other hand, I'd like to ask why would someone use a non copylefted
> > license? Almost all the time (especially for applications, not libraries), 
> > the
> > main reason is intellectual masturbation, not a concrete goal like GPL's 
> > one.
> >
>
> I think I wrote I am ok with GPL applications ( and in fact I am using them ).
>
> I just want people to be able to do proprietary software no questions asked.
>
> Some of my users may not know anything about copyleft and do stuff that is 
> wrong without knowing it and I don’t want this to happen to them.
>
>

Then you're honest, at least. GPL (and copyleft in general) is indeed for those
who despise proprietary software and will exert some effort to at least try to
remove it (that obviously includes not allowing them to use your applications).

Re: [dev] GPL free Linux

[Hadrien Lacour]

On Sun, Nov 11, 2018 at 09:43:12PM -0700, Anthony J. Bentley wrote:
> Markus Wichmann writes:
> > Why would you do something so pointless? First of all, licences only
> > matter if you plan on redistribution, so most here won't care. Second,
> > all the GPL demands is that you distribute the source, which any good
> > distribution should do, anyway, right?
>
> GPL also demands that you not combine the code with GPL-incompatible
> terms, even if those terms are free themselves. A ridiculous requirement
> that violates the spirit and practice of free software.
>

Even if this discussion is pointless, I'll humour the list; attacking the
methods and not the goal (which is to eradicate proprietary software) without
proposing an alternative methode is at best fallacious.

On the other hand, I'd like to ask why would someone use a non copylefted
license? Almost all the time (especially for applications, not libraries), the
main reason is intellectual masturbation, not a concrete goal like GPL's one.

Re: [dev] freetype2/fc pain

[Hadrien Lacour]

On Mon, Sep 24, 2018 at 04:08:17PM +, sylvain.bertr...@gmail.com wrote:
> On Mon, Sep 24, 2018 at 05:44:40PM +0200, Hadrien Lacour wrote:
> > Of course, the range:font mapping is more granular, but I find it a little 
> > bit
> > more complex to configure than this type of fallback.
>
> It does as some asian fonts do contain some latin glyphs. You have to specify
> the unicode range, or to be sure the x11 font names have orthogonal encoding 
> fields.
> To prepare such font list, you may have to split font files per
> encoding/unicode range, something like that.
>
> --
> Sylvain
>
>

Then you put your latin font first, since those usually don't contain CJK
characters. The only case where it could gives problems is if you don't want
fallback but really a merger of your fonts: e.g. using Terminus but wanting a
different font for cyrilic.

But yeah, I'm in favor of the range scheme, since it solves more problems and
may make the implementation cleaner. If there are alphabet aliases or comments
concerning common ranges in the config file, it should be pretty easy to use.

Re: [dev] freetype2/fc pain

[Hadrien Lacour]

Couldn't this be done like rxvt-unicode (or the current st fontarray patch)? You
specify a list of fonts, and the program iterates on it until it finds one that
provide the required character. With a very basic cache, it's pretty simple and
doesn't causes problems.

Of course, the range:font mapping is more granular, but I find it a little bit
more complex to configure than this type of fallback.

Re: [dev] [makes] release version 2.0

[Hadrien Lacour]

On Sun, Aug 12, 2018 at 03:58:29PM +0100, ra...@airmail.cc wrote:
> Hello!
>
> This post is an announcement releasing makes version 2.0.
>
> makes is a minimal build tool that cleanly separates the user interface from
> the core algorithm that actually performs the build. It supports
> incremental, parallel builds with dependency resolution.
>
> makes takes on standard input a tab separated values stream of 'build rules'
> with the following format:  \t  \t ... -- .
> These TSV build scripts can be generated using a shell script, python
> script, a new build UI tool, anything.
>
> The tool has been proven by building jq and sbase with it. It can also be
> seen as a generalization of gnu parallel, sabotage jobflow this was tested
> by converting a directory tree of flacs to mp3s.
>
> The repo is here: https://github.com/rain-1/makes
> and some example uses can be found here:
> https://gist.github.com/rain-1/f3434f4b12147d5ef62369e511a184de
>
> Justification for a new build tool: makes improves upon POSIX make and other
> build systems like waf, cmake, meson etc. in several ways. Unlike make it
> does not require reimplementation of an incompatible version of shell
> language. It is also implemented in 1/1000th the amount of code. Unlike make
> which tries to do everything and falls short (resulting in stuff like
> automake, autoconf, ./configure, etc.), it fulfills the UNIX philosophy of
> doing one thing well by separating concerns. By using an incredible simple
> TSV input format it gives programmers complete freedom and power to specify
> builds using any toolkit they wish, m4, shell, python.
>

This looks like a ninja (or samurai) replacement, not really a make one. Looks
nice, but when reading your examples, you use #!/bin/sh with stuff like arrays,
you should set to something more approriate.

Re: [dev] [st] Some tmux trouble

[Hadrien Lacour]

On Sun, Dec 31, 2017 at 01:50:50PM -0800, Eric Pruitt wrote:
> On Sun, Dec 31, 2017 at 10:15:24PM +0100, Hadrien Lacour wrote:
> > I'm trying to do
> > `st -e "tmux a -t cmus"`
>
> Use `st -e tmux -a -t cmus` as documented in st(1) which reads "-e
> command [arguments...]".
>
> Eric
>

Thanks, I didn't notice this particularity.

[dev] [st] Some tmux trouble

[Hadrien Lacour]

Hello,

I'm trying to do
`st -e "tmux a -t cmus"`

but it only gives me `child finished with error '256'`.

* `tmux a -t cmus` works perfectly in an already open st.
* `st -e tmux` works fine (there's an `erresc: unknown private set/reset mode
1005` message, though).
* `tmux new -A -s dash -d dash; st -e "tmux a -t dash"` fails (the problem isn't
in cmus).
* xterm works in both cases.


Tested with 0.7 and git.

Re: [dev] [dwm] Fonts from dwm screenshots

[Hadrien Lacour]

On Sun, Dec 24, 2017 at 03:11:57AM -0200, Guilherme Vieira wrote:
> I'm looking for a good terminal font, with no anti-aliasing /
> smoothing non-sense. I'm also looking for a nice compatible icon set,
> and the one from the following screenshots looks just perfect:
>
> https://dwm.suckless.org/screenshots/dwm-20120806.png
> https://dwm.suckless.org/screenshots/dwm-20101101.png
>
> Does anyone know where I can find them, as well as their license information?
>
> Thanks,
> G.
>

It's probably Terminus (http://terminus-font.sourceforge.net/) aka The one
bitmap font to rule them all.

Re: [dev] [dmenu] doesnt open apps

[Hadrien Lacour]

On Wed, Dec 20, 2017 at 10:37:37AM -0600, Jorge Ga wrote:
> the commands i used:
> ~ dmenu
> (search for any app)
> - hit enter
> - nothing happens
>
> Same result for hit i3 dmenu shortcut (mod+d), dwm shortcut and execute dmenu:
>
> dmenu /usr/bin/dmenu_run
>
> 2017-12-20 10:28 GMT-06:00 Hadrien Lacour <hadrien.lac...@posteo.net>:
> > On Wed, Dec 20, 2017 at 10:19:48AM -0600, Jorge Ga wrote:
> >> OS: Debian 9 WM: i3
> >> When i open dmenu (mod+d on i3) i can search any app, but when i try
> >> to open, it just don't open.
> >> I try to debug the commands using i3 debug mode but i'm kinda lost,
> >> also i find on some arch linux post that maybe the fonts can be an
> >> issue (i have custom fonts on debian) but i don't know if thats the
> >> problem.
> >> I have the same version of i3 and suckless tools on an Ubuntu machine
> >> and works great.
> >> I hope you can help me, i dont want to reinstall another distro.
> >>
> >
> > The first thing to do, in this case, is to run it in a terminal emulator. Is
> > there no output at all? Anyway, I doubt this is a dmenu bug.
> >
>

Have you tried dmenu_run or dmenu_path?

Re: [dev] [dmenu] doesnt open apps

[Hadrien Lacour]

On Wed, Dec 20, 2017 at 10:19:48AM -0600, Jorge Ga wrote:
> OS: Debian 9 WM: i3
> When i open dmenu (mod+d on i3) i can search any app, but when i try
> to open, it just don't open.
> I try to debug the commands using i3 debug mode but i'm kinda lost,
> also i find on some arch linux post that maybe the fonts can be an
> issue (i have custom fonts on debian) but i don't know if thats the
> problem.
> I have the same version of i3 and suckless tools on an Ubuntu machine
> and works great.
> I hope you can help me, i dont want to reinstall another distro.
>

The first thing to do, in this case, is to run it in a terminal emulator. Is
there no output at all? Anyway, I doubt this is a dmenu bug.

Re: [dev] Writing subtitles for videos

[Hadrien Lacour]

On Tue, Oct 24, 2017 at 03:48:28PM +, Thomas Levine wrote:
> I settled on the following mpv configuration.
> https://thomaslevine.com/scm/langrompiloj/artifact/6a086022d93af1a1
> https://thomaslevine.com/scm/langrompiloj/artifact/161b62d352fec4f7
>
> This produces a file like the one below, which I edit until the
> subtitles are acceptably timed. Each line marks the beginning of the
> next cue and the end of the previous cue.
> https://thomaslevine.com/scm/langrompiloj/artifact/49ddb891f1f0b6fd
>
> Texts for the subtitles are stored in other files, one file per
> language. These files have one line per cue, so they have one fewer
> line than the corresponding timings file.
> https://thomaslevine.com/scm/langrompiloj/artifact/f01066b80ae8fe3b
> https://thomaslevine.com/scm/langrompiloj/artifact/cf93e6b1b7967053
>
> I then produce a WebVTT file for each combination of a timing file and
> language.
>
> Thank you for everyone's input
>
> Hadrien Lacour writes:
> > It may be possible to do this with mpv and lua scripts.
>

Thanks for reporting back, I'm sure this'll help a lot.

Re: [dev] [st] Start with text already input

[Hadrien Lacour]

On Fri, Sep 15, 2017 at 09:24:55PM +, Eric Pruitt wrote:
> On Fri, Sep 15, 2017 at 09:41:32PM +0200, Hadrien Lacour wrote:
> > I basically wanted a way to open a terminal with the beginning of a
> > command ("pass -c " in my case) already typed.
> >
> > I finally settled for the dmenu integration, but this still could be
> > useful. I'll probably have better chance with xdotool.
>
> The only method I'm aware of for pushing characters to a terminal
> requires using ioctl, and I think (but am not certain) this only works
> if the process in question is the session leader. In C, this looks like
> "ioctl(tty, TIOCSTI, data)" where "tty" is a file descriptor for the
> terminal. Maybe you could create a wrapper program that uses ioctl to
> push bytes into the input buffer then spawns a shell.
>
> Eric
>

Thanks, it works perfectly. Too bad termios doesn't seem to make this possible.
Also, understandably, it only works on the current tty (probably what you meant
by "session leader").

Re: [dev] [st] Start with text already input

[Hadrien Lacour]

On Fri, Sep 15, 2017 at 07:24:51PM +, Kamil Cholewiński wrote:
> echo 'echo mytext' >> .zshrc
>
> P.S. please remove "in-reply-to" headers when starting a new thread
>

Yeah, sorry. Just noticed. Your solution isn't "input" text, it's just
displayed. I basically wanted a way to open a terminal with the beginning of
a command ("pass -c " in my case) already typed.

I finally settled for the dmenu integration, but this still could be useful.
I'll probably have better chance with xdotool.

[dev] [st] Start with text already input

[Hadrien Lacour]

Hello,

I'm trying to do what the subject says but I have some troubles. Maybe someone
already have a solution. Here's what I tried:

#!/bin/sh

tty=$(mktemp)
st -e sh -c "tty >\"$tty\"; exec \"$SHELL\""
sleep 1
printf 'mytext' >"$(cat "$tty")"
rm -- "$tty"

I get the text, but the shell (zsh here) doesn't "detect" it (I can't go back,
delete it or get completion). Any idea?

Re: [dev] [st] font fallback

[Hadrien Lacour]

On Sun, Sep 03, 2017 at 10:06:35AM -0700, Eric Pruitt wrote:
> On Sun, Sep 03, 2017 at 06:31:44PM +0200, Hadrien Lacour wrote:
> > I see, thanks. Don't know why I thought it was like this. Well, I'll try it
> > but fontconfig is indeed a big pain in the ass (editing XML is never fun).
>
> If you don't mind running an older revision of st (or porting my changes
> to a newer release), you can use my patch:
> https://github.com/ericpruitt/edge/blob/master/patches/st-00-font-array-support.diff
>
> Eric
>

Thanks, if it doesn't patch cleanly, I'll probably try to port it (the
advantages of minimalist software).

Re: [dev] [st] font fallback

[Hadrien Lacour]

On Sun, Sep 03, 2017 at 06:24:13PM +0200, Quentin Rameau wrote:
> > Hello,
>
> Hello Hadrien,
>
> > I'm trying view Japanese text but I don't manage to. Here's what I do
> > with urxvt (it works):
> > $ urxvt -fn "xft:xos4 Terminus:size=12,xft:Misc Fixed:size=11"
> >
> > with st (it doesn't; I get blank spaces or squares):
> > $ st -f "xos4 Terminus:size=12,Misc Fixed Wide:size=11"
> >
> > Am I doing something wrong?
>
> As you can read in config.h, the string is called “font”, not “fonts”.
> And so, st doesn't work with fallback fonts, this is something
> fontconfig should do for you, there is the configuration to make.
>
> Until further progress on replacing this bloated font management.
>
> — Quentin
>

I see, thanks. Don't know why I thought it was like this. Well, I'll try it
but fontconfig is indeed a big pain in the ass (editing XML is never fun).

[dev] [st] font fallback

[Hadrien Lacour]

Hello,

I'm trying view Japanese text but I don't manage to. Here's what I do with
urxvt (it works):
$ urxvt -fn "xft:xos4 Terminus:size=12,xft:Misc Fixed:size=11"

with st (it doesn't; I get blank spaces or squares):
$ st -f "xos4 Terminus:size=12,Misc Fixed Wide:size=11"

Am I doing something wrong?


(with st-0.7 and rxvt-unicode-9.22-r1 on Gentoo)

Re: [dev] Writing subtitles for videos

[Hadrien Lacour]

On Thu, Aug 31, 2017 at 08:04:26AM +, Thomas Levine wrote:
> I want to write some subtitles for some videos. I found several subtitle
> editors through web searches, and their documentation doesn't make them
> look very good. What's more, I haven't managed to install any of them
> properly, which is both inconvenient and further indicative of suck.
>
> I think that most of what I want could be accomplished by having a video
> player that writes the current time somewhere (like a file) when I press
> a particular key. I would play the video until I get to the position
> where I want to start or stop a subtitle, then I would press the key,
> and then I would copy that time to the subtitles file.
>
> Another helpful feature would be to reload the subtitles file without
> changing the current time; this way I could review the subtitles more
> quickly.
>
> Do any video players already do this? Or, does anyone have other
> recommendations about the editing of subtitles?
>

It may be possible to do this with mpv and lua scripts.

Re: [dev] less(1) replacement?

[Hadrien Lacour]

On Sun, Aug 27, 2017 at 03:47:52AM +0200, isabella parakiss wrote:
> On 8/27/17, Laslo Hunhold  wrote:
> > On Sat, 26 Aug 2017 23:59:27 +0200
> > isabella parakiss  wrote:
> >
> > Hey Isabella,
> >
> >> https://i.imgur.com/79U7mcO.png
> >> side by side screenshot against less
> >> your face looks hideous
> >
> > he did not mean the interface, but the code itself. And I personally
> > concur that this rather belongs to the uglier realm of bash-scripts.
> > Please refrain from personal insults.
> >
> > It's impressive how it has been made, but I'm sure "native" solutions
> > in C or other compiled languages should be preferred. Paging is not a
> > too difficult thing to solve, if I may make this statement.
> >
> > With best regards
> >
> > Laslo
> >
> > --
> > Laslo Hunhold 
> >
> >
>
>
> cool, let me just rewrite it in c++
> or in javascript and then create a native solution with electron
>
>
> name 3 reasons why compiled languages should be preferred, but of course
> performance can't be in your list
>
>
> also it's funny that you talk about personal insults after your rape threats
> go fuck a cactus
>

The point of using a compiled language is to avoid useless dependencies, even
if performances also count.
To be honest, it'd be more acceptable if it didn't rely on the most bloated
shell ever (baring fish, maybe). POSIX sh isn't that hard.

Re: [dev][all] Migrating build system

[Hadrien Lacour]

On Sat, Apr 01, 2017 at 10:26:33AM +0100, Joseph Graham wrote:
> On Sat, Apr 01, 2017 at 02:46:36PM +0530, Aditya Goturu wrote:
> > As we know, the greatest weakness of suckless apps is their dependence on 
> > bloated build systems like make.
> > 
> > I tried porting to to gnu autotools, but while it helped, it still needed 
> > work.
> > 
> > I am proposing we migrate to visual studio as our build system immediately. 
> > We must also start reimplementing some parts in modern languages like C# or 
> > Java.
> > 
> > I also propose we stop using this mailing list immediately and move to a 
> > better communication platform like Microsoft Exchange and that we replace 
> > IRC with slack.
> > 
> > Thanks
> > Aditya
> > 
> 
> What?
> 
> -- 
> Joseph Graham, techno-philosopher and Free Software advocate. 
> 
> I have a blog: http://www.naughtycomputer.uk/
> I write software: https://www.suckmore.uk/
> I run a web forum: https://www.freesoftwareuk.org.uk/
> And a platform for Free Software success stories: 
> http://www.freedcomputer.net/
> 

Date: Sat, 1 Apr 2017 14:46:36 +0530

Re: [dev] looking for a simple music player

[Hadrien Lacour]

On Thu, Feb 09, 2017 at 07:56:42PM +0100, Cág  wrote:
> Hadrien Lacour wrote:
> 
> > If you want the Noice of music player, there's cplay. If you want something 
> > a
> > little bit more like ranger/vifm, there's cmus. I personally use mpd and mpc
> > with sh scripts.
> 
> Looks like cplay is Python and doesn't support flac players. Looks good 
> though,
> thanks.
> 
> --
> Cág
> 

It is indeed python, but it seems okay to use it for such a simple (script)
job. It looks like cplay can use mplayer or sox; I think those support flac.

Re: [dev] looking for a simple music player

[Hadrien Lacour]

On Tue, Feb 07, 2017 at 08:25:02PM +0100, Cág  wrote:
> Hi,
> 
> I'm looking for something that looks like noice when I'm in my music
> folder: basically a list of file names and the current song's name and
> length at the bottom. No need for colours and album/year; ideally 
> it'd be customised by  editing config.h. Maybe mplayer, ffmpeg
> or gstreamer based.
> 
> Is there something like that?
> 
> Thanks
> 
> --
> Cág
> 

If you want the Noice of music player, there's cplay. If you want something a
little bit more like ranger/vifm, there's cmus. I personally use mpd and mpc
with sh scripts.

Re: [dev] surf crash

[Hadrien Lacour]

On Tue, Jan 17, 2017 at 06:41:02AM -0800, Greg Minshall wrote:
> Cág,
> 
> > Okay, try re-installing webkit, both -dev and
> > the package. I'm not really sure what's the
> > problem.
> 
> no change, sigh.  i guess i'll just leave this "open" for the time
> being.
> 
> > By the way, if you are an ex-BSD user, you may
> > want to try Alpine[1]. Stripped; elegant package
> > management; no systemd, dbus, GNU etc.; you
> > can also pull the ports, but packages are
> > usually compiled the way they should be. And
> > the documentation is pretty good.
> 
> thanks for the pointer.  it would be nice running a system that i've
> built from the sources.  though i'm not sure Alpine is really designed
> with that in mind; maybe gentoo is reasonable (sort of "digging" for
> suggestions here)?
> 
> cheers, Greg
> 

Gentoo is indeed your best bet. Portage is pretty complex, though. Then you
have the old school distros like Crux/Sourcemage, but they're less active.
Really, USE flags are amazing.

Re: [dev] [st/dwm] Alt-Shift-C and Mod1-Shift-C

[Hadrien Lacour]

On Thu, Jan 12, 2017 at 07:25:06PM +0100, Patrick Bucher wrote:
> Hi there,
> 
> I'm using st and dwm at the same time, and today I discovered a little problem
> when using the default config of both programs. st uses Alt-Shift-C to copy 
> text
> into the clipboard, dwm uses Mod1-Shift-C for closing the selected window,
> whereas Mod1 is Alt by default, at least on my machine. (Maybe some of you use
> Super_L, vulgo "the Windows key".)
> 
> So guess what happened when I was trying to copy some code into the clipboard
> today ;-)
> 
> How do you deal with that?
> 
> Thanks for suggestions,
> Patrick
> 
> PS: Anybody using Arch Linux here? Since the fontconfig update today st no
> longer works with my font of choice Terminus. Just in case somebody has the 
> same
> problem... here's my font[] definition:
> 
> static char font[] = 
> "Terminus:pixelsize=24:antialias=true:autohint=true:lang=ru";
> 

This bug report seems related https://bugs.gentoo.org/show_bug.cgi?id=605168

Re: [dev] Request for name suggestions: suckless video editor

[Hadrien Lacour]

So this is a bit like Vapoursynth?

Re: [dev] Re: [st] Crash on middle finger character

[Hadrien Lacour]

On Sun, Dec 18, 2016 at 03:19:11PM +, Amadeusz Żołnowski wrote:
> I have forgot to attach the "utftest1.txt" file. Sorry. Here it goes.
> 
> Cheers,
> -- Amadeusz Żołnowski



> REVERSED HAND WITH MIDDLE FINGER EXTENDED: 

Actually, I tried using "Terminus:pixelsize=16" (on gentoo too), and it
automatically fallbacks to Unifont. Really no problemo here.

Re: [dev] Re: [st] Crash on middle finger character

[Hadrien Lacour]

On Sun, Dec 18, 2016 at 03:19:11PM +, Amadeusz Żołnowski wrote:
> I have forgot to attach the "utftest1.txt" file. Sorry. Here it goes.
> 
> Cheers,
> -- Amadeusz Żołnowski



> REVERSED HAND WITH MIDDLE FINGER EXTENDED: 

Work here. Using GNU Unifont and st-0.7

Re: [dev] Collecting sins of Apple

[Hadrien LACOUR]

While this can seem relatively unimportant to some, the use of proprietary
screws (Pentalobe) really does sum up Apple's stance toward its client base.

Re: [dev] Djvu viewer

[Hadrien LACOUR]

On Tue, 13 Sep 2016 18:14:25 +0100, Cág wrote:
>[0]: http://repo.or.cz/fbpdf.git

Thanks, it seems acceptable. Even if it'd be better if mupdf could do djvu 
(but I'm daydreaming here).

On Tue, Sep 13, 2016 at 10:46:58PM +0300, ilab...@gmail.com wrote:
> Why would you want to do this? It makes some sense to save new scans to
> DjVu because the format is simplier, but converting one lossy format to
> another lossy format is not a good idea.
> 

Well, because of the massive compression improvements, and because I prefer
free stuff.

[dev] Djvu viewer

[Hadrien LACOUR]

Hello,

I'm becoming interested in converting all my PDFs to Djvu, but I don't
seem to find a relatively not bloated viewer (like Mupdf). Looked at
zathura-djvu, djview and apvlv. They all require some sort of toolkit
(Qt or gtk+3) and even the dbus cancer.

Any recommendation?

Re: [dev] Never Ending Systemd Chronicles

[Hadrien LACOUR]

On Fri, Aug 05, 2016 at 08:26:42AM -0300, Marc Collin wrote:
> I got introduced to s6-rc [0] lately.
> Do you guys have any experience with it?
> 
> [0] http://skarnet.org/software/s6-rc/
>

When I compared daemontools, runit and this one, I thought it was the best.
Nice comparison: http://skarnet.org/software/s6-rc/why.html

Re: [dev] Never Ending Systemd Chronicles

[Hadrien LACOUR]

On Fri, Aug 05, 2016 at 11:58:25AM +0200, FRIGN wrote:
> 
> Of course, runit is only a service manager. But runit+sinit+misc is a
> whole other story.
> 
> Cheers
> 
> FRIGN
> 
> -- 
> FRIGN 
> 

What? I'm pretty sure runit can do init.

As for the systemd controversy, I used for a long time on Arch and it 
wasn't that bad from a end user point. But when you had to modify or write
unit files, it wasn't fun. Even if most of the vocabulary is simple, the
number of keywords is simply too high; while a shell script can be understood
by anybody.
In the end, I'm now happy with Gentoo and OpenRC. Especially nice to see
that it'll be soon usable with something else than sysvinit.

Re: [dev] JWM on website

[hadrien . lacour]

I'd say cwm instead of evilwm. When I had to use an ant screen laptop, it was 
pretty nice. The only thing I lacked is workspaces.

On Wed, Aug 03, 2016 at 07:25:56AM +1000, Timothy Rice wrote:
> Hi Pat,
> 
> > http://incise.org/not-so-tiny-window-managers.html
> 
> On that list I see evilwm. Apparently it is stacking, and if I'm not
> mistaken it appears to have a similar size to dwm (maybe even smaller).
> 
> So why propose JWM instead of EvilWM?
> 
> 
> ~ Tim
> 

Re: [dev] [st] Latest git - Nano with syntax highlighting strange bug

[hadrien . lacour]

On Mon, Jul 18, 2016 at 10:07:36AM -0400, Greg Reagle wrote:
> On Sun, Jul 17, 2016 at 10:45:10PM +0200, hadrien.lac...@openmailbox.org 
> wrote:
> > I've recently changed from urxvt to st and noticed a bug when using nano 
> > which will be easier to describe with a short gif: 
> > https://a.cocaine.ninja/xtlajf.gif
> > This issue happens ONLY when I change "static unsigned int tabspaces" from 
> > 8 to 4 in the config file.
> 
> I cannot see the gif:  "can't establish a connection to the server at 
> a.cocaine.ninja"
> 
> What happens when you leave tabspaces alone and call nano with "-T4"?
> 
That's what I'm doing now (tabsize 4 in the rc) and it works perfectly. Here's 
the video https://a.desu.sh/xqqufs.mp4 (fucking pomf clones dying every day)

Re: [dev] [st] Latest git - Nano with syntax highlighting strange bug

[hadrien . lacour]

On Sun, Jul 17, 2016 at 03:41:07PM -0700, Eric Pruitt wrote:
> On Mon, Jul 18, 2016 at 12:30:45AM +0200, hadrien.lac...@openmailbox.org 
> wrote:
> > The problem might be hard to reproduce, so here's a simpler one
> > https://a.cocaine.ninja/jihcdl.gif
> 
> I tried that, and it also didn't give my any issues. I don't have any
> other ideas of what it could be; sorry. If you haven't tried this
> already, consider pulling the git repo and compile st yourself without
> using the ebuild at all.
> 
> Eric
> 
That's how I tested it, actually. Tried everything. Tried again with tabspaces 
= 6, and the problem is different but still here.
I'm trying with nano 2.5.3 if it helps. I'll try to see on the Gentoo 
bugtracker.

Thanks for the help.

Re: [dev] [st] Latest git - Nano with syntax highlighting strange bug

[hadrien . lacour]

On Mon, Jul 18, 2016 at 12:23:22AM +0200, hadrien.lac...@openmailbox.org wrote:
> On Mon, Jul 18, 2016 at 12:04:22AM +0200, hadrien.lac...@openmailbox.org 
> wrote:
> > On Sun, Jul 17, 2016 at 02:22:00PM -0700, Eric Pruitt wrote:
> > > On Sun, Jul 17, 2016 at 10:45:10PM +0200, hadrien.lac...@openmailbox.org 
> > > wrote:
> > > > I've recently changed from urxvt to st and noticed a bug when using nano
> > > > which will be easier to describe with a short gif:
> > > > https://a.cocaine.ninja/xtlajf.gif
> > > > This issue happens ONLY when I change "static unsigned int tabspaces" 
> > > > from 8
> > > > to 4 in the config file.
> > > 
> > > I wasn't able to reproduce this. Did you compile the st termcap file,
> > > are you overriding the TERM environment variable, and are you using a
> > > multiplexer like tmux, screen or dvtm?
> > > 
> > > Eric
> > > 
> > No I didn't compile it (using the gentoo st- ebuild). I'm using 
> > ncurses-6.0, but I indeed read that the terminfo file was outdated. TERM 
> > isn't overriden, no multiplexer is used.
> > 
> 
> I tried with the git termcap too (ran mv 
> /usr/share/terminfo/s/st-256color{,.bak} then tic -s st.info) and the problem 
> still exists.
> 
The problem might be hard to reproduce, so here's a simpler one 
https://a.cocaine.ninja/jihcdl.gif

Re: [dev] [st] Latest git - Nano with syntax highlighting strange bug

[hadrien . lacour]

On Mon, Jul 18, 2016 at 12:04:22AM +0200, hadrien.lac...@openmailbox.org wrote:
> On Sun, Jul 17, 2016 at 02:22:00PM -0700, Eric Pruitt wrote:
> > On Sun, Jul 17, 2016 at 10:45:10PM +0200, hadrien.lac...@openmailbox.org 
> > wrote:
> > > I've recently changed from urxvt to st and noticed a bug when using nano
> > > which will be easier to describe with a short gif:
> > > https://a.cocaine.ninja/xtlajf.gif
> > > This issue happens ONLY when I change "static unsigned int tabspaces" 
> > > from 8
> > > to 4 in the config file.
> > 
> > I wasn't able to reproduce this. Did you compile the st termcap file,
> > are you overriding the TERM environment variable, and are you using a
> > multiplexer like tmux, screen or dvtm?
> > 
> > Eric
> > 
> No I didn't compile it (using the gentoo st- ebuild). I'm using 
> ncurses-6.0, but I indeed read that the terminfo file was outdated. TERM 
> isn't overriden, no multiplexer is used.
> 

I tried with the git termcap too (ran mv 
/usr/share/terminfo/s/st-256color{,.bak} then tic -s st.info) and the problem 
still exists.

Re: [dev] [st] Latest git - Nano with syntax highlighting strange bug

[hadrien . lacour]

On Sun, Jul 17, 2016 at 02:22:00PM -0700, Eric Pruitt wrote:
> On Sun, Jul 17, 2016 at 10:45:10PM +0200, hadrien.lac...@openmailbox.org 
> wrote:
> > I've recently changed from urxvt to st and noticed a bug when using nano
> > which will be easier to describe with a short gif:
> > https://a.cocaine.ninja/xtlajf.gif
> > This issue happens ONLY when I change "static unsigned int tabspaces" from 8
> > to 4 in the config file.
> 
> I wasn't able to reproduce this. Did you compile the st termcap file,
> are you overriding the TERM environment variable, and are you using a
> multiplexer like tmux, screen or dvtm?
> 
> Eric
> 
No I didn't compile it (using the gentoo st- ebuild). I'm using 
ncurses-6.0, but I indeed read that the terminfo file was outdated. TERM isn't 
overriden, no multiplexer is used.

[dev] [st] Latest git - Nano with syntax highlighting strange bug

[hadrien . lacour]

Hello,

I've recently changed from urxvt to st and noticed a bug when using nano which 
will be easier to describe with a short gif: https://a.cocaine.ninja/xtlajf.gif
This issue happens ONLY when I change "static unsigned int tabspaces" from 8 to 
4 in the config file.