Block / Report User
If this user/feed is violating this Pod's (twtxt.net) community guidelines as set out in the Abuse Policy, please report them immediately!
You are also free to Unfollow or Mute this user or feed. Muting will also remove that user/feed's content from your view and you will no longer see content from that user/feed anywhere.
@movq does not follow you (they may not see your replies!)
Recent twts from movq
Ist mir auch eben erst klar geworden: Die Uhu-Webcam (hab’ ich vor einiger Zeit mal verlinkt) war im … Ahrtal. Und da war doch was mit Unwetterkatastrophe. Ohweh. https://uhu.webcam.pixtura.de/das-ahrtal-ist-nicht-mehr-so-wie-wir-es-kannten/
I love how my Android phone unironically tells me: “Please restart your device. Your device has not been restarted for 28 days. We e …” (Yes, it ends with “we e …” and I have no idea how to show the full message.) Really? So they haven given up and don’t even try anymore to make software that, well, works?
@firstname.lastname@example.org (#wkjlotq) Fixing old entries is tricky and I wouldn’t do it. If you change something in an old twt, it will change its hash sum – and thus, it will break threading if someone has replied to your old twt or otherweise referenced it. 😵
(#wkjlotq) Should be fixed on jenny’s
main now. 🥳
Right now, jenny sometimes has to make up those URLs, because there simply is no cross-platform way of creating them. URLs like
https://twtxt.net/search?tag=gjt7pqa only exist on yarn.social, but there’s no equivalent on my web site … so, yeah, that’s probably where those bad links are coming from.
I guess we should update https://dev.twtxt.net/doc/twtsubjectextension.html accordingly. (Or maybe there’s a PR already, haven’t checked.)
Interesting idea. 🤔
This is a key factor:
Such an upcycling will be possible with the manufacturers obligation to publish a device’s underlying source code under a Free Software licence at the end of support for any software necessary to run or modify the initial functioning of the device.
A device’s source code isn’t worth anything if it depends on, say, a proprietary compiler.
A similar loop hole for manufacturers: They could add pointless complexity to their build system. “Sure, here’s the source code for iOS. Have fun building it! You only need to perform these 13 million steps: …”
Or design the build system in such a way that it’s impossible for most people to perform because of their hardware: Just put it enough effort for the build to require 128 GB of RAM and you’re good.
Alright, I think I like it. I pushed the changes. FYI @email@example.com
That’s enough changes for now. I’ll let things settle for a while, fix bugs (if we’re finding any), maybe add some more tests, and then go for a new release. 🥳
Speaking of Vim: It might be a good idea to write a twtxt syntax highlighting file, which extends the markdown one. 🤔 But then again, the currently used “mail” syntax highlighting is not that bad either, and it get’s nested quoting right:
Experimenting with “replace all newlines by U+2028 when writing twts”.
- This is a list.
- This is another item on the list.
And then she said:
Look, a tree!
It’s not that bad. 🤔 I just have to set my Vim to not do hard line-wrapping in jenny postings (which it does by default for all plain text files). So I now have this in my
au BufRead,BufNewFile jenny-posting.eml call SetForumWrapping()
It’s nice, but this should be required by law, really. (Nothing stops Pine from becoming “evil” in the future or getting bought by an “evil” company. And then we’re back to square one with unrepairable phones.)
At first, there was only “reply” in jenny. Then you introduced “fork”, so I added that method. 😁 But there is no default, really. The example mutt config just installs two hotkeys and it’s up to the user which one to press.
I’m not sure which model is better, to be honest. 🤔
btw, jenny does not pre-fill mentions of all the people in the conversation. When you hit “reply” (or “fork”), you only get a mention of the person you’re replying to. I think that’s actually a little bit better, because those “mass-mentions” can get a bit noisy. 🤔 I regularly see mentions of my nick, but the person really was talking to someone else. I just happened to be “in the loop”. (Reminds me a bit of business e-mail. 🤣)
@firstname.lastname@example.org (#vnoddea) Oh yeah, this is so annoying on Arch. I guess there’s a lot of historical baggage … There is some attempt to fix this situation by providing an “alternatives” mechanism, it seems: https://wiki.archlinux.org/title/User:Allan/Alternatives But it’s still very much “work in progress”.
I can relate to this video so much: https://youtu.be/KjYBh7rq0-Y No more programming for me today. 🎸
Why @email@example.com saw dups: gopher://uninformativ.de/0/phlog/2021-10⁄2021-10-15–python-open-locale.txt So let’s try to be more strict with encodings: https://www.uninformativ.de/git/jenny/commit/6477e2edbbcde4936ce825e7cc73449922cf2e0e.html
@firstname.lastname@example.org (#74lxfha) Yeah, I get what you mean (I think). So jenny should probably simply replace all newlines with a U+2028. 🤔 That would require some more changes, but maybe it’s the cleanest solution. I’ll think about this.
does with this.
New paragraph, hopefully?
@email@example.com (#44nacmq) Not a bug. All lines starting with “> ” are stripped. (This is done to remove the quoted stuff that is initially appended at the bottom when you reply to a twt.) What you’re writing here is not Markdown, it’s just “text”. The only special processing that jenny does now is that multi-paragraph thingy. (This is in contrast with yarn.social, which renders everything as Markdown, I think?)
@firstname.lastname@example.org (#juoezea) There was a time (after the Perl era) when everbody built their own web site … in PHP, with MySQL. 🤣 What a mess. The good thing about static web site generators is that they’re harmless. You can’t screw this up. You can’t accidentally introduce SQL injections or make PHP read sensitive files or whatever. I love static web stuff. 👌
(#zrg4luq) … hmmm. I can force everything to be UTF-8, that’s not a problem. But that means that your entire software stack must be capable of handling UTF-8 (editor, terminal, …). And at that point why not just require the user to use an UTF-8 locale? 🤔
(#zrg4luq) The test suite breaks horribly with en_US.ISO-8859-1. Not only do the tests fail, but the test framework is broken as well. 🤣
@email@example.com (#65k6uvq) It does make sense, yeah. (I got used to reading flat conversations when the microblog that we used at work no longer supported threading. But I remember, back then, I was pretty pissed. 🤣)
@firstname.lastname@example.org (#zrg4luq) Gah, I finally understood what’s going on here. The point is that you were using a non-UTF-8 locale (one with latin1, apparently) – I kept trying to reproduce it with
LANG unset or
LANG=C, which is different. And that made Python decode strings using latin1, which of course results in garbage. This is clearly a bug, jenny shouldn’t break with non-UTF-8 locales.
I wonder how all the heavy “conversation forking” lately affects usability on yarn.social 🤣 https://movq.de/v/ec4cdd7174/s.png
@email@example.com (#4uyx3kq) Technically, it’s possible. The thing is just that I have hard-wrapping turned on by default in my Vim and there’s newlines all over the place. 🥴 This is a screenshot of me writing this twt: https://movq.de/v/5977722c48/s.png I’ll think about it. 🤔 (I’d rather not introduce new config options for this, though.)
@firstname.lastname@example.org (#pe5ymoa) Hmmmm, good idea, but it already does that: https://www.uninformativ.de/git/jenny/file/jenny.html#l219 🤔
@email@example.com (#yc6iika) Rendering them was already supported, so the diff for composing them is not that big: https://www.uninformativ.de/git/jenny/commit/4a02eeec58317107c07e759733312d168e319f17.html 😊
(#br6vghq) I mean, hey, mutt is already optimized to handle lots and lots of e-mails. Had I written all this myself, it might be quite a bit slower. 🤣
@firstname.lastname@example.org (#pe5ymoa) Alright, I can’t tell when I’ll be able to do a screen sharing thingy. So let’s try this the old-fashioned way first. Please try to reproduce the issue with the branch
quark-trace that I pushed recently. It’ll create a /tmp/jenny.log file (it will get large). When you see duplicate twts, try to find them in that log.
Reasons, in theory, why we could see dups:
1) jenny doesn’t detect your feed’s URL correctly.
2) python-dateutil doesn’t parse your twt’s timestamp correctly. Or rather, it parses it differently depending on some env vars? Cronjobs often have this pitfall where some env var is different than your normal environment.
Actually … I can’t think of anything else. 🤔 You don’t see dups all the time, it only happens for your own twts, and you said that the twt hash mismatches. That already narrows it down to something in make_twt_hash(). 🤔
Let’s see if that trace file helps. If it doesn’t, we can add more trace() calls.