(#rj7o6zq) @kat@yarn.girlonthemoon.xyz On the one hand, all these programs have a very long history and the technology behind manpages is actually very powerful – you can use it to write books:

https://www.troff.org/pubs.html

I have two books from that list, for example “The UNIX programming environment”:

https://movq.de/v/c3dab75c97/upe.jpg

It’s a bit older, of course, but it looks and feels like a normal book, and it uses the same tech as manpages – which I think is really cool. 😎

It’s comparable to LaTeX (just harder/different to use) but much faster than LaTeX. You can also do stuff like render manpages as a PDF (man -Tpdf cp >cp.pdf) or as an HTML file (man -Thtml cp >cp.html). I think I once made slides for a talk this way.

On the other hand, traditional manpages (i.e., ones that are not written in mandoc) do not use semantic markup. They literally say, “this text is bold, that text over here is italics”, and so on.

So when you run man foo, it has no other choice but to show it in black, white, bold, underline – showing it in color would be wrong, because that’s not what the source code of that manpage says.

Colorizing them is a hack, to be honest. You’re not meant to do this. (The devs actually broke this by accident recently. They themselves aren’t really aware that people use colors.)

If mandoc and semantic markup was more commonly used, I think it would be easier to convince the devs to add proper customizable colors.


#bsyxsjq

(#c3afgma) There is a missing feature I’ve been intending to add to though, which is that any link that looks like a URL that might be an image, for example, ends with .png or .jpg or whatever, we should just render that as an image and not expect users to wrap it in Markdown image links ![](...)


#uvxddyq

(#rj7o6zq) @lyse@lyse.isobeef.org @kat@yarn.girlonthemoon.xyz Colorized manpages have been a thing for a very long time:

https://movq.de/v/81219d7f7a/s.png

Problem is, hardly anybody knows this, because you configure this by … drumroll … overwriting TERMCAP entries of less in your ~/.bashrc:

export LESS_TERMCAP_md=$'\e[38;5;3m'      # Bold
    export LESS_TERMCAP_me=$'\e[0m'           # End Bold
export LESS_TERMCAP_us=$'\e[4;38;5;6m'    # Underline
    export LESS_TERMCAP_ue=$'\e[0m'           # End Underline
export GROFF_NO_SGR=1                     # Needed since groff 1.23

#gixfeuq

(#6u6yutq) @kat@yarn.girlonthemoon.xyz @movq@www.uninformativ.de Sorry, I neither finished it nor in time. :-( That’s as good as it’s gonna get for the moment: https://git.isobeef.org/lyse/gelbariab/-/tree/master/rss-proxys?ref_type=heads

The README should hopefully provide a crude introduction. The example configuration file is documented fairly well, I believe (but maybe not). You probably still have to consult and maybe also modify the source code to fit your needs.

Let me know if you run into issues, have questions, wishes etc.


#jqicbha

Why is it that I hate packing so badly? I gotta have to brace myself up to start that now.

The outlook is poor, rain all the way until maybe the last day of summer camp. Definitely bringing my gummies, they are well needed, the weather report announces several days with up to 14 liters per square meter.


#rftfysq

In 1996, they came up with the X11 “SECURITY” extension:

https://www.reddit.com/r/linux/comments/4w548u/what_is_up_with_the_x11_security_extension/

This is what could have (eventually) solved the security issues that we’re currently seeing with X11. Those issues are cited as one of the reasons for switching to Wayland.

That extension never took off. The person on reddit wonders why – I think it’s simple: Containers and sandboxes weren’t a thing in 1996. It hardly mattered if X11 was “insecure”. If you could run an X11 client, you probably already had access to the machine and could just do all kinds of other nasty things.

Today, sandboxing is a thing. Today, this matters.

I’ve heard so many times that “X11 is beyond fixable, it’s hopeless.” I don’t believe that. I believe that these problems are solveable with X11 and some devs have said “yeah, we could have kept working on it”. It’s that people don’t want to do it:

Why not extend the X server?

Because for the first time we have a realistic chance of not having to do that.

https://wayland.freedesktop.org/faq.html

I’m not in a position to judge the devs. Maybe the X.Org code really is so bad that you want to run away, screaming in horror. I don’t know.

But all this was a choice. I don’t buy the argument that we never would have gotten rid of things like core fonts.

All the toolkits and programs had to be ported to Wayland. A huge, still unfinished effort. If that was an acceptable thing to do, then it would have been acceptable to make an “X12” that keeps all the good things about X11, remains compatible where feasible, eliminates the problems, and requires some clients to be adjusted. (You could have still made “X11X12” like “XWayland” for actual legacy programs.)


#2t3kgxa

(#u53cqtq) I wasn’t really aware until recently that programs can’t choose their own window’s position on Wayland. This is very weird to me, because this was not an issue on X11 to begin with: X11 programs can request a certain position and size, but the X11 WM ultimately decides if that request is being honored or not. And users can configure that.

But apparently, this whole thing is a heated debate in the Wayland world. 🤔


#3sxza4q