Re: GitLab integration take two, light edition

["Adam Sjøgren" <asjo@koldfront.dk>]

Eric writes:

> I don't have any experience doing this so I'm also shooting in the dark
> but...

Appreciated!

> It looks like the dynamic variable `gnus-treat-type' is bound while
> `gnus-part-display-hook' is being run, so you should be able to examine
> that to see if you're currently displaying "text/html" or what have you
> (it could also be nil) and only run your function once.

Cool - I will check that out.

Ok, so now I can run it once, and I also figured out how to add a
header. Thanks for the push!

> Another approach would be to add your function to
> `gnus-treatment-function-alist'.

Yeah, making a "real" treatment would probably be the correctest (I've
heard that's a word) way to go.

>> Also, the request actually returns a list of the various emojis, which
>> ideally would be iterated over, and added to the header instead of the
>> hardcoded thumbs up.
>>
>> Oh, and the ghub-request errors out with a 404 when there are no emojis
>> (funky API design), which really ought to insert an empty GitLab-Emoji:
>> fake header instead of just being ignored.
>
> These two issues shouldn't be hard, right? What is the actual elisp
> return value of `ghub-request'?

It's just a list of lists of conses, so if only I could remember which
is which of car and cadr, it would indeed be easy.

This is what I have currently:

  (defun adsj-article-treat-gitlab ()
    "Show thumbsup on GitLab comments"
    (when (and gnus-treat-type (string= gnus-treat-type "text/html"))
      ;;; (gnus-with-article-buffer
      (let ((project-id (gnus-fetch-field "X-GitLab-Project-Id"))
            (issue-iid (gnus-fetch-field "X-GitLab-Issue-IID"))
            (message-id (gnus-fetch-field "Message-ID")))
        (when project-id
          (string-match "<note_\\([0-9]+\\)" message-id)
          (ignore-errors
            (let ((emojis (ghub-request "GET" (format "/projects/%s/issues/%s/notes/%s/award_emoji" project-id issue-iid (match-string 1 message-id)) nil :auth 'nngitlab :host "gitlab.nzcorp.net/api/v4" :username "adsj" :forge 'gitlab))
                  (name-to-emoji '(("thumbsup" . "👍"))))
              (widen)
              (message-goto-eoh)
              (dolist (emoji emojis)
                (let ((name (cdr (assoc-string "name" emoji))))
                  (insert "GitLab-Emoji: " (cdr (or (assoc-string name name-to-emoji) `("default" . ,name))) "\n"))))))))))

  (add-hook 'gnus-part-display-hook 'adsj-article-treat-gitlab)

The mapping of name-to-emoji needs to be expanded.

Ideally I'd rewrite it to do a map and join over the list, so I'd get a
single header with a comma-separated list of emojis, if there is more
than one.

The cherry on top would be if mousing over the emoji showed the name of
the person awarding the emoji (it's in the data returned). But it's
getting dark now.

I tried using a different hook, but then gnus-fetch-field returned nil.

And I cheated on handling the error, just ignoring all errors.

> Is it more complicated than that for some reason?

No, I just don't know (e)lisp, neither the vocabulary of functions nor
the idioms :-)

> (I'd also be curious to see where you gave up with the actual Gitlab
> API -- do you have a relevant link you can share?)

What made me give up was that I found a comment about the value of
last_activity_[something] not being updated. I can't find it again
currently.


  Best regards,

    Adam

-- 
 Interviewer: "So you don't fear Linux?"                    Adam Sjøgren
 Bill: "Oh - I - you know - my job is to fear          asjo@koldfront.dk
  everything."