#481 Sending email: runtime error: invalid memory address or nil pointer dereference 3 years ago

Comment by ~y0ast on ~sircmpwn/aerc2

Are you on master or latest release? Master just had some changes in send, so it could be that you're hitting those.

Do you use IMAP?

#271 Bug in url parsing in markdown 4 years ago

on ~sircmpwn/sr.ht

REPORTED RESOLVED FIXED

#271 Bug in url parsing in markdown 4 years ago

Ticket created by ~y0ast on ~sircmpwn/sr.ht

The following markdown:

[~sircmpwn/aerc@lists.sr.ht](https://lists.sr.ht/~sircmpwn/aerc).

Is parsed into this HTML:

<a href="https://lists.sr.ht/~sircmpwn/aerc" rel="nofollow
noopener"></a><a href="mailto:~sircmpwn/aerc@lists.sr.ht" rel="nofollow
noopener">~sircmpwn/aerc@lists.sr.ht</a>.</p>

While I expected this:

<a href="https://lists.sr.ht/~sircmpwn/aerc" rel="nofollow
noopener">~sircmpwn/aerc@lists.sr.ht</a>.</p>

It seems the parser forces the email to be a url based on its shape, while also adding the markdown url and getting into a weird final state. The expected behavior would be to not parse the email if it's part of a markdown url.

Example: https://git.sr.ht/~sircmpwn/aerc/tree/master/README.md

The markdown is parsed here for reference: https://git.sr.ht/~sircmpwn/core.sr.ht/tree/master/srht/markdown.py

Drew asked me to ping ~araspik, but I am not sure if just mentioning is enough.

#397 SEGFAULT in aerc/widgets.(*MessageList).Draw 4 years ago

Comment by ~y0ast on ~sircmpwn/aerc2

I hit this too and submitted the relevant patch: https://lists.sr.ht/~sircmpwn/aerc/patches/14540

I got it when quickly switching between two loading folders.

#416 aerc's :term doesn't seem to support high/true color, some text decorations 4 years ago

Comment by ~y0ast on ~sircmpwn/aerc2

I just submitted a patch that fixes truecolor detection by updating tcell: https://lists.sr.ht/~sircmpwn/aerc/patches/11972

Curious to hear if it works for you and perhaps fixes your other problems too!

#115 #text and #img ignored 4 years ago

Comment by ~y0ast on ~scoopta/wofi

Without a config file and only

#window {
    background-color: red;
}

#text {
margin: 5px;
border: 2px solid cyan;
background-color: cyan;
}

as css, and calling wofi using wofi --show drun:

The bg to the window is applied, but text styling is ignored.

I was able to fix my original problem using:

#entry image {
    padding-right 5px;
}

so image works, but not #img.

#115 #text and #img ignored 4 years ago

Ticket created by ~y0ast on ~scoopta/wofi

I tried to change some css and found that #text and #img are ignored.

e.g. using the example from https://cloudninja.pw/docs/wofi.html does not lead to the text having a cyan background:

#text {
margin: 5px;
border: 2px solid cyan;
background-color: cyan;
}

Further any padding/margin on #img does not work. (The new hidpi icon support looks great however!)

On wofi 1.2.

#416 aerc's :term doesn't seem to support high/true color, some text decorations 4 years ago

Comment by ~y0ast on ~sircmpwn/aerc2

Hmm, so it seems aerc depends on a custom tcell fork: https://git.sr.ht/~sircmpwn/aerc/tree/master/go.mod#L48

And it seems Drew reverted a specific commit to support $COLORTERM (which I believe is what is most often used to verify truecolor support):

https://git.sr.ht/~sircmpwn/tcell/commit/1f7dcc6382865d9b65b422e3c5f13d0ed1c12329

fish gets really unhappy if I start using TERM=xterm-truecolor aerc, so it would be very helpful if aerc would depend on the original tcell, instead of the custom fork.

#99 Icons look blurry on hidpi screen with scale 2 4 years ago

Comment by ~y0ast on ~scoopta/wofi

Thanks for getting back so quickly!

I was able to set image_size and the higher resolution icons get picked up fine, the trouble is that they're of course rendered much larger.

So ideally, wofi would pick up higher resolution icons depending on dpi, and render them sharp without changing the size on screen.

#99 Icons look blurry on hidpi screen with scale 2 4 years ago

Ticket created by ~y0ast on ~scoopta/wofi

When running wofi with:

wofi --show drun -i -I

On a scaled output (4k at 2x), the program icons look a bit fuzzy. If I run the same command on a non-scaled output, they look fine so the high res version is available. It seems like wofi is manually downsampling them instead of picking up the right icon.