~sbinet

France

Particle physicist turned software engineer

~sbinet/star-tex

Last active 28 days ago

~sbinet/go-hep

Last active 4 months ago

~sbinet/star-tex-patches

Last active 6 months ago
View more

Recent activity

Re: introduce the "trash" command 24 days ago

From Sebastien Binet to ~sircmpwn/aerc

On Fri Sep 3, 2021 at 09:32 CET, Moritz Poldrack wrote:
> Right now - at least to me - it sounds like changing the default
> behaviour of :move inside the message view would be the easiest
> solution, but I'd prefer to see the patch first.

sent.
another avenue could be to add an option to :delete.
(but it was easier for me to just copy-paste the code of :delete and
rebrand it as :trash with the expected behaviour)

>
> > You can configure :archive to stick things in the [Trash] folder, using
> > `archive` in accounts.conf. It might make sense to be able to configure
> > multiple archive directories, but I don't think we need a separate

Re: introduce the "trash" command 24 days ago

From Sebastien Binet to ~sircmpwn/aerc

On Fri Sep 3, 2021 at 09:15 CET, Moritz Poldrack wrote:
> > in my aerc tree, I have introduced a new command: :trash.
> > it's somewhat similar to the :delete one, except it moves the (list of)
> > email(s) under the [Trash] folder.
> sooo... something like :move Trash ?
>
> > I initially wrote a binding to do this but I didn't find a way to make
> > it behave the same than the :delete command (where it moves to the next
> > message afterwards).
> :move Trash selects the next message afterwards

not when viewing the message.
when in the "message viewer" mode, displaying a given message, 
':move Trash' will dutifully move that message to [Trash] but will go

Re: introduce the "trash" command 24 days ago

From Sebastien Binet to ~sircmpwn/aerc

On Fri Sep 3, 2021 at 09:08 CET, Eyal Sawady wrote:
> On Fri Sep 3, 2021 at 7:05 AM UTC, Sebastien Binet wrote:
> > in my aerc tree, I have introduced a new command: :trash.
> > it's somewhat similar to the :delete one, except it moves the (list of)
> > email(s) under the [Trash] folder.
>
> This sounds to me like :archive

not exactly.
:trash is for messages I don't think I will need but "well, better stash
them in the [Trash] folder just in case, although it's ok if the garbage
collector gets rid of them at some point".

well, it's a bit like ":archive flat", but not quite.

introduce the "trash" command 24 days ago

From Sebastien Binet to ~sircmpwn/aerc

hi there,

in my aerc tree, I have introduced a new command: :trash.
it's somewhat similar to the :delete one, except it moves the (list of)
email(s) under the [Trash] folder.

I initially wrote a binding to do this but I didn't find a way to make
it behave the same than the :delete command (where it moves to the next
message afterwards).

would there be interest in providing it to aerc proper?

cheers,
-s

[ANN] star-tex v0.2.0 & v0.3.0 28 days ago

From Sebastien Binet to ~sbinet/star-tex

hi there,

long time no see...
It's a quick announcement about 2 releases for star-tex:

- v0.2.0: the first pure-Go release of star-tex
- v0.3.0: the first release with the beginning of a dvi package.

`v0.2.0` had been cut back in March 2021 (but I kind of forgot to
announce it).
`v0.3.0` is a smaller release: I had intended to cut it when the
`dvipdf` and/or `dvipng` commands were ready.
it turns out it's still quite a long way (one would need either a fully
working implementation of `PK fonts` or of `Type 1 fonts`.)

meta: sr.ht+Gio+code coverage 29 days ago

From Sebastien Binet to ~eliasnaur/gio

hi there,

I am slowly migrating most of my dev. presence from GitHub to SourceHut.
in the context of Go projects -and without falling to the pitfall of
governance (only) by metrics- I have been used to setup a code coverage
action as part of my CI.

On GitHub, it's quite easy to set that up.

I noticed Gio doesn't seem to use code coverage and I was wondering
whether that was because:

- it's in effect quite hard for a GUI project,
- it's difficult within SourceHut (and if so, what did you try and what

Re: handling of 2 "regular" key.Event 2 months ago

From Sebastien Binet to ~eliasnaur/gio

Chris,

On Thu Jul 1, 2021 at 18:57 CET, Chris Waldon wrote:
> Hi Sebastien,
>
> I've modified the Gio hello example to do what I think you're asking for
> here:
>
> https://play.golang.org/p/B7aUDQOcIGX
>
> Try running this program and then holding down multiple arrow keys at
> the same time. Watch its log output.
>
> A problem that I had to solve was the fact that key repeat was

handling of 2 "regular" key.Event 2 months ago

From Sebastien Binet to ~eliasnaur/gio

hi,

I am (still) using "gioui.org v0.0.0-20210308172011-57750fc8a0a6"
(because $REASON which can be dealt with elsewhere).

I am unsure whether this is a supported use case but I am trying to
implement this example with go-p5:

- https://p5js.org/reference/#/p5/keyIsDown

ie: trying to make the "ball" navigate diagonally, by noticing when 2
"regular" keys are pressed together (e.g.: key.NameLeftArrow and
key.NameDownArrow, trying to navigate SW).

display number of unread emails in account title 2 months ago

From Sebastien Binet to ~sircmpwn/aerc

hi there,

I have multiple accounts setup with Aerc and it's working great
(thanks).

I have one little axe to grind though: it would be great if (optionally?)
the account title could be decorated with the number of unread emails
available for that account in the top-level bar.

say:

```
accnt-1 (3) | accnt-2 | accnt-3 (+100)
```

Re: updating contacts list when sending a message 3 months ago

From Sebastien Binet to ~sircmpwn/aerc

On Sun Jun 6, 2021 at 12:14 CET, Sebastien Binet wrote:
> hi there,
>
> I am trying to automatically update my contacts' list when replying to
> an email (triggering the parsing of the message for its recipients and
> sending that list of recipients to my CardDAV server).
>
> reading through the various aerc man pages, I didn't notice anything
> related to this, only a 'new-email' trigger.
> did I miss something?
>
> reading through the send-mail code (commands/compose/send.go), I guess a
> possible avenue to do such a thing is to write a separate command, say
> `~/bin/mta`, that would forward the bytes written to its STDIN to both