hi Ralph,

On Thu Jan 23, 2025 at 22:04 CET, Ralph Seichter wrote:
> * Sebastien Binet:
>
>> haven't used it (yet), but when researching for this kind of use case,
>> I've stumbled upon this: https://www.muchsync.org/
>
> I used Muchsync for about a year and found it helpful. I only stopped
> using it when I decided to no longer keep maildir stores across multiple
> machines, not because there was anything wrong with Muchsync.

thanks for the input.

hi there,

On Thu Jan 23, 2025 at 07:08 CET, Jason Cox wrote:
> On Wed Jan 22, 2025 at 11:09 PM EST, Io SDB wrote:
>> Recently, I ran mbsync and received this error:
>>
>> 'Unable to recover from UIDVALIDITY change.'
>
> Sorry to hear that you're having trouble with mbsync. I've found success
> in the past via the isync mailing list, either by searching the archives
> or sending a new message:
>
> https://sourceforge.net/p/isync/mailman/isync-devel/
>

hi Jan,

On Fri Nov 15, 2024 at 17:30 CET, Jan Mercl wrote:
> Hi Sebastien,
>
> At 723afeea,
> https://git.sr.ht/~sbinet/star-tex/tree/main/item/font/fixed/int12_20.go#L33
> and
> https://git.sr.ht/~sbinet/star-tex/tree/main/item/font/fixed/int16_16.go#L31
> there are conversions from float64 to a type based on uint32, ie. an
> unsigned type. Those conversions are not guaranteed to work when the
> number is out of range for the target type, but it is CPU-specific. On
> linux/arm it seems the CPU conversion instruction converts negative
> float64 values to uint32(0) and the test fails, see

Hi Jan,

On Sun Sep 8, 2024 at 00:38 CET, Jan Mercl wrote:
> Hi Sebastien.
>
> staticcheck noticed this:
> https://git.sr.ht/~sbinet/star-tex/tree/main/item/cmd/dvi-cnv/png.go#L68
>
> I'm not able to figure out if the value of the computation should be
> used somehow or if it is perhaps some leftover from a debug session or
> something else.

thanks for the hint.
done. (hard for me as well, it's been a long time)

Hello Patricio,

(apologies for the belated answer, I was off the grid for the better part of the summer)

On Sun Aug 4, 2024 at 23:38 CET, Patricio Diaz wrote:
> I'm trying to use start-tex (v0.4) to parse this formula
> `$x_{n+1}=x_{n}-\frac{f(x_{n})}{f'(x_{n})}$` but it fails with
> ```
> This is TeX, Version 3.141592653 (INITEX)
> **(output.tex
> (TeXinputs:plain.tex Preloading the plain format: codes, registers,
> parameters, fonts, more fonts, macros, math definitions, output
> routines,
> hyphenation (TeXinputs:hyphen.tex))

hi there,

right now, in Go, to import and use a package hosted on SourceHut, one needs to write:

```go
import "git.sr.ht/~user/repo"
```

this works because the needed metadata information used by the Go tool is present:

```sh
$> curl https://git.sr.ht/~sbinet/peertube |& grep meta
<meta charset="utf-8"/>
<meta content="width=device-width, initial-scale=1" name="viewport"/>

On Wed Feb 14, 2024 at 14:24 CET, inwit wrote:
>
>
> On 17/01/2024, 11:59, Robin Jarry wrote:
> > Sebastien Binet <s@sbinet.org> wrote:
> > > use the currently selected message part (if any) as the original message
> > > for quote-reply and forward.
> > > honor viewer::alternatives if no message part was selected.
>
> Is there a way to disable this behaviour, at least for attachments? It
> is kinda annoying when you reply to a message while an attachment is
> selected and this attachment it's a binary file of some sort... I'd have
> expected a flag in the reply/forward commands. Sorry for not pointing
> this out while the patch was being reviewed.

On Wed Feb 14, 2024 at 16:24 CET, Bence Ferdinandy wrote:
>
> On Wed Feb 14, 2024 at 15:02, Sebastien Binet <s@sbinet.org> wrote:
> > Modify getMessagePart to only return selected message part if it
> > isn't an attachment, to prevent accidentally quoting a (possibly)
> > binary attachment file.
> >
>
> Can't we detect instead if it is a binary file? I actually see the merit in
> replying to say an attached README.md. Although in that case you might need
> parts of text/html as well ... For that you probably need to pipe the message
> part to your clipboard and insert in the composer.

is there any agreed upon criteria for deciding a file is binary ?

On Wed Feb 14, 2024 at 14:24 CET, inwit wrote:
>
>
> On 17/01/2024, 11:59, Robin Jarry wrote:
> > Sebastien Binet <s@sbinet.org> wrote:
> > > use the currently selected message part (if any) as the original message
> > > for quote-reply and forward.
> > > honor viewer::alternatives if no message part was selected.
>
> Is there a way to disable this behaviour, at least for attachments? It
> is kinda annoying when you reply to a message while an attachment is
> selected and this attachment it's a binary file of some sort... I'd have
> expected a flag in the reply/forward commands. Sorry for not pointing
> this out while the patch was being reviewed.

Modify getMessagePart to only return selected message part if it
isn't an attachment, to prevent accidentally quoting a (possibly)
binary attachment file.

Signed-off-by: Sebastien Binet <s@sbinet.org>
---
 commands/msg/utils.go | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/commands/msg/utils.go b/commands/msg/utils.go
index d6dffd50..022e79bf 100644
--- a/commands/msg/utils.go
+++ b/commands/msg/utils.go
@@ -63,7 +63,8 @@ func (h *helper) messages() ([]*models.MessageInfo, error) {
[message trimmed]