Last active 4 months ago


Last active 5 months ago


Last active 6 months ago
View more

Recent activity

Re: Discussion: Replying to specified message part (plain|html) 2 days ago

From Ben Burwell to ~sircmpwn/aerc

Hi Leszek,

> if you imagine that we will parse markdown to HTML version ... it is quite
> easy to implement and useful for business email.

Someone replied to me off-list and described a pre-processing script they use
with mutt to add a HTML version to their messages. So, I suppose there may be
some interest in doing this, though I don't really understand the use case (and
don't want to derail the thread).

> I just done two simple things:
> * exposed OriginalMIMEType to template, so you can write (pseudocode):
> if html do this else that
> * added exec function, so you can call anything you want, chain it,

Re: Discussion: Replying to specified message part (plain|html) 2 days ago

From Ben Burwell to ~sircmpwn/aerc

> - if I reply from msglist plain text version is used as quotation
> source, if not available html version would be used,

In this case I think we should use the alternatives list, as we do for
deciding which part to show by default in the msgviewer:

> - if I reply from msgview selected part in switcher is used as
> quotation source.

Makes sense.

> - Make preferred mail version configurable in aerc.conf.
> IMO: noone would preferre html version so unnecessary.

Re: [PATCH aerc] fix quote, add stopAt, exec, provide IsHTML 3 days ago

From Ben Burwell to ~sircmpwn/aerc

On Mon Dec 9, 2019 at 10:33 AM, Leszek CimaƂa wrote:
> BTW: sorry for lame question, but I am spoiled by github ... Should I
> send just diff patch, or should I send whole patch again as v2?

Diffs between patch versions are hard to keep track of, so if you need
to update your patch before it has been applied, just send a v2.

Also, I'm not sure exactly how you're sending your patches, but note
that the content of your email before the patch becomes the commit
message in the git log, so it's not necessary to include
greetings/signatures in those messages. If you do want to add some
context for your patch that will not go into the commit message, you can
use the "timely commentary" section to do so, see
https://git-send-email.io/#step-4 for how to do this.

[PATCH v3 4/4] Add address book completion in composer 8 days ago

From Ben Burwell to ~sircmpwn/aerc

Complete email address fields in the message composer with an external
address book command, compatible with mutt's query_cmd.
 completer/completer.go | 138 +++++++++++++++++++++++++++++++++++++++++
 config/aerc.conf.in    |  12 ++++
 config/config.go       |   5 +-
 doc/aerc-config.5.scd  |  16 +++++
 widgets/compose.go     |  23 ++++++-
 5 files changed, 189 insertions(+), 5 deletions(-)
 create mode 100644 completer/completer.go

diff --git a/completer/completer.go b/completer/completer.go
new file mode 100644
index 0000000..4d1aafe
[message trimmed]

[PATCH v3 3/4] Don't use current input as a possible completion 8 days ago

From Ben Burwell to ~sircmpwn/aerc

Now that completions are being shown in the popover, it doesn't make
sense to show the unfinished command as a potential completion.
 aerc.go | 1 -
 1 file changed, 1 deletion(-)

diff --git a/aerc.go b/aerc.go
index e8944d7..028cc6a 100644
--- a/aerc.go
+++ b/aerc.go
@@ -78,7 +78,6 @@ func getCompletions(aerc *widgets.Aerc, cmd string) []string {
 	for _, set := range getCommands((*aerc).SelectedTab()) {
 		completions = append(completions, set.GetCompletions(aerc, cmd)...)
[message trimmed]

[PATCH v3 2/4] Show textinput completions in popovers 8 days ago

From Ben Burwell to ~sircmpwn/aerc

Rather than showing completions inline in the text input, show them in a
popover which can be scrolled by repeatedly pressing the tab key. The
selected completion can be executed by pressing enter.
 config/aerc.conf.in   |  11 +++
 config/config.go      |  35 ++++---
 doc/aerc-config.5.scd |  10 ++
 lib/ui/textinput.go   | 219 ++++++++++++++++++++++++++++++++----------
 widgets/aerc.go       |   4 +-
 widgets/exline.go     |  15 ++-
 6 files changed, 223 insertions(+), 71 deletions(-)

diff --git a/config/aerc.conf.in b/config/aerc.conf.in
index 16e3da1..660a525 100644
[message trimmed]

[PATCH v3 1/4] Add popovers 8 days ago

From Ben Burwell to ~sircmpwn/aerc

A popover is a special UI element which can be layered over the rest of
the UI (i.e. it is painted last) and can fall anywhere on the screen,
not just with the bounds of its parent's viewport/context. With these
special abilities comes the restriction that only one popover may be
visible on screen at once.

Popovers are requested from the UI context passed to Draw calls and
specify the anchor point and the desired dimensions. The popover is then
fit to the available space and placed relative to the anchor point.
 lib/ui/context.go | 23 +++++++++++++-----
 lib/ui/popover.go | 62 +++++++++++++++++++++++++++++++++++++++++++++++
 lib/ui/ui.go      | 28 ++++++++++++++++++---
 3 files changed, 103 insertions(+), 10 deletions(-)
[message trimmed]

[PATCH v3 0/4] Address completion 8 days ago

From Ben Burwell to ~sircmpwn/aerc

Since previous version:

- Reverted event bubbling to preserve original behavior
- Send events to popovers first, if visible, since they are conceptually
  "on top"/have a higher Z coordinate.
- Add scrolling in completion popover
- Add a global completion toggle in config

Todo (probably in a future patch set):

Be smart about address completion when there are already > 0 addresses
entered in the input.

Ben Burwell (4):

Re: [PATCH v2] Add custom sorting for folders 10 days ago

From Ben Burwell to ~sircmpwn/aerc

> --- a/config/config.go
> +++ b/config/config.go
> @@ -61,6 +61,7 @@ type AccountConfig struct {
> + FoldersSort []string `ini:"folders-sort" delim:"|"`

Elsewhere in the config, we use the comma as a delimiter. Is there a
reason not to use that here as well?

Re: [PATCH v2 2/5] Invert event bubbling 20 days ago

From Ben Burwell to ~sircmpwn/aerc

After thinking about this a bit more, I think that part of the special
treatment of popovers is that they get first crack at event handling. To
me, this makes sense given that they are effectively at a higher z-index
than the rest of the UI. So if a popover is being rendered when an event
fires, it goes to the popover first. If the popover does not return true
from Event() marking it as handled, it traverses down the widget
hierarchy as before.

I've updated my patchset to use this approach; this means that the
event bubbling doesn't need to invert. I'm going to play with it a bit
more locally before sending v3, but if anyone has feedback on the rest
of v2 in the meantime, let me know.