pager: fallback to syntect as syntax highligther

[granquet]

Fallback to use syntect library as syntax highlighter if no pager is defined in the meli config.

Signed-off-by: Guillaume Ranquet granquet@baylibre.com

[granquet]

The theme and syntax are hardcoded for now. Just pushing this MR as a draft to gather some feedback?

Using syntect as the syntax highlighter: https://github.com/trishume/syntect

[epilys]

Hm wouldn't it make more sense to offload this to the pager filter command instead of shipping it in the binary? It follows the unix philosophy 'Make each program do one thing well' by design.

[granquet]

Yes, the result would be similar to piping the mail content into syncat or other modern pager using syntect as their syntax highlighting engine.

Though I expect to be able to be a bit more intelligent about this if the coloring is done internally...
my intended use case is to split the mail by paragraph and apply syntax highlighting depending on the context.

I would like to have a mix of diff and mail coloring schemes depending on the paragraphs of the mail content and have a way to navigate between those paragraphs.

[epilys]

@granquet

Though I expect to be able to be a bit more intelligent about this if the coloring is done internally... my intended use case is to split the mail by paragraph and apply syntax highlighting depending on the context.

I would like to have a mix of diff and mail coloring schemes depending on the paragraphs of the mail content and have a way to navigate between those paragraphs.

This is reasonable! How about adding an option to pass more information
to the pager filter optionally?

To cover the broadest language support the serialization format could be
JSON. Not a big fan of it but it's easiest to deal with in scripted and
more languages.

The output going to the filter's stdin could be something like:

{
  "head": {
    "headers": {
    "header-name": ["header-value-1", .. ],
    ..
    },
    "other-metadata?": {
    ..
    }
  },
  "body": [
    {
    "name": text or null or missing as key,
    "filter": bool,
    "content-type": ..,
    "bytes": "bytes #0..",
    },
    {
    "name": ..,
    "filter": bool,
    "content-type": ..,
    "bytes": "bytes #1..",
    },
    ..
  ]
}

The client configuration option can be:

[pager]
filter = "/path/to/myscript"
filter_options = "plain" #default, current behavior
filter_options = { "type" = "json", "extra_headers" = [ "List-ID" ], include_binary_attachments = false }

Something like that.

I want to avoid adding dependencies if it's not necessary because (a) it
increases transitive dependencies (at the moment I think it's in the
hundreds.. excessive number and could get worse) (b) it makes it more
difficult to package without vendoring dependencies (like they do in
Debian).

I'd really welcome such functionality as separate binaries, perhaps in
the tools/ subdirectory? This way it can be shipped with the meli
project but make it opt-in. For example a small binary that depends on
serde-json and syntect only and nothing else, that can this sort of
intelligent highlighting for e-mail.

[granquet]

I understand your point... but this sounds rather complex for something that should (for me) be part of the mail client by default.

could it be added as a feature at compile time? would not change the default for everyone... but those interested could get the features built-in.

[epilys]

A feature sounds good! We can merge it that way first and then do improvements on future commits/PRs.

[epilys]

Hey @granquet, would it be okay for me to pick this up or would you like to work on this at your own time? No hurry, I just don't want your effort unused 🙃

[granquet]

Hi @epilys, no problem if you want to take over, I hadn't much time to keep working on these ideas.
I have a few more lines of code I can share though, I'll update the PR with the current code I have.