I see. I think you could try to write it with the internal functions
that I mention in the rest of this message and then we can more easily
see which parts are currently "internal" that could be "external":

1) Most important you need an easy way to get the the "diagnostic"
object at point. This is held by the overlays within their
'flymake--diagnostic' property.

2) You'll probably need accessors for the flymake--diag object (text,
type, issuing backend function). I think this is a question of renameing
the existing flymake--diag-text, flymake--diag-type,
flymake--diag-backend.

3) Perhaps a way to get all the diagnostics in a region. There is
flymake--overlays for this.

4) Maybe check the properties (severity) of a given type? This is
currently done via flymake--lookup-type-property.

Thank you for your helpful comment.

I've made a function (just for my flymake-tip package) using your comment.

--- code:

(defun flymake-tip-get-diag-text-on-line ()
    "Return list of string of error/warning info on the current line."
    (cl-loop for ov in (flymake--overlays :beg (point-at-bol) :end (point-at-eol))
             collect (flymake--diag-text (overlay-get ov 'flymake--diagnostic))))
---

As you can see, I used 1 (flymake--overlays), 2 (flymake--diag-text), 3 (flymake--diagnostic).

So, I hope those functions/symbol become public API. (i mean "-" instead of "--")

Also, after implementing my stuff, I popped up a question:

is there public API to check whether error/warning exists on the buffer?

The reason is I would make a command like flymake-next-error, but if there is no error

I would invoke other things. (maybe using flymake--overlays to check?)

Thanks,

Yuta Yamada

On Mon, Oct 16, 2017 at 11:23 AM, João Távora <joaotavora@gmail.com> wrote:

Yuta Yamada <sleepboy.zzz@gmail.com> writes:

> Hello Emacs devel.
>
> First of all, thank you to rewritten of flymake!
>
> I'm an emacs' package maintainer of flycheck-tip and
> flycheck-nimsuggest (nim language's flycheck backend) and I could
> convert to flycheck-nimsuggest.el for flymake very easy.
>
> But, as for flycheck-tip (which show flycheck/flymake's errors and
> warning on a tooltip), or other flymake related packages, could you
> support public API to get errors and warnings object? (I mean a public
> function for it)
>
I see. I think you could try to write it with the internal functions
that I mention in the rest of this message and then we can more easily
see which parts are currently "internal" that could be "external":

1) Most important you need an easy way to get the the "diagnostic"
object at point. This is held by the overlays within their
'flymake--diagnostic' property.

2) You'll probably need accessors for the flymake--diag object (text,
type, issuing backend function). I think this is a question of renameing
the existing flymake--diag-text, flymake--diag-type,
flymake--diag-backend.

3) Perhaps a way to get all the diagnostics in a region. There is
flymake--overlays for this.

4) Maybe check the properties (severity) of a given type? This is
currently done via flymake--lookup-type-property.

My only doubt is if 1 and 3 should work through the overlays API
(flymake--overlays and overlay-get for discrimination) i.e. If so the
API is smaller, but ties Flymake to an overlay overlay-based
implementation. Otherwise we can make flymake-diagnostics-at-point
etc...

> because I don't feel the fear of devel's change.

:-)

João