On Tue Dec 3, 2024 at 7:51 PM CET, Ploum wrote:
>
> There’s no parsing of the content of pages in Offpunk. But there’s a way 
> to do what you want (and I’m doing it every day).
>
> Create a list "decemberadventure":  list create decemberadventure
>
> Add the capsules/pages you want to follow in it.
>
> Now, every day after the sync, you can do:
>
> "tour decemberadventure"  (use the autocompletion)
>
>

Hey there,

Right now is #DecemberAdventure, a sort of counter-event to the
performance-inducing, competition-oriented #AdventOfCode. Here are some details:

https://eli.li/december-adventure-2

Basically, you just write a few lines of code for pleasure, for exploring
something new, for fun. Something you'd do the rest of the year, but dedicate
some time now. No pressure, no objective, no goal, just curiosity.

I'd like to see the updates made by participants on their page. However they
all add new content to the existing page rather than creating a new page for
each day.

On Fri Nov 29, 2024 at 9:08 AM CET, Ploum wrote:
 
> [I] think it would be better server on an exeternal ressource.

Yeah, since the tour list is just a file with links, you can create a random.sh
script that will fetch the random links and write the tour file

Ploum <sourcehut24@ploum.eu> wrote:
> Testing is welcome!


Awesome ! It works exactly as expected. I love where this is going.

Here are a few quirks I came into:

- when using an invalid "index", offpunk crashes:

```
ON> open sanothue
Traceback (most recent call last):
  File "/usr/lib/python3.12/site-packages/offpunk.py", line 1052, in do_open

Hello there,

Currently the workflow for images or third-party resources is a bit cumbersome
if images are not supported in the terminal:

- exit view mode
- open image url, which shows nothing
- use "open" to open in the handler, or "open url" to open in the browser
- use "back" to go back to the page

This is because "open" only works on the current page. Is it possible to make
it work on a target page, like tour ? Something like `open 3 6-10` to open all
the links directly via their url for example.

Ploum <sourcehut24@ploum.eu> wrote:
> If someone is on those platforms, don’t hesitate to tell him about 
> Offpunk and ask him what is plans are for PWR. I would be very 
> interested to get in touch.

The code is on github, so I guess if you still have an account you can start a
discussion there (although I'd love to see the discussion happen in this
mailing-list)

-- 
Matthieu Rakotojaona

Hey there,

I just came across this page that describes a terminal web reader that seems to be architectured around the same ideas as offpunk's tour along with its offline mode:

https://muxup.com/pwr

It looks like offpunk is more "advanced" but I thought it was interesting that other people had the same need.

-- 
Matthieu Rakotojaona

Hey :)

Conrad Hoffmann <ch@bitfehler.net> wrote:
> I'll take a closer look sometime, but for now I have decided that I no 
> longer want to work with Maildir, and am busy porting all my tooling to 
> m2dir [1] (full disclosure: which I made up myself).

I actually discovered vomit because I stumbled upon m2dir first, and I quite
like the idea although the migration path is probably a bit too long for me
right now. I'll also keep an eye on that though because it's interesting :)

-- 
Matthieu Rakotojaona

Hey there,

I stumbled upon your project and am happy to find someone else is fixated on handling mail directly from the terminal. In my different searches I stumbled upon mblaze at https://github.com/leahneukirchen/mblaze. Are you familiar with it ? There seems to be some use cases that overlap.

It enabled me to build my own MUA in ~300 lines of different scripting over at https://sr.ht/~rakoo/omail/. The code is probably a mess, but it's a small mess and it's my mess so I can still understand it.

In any case I'll happily what you're doing over here :)

-- 
Matthieu Rakotojaona

Simon Ser <contact@emersion.fr> wrote:
> Yeah, I think so. Maybe there's an opportunity to simplify some code here,
> by introducing a function which matches exactly a text/* MIME type without any
> fallback logic like:
> 
>     func (msg *IMAPMessage) inlineTextPart(subtype string) *IMAPPartNode
> 
> And then using that to implement TextPart and HTMLPart, e.g.
> 
>     if part := msg.inlineTextPart("plain"); part != nil {
>         return part
>     }
>     return msg.inlineTextPart("html")